stgatilov

Created issue: 5542

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"

> 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.

Quick workaround: Go to Settings \ Gameplay \ General. Set Use-by-frobbing to Disabled. 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.

From my very brief knowledge about the issue, I would say this problem happens because AI sitting was designed to be too smart. Smart things tend to inevitably break with some probability. I'm not sure it is fully fixable for existing FMs.

Ok, I'll try to get some more information, but that would need more complicated steps from you. 1) Run tdm_installer without any custom checks, and make sure it installs release209 properly. Do not use test/dev versions for this! 2) Delete "currentfm.txt" file in TDM installation directory (if it exists). 3) Download apitrace from this link. It is a 7z archive with a folder inside. Unpack the contents of the folder into "C:\apitrace". Make sure that path "C:\apitrace\bin\apitrace.exe" indeed points to the executable! 4) Download attached zip file. Unpack its contents into the root of your TDM installation directory. Make sure you see files like "_apitrace_record1.cmd" in the same directory where you see "TheDarkModx64.exe". 5) Action time Run "_apitrace_record1.cmd". It will start TDM game, and after a bit of time you will hear music. Now press Ctrl+Alt+Tilde (~) to open console. Type "condump 1" and hit Enter. Then exit game by pressing Alt+F4. Note that you'll have to do it blind, so verify that both "1.txt" and "res1.trace" have been created in TDM directory. 6) Repeat point 5, but now run "_apitrace_record2.cmd" and execute "condump 2". 7) Repeat point 5, but now run "_apitrace_record3.cmd" and execute "condump 3". 8|) Take files "1.txt", "2.txt", "3.txt", "res1.trace", "res2.trace", "res3.trace" in TDM installation directory, and pack them all into 7z/zip archive. Upload the archive somewhere and share it for download. P.S. And if you start seeing the menu instead of black screen in any of the runs, of course report it 209_blackmenu_apitrace.zip

@id3839315 or @Jedi_Wannabe, did you try setting seta r_useBindlessTextures "0" on release209 version? Note that you need 2.09 release, not some dev. build ! UPDATE: Or no, this can't work, since this extension is reported to be missing =(

I have packaged two new versions: test15973-8793 and test15973-8795. Would be great to see which work/fail.

When you have some version which does not work, did you try "r_useNewBackend 0" ? Basically, find seta r_useNewBackend "1" in darkmod.cfg, replace it with seta r_useNewBackend "0", then try to run TDM.

Try to Right+Click and Open in New Tab. Or copy the link and paste it into browser. Perhaps that's because of https://www.ghacks.net/2020/10/08/chrome-is-blocking-downloads-here-is-why/ Which is rather stupid, because this is a static file, and there is absolutely no reason to serve it over https. No additional security is gained this way. @taaaki / @Springheel: Could you please replace http:// with https:// in all URLs on the Downloads page?

Could you please test the next version: "test15973-8787" ?

By the way, you can in principle play version 2.08 for now: most of FMs should work fine in it. Perhaps having two installations would be more convenient in this case (just be sure to not confuse one for another). I'm afraid the best idea I have is to send you bisecting over development versions (just like in the other thread nearby). When you check "Get Custom Version" in tdm_installer, you will see a lot of versions, and you can install any of them. I'm interested in the versions under folder dev/2.09 (like dev16010-8948): they are listed in order of increasing age. Normally, they should work fine up to some point, and then fail after that point. Could you please find the first one which fails for you?

The new version to test is: "test15973-8797" Now it is not the last in the list Also note that it has the same first number, but different second number. UPDATE: Note that this build has broken stencil shadows. Shadow maps should work well. Given that you don't see main menu in bad builds, it should not be a problem for you.

This is almost 2.08, so it is not suitable for playing. I'll create new version now.

Ok, then please try version "test15973-8778" --- it's in the very end of the list.

You can download 32-bit executable of 2.09 from the Downloads page on website. Oh crap, for some reason it is not there! We'll add the link to archive. Meanwhile, you can download 32-bit executables here: http://update.thedarkmod.com/zipsync/_aux/209/tdm_exe32.zip Could you please confirm that "TheDarkModx64.exe" does not work for you in 2.09, but "TheDarkMod.exe" from the archive does work for you in 2.09? Also, could you please go to properties of "TheDarkModx64.exe" and post a screenshot showing the exact size of it (up to the last byte).

