[Fan Mission: By Any Other Name by joebarnin (2022/3/10)]

Has any progress been made on tracking down that collision issue? I have this on my list of FM's to go back to, but I'd rather not replay half of it just to find myself stuck again and need to try again later. As there's been no news I take it the problem would still be there in latest TDM dev which is what I use.

[DarkRadiant experiences huge slowdowns on complex maps when moving the camera or toggling filters]

DarkRadiant is presently suffering from huge slowdowns when editing complex maps. They appear to increase the more models and entities are added to a map: With the building modules used in a lot of places, one of my maps is at the point where DR freezes for over one second whenever I merely toggle a filter which is very annoying for every repeated action. The lag occurs both when moving the 2D or 3D camera or viewport around, as well as enabling or disabling filters or using Control + F to go in and out of editing a group.

From what I can tell as an end user, this seems to occur because DR drops models that are no longer being rendered from memory, so whenever a change in the camera or viewport is made everything that pops into view or is recalculated floods back in. While this may be nice to save on RAM, my suggestion would be a change or at least an option to disable this behavior and keep everything precached: Like TDM itself, DR should maintain every model and texture used by the map in memory, only removing it once every last instance has been changed or deleted from the map being edited.

[Snatcher's Workshop - Mods for The Dark Mod]

I blame tdm_custom_scripts.script... which may not be at fault for all such cases, but I blame it none the less as I hate it being a requirement I'd prefer all scripts being auto-loaded like defs and everything else, in alphabetical order so the pk4 with the last name overrides older versions with ones in the FM directory having higher priority: This would finally make it possible to include mods with custom scripts as a simple drag-and-drop pk4, no need to have FM's integrate it or a separate mod installer.

Speaking of which: Why not have a mod section in the vanilla installer itself managing those mods? I haven't used the mod workshop yet but understand it relies on its own tool, which is likely not hard to use but we already have an installer which could include these just as easily so more people can find and enjoy them.

[Slam doors open while running]

49 minutes ago, snatcher said:

Mappers, I understand, can configure certain AI to detect if a door has been picked, unlocked or opened (not sure about this last one).

That's for doors that should always be closed: AI can indeed go and investigate if they find such a door open. That's different from what I'm thinking here: The fact that even a normal door should draw attention if it mysteriously opens by itself, which would make things too hard for normal opening but for a new slam mode it would be a great opportunity to add this.

[Slam doors open while running]

I quite like this idea and am in favor of seeing it in vanilla! Especially as the implementation is an easy and intuitive one that doesn't conflict: Hold the sprint key while opening or closing doors in order to slam them. I often feel I'm waiting too long for doors to open so I can get through, this would make runs more fluid granted it retroactively works on existing standard doors in all FM's.

But there should be one caveat: Slamming a door should cause a slight alert and draw the AI's attention. I think long ago I complained about the lack of realism in AI never wondering why a door is mysteriously moving right in front of them, even if they don't see the player directly: This would be a good excuse to keep normal opening as is but have fast opening make a louder sound that draws just a bit of attention from enemies.

[So, what are you working on right now?]

Always love when I get around to designing a cozy looking tavern. What would I do without the AI table prefabs, much as food and cutlery starts flying around everywhere whenever they get alerted no matter how you try fixing them

[Mod: Wearable disguises]

16 hours ago, snatcher said:

How about limiting player's actions with setImmobilization() or similar tricks while wearing a helmet? That way you organically let users know they must stay put while wearing a disguise.

Also, you should perhaps think in ranks. You can go your merry way wearing a City Watch helmet unless you stumble across an elite guard...

That's already implemented just not enabled on the default helmets: I may set some movement speed immobilization on them in the next version. Great suggestion to use rank to make the disguise drop even faster, will definitely be doing that... experienced members of the team would indeed see through your disguise even faster.

[Newbie DarkRadiant Questions]

17 hours ago, thebigh said:

Triggering a rotating prop with a target spawnarg makes it stop/start rotating. So you have a couple of options.

 

If the AI doesn't patrol, you can just target him to the prop directly and he'll trigger it when he's killed. This is a holdover from the old DOOM3 days. However, don't use this if he patrols because he'll also trigger the propeller every time he reaches a path_corner.

You can also use a hidden kill objective to target the propeller. This is likely only useful if you've only got very few propeller guys in your mission because you'll need a separate objective for each AI.

 

I think you can use the "unbindondeath" spawnarg to make the propeller fall off.

Thanks. Those methods might not work well unfortunately: Using an objective is overkill as they're meant to be standard characters you dynamically drop to the map and should just work... triggering would have worked but apart from the AI being made to patrol, I don't think it's possible for a def to reference another def as a target since those need to be linked on the map and there's no name for the AI to refer to the attachment by for a trigger.

What do attached lights that turn off when the wearer dies use? Actually I think the Automaton has that so I can probably look at its example for the lamp component. It probably wouldn't work for my rotator though, stopping rotation is different from turning off a light... unless the light is also targeted or uses the SR system so I can reach the "use" stimuli via spawnargs after all?

Another option would be having my fan as a texture, it's thin enough anyway: I define a version of the material that rotates and one that doesn't then switch the skin. But then the question becomes how does the AI change the skin of an attached entity on death? And a flat surface is uglier anyway I want to be up to date with quality standards so I'll have to think about this.

[New shadow leaks in 2.12 dev builds]

Though this is a more general question and less related to light leaking bugs per say, I'd still like to ask to be sure: Does using shadowcaulk instead of caulk teach lights to better detect rooms and ignore entities behind such brushes, thus texturing walls with it improves performance? At first I thought that's the case but likely not since I think the recent light optimizations use visportals to check rooms outside of the light's field of vision.

[Mod: Wearable disguises]

Thanks to Stgatilov for fixing the head model change crash! Though the fix will be featured after next dev snapshot, I'll likely update this mod again once that's out. While few maps have mirrors, remember some may be designed with this mod in mind as the goal is to have it working as both a FM and universal mod.

9 hours ago, snatcher said:

The Modpack and the Unofficial Patch are supposed to work out of the box: plug and play. Casual and even advanced players wouldn't know what to do with the Wearable disguises or the Augmentation mod the way things are today.

This is a neat mod @MirceaKitsune, congratulations. I am rooting to see it implemented in a map!

The mod however is overpowered, and it feels like having notarget on. There must be limitations and/or penalties. I suggest:

1) While wearing a helmet players must act like a guard: (creep or) walk in stand up position. The moment you jump or crouch, run, raise a weapon, grab an item... your are fully exposed.

