Versioning, iterative design and integration (for crafts and missions)

[Vl3d]

Hello! This subject has been a lot on my mind since I started playing KSP because I've always found myself wasting a lot of time designing unique upper and booster stages for my payloads instead of just slapping on a previously used assembly. I feel like there should be some better assembly building gameplay mechanics and incentives to guide the designing, building and integration steps towards an easy to use iterative process. Allow me to explain:

What we have in KSP1

VAB / SPH have gameplay features that allow us to save our designs:

1. Saving craft files in folders
   • Saving with distinct folder roots for VAB and SPH
     • this is a problem when you have a structure like the one below
     • it also messes with the orientation
   • Craft files can be manually overwritten
     • although the path to the file is not loaded automatically and if I want to overwrite I save I have to point to the appropriate folder every time I load the craft, otherwise it saves in the root folder - I feel like this is a bug;
   • We can of course create folders that are the basis for our organizational choices - I like to separate them initially into:
     • Craft designs:
       • Prototypes
       • Structural assemblies
       • Planes
         • Fighter
         • Space
         • Cargo
         • Other
       • Rockets
         • Boosters (by weight to LKO and diameter)
         • Upper stages (by weight to solar orbit and diameter)
         • Mothership propulsion elements
       • Space Stations
       • Rovers and vehicles (by size, number of passengers, purpose - science, fun or utility)
       • Manned exploration
         • Landers
         • Return capsules
       • Unmanned exploration
         • Deep space / fly-by probes
         • Orbiters
         • Landers
         • Return missions
       • Satellites
         • Science / mapping
         • Communication relays
       • Fuel
         • Tanker stages
         • Refineries
         • Wheeled transports
       • Pods
         • Living pods
         • Tourist pods,
         • Science pods / labs
         • Escape / transport pods
         • Other
     • Missions (the rockets / space planes I actually launched): with a folder for every celestial body, in orbit or landed + asteroids / comets
   • As you can see things get very complicated and there is potential for overlapping functions, sizing problems and other issues
   • All of this does not even touch on the problem of design versioning and evolution - this adds another whole new level of complexity to the issue
   • Of course a very big problem is that if I save the craft as a mission and I change or improve something after mission failure or after returning from the launchpad.. then I have to go back and change that exact same thing in the original assembly design file.
2. Saving subassemblies
   • This theoretically should be straightforward but there are some issues:
     • The root part mechanic makes it complicated
     • All subassemblies are in the same "folder"
     • When overwriting its difficult to change the description if the design changes, sometimes its better to write everything anew
     • I have to search through and update the subassemplies every time I change something in the mission / craft design files
     • I have to go to the subassemblies tab, its extra effort

What we need in KSP2

• We desperately need a better way of creating iterative designs, group them by families and separate them by version
• Craft versioning system (like GIT, to track evolution of specific craft models according to part and science progression)
• Missions and designs should be separate abstractions, missions should contain design versions
• Changes to designs should cascade into missions that use that design version
• We need some kind of default structure for the craft designs.. like the one I described above, otherwise players will take ages to become efficient in organizing all their stuff

What has been confirmed for KSP2

• Saving a workspace containing multiple craft assemblies

Can you please help with other ideas? I think its a very important topic.

Edited June 25, 2022 by Vl3d

[Ember12]

One could have a basic sorting system for assemblies, like the "Prototypes, structures, planes" thing you proposed, with players free to create their own subcategories.

5 hours ago, Vl3d said:

Changes to designs should cascade into missions that use that design version

I'm not sure this is a good idea, because changing a design without seeing what the change did could cause issues.  Like, if you give a booster taller side stages, they might end up inside a wider upper stage.  This would also be nearly impossible without a root part mechanic

[Vl3d]

I feel like this topic should not be forgotten and should be discussed for KSP2 EA. It pops up everywhere. Workspaces and assemblies (grouping) are some of the most important and fundamental changes compared to KSP1. It's so important to have an easy way to do iterative designs and craft families.

Also this:

Also give us git for rocket designs please!

Edited November 4, 2022 by Vl3d

[poopslayer78]

For KSP1, I copied my .craft files between the save game folder and a git repo.  This is one reason why I'm hoping a native Linux version of the game is eventually released.