@Jedi_Wannabe, "dev15976-8815" is the very first dev build. Are you sure 'dev15976-8815' gives you black screen but release208 works properly? I hope you do not restore config file when switching versions?

I have asked some files from @Jedi_Wannabe, and I'm 90% sure his installation is perfectly the same as on our release server: He has Radeon HD 6950 card, which is old, but not too old to run TDM. It supports GL version 4.4, while only 3.3 is required in TDM. Also, the main menu does not use most of the advanced rendering features. I asked to bisect over TDM versions, to see which dev. build started failing: And the result is:

Decided to start dedicated thread about this problem. Right now at least @Jedi_Wannabe and @id3839315 have it. Let's continue the discussion here.

@johlkien, are you sure the dump was taken after TDM hanged up, and not before that? In the crashdump, all threads are waiting. Basically, this is a deadlock. Frontend thread is waiting for "signalFrontendThread", which is I guess when backend would finish. Main/backend thread is waiting for GL fence lock: ntdll.dll!00007ffea48bce14() Unknown KERNELBASE.dll!00007ffea2011e93() Unknown ig7icd64.dll!00007ffe5a9c5f8b() Unknown ig7icd64.dll!00007ffe5a5b65ad() Unknown > [Inline Frame] TheDarkModx64.exe!WaitForGeoBufferSet(int) Line 119 C++ TheDarkModx64.exe!idVertexCache::EndFrame() Line 333 C++ TheDarkModx64.exe!idRenderSystemLocal::EndFrame(int * frontEndMsec, int * backEndMsec) Line 689 C++ TheDarkModx64.exe!idSessionLocal::UpdateScreen(bool outOfSequence) Line 2760 C++ TheDarkModx64.exe!idCommonLocal::Frame() Line 2550 C++ TheDarkModx64.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 1321 C++ [Inline Frame] TheDarkModx64.exe!invoke_main() Line 102 C++ TheDarkModx64.exe!__scrt_common_main_seh() Line 288 C++ @johlkien, could you please try starting TheDarkMod two times: With "r_useFenceSync 0". With "com_smp 0". Since you cannot set cvar in console, you need to open "darkmod.cfg", find corresponding cvar there, and change its value.

Done all of that. Sorry to players for leaving many logfiles around. The logfiles older than 30 days should get deleted automatically... but the amount of garbage will increase. As for preliminary check for locked files. This works perfectly under Windows, all pk4/zip files and manifest.iniz are checked. I have tested: if TDM or DR is open, then the check complains about it. I had to use some Windows-specific function to implement it, because normally you can write to pk4 files while TDM holds read access to them (but cannot delete them). However, it does not work under Linux. In fact, when TDM is running, everyone can overwrite and delete pk4 files. Only the actual executable cannot be modified. I'm afraid there is no special flag or state on pk4 files which would tell me that someone uses them: since TDM does not explicitly lock them using Linux-specific API, it basically says "everyone is free to modify them as they like".

Since reinstalling does not help, it is most likely not the problem of installation. Could you please run TDM, wait until it freezes, then record memory dump in process explorer? Archive and share the memory dump. Hopefully, we will be able to see where it froze.

My Windows 10 does not like any executable downloaded from internet. That's because you were looking at the wrong place. The initial location of zipsync packages (http://darkmod.taaaki.za.net/zipsync) is abandoned now. I have already deleted zipsync.exe from there, and just now I have deleted the core packages from there. Only tdm_installer executables and your packages are left. Now the official TDM packages are at http://darkmod.taaaki.za.net/release/zipsync. But you cannot put your own files there, because it is synchronized to TDM server (which is another location you don't have write access to). If you like to put your own patches on TDM servers, I guess the old location can be used for it (just as you did). I did not think people will really use zipsync packages, and I must admit that you have lowered the difficulty bar of it in my head You can of course do any unofficial packages you like. Just keep in mind that I'll anyway do dev builds from trunk on regular basis. Just need some time for 2.09 release to settle...

Very strange indeed For most people, the performance improvements are noticeable, but pretty small. Maybe your case is different because you have APU, or because CPU/GPU performance ratio is different. As for loading times, I think it has worsened in 2.09, especially on AMD GPUs! Because now all normal textures are compressed into RGTC format during loading (to be fixed in 2.10), and texture loading takes most of the time.

I assume that if you save the game, then restart TDM and load it, the quad is gone, right?