Snatcher's Workshop - Mods for The Dark Mod

[Dragofer]

1 minute ago, snatcher said:

I dare invoking @Dragofer to evaluate a "custom_script_ini()" on "script/tdm_custom_scripts.script".

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.

[snatcher]

Ok then.

[wesp5]

I tested the new Hazard Pay version with my patch and I still get errors when starting it, because the mission contains the same statistics scroll script as my patch and doesn't like that variables and other things are reassigned. Is there an easy way to avoid missions breaking if they include duplicate scripts or do I need to rename everything in my version and hope that nobody uses the same names? I can imagine the same happening to snatchers mod, like if a mission editor likes a feature and includes it in his mission, the mission will break once snatcher's mod is installed in case names are the same...

Edited November 11, 2023 by wesp5

[Dragofer]

10 minutes ago, wesp5 said:

I tested the new Hazard Pay version with my patch and I still get errors when starting it, because the mission contains the same statistics scroll script as my patch and doesn't like that variables and other things are reassigned. Is there an easy way to avoid missions breaking if they include duplicate scripts or do I need to rename everything in my version and hope that nobody uses the same names? I can imagine the same happening to snatchers mod, like if a mission editor likes a feature and includes it in his mission, the mission will break once snatcher's mod is installed in case names are the same...

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.

[MirceaKitsune]

I blame tdm_custom_scripts.script... which may not be at fault for all such cases, but I blame it none the less as I hate it being a requirement I'd prefer all scripts being auto-loaded like defs and everything else, in alphabetical order so the pk4 with the last name overrides older versions with ones in the FM directory having higher priority: This would finally make it possible to include mods with custom scripts as a simple drag-and-drop pk4, no need to have FM's integrate it or a separate mod installer.

Speaking of which: Why not have a mod section in the vanilla installer itself managing those mods? I haven't used the mod workshop yet but understand it relies on its own tool, which is likely not hard to use but we already have an installer which could include these just as easily so more people can find and enjoy them.

[wesp5]

4 hours ago, Dragofer said:

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.

The statistic scroll script has the inclusion guard, but it still fails although I use the same script, maybe this is not working as intended when the game tries to include it twice? Here is the error I get and the part of the script that causes it:

Error: file script/tdm_statistic_message.script, line 5: statistic_message_init redeclared

 

#ifndef __STATISTIC_MESSAGE__
#define __STATISTIC_MESSAGE__

void statistic_message_init()            //spawns a statistic scroll inventory item that's added to the player's inventory automatically. It carries a scriptobject to display stealth statistics on a message entity, by Dragofer
{
    entity statistic_message    = sys.spawn("atdm:statistic_message");        //spawns a message entity tailored to showing 2 lines of statistics
    entity statistic_scroll        = sys.spawn("atdm:statistic_scroll");        //spawns an inventory scroll that controls the message entity
    statistic_scroll.addTarget(statistic_message);                    //links the inventory scroll to the message entity
}

...

#endif __STATISTIC_MESSAGE__

 

 

Edited November 11, 2023 by wesp5

[kingsal]

Okay. Im gonna actually make these updates in the hazard pay thread and make sure everything is working. 

 

 

Edited November 11, 2023 by kingsal

[snatcher]

It is all my fault and I am sorry.

I should have played safe and renamed everything before proposing the change to @kingsal.

[wesp5]

10 hours ago, snatcher said:

It is all my fault and I am sorry.

It's not your fault, I have the same problems. It's just the structure of TDM. Would it be possible like MirceaKitsune suggested to give files outside mission pk4s higher priorities, so that if the game finds the same file again inside a pk4 it is just ignored? As far as I know this works for the base pk4 files just well...

Edited November 12, 2023 by wesp5

[MirceaKitsune]

8 hours ago, wesp5 said:

It's not your fault, I have the same problems. It's just the structure of TDM. Would it be possible like MirceaKitsune suggested to give files outside mission pk4s higher priorities, so that if the game finds the same file again inside a pk4 it is just ignored? As far as I know this works for the base pk4 files just well...

Similar: My suggestion is getting rid of needing tdm_custom_scripts.script as a requirement. The problem is that unlike every other asset, be it a def or a skin or model or texture, scripts need to be referenced from a core script file for execution: FM's each need to contain a file with that exact name including their custom scripts.

The problem with this is that no mods containing scripts can work out-of-the-box as a drag-and-drop pk4, the same way that say a custom character (just AI model or skin) can: Each individual FM needs to integrate it manually, universal mods aren't possible since the last pk4 loaded will override tdm_custom_scripts.script or tdm_user_addons.script breaking all previous mods referencing their own scripts from those files.

