zaphodikus

Greets, Heya there VulcanTourist. This is a cool idea - the way we are describing this to me, as someone who does not know the nexus system at all, is that we need to write our own implementations in javascript/typescript and then things may well start slotting into place. I have coded a lot in a previous lifetime, but not JS, but nothing stops me from trying from the sounds of this. Basically the pain is this. The Empyrion game supports configurations or scenarios, which live in their own folder tree, so a player using a mod manager like nexus would only end up breaking their chosen scenario when we merge mods into it, not the entire game, other scenarios will carry on working unless they mod the main scenario, and even then it's not really all dead. So the manager would need to find the user's chosen "config" to start off The game uses YAML, and that's as common as, well not unicorn poop, so that's probably only a case of implementing the plugin bits. And designing a strategy to merge multiple mods and handle conflicts somehow. I'd need to design that as I go I guess. The game uses JSON, but not the kind that Java generates, as a retiring programmer, this has been the most embarrassing software engineering joke of all time, new standard comes out and nobody adopts it fully.... but it is serialisable in my experience. With some massaging. Same problem with detecting JSON conflicts at merge time as with the YAML needs sorting out.It's a huge job I'm sure. I'm only now starting to get up to speed in JavaScript too. I don't think we need runtime merging/loading etc. I will come up with some kind of markup that will let us figure out how to deal with cases where the same property is affected by 2 mods. Load ordering may be an easy way out, and I suspect will help us here. Baby steps I guess. I better install Nexus again. (Not even sure I can trust this Vulcan, maybe I should test this. Hey VulcanTourist ; what are the odds of mission success looking.)