Dragofer

@grayman thank you for the promising idea, but it doesn't seem to be what it takes. I've started with cloning & renaming the message scriptobject + def, with the difference that it calls the message gui with layer 101 instead of 10 (and I set cinematic 1 inside DR). That didn't change things. Then I lifted the bare essentials from the scriptobject and turned it into a map script. Tried layer 11, 16, 26, 51, 102, 250, 1002... works fine except when there's a func_cameraview active. I'd take a look at the func_cameraview's coding but that seems to be buried in the source code, which is a different beast from Doomscript. I don't know... do you have an idea what's going wrong?

Hm, I want to show a message during a cutscene (by using sys.trigger() on an atdm:gui_message entity) but as long as there's an active func_cameraview it doesn't show up, while outside of the cutscene it shows up fine. This is despite cinematic 1 being set on the entity. Also tried force 1, which made it show for just a split second. Has anyone pulled this off before?

Pausing the game would probably be the most elegant solution, but you can probably get away with using the camera to freeze the player's controls and calling that video overlay which covers the whole screen. The player wouldn't know the difference. If the cutscene should be shown in an area that AI can access it'd be best to teleport the player to a safe blue room while the cutscene is playing.

Yes, looks like you can simply define a GUI and call it as an overlay with a script. Still just an ingame texture, but more refined than making an ingame cinema screen for the player.

You could override that particular material by copy pasting it into your own .mtr file (renamed from .txt), fix the inconsistency in it and provide it with your mission. As for fixing it, I'd look first to see if at one place it points to diffusemap x and another to diffusemap y. Can't look at this myself atm as I'm not near a PC.

@Amadeus #1 looks like it's because the material used by that skin is mixing several different textures together. For #2 if this happens even though your compass has inv_map_start and no diff_x_nospawn spwnargs I'd replace them with the ones you get when importing the prefabs from the mapper_tools folder. Remember to adjust their diff_no_spawn spawnargs after you imported them.

Oh nice texture painting onto a model, maybe I can finally start more regularly making my own textures with this.

Yeah, this website has more shots showing the ceiling and other details around the place: https://www.apotheke-adhoc.de/nachrichten/detail/apothekenpraxis/berlins-aelteste-apotheke-berlinapotheke-am-hackeschen-markt/

Now this is one fancy apothecary's near where I live:

It's because the player will still hear his former surroundings if you don't teleport him, the func_camera only changes what he sees. Safety from AI is another benefit of course. IIRC grayman did work with changing the position of the player's 'ear', so it may be possible to get a kind of microphone functionality. This is pretty vague coming from me though.

You can trigger a func_camera to freeze controls and again to unfreeze. It's good practice to put those triggers into a script together with a sys.wait command so that the player is able to press escape to skip the cutscene.

It looks to me like it does have one, it's under intrinsic properties as "loss_open" "1".

I have some buggy doors which have a pretty big drop in sound volume across them even though they're open, and they don't respond to loss_closed and loss_open spawnargs. For example if I'm in a deckhouse and open the left door, the wind becomes louder as expected, but if I open the right door the wind is still muffled by what must be 10dBs. Only when I walk through the doorway does the wind become louder. The wind speaker has a very large maxradius that's more than twice the distance to those doors, and there are no visportals on the way. Has anyone else run into this/solved it?

@Geep it is indeed, you need to setup a new GUI material as per these instructions and you'll be able to texture ingame surfaces with that material - note that you should use FFPMEG instead of ROQ video format nowadays. You'd probably want to teleport the player into a dark quiet room, activate a func_camera and let that surface cover the whole view of the camera, but you could even have the video as a fully integrated part of your map (like Greebo did with this laptop in 2007):

That's the tricky thing about it, users.xml stays unchanged when reinstalling DR, so you have to go and find it in that hidden AppData folder. Fortunately Orbweaver fixed that particular unhandled exception in 2.7.0.