2) Each helmet is functional for limited time. The longer you use it the more suspicious you become and at some point the helmet is of no use. Perhaps helmets can be "recharged" somehow, I don't know, but you get the idea.

PS: Considering the number of mirrors per map and the fact that there are no player reflections (glass, water...) I wouldn't worry much about the head, to be honest.

Thanks: I'm glad you like it even if it may not be featured in the mod pack, though I'll likely attempt some of your suggestions at least. I tried to make it intuitive, hence I didn't add special circumstances (like running) for wearing out the disguise even faster so players aren't left wondering what triggers it, however it may be featured next time: I don't remember if there's a way to check if the player is sprinting or crouched, so I'll likely use the player speed thus the faster you're moving the more quickly you're spotted... I might even make it so being seen picking locks or stealing loot instantly makes your disguise fail!

Making a helmet no longer usable after being caught once is tricky: Helmets all look the same, therefore guards wouldn't notice if you stole another hat and used that to trick them again... they don't use energy either so needing a special way to recharge them wouldn't make much sense. Remember also that being seen by an alert guard makes the disguise drop faster, and part of the alert level is permanent meaning guards will always catch you a bit more quickly if they were alerted once.

The logical solution would be that once you're caught, you can't ever disguise yourself to trick that team again... this would make them too useless and irreversible so no. A good middle ground instead is having a long cooldown timer, so once caught you can't disguise yourself for say 5 minutes. What does everyone think about that?

[So, what are you working on right now?]

Obviously they aren't all going to be in the same place... you're only meant to see one at a time after all, not giving away too much mechanics wise. But I found an interesting design to go with for a main character, and with all shiny crystals lined up in order I'm amazed how beautiful this looks even if it's just a circumstance of testing! Needless to say it wrecks my FPS to look at, no surprise for 6 volumetric lights attached and thus recalculated each frame.

