Dragofer

Thanks! This was it, the typical old remnants of a dev build causing graphical errors. Turns out this GPU is surprisingly capable at TDM, rendering the whole Perilous Refuge harbour at 50+ fps @1440p, albeit without fancy settings like AO, soft shadows or shadowmaps. Edit: ran out of VRAM at these settings, unfortunately.

Did you have "irreversible" unchecked? Otherwise I guess it's a limitation of the objectives engine and could be worked around via other means, like an on-death script for each AI or a looping script that checks the kill statistic or every killed AI.

I've removed all .pk4's and ran tdm_installer.exe, but that only got rid of the GUI warnings: peril_550_2.txt

Edit: the problem was simply leftover glprogs from an old TDM version. I've recently "upgraded" my office desktop with a 2nd hand GPU so that it can supply video to 2 modern screens. However, it appears unable to compile GLSL shaders for TDM and is therefore unplayable. As an example, this is what I see on TDM 2.13 or latest 2.14 dev build in Perilous Refuge: And this is the condump: peril_550.txt The GPU in question is an RX 550 with 2 Gigabytes of VRAM. It came out in April 2017, so I suppose it should still be able to open TDM. I've installed the latest drivers according to AMD Adrenalin, and never had a GPU or GPU drivers installed in this machine before. The screenshot is identical to what I'm seeing, so to me this suggests the GPU is at fault and not the cables or monitors. Specs of this PC: Make: HP OEM small form factor desktop PC OS: Win11 (upgraded from Win10) CPU: Intel i5-9400 RAM: single stick of 8 GB DDR4-2660 CL19 GPU: XFX RX 550 2 Gb GDDR5 Motherboard: HP 8653 (proprietary) PSU: rated for 180W Monitors: P2711 TS QHD x2, via HDMI and DP from the GPU ports SSD: INTEL SSDPEKNW512G8H 512 Gb, NVME PCIe x4 Maybe this proprietary HP motherboard isn't designed to be compatible with dedicated GPUs... These days I have better things to run 3D apps on, but maybe solving this case would help improve TDM's compatibility.

You could use the spawnarg hideModelOnBreak 1 to hide the entity completely. You may still need to set the broken spawnarg, even if its the same as the model spawnarg. A suitable broken model if it were still visible could be something that just has the hinges and one board left, but probably not that easy to tweak models when youre still new to mapping.

At long last there is also an accompanying Wiki article here: https://wiki.thedarkmod.com/index.php?title=Turret, complementing the info that was found in spawnarg tooltips and entity and prefab descriptions.

I have a working setup of a destroyable 3D objects in the form of the camgoyle, security cameras and the turret. I've extended the flinderize system for these entity types, but the basic components that should work on any static entity type are: A health spawnarg, so that the entity knows when to break. By default it'll be vulnerable to sword attacks, broadheads, fire arrows and fast-moving moveables. A "broken" spawnarg, which defines the model to switch to when the entity is broken. The flinder spawnargs shown above. The damage detection on a func_static is simple. For example, a fire arrow's splash damage is always 30 as long as the entity was within the splash radius, and you can't disable certain damage types. I don't recall a general-purpose entity type that offers better control atm, but technically you could turn your door into a disabled security camera if you wanted to make use of all of the damage spawnargs described on this wiki page, but you'd need to assign a simple collision mesh to the door.

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.

This is a custom script based on shaderParms, whereas all old material definitions contain some code that's based on globalParms. The script has nothing to do with what you find in the material defs and still works the same way today.

No, to my knowledge the only thing special about it is that there are hidden objectives that get completed when you reach certain pages.

From a very, very layman's point of view, this seg fault looks like a Linux issue to me. The warning about not being able to add the book to the inventory is a false alarm and happens with every immobile readable.