Critical problem with RTC dungeon

Guest · Post by **Guest** » Sun Jun 13, 2004 11:04 pm

Everytime I try to upload my dungeon to RTC is says it had a critical problem and has to terminate the program. I need help.

Post by **Gambit37** » Mon Jun 14, 2004 12:11 am

Hmmm.. not really enough information to help you. You need to give more information, for example:

Can you provide the error messages/warnings and/or log files.
Are you including any custom graphics?
What version of RTC are you using?
Are you using an editor to create your dungeon, or by hand?
If using an editor, which one?

Post by **Ameena** » Mon Jun 14, 2004 2:00 am

Sounds similar to the problem I had a few months ago which I posted about...though I still haven't heard anything from anyone about what's wrong or how to fix it...

Guest · Post by **Guest** » Mon Jun 14, 2004 8:40 am

RTC (V0.28) Diagnostic file - Sun Jun 13 23:29:59 2004

Error:
an access violation exception.

Stack Dump:
RTC.InitSecondary();
RTC.DoFrame(int 7);
RTC.WinMain();

darkdragon · Post by **darkdragon** » Mon Jun 14, 2004 8:47 am

I'm using the RTC that is on the front page of George's site.

I'm using an editor. It's the one that come's with RTC

No I'm not using any custom graphics

Me · Post by Me » Tue Jun 15, 2004 6:12 am

In a recent email to GG, I pointed out a serious error in version V0.28 that has to do with the "disable self" option of floor triggers. I have noticed that in any dungeon that I create containing a floor trigger with the disable self option selected, the game will crash at the end of compilation of the new dungeon or in the game when the trigger is stepped on twice by the party. When the disable self option of the trigger is removed in the editor, the file compiles with no errors and does not crash when stepped on multiple times.
I have not tested to see if this error occurs when the floor trigger is set to activate with a different opby (moster or object).
This kind of crash produced the same diagnostics error file that you posted above.
Perhaps when GG figures out why this happens a new version of RTC will emerge with the error fixed.

Me · Post by Me » Tue Jun 15, 2004 6:14 am

Sorry, with respect to the last post,
The diagnostic report I get is actually different:

Error:
an access violation exception.

Stack Dump:
RTC.CheckPartyTile(bool TRUE);
RTC.MovePartyForward();
RTC.DoFrame(int 50);
RTC.WinMain();

The problems are thus probably unrelated and are of a different nature.

Post by **Gambit37** » Tue Jun 15, 2004 3:53 pm

Those messages suggest that there is a problem with where your party is placed, and what available exist they have. Have you created some kind of continual teleporter system that creates a loop that you can't get out of? This can happen if you use teleporters with no delays attached.

As for the disable_self on floor actuators; I do believe that disable_self was never properly implemented for floor triggers, only wallitems. I've never been able to get it to work either.

Someone Else's Problem · Fri Sep 10, 2004 12:43 pm

thought i'd blast my way onto the RTC scene by resurrecting an old thread...

the above problem - RTC.DoFrame(int 7) - appears to be caused by copying and pasting objects. i don't know why this would be the case, although i'd speculate that you might be getting repeated references which in some cases would screw things up, but the fact is that since i stopped copying and pasting, i no longer have the problem.

[tick tock tick tock]

and so, subsequently, i thought maybe i'd expend two valuable minutes to test the theory. the conclusion is that repeat references is not the problem - copying and pasting produces proper references. so, all i can say is that not copying and pasting appears to prevent the problem from appearing. it is possible that i've started doing something else differently as well and the copy/paste thing is coincidental.

this is really going to bug me now.

George Gilbert · Post by **George Gilbert** » Fri Sep 10, 2004 2:25 pm

If it's any help then DoFrame(7) just means that RTC is loading and initializing; it really doesn't narrow down the source of the error very much at all!

There are some problems with copy and paste in V0.28 though, but these are now corrected for V0.29...

Someone Else's Problem · Fri Sep 10, 2004 3:55 pm

good to know - creating a room full of relay-toggled flashing teleporters without being able to copy and paste really makes you glad that it's actually physically impossible to chew your own eyes out. i shall stare in your general direction until 0.29 is released. no pressure.

George Gilbert · Post by **George Gilbert** » Fri Sep 10, 2004 4:59 pm

None taken!

In the meantime, you can of course set yourself up a single all-singing, all-dancing teleporter, save the RTC text file, open it up in notepad do the copy-and-paste the good old fashioned way, save it and then reopen the file in the RTC editor.

OK, so it's not exactly the greatest interface, but it works!

Someone Else's Problem · Mon Sep 13, 2004 2:26 pm

tried this out at the weekend (in excel rather than notepad, so that i didn't have to worry about screwing up references) and it worked out really well - not fab for overall dungeon design, but a great time saver for producing repeating patterns.

back to the question at hand; do we know what copying/pasting actually does that makes the whole thing go tits up? i was looking through some old (failed) dungeon files and found at least one object placed at -1,-1,-1; is this where the problem lies? (i realise that this is a problem, but just want to know if it's likely to have been caused by copying & pasting). if i can identify what problems it causes, then i can happily copy and paste in the editor and fix any bad nastiness that comes up via notepad.

beowuuf · Post by **beowuuf** » Mon Sep 13, 2004 5:55 pm

-1 -1 -1 is your elsewhere that chested items are stored until dropped by monsters - so it's perfectly natural, and is infact the reference you need to use for all objects that aren't physically located in a dungeon

things to look for may bee references that aren't going anywhere - so maybe a switch pointing to a non-existant trigger object?

Someone Else's Problem · Wed Sep 15, 2004 11:53 am

i can certainly reproduce the problem by pointing multiple triggers at the same object (see here). the editor is generally pretty good about preventing you from pointing a trigger at nothing, but not from pointing two triggers (that may give simultaneous conflicting instructions) at the same thing. perhaps this is the actual problem that can come out of careless copying and pasting.

beowuuf · Post by **beowuuf** » Wed Sep 15, 2004 7:49 pm

There should be no problem with pointing two triggers at the same object though...for exampel sending open and closes to switch a counter up and down....
so this is very buggy then!

Someone Else's Problem · Thu Sep 16, 2004 11:12 am

use of multiple triggers is fine (not to mention common practice); having, for instance, two constant weight FLOORITEM_TRIGGER objects next to each other is not. a creature stepping from one to another will simultaneously send out two conflicting instructions to the target. this was my mistake in the example that i linked to. while the editor doesn't see this as a problem and will verify just fine, it will cause a compile to fail as a result.

Post by **Gambit37** » Thu Sep 16, 2004 11:20 am

If you use relays and with a minimum delay (1/6 of a sec) you should be able to get around this limitation. As you say, RTC doesn't like messages being received from different actuators at the same time. If one of them sends it's message with a small delay, everything should be fine.

Having said that, your puzzle is a tricky one to get right even with delays as you can't predict when a pad will be toggled by a monster.

Someone Else's Problem · Thu Sep 16, 2004 2:37 pm

as i said in the other thread, i think counters are the key. still haven't got around to trying this out, but it seems logical. delays are a good idea, but they won't work in this situation because there's nowhere else for the monsters to go; however long you set the delay for, it's eventually going to catch up with you and cause a conflict.

so, here it is:

8 triggers (FLOORITEM_TRIGGER), constant weight, activated by MONSTER, deactivating a counter.
4 monsters on any of the eight triggers.
counter set to deactivate the pit on a count of 8. pit is defaulted to active.

so, the starting position will be:
4 triggers activating, 4 triggers deactivating for a count of 0 (pit active).
as every monster dies, the count goes up by 2 (first monster dies, there will be 3 deactivates, 5 activates for a count of 2). only when all four monsters die (so all of the triggers are sending an activate to the counter) will the counter reach 8 and deactivate the pit.

anyone see a flaw in my logic here?

beowuuf · Post by **beowuuf** » Thu Sep 16, 2004 5:49 pm

i seem to recall some weirdness with counters ansd constant weight effects...
try using open and clsoe triggers instead on walk on/walk out
i may be mis-remembering, i seem to recall soemthign happening badly with an alcove and counters with constant weight...i'll have to look back at old dungeon files and check...

beowuuf · Post by **beowuuf** » Thu Sep 16, 2004 7:15 pm

wait, maybe i've foudn the fundamental flaw - doens't a counter activate when it reaches 0? So effectively it will start sealed, and the pits activate as soon as the first monster dies

Post by **Gambit37** » Thu Sep 16, 2004 8:16 pm

Your logic is flawed, counters don't work quite that way. Check out this thread:

http://www.dungeon-master.com/forum/vie ... hp?t=20400

By the way, welcome to the forums! Nice to see someone else starting to play with RTC editing.

Someone Else's Problem · Fri Sep 17, 2004 2:13 pm

it should still make sense, though, surely, despite the fact that i've got the specific way that counters work ass backwards? or am i missing something? counters decrease from their count value each time they're activated, and activate on 0 - this is, practically speaking, the same as thinking that they start at 0 and increase with each activate, activating themselves on their count value. consider the fulya pit in CSB:

Code: Select all

1007	FLOORITEM_TRIGGER				21	0	0			OPBY=(MISC_CORBAMITE,ON_ONLY)	ACTION=(ACTIVATE)	TARGET=(1012)	
1012	WALLITEM_COUNTER				22	0	0	CENTRE	COUNT=(4)	ACTION=(ACTIVATE)	TARGET=(1289)
1289	FLOORITEM_TELEPORTER			3	24	0			STATE=(INACTIVE)		OPBY=(PARTY_OR_OBJECT)	DESTINATION=(0,1,0)	OPTIONS=(ROTATE:180)

you can slice this up either way and it works out. i blame george for all the confusion

still interested to know if there are any issues with constant weight triggers. i really ought to just try it out, but every time i go back to that area, i start to twitch. 'sides, it's fun to talk about it.

Thanks for the welcome.

Someone Else's Problem · Thu Sep 30, 2004 6:13 pm

Just found another good way to produce this error (as detailed in the original post). I tried to clone a chest and reduce its weight (for parties of 1 or 2 to ameliorate the general carrying capacity problem). Good old RTC.DoFrame(int 7);

This is especially fun when your main technique for tracking down the source of such errors involves deleting the levels of your dungeon one at a time, from the bottom up, and seeing if you can compile...

George Gilbert · Post by **George Gilbert** » Fri Oct 01, 2004 10:05 am

Strange - can you send me the RTC text file for this, and I'll fix the problem.

Dungeon Master Forum

Critical problem with RTC dungeon

Critical problem with RTC dungeon

Here's the diagnostics

It's still me, the guest