&WAIT (CSBwin)

[beowuuf]

Would it be possible to have a DSA command that could take in a value and pause for that many ticks? Just I'm creating the Chaos/Order switches and the explosion chains for the Fuse animation, and they all happen at once.

[rain`]

If you want some delay in your DSA actions, remember you can set/clear/toggle the DSA's N/E/S/W inputs. I have a similar DSA that is a sequence of events, and what I did was give it a set north action, which closed a door, then after closing the door i had it give the dsa (itself) a clear north message with delay 6 and set the state to 1. Then in 1C0, I'd put in some code to spawn a monster behind a door with delay 8 or so. Then give a toggle message to the north to the DSA (triggering 1T0), which would proceed to launch some fireballs at the monster. After that, I did a set east message, which reopened the door and set the state back to 0. It was simply a pushbutton that spawned a mummy in a room and let you see it get massacred slowly =]. The changing states thing did cause me some problems though, i dont remember if i had to set the dsa to global state or if i actually ended up using and/or gates to trigger the dsa instead of the dsa triggering itself. There was some issue where if the state of the DSA wasn't the default (0 in my case), it wouldn't remember what state it was in.

Having a &wait inside a dsa is actually quite easily simulated using messages to itself (and L$ is probably made for this purpose!)

[Paul Stevens]

here was some issue where if the state of the DSA wasn't the default (0 in my case), it wouldn't remember what state it was in.

You have probably forgotten the exact problem. But it should
work. If you reproduce it, report it. I can't fix it if I don't know
about it. OK?

An issue with your solution is that it allows other things
to happen during the delay. You probably need to Freeze
Monsters during the time that you are delaying. You cannot stop
time because time is what runs the DSA itself.

[beowuuf]

Yeah, but you will lose all your variables and parameters calling the DSA, don't you? I am storing the location (and type) of the monster for clouds, moves and adds - losing this would mean having to keep re-capturing this information for each of, as it stands, 25 events.

[Paul Stevens]

You can pass information along with a message if you
use the &MESSAGE word. See:

http://www.dianneandpaul.net/CSBwin/doc ... guage.html

At any rate, a delay while executing a DSA is quite impossible.
It must appear to happen instantaneously to the rest of the
runtime engine.

[ADDF_Toxic]

Awsome! Awsome! Awsome! Awsome! Awsome! Thanks for the site! That shall be bookmarked! It might help me with DSAing!

[beowuuf]

Hmm, a bit messy but very doable...I guess I shall start staggering it thoguh the DSA then! : )

[ADDF_Toxic]

beowuuf, was that a typo?

I guess I shall start staggering it thoguh the DSA then! : )

I guess I shall start staggering it through the DSA then! : )

Am I correct?

[Paul Stevens]

That shall be bookmarked!

That list is very incomplete. I add to it as intelligent
questions arise.

[ADDF_Toxic]

Yes, I do see that there are some missing, but there are lots there that I do not know. And it has helped me with

Code: Select all

&ADD

[beowuuf]

Between the kentaro site (see the monster DSA- wait, http://members.at.infoseek.co.jp/danmas ... ator%20rot), the CSBuild help, and Paul's own documentation you can pretty much get most things

An example of a hole would be &SOUND, I can crash the engine with it no problem. I know this is from user stupidity but I will get back to it and ask 'intelligent' questions about it after I get this fuse thing licked

[ADDF_Toxic]

Okay, thanks for that site(too bad the ones I need right now aren't available!(ADD and DEL))

[beowuuf]

&Add is defined well enough with Paul's docs
&del simply uses object id and then the location of the item (see the CSBuild help for syntax), but doesn't seem to delete critters - use &move instead if you need to do this I guess...

[ADDF_Toxic]

lol squish them in walls!

[rain`]

Yeah, but you will lose all your variables and parameters calling the DSA, don't you? I am storing the location (and type) of the monster for clouds, moves and adds - losing this would mean having to keep re-capturing this information for each of, as it stands, 25 events.