That said, I think you have some great suggestions here.  Most people won't be using git and even if they know how it's still quite tedious, so having good in-game organization for craft and sub-assemblies would be nice.

[GoldForest]

On 6/25/2022 at 5:30 AM, Vl3d said:

What we need in KSP2

• We desperately need a better way of creating iterative designs, group them by families and separate them by version
• Craft versioning system (like GIT, to track evolution of specific craft models according to part and science progression)
• Missions and designs should be separate abstractions, missions should contain design versions
• Changes to designs should cascade into missions that use that design version
• We need some kind of default structure for the craft designs.. like the one I described above, otherwise players will take ages to become efficient in organizing all their stuff

What has been confirmed for KSP2

• Saving a workspace containing multiple craft assemblies

Can you please help with other ideas? I think its a very important topic.

I think the folder system works just fine, if you want to make iterative designs, just save them the craft file as "Jool Spaceplane 1.0",  "Jool Spaceplane 1.1", "Jool Spaceplane 1.2 (Science focus)" Though, I will admit that the save system could be improved. It lags out badly once you get past 100 craft or so.

Again, just make separate saves of the same craft. 1.0, 1.1. 1.2, 1.1 science, 1.1 cargo, etc. Besides, some people make 100s of design changes to a single craft, and saving ALL those files is going to use up space. Better to just name the craft 1.#, overwrite the save with any future changes, and if you want to go back to a certain look, just remake the plane how you want. No need to save unneccsarily large number of versions which most will never be used again.

Why keep an obsolete version of a craft for a mission? If you add new science modules to a spaceplane, why go back to the version with the old modules? Makes no sense. Just overwrite your craft save and be done with it. If you want the old science back on the plane, put it there. No need to use up space.

I don't understand this one. Do you want it to change craft that are in flight, or simple change the craft in multiple save locations? Either, way, that's not a good idea. I mean, what if you don't want your Jool mission craft changed because you saved over your Duna craft? Or you don't want Save 1 to effect Save 2?

I disagree. It should be up to the player to design his or her own folder structure. What works for you might not work for the next person. Some people like no structure at all. Some people go ballistic with folder structures. We're all different. A default system should consist of how KSP 1 handles it. VAB and SPH folders. That's it. From there, it should be up to the player. 

Edited November 4, 2022 by GoldForest

[Vl3d]

31 minutes ago, GoldForest said:

Why keep an obsolete version of a craft for a mission?

If we use versioning the current working versions of designs are displayed in a craft family list and every previous iteration is hidden in the "git" like tree.

31 minutes ago, GoldForest said:

Do you want it to change craft that are in flight, or simple change the craft in multiple save locations?

I want to be able to just import my 100 ton to LKO booster into the current workspace and just slap it on my new upper stage.

I want each assembly (craft design) to be imported into the current workspace with just 1 click or drag and drop when needed.

I want the option to cascade improvements to parallel designs that use a specific assembly. So I can just duplicate a Jool mission workspace and just replace the science module on the upper stage but have everything else use the latest and greatest versions of my designs.

And then I want to see how everything evolved in orthographic view.

... and I also want to be able to weld / merge / group parts logically, while keeping the volume/mass ratio realistic. You want really efficient CPU usage? Allow us to merge parts and create a new (structural / tank) part from that (but keep the archive in an assembly / craft file so we can un-merge later). Allow us to build custom command pods in the editor, without having to be modders.

Edited November 4, 2022 by Vl3d

[poopslayer78]

5 minutes ago, Vl3d said:

every previous iteration is hidden in the "git" like tree.

For single player, I think a git tree would be overkill and version numbers would be preferable.

For multiplayer, having the ability to "merge" and "branch" craft could be useful, as long as it's simple enough for non-git users to learn comfortably.  I'm using the term "merge" very loosely, it would probably be as simple as a full craft replacement or adding a sub assembly to a workspace.

To clarify, I'm not saying single/multi player should have different versioning systems, I'm saying that single player may get some extra features that are motivated by multiplayer.

28 minutes ago, GoldForest said:

Why keep an obsolete version of a craft for a mission?