The ideal solution would be just auto-loading scripts like everything else. But I imagine this may no longer be possible as it could break a lot of existing things like older FM's. One compromise I believe I suggested was allowing a dynamically named script to be auto-loaded by the engine, which would make it so different pk4's don't override the exact same file and conflict with each other: If your mod is named "whatever.pk4" for instance, the engine should auto-execute the script named "scripts/whatever.script" located in that archive... this would provide an elegant and equally sandboxed solution to this long standing issue.

[Dragofer]

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*).

[MirceaKitsune]

1 hour ago, Dragofer said:

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.

Yeah, that's what I was thinking of. When FM independent mods are also circulating this is bound to happen with the current system unfortunately, realized it soon after I started delving into modding. In the mods I posted so far I include the notice that you must edit tdm_custom_scripts.script yourself and watch out for it overriding or being overridden by other mods even then.

1 hour ago, Dragofer said:

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*).

Thank you lots for this, can't wait! The best solution to me always seemed like the one I suggested: Auto-execute the script with the name of the archive, so if it's "mod_something.pk4" then "scripts/mod_something.script" is automatically ran only from that archive. Only problem is if you put things like version number in the archive's name this would require renaming the script with each update, I wonder if a slightly different way is possible like pattern matching based on any part of the name, but anything among those lines will be a godsend.

Edited November 12, 2023 by MirceaKitsune

[snatcher]

3 hours ago, Dragofer said:

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*).

This is most excellent news!

Break the Modpack or any other add-ons / mods in the process if you must. We shall gladly rebuild them!

Set up a good foundation. The most exciting and ambitious mods will require config files and dedicated guis, but we aren't there yet.

[boissiere]

6 hours ago, MirceaKitsune said:

Auto-execute the script with the name of the archive, so if it's "mod_something.pk4" then "scripts/mod_something.script" is automatically ran only from that archive

I'd like to chip in and say I think basing the script name on the archive/file name is not a good idea. Filenames are extrinsic to the mod and something you have no direct control over. Someone may unwittingly change the filename and wonder why the mod stops working.

You'd be better off having a fixed script name for all mods which is, I think, what dragofer says is being considered.

[MirceaKitsune]

29 minutes ago, boissiere said:

I'd like to chip in and say I think basing the script name on the archive/file name is not a good idea. Filenames are extrinsic to the mod and something you have no direct control over. Someone may unwittingly change the filename and wonder why the mod stops working.

You'd be better off having a fixed script name for all mods which is, I think, what dragofer says is being considered.

I know, it's just the only easy way I can think of. Fixed script names is what we have now, tdm_custom_scripts.script or tdm_user_addons.script: Every mod will use them up and thus take them away from other mods. We need something that's dynamic and unlimited.

A better alternative is a prefix to indicate you want auto-running of that script: Anything called "scripts/include_*.script" would be a good one, just use an unique name and call yours "include_mod_something.script" which will work if no one else names theirs "mod_something".

Even better: Have a keyword at the beginning of the script! Like how scripts in Linux start with #!/bin/bash so file managers know how to preview them: Similarly we could add something like #autoexec at the beginning of ours, though this approach requires the engine looping through all script files to detect this keyword.

We could imagine making tdm_user_addons.script unique per pk4. But I haven't even mentioned this one as it goes against how the file system works: You can't have multiple files with the same name and different contents, the latest archive in alphabetical order must always override a file loaded by an earlier archive.

What gets close to that is a special text file in each pk4 like a package.txt which references the inclusion script as a flag. FM's kind of do that with darkmod.txt: When each pk4 is iterated by the engine at startup, it could read a script name mentioned there and execute the file referenced. But this seems more complicated than necessary unless this configuration is used for more stuff, maybe to list loaded mods in the main menu with their title / description / author / version the same way missions are?

Edited November 12, 2023 by MirceaKitsune

[wesp5]

Small update: It seems the issue with Hazard Pay was fixed by kingsal now, so from my side everything is fine :)!

Edited November 14, 2023 by wesp5

[snatcher]

Good. Thanks @wesp5 for letting know and thanks @kingsal for your patience with all this.

[snatcher]

TDM Modpack v3.8 released in the opening post

Introducing... the SHOCK MINE MOD v1.0

We must thank @wesp5 for this one!

Flashmines are a rare item nowadays. Shortly after production begun blueprints of a more practical equivalent made it into the streets and Flashbombs took the market by a storm. To make matters worse, Flashmines had a critical flaw and the inferior chemical components degraded over time and Flashmines were quickly known to have caused misfortunes.

