[Planning] Community Tech Tree

[Nertea]

If you're new to the thread, check out current work on the tree.

------------------------

As suggested by RoverDude here, now that we have a tech tree editor (any maybe two of them soon) that can handle more complex trees than stock, it might be a good idea to see if a collaborative community tech tree could be designed. Because I like being involved in such a thing, I volunteer to curate and work on it. Can't let Rover have everything.

In my view this would be limited to an expansion of the stock tree, so none of this "unmanned flight first" lunacy ( ). We would try to come up with a nice way of adding high-tech endgame nodes with high science costs and potentially some new branches starting at lower levels.

Off the top of my head, mods that might benefit from this:

• MKS/OKS/RoverDude's huge stack of mods (heh)
  
• Karbonite/Kethane (resource extraction technologies)
  
• Near Future Technologies (nuclear, solar, ion engines)
  
• KSP Interstellar (fusion, really fancy stuff)
  
• Station Science (and other science-instrument mods)
  
• TAC-LS, Snacks (and other life support mods)
  

That's quite a lot of mods, and I can see a huge line of 400 tech nodes stretching into the distance... my approach would be to try and break the contents of each mod into their component areas of research, and either extend existing branches or consider adding new ones where appropriate.

My own stuff will probably be my goto example, so... here's my NFT tech tree extensions.

Javascript is disabled. View full album

Broken down into three main areas of research: ion engines (extension of existing branch), nuclear technology (new branch), solar technology (extension of existing branch). I think if we can ID the areas of research like this for all the mods that want to join a community tech tree, we can figure out what overlaps where and therefore how to keep the additions relatively focused while still trying to take into account the large ranges of mods we could have.

Based on what I have above in that mod list, I can kinda see the following set of vague branches and extensions. Some are very self serving.

• ISRU branch (Kethane, Karbonite, MKS/OKS)
  
• Ion engines extension (NFT, KSPI)
  
• Nuclear engines extension (FTmN AR, KSPI, FTT)
  
• Nuclear power extension leading to fusion (NFT, FTT, OKS/MKS, KSPI)
  
• Life support branch (Life support mods)
  
• Construction extension (MKS/OKS, NFT, FTT)
  
• Solar power extension (NFT)
  
• Science instrumentation extension (Station Science, KSPI)
  
• Doomsday endgame things (KSPI)
  

So I'll open up some questions: do you have a mod that might benefit from fitting into a stock tree? What areas of research does it contain? How many nodes would you like in that area?

Edited October 30, 2014 by Nertea

[RoverDude]

Love it

