Crash to desktop using combination lock

[joebarnin]

I've got a CTD that happens when using a atdm:combination_lock_small. The lock is bound to a safe door (atdm:mover_door). I can get it to happen every time by setting the combo correctly (which opens the door), then closing the door, then trying to spin one of the combo dials again - as soon as you do this TDM crashes.

 

I cranked up logging. I saw one thing interesting, that didn't show up until the CTD:

 

[game\BinaryFrobMover.cpp ( 533):DEB (FROBBING) FR: 5085] [safe_door1] FrobMover is locked

This might be related to the crash because it's the last thing that is logged, just before all of the C++ destructor logging (which I assume is associated with the crash). E.g.:

[game\Entity.cpp (1889):DEB (FUNCTION) FR: 5085] this: 327766FC [idEntity::~idEntity]

But that's just a guess.

Anyway, it was suggested that Obsttorte might be the right person to help me with this? I've got a simple test map that displays this issue. Or let me know if there's anything else I should try.

Thanks.

Edit - I've experimented with different spawnargs on the combination lock, trying to see if that changed behavior - no luck. Also, I found a different FM that used the same lock (and doesn't crash), and tried to see what it does differently, but so far I can't figure out why it works and mine doesn't.

Edited September 12, 2018 by joebarnin

[Obsttorte]

The combination lock needs to target the door that it is suppossed to open (as said in the description!!!). You most probably missed that.

 

 

[s.urfer]

I added the following to the beta test thread, maybe it is useful here:

 

I found out one more thing: It crashes, if the dial is touched, after the safe opens.

 

Since I'm using the mousewheel for dialing, I seem to overshoot the last number one in five times.

 

Reproducing it with the keys also will lead to a crash, if you put in one more keystroke, as the number you'll need.

 

So it looks like its not the opening per se, but dialing after it opens - even if the door hasn't moved yet.

 

Maybe this can help to get to the bottom of this.

[joebarnin]

The combination lock needs to target the door that it is suppossed to open (as said in the description!!!). You most probably missed that.

 

 

The lock does target the door. I've created a very simple test map (attached). It is just a locked door, with a combination lock bound to it (and it targets the door too). I can get the CTD to happen every time: set the combo to 111, which opens the door. Close the door, then try to change the combo in any way. Poof.

 

Here are the two entities. You can see that the combination lock targets and binds to the door.

 

// entity 3

{

"classname" "atdm:3panel_104x56"

"name" "door"

"origin" "64 64 768"

"rotation" "1 0 0 0 1 0 0 0 1"

"lock_picktype" "-"

"lock_pins" "0"

"locked" "1"

"rotate" "0 90 0"

"used_by" "-"

}

// entity 4

{

"classname" "atdm:combination_lock_small"

"name" "combo_lock"

"bind" "door"

"combination" "111"

"frob_peer" "door"

"frobable" "1"

"model" "models/darkmod/mechanical/combination_housing01_small.lwo"

"origin" "34.76 61.875 821.75"

"rotation" "1 0 0 0 1 0 0 0 1"

"target" "door"

}

test.map.txt

[joebarnin]

Summary: I think I figured it out. Looks like there's a bug in tdm_numberwheel_lock.script. I can work around it in my FM, but I don't know what the real fix is.

 

Details: I have a software background, so I download the DarkMod source code, and VisualStudio, and did some debugging. Eventually I figured out that the crash is happening on line 73 of tdm_numberwheel_lock.script:

 

callGlobalFunction("closeBar",$safe_bar);

From my limited understanding of scripting, this code requires that the mod have a script called "closeBar" and an entity named "safe_bar". My mod had neither. I found an FM (Mission 1: A New Job) that uses the combination lock, and it has both. I think what this code is doing is, when you spin a combo dial away from the correct combination, it should close the "safe_bar" (slide it closed) which effectively locks the safe.

My safe doesn't have a safe_bar, so the hard-coded references in tdm_numberwheel_lock.script cause the crash. I can work around it by creating a dummy "safe_bar" entity in my map, and a no-op "closeBar" script.

But perhaps that script code should be more bullet-proof, so that if those objects don't exit, the app doesn't crash?

[Obsttorte]

Fuck, completely forgot about that. This issue has come up several times now.

 

The script shipped with the mod was specifically designed for the "A New Job" Mission and should have been placed in the corresponding fm folder. I noted the misplacement in the past but the file hasn't been moved by now.

 

For anyone using the script, remove the closeBar line.

 

I would say sorry for the circumstances, but it isn't my fault to be honest.

[joebarnin]

Perhaps I'm misunderstanding, but tdm_numberwheel_lock.script is part of the standard DarkMod install, in tdm_base01.pk4. I wouldn't think it was possible to modify that file. Can it be overridden (it defines an object called numberwheel_lock)? (Anyway, my workaround works fine).

[stumpy]

pk4 files are only renamed zip files.

[Destined]

Additionally, each file that you extract (and change) takes precedence over the ones still packed and each file or definition in your FM folder takes precedence over both of these, so you can change whatever you like for your FM without modifying the core game.

[joebarnin]

Ah, I didn't realize you can override core files like that. Thanks!

[Obsttorte]

Perhaps I'm misunderstanding, but tdm_numberwheel_lock.script is part of the standard DarkMod install, in tdm_base01.pk4.

It shouldn't.