[Planning] Community Tech Tree

[Fractal_UK]

@Fractal_UK

I'll go ahead and address the next elephant in the room since it was not clear form your post. Is it your intent to:

(a) participate in the community tree so users can use USI mods, NFT, and KSPI simultaneously (and given the efforts other folks have spent making this happen, it appears to be where the users want to go)

( keep KSPI as it's own tech tree without interop with the Community Tech Tree

© Do both (participate in the community tech tree and also have a KSPI-only tree)?

It would be good to address this now as it likely affects how Nertea is laying things out.

(Edit) I don't see why the community tech tree would have MM configs? The entire point is that a set of common nodes and their relationships is defined, and the mod authors drop their stuff in there as part of our regular configs - i.e. I don't see it as a special case, more just a largish tree that multiple mods share.

My concern, and hopefully it turns out I am incorrect, is that we will miss the interop boat again.

c) Seems like the logical choice. I'm assuming, for the time being, that Interstellar would be distributed with its own tech nodes and nothing else and that the community tech tree would be distributed seperately as almost a distinct mod. I'm not, in principle, opposed to distributing a community tech tree with Interstellar though it would depend on what the final result looked like.

[RoverDude]

c) Seems like the logical choice. I'm assuming, for the time being, that Interstellar would be distributed with its own tech nodes and nothing else and that the community tech tree would be distributed seperately as almost a distinct mod. I'm not, in principle, opposed to distributing a community tech tree with Interstellar though it would depend on what the final result looked like.

Good. So I'll toss the ball back to Nertea then

It would be wise to be on option C before a release, or we will have an excessive amount of sadness when people can't use the mods together.

