joebarnin

The keyhole lean/peek problem - some Linux players report all you see is black when peeking.

I've got a Windows 11 machine. TDM players on Linux are running into problems with my mission; it appears these are Linux-specific issues. I'd like to have a Linux install of TDM, to verify these issues (and maybe be able to submit bug reports). What's the best technique for getting a Linux install on my Windows computer? My ignorance of Linux knows no bounds . How do these options look? https://www.windowscentral.com/software-apps/windows-11/how-to-run-any-linux-distro-alongside-windows-11 Thanks!

@snatcherThanks for the review! I'll consider some of your suggestions for version 2. Although, I might be pushing my luck if I make the mission even longer! As for,

Crap. That’s a bug alright. There is another way out. Or, noclip through the obstruction. Sorry about that.

My new mission, A Night in Altham, is available. We are already up to version 2! @Dave the Tafferfound an problem that deserves a fix, so here is version 2: https://www.dropbox.com/scl/fi/y4r1dmziuq6clh2im3qz1/altham2.pk4?rlkey=m3cv5v6v70lxbc9xha61nuxoj&dl=1. I will ask @nbohr1more to update the databases. A special thanks to JackFarmer for several pieces of custom ambient music. They "complete" the mission, providing a unique feel to its locations. Also thanks to the many beta testers (jaxa, Shadow, wesp5, Cambridge Spy, thebigh, datiswous, Mezla, MirceaKitsune, Melchior, Acolytesix, TheUnbeholden, prjames, Bergante). Thanks to @peter_spy for his beautiful Builder Compound assets. This is a large mission, so be ready to take some time. I recommend that you do named saves occasionally (I actually implemented auto-saves for this mission, but it was causing crashes on Linux, so I removed it). This mission has a lot of keys, so it implements a key management mechanism. Keys are removed from the game when no longer needed. This includes when you use a key to open a door, or if you pick a door/lock that also uses a key. Most keys are automatically removed, but there are a couple that aren't (for example, if they open up more than one door). In a certain area, this mission uses the Keyhole Peek feature of TDM. Typically, this is when you lean forward (F key) into a door keyhole and you can see into the next room. But in this case you don't lean into a keyhole. It's a hole of another kind. It's an unconventional use of something that isn't used a lot in TDM; hopefully the mission context will make it clear when to use it. The mission does not use Keyhole Peek for regular doors. Be aware, there is a known problem on Linux, where the peek feature can cause a crash. Peeking is not required for mission completion. This has been tested on TDM 2.11a and the current dev build of 2.12 (dev16854-10518). Scary things warning: Difficulty settings make a difference. Things that are affected by the difficulty level: Enjoy!

Models are inserted as func_statics, so basically the same thing?

Yes indeed, a func_static. I maxed out the logging with these settings in darkmod.ini: [Debug] LogFile=Darkmod.log LogError=1 LogBegin=1 LogEnd=1 LogDebug=1 LogWarning=1 LogInfo=1 LogClass_INIT=1 LogClass_MISC=1 LogClass_SYSTEM=1 LogClass_FROBBING=1 LogClass_AI=1 LogClass_SOUND=1 LogClass_FUNCTION=1 LogClass_ENTITY=1 LogClass_INVENTORY=1 LogClass_LIGHT=1 LogClass_WEAPON=1 LogClass_MATH=1 LogClass_MOVEMENT=1 LogClass_STIM_RESPONSE=1 LogClass_OBJECTIVES=1 LogClass_DIFFICULTY=1 LogClass_FRAME=1 LogClass_LOCKPICK=1 LogClass_CONVERSATION=1 LogClass_MAINMENU=1 LogClass_AAS=1 LogClass_STATE=1 Way overkill, it creates a massive log file. But I searched for the name of the AI and found a log entry that mentioned something about "HandleDoorTask performing by <guard name>" and a lightbulb went off.

Something I just ran into, so I figured I'd share what I learned. I had an AI doing a path back and forth from A to B to A, etc. It would work fine for a while, and then suddenly he would stop and just stand there. At that point he would never proceed on the path. I cranked up the logging and saw something in darkmod.log about "handle door task" associated with that AI. I realized the problem. I had a dummy door nearby - it is a "door to nowhere" (solid wall behind it). But instead of using a door model, I had cloned a nearby atdm:mover_door and set it to frobable=0 (and removed the handles). That certainly keeps the player from using the door, but apparently it confuses the AI pathfinding. I replaced it with a model door, and now the AI path works fine. Bottom line: always use a model for dummy doors. Sounds obvious, I know.

I suspect you are correct.

Forgot to mention, I’m running the same .pk4 as well. Something must be different, I just can’t figure out what. I’ve asked about addons, etc.

Should I be able to load a save file from another player? My mission is in beta test, and one of the testers has run into an issue. I had them store out a save file, but when I try to load it, TDM hangs (the loading screen just sits there with the bar at 0% progress). We're running the same version, 2.11/64 #10264. Is what I'm trying to do possible?

This bug is fixed in TDM 2.12. I just verified that the elementals work as they are supposed to, using TDM version dev16842-10488. So have fun!

Also, the training mission has an example of this.

Set up a hidden objective, fourth object in location X. When it succeeds, call $player1.holdEntity($null_entity). I haven't tried this, but that's my guess.

