Dragofer

There's nothing really hindering it, you just have to make sure that both scripts dont try to run at the same i.e. by starting with a version check to pick the right script. Core scripts already include the identifier "tdm" to minimise the risk of conflicts with FM scripts (originally: with Doom3 scripts). You could make up your own identifier such as "snatch", and in a community of this size it'll be unlikely that anyone else will think of the exact same one.

This would be accurate since saves are specific to the scripts (and TDM build) that were installed at the time, so getting a newer version of an addon will make saves incompatible. Changing other custom files like entityDefs will probably cause issues as well. I added this to the creators' notes.

This pinned thread's purpose is to collect links to all the discussion threads for new features to be added in 2.12: [2.12] Multi-addons support [2.12] Auto-search bodies [2.12] Turrets Allow mantling while carrying a body New lean for 2.12 Frob to use world items [2.12] Viewpos on player HUD and screenshots English Subtitles for AI Barks Subtitle Enhancements [2.12] Improved Interaction Culling and a related bug report thread HERE As well as older feature collection threads: [2.10] Feature discussion threads [2.11] Feature discussion threads

Pinging addon creators that are known to me: @MirceaKitsune@wesp5@snatcher@Dragofer

In the current user addons system, only one addon could ever be installed at a time. This was because every addon would try to overwrite tdm_user_addons.script, and only the one in the alphabetically latest .pk4 would win. Merging addons was not a practical solution for most since this required a similar level of proficiency as actually creating the addons. Coming to the next dev build for 2.12, this limitation has been lifted by automatically including or calling all script files or functions that start with a specific prefix. Addon creators will need to choose unique names, however, which could for example include one's username. For now, backwards compatibility with the old style of addons will be maintained so they will still work, but they will need to be updated before several can be installed at once. Note to creators: as this may result in a surge of popularity of user addons to "mod the mod", it feels like some remarks are necessary: it's important to communicate to players downloading the addons that these are to be used at one's own risk and there's no certain way to ensure that no mission will break. releasing a stable mission with the default TDM package is hard enough. Addons create another layer of complexity that is out of the authors' hands. So while it's okay to ask, please respect the authors' decision not to support addons. savegames will only work with the exact combination and version of addons that they were created with. Updated instructions for creating addons can be found here: https://wiki.thedarkmod.com/index.php?title=A_to_Z_Scripting:_Script_addons_for_players

The most appropriate method would be an on_death script. You can reference the fire elemental for an example. Also, the sole purpose of tdm_custom_scripts.script is to allow mappers to add more .script files to their FM, so there's no reason not to use it.

As part of the 2.10 update, a long extinct engine feature was restored by duzenko that allowed the visual changes to happen. Meanwhile, when the item is used its custom scriptobject cycles through all entities on the map that have been marked with a custom spawnarg and updates their solidity. 2.10 was a very feature-heavy update so that became a theme in the contest and using this back-then experimental feature gave bonus points. Meanwhile it's become a core feature. @MirceaKitsuneas this FM is the first instance of the overhauled and quite complex multi-part version of this AI script, it'd probably be good to compile all known issues like yours so the script can be finetuned further. Could probably also do with a wiki page to describe how to use its features.

We have a whole folder of oil lamps in core assets since 2020 or so - for desks, walls, ceilings and freestranding. Also check out the vintage lamps.

For scripting it's essential what order the functions come in because a function can only call another function or access a variable if it has already been seen by the scripting engine. This would make auto-loading scripts in alphabetical order problematic unless all core and FM scripts have their names changed in a way that mimics their current #include orders. It would be better if the order no longer mattered, but that's probably a change in a different ballpark entirely. Also note that tdm_custom_scripts.script is explicitly for mappers and tdm_user_addons.script is explicitly for users/addon creators, with warnings in the respective files similar to how most of our GUI files point people to which ones are safe for them to tamper with. The messup with Hazard Pay happened because the FM provided a copy of tdm_user_addons.script (accidentally left behind after testing), conflicting with other addons. @wesp5files outside of .pk4s already overwrite same-named files inside .pk4s, both on the core and FM levels. In any case, we've recently started looking into a way of supporting unlimited addons in parallel by auto-including and auto-calling script files and functions whose names follow a specific naming convention (tdm_user_addon*).

Alternatively, it's possible the update came from the old missions repo (packed) which still has the stealth scroll bug, instead of the new missions repo (unpacked) which has the fixed version. I just downloaded the FM for the first time on this install and it was the correct version.