RE Distro, the reality is that this would not be a separate mod, it would be a core part of the USI constellation as well as NFT for starters (no different than how KSPI distributes it's own tech tree), likely others based on addoption. Hence why it's a pretty important bit, since stuff will break day one if we don't have option C locked down.

Since this is pretty much the discussion thread FOR the Community Tech Tree, now would be a good time to address how you would like to see KSPI integrated, since Nertea is working on the nodes.

[Your_Uncle]

@Fractal_UK

My concern, and hopefully it turns out I am incorrect, is that we will miss the interop boat again.

I would love to see all the mods play nice on the same tech tree.

Conceptually it doesn't feel to hard to agree on a node structure that allows meaningful progression for all the advanced tech mods- it is just a matter of everyone agreeing before updating their mods.

Selectable trees is awesome though Fractal, but I personally feel that they should be primarily used for tech tree overhauls (ie, better than starting manned) rather than ending up in the same area we previously had whereby each mod has its own unique trees.

(edit) Seems you guys both posted while I was typing, making post this completely redundant.

Keep up the good work!

Edited October 29, 2014 by Your_Uncle

[anonish]

(Edit) I don't see why the community tech tree would have MM configs? The entire point is that a set of common nodes and their relationships is defined, and the mod authors drop their stuff in there as part of our regular configs - i.e. I don't see it as a special case, more just a largish tree that multiple mods share.

well, correct me if i'm wrong, but don't we still have the part assignment problem? Lets assume a mod developer wants to provide both a static tree custom built for their mod only and also be included in the community tree. To provide the most flexibility for the creation of their own custom tree, there should be no assumption that the parts they provide will have a TechRequired property that is valid for both trees. So, we need MM somewhere to fix that field. I'd expect a mod developer would set up their parts by default to work with their own static tree. So, it would be up to the community mod to figure out how to remap all the parts to the community tree.

yes, if all mod developers want to restrict themselves to a pre-defined set of techIDs then the problem goes away. but that is a restriction on the trees they might want to make for themselves.

We could double up on Fractal_UK's idea of tree definition configs. Each mod provides a static tree config for a universe where only their mod exists under a local config file that gets slurped up and presented to TM as an option. But they *also* provide a config file that defines how to map their parts to the community tree. Participation in the community tree would be defined as providing this config file. That set of config files is slurped up and given to the community mod to produce the community tree. Ok, so I did lose MM in there. Also, TM could operate on the second set of config files instead of there being a separate community mod as an alternative.

My original thinking was that MM would need to figure out how re-assign parts based on which mods are installed. But having participating mods provide a community config file seems workable to me.

EDIT: to be clear, the per-mod community config files are not tree definitions. they would only specify how to map parts to techs in the community tree

Edited October 29, 2014 by anonish

[RoverDude]

well, correct me if i'm wrong, but don't we still have the part assignment problem? Lets assume a mod developer wants to provide both a static tree custom built for their mod only and also be included in the community tree. To provide the most flexibility for the creation of their own custom tree, there should be no assumption that the parts they provide will have a TechRequired property that is valid for both trees. So, we need MM somewhere to fix that field. I'd expect a mod developer would set up their parts by default to work with their own static tree. So, it would be up to the community mod to figure out how to remap all the parts to the community tree.

(Let me correct you). The point of this project is to provide a framework of interrelated nodes that all of us agree on and will participate in. For example, I will have my nuke reactors on the same node as Nertea's nuke reactors. Probably the only time there would be an MM config is when going between stock and the CTT. The entire point of the CTT is to *not* have separate trees.

yes, if all mod developers want to restrict themselves to a pre-defined set of techIDs then the problem goes away. but that is a restriction on the trees they might want to make for themselves.

That's the entire point of this thread and the project last I checked, which is why it's becoming increasingly frustrating to see our community one more time on the cusp of squandering another opportunity for interop. One that basically costs... nothing. Well, other than goodwill.

We could double up on Fractal_UK's idea of tree definition configs. Each mod provides a static tree config for a universe where only their mod exists under a local config file that gets slurped up and presented to TM as an option. But they *also* provide a config file that defines how to map their parts to the community tree. Participation in the community tree would be defined as providing this config file. That set of config files is slurped up and given to the community mod to produce the community tree. Ok, so I did lose MM in there. Also, TM could operate on the second set of config files instead of there being a separate community mod as an alternative.

My original thinking was that MM would need to figure out how re-assign parts based on which mods are installed. But having participating mods provide a community config file seems workable to me.

Again, no offense, you're treating the project for which this very thread was started as kinda a second class citizen. To be clear, I don't expect Nertea to deal with two trees, nor do two configs. I know I have no intention of doing a separate tree and a separate config to share... I ask again, why not share? The fact that Nertea and I can do this without even blinking (and let's be clear, between the two of us we hit a LOT of the larger mods that have tech) is the entire point of this thread.

Wanting to go it alone is the exception, by no stretch the rule. And again, it continues to disappoint me how quickly other folks go in the direction of outright squandering what few shots we have at solid interop - because at the end of the day, all that does is screw over the users. Again.

I'm pleased that Fractal is considering participation in a shared set of nodes. That rocks. But let's be clear, from where I stand that's pretty much the default with an option to go it alone, not the other way around.

Sorry for being so blunt, but I think the characterization of this project has started to get off track and I feel like it's being pushed once again into isolationism, which is bad for everyone, except the isolationist.

[RoverDude]

(Summary stuff written on a mobile phone). So from my personal standpoint, this specific project (CTT) should land where a single tree configuration used by several mods is distributed, with an agreed to layout of the tech tree and each mod responsible for the placement of their parts in that tree, and each mod distributing the same config. Full stop.

[Nertea]

Okay, I had a shot at laying out areas of technology, and drew up the KSP tree in an online tool so everyone can have a look.

Arrows represent areas of tech, and about where they would branch out from a stock node. Their horizontal extent across the tiers shows about what area the node would cover (eg, the Colonization section might cover two tiers). This works out to about 30-50 new nodes total at the moment, depending on how many splits in a tier there are. Notice that no area of tech really derives from a new area (except in the case of KSPI which adds several areas of tech that are subsequent). This limits inaccessible nodes.

A few things:

• I think very few nodes are needed for life support (2 or 3 at the most), most parts fit into stock nodes beyond recyclers, greenhouses
  
• Locations of branching aren't totally clear for some branches. Solar, nuclear, ion, these make sense. Life support, scanning, they could probably be moved around.
  
• It's easy to cover everything except KSPI . This is because KSPI does these things like thermal nozzles, which don't exactly fit anywhere (could be fusion, could be AM, could be nuclear).
  
• I made up tier costs on the spot.
  

Comment as you wish.

[anonish]

Again, no offense, you're treating the project for which this very thread was started as kinda a second class citizen.

None taken, just wanted to contribute. Thanks for listening.

[Starstrider42]

Okay, I had a shot at laying out areas of technology, and drew up the KSP tree in an online tool so everyone can have a look.

Arrows represent areas of tech, and about where they would branch out from a stock node. Their horizontal extent across the tiers shows about what area the node would cover (eg, the Colonization section might cover two tiers). This works out to about 30-50 new nodes total at the moment, depending on how many splits in a tier there are. Notice that no area of tech really derives from a new area (except in the case of KSPI which adds several areas of tech that are subsequent). This limits inaccessible nodes.

A few things:

• I think very few nodes are needed for life support (2 or 3 at the most), most parts fit into stock nodes beyond recyclers, greenhouses
  
• Locations of branching aren't totally clear for some branches. Solar, nuclear, ion, these make sense. Life support, scanning, they could probably be moved around.
  
• It's easy to cover everything except KSPI . This is because KSPI does these things like thermal nozzles, which don't exactly fit anywhere (could be fusion, could be AM, could be nuclear).
  
• I made up tier costs on the spot.
  

Comment as you wish.

Looks nice, and I agree with the general strategy comments you've outlined above. A few quibbles:

• You made a few mistakes in the stock part of the tree. The two that are likely to affect the CTT are that nanolathing now derives from composites, while meta-materials leads to experimental rocketry (along with very heavy rocketry).
  
• Can you clarify what sorts of breakthroughs go in the Heavy Construction path? That's the only one where I can't really visualize what is involved.
  
• Making ISRU a branch of Field Science was pretty clever, I wish I'd thought of that. Would it also have interconnections with surveying, or not so much?
  
• Can you spell out the children of Automation and Robotics, along with the prerequisites for Spaceplanes, Colonization, and Gigantic Rocketry? The intersecting lines make it hard to tell if we're all on the same page.
  

That's about it. Thanks for putting this draft together so fast!

[Nertea]

Looks nice, and I agree with the general strategy comments you've outlined above. A few quibbles:

• You made a few mistakes in the stock part of the tree. The two that are likely to affect the CTT are that nanolathing now derives from composites, while meta-materials leads to experimental rocketry (along with very heavy rocketry).
  
• Can you clarify what sorts of breakthroughs go in the Heavy Construction path? That's the only one where I can't really visualize what is involved.
  
• Making ISRU a branch of Field Science was pretty clever, I wish I'd thought of that. Would it also have interconnections with surveying, or not so much?
  
• Can you spell out the children of Automation and Robotics, along with the prerequisites for Spaceplanes, Colonization, and Gigantic Rocketry? The intersecting lines make it hard to tell if we're all on the same page.
  

That's about it. Thanks for putting this draft together so fast!

1. Fair enough. At this point I don't think it matters too much, but I'll update it when I get a chance.

2. Large girders, large habitation or station modules, large... things. Look at Rover's FTT for examples or really large parts, or NF Construction's octo-girders.

3. Thanks - thought it made sense. It could have interop with scanning, but it would have to be carefully managed so that nothing depended on anything. I guess logically you might want to lock Kethane tanks until you discovered the Kethane scanner.

4. Sure, it's unclear. I've changed it for clarification using colours. That entire area would be subject to the exact nodes that end up going in there.

[RoverDude]

Looks excellent. I can see FTT using a combination of heavy construction and gigantic rocketry. I'd also consider anything around asteroid construction in the heavy construction node as well. Maybe replace that with the moniker orbital construction or have it as an offshoot somewhere?

I'll likely share some of the Future Tech nodes with KSPI for my fusion drives as well as an upcoming 5m torch ship, which will be on par with the Alcubierre drive tech wise.

For ISRU I would consider (when we get into the weeds) of putting miniaturization later in the tree - so you get big bulky converters first, then tiny ones.

(Edit)

Where do the NFT reactors come into play? That's where mine would be as well.

[Nertea]

Yeah, node names... going to be finicky. They need to be broad enough to encompass all the mods' content, but specific enough not to lose meaning.

I plan on working off of the NFT tech tree (see first post) for the fission reactor area, though with simplifications.

[Your_Uncle]

Looks great Nertea

Yeah, node names... going to be finicky. They need to be broad enough to encompass all the mods' content, but specific enough not to lose meaning.

Are you asking for suggestions at this point? (I'm going for yes)

In my mind life support and colonization share the same origins, as in packing snacks in a can are the first step towards greenhouses on Laythe. So a progression such Survivability -> Life Support -> Self Sufficiency -> Outpost Construction -> Colonization, where small life support canisters come first, then larger ones, then recyclers and then the greenhouses. Just a thought.

Assuming most mods follow RoverDude's comment/structure that bigger, bulkier tech is unlocked first, and smaller more efficient stuff later then bucket terms like Nuclear Propulsion -> Compact Nuclear Propulsion -> Advanced Nuclear Propulsion -> Compact Advanced nuclear Propulsion -> Experimental Nuclear Propulsion -> Compact Experimental... etc

From a UI/accessibility point of view, it would be good to use the same descriptors for multiple branches. For example, Solar Power, Ion Propulsion, Nuclear Propulsion would all follow the same Basic -> Intermediate -> Advanced -> Experimental progression. Adopting a consistent nomenclature makes each branch more familiar and approachable, and avoids newbies getting overwhelmed by the complexity of a full tree.

Just some food for thought.

Keep up the amazing work

[Nertea]

I was going to post a bunch more thoughts, but I decided to just lay out some nodes . This is 41 new nodes. I'm gonna cap it at 45, 50 at maximum cap. I fully expect people to object to some of it, so here's some rationale on some areas.

Nuclear Power Branch

• There are at least 3 mods playing in this playground so it has to have room for a decent progression
  
• Nuclear Support Technology is an extra node that I want, but I don't like the name (In NFT it's Advanced Cooling Systems, which is too specific)
  
• There should be enough here to support KSPI's abundance of reactors, NFT's reactors, KSPI's fusion (two levels)
  
• 
  

Larger Rocketry Branch

• Pretty generic extension of the stock tree
  
• Suggest this for 5m parts and the like
  
• Name of the second node isn't great
  

Nuclear Propulsion Branch

• Two new nodes gives room for 2.5m and 3.75m parts, if you follow Squad's progression. There aren't enough NTR mods to justify that much more.
  
• 
  

Construction Branch

• Three new nodes focused around larger parts
  
• As Rover requested, later nodes are Orbitally focused in names
  

Ion Engine Branch

• I need this many nodes for NFP
  
• KSPI can play here too
  

Science Branch

• Room for a node's worth of new parts
  
• Two nodes with nomenclature for Station Science (and mods like it)
  

Survey Branch

One node for scansat and co

• One node for ISRU scanners
  
• I think this is enough, but we might go another node because there are quite a few ISRU scanners now...
  

ISRU Branch

• Branch running from initial exploration to use to large scale stuff
  
• Should hopefully cover the range of solutions out there
  

Colonization Branch

• I moved this branch to the bottom so it would fit better
  
• As suggested, folded life support into this
  
• Recycling -> Hydroponics -> Off world living
  
• Final tech might require stuff from ISRU and Science branches
  

Future Technology

• Combines the end of the science stuff with the end of the plasma engines with the end of the fusion power stuff
  
• KSPIland.
  
• Rover, what would you want to do with your fusion drive?
  

Solar Power Branch

• I want three nodes here
  

Random other things

• Electrical Systems Node: KSPI generators or microwave transmitters? could add another node here for transmitters, considering that I have some ambitions of doing that sometime
  
• Another Control Node: Another node after Large Control might be good for large command pod mods?
  
• Firespitter, KAX, B9: Not familiar enough with these mods to say what they might want or need. However, be my guest and suggest a few nodes wherever (though do pay attention to the locations of the lines, it's hard to make things fit sometimes in the middle).
  

I also solicit comments on (some) names. A few are evidently bad. I'd like to stay away from the high tech-> miniaturization though. It's the opposite of how the stock tree goes in a lot of respects. That doesn't mean you couldn't put those in with your own mod, but in most cases I've gone with "advanced", "high effic", "large scale" which neatly sidesteps the size question (yes, large scale could be many small ones ).Things also only get specific when I'm really sure that I know all the mods that play in that area, and that I can cover them all with a statement.

Edited October 29, 2014 by Nertea

[Your_Uncle]

Amazing!

I like the requirement for both Automation and Robotics for Off World Manufacturing.

I also see your point in adding Orbital Surveys and Resource surveying as dedicated nodes, given how many mods use them. Not sure about having a technology tree pathway/branch dead end by tier 6 though. As it stands, Scansat's more advanced scanners are further down the tree than that. Also, nobody should want to start extracting resources without first having the detection tech researched.

Maybe tweak it so that Resource Utilization follows on from Resource surveying- that removes the dead end early on and and gives resource finding/mining/exploitation its own whole branch from Tier 5 onwards.

As for the nomenclature, the progression of Basic -> Advanced -> Specialized -> Cutting Edge (or Experimental) works well.

I note that Advanced Solar goes to two Tier 9 nodes, that both dead end. whats your view on bumping Cutting Edge to tier 10?

Or are there enough different solar components around to warrant the two?

I'm just thinking about avoiding empty nodes with say, only 1 mod installed- the fewer dead end branches there are, the easier it is to arrange parts logically

Really though I'm just nitpicking some minor details. The overall structure there is logically arranged, and it is fairly intuitive as to where I would expect to find various parts.

[KaiserSoze]

Looks great.

Regarding node dependencies I have a question, more a potential problem we need to decide how to act before it grows.

Whenever we make a new node dependent of another new node we should be very careful. I'm not referring to the problem of some small mod putting its part in a node in the last leaf of the tree (which could be a problem but I agree with roverdude being something that the modder should resolve rather than been solved here).

I'm talking about things like:

a) we create a new node for resource extractions utils (or a whole branch of the tree). This node refers mostly to resource storage or processing.

one mod decides its a god node to put his converter and/or tanks for his new flassy resource (dont care wich one).

c) we decide that since the bigger user for this could be Kethane/Karbonite it makes sense to make this node to be dependent for scanners.

d) since the mod described has no scanner it has no need to that dependency (or it could make no sense for that resource in particular), so now this mode now depends on some other node which makes no sense for him.