GoldForest has a point here, once you successfully optimize a craft there's usually no reason to go back.  There are a few use cases where multiple version are still useful:

1. You make a design change but won't know if the new craft is better or worse until after flying a (potentially long) mission, so being able to roll-back versions after testing is useful.
2. Occasionally, you may want to look back on the evolutionary path of a complicated spacecraft and reflect on what you've learned between versions.

36 minutes ago, GoldForest said:

It should be up to the player to design his or her own folder structure. What works for you might not work for the next person.

Agreed

[GoldForest]

56 minutes ago, Vl3d said:

If we use versioning the current working versions of designs are displayed in a craft family list and every previous iteration is hidden in the "git" like tree.

I want to be able to just import my 100 ton to LKO booster into the current workspace and just slap it on my new upper stage.

I want each assembly (craft design) to be imported into the current workspace with just 1 click or drag and drop when needed.

I want the option to cascade improvements to parallel designs that use a specific assembly. So I can just duplicate a Jool mission workspace and just replace the science module on the upper stage but have everything else use the latest and greatest versions of my designs.

And then I want to see how everything evolved in orthographic view.

... and I also want to be able to weld / merge / group parts logically, while keeping the volume/mass ratio realistic. You want really efficient CPU usage? Allow us to merge parts and create a new (structural / tank) part from that (but keep the archive in an assembly / craft file so we can un-merge later). Allow us to build custom command pods in the editor, without having to be modders.

KSP 1 can already bring craft files from other saves into the one you're working on, and I imagine KSP 2 will do the same thing. And IIRC, the devs did confirm that your workspace will remain unchanged when you load in a new craft, so you can load up multiple craft. 

As for versioning, again, too much space for such a small feature. The only way I see this being a thing is cloud saves to either steam or a dedicated Intercept server.

38 minutes ago, poopslayer78 said:

For single player, I think a git tree would be overkill and version numbers would be preferable.

For multiplayer, having the ability to "merge" and "branch" craft could be useful, as long as it's simple enough for non-git users to learn comfortably.  I'm using the term "merge" very loosely, it would probably be as simple as a full craft replacement or adding a sub assembly to a workspace.

To clarify, I'm not saying single/multi player should have different versioning systems, I'm saying that single player may get some extra features that are motivated by multiplayer.

GoldForest has a point here, once you successfully optimize a craft there's usually no reason to go back.  There are a few use cases where multiple version are still useful:

1. You make a design change but won't know if the new craft is better or worse until after flying a (potentially long) mission, so being able to roll-back versions after testing is useful.
2. Occasionally, you may want to look back on the evolutionary path of a complicated spacecraft and reflect on what you've learned between versions.

Agreed

I understand that versioning has some pros, but they are so little in comparison to the cons, like space. 

I think the best solution to 1 and 2 is just make separate saves yourself. Jool Moon Lander 1, 2, 3, 1.1, 1.2, 1.3. 

Alternatively, if we put a hard limit on craft versioning, then it wouldn't be a problem. Say, 5 versions or so. 

[Ember12]

2 hours ago, poopslayer78 said:

For single player, I think a git tree would be overkill and version numbers would be preferable.

I disagree with this.  One way I see a git tree being useful is for my launch vehicles; especially in career mode I have a standardized system of launchers, for different payloads and destinations.  I've had to label them as things like "Universal Launcher 2-8-1" meaning a 2.5 meter core with 8 1.25m side asparagus stages.  (Don't even get me started on what I have to do with SRBs.)  A tree organization would be a far better way to organize them.  This would also apply to rovers, where they often (at least for me) have the same basic design but vary in terms of experiments carried, power generation parts, number of wheels, etc, and you want a good way to find the one you're looking for.

[poopslayer78]

1 hour ago, Ember12 said:

One way I see a git tree being useful is for my launch vehicles; especially in career mode I have a standardized system of launchers, for different payloads and destinations

I agree with you Ember12, having standardized/modular sub-assemblies is something I want as well.

When you say "git tree" it seems like you're actually talking about a "directory hierarchy" where you can have folders and sub folders with different variations of your design.  When I used the term "git tree" I meant the directed flow graph that gets generated when you do forks & merges on a single file/craft over time... which now that I think of it isn't really a "tree" it's more of a DFG but I digress.

