With server mods looming, how should we add them to the repository? We can either: Add them to the same directory and modlist.json as client mods Add them to a new directory and modlist.json My money is on the latter, because the former introduces all sorts of issues in the transition from old versions of the UI. Plus the latter mirrors server mods being in a separate directory in the game.
It have to be a separate json, for an easier PAMM migration. Maybe servermods.json if we want separate json for client & server mods, or modlist2.json for a new version which store the targeted context. But for me, the main point would be to stop storing zip packages on pamods.github.io, but using the github repository. I plan to make a PoC in Atom Shell PAMM quickly.
Oh, heh. I hadn't even considered backward compatibility. The way I implemented server mods is that it just reads the current modlist.json, but expects the context field to be set to server for server mods. I haven't released that version yet though. But thinking it over, separate json's for client and server mods would probably be better. What do you mean by PoC? A quick search revealed piece of crap, person on cocaine, pen of chaos, but I doubt you mean any of those. So, instead of the download url in the modlist.json, you would use a link to that person's GitHub repository?
Exactly. We could use urls like https_//github.com/pamods/servermod-murderparty/archive/master.zip or https_//github.com/pamods/servermod-murderparty/archive/be866e556bd2368937708dcf5a921fc8c8dea8bf.zip. Maybe we could even implement some automatic version checker like pamm-atom using the package.json : no need for updates on the modlist.json after the first publish, it would not be a huge loss if the version was not visible in the "online" list.
Ah, so to check if there are updates for all of the mods, pamm would have to get that info from each GitHub repository of every mod author? And every author would have to have a modversion.json file there? In that case, the JSON would have to look something like this. Code: { "myfirstmod" : { "version": "1.0", "url": "https://github.com/...........zip" }, "myothermod" : { "version": "1.1a", "url": "https://github.com/...........zip" } } Is that what you mean?
The first change would be to be able to use whatever url we want to target the zip package and it's just a matter of whats is in the url property, it would not change how updates are detected (modders update the modlist). By this way, we could use direct link to branch/commit/tag or even releases download on github. But if people still use the modlist generator, it will have to be fixed to not discard mods stored elsewhere, and PAMM will have to properly handle packages with more than one mod, or wihtout a subfolder. The 2nd change would be to allow "non package" url aka https_//github.com/pamods/uimod-scaleui/tree/master/scale-ui. The modlist will not store the version, and the version would not have to be displayed in the online list. We could detect updates on installed mods by checking https_//github.com/pamods/uimod-scaleui/raw/master/scale-ui/modinfo.json changes. We could also stop having both identifier & id properties, only the first one is needed, the other is a PAMM only requirement.
Having only one identifier would be neat. Updating a modlist.json manually with pointing it at a packaged zip file could work. The question is do we still need a modlistgenerator that way ? Cause then you could let PAMM read all modinfo.json's remotely ? Either way is fine by me.. I propose for now to start making a modinfoserver.json (I'll update modlistgenerator to look at servermods folder on the github and then creates a modinfoserver.json). So at least you can easily do an update to PAMM and have it distribute client / server mods....
You can have a look on the "servermods.json" currently used by PAMM (Atom Shell) . Just an array, no id field, and url to external archives. It can be easily updated without cloning the repo through the github edit interface. https://github.com/pamods/pamods.github.io/blob/master/servermods.json The modlistgenerator should probably be more an utility to add/remove mods from the lists instead of regenerating the whole list every times.