[Newbie DarkRadiant Questions]

There's a little something I want to try for which I'll need another obscure trick, might share another mod if I can get it right: How do I attach a func_rotating propeller to an AI, but make it so that it stops rotating once the AI is dead? It must also loop a sound which stops once the AI is disabled. Ideally the rotator can fall off and become a moveable, I don't care if it stays attached as long as it stops spinning when the AI dies or goes unconscious... while attached it should have no collisions.

I'd like to avoid a custom script for this one since I hate having to hijack tdm_custom_scripts.script every time: I know there are parameters for AI attachments and loot items to change state when taking down their wearer... like the mask of the manbeast which falls and can be looted once you defeat the owner, there was also a FM with a flaming skull that gets extinguished when the skeleton is killed. But I have no idea if there's any parameters to make an attachment rotate only while the AI is alive.

[New shadow leaks in 2.12 dev builds]

28 minutes ago, stgatilov said:

The modules are comprised of models, they are completely ignored by the area-portal graph. And now they don't cast shadows if it is proved that light beams travelling though visportals don't touch them.

If you use caulk to create areas, then there is nothing that would cast shadows: brushes don't cast shadows because they don't exist (caulk), and modules don't cast shadows because according to area-portal graph they are not hit by light to begin with.

There is internal material called "shadowcaulk".
As far as I understand, it is not drawn as ordinary surfaces, but it does cast shadows. I think in order to work properly with new optimization, shadowcaulk should be preferred to caulk for the brushes.

Aha, thank you for this clarification! I see what's happening now: I was expecting that the building modules still cast shadows by default, which I was in fact hoping got disabled since their performance impact can be felt... in addition I thought texturing the walls with normal caulk would still work as they create closed rooms, but indeed caulk isn't a shadow caster so I shall replace them with shadowcaulk as suggested.

There's another bug in latest dev I was waiting to report: I noticed I can place electrical lights in DarkRadiant where they show up just fine, but when opening the map in TDM they do not spawn any longer. The console provides a warning which suggests an invalid newline causing the engine not to load the def though DR doesn't mind it. I don't override the file in my FM nor had any errors while running the installer and updating so I'm presuming something got broken.

WARNING:file def/tdm_lights_static_electric.def, line 612: newline inside string

[New shadow leaks in 2.12 dev builds]

25 minutes ago, AluminumHaste said:

Make sure the gas lamp light is not set to no shadows. Same with the wall texture, make sure you didn't accidentally use _ns version of a texture

It's not that no: I didn't modify the properties of the default entity or its flame, in this case it's the standard atdm:lamp_oil_wall_lit entity... also I have player shadows enabled, the player as well as other architecture elements cast shadows fine. Walls are the building modules, eg: model models/darkmod/architecture/modules/interior_set01_corner.lwo with skin diamond_wallpaper as a test.

This is the closest to the setup I still have: The origin of the light is well beyond the face of the module surface for shadow casting. Though this shouldn't even matter since the light is in the other room and the caulk brush should itself mark this.

I think I noticed this on other maps too while playing, but only now saw it obviously enough to realize there's likely an issue somewhere. I remember seeing the glow of a light from another room shining on the floor / ceiling when it shouldn't, though I didn't document it at the time.

[New shadow leaks in 2.12 dev builds]

I'm on dev16829-10455: With a new map I'm working on I keep noticing lights leaking through walls. The walls are thin caulk brushes (8 units thick) as I'm using the building modules. Sometimes a lamp on the other side will shine straight through the wall over the floor or ceiling. In one case I noticed this happen even if the room where that lamp is located was behind a closed door / portal, meaning the engine should know the light doesn't reach you and should be disabled entirely yet it still worked.

I've reworked my map since so I no longer have it. But in this screenshot I took, the brightness you see on the ceiling in the middle is from a gas lamp mounted on the wall on the other side. In this case closing the door to the right while standing in the same spot makes the glow go away once the door is shut, but like I said there was another case where the light shined through a caulk room even when its door was closed and I was standing outside.

[So, what are you working on right now?]

