CSBwin Version 9.51e

[Paul Stevens]

A pre-release, test version of CSBwin is at:

bahamas.globat.com/~dianneandpaul.net

It is labeled version 9.51e.

It has (these will be repeated in the final release)

--Two linefeeds in scroll text now displays an empty
line rather than a 'J'.
--Full-Screen capability.
--Anti-Fire and Anti-Magic capability.
--DM Rules option in Misc menu
--Reincarnate can use DM rules for adjusting stats
--Detects infinite message loops
--Prevents going through walls to 'Loot' portraits
--Illegal portrait text yields 'BOGUS' 'ILLEGAL HERO'
--Clears screen when screen size changes
--Repairs 'EVIL-OUTSIDE' wall graphic from distance=3.
This is an error in the graphics file, IMHO. I hope I
didn't break something else.


If you try it, please let me know of any problems.

My pile of runtime-engine cards is empty. Please let
me know of any additional problems before I give
this to Erik to adapt for Linux.

[Zyx]

Thank you again for your work!

"This is an error in the graphics file"
Could you explain why?

"Prevents going through walls to 'Loot' portraits"
Could explain this decision? (some custom dungeons were meant to allow looting by putting trick walls instead of real walls)

"Please let me know of any additional problems before I give this to Erik to adapt for Linux."
1) If I put a torch with "torch type" and "15 charges" in CSBuild, it appears as an burning torch when I grab it from the floor in CSBwin, and it still as a burning icon if I put it in the backpack. I have to put it in the hand and take it out of the hand to set the icon right.

2) In DM, when in the backpack view, if you put a scroll in the hand of a character, it becomes an open scroll. In CSBwin, it doesn't. (in both cases you can read the text)

[Paul Stevens]

The error in the graphics file......

The graphic is more than 63 pixels wide and less than
81 pixels wide. It is 76 pixels wide as I recall. Therefore
it requires five groups of 16 pixels....pixels come in groups
of 16 - ALWAYS. Five groups of 16 pixels requires five
groups of eight bytes...there are eight bytes per 16 pixels.
Five groups of eight bytes is forty bytes.
But the graphics file says the graphic is forty-eight bytes
wide (0x30). So when it is displayed it comes out with diagonal
stripes and some undefined garbage at the bottom.
=======================================
I made this decision because it was clearly the
intent of the original programmers.

I did not prevent you from going through trick walls. At
least I did not intend to.
=========================================
Torch. Hmmmmm. I guess I will have to look into that.
========================================
Scroll. Hmmmmm. I guess I will have to look into that.

[Zyx]

The error in the graphics file......

Understood. But how is it that the graphics look fine from distance 1 and 2 and is only garbled from distance 3?


"I did not prevent you from going through trick walls. At
least I did not intend to."

i think I misunderstood. I'll have a check.

[Paul Stevens]

But how is it that the graphics look fine from distance 1
and 2 and is only garbled from distance 3?

The data for the other graphics at distance 1 and 2 must
be correct.

[Zyx]

"The data for the other graphics at distance 1 and 2 must
be correct."
I thought that the graphic from distance 1 was the original,
and that distance 2 and distance 3 were only scalings?


Here are some suggestions for CSBwin:
1) Is there a way to make a text (not a wall text but a "voice" text) be heard even if you're not on its cell? If the text receives a set message, you hear it.

2) When a monster releases a pad and objects, the pad is not checked (ie, a pressure pad activated by the weight of an object wouldn't be activated)
Could you change that?

3) Samely, if a monster gains an object (for example a giggler), and it's carrying a pad, the pad is not checked either.

4) By the way, I read a thread about what should rob gigglers. Somebody said the code was ready to allow robing from the body, the pack, etc...
Could it be that you add a variable associated to each group of gigglers, stating their "Ninja level"?
Example:
Neophyte: Can only grab objects from the hands
Journeyman From the hands, and from pouch and the belt
Expert From hands, pouch, belt and from backpack
Archmaster From hands, pouch, belt, backpack and body.
What do you think of it?

[Paul Stevens]

