Dragofer

I did exactly this in One Step Too Far using def_attached props and a small script that activated teleportation entities: void MenReturn() //thugs return to their house on the beach { sys.wait(10); sys.trigger($danger_ambient); $woodsman_teleport1.activate($Woodsman1); $woodsman_teleport2.activate($Woodsman2); $woodsman_teleport3.activate($Woodsman3); $woodsman_teleport4.activate($Woodsman4); sys.trigger($start_AI); $boat1.setOrigin('-8084 30528 -13452'); $boat2.setOrigin('-8512.1 30535.5 -13453.4'); sys.trigger($gold_bar_hint_speaker); $player1.replaceInvItem($BookFog,$null_entity); //BookFog is removed $player1.addInvItem($BookMen); //player receives BookMen sys.trigger($BookMenAcquireSound); //plays a sound when receiving the book $Window_Porch_Outside.Close(); //bugfix thread BookMenPost(); sys.wait(50); $danger_ambient.fadeSound(SND_CHANNEL_ANY, -30, 20); sys.wait(20); sys.trigger($danger_ambient); } thugs.pfbx def_attach, besides binding the prop at the correct position, angle and bindpoint defined in the prop definition, can also alter animations and various behind the scenes work to make the AI work well with that prop. I think it should also be possible to bind a prop entity after the map has started and achieve the same effect, but haven't tried and you would probably need a supporting script to calculate the correct position. If you bind a normal moveable entity or even a func_static it'll just be a visual model next to the AI, which is fine for keys but not for lamps etc. Normally bound entities should follow the parent entity's position and rotation around exactly, including when it's teleported. If the teleport entity leaves bound entities behind it's a bug that should be reported - may be worth isolating that into a test map and filing an issue on the bugtracker. It's surprising to me since almost all AIs have def_attached props (i.e. weapons) and a lot of mappers have used the teleport entities before.

Yes, it may be enough to just change the def_projectile spawnarg. The flashbomb might have some unique scripting that depends on player inputs, but in that case it would be possible to clone the rock projectile, give it a flashbomb model and make it cause a flashbomb effect when it hits something. Likewise, you can change the weapon and arrow projectile spawnargs. As long as the new entity can function as a weapon (the right spawnargs in its entityDef, a collision model etc.) it will work. We have a selection of non-standard weapons in the core assets already.

I remember trying to clean these up enough for TDM but got lost in the detail-richness. Those are fun models.

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.