Jump to content

Photo

Full support for modding Empyrion with features comparable to those for Skyrim?

empyrion modding yaml json extensions

  • Please log in to reply
7 replies to this topic

#1
VulcanTourist

VulcanTourist

    Canary in the coal mine

  • Supporter
  • PipPipPipPip
  • 1,889 posts

NexusMods currently hosts a sub-site for Empyrion: Galactic Survival, but most of its content isn't modding in the correct sense, as most of the "mods" hosted are (Steam) Workshop items constructed by players IN-GAME, rather than changes to the game itself.  The game does support modding, however, and while it was initially quite rudimentary it is currently more robust.  However, modding the game both early and current consists of making alterations to data structures contained in JSON- and YAML-like text files, and there is no provision whatsoever made for keeping mod changes separate and distinct and merging them at runtime.

 

Is the extension system of Vortex flexible and robust enough that an extension could be created to manage and merge mods consisting of groups of these data properties from one or more files, including conflict detection and resolution?



#2
Nagev

Nagev

    Newbie

  • Staff
  • Pip
  • 10 posts

Hi VulcanTourist, short answer is yes - Vortex provides users with a file-based conflict detection/resolution system that allows them to select which file "wins" the conflict through our application's interface; and we do provide file merging functionality which can indeed be used to merge data structures together - a good example of how this is done can be reviewed in our Dragon Age Origins extension where we're merging XML elements. The extensions themselves can be written in JavaScript or TypeScript which automatically gives you access to the built-in JSON parser, but in the case of YAML files we don't currently have a YAML parser module pre-included, but nothing is stopping you from including a parser script like js-yaml.js with your extension.

 

and there is no provision whatsoever made for keeping mod changes separate and distinct and merging them at runtime.

 

Did I read this correctly - does your use case require merging to occur during game runtime ?

 

Please note that the extension developer is responsible for resolving any data structure level conflicts in his merging logic.



#3
VulcanTourist

VulcanTourist

    Canary in the coal mine

  • Supporter
  • PipPipPipPip
  • 1,889 posts

Hi VulcanTourist, short answer is yes - Vortex provides users with a file-based conflict detection/resolution system that allows them to select which file "wins" the conflict through our application's interface; and we do provide file merging functionality which can indeed be used to merge data structures together - a good example of how this is done can be reviewed in our Dragon Age Origins extension where we're merging XML elements. The extensions themselves can be written in JavaScript or TypeScript which automatically gives you access to the built-in JSON parser, but in the case of YAML files we don't currently have a YAML parser module pre-included, but nothing is stopping you from including a parser script like js-yaml.js with your extension.

 

and there is no provision whatsoever made for keeping mod changes separate and distinct and merging them at runtime.

 

Did I read this correctly - does your use case require merging to occur during game runtime ?

 

Please note that the extension developer is responsible for resolving any data structure level conflicts in his merging logic.

Thank you for the encouraging answer.  I'll have a learning curve to accomplish such an extension myself, but I may find others in the Empyrion community who are readily capable of doing it.

 

Regarding your question about runtime merging, I may not have communicated what I meant very well.  Skyrim, for example, has an intrinsic ability to load multiple ESP files containing some of that game's data structures, and further it has a means of establishing a load order precedence between them to create a rudimentary conflict resolution.

 

Empyrion has NONE of that: it knows how to load ONE each of specifically named and located .ECF and .YAML files.  Any modding that is done requires that the changes be made directly in those files.  The only exception to this are "scenarios", which are like an alternative data set to be loaded but, again, there is no provision for loading that data from multiple arbitrarily named files with precedence to resolve conflicts.

 

So, having multiple mods for Empyrion that might alter the same properties in the same files would require that the extension itself be able to merge these mod files together with the base game data files whose data they alter with some sort of conflict resolution.  It's an extra order of complexity that the built-in extension for Skyrim doesn't require because the game itself handles it.  In this instance, the entire process must be external to the game.

 

Does that change your answer at all?



#4
Nagev

Nagev

    Newbie

  • Staff
  • Pip
  • 10 posts

Thanks for clarifying - and yes a Vortex extension is able to cater for your game's modding requirements, and will merge data structures from multiple mod files into the specifically named .ECF/.YAML game files whenever the user deploys his mods, but please keep in mind what I said in my previous post - any data structure level conflicts (i.e. whenever 2 mods modify the same property) will have to be resolved by the merging logic written by the extension developer. The developer would have to register the merge using the extension context object we forward to dynamic extensions.

 

If load ordering is also required, we've recently developed an improved file based load ordering API which will be released with Vortex 1.4.x. The new API can be used during the merge to ascertain which mod has higher priority (users can organize their mods via a drag-and-drop page); I'm currently creating a usage document for it and can post you a link to it once it's done.



#5
VulcanTourist

VulcanTourist

    Canary in the coal mine

  • Supporter
  • PipPipPipPip
  • 1,889 posts

This sounds very promising.  Currently the NexusMods site for this game is a waste of space, as there's no practical facility for using more than one mod (file) at a time and the majority of the "content" is just in-game construction projects and not mods.  A Vortex extension that added functional modding to the game would give the site a functional purpose and players a reason to visit.  Right now they have no reason at all to visit here instead of the Steam Workshop for the game.



#6
zaphodikus

zaphodikus

    Stranger

  • Members
  • Pip
  • 3 posts

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.

  1. 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
  2. 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.
  3. 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.)


Edited by zaphodikus, 20 November 2020 - 06:17 PM.


#7
rmm200

rmm200

    Faithful poster

  • Members
  • PipPipPipPip
  • 2,113 posts

Really good quality of posts on this one. Good job all - makes the forum a lot more useful.



#8
VulcanTourist

VulcanTourist

    Canary in the coal mine

  • Supporter
  • PipPipPipPip
  • 1,889 posts

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.

Well met again, zaphodicus. I don't think that Empyrion scenarios necessarily pose a threat, since if the extension is made aware of them then separate Vortex profiles can be created to target and manage mods in each one, as well as the default singleplayer dataset.  In other words: one "scenario" - default or otherwise - per profile, but multiple profiles possible.  Part of the extension development process will be getting up to speed on the features and capabilities of Vortex, and how those can be leveraged.


Edited by VulcanTourist, 22 November 2020 - 12:25 AM.






Also tagged with one or more of these keywords: empyrion, modding, yaml, json, extensions

Page loaded in: 1.048 seconds