I thought that the graphic from distance 1 was the original,
and that distance 2 and distance 3 were only scalings?

That might be. I don't know how that works. But I do know
that the graphic.dat file contains the data required to properly
display each graphic at the various distances. I called them
"RECTPOS' in the code. One of these structures tells
--X, Y of upper left
--X, Y of lower left
--Width of graphic (in bytes)
The one in question had the wrong width.
=============================================
1) Sounds.....

You know...That would not be hard at all. You could provide
.WAV files for each such sound that you want. The DSA
could have a "Play Wavefile" function.
It is a bit different from the origian DM; what do other people
think about this capability?

The "Play Wavefile" function could have a "WAIT" option that
makes sure the playing is not interrupted by some other
sound.
=============================================
2) Pressure pads not checked.

Please give me VERY precise example of what happens
now and what you want to have happen. It souds like
it might change some existing puzzles. I don't want to
destroy that kind of "forward compatability".
=============================================
3) I don't think there is any reasonable way to have different
kinds of Gigglers. I don't think there is any space for
additional information.

Having said that......of course there is a very large space
for additional information....in the form of items being carried
by the Giggler. For example, if the giggler is carrying text
that starts with 'J' then he is a 'Journeyman'. When a Giggler
dies with non-displayed text we can delete the text to avoid its
piling up in the dungeon. An advantage is that very few
existing dungeons contain Gigglers carrying non-displayed text.

The biggest problem with this is that one month after I implement
such a thing I will have forgotten it completely. It would need to
be documented for Posterity (you remember him, I hope).

But that does not address the problem of 'Generating' such
Gigglers. Here is another example of where a special
'Modifier' actuator could be used. It would modify the action
of the 'Monster Generator' that follows it in the list. I had
suggested such a 'Modifier Actuator' to solve some other
problem, but I forget what it was.

But all of this is speculation for the far future. There are other,
more pressing issues that need solving. Things like the
Portraits on trick walls that already work but that CSBuild
does not allow.

[beowuuf]

2) Iwas the probelm rain complained of. If a monster drops objects and a pressure pad, then a) the pad won't trigger right away, and b) the pad can't be triggered at all until the objects on it have been removed

So you cannot have a dragon carrying a steak activated pressure pad to trigger anything on its death, and but you can't have a dragon carrying a party activated pad either, as it won't be triggered until the dragon steaks are cleared, which can't be guaranteed.



The only other instance of this is objects starting on a pad/pit in a dungeon. But this seems bug-like anyway. A rock can be placed on a pit and won't fall until someone stands on the pit!

[Paul Stevens]

OK. I think I see. Did the monster drop the objects in
the correct order? The pressure pad first and then
the Rock? Did the Dragon drop the actuator and then
the steaks? You cannot control this last one. But if
the first one works maybe we can arrange for monsters to
drop their 'remains' after dropping their 'possessions'.

That rock on a pit is funny! You cna get that effect
by putting a rock at the top of a stairwell, too.

[beowuuf]

The order doesn't seem to matter, from what I checked. A list of apple and pad in either order produces the same non-effect. Dropped possessions and natural possessions both appear too fast on the pad to register aswell. Dropped monsters work, as there is a delay between the death cloud before the next monster appears...

[Paul Stevens]

OK. I thought that should work if they were in the right
order. I will see what is going on.

[Zyx]

1) "Is there a way to make a text (not a wall text but a "voice" text) be heard even if you're not on its cell? If the text receives a set message, you hear it."
Sorry, it is sometimes hard for me to find the correct words in english.
Allow me to change the question:
If the text receives a set message, you READ it.
I was asking for "global texts" instead of "local texts".


Sound:
It is a very interesting idea of course, however personnaly I see it as a low-priority, big expansion of DM. Let's see what other think.
To be honnest this looks as a "dangerous" option to me. Customized dungeons will be several hundreds of Kb, and there are great chances of ruining the DM atmosphere. Of course it's up to the designer, but such an easy tool couldn't be ignored, and I fear people would spend more time adding sounds instead of designing a good dungeon.
DM Java has this "customized sound" option. I don't play it, but if there is somebody here who does, maybe he/she can tell us if it's worth it.
Maybe this topic deserves a new thread?