If you place another dsa on the same tile (empty dsa, no code at all) after the DSA you're writing, you can the C and D variables as well as the A and B variables. Infact, you can add 10 dsa's (empty, no code) on the same tile below a certain dsa and that will give you the A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, and V variables, which can be loaded and stored between calls to the DSA. As far as I know, the above trick does work, but how far into the alphabet it goes I do not know, but I'm 100% positive that it works through J, as I have done it.

Also, if i assume correctly you are simulating a FUSE CHAOS feature in a DSA, wouldn't it be OK to have one of the messages as "move chaos on the tile and remove grey lord", one of the messages as "move grey lord on the tile and remove chaos", and reusing them? I don't know what you are planning on doing, but reusable DSA codes are always tricky to get right (loops, nested loops, etc).

[rain`]

You have probably forgotten the exact problem. But it should
work. If you reproduce it, report it. I can't fix it if I don't know
about it. OK?

I'll see if I can reproduce it with the latest CSBWin, but I'm most certain it was the fault of my DSA rather than CSBWin. I'm not sure how easy it is going to be to purposely reproduce bad code that doesnt work though =].

[beowuuf]

Lol, and yesterday Paul got at me for making things more complex than it needs to!

No, the &message calls are fine, it just means taking my nice NEAT subroutines for the clouds and stretching them out, with stores and recalls in between, then having my beatiful single line of move/adds and stretching it out too.

It's my own fault, I extended the functionality to fuse Lord Order aswell as Chaos, so that needs an extra consideration as to what is being displayed (chaos plus explosions first or oder and dispells first)

[Paul Stevens]

As far as I know, the above trick does work,

This is not a 'trick'. This is quite proper programming practice.
It is not very much more-or-less efficient than the &MESSAGE
and the &MESSAGE allows you to separate your DSAs to make
each one a bit simpler and easier to debug. &MESSAGE also
allows 32-bit numbers to be saved. But it is a personal
preference. Putting them all into one DSA saves using a DSA slot.
Zyx is probably running out, something I had never envisioned.

[beowuuf]

Problem encountered sending &message out

When I sent the message my DSA was in state 1
I hoped to trick it into being in state 3 when I got back by putting a '3' on the first command in that line (does this work on jumps and gosubs or just messages?)
Unfortunately, when I came back it was in state 0

0????!!!!!!!

I can't see the logic in that, except this is the initial state the DSA is in before the original message came in. *sniff* why did it default? : (

[Paul Stevens]

Have you read the <nextstate> documentation?
http://www.dianneandpaul.net/CSBwin/doc ... yntax.html

If so, and this does not explain your problem, then I
need a clearer statement of the problem or the dungeon
itself so I can try it.

[beowuuf]

Oops, forgot about that, cheers *smacks head*
Yup, that seems to work. And I see by the documentation the first commands full stop sets the next state, not the first commands of the last line of commands *oops* But cool, one step closer now!

[rain`]

Referring to the problem earlier in the thread I found, I found a way to reproduce the problem.

http://www.uwm.edu/~pjgross/dsastatetest.zip

The DSA is simple:

0S0: set state to 1, clear self in 3 ticks
1C0: set state to 2, toggle A, clear self in 3 ticks
2C0: set state to 3, toggle A+1, clear self in 3 ticks
3C0: set state to 4, toggle A+2, clear self in 3 ticks
4C0: set state to 0, toggle A+3

A pushbutton sends a set message to the DSA location, it sets the state to 1, and proceeds to toggle locations A, A+1, A+2, and A+3 (4 doors in a verticle row). If you press the pushbutton while it is opening the doors, since it is not in state 0, it shouldn't do anything.

Now, if you press the button once, all the doors open, if you press it again, the doors close. It will work endlessly. The problem is when you press the button very rapidly, the DSA becomes broken, and the button no longer does anything.

NOTE: It currently uses &SETNEWSTATE to set the state, if I tried using (in 0S0) L$ 1M3C*, it wouldnt even change the state at all, regardless of whether i used global, local, or parameter B as the mode. This is intended though correct? If i make it 1N L$ M3C*, it will change the state. I think the <next state> option will only work if the message is the first action in the DSA.