Anyway, just wanted to make sure we're talking about the same thing.  I love the idea of building flexible boosters and modules that can be easily imported for various payloads.

[Ember12]

50 minutes ago, poopslayer78 said:

When you say "git tree" it seems like you're actually talking about a "directory hierarchy" where you can have folders and sub folders with different variations of your design.  When I used the term "git tree" I meant the directed flow graph that gets generated when you do forks & merges on a single file/craft over time... which now that I think of it isn't really a "tree" it's more of a DFG but I digress.

I may have misunderstood what you meant by git tree.  What I am thinking of is an organizational array of manually saved files.  Going back to my rover example, for instance, there could be branches for high, medium, and low gravity, each of which has sub-branches for power generation method, each of which has sub-branches for scientific payloads.

I agree though that trees can get messy quickly.  An alternative/supplement might be tags for crafts and sub-assemblies.  So if you are looking for a rover to  send to Tylo, you could search for "rover non_solar mid_gravity" or whatever.

Edited November 4, 2022 by Ember12
Clarity

[Vl3d]

How will you use workspaces (the new VAB feature) to organize your assemblies and craft families?

I shared some thoughts a while back on the subject.

Now I'm wondering if we should have a workspace for sattelite / lander / rover types and another for stage 1 / 2 ... or we should have workspaces dedicated to specific destinations? I wonder how mixing workspaces will work also.. you just import everything in a new workspace? Or you select assemblies? Is there craft versioning and are changes to an assembly applied in cascade to all used versions of it?

 

[magnemoe]

I'm pretty sure you merge two workspaces and then remove the items you don't need.  Say you have rovers in one, practical as you can test drive them. 
If you then want to add one to an lander you merge rover workspace, pick the rover you want and move it to lander then remove the rover workspace. 

I bit like in KSP 1 but more streamlined. 

[Vl3d]

13 minutes ago, magnemoe said:

I'm pretty sure you merge two workspaces and then remove the items you don't need. 

Why would I have to import a workspace with 15 complex satellites and another workspace with all my 10 boosters into a workspace containing all my 20 Mun missions? We should be able to pick specific assemblies from a workspace to import...

[James Kerman]

Overlapping topics have been merged.

[Scarecrow71]

I'd like to ask why people keep asking "What are you going to do with x" or "How are you going to deal with y".  The simple answer here is that nobody yet knows how anything is going to function, so asking how people are going to deal with it is pointless.  Why?  Why the constant threads asking about stuff we don't even know about yet?  Why not wait until the game is out and then ask "How did you deal with this feature when you got your hands on the game"?

[Snafu225]

I really don't get it and I tried about half an hour trying to figure out how the system you propose isn't just a complicated, semi-automated version of @GoldForestsuggestion: Naming a craft "xxxxx 1.5"

How's that even supposed to work? How is the editor supposed to know which mission/planet/whatever reason the craft is used for? For that to work there has to be a menu in which you choose all that stuff and then you have to tell it that tilting the wings back 5° is maybe not a new version but tilting it 15° is, or adding another fueltank isn't but adding two is. At this point you'll be clicking more/the same amount to get the same effect. The only difference? You click before building and not afterwards while saving and dev time was used on scripting it.
If you want to see an iterative progess. Just save it everytime before you test it. Done.

Features like merging etc already exist in KSP 1 and work fine. 

So in my oppinion that's nothing KSP "desperately needs" but something you'd like. 

[Vl3d]

3 hours ago, Snafu225 said:

How is the editor supposed to know which mission/planet/whatever reason the craft is used for?

Mission / journey planner for the launch vehicles in the workspace! It's a system that was confirmed to exist, but we don't know much about it.

5 hours ago, Scarecrow71 said:

Why the constant threads asking about stuff we don't even know about yet?

Why not think about what the game could be? It's interactive and interesting.

[Snafu225]

45 minutes ago, Vl3d said:

Mission / journey planner for the launch vehicles in the workspace! It's a system that was confirmed to exist, but we don't know much about it.