3) gigglers. Understood. The invisible texts are a good idea but they seem a complication, so I agree to leave this for later. We may have some better ideas.
Just suggesting (maybe it's a nonsense): gigglers don't do damage, so maybe there is space in the variable that other monsters use for damage?
Another way to solve the gigglers problem is to include a global information in the dungeon.dat: all the gigglers would have the same capacities. I guess you can easily add data to the dungeon?

2) pressure pads carried by monsters. I'll try to be more precise:
let's consider that the "content" of a monster is a cell like any other.
This cell has a pressure pad, activated by any objects. For example this pressure pads would open a door when you put an object on it.

Case A:
A giggler posess this pressure pads. It robs you an apple. So know the giggler has a pressure pad and an apple.
Now if we look at the content of the giggler as a cell, it is clear that the pressure pads should be activated: it just received an apple on it.
However in DM, CSB and CSBwin, nothing happens.
I would like the pressure pad to be activated. (it would allow some neat tricks like giving things to a giggler who, in exchange, would open door or give you other things)

Case B:
A giggler carries this pressure pad and an apple. When it dies, it leaves the pressure pads and the apple.
In DM, CSB, CSBwin, nothing happens, as the pressure pads doesn't receive the apple. The cell referring the monster now refers the pressure pads.
However the pressure pad should be activated by the apple, as in appearance, for the player and the designer, the pressure pad, released on the cell, has received an apple.

Case C:
Same as case B, but it's a screamer carrying this pressure pad. When it dies it leaves the pressure pad and some random screamer slice. The pressure pad should be activated because of the screamer slices.

[Paul Stevens]

1) Display text. We could easily add a DSA command
to display text. It would do what you want.

I agree about the sound. I would not want it myself.
Except for perhaps some particular noises that would
provide clues to what is going on....as the sounds of
unseen doors do.
========================================
2) Neat idea. I think your method of going about it is
too complicated for implementation. Pressure pads are
very complicated things in the code. And if you kill
the Giggler, he will drop the pressure pad and you
can then activate it by placing an apple on the floor.

What you want to do is buy things from a Giggler.
Killing him does not work. I like it. It ain't very DM-ish.
I will ponder this as I doze off tonight. Sometimes
things seem clearer after a couple days of pondering.

I agree with case B) and thought it should work. I
don't know why it doesn't work and told Beowuuf that
I would investigate.

Case C) I agree but I don't have any idea
whether it might work. As I told Beowuuf "maybe
we can arrange for monsters to drop their 'remains' after
dropping their 'possessions'".

[Zyx]

"if you kill the Giggler, he will drop the pressure pad and you can then activate it by placing an apple on the floor"
The only way i found to avoid it was to imprison the giggler on a cell with a teleporter for objects. If the giggler dies, its possessions are teleported but not the pressure pad.

Case B: I think it doesn't work right because the cell "receives" a pressure pad, but the pressure pad was already linked to the apple.
Maybe CSbwin consider that only one object can fall at a time on a pressure pad, so it only checks the first object, not the other ones linked...
Am I clear on this topic?

[Paul Stevens]

As clear as any of the rest of us.

[beowuuf]

Stolen items don't appear in the carried objects list though, do they?

i did as messier version of the pressure pad thing when rain brought up the subject - it involved a cloned tile with a teleporter, so the objects were teleported away no matter where they were dropped, then returned afterwards to the same tile

I will upload the dungeon, if i can find it, when i get home, if i can find that

[Zyx]

"Stolen items don't appear in the carried objects list though, do they?"
Yes they do!

[beowuuf]

Ooh, never knew that : )
Then you can do your system...preliminary hunts for the dungeon were unsuccessful, but basically you have the pressure pad tile cloned with a teleporter above it, and have a constant trigger effect activating it. It teleports briefly to some destination that activates the effeect you want, which can also disable the original teleport trigger. It then teleports back.
One time only,. so you couldn't keep giving items for money, or whatever though