What do you think?

[beowuuf]

Yeah, I think with rapid presses the self-targetting message gets lost to the incoming normal messages - in the trace I tried, it stuck in state 1, the initial timer created by the DSA never seems to get processed. This isn't just DSAs, I believe it happens to anything with multiple signals incoming at the same time (sure I've heard Paul mention this as possible reason for things not working on rare occasions)

And yup, the state is set on the very first action - a literal leaves it in the same state

[Paul Stevens]

I think the <next state> option will only work if the message is the first action in the DSA.

As described in the documentation. (DSA Syntax, I believe)

press the button very rapidly, the DSA becomes broken

This is a bad thing, I agree. The original FTL code carefully
deleted identical messages to the same cell. Identical means
that they are to arrive at the same time at the same cell and
something else that I will not guess at here because even if
I guess wrong and correct myself later it will become gospel.

I am not sure why this was done. But if, for example, two
toggles of a doorway were generated to happen at the same
then only one would be processed. Why? Anyone have any
ideas?

It would be easy, and perhaps enlightening, and perhaps
even good, to bypass this behaviour. I hesitate to do it
globally for fear of breaking something in existing designs.
But I would be happy to do it for designs that are still
being created. Or I could do it automatically for any designe
that CSBuild writes. I guess I would like to do it automatically
because it is such a rare problem, easy to overlook, and
hard to debug. And counter-intuitive, if you ask me.

[Zyx]

Hmm, this could break my old DSAs and mechanisms. But I agree it would be better to make this change.

[Paul Stevens]

I took out the code that discards duplicates. I played
through CSB three times. Had to fix a couple things.
All went well until I threw the four corbum into the pit
very quickly. I died. I can throw them slowly but not
quickly. I'll try to determine why. Yuk.

[beowuuf]

Interesting, I tried with a normal CSB game (old engine), but slowing the speed down so I could effectively throw the corbums faster, and fireballs started being fired at the end game area, almost killing me, and then at slower speeds hitting me!

Aha, think I figured it out-ish - when you throw anything into the FULYA pit, one floor acuator decreases a counter that would target the fireballs. However, a corbum activated pad can get in first and increase the counter by one - so corbums don't generate fireballs if you put them into the pit. Why the counting four corbums mechanism works no matter the speed, yet this filtering mechanism doesn't at the end, is a mystery to me though!

[Paul Stevens]

Oh, dear. That CSB ending sequence is not supposed to work.
When you throw a Corbum into the pit a Black Flame is
transported to the pit and destroyed by a spell from a
Shooter. A Death Cloud results. When you thow another
Corbum into the Death Cloud, both the Corbum and the
Death Cloud get Teleported to the 'Corbum-Only Logic'.
The Death Cloud sends a Clear message to the counter
which causes the Party's death. This is as it should be
because only Corbum are supposed to be sent to the
'Corbum-Only Logic'. But the Corbum first causes an
increment and decrement of the counter. The Death Cloud
causes a decrement but the decrement is deleted by the
strange code that deletes duplicate messages to the same
cell. Well, that's nice because it works, kinda. But it works
for the wrong reason in my opinion. Moreover, as has been
discussed above, the original code does not work if the
party is quick enough.

It occurs to me that I may have made other errors that
cause this problem.
1) Maybe clouds are not supposed to be teleported.
2) Maybe clouds are not supposed to activate pressure pads.
Can anyone test these theories using the Standard PC-DM engine?

The final result of all this experimentation is that I am
going to allow the designer to specify whether he wants
these duplicates deleted. And I am going to remind him
until he makes a decision one way or the other. Then I
will be quiet. Three pass through CSB (no spped runs, I
can assure you) convince me that it won't be disastrous
to leave these duplicates alone.

[beowuuf]

I can test 1) and 2) in PC DM tomorrow if no one else has done so, but I would have assumed clouds wouldn't trigger pressure pads

[Paul Stevens]

would have assumed clouds wouldn't trigger pressure pads

That makes a lot of sense. The Pressure Pad is supposed to
be triggered by 'Anything'. I don't know about levitating
monsters, either.