@Amadeus while you're already in the AppData/Roaming folder, maybe you could try to backup & delete the the files in there? The last time I've seen an unhandled exception was because users.xml got corrupted, so maybe this is along the same lines. If it fixes the issue it'd be worth uploading the broken files to the bugtracker.

Ah, that clears up why I was having such a rough/inconsistent experience with scripting sounds. Turns out I've been missing theory. So, I've switched to startSound for snd_open without problems now. Will still keep startSoundShader for snd_close because I want to run that on a different entity which may have a different/missing snd_close spawnarg, but added a line to cache snd_close in initialisation. Also fixed a bug: turns out I can't check multiple conditionals side by side in the same for(), so the teledoor was missing some target assignments. Moved them into each their own for() and they catch everything now. Broken & working versions:

@stgatilov thanks for finding that out, this kind of thing can go on the wiki later on. Neither do I. I've made a simple map script yesterday that should automatically play the start, loop and end sound of an elevator at the location of player1 and prints sound durations to the console. If I use the thread with startSound, no sound is played and it returns 0 as the duration of the start sound, while if I use the thread with startSoundShader everything works smoothly: Now I'm no longer sure if I ever managed to get startSound to play a sound. Been experimenting with netSync 0/1 as well as alternative channels. You can specify a channel either with text or a number: tried channel 0, 1, 5, 9, 11, SND_CHANNEL_UNUSED, _UNUSED_2 and _ANY, I never hear anything and duration is 0.

Thanks, that's got me on the right track. There's startSound and startSoundShader - the wiki says startSound is to be preferred, but it's been behaving oddly when I was working with it. It also has an odd 3rd parameter called netSync that's never been mentioned anywhere on thedarkmod.com. Seeing that it always returns 0 as the duration caused me to look for another command: startSoundShader, which works flawlessly out of the box. So, the teledoor has been refined: the teledoor now uses snd_open and snd_close instead of asking for speakers. snd_open gets played on this teledoor, while snd_close plays on the other side's teledoor if the mapper has targeted it, otherwise snd_close plays in the player's head. There are now no more custom spawnargs. the teledoor now identifies up to 2 door handles via their spawnclass, rather than triggering all bound entities (this was after getting blocked by a bug in trying to identify them via their "inherit" property) Also experimented with making it lockable, but the road got blocked at calling the use_action_script. As I understand the use_action_script should get called when I use any inventory item on it, but the items seem to only use themselves on themselves. I'm guessing when an item is used it checks whether an eligible entity like a mover_door is in your frob highlighter? For an in-Doomscript solution I'm imagining turning this into a hybrid between a func_mover and an elevator button, which spawns a symbolic elevator that tells the AI to wait x seconds before it can move from its new position. Well.. it sounds like the kind of thing that you can spend ages tweaking & polishing, and as has been said it's mainly for special situations. I'd rather get my spawnarg-controlled func_mover ready before going down this route.

Would've thought I always double-clicked to load them, but that's not how it works at the moment, and I agree it'd be an improvement. I've opened an entry on the bugtracker for this.

Well having thought on it I can probably do something inside Doomscript, given enough input from the mapper: 1) Ask the mapper to draw an inactive trigger_touch brush in front of each teledoor. It should represent the max range from which an AI would pursue the player through the door. Also ask the mapper place a 2nd teleport entity and maybe also a 3rd in case the 1st teleport spot is occupied. 2) Every time the teledoor gets activated its trigger_touch brush runs for one frame to detect all AIs and their alert states. 3) For any alert 5 (chasing) or alert 4 (agitated searching) AI, calculate their distance to the door and assign a time taken to reach it. Alert 4 AIs have to be closer to the door and take more time to reach it. 4) If the player is still on the other side of the door after the time has elapsed, the AI tries to teleport. Prefer the 1st teleport spot, but use the 2nd spot if the 1st spot is occupied. Run the trigger_touch before each teleport to make sure there are no AIs or moveables standing on the targeted spot. If occupied, wait 1s and try again. 5) After teleporting, check the AI's alert level every 3s. If they're back down to alert 1 (idle, but alert), let them walk back to the teledoor and open it. The AI gets teleported back to the other side - Skyrim has them fade out first - if any of the teleportation spots are free. If they're occupied, keep checking every 3s 6) Find what path node the AI was targeting and reassign it so the AI resumes his patrol. So it's clear this is a larger project than just getting a new kind of teleportation entity, and there's more that can go wrong. I'd probably be better off learning C++ and doing this properly with all the extra commands available in the source code.. And yeah, chakkman makes a good point about physically connected spaces being preferrable, even if teleportation has its uses. My current WIP ship uses these teledoors to get a more spacious interior that has more content and is less prone to the pathing issues seen in one-piece ships. Imo the benefits outweigh the downsides by a good amount in this case. An alternative that I'm using for another WIP btw is my mass_teleport script: 2 identical areas with a large trigger_touch brush that can be activated to detect & call teleportation on all moving entities except AIs.