I put only an example, but this could happen if we mix branches of the tree. I see a few solutions:

1) Only Use OR dependency (instead of AND) whenever we mix tree branches. this kinda looses the point of dependy, but allows it to work if there is no other branch at all.

2) Always leave a node in the branch which has no AND depency from other branches (I don't care about AND dependency on the same branch). This has the problem of having more nodes, the ones that has no interdependence (or have it but with and OR) and the ones with dependence (with AND).

If we are using interdependence of branch (which I like for somethings) I prefer the second option. So a mod with few part should not use the nodes with heavy dependency on other new nodes:_ Golden rule for modders: always test first with only your mod and stock unless you really want to have dependency from other mod, which should be know by each modder right now.

Of course there could be a third option: dynamic trees that make those dependency OR/AND if certain mods are installed, but I'm assuming that will not be possible (and/or too much work for small utility).

Edited October 29, 2014 by KaiserSoze

[gh7531]

Nice to see that it's going on!! Keep it going.

A way of solving the Problem with empty nodes dependencies if one mod isn't installed could be set empty nodes to visible and set the science cost to zero. But this is probably something that TreeManager should adress.

[RoverDude]

This rocks!

RE the fusion drives and upcoming torch ships - I'll fit those at the far end of the tree, likely in KSPI-land since mine are comparable balance wise to KSPI's.

[gameguy600]

I think these additions to the tech tree would make it even more flexible than it currently is:

1.propeller engines node for firespitter, retrofuture and kax branching from the aerodynamics node

2. 2-3 nodes for space telescope mods like the tarsier and cacteye that would branch from space exploration while being a separate node from the planetary surveys

3. an experimental AI node that would cover things like the interstellar AI core and a few other super advanced probecores.

4. a new node meant for rover systems that use alternatives for wheels like tracks or antigravs.

5. 2 lategame nodes meant for VTOL and SSTO planes and helicopters.

6. thermal propulsion node branching from the nuclear propulsion node.

Edited October 29, 2014 by gameguy600
added retrofuture to propeller engines

[Nori]

Snip.

Wow! That looks amazing. I don't know that I could add anything as it seems like you hit all the highlights for my mod selection.

[DaPatman]

Personally, I think this is a great idea that will inspire me to use more mods. Also, I have a couple of things to say regarding Nertea's layout:

Larger Rocketry Branch

• Name of the second node isn't great
  

Gargantuan Rocketry?

Random other things

• Another Control Node: Another node after Large Control might be good for large command pod mods?
  

This is definitely something that's needed, as it would be perfect for things like the 3.75m monopropellant tank and SAS module the Tarus HCV guys have in the works (and the Taurus HCV itself, come to think of it).

• Firespitter, KAX, B9: Not familiar enough with these mods to say what they might want or need. However, be my guest and suggest a few nodes wherever (though do pay attention to the locations of the lines, it's hard to make things fit sometimes in the middle).
  

Well, I'm not overly familiar with those mods myself, but I do know that propeller engines feature in at least one of them, and probably need to make an appearance near the start of the stock space plane branch.

Other than those, that all looks good to me.

[Serino]

While my knowledge of programming is pretty good, yay college and years of fun with writing programs, my knowledge of how .cfgs for kerbal is a bit limited right now so correct me if I'm wrong but wouldn't it be easier to, instead of needing the mod writers to make two seperate trees, instead have a tag that they can add to their trees to check for the community tech tree and then shunts the parts into the appropriate node as CTT defines like a simple if else statement. Assuming of course you could load multiple trees this would mean little extra work on the modders part and the user just needing to load the trees for the mods s/he is using.

[Nertea]

Updated the tree:

• Added node: Fusion Rockets (what could this be...)
  
• Added node: Subsonic Flight (propellers!)
  
• Added node: Advanced Aerospace Composites (Advanced spaceplane parts)
  
• Added node: Experimental Aircraft Engines (Advanced aircraft engines)
  
• Added node: Heavy Control (larger pods and reaction wheels)
  
• Added node: Power Transmission (microwave networks)
  
• Moved the nuclear propulsion branch above rocketry
  
• Renamed a few techs
  
• Rearranged some more techs
  

Comments on comments:

I think these additions to the tech tree would make it even more flexible than it currently is:

1.propeller engines node for firespitter, retrofuture and kax branching from the aerodynamics node

2. 2-3 nodes for space telescope mods like the tarsier and cacteye that would branch from space exploration while being a separate node from the planetary surveys

3. an experimental AI node that would cover things like the interstellar AI core and a few other super advanced probecores.

4. a new node meant for rover systems that use alternatives for wheels like tracks or antigravs.

5. 2 lategame nodes meant for VTOL and SSTO planes and helicopters.

6. thermal propulsion node branching from the nuclear propulsion node.

1. Ok

2. I think these fit perfectly well in Specialized Science Tech and Long Term Science Tech

3. I think that's not quite needed. I'd rather give KSPI microwave transmission a node

4. Experimental Motors not enough?

5. Fair enough

6. Covered in Nuclear Propulsion, really.

This rocks!

RE the fusion drives and upcoming torch ships - I'll fit those at the far end of the tree, likely in KSPI-land since mine are comparable balance wise to KSPI's.

Gave you a fusion engines node. Some other mods could find it useful.

Looks great.

Regarding node dependencies I have a question, more a potential problem we need to decide how to act before it grows.

Whenever we make a new node dependent of another new node we should be very careful. I'm not referring to the problem of some small mod putting its part in a node in the last leaf of the tree (which could be a problem but I agree with roverdude being something that the modder should resolve rather than been solved here).

words

I think that I've solved that problem by not making co-dependencies unless mods can be confirmed to fill everything.

Amazing!

I like the requirement for both Automation and Robotics for Off World Manufacturing.

I also see your point in adding Orbital Surveys and Resource surveying as dedicated nodes, given how many mods use them. Not sure about having a technology tree pathway/branch dead end by tier 6 though. As it stands, Scansat's more advanced scanners are further down the tree than that. Also, nobody should want to start extracting resources without first having the detection tech researched.

Maybe tweak it so that Resource Utilization follows on from Resource surveying- that removes the dead end early on and and gives resource finding/mining/exploitation its own whole branch from Tier 5 onwards.

As for the nomenclature, the progression of Basic -> Advanced -> Specialized -> Cutting Edge (or Experimental) works well.

I note that Advanced Solar goes to two Tier 9 nodes, that both dead end. whats your view on bumping Cutting Edge to tier 10?

Or are there enough different solar components around to warrant the two?

I'm just thinking about avoiding empty nodes with say, only 1 mod installed- the fewer dead end branches there are, the easier it is to arrange parts logically

Really though I'm just nitpicking some minor details. The overall structure there is logically arranged, and it is fairly intuitive as to where I would expect to find various parts.

1. I see what you're saying there - I could see renaming Resource Detection to Advanced Surveys or something and moving it a few levels down. Merge resource scanning parts into Resource Utilization. I don't want to tie the surveying bits to the resource tree though. Seems... messy.

2. It makes things a little more interesting? But seriously, I already have like 20 panels (and more planned) to distribute in those nodes. None are really better than the others, so they're colocated.

[Norcalplanner]

I only understand half of what you all are talking about, but what I do understand has me using all my self-control to avoid squealing with delight like a little girl. Keep up all the great work!

[Your_Uncle]

Gargantuan Rocketry?

Inadvisably Large Rocketry?

Edited October 30, 2014 by Your_Uncle