The discussion on unit_list.json hasn't turned up any ideas on the scale of the negative damage that made the first regen mod possible. So it looks like we'll need an offline solution. I'm volunteering to make the necessary modifications to PAMM-Atom to compose unit_list.json based on the active mods. I want feedback on what interface will be useful to mod authors. I'm considering a couple uses cases: - single unit mods - large additions likes factions (a topic I haven't thought enough about) - total conversions and game modes - ban mods (e.g. no nukes) Proposal: New modinfo.json property, with two optional array properties. Code: "unit_list": { "add_units": [], "remove_units": [] } Example: single unit Code: "unit_list": { "add_units": [ "/pa/units/land/baboom/baboom.json" ] } Example: no nukes Code: "unit_list": { "remove_units": [ "/pa/units/land/anti_nuke_launcher/anti_nuke_launcher.json", "/pa/units/land/nuke_launcher/nuke_launcher.json", "/pa/units/land/tank_nuke/tank_nuke.json" ] } Limited Backward Compatibility If the unit_list property is not specified, this information can also be generated by comparing the mod's unit_list.json with the game's current list. This may have some side effects (e.g. creating removals for new commanders) for out of dates mods, but it's no worse than currently. Another concern would be a mod removing the base spec required by a different mod. (Example: BaBoom requires base_bot) It's also limited in that mods with build bar shadows cannot effectively be combined. Algorithm I'm considering two algorithms for combining the edits. 1. Remove Then Add Apply all removals, then apply all additions. Pros: This addresses the base spec problem by letting mods which add units use the modinfo version to also list required base specs. Cons: Ban mods might not work. 2. Priority Order Pros: Ban mods using the modinfo property could include, for instance, known nukes in mods. Conflicts could probably be resolved by adjusting the priorities of particular mods. Cons: Potential for base spec removal. More complicated to reason about. Assuming mods adopt conventions, we could address most situations. Something like: - Total conversion: early priority - Unit additions: standard priority - Bans: late priority Regardless of algorithm, it looks like it will be good practice to list base specs you depend on, and leave ones you don't need.
Nearly forgot an inconvenient detail: PA has two unit lists, one for classic and one for titans. Possible solutions: - UI element similar to stable/PTE - Standard mods that add or remove the titans units. - Ignore the problem. PA won't be able to load details on units that aren't mounted. I tested hosting a classic game on a titans-licenced copy with a titans-based unit list, but that isn't extensive.
I got messaged a week ago by someone that tried to play GAT on a classic PA install; it crashed his game when he tried to build Titans units. My opinion? Screw those players who refuse to spend $15 to support continued development; I personally don't care if mods break for people who refuse to support the creators of this game.
Then GAT directly depends on Titans. Here I'm only concerned about mods that are classic compatible to begin with.
Anybody want to test this before we unleash it upon the world? Looks like the main issue is just Mereth not having time to test it thoroughly, and it's big enough that there is plenty of room for something to go wrong. I've been running it for a few weeks, but I've really only been testing rather than playing. To qualify, you need to be comfortable replacing the app directory in your PAMM install (or perhaps a copy of PAMM) The main caveat would be that it writes the unit list into the pamm server mod, which may still be present if you switch back to the current stable version. https://github.com/JustinLove/pamm-atom/tree/unit_list
I haven't seen anything this cool for PA and PAMM in a REALLY long time! I am excited for this ingenuity! Sort of crazy how nobody thought of making the PAMM build a unit_list.json from parameters across all modinfo.jsons before. But this is a rather fine solution to have one unit_list.json contain the data from multiple mods that would add individual units but be incapatable with one another.
