Dragofer

You can try to make monsterclip that doesn't touch the floor. This might allow walking AIs to still use that space, but elementals would be blocked. Another idea is to vertically restrict the elemental to the upper part of the room using a large flat monsterclip brush. The problem is that once an AI is alerted it can no longer be directed via script.

Personally the stealth counter feels like a diagnostic tool to me, which is at odds with TDM's design direction of a minimal GUI and moves focus away from audio and visual cues coming from AIs, towards a number in the corner of the screen. So I wouldn't have it enabled by default. Adding it as an option in the settings would be possible, on the other hand. My approach would be to let the setting add or remove a stealth counter item to the inventory which shows stealth scores in real time, without altering the existing loot counter item and without adding a gimicky-feeling scroll + GUI popup.

Is the crash to desktop when you attempt to launch TDM, when you load the map or when you drink a potion?

Yep, a side-effect of the current implementation is that your horizontal jump distance is significantly longer, even if your vertical jump height is still the same. It kind of makes sense to me that you would be able to cover more distance if you hang in the air for much longer, and I don't think it would feel good for gravity to abruptly change depending on your vertical velocity. But it would be be possible to scale your horizontal acceleration with your vertical velocity, if this is more widely desired. Maybe gravity, too, should scale with velocity in some way.

That was what my latest commit shortly before the test went live was about actually. Core TDM already supports moving towards any direction while falling, but it's very slow so the slowfall potion amplifies your horizontal acceleration by about 5x. That said, something in spoilers for people who have already tried changing direction mid-air:

I dont think DoomScript allows you to use any other kinds of floats, and variables always have to be case matched since DoomScript, too, is case sensitive.

Seems the issue is that inv_count (like the original, defunct inv_item_count) has a default value of 0 in the base playertools class, which items like health potions dont change in their own def. Line 593 in Inventory.cpp assigns a default value of 1 if the "inv_count" spawnarg is missing (which was always the case so far unless the mapper specified a value for certain entities). So to preserve the old behaviour we should set the default value of inv_count to 1 for playertools. I realised that the base entity definition for all playertools was referencing a spawnarg "inv_item_count" which is not used anywhere in the code or in any core scripts. It appears to be a typo of "inv_count", which is used in the code. This meant that when mappers attempted to change the amount of an item using "inv_item_count" presented to them by the editor, it would have no effect. They probably wouldn't realise that they should be using the "inv_count" spawnarg instead. I overlooked that the default value of inv_item_count and now inv_count was 0, so stackable items currently don't work as intended. I've fixed the bug, and also attach the fixed file here for use until the next dev build is out. Create a "def" folder in your darkmod installation and put the file in there. It will take effect after restarting the mission. tdm_playertools.def For people without a forum account, here's a Google Drive link. Remember to delete this folder and file after the next dev build, to avoid getting locked out of future changes to this file.

I observed the majority of issues with objects near diagonal walls, even when they were perfectly grid-aligned with the walls, or even some units apart from the wall. The engine seems to be very conservative by treating the entire bounding box of such diagonal walls as the boundary, rather than the actual wall itself. So objects quickly start to leak to the other side's visleaf when they begin to approach such walls. You can see a very stark instance of this issue in the ship in Perilous Refuge, where almost the entire ship's contents leak to the exterior visleaf due to the many curved sealing walls. areaLock is crucial there.

Just uploaded version 4 of this FM: Primarily this is a bug fix update, using TDM's many new diagnostic tools to fix issues like non-functioning visportals, dead-end GUI elements and sounds not playing due to a wrong sampling rate. The console now posts no warnings about FM-specific assets. Added subtitles provided by datiswous. Adjusted the river forest skybox to look more like it did when I originally released the FM, counteracting subtle, but significant changes to how transparent (leafy) surfaces are rendered in fog. Added a black fog to make the ravine scene look more bottomless. Also, wisps no longer leave behind black boxes at their starting positions. The AI in the bunk cabin of the starting ship should no longer be able to see the player through the corner of the bunks model (all nonsolid items should have visual-clip now). Cleaned up obsolete clutter from old-era material shaders. As a side effect, Linux users should now be able to start up the FM. Switched moonlights in certain outdoor scenes to the new parallelSky system. Got completely rid of the rotation hack for scaling models. Recompiled the maps using the newest version of TDM's compiler, benefitting from a lot of things that stgatilov changed over the years.

Yes, the first angle is to set which direction the AI faces while playing the sit down animation, then the second angle is needed to make the AI spin in place so it faces forwards while seated. No idea whether @Amadeustinkered with something in this direction while reworking the drunk spawnarg?

Seeking Lady Leicester features Precursor tablets which translate their world GUI text whenever the player frob highlights them. This would be a suitable starting point for figuring out how to hide or fade out your readable's GUI text. I guess it happens because some part of the AI's ragdoll is clipping into the bed's collision mesh at the time of the ragdoll event, so it falls through the bed just like when you activate a moveable that's clipping into a table. You could try making the bed nonsolid and putting in some nodrawsolid brushwork where the level of the bed surface is a unit or two lower to reduce the risk of this bug happening. If it happens a lot with specific beds they should have their collision mesh changed on the core side.

I don't think there's a contradiction: if an addon has the same .pk4/script/asset names as another addon they will interfere with each other's function if both are installed. However, addons can intentionally overwrite core .pk4 files as an intended feature.

Doors are a type of mover so they support accelTime and decelTime spawnargs (might have been with an underscore). That's all that's needed.