The Flashmines that remain in the black market are now old, unpredictible, and dirty cheap. "I am not interested, chap. Too dangerous! A single spark and I am out of business!", could be heard from a merchant in a tabern. Later that evening a few Flashmines had a new, mysterious owner. A couple of nights after the first altered Flashmine was put to the test with shocking results.

The original "Electric Mine" can be found in wesp5's Unofficial Patch. Stims are, in my experience, unreliable and for this new take on the infamous mine I ended up scripting everything. New sounds, different effects... but more importantly, KO's are now credited to the player.

A Shockmine is a powerful, silent weapon that can put most of your opponents down but be careful, Shockmines can be deadly. Whenever you stumble across a Flashmine just grab it! Our protagonist knows well what to do with it.

Big thanks @wesp5 !

 

HUNTER BOW MOD v1.1

Something that buggered me from day one is the mandatory reload when you miss a shot with the Rope Arrow. The Hunter Bow Mod has been upgraded so that when you miss the shot you have the opportunity to retrieve the arrow. Sometimes arrows will land in inaccessible places but hey, you at least have a chance now.

 

CLASSIC BLACKJACK MOD v1.3

A little update to conclude the "It Just Works" exercise. The blackjack is now as reliable as it can get...

KO guaranteed: no indicator and no quick-save required.

 

FLASH GRENADE MOD v1.1

Flashbombs no longer clip through the world and the script has been greatly improved. There is no way Flashbombs can fail now: if AI are within range and sight, AI will be blinded. I consider this the definitive version.

---------------------------------------------------------

Thanks to @Dragofer & Company, The Dark Mod 2.12 will allow different mods to coexist so expect a reorganization of the mods included in the pack sometime early next year. Until then, have fun with the TDM Modpack!

The download can be found in the opening post.

Full changelog:

==============================
  v3.8 - New release
------------------------------
• STANDALONE SHOCK MINE MOD v1.0: Initial release.
• FLASH GRENADE MOD v1.1: Resolved clipping issues, better AI blind detection.
• HUNTER BOW MOD v1.1: Retrieve rope arrows when missing shots.
• CLASSIC BLACKJACK MOD v1.3: Improved collision detection.
• PLAYER SKILLS MOD - DISTRACTION v1.4: Revised mod, new method.
• Modpack: Minor general corrections. 

Cheers!

Edited November 26, 2023 by snatcher

[wesp5]

Great that you used my idea for the shock mine, it was time I gave something back having taken much from your mod for my patch ;)! But I have some questions: 1) You write K.O.s are credited to the player now. I wasn't aware this wasn't the case before. Is this a general mine problem or how can I fix this? 2) You write that your version can kill players. How? What are you using instead of stims?

Edited November 26, 2023 by wesp5

[snatcher]

29 minutes ago, wesp5 said:

Great that you used my idea for the shock mine, it was time I gave something back having taken much from your mod for my patch ;)!

We get along and players win. Thanks again!

29 minutes ago, wesp5 said:

1) You write K.O.s are credited to the player now. I wasn't aware this wasn't the case before.

Both the Electric Mine and the Shock Mine look more or less the same in-game but the difference in the approach is considerable.

I first wanted to do without the Gas stim and use the KO stim instead:

1. To avoid the cough
2. To avoid extinguishing nearby candles and fires

Stims are great for things that may or many not happen but when things must happen stims are unreliable and we end up using stims wrongly, creating more issues as we go.

The KO stim didn't work:

1. It doesn't hurt the player
2. KOs don't get credited to the player

So I scrapped everything and started from zero. A script now takes care of the most relevant events with no room for unintended side effects or failure.

29 minutes ago, wesp5 said:

Is this a general mine problem

It is not a general mine problem, this is how the game is designed and it our problem.

29 minutes ago, wesp5 said:

how can I fix this?

If you mean: can I fix it with a few edits? The answer is I have no clue. You must use my version.

29 minutes ago, wesp5 said:

2) You write that your version can kill players. How? What are you using instead of stims?

I took advantage of both built-in "defs" and scripted events. Shock Mines first damage AI:

• If AI is still alive then AI fall unconscious (KO)
• If AI is low on health AI dies and so will you!

[wesp5]

Uh, this sounds a bit complicated. I will keep my version for now :)!

[snatcher]

There it remains for the taking!

Edited November 29, 2023 by snatcher
Removed mention to a member

[datiswous]

On 11/26/2023 at 5:39 PM, snatcher said:

If AI is low on health AI dies and so will you!

Why will you die as well?

[snatcher]

Sorry, I intended to say that just as AI can die, you can also die if your health is low and you step on an armed Shockmine (or you are close when a Shockmine detonates).

[snatcher]

The second post of this topic - Beyond the Modpack - now includes a list of other Tools and Mods for TDM.

Are we missing anything? Let us know!