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.