Customization scripts (global and per-map)

[Tsuey]

For @Treescrub. Summary of discussion from Issue #7:

• Prevent server admins from needing to maintain files we'll be changing with future updates, i.e.:

https://github.com/SirPlease/L4D2-Competitive-Rework/blob/master/scripts/vscripts/anv_versus.nut

• Comprehensive changes SirPlease currently makes that need support:

  c2m1_highway:

    "_motelskyboxroof_clipinfected"
  

  c2m4_barns:

    "_hittable_bumpera"
    "_hittable_bumperb"
  

• If necessary, re-work anv_functions.nut to pre-empt spawning of entities instead of deleting them after they have spawned.

• Possibly a Mutation-style configuration file to add/remove/edit entities? Are we requiring the user to have scripting ability?

• Customization script for each map that runs if the script exists. Allows customization without relying on exactly how the map specific script is set up, and it wouldn't cause issues with updated scripts unless the customization relies on specific entities the normal script creates.

• Add a variable that can be set to prevent normal map specific scripts from running so that customization scripts can easily work with a blank slate.

• A main customization script that's always run is definitely a must. If there was no global customization script, then modders would have to edit anv_mapfixes to do mode specific changes.

[Tsuey]

Also: one criticism of using VScript for map fixes is that Stripper:Source config files don't have much means of interfacing with them. Accessible customization configs/scripts should help with that.

A related criticism comes from Rene's RocketDude Mutation as an example. His script kills the new clips with a long delay, just for the sake of ensuring they're deleted. A global variable or other means to conveniently pre-empt them would be cool, but I'm not sure that's possible if mapspawn.nut runs before all Mutations.

Note: Replacing mapspawn.nut with an empty (or slightly modified) file is the intended way to override the update's changes. Several revert addons (or servers) use this method. Reverting isn't an issue, the interest is just if there's more flexible options for control.

[Derpduck]

The specific "SirPlease" changes listed are simply a product of initial efforts to remove these changes, the method isn't ideal and now as a result many server owners have this script permanently overwriting any official updates to this script.
I will push an update for Sir to apply those changes without modifying the script files, and try to encourage server owners to not use this method. But at least for competitive servers, this kind of modification should not be an issue when better methods already exist.

This is the method currently being used by SirPlease to remove VScript map changes:
https://github.com/Derpduck/L4D2-Comp-Stripper-Rework/blob/master/cfg/stripper/maps/c2m1_highway.cfg#L1318
It can still potentially be prone to issues if the script takes a long time to execute, I had to increase the delay before deleting the entities by quite a bit.

Don't know if this is the best approach, but one way I see the customization working is this:

1. Load anv_mapfixes for current map
2. Load customization script for current map
3. Provide a function that can be passed values to modify anv entity properties, or fire inputs to them (e.g. mins, maxs, Kill)
   • Functions to do this en-mass like removing all clips/props could be added too

Function could be something like this:
modify_anv( targetname, keyvalue name, value )

There shouldn't be an issue of timing since the anv_mapfixes changes will always be loaded first.
Not sure how efficient a method of checking each entity as it spawns instead would be.

Regardless of the method used though, there could still be the issue of conflicting customizations overwriting each other, such as 2 different mutation addons both trying to load a customization script for the same map.

[Treescrub]

* Possibly a Mutation-style configuration file to add/remove/edit entities? Are we requiring the user to have scripting ability?

Wouldn't that essentially be a commentary file? I think it would be too much effort for very little reward. We would have to create a parser for the files, which could cause performance issues or confusing bugs.

[Tsuey]

It's easy to over-think this, so probably simply running per-map and a global script (none of which we ever ship) should be enough. Maybe the bigger question is what the files should be named -- anv_customization.nut might be a strange choice if we plan to change 'anv_' later.

*.nut files will be fine, since any supplemental entity placement tools would output make_ function calls to console that can just be copy/pasted in.

Regarding what we should do for RocketDude etc.... things could get a bit convoluted, so some experimentation may be needed. An "off switch" global variable is probably the most sane approach.

[Treescrub]

Anyone have any thoughts on when the custom script should be run? I was thinking it should be run just before anv_mapfixes is run so that the custom script can disable base global and/or map fixes. It would probably be the easiest to implement, but might not be super user friendly.

[Tsuey]

Anyone have any thoughts on when the custom script should be run? I was thinking it should be run just before anv_mapfixes is run so that the custom script can disable base global and/or map fixes. It would probably be the easiest to implement, but might not be super user friendly.

Sounds fine tbh. I imagine that the simplest approach should work for now.

Global and per-map customization scripts would allow for a lot of flexibility. The approach would inevitably change for major re-writes i.e. #27 and beyond.

[Tsuey]

See PR #27 and this commit. Allows users to CancelUpdate() and execute their own code from "community/usercustom" and "community/usercustom/MAPNAME" scripts.

This issue is outdated as competitive configs have long deleted anv_versus.nut and remove unwanted changes in other ways.