The options you have up there make sense, with the only distinction off the top of my head being colonization type construction (I'd toss MKS/OKS/Asteroid mining there) and 'Make really big ships' construction (for FTT, 5m+ rocket parts, ELP, etc.)

110% in and will use or adjust to whatever you end up with!

[cvod]

I'm looking forward to this. I had been working on my own tree for mods, but mine definitely didn't start with the stock tree. Can't wait to see what you guys come up with.

Edited November 4, 2014 by cvod

[FreeThinker]

Please use [0.25] TechManager Version 1.1 to implement all Tech modifications

[Streetwind]

I maintain that it's never going to work (for reasons listed elsewhere) but I won't be a Grinch about it Prove me wrong, if you can!

[KaiserSoze]

I see it as a possible. BUT with only a bunch of mods. NOT every mod, and not every personal tree.

But If we can create some kind of "standard" tree or community tree we can be sure that all the mods can add the seal of "compatible with community tree" so that they use only the node included here. and if they need a new node it will be added here, so it doesnt stomp other mods.

giving that we have ORSX (and ORS), and community resources also I think this is possible in this community. At least if we narrow our expectations to only this and leave out people who want very personal tech trees that move everything around.

EDIT: there is also one question I have. This Tech tree should force parts to tech or leave that liberty to other mods? In my opinion this is the main difference between it being use for personal tech trees that move things around (usually to be more "realistic") or create the room for other mods to play.

My vote is for the later: it should only create nodes (with name, icons, cost, etc) as frame for other mods to add their part wherever they prefer. Moving parts should only be done for very specific reasons.

Edited October 28, 2014 by KaiserSoze

[Crater]

Two things.

Firstly, this doesn't have to cover ALL THE MODS. Even if it only brings collaboration to 50% of them, it'll still make life much easier and more pleasant for players who are using a suite of mods that do play nice. And while I can't talk for others, it would certainly influence my decision on whether or not to install a mod if I knew that it wouldn't work well with the other mods that I already had from the suite.

Secondly, it seems that the thrust here and in the Tree Modifier mod is towards the tree.cfg defining the nodes and their interconnection, and the part files defining which nodes they want to be in.

Having this community project as a base would actually make it easier for people who want to create their own completely independant trees, since it would make it possible to target the parts in various nodes with catch-all ModuleManager scripts to push any "other" parts into spots on their own tree after they had moved all the specific parts they cared about. This has been the biggest problem with custom trees in the past - you not only have to play with the creator's tree, but also with pretty much exactly their set of other mods, or else parts are missing, or weird nodes appear past the end of the tree, or stuff is in bizarre places.

This project could at least help focus on a baseline that could help reduce that sort of thing.

[RoverDude]

I maintain that it's never going to work (for reasons listed elsewhere) but I won't be a Grinch about it Prove me wrong, if you can!

Oh, I see no reason why it won't work, mostly because we have no better alternative, and have no choice. I'd go one step further and say it already has worked, because I'll be migrating 100% of the USI mods (what I already have, plus all future expansions including my upcoming ELP integration) into this. And given we have... what? Two major mods out there today that have custom trees - NFT and KSPI. And between Nertea's constellation and mine, we're already hitting a significant chunk of the userbase. So the only outstanding question will be if Fractal wants to play on the playground or not. If so, awesome. If not, then I don't see it in any way diminishing the success of the project.

[FreeThinker]

I think the BG9 Mod could use several tech tree nodes for their advanced Spaceplane and Spacestation parts

Seperate Tech nodes for advanced landing gears, propellers and wheels would also be usefull

Edited October 28, 2014 by FreeThinker

[Streetwind]

Oh, I see no reason why it won't work, mostly because we have no better alternative, and have no choice. I'd go one step further and say it already has worked, because I'll be migrating 100% of the USI mods (what I already have, plus all future expansions including my upcoming ELP integration) into this. And given we have... what? Two major mods out there today that have custom trees - NFT and KSPI. And between Nertea's constellation and mine, we're already hitting a significant chunk of the userbase. So the only outstanding question will be if Fractal wants to play on the playground or not. If so, awesome. If not, then I don't see it in any way diminishing the success of the project.

(In an effort to not clog the other thread with offtopic)

I potentially misunderstood the scope and purpose of what you initially proposed. You're not trying to design a tech tree as such. You're trying to design a web of nodes that modders can plunk their parts into as they see fit.

Am I getting it right this time?

[RoverDude]

(In an effort to not clog the other thread with offtopic)

I potentially misunderstood the scope and purpose of what you initially proposed. You're not trying to design a tech tree as such. You're trying to design a web of nodes that modders can plunk their parts into as they see fit.

Am I getting it right this time?

That's it

[Myrten]

Just keep it simple, don't go into hundreds of techs and I'll applause this

[UAL002]

I endorse this project. I have wanted to get into all of the mentioned mods but found a unified tree hard to come by. This needs to happen.

[Nertea]

Just keep it simple, don't go into hundreds of techs and I'll applause this

I might cautiously say that the number of new nodes should not exceed the number of stock nodes. Which is 53.

Love it

The options you have up there make sense, with the only distinction off the top of my head being colonization type construction (I'd toss MKS/OKS/Asteroid mining there) and 'Make really big ships' construction (for FTT, 5m+ rocket parts, ELP, etc.)

110% in and will use or adjust to whatever you end up with!

Yup, I'd extend the structural tree a few nodes further for really big stuff, and toss colonization stuff into a branch related to ISRU and life support.

Two things.

Firstly, this doesn't have to cover ALL THE MODS. Even if it only brings collaboration to 50% of them, it'll still make life much easier and more pleasant for players who are using a suite of mods that do play nice. And while I can't talk for others, it would certainly influence my decision on whether or not to install a mod if I knew that it wouldn't work well with the other mods that I already had from the suite.

Secondly, it seems that the thrust here and in the Tree Modifier mod is towards the tree.cfg defining the nodes and their interconnection, and the part files defining which nodes they want to be in.

Having this community project as a base would actually make it easier for people who want to create their own completely independant trees, since it would make it possible to target the parts in various nodes with catch-all ModuleManager scripts to push any "other" parts into spots on their own tree after they had moved all the specific parts they cared about. This has been the biggest problem with custom trees in the past - you not only have to play with the creator's tree, but also with pretty much exactly their set of other mods, or else parts are missing, or weird nodes appear past the end of the tree, or stuff is in bizarre places.

This project could at least help focus on a baseline that could help reduce that sort of thing.

Yeah, and working additively (no rearranging, renaming or anything) from the stock tree also somewhat ensure that any combination of mods should in theory be playable. The only (partially) forced dependency I can foresee occurs when you might add up all the costs of the new nodes; it's quite likely that you might want more science equipment to max it out more easily. Of course, contracts give the needed science too, so it isn't an ironclad rule.

EDIT: there is also one question I have. This Tech tree should force parts to tech or leave that liberty to other mods? In my opinion this is the main difference between it being use for personal tech trees that move things around (usually to be more "realistic") or create the room for other mods to play.

My vote is for the later: it should only create nodes (with name, icons, cost, etc) as frame for other mods to add their part wherever they prefer. Moving parts should only be done for very specific reasons.

I lean towards not doing part assignment, and having mods do it themselves via MM. Mods would be responsible for implementing their own balancing, their own layouts. That effectively removes like 90% of the difficulties I can foresee with the project

Caveat: I don't know if this is possible with TechManager right now.

(In an effort to not clog the other thread with offtopic)

I potentially misunderstood the scope and purpose of what you initially proposed. You're not trying to design a tech tree as such. You're trying to design a web of nodes that modders can plunk their parts into as they see fit.

Am I getting it right this time?

That is the idea, yeah, a set and layout of nodes that modders can use, rather than a sorting nightmare o' doom.

I'll start knocking together some more concepts, but I would really appreciate a post here if you are a modder and you are interested.

Edited October 28, 2014 by Nertea

[undercoveryankee]

Oh, I see no reason why it won't work, mostly because we have no better alternative, and have no choice. I'd go one step further and say it already has worked, because I'll be migrating 100% of the USI mods (what I already have, plus all future expansions including my upcoming ELP integration) into this. And given we have... what? Two major mods out there today that have custom trees - NFT and KSPI. And between Nertea's constellation and mine, we're already hitting a significant chunk of the userbase. So the only outstanding question will be if Fractal wants to play on the playground or not. If so, awesome. If not, then I don't see it in any way diminishing the success of the project.

Part assignments for Interstellar are something I could do if Fractal doesn't. Keep the playground growing, and if Interstellar has to be dragged kicking and screaming into the Century of the Fruitbat, that's what the community will do.

[undercoveryankee]

I lean towards not doing part assignment, and having mods do it themselves via MM. Mods would be responsible for implementing their own balancing, their own layouts. That effectively removes like 90% of the difficulties I can foresee with the project

Caveat: I don't know if this is possible with TechManager right now.

It is. http://forum.kerbalspaceprogram.com/threads/98293-0-25-TechManager-Version-1-1?p=1506287&viewfull=1#post1506287

[RoverDude]

@undercoveryankee Good deal. And it looks like Nertea is already adding ones sufficient to cover KSPI. We may have interop yet

[Nertea]

It is. http://forum.kerbalspaceprogram.com/threads/98293-0-25-TechManager-Version-1-1?p=1506287&viewfull=1#post1506287

Excellent.

[Streetwind]

That is the idea, yeah, a set and layout of nodes that modders can use, rather than a sorting nightmare o' doom.

Good!

But now I'm struggling somewhat to put into words what to think of it. It's certainly a far smaller scope project than I thought it was.

I suppose the chief advantage will be on the mod author side, where people with mods that could benefit from a custom tree but no means/time/motivation to pull it off can now simply bundle a third party DLL (or two - for guaranteed compatibility you need to outsource the part assignment to community tree nodes to a MM config), name the right nodes for their parts, and call it a day.

From a player's perspective, there won't be that much of a difference. Having a deeper tree ingame (and justification to actually go beyond the Mun for science) will certainly be a plus, but it doesn't address any of the fundamental issues with stuffing lots of different mods into the same progression.

...Well, there is one in that list of issues that it should be addressing, and that's how to deal with potentially empty nodes. Imagine a mod that adds content to the very high end nodes. Such a mod would play great when combined with other mods that populate the other nodes, but what if it was the only one that a player installs? Or in a different scenario, a player might have a whole bunch of mods installed, but by sheer chance, there is one tech tree node that doesn't have any part added to it.

Now, KSP supports setting nodes "hidden if empty", but the node in question could have children - other nodes that rely on it as a prerequisite. If you hide it, then all nodes depending on it will never be reachable, even if they're full of parts. If on the other hand you never set any nodes hidden, then installs with only one or two mods will have a potentially giant field of mostly empty nodes... and a confused player, who isn't sure if it's worth researching them, because he can't see if there are any more nodes containing actual parts behind it.

The decision of how to handle this will inform the tree design to a significant degree. For instance, you could request of modders to not add any parts to nodes that are unreachable without other mods installed (essentially saying "you must add parts to all the nodes along the way to the highest node you want to use"). That works well, allowing you to set all nodes as "hidden if empty" so that the player only gets to see the part of the tree that's actually in use in his specific configuration. But depending on how the tree itself is designed, this could make a lot of mods unable to use it. Like, Interstellar has a large number of parts... but does it have enough low-tech parts to open the way to all the high end nodes that it needs? The answer to that depends less on Interstellar, and more on the number of interposing node steps and cross-connections that you specify in the community tree design.

For example, using the subtree approach as Nertea suggests, you would define certain "entry nodes" for each subtree. You set those entry nodes as "hidden if empty", and stipulate that if a modder wants to use any node in that subtree, he must put something into the entry node in order to make the subtree accessible even if his mod is the only mod installed. The more finely grained you make this, the more efficient at removing empty nodes this gets - but also the more contrived and onerous to work with. You're also effectively removing the ability to have interconnects between subtrees this way.

As you can see, this isn't a trivial issue, and I think it's best that it's sussed out early on, in the conceptual phase.

Edited October 28, 2014 by Streetwind

[Starstrider42]

Now that I'm officially de-Grinched...

Based on what I have above in that mod list, I can kinda see the following set of vague branches and extensions. Some are very self serving.

• ISRU branch (Kethane, Karbonite, MKS/OKS)
  
• Ion engines extension (NFT, KSPI)
  
• Nuclear engines extension (FTmN AR, KSPI, FTT)
  
• Nuclear power extension leading to fusion (NFT, FTT, OKS/MKS, KSPI)
  
• Life support branch (Life support mods)
  
• Construction extension (MKS/OKS, NFT, FTT)
  
• Solar power extension (NFT)
  
• Science instrumentation extension (Station Science, KSPI)
  
• Doomsday endgame things (KSPI)
  

While I don't have a mod of my own to add to the list (RemoteTech makes more sense in the stock tech tree, and Custom Asteroids doesn't have a single part), I have been working on a tech tree rearrangement for my own use (https://github.com/Starstrider42/IntegratedTech/blob/master/integratedTech.png). That's given me a few ideas for what would be useful tech areas to have:

• A ground bases branch (possibly partially overlapping with your construction and ISRU extensions). This would include not only MKS, but also EL's survey station and mining capabilities, and possibly PorkJet's ground-based habs. Could be the same size as the stock space station branch (which I define to be Specialized Construction, Advanced MetalWorks, and Meta-Materials, but I'm sure others have their own interpretations).
  
• An orbital surveys branch -- probably just one or two nodes, and located near the middle of the tech tree rather than at the end. This would cover ScanSat, Kethane, and ORS(X).
  

Otherwise, I think you pretty much have things covered. I guess I'd rather Life Support were mixed in with the stock crew space nodes rather than being its own branch (as I argued on the TechManager thread, these kinds of advances tend to go together), but that's a secondary issue.

[Rabada]

Are you planning on expanding solely to the "right" of the tech tree? That is to say are you going to solely be adding expensive, high tech expansion nodes? I personally think that some mods (TAC life support and DRE mostly) should get their own tech nodes earlier on in the tech tree. I would suggest expending trees for those mods (assuming the mod authors agree) towards the upper left portion of the tech tree.

[Starstrider42]

The decision of how to handle this will inform the tree design to a significant degree. For instance, you could request of modders to not add any parts to nodes that are unreachable without other mods installed (essentially saying "you must add parts to all the nodes along the way to the highest node you want to use"). That works well, allowing you to set all nodes as "hidden if empty" so that the player only gets to see the part of the tree that's actually in use in his specific configuration. But depending on how the tree itself is designed, this could make a lot of mods unable to use it. Like, Interstellar has a large number of parts... but does it have enough low-tech parts to open the way to all the high end nodes that it needs? The answer to that depends less on Interstellar, and more on the number of interposing node steps and cross-connections that you specify in the community tree design.

For example, using the subtree approach as Nertea suggests, you would define certain "entry nodes" for each subtree. You set those entry nodes as "hidden if empty", and stipulate that if a modder wants to use any node in that subtree, he must put something into the entry node in order to make the subtree accessible even if his mod is the only mod installed. The more finely grained you make this, the more efficient at removing empty nodes this gets - but also the more contrived and onerous to work with. You're also effectively removing the ability to have interconnects between subtrees this way.

I would think the simplest solution to this problem is to make the tree extensions fairly shallow -- say, never going more than one or two nodes away from the nearest stock node. I don't think hidden if empty was ever designed to be used on more than leaf nodes.

EDIT: another possible solution is to make all extended nodes hidden if empty by default, then remind modders that they can use MM to change that flag if they feel the need.

Edited October 28, 2014 by Starstrider42

[RoverDude]

@Streetwind I really don't anticipate empty child nodes being an issue because this is something we haven't had an issue with in the past - that is to say, any mod who actually *needs* an extended tree (and there are very few of those) would know to not paint themselves in a corner with an empty node - i.e. I would assume the mod author would test their tree with just their own mod + stock - so the empty parent node should never occur unless someone is willfully ignorant.

I would advocate not making any assumptions for any mod out there whether it's TAC-LS, DRE, etc. - those ones remain best served by working in stock nodes because in most cases, people simply don't have one of the few tech-extending mods installed. That being said, a mod *might* chose to shuffle them around, but I would see that as completely out of scope. This is just framework stuff.

At the end of the day, this would just be the DLL distributed with possibly a MM config at the mod level for any rearrangement. Your worst case scenario there is having two of us move the same stock element, but again given the audience and scope, I expect that will be a weird edge case solvable by a simple conversation (tbh I don't know if even NFT moves anything around in stock - USI does not, and I don't believe KSPI does).

Best bet is to be careful on scope and not over complicate things. This is just scaffolding for people to use responsibly, and the number of people that would actually need this can probably be counted on one hand.

@Starstrider42 I don't think there needs to be a limit to the depth since these are in support of mods that will by definition already need to fill in that tree. I think the right answer is 'if your mod is going to use this, you can't leave any gaps between your parts and stock, nor gaps in your tree. i.e. common sense, and issues that would pop up the second they tested their mod.

[DMagic]

I would think the simplest solution to this problem is to make the tree extensions fairly shallow -- say, never going more than one or two nodes away from the nearest stock node. I don't think hidden if empty was ever designed to be used on more than leaf nodes.

I like this idea for earlier branches in the tree. Later branches could obviously be bigger and more complex since they would likely be designed with one or two specific addons in mind.

But having some more variety early in the tree would be nice for some of the more optional type of parts (the resource scanners you mentioned, additional science parts, command pods, etc...); things that might not necessarily make sense at the end of the tree, but that might make the early nodes too crowded.

[Starstrider42]

I would advocate not making any assumptions for any mod out there whether it's TAC-LS, DRE, etc. - those ones remain best served by working in stock nodes because in most cases, people simply don't have one of the few tech-extending mods installed. That being said, a mod *might* chose to shuffle them around, but I would see that as completely out of scope. This is just framework stuff.

The problem of whether players have tech-extending mods installed could be easily solved on the modder's side by doing what Nertea did with Near-Future: use both a stock node and an extended node, depending on whether a custom tech tree is installed. Taking TAC-LS as a hypothetical example:

PART
{
    ...
    title = Life Support Container, Large
    techRequired = heavyRocketry
    @techRequired:NEEDS[CommunityTechTree] = longTermMissions
    ...
}

So I agree, we shouldn't worry about every edge case. Just make a tree that's both robust and flexible, and everything else will take care of itself.

Edited October 28, 2014 by Starstrider42
More explicit wording