joebarnin

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.

That is up to the mission designer. Locked doors can be opened if an NPC has a key; optionally, NPCs can be allowed to open doors even if they don't have a key. In this case, the modder has explicitly allowed the priest to open that door, even if they don't have the key. I assume that the mission designer wanted this behavior (maybe the priest has an extra key?). I can see why you'd want the other behavior - it was clever to relock the door.

Okay, try this: I get Objective Failed and then the mission ends. I think "Ongoing" and "Satisfied at start" are the keys.

Try unchecking the "Boolean NOT" box, but adding "Failure Logic: 1" (see my screengrab). That way the objective fails if the AI is killed, and since it is a Mandatory objective, the mission fails.

Something like this, I think:

A fun mission - great atmosphere and design. Good idea - sort of a "Ponte Vecchio" feeling for the bridge. Lots of entry points, good use of rope arrows (I love missions with rope arrows), nice physical relationship between rooms & levels. I don't have the patience to ghost, but it looks ghost-able. I just knocked out most everyone, which was fine. I did accidently kill one guard who was sitting, but that's a known bug with TDM. Nice work, and thanks! Like others, I ran into performance issues. Outside my FPS was low, and TDM froze once for about 10-15 seconds. Also, some minor things:

Stunning!

See this comment:

I created a simple test with 3 objects. A stackable arrowhead: "classname" "atdm:moveable_loot_ancient_arrowhead" "name" "atdm_moveable_loot_ancient_arrowhead_1" "origin" "64 104 -40" "rotation" "1 0 0 0 1 0 0 0 1" "inv_category" "Special" "inv_loot_type" "0" "inv_loot_value" "0" "inv_stackable" "1" A frobable bowl: "classname" "atdm:frobable_base" "name" "func_static_1" "origin" "112 104 -61.9901" "model" "models/darkmod/kitchen/bowl01.lwo" "rotation" "1 0 0 0 1 0 0 0 1" "target" "atdm_target_itemremove_1" And an itemremove target: "classname" "atdm:target_itemremove" "name" "atdm_target_itemremove_1" "origin" "120 104 -16" "ammo_count" "0" "ammo_type" "-" "drop_in_world" "0" "stackable_class" "Arrowhead" "stackable_count" "1" "unique_item" "-" When you frob the bowl, the arrowhead count in your inventory drops by 1. If you want to do additional processing when the bowl is frobbed, have it target a atdm:target_callscriptfunction, which can do whatever you like (including activating the atdm:target_itemremove).

I found this object in the TDM files (tdm_target.def) entityDef atdm:target_itemremove { // Added in #3784 "inherit" "atdm:target_base" "editor_color" "1 0.5 0" "editor_mins" "-5 -5 -5" "editor_maxs" "5 5 5" "noclipmodel" "1" "wait_for_trigger" "1" "spawnclass" "CTarget_ItemRemove" // DR documentation "editor_usage" "Removes items from the player's inventory. Each target_itemremove can remove up to 1 unique entity, one stack of stackables, and one type of ammo. Melee weapons cannot be removed." "editor_var unique_item" "The name of a unique entity to remove. Must match the entity's 'name' spawnarg." "editor_var stackable_class" "Specify a type of stackable. Must match the entity's 'inv_name' spawnarg." "editor_int stackable_count" "The number of stackables to remove. 0 means all." "editor_var ammo_type" "The weapon whose ammo is to be removed. Standard ammo names are: broadhead, firearrow, gasarrow, mossarrow, noisemaker, ropearrow, vinearrow, waterarrow" "editor_int ammo_count" "The amount of ammo to remove. 0 means all." "editor_bool drop_in_world" "If set, the item will be dropped at the player's feet instead of being removed from the world." // DR default keys "editor_setKeyValue unique_item" "-" "editor_setKeyValue stackable_class" "-" "editor_setKeyValue stackable_count" "0" "editor_setKeyValue ammo_type" "-" "editor_setKeyValue ammo_count" "0" "editor_setKeyValue drop_in_world" "0" // Defaults for subclasses "stackable_count" "0" "ammo_count" "0" "drop_in_world" "0" } Note this: "editor_int stackable_count" "The number of stackables to remove. 0 means all." The default is 0, which is the behavior you are seeing. I'm not sure how to use this, but maybe you can somehow, and set stackable_count to 1?

Thanks. I was hoping to create the trigger in an arbitrary location. I guess I could create a brush trigger in a "blue room" (in DR), then have some script code that moves it to the arbitrary location (using setOrigin). Anyway, I found a different workaround for this, so it's not an issue anymore.

I want to dynamically create a trigger_hurt via a script. The following creates one, but it has no size: sys.setSpawnArg("origin", <some point>); entity trigger = sys.spawn("trigger_hurt"); How can I specify a size and shape (e.g., a rectangle) for this entity?

I've been using DR for years. I just reinstalled on a new computer and I'm seeing behavior that isn't familiar. When I deselect objects with the Escape key, the Camera view doesn't update (the objects still show as selected). The objects are deselected in the Orth views, but not the Camera view. If I click in the camera view or move the camera at all, the view is updated correctly. Same thing happens if I Hide an object (H key) - the hide happens, but the camera view isn't updated until I do something (Shift-LMB in the window, move the camera, etc). I know on my old system that the Escape or Hide actions would immediately show up in the Camera view. Is there a setting that effects this behavior? Edit: Never mind, now it's working. I don't know what the problem was, but now it's working as expected.

I dunno. Ignorance? Laziness? I'll go with laziness . I really don't remember why.

Which specific Dark Radiant features are involved with that screengrab?