Was it confirmed to read minds too? Just pulling your chains here, but even with that mission planner, you'd still have to tell that system which mission/where you want to go.  Wouldn't be more or fewer clicks than selecting the "Manned/Minmus/Lander" subfolder. Name it "MML - XL - S 6k" - Manned Minmus Lander - Xtra Large - Science Variant - 6000m/s dV. Doneski.

Quote

• .....there is potential for overlapping functions, sizing problems and other issues
• All of this does not even touch on the problem of design versioning and evolution - this adds another whole new level of complexity to the issue
• Of course a very big problem is that if I save the craft as a mission and I change or improve something after mission failure or after returning from the launchpad.. then I have to go back and change that exact same thing in the original assembly design file.

And I still don't really get the real issue here? Stuff will still overlap if it's sorted by missions.

With the file structure you presented, it's really easy to find what you're looking for, even if you're not the "author/maintainer" of it as it's straight forward. 
Having it segmented after mission names would make it harder in my oppinion: Oh shoot, was it "Exploration 4 or 5 which had that specific rocket design I'm looking for? Or was it "Biome studies over the flatlands on Minmus"?

Also, I don't really get the red part. When I change something on a craft and it fails and I go back, the change is still there. Unless you're talking about not changing it in previous versions or subassemblies, then I don't really get it, because then you'd just advance the version # by one and save it. Tada, iterations.

 

Edit: Additionally it's still unanswered how iterations should work as an automated system. How does it know that whatever you changed is now a new version or an evolution or a fusion or a new subversion?

Edited January 19, 2023 by Snafu225

[Skorj]

At first my thought was "there's no way the dev team is going to re-invent git", but then I realized they could just use git. Still need a UI for it, which isn't trivial, but is at least approachable.

As far as automation, the game could never guess right, but that's no problem, you just need 2 UI controls: "save" and "save as new version".  Have the latter default to bumping a version number, but give you the choice of a more informative name.   That way a new version can just be 2 clicks if you don't need more than a version number.

[Scarecrow71]

16 hours ago, Vl3d said:

Why not think about what the game could be? It's interactive and interesting

Because we have no idea what is coming.  Sure, we can speculate on what we'd like...but that is entirely different from the multitude of threads you have started asking how people are going to tackle some situation.  We don't know what the game will be, or how it will react, or what situations will be there.  Can't we just wait until 2/24 and ask the questions when we do know?

Edited January 20, 2023 by Scarecrow71

[Snafu225]

10 hours ago, Skorj said:

As far as automation, the game could never guess right, but that's no problem, you just need 2 UI controls: "save" and "save as new version".  Have the latter default to bumping a version number, but give you the choice of a more informative name.   That way a new version can just be 2 clicks if you don't need more than a version number.

Don't get me wrong I'm all for automation and QoL stuff, but bumping the version number without it is 

1. Click craft name field
2. Backspace
3. New Number
4. Profit

and the name can still be as informative as you want it to be.

I agree a button like that is probably scripted rather easily though the impact is also questionable.

A far more useful implementation would be the ability to add "tags" to a craft and have a search feature that can filter with those tags. That could help searching for specific stuff, but also only useful once you have a huuuuge number of crafts.
Something like this mod did:

For a few people this seems to be really handy though looking at the amound of replies, I reckon few people actually need (needed) it.

[linuxgurugamer]

1 hour ago, Snafu225 said:

Something like this mod did:

For a few people this seems to be really handy though looking at the amound of replies, I reckon few people actually need (needed) it.

Just an FYI, a new feature of this mod recently rreleased is that it will save a copy of every edit that you make, so you can go back and look at the history of how a craft evolved, and obviously use an older one if you feel you went down the wrong path

[Vl3d]

57 minutes ago, linuxgurugamer said:

a new feature of this mod recently rreleased is that it will save a copy of every edit that you make, so you can go back and look at the history of how a craft evolved, and obviously use an older one if you feel you went down the wrong path

wow.. thank you!

[SolarAdmiral]

One feature I'd really love is for ships to have both an individual name and a class name. Like I can build and save an Excelsior Class Cruiser, and launch one named the Enterprise. Especially by the time we get multiplayer. So me and other players can see both names on it in the map. "Enterprise - Excelsior Class"

Edited January 20, 2023 by SolarAdmiral