The first thing you need is to make sure all your script files have inclusion guards so they can only be loaded into the script stack once (these are the #endif lines you see at the start and end of official TDM script files). If you have those, then as long as both your addon and the FM author use the same name for the same .script file there shouldn't be an issue in terms of re-inclusion. Problems can still arise if both the author and you try to initialise the custom script separately, i.e. in this case you would have 2 copies of the stealth statistics scroll. Another issue arises if the FM author overwrites tdm_user_addons.script, which is the case here, because that will overwrite your addons. This is an error that should be corrected by the FM author (they should use tdm_custom_scripts.script, which is designed for mappers to use), and I've already told kingsal about this just now. Ultimately I think it's hard to avoid conflicts if the FM author integrates a user addon into his map. The best thing you can probably do besides what's above is to make sure each of your files and functions has unique names so both copies of the script can run in parallel in peace. Ofc this doesn't help if the author got the addon from your addon pack. We should probably discourage FM authors from integrating addon packs and instead ask them to point players to a download link.

I guess you'll have a horrible teleportation accident on your hands, then. I don't think the setOrigin code checks whether the destination is free and applies an offset.

Not with the current scripting, right now frobbing causes the door to open and close a little bit to simulate Skyrim-style opening of a closed door to another map section. This would conflict with the stock door opening effects. Apart from that I don't see a technical issue with adding new script effects to an existing door. Conceptually, the teledoor script is designed for permanently closed doors. If the door can be used normally by AI you might find it fully opened. It would be odd if AIs and the player can walk through at will but if the player frobs it he gets teleported somewhere else.

Why would you need this? If a mapper wants to initialise custom scripts in his FM he can do so via the regular map scripts i.e. void main(). tdm_custom_scripts is only needed to add new files to the script inclusion chain.

I don't think you can create brushes on the fly because dmap is needed to give them their collisions.

I believe there's no way to control a func_mover without using a script. Doors have the advantage of having an inbuilt response to frobs and triggers. If you can script, then func_movers are the more elegant option. In this case their advantage would be that you can more easily make it a single-use thing.

Ignoring is somewhat inadequate as you still see other members engaging in a discussion with the problematic user, and as Wellingtoncrab says such discussions displace all other content within that channel. Moderation is also imperfect as being unpleasant to engage with is not in itself banworthy, so there is nothing more to do if such people return to their old behaviour after a moderator had a talk with them, except live with it or move away. I'd be more willing to deal with it if it felt like there were more on-topic discussion, i.e. thoughts about recently played fan missions or mappers showcasing their progress, rather than a stream of consciousness about a meta topic that may or not have to do with TDM. I guess the forums already serve the desired purpose, or they just compartmentalise discussions better.

Yeah, I quit the official Discord after someone intensively argued with me that we shouldn't credit Grayman for Seeking Lady Leicester (but Black Mage was fine?). A few other mappers have left too after similar episodes.

Btw, last time I talked to Flood he said he wanted to step away from this task and is glad for the team to take over. The abandoned missions repo has also been moved to TDM's SVN server. I suppose any team member who manages FM uploads can also accept newly abandoned missions.

Could it be your map is leaking and therefore not generating physics for new geometry? If you use "testmap" instead of "dmap" + "map" it will load the map even if dmap failed.

After a brief delay version 2 of the mission is now up for grabs from the downloader and from Google Drive. The above post does still hold true for the most part, all-round polishing what was already there of this first mission of mine. Retaken screenshots can be obtained here: Google Drive. Thanks go out to the betatesters of round 2: JackFarmer, joebarnin, The Black Arrow, datiswous, Acolytesix

Hm, he's meant to continue talking after the placement is complete and the objective ticks off.

Thanks for giving it a playthrough and leaving the detailed feedback. Regarding your supposed glitch, it's actually an intended feature to ensure the player stays inside the room while the NPC is talking to him to avoid missing cues and not seeing why the objectives were updated. The barrier should be gone afterwards.

This would also have the advantage that the foglight wont be contributing to an extra rendering pass of everything it touches in the map, even if its transparency were ultra high. IIRC a foglight added 1000+ drawcalls to the Perilous Refuge harbour scene.

On a separate note, does the stealth score behave as expected now? 2.11 had some fixes regarding detections by guards in dark places and civilians.