new features (CSBwin)

[Zyx]

I'm working on the wallsets and this is going to take me a long time. Could you, meanwhile, implment some features:

I'd like an operation to increase skills experience, something like &ADDMASTERY (<char num> <skill num> <gain>)

Could you implement the mirrored view for the skins?

Could you implement the postmove monster filter? (allowing to put sounds if they moved)

[Paul Stevens]

Skills should be easy.

Mirror? How do we want to do this? The floor and
ceiling.....we could create 'virtual' graphics at runtime.
Say that you have a floor graphic #23. At runtime you
might say that if #24 does not exist then create it as
a mirror of 23). In the code you would say:

Code: Select all

OddPartyView? 
  IF
      23 24 CreateMirror    //Does nothing if 24 already exists!
         <use graphic 24>
  ELSE
        <use graphic 23>
  THEN

OddPartyView would be non-zero if x + y + facing is odd.

Postmove monster filter should be possible.

[Zyx]

You said that if the graphicID number was higher than 127, then for OddPartyView it would use the next ID.
But the mirroring function is still needed for the masks, since they can be assymetrical in case of floor with relief.

[Paul Stevens]

You said that if the graphicID number was higher than 127

It took me a long time but I found it. And that is NOT what
I said. Here is what I said:

That is why two skins are
necessary. If the skin number is 128 or greater then
the program will display the specified skin for the odd case
and the next higher skin for the even case.

It was Skin numbers, not Graphic IDs. Very different
because there are 65000 graphics and only 256 skins.
But I said that back in the days when you had no control
over what was being displayed. In those days it was all
hard-wired into CSBwin and only the pictures and masks
existed to give a hint as to what was wanted.

I think my most recent suggestion (three posts up) is much
less 'special-case' and much more flexible and much less ugly.
Your code can simply add one to the graphicID.

Code: Select all

OddPartyView  +

This will work because the boolean value is 0 or 1.

[Paul Stevens]

Could you implement the postmove monster filter? (allowing to put sounds if they moved)

I spent about four hours today trying to trace and
diagram the code for monster movement. I don't feel
very much closer to getting this done right.

Here is a proposal.
-A-At the front of the moster movement code (when I
call your present filter) I will note the location and
direction facing for each monster in the group.

-B-At the end of the monster movement code I will
try to find the monster in the same location.
There are four cases:
-1-He ain't there anymore. He either died or moved.
If he died it was probably the result of movement into
a teleporter or something that caused him to go to
a level where he is not allowed. Or he moved into the
path of a fireball.
-2-He is still there but one of the members is gone.
-3- He is still there but one or more of the members
of the group has turned.
-4- He is still there and nothing whatsoever has changed.
I can call your filter and tell you which of the four
cases I discovered.

Would that be sufficient? Should I call the same
filter with a C0 message? Or do you need a new
'Post-move' filter? I will guarantee that each call to
your present filter will be followed by exactly one
call from the 'post-move' code.

[rain`]

You could use a DSA for this. I actually made a DSA that took 2 parameters (A = location of upper left bounds of an area, B = locationf lower right bounds of an area) and actually went through the entire area room by room checking for a specific monster. When the monster moved, it would do a set on all rooms one square away from the monster and the room of the monster itself, and specifically not send a set message to any other room that does not reside in the specified bounds (A and B). In case your wondering, it is a flying invulnerable monster in a room full of pits =].

If you want, its actually well documented and perhaps re-usable? The only downside is it only is designed to go through a set area, making the area very large would certainly make it one hefty DSA.

[Zyx]

Here is a proposal.
-A-At the front of the moster movement code (when I
call your present filter) I will note the location and
direction facing for each monster in the group.

-B-At the end of the monster movement code I will
try to find the monster in the same location.
There are four cases:
-1-He ain't there anymore. He either died or moved.
If he died it was probably the result of movement into
a teleporter or something that caused him to go to
a level where he is not allowed. Or he moved into the
path of a fireball.
-2-He is still there but one of the members is gone.
-3- He is still there but one or more of the members
of the group has turned.
-4- He is still there and nothing whatsoever has changed.
I can call your filter and tell you which of the four
cases I discovered.

Would that be sufficient? Should I call the same
filter with a C0 message?

Yes, it would be enough, and yes, a C0 call would be better.
Could you differentiate, for case 1, if the monster died or not?

[Paul Stevens]

differentiate, for case 1, if the monster died or not

Well, the problem is that if he ain't there no more then
I would have to search the dungeon for him. I'll see
what kind of ugly solution I can devise. And, for all I
know, you have picked the poor Screamer up and
placed him in a chest an launched him into the air.

(You better not move the minster that is the
subject of a filter.......I will draw that line at
supporting such things.)

[Zyx]

Don't you just need its ID and check its hitpoints?

[Paul Stevens]

If it is still alive and kicking then OK. But if it is dead
then the record containing the hitpoints has been released,
is perhaps being used for something else, and perhaps
contains simple garbage. If the memory has been released
the referencing it would cause a hardware crash.
If you are interested in its working most of the time
and crashing some of the time then that would be OK.

[Zyx]

Then I choose option no crash never, as proposed before... Since the mosnter would have died by being teleported, it means it would have moved anyway, so it's ok.