joebarnin

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.

Well, this one doesn't have

Thanks to all volunteers! The Beta thread is up here: Please use that thread to report any issues you find. Thanks!

I'm looking for some beta testers for my new mission, A Night in Altham: This is a large mission - not gigantic like Iris or The Painter's Wife, but bigger than anything I've done before. Content warning: In the next day or so I'll put up a thread in the beta testing forum, with a link to the pk4. Thanks!

Building on what @HMart said, here's a technique that extends the existing 'text' entity. In the "def" folder of your mission, create a <whatever>.def text file. E.g., mytext.def. It should contain this: entityDef mytext { "inherit" "text" "editor_setKeyValue force" "0" "editor_setKeyValue playerOriented" "0" "editor_setKeyValue text" "Default text" } (you can name it something else besides "mytext"). Since it inherits from the default text entity, it will behave correctly. In DM, create a "mytext" entity - it will have those three properties initialized to the values specified in the .def file.

Nice mission! Lighting, sound, effects all fit perfectly. As other have said, spooky without the typical jump scares. I especially liked the I really struggled with Great stuff, thanks!

Congrats on the release, and thanks! Also, made me laugh . I have to look! (after I finish it, of course)

Oh, one thing I forgot to mention (don't know if anyone else has discovered this). From here, I was able to use a rope arrow to climb up here: From there I could walk all the way around to the right and then back along the roof edge, and get a view that I wasn't supposed to: For my own missions, I personally don't care if someone can "break the fourth wall" (unless it's too easy). But in case it matters to you...

I think that is what's supposed to happen.

I have no idea if that's possible.