Lockpick-Key selection causes crash - Heart of Lone Salvation - 2.09

[Zeen]

Apologies in advance if this is a known problem, I haven't found any results from my search.

My Heart of Lone Salvation mission save started to crash whenever I tried to select lockpicks or keys. Other items (I tested potions, reading material) seem to be fine, but whenever I select lockpicks or keys the game freezes and crashes to desktop. I restarted the mission and it seem to run fine is there a way to solve this without restarting the mission?

If you want to try out, you can find my save at https://www.sendspace.com/file/yzn2qk

[stgatilov]

Quick workaround:

1. Go to Settings \ Gameplay \ General.
2. Set Use-by-frobbing to Disabled.
3. Load the game and continue playing.

Note that with this setting disabled, you have to hit Enter on keyboard to apply keys and lockpicks to doors/locks.
I have checked that I can successfully lockpick something, but I can't be sure the game will work properly.

Also, please keep this crash-save around: most likely I'll ask you to test the fix when it is available.

 

[stgatilov]

>	TheDarkModx64.exe!idPlayer::PerformFrob(EImpulseState impulseState, idEntity * target) Line 11496	C++
 	TheDarkModx64.exe!idClass::ProcessEventArgPtr(const idEventDef * ev, __int64 * data) Line 1047	C++
 	TheDarkModx64.exe!idInterpreter::CallEvent(const function_t * func, int argsize) Line 819	C++
 	TheDarkModx64.exe!idInterpreter::Execute() Line 1092	C++
 	TheDarkModx64.exe!idThread::Execute() Line 872	C++
 	TheDarkModx64.exe!idClass::ProcessEventArgPtr(const idEventDef * ev, __int64 * data) Line 1047	C++
 	TheDarkModx64.exe!idEvent::ServiceEvents() Line 598	C++
 	TheDarkModx64.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds, int timestepMs) Line 3393	C++
 	TheDarkModx64.exe!idSessionLocal::RunGameTic(int timestepMs) Line 3072	C++
 	[Inline Frame] TheDarkModx64.exe!idSessionLocal::RunGameTics() Line 3114	C++
 	TheDarkModx64.exe!idSessionLocal::FrontendThreadFunction() Line 3160	C++
 	[Inline Frame] TheDarkModx64.exe!idSessionLocal::StartFrontendThread::__l2::<lambda_6b7828b12cf509cf76fb3406570c8cd1>::operator()(void *) Line 3254	C++
 	TheDarkModx64.exe!<lambda_6b7828b12cf509cf76fb3406570c8cd1>::<lambda_invoker_cdecl>(void * x) Line 3256	C++

Call stack is above.

Basically, stim-response script calls idEntity::Event_Frob on target entity WaterUpBut.
It redirects to idPlayer::PerformFrob, where idEntity* highlightedEntity = m_FrobEntity.GetEntity(); is NULL.
But later this pointer is used in if ( (item != NULL) && item->UseOnFrob() && highlightedEntity->CanBeUsedBy(item, true)), because some inventory item with "use on frob" is selected by player.

I assume in this FM and in this state the corresponding stim-response is generated repeatedly for some reason. So as soon as player decides to select key or lockpick, the game crashes on next event.

The main question is: if it is possible to generate a "frob" from game script, is it valid to take gameplay settings into account?
It means that FMs using this frob event will behave differently depending on gameplay settings, which is often very bad and can break mission.

[stgatilov]

Here is the entity definition which generates response:

// entity 868
{
"classname" "atdm:mover_lever"
"name" "PlugLever"
"frobbox_size" "15"
"interruptable" "0"
"model" "PlugLever"
"move_time" "0.7"
"origin" "76.875 5432 233"
"rotate" "0 0 0"
"sr_class_1" "R"
"sr_effect_1_1" "effect_frob"
"sr_effect_1_1_arg1" "WaterUpBut"
"sr_state_1" "1"
"sr_type_1" "1000"
"target" "BathPlug"
"target2" "DrainOnlyWhenOpen"
"translate" "0 0 -29"
"trigger_on_close" "1"
"trigger_on_open" "1"
"trigger_when_opened" "0"

And here is one which generates the stim:

// entity 869
{
"classname" "atdm:mover_lever"
"name" "PouringWater"
"frobable" "0"
"model" "PouringWater"
"noShadows" "1"
"origin" "76.875 5456.13 337.937"
"rotate" "0 0 0"
"snd_move" "noSound"
"sr_class_1" "S"
"sr_radius_1" "32"
"sr_state_1" "1"
"sr_time_interval_1" "1000"
"sr_type_1" "1000"
"target" "WaterPouringSound"
"translate" "0 0 -110"

 

[stgatilov]

Created issue: 5542

[stgatilov]

@Zeen, I have published version "test_release209_5542" with this problem fixed (only in Windows build).

One can update to this version in tdm_installer, and check that it does not crash.
Set "tdm_force_savegame_load 1" in order to load existing savegame (saves are compatible with 2.09, but the game will complain).

I do not recommend leaving this version for playing though!
Just check that the issue is gone, then revert back to release209.

[Zeen]

Thank you very much for these!

The first solution disabling use-by-frobbing works, and it crashes back again when it is enabled.

test_release209-5542 and force loading the save solves the issue.

[stgatilov]

2 hours ago, Zeen said:

test_release209-5542 and force loading the save solves the issue.

Thank you for testing!

Better revert back to release209 and continue playing with this feature disabled.
We will release "hotfix" for 2.09 later.

[Zeen]

Thank you very much. I will revert back to release2.09

fyi, I finished the mission with test_release and encountered no issue at all.

[stgatilov]

I'd like to ask @Dragofer,s advice here, since he has apparently used this "effect_frob" too.

When "effect_frob" response is triggered, or when ".frob()" method is called from the script: is it normal that player may apply lockpick/key he currently has selected to the frob target? Would it be OK if I disable this "use-by-frobbing" behavior for the cases when frob originates from a script/stim-response?

 

[Dragofer]

@stgatilov
I don't think that effect/method is meant to use inventory items for the player, it would not be possible for lockpicks anyway because the player needs to hold down his key for those.

It's more meant to simulate that items are frobbed by the player, i.e. pressing a button as if the player had pressed it. My main use case is to make func_static items that, when frobbed, call a frob effect on an item in the blue room. This way I can give the player moveable inventory items like keys without risking that an explosion or other force has pushed the item to somewhere where it can't be found anymore.