Dungeon Master Forum

This is to primarily to Adamski following a UD post, but anyone jump in.

Have you experienced problems in your compiled dungeons that don't occur in test mode?
Specifically trigger queue crashes near the end of the dungeon?
I had a lot of problems here, mainly from destroying triggers after use. It never happened once in test mode, but a lot in the compiled dungeon, and always near the end.
Something that would work fine early on would crash the dungeon near the end, and because the dungeon would typically take around nine hours to complete even running through it very fast, it became a real pain in the arse to test. Took months.
This is the only one of my dungeons this ever happened in, and I'm sure it's down to the weight of objects in it (you start only two hundred away from the limit), but it only ever happened near the end.

I ask you because I got the same trigger queue crash on one occasion in ToC that fortunately didn't recur when I reloaded the save (it was on the way back down the tower when the legions appear, in the room full of gargoyles on the symmetry level).

Can you tell me in which situation does it happen? Is it random? Does it happen in specific places or after specific actions?
Usually random crashes near the end can occur when new objects are created in game and the object limit is overtaken.
Sometimes I noticed crashes when monsters are teleported in a tile where is another monster. And when monsters or objects are teleported in a tile where is an active teleport. However it is strange that you notice these crashes only in the compiled game.

Sometimes I noticed crashes when monsters are teleported in a tile where is another monster.

Yup, this is a problem. If the monster is invincible it will crash for sure. I have had the same problem also when creating monster in front.
Testing doesn't always reveal errors.

Chaos Shaman, I've never noticed any difference between the test mode and the compiled game.

Saumun, I have a suggestion: try to change the trigger delays. It's enough setting the delay to 1. Do the same with the relays that are activated by those triggers. In many cases realys that activate other relays recursively and without any delay could crash the game.

This was a while ago now, and I managed to sort the crashes out. They were almost all caused when items as part of a sequence were destroyed. Got around it by simply deactivating instead, but it changes the aesthetic in places. I was trying to get rid of as many objects as possible. It felt like the engine struggled the further the dungeon went on.

It was just puzzling that something that worked perfectly in test mode and also early in the dungeon, would crash later on.
Also... It didn't ALWAYS crash in these places, just sometimes. Making it even more infuriating to test.

Chaos Shaman, I've never noticed any difference between the test mode and the compiled game.

If you clone an object and remove it, testing will work with no errors, compiling the same thing can give an error. Cloning anything and removing it can give an error if there is a query, a very frustrating one. I've lived through this enough times and was to be quite frank, pissed on a number of occasions when I went to play the dungeon, behold there is an error where the error checker in the rtcedit did not show it, it reported no errors. Without compiling it, it can be missed.

@ Saumun, my experience has been that RTC is unstable when complicated mechanics are placed and removed when applying to: and from: using relays. Cloning and assigning a relay for the cloned object has been where I lose my mind, I figured out I had to remove all objects that references the cloned object and removed the object reference to get rid of the error. Using relays that query cloned objects that have been deleted produce errors. Your dungeon is massive, no doubt there is a few deleted relays that referenced a cloned object that no longer exists. I still can't believe you built such a huge and complicated dungeon with so few errors. Your timing was flawless on your puzzles with teleporters and monster spawning.

CS... My findings at the time certainly agree with you, in that certain sequences tried to target something already destroyed (hence an empty trigger queue). The strange thing is that it happened here and there near the end despite all the queue orders being correct. It felt almost like the engine was running certain things at different speeds, so that an object is destroyed too early.

This is guesswork on my part as I don't know how it all works.
There is, however, definitely timing issues between different relay loops.
In my new dungeon I have had instances where loops timings activated by different triggers on the same square degrade over time.
Logically a fractional difference would be expected due to the queue system, but that difference seems to increase constantly rather than always having a tiny difference. Easy to get around by having everything stem from one loop, but it could explain the crashes occuring late in the dungeon and not at the start.
I thought at first that it might be down to the number of objects, but I doubt it since there are significantly less near the end... or are they stored in a cache of some kind that starts to make the engine sluggish?
I don't know.

Saumun, I did notice running more than one loop that activate each other does give errors, I had that experience with light. I never could get it to operate properly when in a loop.
About the testing. There is one important factor about using test mode to run the dungeon, you can't save. It is only upon saving that a serious dreaded error will occur with the "null" in place. I can't state how much that bothered me. I'll compile it always in order to be able to test the saving for that error. Todays computers are fast that a big dungeon can compile in a few seconds.

It would be nice if GG could explain this, but as we all know he is gone. I hope there is a new engine in the future where it has a good GUI for people who didn't follow up with programming in their life.

When is your next dungeon finished?

Part 1 is 99.9% finished, but untested.
If you're still interested in beta testing, I should have something in about a weeks time.

Sure, I could spend a bit of time. It will be fun.