-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: Optional mod provided metadata #416
Comments
Recently had a discussion on Irony discord in regards to something like that. TLDR; What is good such a feature if community will not use it? It's going to be tedious to advocate such a feature and modders won't certainly tell people please use Irony. Just look at CWTools, lots of users very few contributors. |
While that is true for CWTools there are a couple of reasons I don't think it applies to this. secondly improving CWTools is more complicated than adding more metadata is, adding stuff to tools required a basic level of coding knowledge and interesting learning how the back end works. whereas the metadata can be made far more simple. lastly, updating isn't as needed, once a mod has its relations added unless it is updated for more compat the part of the file don't need to be touched, unlike CWTools that any file can be needed to be updated when pdx updates the script so even if there is a low amount of updaters its less of an issue. also, the vast majority of users use the main mods e.g. gigas, uiod or NSC so only a couple of mods relations would be needed to be super focused on and amount them most take steps to avoid overwrites so reducing the amount of work needed further |
Heck, I've tried to take a look at contributing to cwtools myself, and despite a pretty decent level of programming experience I can't make heads nor tails of F#. I'm at the point where I am seriously considering trying to write my own tool... As for the metadata, I think it'd probably see a higher level of adoption, since really it's not a whole lot of work to add this kind of data to a mod and many authors are willing to add larger compat stuff. I bet even more so if it means fewer bug reports due to users ordering things incorrectly. I'm certainly willing. (Hi, I'm currently the lead on Gigastructural Engineering) |
I'm not talking about CWTools source code (main repo) I'm talking about the stellaris config. Without it CWTools will not really be what it is. I'm using that as a baseline comparison. In the words of the CWTools author: Stellaris cwtools config is mostly maintained by a pdx employee. HOI4 is maintained by some really large modding groups. Other games lack many of the resources that these 2 games have, Victoria 3 seems to be kicking up (at least Dayshine kickstarted it). |
To add from my perspective, pretty much all the mods I am familiar with advocate for using Irony over the Paradox launcher due to the multitude of issues the Paradox launcher seems to cause. I can't speak to the CWTools issues, largely because I don't really do much in the paradox scripting language (I generally try to avoid it) and don't know it well enough to contribute to any syntax tools. I think the simplest approach would just be to add a file that mods can include to provide metadata, but in the Rimpy approach, where there is a "community" database is where I personally am most interested in the possibilities, largely because I think there are significant possibilities for automated analysis and automated testing. For example, the capability to batch modifier updates was added in Stellaris 3.0.1, so any mod that uses that is incompatible with any older version. One of the things I've been interested in doing is building a "performance baseline" testing mod, something that will allow an automated test to run on each new version of the game and baseline the performance of a series of scenarios that have been or are currently problematic (IE: measuring the frame rate with a large number of fleets in a single system); basically, having a setup that can have test cases added to it and be performance measured repeatable over time against each version of the game to track improvements or regressions. I think one of the rather easy things to add to this would be taking popular mods (or mod combinations that have been identified as problematic somehow) and doing either a performance baseline or a functionality baseline test (IE, does combining mod x and y cause the game to crash at startup). Ultimately I think you are correct, in that this is something that the games itself need to require, but I don't think that will happen without an existing implementation that is showing usefulness. |
OK. So full disclosure about what Irony was supposed to have when I started the project. It's been mentioned briefly before but never got from the ground (lack of help) so I pretty much shelved it. It's also the main reason why I'm still hesitant to pick up anything related to it. I've never played the games you're referencing but I did play KSP. And my inspiration(s) come from there. Irony was intended to have a similar db such as this but based upon CKAN (comprehensive kerbal archive network). Given how Irony came in late to the scene (3-4 years) it was difficult to advocate for such a feature. CKAN already has metadata which could have been repurposed for Stellaris ie. requirements, min\max version, recommends, conflicts with and so on. Some metadata of course is missing but you get the idea: https://github.com/KSP-CKAN/CKAN-meta/blob/master/APPLE/APPLE-1-1.1.9.ckan Once this was solved then there would have been phase 2, which would have been based on ModuleManager: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax
The syntax states: Patch country type and (swarm) before mod-id1 and after-mod-id2 and add the following line(s). Pretty sure you all understood what it means but just in case. This whole logic should have (hope) reduced number of compatibility patches. This was the reason why I wrote 2nd iteration of Irony's parser (a general dumb parser) due to many reasons. One of them due to CWTools edge cases (not understanding how to parse HSV - I think), failing to parse certain name scripts. And more importantly to allow the development of this feature since most likely the paths of Irony and CWTools would diverge therefore a dedicated parser would be needed. The idea was abandoned due to arguments:
And we're here at the present. |
I think if we can convince major mod dev (leads) to adopt this format, the community will follow suit over time. (TTFTCUTS could provide some insight in how feasible it would be to adopt it in Gigaengineering/how much resistance there would be?)
CKAN does not download mods. CKAN uses SteamCMD to download mods (and also helps the user to set SteamCMD up). SteamCMD is covered by the Steam Workshop Agreement AFAIK, so there should be no legal issues involved. (I am not a lawyer, this is not legal advice.) Have you talked to HerbaruSan about this by any chance? He can probably give you more insight on the issue. |
Wrong. It does:
Also, I haven't spoken to anyone about anything. |
I think the scripting-patch-language that you mention would be going much further than necessary, and would likely have issues with adoption as you mentioned; but I don't think a simple file that points out recommended load order and incompatibilities between mods would. As for downloading mods, personally I don't think that's very important, the current functionality of Open in Steam or Open in browser works fine. |
My mistake. RimPy does that in any case. Are you considering reaching out? I don't see a reason why they would refuse a short exchange on information. |
Not really. This feature is not on the roadmap and all the theoretical knowledge is pretty much acquired. Lastly you just don't drop unannounced to people you've never met and start bothering them with random questions (CKAN etc). |
so i feel like theres 2 ides at play in this post #416 (comment) Not many people want to use third party tools Lack of interest last note it could be possible to have the mod tools in some webpage where someone uploads their list and it orders it for them, removing most of issues 1/2. but that's a lot of extra work for that |
As a modder, I'm interested in providing this metadata. Preferably it could be some form of text file that I include in the root mod directory. I vote for something json-formatted since that is easy to parse in many programming languages, and won't require additional tools to be used by modders to enter the data into an external website (etc). Stellaris files have two priority systems. I often choose to use per-item overrides rather than full-file overrides, and mod load order means nothing to partial overrides. I know Irony provides some levels of game-object conflict detection, but some sort of spec for including that info in metadata is attractive to me. As an example, a modder had to reorder their mods before Irony detected multiple, conflicting overrides for a vanilla building. My mod in question was Building: Aquaponics Farm but I unfortunately don't know the other conflicting mods. |
Is your feature request related to a problem? Please describe.
Stellaris (and other games I assume) needs a better mod metadata format to improve mod compatibility and reduce "support cost" for known issues that can relatively easily be solved. Ideally it'd be up to the game developer to implement such a format, but since they aren't I figured I'd come discuss it here and hopefully could demonstrate the usefulness and "reverse engineer" better functionality into the games.
Describe the solution you'd like
It would be ideal if someone defined an optional metadata file format that mods could include to define:
I think for first pass completely ignoring mod versioning might be the best strategy...
Describe alternatives you've considered
RimPy implements this for rimworld as a "community rule list"... which might also be a useful functionality for mods that chose not to / refuse to provide their own metadata...
Additional context
Similar implementations:
https://wiki.factorio.com/Tutorial:Mod_structure#Dependency
https://rimworldwiki.com/wiki/About.xml
https://github.com/rimpy-custom/communityRules/releases
The text was updated successfully, but these errors were encountered: