Mod Support Suggestions

[rezecib]

I'm putting this up here so others can add on, and I'm starting to feel like I'm pestering @PeterA directly a little too much... There are a number of areas of mod support that feel like they've been a bit forgotten, and some new ideas I've had that would make certain common things much easier.

1. AddPlayerPostInit. We have this right now, but it's actually really inefficient. Given that this is a really common thing you need to do in mods, and requires a really weird workaround at the moment (lowering your priority to load after all character mods, and then looping over the character list tables...), it would be really nice to have a proper solution to this. For example, the MakePlayerCharacter function from player_common could call these immediately after a character is made. Right now AddPlayerPostInit runs the function after every single prefab is created, which puts a lot of overhead on literally everything.
2. Containers. There's still no truly proper way to add a container widget to the game. Lots of mods do this, and tons of them do it in ways that prevent compatibility with any other container mods. The issue is that on the client, containers.widgetsetup only gets the prefab name as an argument, and only refers to its own local table to look for widgets. All we need is a way to add things to that local table. Right now there are only three (terrible) ways to do this: (a) override containers.widgetsetup (if you do this wrong, you break compatibility), (b) add netvars to your container prefabs to signal when to make the container on the client, and have a function that provides the container data, and (c) do some upvalue hacking to get your data into the containters.widgetsetup table. We really just need an AddContainerWidget function, and perhaps a function to override what container widget a prefab uses.
3. Local variables everywhere. There are tons of local variables in the code that make modding life difficult, forcing modders to either override the entire file, or large portions of it, or do upvalue hacking. If these functions were just attached to the prefab's table, it would make changing them much easier (for example, you can't unhook event listeners well if they have a local function, because you have to give the function to unhook and you can't get it if it's local). DarkXero had a really good solution to this here. This is better than upvalue hacking because instead of needing to know the stack of functions to get at a particular local reference (and thus having your mod broken any time that chain changes), you only need to know the file and the function / value name (only gets broken when the variable or file name changes). This could also get automatically generated into the files, or perhaps inserted into the file loader.
4. Mod compatibility code. Currently the main tools we have for this are setting priority and checking the KnownModIndex (which isn't included in the mod environment, by the way) for a mod's fancy name or modname, and then running code for it. However, we need more control that priority allows. One thing that would be really nice is if there was an AddModPostInit function. These would let you provide a function to run after a specific mod (it wouldn't make sense to have one for before, because your mod won't load its "PreInit" before anyway, and so you can control that with priority). This would make it much easier to add code to support other mods that add things that you then need to modify in your mod. Currently the only solution is to try to hook your code into something else that *hopefully* loads after that mod, and *hopefully* runs before anything else it was needed for. Having a hook to run *right after that mod* would make this much neater.

Also, as a side note, I've noticed a lot of comments in code that's been added to the game recently that mentions sticking with bad architecture because you guys don't want to break mods. I, at least, would much rather have the architecture improved, and have some crashes to fix, than have bad architecture stick around. But perhaps I am a minority in this opinion.

Edit: Another idea that I've already mentioned to Peter:

1. Mod revision numbers. Currently the game can't tell if a mod's version is greater or less than another version of it, because the version numbers are just strings and you can put whatever you want in there. Because the mod uploader requires you to change the mod version every time anyway, it might as well just automatically assign a hidden version number ("revision number") and then use that to keep track of mod versions. This would let you still use "nice" version names, but also allow the game to understand mod versions better, without adding any extra work to updating mods.

Edit: Brought up by DarkXero:

1. Tags: Apparently entities only network up to 32 tags, and if you go over that, some tags just don't get networked. Especially with several mods modifying the same thing, it's very easy to go over this limit, with components often adding their own tags. At the very least, there should be an error message on adding the 33rd tag ("Entity already has 32 tags: <list of tags>"), but ideally this could get increased. I'm not sure how much of an overhead this adds to the game, so perhaps there are good reasons not to increase it.

Edit: Brought up by CarlZalph:

1. Proper mod keybindings. Right now mods have to either steal one of the game's controls or explicitly provide a list of raw keys that they can be bound to in the config option. The ability to do true keybindings would be a huge quality of life improvement for people who use mods.

Edited June 18, 2016 by rezecib

[Fidooop]

I fully agree with everything here! I don't have much of anything to add on to it really.

*cough* except adding in an official function for mod character to add their own GoH/Survivor/Triumphant skins but whatever I can wait for that *cough*

[HomShaBom]

#3. omg #3. Yes. That. Do it now. I'm trying to change something with ponds and the listener it puts on the pond to turn on/off the childspawner based on the time of day is driving my crazy. I just want to remove that listener but i can't because its local and I don't have access to it.

Edited June 13, 2016 by HomShaBom

[rezecib]

@HomShaBom Well, I'm not quite done with this, and it's a bit advanced, but I tried to do some good explaining here. This will help you be able to make that change before they add real support. Here you go: UpvalueHacker

[HomShaBom]

Oh, cool, I will probably need that at some point. But back on the Pond issue, after I posted that I had a revelation... it is adding the listener in a task and assigning the task to inst.task. So in my AddPrefabPostInit i can check if the task exists and if it does cancel it right away. That prevents the listener from being added. I still have to duplicate some of the work (like I still need to add listener for snowlevel) but I can deal with that.

Edited June 14, 2016 by HomShaBom

[CarlZalph]

Ah, something you've left off was native support for keybinds.

 

Right now mods use a wheel of predefined keys that may be used for their actions in the mod's configuration tab rather than a 'click key to bind' feature.

[PeterA]

Thanks for compiling this list @rezecib and everyone else for providing their feedback! My time is split between a bunch of tasks at the moment, but I'll try to fit in some time to improve these.