Nope, that's a size too large for me I believe - would probably have to identify an area with enough pathable space to teleport the AI to. Something that I could possibly get to work is, when there's a level 5 alerted AI chasing the player: stop the door from working. But imo doesn't really make sense that you can't open certain doors because you're being chased. play a silent alarm on the other side of the door that alerts the AIs there. This can mess up something cramped like a ship interior. I remember a discussion from jarredmitchel's ship, which also has teleports between interior & exterior - one solution I offered was to do nothing, because most players quickload anyway when they get spotted. Edit: hm, could maybe ask the mapper to place a teleportation entity for chasing AIs. But what if there are 2-3 AIs chasing the player?

This is a Skyrim-style door which opens just a bit into a black_matt "void" before teleporting the player to a different area of the map, which may represent the other side of the door. This is used for connecting physically separated map areas with each other, such as when there's an exterior/interior split of a building or ship to allow for more mapping freedom. It's based off the func_mover, so it's only distantly related to normal doors and works slightly differently. Usage is to specify rotate/translate/move_time/accelTime/decelTime/snd_open/snd_close, target an info_player_teleport entity and optionally the corresponding door on the other side. It'll trigger all other targets and automatically detect up to 2 door handles. Currently no support for locking or AI pathing. At the end of the video you see something to be careful of: don't put bright lights on the other side of the door where the player can get seen. Also noticed the audio is a little bit delayed in this video. teledoor.pk4 The download comes with a prefab and entity def with tooltips for new spawnargs. Drop or extract the .pk4 in your FM folder and you will find a new entity atdm:teledoor in the folder movers/doors. Remember to update your tdm_custom_scripts.script if you've already modified yours. This is the scriptobject: And entity def:

@wesp5 Sure thing, feel free to add it to your Unofficial Patch.

Now then, I've created a new way to show stealth statistics. Simply place the .pk4 in your darkmod installation and you will start every FM with a scroll called "Stealth Statistics" in your inventory, which you can "read" to show a small message with current stealth statistics. Addon - Stealth Statistics for 2.07 I've taken on some ideas posted in this thread, and was also able to make good use of kcghost's earlier work. The scripts are included via a new tdm_user_addons.script file, which also contains an initialisation script that gets run by tdm_main: user_addons_init(). Any addons that want to be run at map start can be initialised by calling their init script from within user_addons_init(), simply adding one line. Disclaimer: this addon modifies tdm_main.script in order to better support addons. tdm_main is very likely to get changed in future TDM versions, in which case this addon will need to either get updated or removed. Ideally TDM will support addons better from 2.08 onwards. The point still stands that a GUI will yield the most polished results, but as an FM author I'd have to put in some time to learn how to setup GUIs, while I've already done more than a few things with scripting. By the way, to anyone who uses this, I'd appreciate if you could share if the scroll shows the same score as is shown at the end of the mission on the statistics screen. I've noticed a few cases where stealth score doesn't seem to get added how you'd expect - got the feeling there might be a bug either in the stealth scoring system or in the commands used by the scroll's script.