The magic temple / monastery of a new FM concept I'm working on. The flames will be part of the gameplay and represent progress in some form, will address the details as I go.

[Newbie DarkRadiant Questions]

There's another trick I wanted to try but haven't seen done before and it may not be possible but still: Can you make it so when you die, the FM doesn't end but a script function executes or an entity is triggered, ideally only if the player is in a given area? Thus once you reach 0 health, you fall hearing the player grunt sound and the screen goes dark as usual, but instead of the "mission failed" screen you find yourself teleported in a particular room with your health fully restored. The script reference page mentions two functions called customDeath and deathMenu for idPlayer, however they aren't documented... does anyone know if that's what I need and how to use them?

[Global Player Tip System ( split from Frob to Use proposal thread )]

Okay now I actually think we need a tip system, since in 10 years I never had any idea you can use lockpicks to disarm mines

[Global Player Tip System ( split from Frob to Use proposal thread )]

1 hour ago, snatcher said:

Are you equipped with the right kit ?

If there's a kit there must be that one FM which implements it: I played nearly every mission and can't remember picking up a "mine disarming kit" item. Makes me think the tip system should be implemented as a script: Apart from keeping the C++ code clean and relevant to the deep stuff, it would allow FM's to add their own custom tips specific to map functionality.

[Newbie DarkRadiant Questions]

12 hours ago, joebarnin said:

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?

Thanks. That would be the method for going with a campaign: I was wondering if it's possible outside of that as well, I take it that means not. I'll either go with the campaign approach, or if I can find a way to do a partial reset in the map.

[Global Player Tip System ( split from Frob to Use proposal thread )]

On 10/25/2023 at 9:22 PM, snatcher said:

• Player places a mine (or flashmine) for the first time: Mines can be disarmed with the right kit and a steady hand. Keep a safe distance!

I need an assistant myself because I completely forgot this could be done.

Wait is that actually true? I'm with TDM for almost a full decade now, always thought you can just disarm any mines but recently discovered that never works, seems I had it wrong both ways and could use such tips myself

[Idea: Demo support, watch recordings of playthroughs as a floating camera / player 1st person / 1st person view from AI]

2 hours ago, Daft Mugi said:

Yeah, it was originally part of the Doom 3 engine.

Indeed, but I imagined it was removed with the other stuff... now I hope it won't be, and if need be can be fixed to be compatible with TDM. The question is if it knows to work with our AI and entities, if we haven't done anything too radical to break it maybe we're lucky and it does! I should finish the FM I'm currently on, then I'll reload a previous one and give it a quick try to at least ensure nothing crashes or goes crazy.

[Newbie DarkRadiant Questions]

I'm still curious about part of my question from last time so I can weigh in all options: Is it possible for the scripting system to generate a text file in the FM directory, which can be used to store and retreive information about previous runs independently of saves? I could have a use for that if yes, though I'm not seeing any obvious way in the documentation.

[Idea: Demo support, watch recordings of playthroughs as a floating camera / player 1st person / 1st person view from AI]

1 minute ago, Daft Mugi said:

@MirceaKitsune Have you tried the following?

recordDemo <name>
stopRecording
playDemo <name>

It does work to a degree, but I don't know how extensive it is or if there are bugs. Plus, FPS drops considerably -- at least on my machine.

Oh my, it's already there? I will definitely take a look at it at some point! If it works there should definitely be a menu component so it's accessible to everyone, I didn't even hope it was already implemented to some extent

Will need to see how it handles saving and loading while a demo is being recorded. Also what camera modes are supported: The magic I had in mind would be the ability to fly around and see the player, as well as through AI's eyes to experience how they perceived the world and saw you during your run.

[Idea: Demo support, watch recordings of playthroughs as a floating camera / player 1st person / 1st person view from AI]

25 minutes ago, jaxa said:

I think there's randomness in parts of the game, like NPC reactions. It probably won't work.

Those would need to be recorded and made constant during playback of course. Physics aren't random though right... like if you pick up and throw a vase against a wall, it will always move and roll the same way based on initial velocity? If so I'd presume this could work by merely remembering and simulating identical player key-presses and mouse movements, while using constant values for randoms in AI decision making and other entity scripts to ensure they always do the same things.