We learned in Kerbal that using raw names or strings for part IDs is a bad idea.
From an engineering perspective: Human readable strings as the sole form of object identification does not a robust architecture make.
Yes, I've been bitten by this problem before.
Before the community gets too deep in the weeds with mods, this game needs a better ID system.
Generating GUIDs is cheap, decentralized, and the most common approach used in heterogeneous databases.
With this in place, players can have multiple major revisions of the same mod installed (under different folder names), and all existing parts can still load and function. This also provides an unambiguous way to mark older mod versions as deprecated without having to modify the text or any other maintenance-intensive work.
Misc. Stream of Consciousness:
Add a Version attribute to define an object version.
Add a UseVersion attribute where an object is referenced. If UseVersion is not specified, it is the same as UseVersion="*" (for latest).
Implement wildcard versioning as:
UseVersion="1.*" to mean UseVersion="1.<latest-minor>"
UseVersion="0.1.2.*" to mean UseVersion="0.1.2.<latest-minor>" etc...
applicable only with a UseVersion attribute.
The native filesystem is NOT your friend!
Add some kind of namespace (Namespace node) that allows structured access between mods.
Implement a resource management layer instead of just relying on raw filenames.
Resource nodes within Assets nodes. A Resource node should be the only place a raw filename or path may appear.
The resource management layer should be the only thing that knows or cares about filenames and how IDs resolve to files.
ID -> Resource is a many-to-one relationship.
Resources can be versioned just like anything else.
Virtual Resources are easy to implement here.
Can change the underlying data in a resource at runtime.
Nix like system addins (e.g. gatOS) can expose game assets under a formal "/mnt/ksa/resources" or similar.
Apologies for the prolific editing. I did not feel multiple posts were appropriate here. If there is significant community or developer buy-in, I can draft a formal specification for the above.
From an engineering perspective: Human readable strings as the sole form of object identification does not a robust architecture make.
Yes, I've been bitten by this problem before.
Before the community gets too deep in the weeds with mods, this game needs a better ID system.
With this in place, players can have multiple major revisions of the same mod installed (under different folder names), and all existing parts can still load and function. This also provides an unambiguous way to mark older mod versions as deprecated without having to modify the text or any other maintenance-intensive work.
Misc. Stream of Consciousness:
Add a Version attribute to define an object version.
Add a UseVersion attribute where an object is referenced. If UseVersion is not specified, it is the same as UseVersion="*" (for latest).
Implement wildcard versioning as:
UseVersion="1.*" to mean UseVersion="1.<latest-minor>"
UseVersion="0.1.2.*" to mean UseVersion="0.1.2.<latest-minor>" etc...
applicable only with a UseVersion attribute.
The native filesystem is NOT your friend!
Add some kind of namespace (Namespace node) that allows structured access between mods.
Implement a resource management layer instead of just relying on raw filenames.
Resource nodes within Assets nodes. A Resource node should be the only place a raw filename or path may appear.
The resource management layer should be the only thing that knows or cares about filenames and how IDs resolve to files.
ID -> Resource is a many-to-one relationship.
Resources can be versioned just like anything else.
Virtual Resources are easy to implement here.
Can change the underlying data in a resource at runtime.
Nix like system addins (e.g. gatOS) can expose game assets under a formal "/mnt/ksa/resources" or similar.
Apologies for the prolific editing. I did not feel multiple posts were appropriate here. If there is significant community or developer buy-in, I can draft a formal specification for the above.
Last edited:
Upvote
1
