Dragofer

It has been in the "brainstorming possible titles" initial phase for... a few years now We liked "The Painter's Wife 2: Return of the Painter's Wife"

I've started using Linux systems in 2023 when I got a NAS with an appliance-style OS and a router with OpenWrt, both of which introduced me to Unix concepts. Since then I've expanded to running a Proxmox hypervisor that runs various VMs and Linux containers that are centered around networking, file management, smart home and machine learning applications. I use Debian for these VMs the majority of the time, and Proxmox itself is based on Debian. Desktop-wise I'm still purely on Windows as my servers keep me busy, but feel certain the days are numbered before I switch to Linux. Debian seems too conservative as a DE, so I was eyeing ArchLinux. Another idea is Bazzite, but at the end of the day it seems the distros differ mainly in their package manager and what's on offer in their repositories.

Welcome back! Keep in mind our moderation for offtopic discussions got stricter, so this time around I'd recommend giving some of the many fan missions a go and telling us what you thought about them.

@datiswous Interesting to see someone giving portals another go. Regarding making it a "one-approach" teleport, an approach could be to use the direction of the player's velocity and a pair of small trigger brushes within the doorframe. The idea would be the player has to step into brush 1, then into brush 2 with a velocity +x for the teleport to trigger. If his velocity at any time becomes -x (which happens if he steps into brush 1, then goes back out and around the doorframe and walks into brush 2), he has to go back to brush 1 again. Behind the scenes, stepping into brush 1 would set a global variable to 1, i.e. "can_teleport". While the variable is 1, a looping script would check every frame whether the player's velocity is -x, setting the variable back to 0. Stepping into brush 2 would check whether the global variable is 1. If yes, teleport the player. The teleportation offset is handled by subtracting the origins of the teleport zones from each other. If the brushes were changed, the position of their origin relative to their doorframe may also have changed and you get a noticeable displacement.

There's this guide that I wrote: https://wiki.thedarkmod.com/index.php?title=A_to_Z_Scripting in particular: https://wiki.thedarkmod.com/index.php?title=A_to_Z_Scripting:_Ways_of_calling_a_script#Stim/Response https://wiki.thedarkmod.com/index.php?title=A_to_Z_Scripting:_More_scripting_basics#Where_to_create_variables https://wiki.thedarkmod.com/index.php?title=A_to_Z_Scripting:_More_scripting_basics#Using_the_TDM_Script_Reference I think Goldwell likes to use such setups. But basically all you need is to have an extinguishable light entity with its snd_lit and snd_extinguished spawnargs matching the sounds you need, as well as a tiny light radius and maybe some low-profile lit/extinguished particles so it can be hidden more easily.

This functionality is already integrated into extinguishable flame entities' scroptobjects (check the light sources folder for i.e. torch flames that play sounds when lit and extinguished). You can also tag on your other stim effects to that entity's water and fire responses. The best way is still to make a pair of short scripts that share a global variable for the speaker state.

Yeah I think something like that would run into a bunch of edge cases. Another one could be players with an ultra wide monitor and a higher FOV being able to see the transition. The advantage of the basic trigger brushes to initiate the teleportation is that there should only be one, predictable way they can work, and they also have a minimal resource footprint. That could make sense for a dead end where you want the player to leave at a different place than where they entered.

Neonsstyle recently pointed out to me that my seamless mass teleportation script doesn't seem to work when the setup is rotated, and I realised that the version I linked to in this thread even relies on manually adjusting the script. It was also inefficient because it had two nearly identical script functions for each direction, and it only supported one teleportation setup per map. As this is an old script it was clearly time to rewrite it. To begin with, the purpose of the script is to enable seamless teleportation without the player noticing that it has happened, giving the illusion that two areas of the map are physically connected. There should be two identical-looking locations, preferrably an S-shaped corridor to limit how much the player can see in the moment he is teleported and thus how much needs to be duplicated. The locations should also be AI-free, since I expect their patrols will break after teleportation. There are two trigger brushes at either end: a narrow brush that initiates the teleportation procedure, and a larger "zone" trigger_touch brush around it that applies the teleportation to the player and all AIs and moveables in its volume. The narrow brushes are in slightly different positions at either location to avoid that the player gets stuck in an infinite teleportation loop. The teleportation vector is automatically calculated from the origins of the departure and destination zone entity, so it's important you keep this in the same relative position. The image above shows the setup: the arrow represents the player's expected direction of movement through each location; the narrow box represents the trigger brush which initiates the teleportation; the large box represents the teleportation zone from which everything that can move gets teleported; the red cross represents the origin of the teleportation zone used to calculate the teleportation vector. To setup, copy the script into your map script or add it to your /script folder. Copy a pair of altogether 4 trigger brushes to your 2 identical-looking locations and change the "zone_departure" and "zone_destination" spawnargs on each of the narrow trigger brushes to point to the trigger zone brushes. With this new version of the script, it should be possible to have as many mass teleportation setups in your map as you want, and rotation should be no problem given the fully automatic calculation of the teleportation vector. mass_teleport.scriptmass_teleport.map

Behind the scenes, what happens is: 0) Lily spawns conscious on her bed 1) one frame after map start, a script is called which aims to KO her (void main() in city.script) 2) the script waits 5s before carrying out the KO (tdm_pw_misc.script) It looks like if you make a save during that 5s (after clicking "Press attack to start") where KO_Painters_Wife is waiting, the KO_Painters_Wife() script fails. This looks like a core bug, so I've posted this on the bugtracker: https://bugs.thedarkmod.com/view.php?id=6640

This sounds like the kind of thing that would happen after you frob an invalid readable. However, all such errors should've been fixed after I fixed all causes of console warnings in this FM.

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.