If you haven't already, take a look at https://wiki.thedarkmod.com/index.php?title=Setting_up_Campaigns#Scripting Calls like sys.setPersistantArg and sys.getPersistant* might do what you want?

No worries, I’ve got a workaround in my current FM so testing it on 2.12 can continue.

Great news, thanks! Do you know when this be available in a dev build?

I see that too (in 2.12, not in 2.11). I've seen issues like this before, occasionally. I usually just fiddle with the brushes until the problem goes away.

So I adjusted each portal slightly in the x direction. The portals were 8 x 112 x 128 (x,y,z), and I moved the x-plane of each portal by a different amount (1 unit, 2 units, 3 units, etc), so that none of them are in the same plane. And now it no longer crashes! So I have a workaround, at least. Thanks for identifying the root of the problem! Let me know if there's anything else I can do; for now, I'm going to proceed with my workaround.

Thanks for the explanation. The building where this happens is an "open plan" warehouse, 4 stories, with a wall at one end but 2 doorways in the wall on each side, so 8 total: Each doorway is a visportal. They are lined up on the X-plane. First question, are all of these portals unnecessary? They do reduce the tris somewhat, but maybe not worth it? Second question, I recall occasional problems when visportals are lined up exactly. Maybe I'll move each of them a slightly different amount in the x direction, see if that helps. I'll experiment and let you know what I find.

My new FM is in beta test, and some testers are using 2.12. They have discovered a hang/crash that only happens in 2.12 (crash doesn't happen in 2.11). I am able to recreate it in 2.12 now. I run TDM in the Visual Studio debugger (using dev16829-10455). After starting the mission, I just wait a minute or so and the screen freezes. Then, I wait another couple of minutes, and the debugger reports a failed assertion. The assertion is: WARNING:ASSERTION FAILED! E:\games\darkmod_source212\idlib\containers\List.h(394): 'newsize >= 0' The callstack is: TheDarkModx64_debug.exe!AssertFailed(const char * file, int line, const char * expression) Line 75 C++ > TheDarkModx64_debug.exe!idList<idPlane>::Resize(int newsize) Line 394 C++ TheDarkModx64_debug.exe!idList<idPlane>::AddGrow(idPlane obj) Line 765 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 351 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FloodLightThroughArea_r(idRenderWorldLocal::FlowLightThroughPortalsContext & context, int areaNum, const portalStack_s * ps) Line 385 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::FlowLightThroughPortals(idRenderLightLocal * light, idFlexList<int,128> * areaIds, lightPortalFlow_t * portalFlow) Line 495 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::AddLightToAreas(idRenderLightLocal * def) Line 2038 C++ TheDarkModx64_debug.exe!R_CreateLightRefs(idRenderLightLocal * light) Line 738 C++ TheDarkModx64_debug.exe!idRenderWorldLocal::UpdateLightDef(int lightHandle, const renderLight_s * rlight) Line 423 C++ TheDarkModx64_debug.exe!idLight::PresentLightDefChange() Line 1076 C++ TheDarkModx64_debug.exe!idLight::Present() Line 1132 C++ TheDarkModx64_debug.exe!idEntity::Think() Line 2318 C++ TheDarkModx64_debug.exe!idLight::Think() Line 1274 C++ TheDarkModx64_debug.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds, int timestepMs, bool minorTic) Line 3366 C++ TheDarkModx64_debug.exe!idSessionLocal::RunGameTic(int timestepMs, bool minorTic) Line 3063 C++ TheDarkModx64_debug.exe!idSessionLocal::RunGameTics() Line 3109 C++ TheDarkModx64_debug.exe!idSessionLocal::FrontendThreadFunction() Line 3159 C++ TheDarkModx64_debug.exe!idSessionLocal::StartFrontendThread::__l2::<lambda>(void * x) Line 3235 C++ TheDarkModx64_debug.exe!unsigned int <lambda>(void *)::<lambda_invoker_cdecl>(void * x) Line 3236 C++ [External Code] The code in question: ID_INLINE int idList<type>::AddGrow( type obj ) { if ( num == size ) { int newsize; if ( granularity == 0 ) { // this is a hack to fix our memset classes granularity = 16; } newsize = (size * 3) >> 1; // + 50% size newsize += granularity; // round up to granularity newsize -= newsize % granularity; // Resize( newsize ); } list[ num ] = obj; num++; return num - 1; } size = 968651120, so newsize is calculated as -694506944, which causes the assertion. Obviously something is running away and the code ends up trying to resize the list to a size that is so big that it wraps around to negative. Is my mod doing something wrong that is leads to this? How do I track this down? I can supply the FM package if that will help. Or, I can set some breakpoints if there's something I can look at here. Thanks. Edit: Here's the FM: https://www.dropbox.com/scl/fi/3fg2x3w4owmku1l4gifi7/altham_crash.pk4?rlkey=z0q1gaflz5b7mifeuayoqmlug&dl=1 To reproduce the problem, start the mission (Easy difficulty), then just stand there. The guard will walk close to you but he shouldn't see you (you can always set the "notarget" console command to ensure he doesn't see you). After a few minutes, the game freezes. A few minutes after that, it crashes. Sometimes it happens in just a minute or two; other times it takes several minutes. But so far, it always happens eventually.