Dungeon Master Forum

Whenever I try to set a WALLITEM_RELAY's Delay to "0", RTC crashes. Everything is fine if I set it to "1" or above.

Edit: I have created a 1x1 room that you teleport to and get blasted with fireballs until you die. The relay switch that I use for the fireballs is the one that the game crashes on.

The game will crash the same way if you go to the original DM and enter the "Outside" space (Level 0), and set the fireball relay's delay to 0.

Are you setting the relay constantly with some kind of looping actuator system? RTC will definitely crash if you do that with no delays as it gets into a recursive loop far too quickly and simply can't keep up.

While this is technically a bug, it's also bad design on your part. I'd put in a delay of 1 to at least give you some control. That's only 1/6 of a second so it should still be quick enough for what you want to do.

To confirm, RTC will crash if it gets into an infinite loop (another example is to have two teleporters pointing at each other so that if you enter one you'll continually move back and forth taking zero time to move).

This is entirely intentional (there's a thread somewhere discussing this).

I wanted to make a space where if you enter it, you instantly die from a hail of fireballs (no matter what level you are). I have found a work around for this (just add more shooters to the walls )

It's funny how sometimes you can't think of the simplest of solutions.

Thanks for your responses - I can see why 0 delay would cause problems.

George Gilbert wrote:This is entirely intentional (there's a thread somewhere discussing this).

The behaviour may be intentional, but the crash isn't.... I'd say that's a bug.

my guess is he means it will crash and kill itself rather than sit there doing nothing and taking up all your processor power, right?

Well, any known exceptions should be handled gracefully, like giving a warning or something. Bombing out with no warnings and no errors is just rude!

Beowuuf - exactly!

You've got to remember that RTC is actually a turn based game; it's just that the turns are very, very quick (1/6th of a second) so it looks like it's real time. If you've got a 0 length delay, or two teleporters pointing at each other etc, then the turn in which they are activated an infinite number of things need to happen. In Lighthouses case, RTC needs to pump in an infinite number of fireballs into the room (which admittedly, would acheive the desired effect of killing the party

In the attempt to do all of this, the engine would never get around to the next turn and therefore the game would appear to freeze. The way I've chosen to deal with this is to detect when a huge number (1000 I think) of identical actions need to be done on a single turn and if this occurs deem it equivalent to an infinite loop (which it probably is) and fall over.

The reason for doing it this way is that by falling over, you get a stack dump showing the repetitive action and this gives the dungeon designer a good crack of guessing what the issue was. In any case, it's much better (IMHO) than just freezing.

Any comments or better suggestions however are, as usual, always welcome!

I think you missed my post by posting at the same time George.... see above. In my experience with this I've not received any log files or anything showing what the problem is -- hence the need for an error message or warning. Has this changed in later verisons?

I've improved the handling of recursion for V0.33 but I'll leave the post (and the various explanations) here as I agree that this might look like a bug but it isn't (no really...honest!)

Is there anything that can be done with a zero-length delay? If not, they could be identified at compile-time and reported as errors.

Kain: Yes, pretty much every time you use relays you want the message relayed immediately. The problem here isn't the relay it's the self-activation. I mean, without looking, I can tell Lighthouse's relay was activating his shooter and then itself, reactivating the shooter and itself, etc...

The coorect way to go about it if you want to instantly kill the party is for the relay to activate the shooter and a power 999 damager on the floor tile where the party stands. If you don't get the cloud before the party dies, then delay the damager activation by a tick or two via a second relay, but that's really splitting hairs.

Note a 1/6 delay between activations means the party gets six of whatever is shot in the face per second...not exactly a tiny amount!

There is a fast global action btw that acts instantly, but it isn't adviseable to use it much, for the whole load of 'things happening in recursion or before other things' reasons

Postby George Gilbert » 28-Jan-05 09:17
To confirm, RTC will crash if it gets into an infinite loop (another example is to have two teleporters pointing at each other so that if you enter one you'll continually move back and forth taking zero time to move).

This is entirely intentional (there's a thread somewhere discussing this).

Two teleporters pointing at each other should NOT crash RTC if only one of them is active at a given time.
It turns out that RTC V049 crashes when you toggle both of them to have the active become inactive and the inactive become active, to throw an objet from one tile onto the other tile.
This is a simplified version of a mechanism where I wanted to move some object when toggling teleporters.
I made sure about having no loop at anytime, but got crashes.

This bug is, I think, from the way RTC is updating teleporter states and teleported stuff. Spurious loops can happen while updating so it crashes.
To avoid such crashes: RTC should firstly update teleporter states over all tliles of the dungeon, secondly move teleported stuff. This way, no spurious loop.

Deactivate the "receiving teleporter" to get rid of that issue...
You're toggling the "sender" so it sends the item, the "receiver" is still active, so it sends it back... then the "sender" sends it again, and again... CRASH!
If you ALWAYS disable the teleporter on the "receiving" end BEFORE you activate the "sender" then it'll only send the item ONCE.

I repeat:

Two teleporters pointing at each other should NOT crash RTC if only one of them is active at a given time.

It crashes, it is clear why it crashes.
IMO it is a bug. The user should not be asked to waste his time with workarounds and twisted ways to do simple things.
The real time implementation is wrong.

Not really, it's just a matter of the order of your actions. If you teleport the item first, the other hasn't deactivated yet, so deactivate the teleporter on the recieving tile before allowing the teleporter on the sending tile to be activated. There is nothing twisted about this workaround, you are doing exactly the same actions, just in a different order. If you are toggling, just toggle the teleporter on the recieving tile off first, then toggle the teleporter on the sending tile on, it can be as simple as the order of your targets on the trigger that toggles the teleporters. You will just need a separate trigger for each teleporter in the sequence that targets them in the correct order.

It doesn't matter whether you feel it's a bug, or bad design, or whatever: it won't be fixed because RTC is no longer in development. So a work around is the only option.

I personally don't consider this a bug any more then someone doing the math equation 4 + 1 * 2 = 10, rather then the correct answer which is 6. It's just order of operations, which in this case is multiply, then add. In RTC it's teleport, then toggle, escpecially if the triggers are set up to do the actions in that order. So if you wanted the math equation above to be 10, you just change the order of the operations, so you add first, then multiply. so you get (4 +1) * 2 which really does equal 10. Just like in math, you just need to be aware of RTC's order of operatins and plan your trigger targets accordingly.