Jump to content

VS modding standard library repo


Recommended Posts

After some thinking, I realized, there really will never be the need for a standard modding library. Tyron has been diligent about making additions to the modding API when asked. If we ever need something enough for it to be in a standard library, it's also probably enough to be included in the base game.

BUT there may still be a need for domain specific libraries and APIs, say, mechanical power and energy, or complex animal behavior.

Edited by VeryGoodDog
rip brain idea
Link to comment
Share on other sites

As i tried using a separate .dll. As a standard library it only causes conflicts, that may partially be solved by 1.13 but in the end you will still end up with different versions which may result in version conflicts at runtime. I tried embedding files with git submodules and just dedicate a folder to these files and at the moment it looks quite good. Updating can happen via a normal git pull, followed by a commit in the mod repo. As long as not every mod gets separate app-domains so different libraries don't clash i would favor separate files embedded via git (or copy pasted if you don't like progress :P). As much as i hate code duplication, because this is a modding environment and i don't see separate app-domains as a reasonable approach (performance, cost of rewriting, etc.), i see a embedded dll as the good-enough solution.

For examples how i embedded it for my mods look at https://github.com/p3t3rix/VsFoundation

Link to comment
Share on other sites

i prefer the compiled one. currently i have the zip with the dll (add <mod> compiled) in, while hat some troubles with the add-dll.
but i would prefer the dll package. all in one and nothing you can forget while packaging. zips can be manipulated and may crash it.

or may i missunderstood the question?

Link to comment
Share on other sites

As Melchior mentioned a precompiled dll would have the disadvantage that you have a problem if the library updates and breaks the contract (for example a refactoring that changes some namespaces around) and suddenly you have to update your mod because the standard library changed or otherwise you force people to choose either your mod or newer mods that use a newer version of the standard library (because you cannot load them side by side as far as i know). So by basically just having a set of .cs files that get copied to your mod your mod does not depend on the standard library mod.

This of course is only true as long as you don't want to distribute stuff like a behavior that other people would reference, but only helper methods, extension methods, stuff that would not be referenced outside your project.

If there is need for example for a set of behavior that should be shared among other mods (for example a energy storage api, an interface that marks a block as carryable, etc.) this would in my opinion be an extra mod (an API mod, which needs to be on the server anyway) and would not land in the STL.

Because you wanted to know what i would like in the STL. Basically everything the normal API does not cover but a modder could need and that could possibly be integrated into the official API.

For example, the official API has a method for saving and loading of config files, but you need a wrapper to ensure the file gets generated. Using the Logger without the logger using string.Format on the string (this causes problems if you for example log an exception which contains the marker '{0}', etc).Another example would be saving of client data on a per world/server basis. At least i need these examples for nearly all my mods.

So basically my vote is, bundle of source files to copy and paste for functionality that doesn't get out of the mod (this would in my opinion be the STL). And dll's for functionality that gets out of the mod, like interfaces, etc.

 

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.