[WIP] ATC - Alternative Tree Configurator (released)

[bonesbro]

Loading from multiple configfiles sounds definitely useful, and is a simple extension I've just added in (later entries just overwrite earlier entries, order is configured via settings-file)

.... but at the moment, i am seriosly considering cutting the "new node" function entirely. Up to "modify existing nodes" (including dependendy changes), the code is readable and well-structured. But adding new nodes? Oh dear, now it gets ugly. There is no way to to extend the tree without going through extreme hoops (SQUAD, why does RDTechTee have "GetTreeNodes()" function but no "AddTreeNode(RDNode)" function??! And how do i setup a new RDNode/RDTech at all? Why does RDNode have a non-null prefab but GameObject.Instatiate(rdNode.prefab) cause an exception?). Really, the API there is extremely convoluted (RDNode.WarmUp(RDTech), RDNode.Setup(), RDController.RegisterNode(RDNode)), and i am getting frustrated. And since I am doing this in my free time for fun, there is only a certain amount of frustration I want to take (and hours I want to sink into this) before I give up and say "actually, I'd rather play the game instead". Unfortunately, this limit is almost reached

SQUAD, please give us a function that creates a new dummy RDNode so that we can fill in the necessary fields (title, science cost, parts, parents/childs etc). Or just create 200 more invisible dummy-RDNodes in the AssetBase.RnDTechTree...

I think that the ability to create new nodes is very important. It's tough to extend the game if you have to cram all your parts into existing nodes. Take Interstellar as an example - it adds fusion, antimatter, and warp drive nodes to the tree. If those had to get shoehorned into existing nodes then it eliminates the progression and endgame additions that Interstellar promises.

I've been testing cvod's mod-focused tech tree and it adds a TON of new nodes, essentially completely rewriting the tech tree. I've really been digging it: http://forum.kerbalspaceprogram.com/threads/90938-Mod-Oriented-Tech-Tree-(August-25-v0-2-2)/

I would offer to help with the coding on this, but between work and moving I wouldn't be able to contribute for about two weeks.

[Ixonal]

I take it you can't create new nodes the same way treeloader does then?

Edit:

        public static RDNode AddNode()
        {
            if (model == null || model.controller == null)
            {
                model = (from a in GameObject.FindObjectsOfType(typeof(RDNode)) where ((RDNode)a).treeNode && ((RDNode)a).gameObject.activeSelf select (RDNode)a).First();
                if (nodePrefab != null && model.controller != null)
                {
                    Destroy(nodePrefab);
                    nodePrefab = null;
                }
            }
            if (model.controller != null && model.controller.node_selected != null)
            {
                model = model.controller.node_selected;
                if (nodePrefab != null)
                {
                    Destroy(nodePrefab);
                    nodePrefab = null;
                }
            }
            if (nodePrefab == null)
            {
                nodePrefab = new GameObject("newnode", typeof(RDNode), typeof(RDTech));
                nodePrefab.GetComponent<RDTech>().techID = "newTech_RenameMe";
                nodePrefab.GetComponent<RDNode>().prefab = model.prefab;
                nodePrefab.GetComponent<RDNode>().parents = new RDNode.Parent[0];
                nodePrefab.GetComponent<RDNode>().icon = model.icon;
                nodePrefab.GetComponent<RDNode>().controller = model.controller;
                nodePrefab.GetComponent<RDNode>().scale = model.scale;
                nodePrefab.SetActive(false);
            }
            GameObject clone = (GameObject)GameObject.Instantiate(nodePrefab);
            clone.SetActive(true);
            clone.transform.parent = model.transform.parent;
            clone.transform.localPosition = model.transform.localPosition + new Vector3(0, 50, 0);
            clone.GetComponent<RDNode>().children = new List<RDNode>();
            return clone.GetComponent<RDNode>();
        }

Edited September 8, 2014 by Ixonal

[SirJodelstein]

Allright, here is the first code release. Please keep in mind that this is a largely untested version - i am using it currently to create my own tree rework, but there are probably quite some bugs to squash left.

Notes:

• you cannot add new nodes (the corresponding experimental section of the code is deactivated). I know that this would be an almost necessary thing to have to be actually useful, and this is why i'm releasing only the source and not a compiled ready-to-go compiled dll. I want to have a proved and tested and proved version of this before moving on.
  
• there is no settings gui.
  
• there is lots of debug output.
  
• There are hardcoded keyboard shortcuts for "Reload Tree" (F8) and "create Debug Dump" (F7)
  
• if you want to actually use it, create a subfolder in Gamedata called "ATC" and put the settings.cfg and the self-compiled dll into that folder. Adjust the entry in settings.cfg to point to your tree-config(s). Refer to the OP for the syntax of the tree-config file
  
• there are probably some bugs and issues
  
• did i mention that there might be bugs?
  

Released under MIT license. Get the pull requests going

https://github.com/GrJo/KSPAlternativeTechConfigurator

[SirJodelstein]

I take it you can't create new nodes the same way treeloader does then?

I've seen that code, and it approximately does whats on the label, but since i load/rework the tree at another time in comparison to TreeLoader, there are some issues when i blindly copy/use that section. More investigation is required. But as a said in my previous post, I'd like to get the current state to a stable base before moving on.

@FlowerChild: There you go, i think your tree would be the best test this plugin could expect. Create a configfile and go wild in a test environment

[FlowerChild]

@FlowerChild: There you go, i think your tree would be the best test this plugin could expect. Create a configfile and go wild in a test environment

Sweet! Working on something at present I want to get done first, but will dive right into this later today!

BTW: Any idea what your redistribution policy is/will be on this thing? If I'm going to dive into it, I'll likely do so head first

[Ixonal]

I've seen that code, and it approximately does whats on the label, but since i load/rework the tree at another time in comparison to TreeLoader, there are some issues when i blindly copy/use that section. More investigation is required. But as a said in my previous post, I'd like to get the current state to a stable base before moving on.

@FlowerChild: There you go, i think your tree would be the best test this plugin could expect. Create a configfile and go wild in a test environment

yeah, no, I wouldn't blindly use it either. Just wanted to make sure you had seen it just in case. I might take a peek and see what your code is doing alike and differently.

[FlowerChild]

All right, been playing around with it some and have some early feedback:

-Not sure if this is just debugging code, but I think it would be best not to clear all the existing tech tree assignments for all parts. This necessitates filling in absolutely every existing part into any tree you create, and eliminates the possibility of say mods just moving a node or adding some dependencies without doing so. It also eliminates the possibility of mod authors just adding their parts to the stock nodes through their config files and them being automatically supported by any tree that has those nodes. In other words, unless a tree author specifically supports a mod and includes its parts in their tree, then those parts simply won't appear. Not sure what purpose clearing the assignments serves, which is why I thought it might be debugging code (I removed it in the version I compiled with no issues).

-Dependencies coming out of the bottom of the parent node don't seem to render at all. This can be seen with the survivability node in the stock tree. As an aside, the rules you have in place for assigning which side the dependencies come out of doesn't replicate the stock tree behavior 100%, which is also illustrated with the survivability node. I suspect having commands so that tree authors can manually specify the side things attach might be the best bet, falling back on the rules you have when not specified.

-Similarly, I'm not sure if ATC should include commands for assigning parts to nodes at all. I say this because there's already an existing syntax for doing precisely that through config files, while in all other cases, ATC is adding commands that do not yet exist. Personally, I'd be concerned that having duplicate syntax like that will only cause confusion. I realize that assigning parts to nodes through module manager results in bulkier configs, but ModuleManager syntax is far more robust than anything you're likely to get from a mod like this, and opens the door to powerful stuff like people placing parts in particular nodes based on which other mods (and potentially trees) are installed. I fear that while the duplicate syntax might be more immediately convenient, it's going to limit what we can effectively do with this thing in the long run.

Put another way in OOP terms, including part assignment commands within the nodes kinda mucks up the "has a" relationship between nodes and parts. Stock config files are operating under "a part has a node" relationship, while ATC is operating under "a node has a part". I suspect this is going to get rather messy in the wild as a result.

-Personally, I would advocate getting rid of settings.cfg entirely and just go with the way KSP .cfg files work in general. Unless you are planning to add support for per-save tech trees (which I personally think is overkill as KSP mods in general don't work on a per-save basis like that), I'd just use a bit of code like this:

			foreach ( ConfigNode node in GameDatabase.Instance.GetConfigNodes( "MODIFY_NODE" ) )

To process *all* tree modifications that are found in any config file anywhere and skip the whole settings thing entirely.

I know it's the way treeloader worked, but is it really necessary to have the user be able to specify the tree through a settings file, or can that be left entirely in the hands of modders through configs as is pretty much the case for everything else in the game?

Alternatively, I think it would be great if the "TechTree = " statements within the settings file were themselves contained within a config node so that they could be modified externally through mod-specific .cfgs that wouldn't need to mess with the settings file directly. That would allow us to use simple ModuleManager commands to package any techtree modifications into our mods without having to directly alter that file.

Anyways, that's it for now. I'll likely attempt to address some of the above myself and will be happy to share my code changes once I do.

EDIT: I think some of my points above can be summed up in what I think is a very relevant question in determining what the scope of this project will be:

-Is this intended as a tool for modders so that we can edit the tech tree in the same way we edit anything else accessible through config files in the game?

-Or is this intended for players that want to mess around with the tree, in much the same way that TreeLoader is/was?

Ultimately, I think that question is rather central to how big a project this will be, and also how powerful it will turn out to be, as I think you can't really do the latter without sacrificing a certain amount of power and flexibility.

Personally, I would opt for the former for obvious reasons given its what is of most use to me personally, but I also think that such a tool would be extremely valuable, and then could potentially act as the basis for the latter as a separate project which wraps the whole thing into a user friendly GUI or what have you.

Somehow, I doubt that last bit will ever get implemented though, as I suspect that the people that will make the most use of this tool are modders themselves

Edited September 10, 2014 by FlowerChild

[Ixonal]

I can see one scenario that would make per-save tech trees useful. If a modder were to put in slightly different values for easy and hard modes of their mod, or some similar concept. Though admittedly, I really only play one save per install, so I'm not sure how relevant that scenario is.

I'm also wondering about the assigning parts to nodes part... I get where you're coming from, FlowerChild, but it could also be argued that leaving that part to ModuleManager puts the responsibility of managing the tech tree under two separate mods, instead of under one. I'd say, though, that since ModuleManager already implements this, I'd at least put it off until I could determine how the two methods of assigning parts to tech nodes would interact with each other.

Another note: I'd rename the main class to be the same as what you're going to name the mod. Separate names might get a little confusing for someone not used to the code base, and refactoring only gets more annoying as you go.

[FlowerChild]

I can see one scenario that would make per-save tech trees useful. If a modder were to put in slightly different values for easy and hard modes of their mod, or some similar concept. Though admittedly, I really only play one save per install, so I'm not sure how relevant that scenario is.

Oh, there are definitely places where it would be useful. Heck, having save-specific mod configurations would also be useful, however, I doubt that would ever make it into stock, and would likely be an incredible pain for a modder to implement.

I guess for me, part of what I'm looking at here is "if Squad were to implement something like this, what would it look like?"

I think it would be pretty straightforward and follow the rest of the config file system. So, the stock tree would likely be defined within a config somewhere within Gamedata/Squad, and we'd then be able to either modify it directly, or use ModuleManager to alter what is there, and that would be the extent of it. Chances of them implementing stuff like save-specific trees or part node associations within the nodes themselves is pretty much nil.

So, personally, that's the way I'd prefer to do things now if possible, both for the reasons I outlined above, and in terms of future-proofing my own work. The idea say of porting over my current way of doing things to a new system, opening up the possibility that I would then wind up porting them back (or to a third system) down the road in the process, is somewhat less than appealing

This is no slight towards what's in ATC at the moment mind you. I think it's awesome what SirJodelstein has put together here. I'm just putting forth questions of what the most effective way to approach this problem is, and my own viewpoint on what is most useful with this kind of tool before anything becomes set in stone.

[bonesbro]

Yes, ModuleManager-style configs, where a mod can easily say "here are my 5 new nodes and the parts I want to add to existing nodes" would be wonderful. If you wanted to gold-plate it, a way for a mod to say "Add it to the first of these six nodes that exists" so their mod could declare tech dependencies that supported multiple trees.

[SirJodelstein]

Hey FC, thanks for the quick feedback. Lets go, starting with the most important aspect:

EDIT: I think some of my points above can be summed up in what I think is a very relevant question in determining what the scope of this project will be:

-Is this intended as a tool for modders so that we can edit the tech tree in the same way we edit anything else accessible through config files in the game?

-Or is this intended for players that want to mess around with the tree, in much the same way that TreeLoader is/was?

I want this to be a modder's tool, at least thats my focus. There are plenty of tech trees out there, and I hope this plugin will someday be able to support the authors/maintainers of these.

Not sure if this is just debugging code, but I think it would be best not to clear all the existing tech tree assignments for all parts

...

I realize that assigning parts to nodes through module manager results in bulkier configs, but ModuleManager syntax is far more robust than anything you're likely to get from a mod like this

The reason behind this was that without something like that i cannot replace the part-assignment list if there are "untouched" parts (like "this tree.cfg removes the Mk1 capsule from the startnode but never re-adds it" => the capsule still has "techRequired = start" and shows up in the tree even though it is no longer in the Tech.PartsAssigned list). But if you want to create a balanced tech tree, you need to assign each part to a tech anyway, and would probably not just add another part mod to your tree without going over each part individually. At least thats what my current idea of "rebuild the tech tree" is.

Anyway, i think I will modify the code that it only clears the assignments for techs where you have a correspoinding MODIFY_NODE with a PARTS section in it. That way, the need to assign parts is only present for those nodes/parts and becomes optional if you use Modulemanager configs etc to manage these assignments. The PARTS sections is already optional.

Dependencies coming out of the bottom of the parent node don't seem to render at all.

Yes, i just noticed that as well, seems to be a bug in the internal arrow-drawing code. All other directions work. I still think the automation systems makes sense, I'll just cut the Top->Down direction from the automatic anchor logic as long as this persists.

Put another way in OOP terms, including part assignment commands within the nodes kinda mucks up the "has a" relationship between nodes and parts. Stock config files are operating under "a part has a node" relationship, while ATC is operating under "a node has a part". I suspect this is going to get rather messy in the wild as a result.

The KSP data model actually is "RDTech has a list of assigned parts (as reference)", not the other way round. AvailablePart just has a string (techId) that is used to initialize this list. (and thats what modders use to assign parts to the tech tree, so i know where you are coming from).

-Personally, I would advocate getting rid of settings.cfg entirely and just go with the way KSP .cfg files work in general.

Alternatively, I think it would be great if the "TechTree = " statements within the settings file were themselves contained within a config node so that they could be modified externally through mod-specific .cfgs that wouldn't need to mess with the settings file directly. That would allow us to use simple ModuleManager commands to package any techtree modifications into our mods without having to directly alter that file.

Yes, per-savegame trees are overkill and will not be done, however, a modularized tech tree consisting of several Tech-tree configuration files is still something that might be useful. Your alternative option sounds like a good idea, I'll go with that and just wrap the settings itself and the techtrees listing in a ConfigNode like this:

ATC_SETTINGS
{
 //keyboard shortcuts/etc/etc
 TREES 
 {
    TechTree = GameData/foo/bar.cfg
    TechTree = GameData/blurb/mooh.cfg
 }
}

[FlowerChild]

@ SirJodelstein

Thanks for taking the time to consider my points man

I had an idea last night as to how we might get the best of both worlds here. How about the following:

What if instead of ATC_SETTINGS pointing to files, it points to tree config-nodes, so it would look something like this by default:

ATC_SETTINGS
{
    TechTree = Stock
}

The stock tree could then be defined in a .cfg file shipped with ATC, within its own config node, which could be generated by some code that dumps the stock tree into a config file (I'd be happy to write that bit up if you like), and which could be run after each vanilla release to make sure that file is up to date with any changes Squad makes.

Then, mods could alter existing trees on an individual basis through ModuleManager with stuff like this:

@TechTree[Stock]
{
    @NODE[node2_stability]
    {
	    @title = New Fancy Technology
    }

    @NODE[node3_generalConstruction]
    {
	    @title = Newer Fancier Technology
    }
}

Define a new node (if/when that makes it in) like this:

@TechTree[Stock]
{
    NODE
    {
        name = nodexxx_revenge_of_the_node

        title = New Fancy Technology
    }
}

Or switch to an entirely new tree like this:

@ATC_SETTINGS
{
    @Tree = MyNewSuperDuperTree
}

Which they would then be responsible for setting up as a brand new tech tree .cfg from scratch, and which other authors can choose to support if they so desire.

IMO, this would make things very "Squad-like" in how everything is setup, going a long-way to future-proofing any work tree authors put in, while preserving the kind of flexibility that you're looking for.

What do you think? If you're keen on it, I'd be down with coding that all up myself, like...immediately

Edited September 10, 2014 by FlowerChild

[FlowerChild]

Ok, individual responses to individual responses on my individual points

Anyway, i think I will modify the code that it only clears the assignments for techs where you have a correspoinding MODIFY_NODE with a PARTS section in it. That way, the need to assign parts is only present for those nodes/parts and becomes optional if you use Modulemanager configs etc to manage these assignments. The PARTS sections is already optional.

Actually, that's exactly what I was talking about, so I think we're on the same page. The only thing I changed in my local version in that regard is removing the code that clears all part assignments globally. Clearing the parts in the individual node if a PARTS section is defined has no impact on me as I'm unlikely to use those sections anyways

Yes, i just noticed that as well, seems to be a bug in the internal arrow-drawing code. All other directions work. I still think the automation systems makes sense, I'll just cut the Top->Down direction from the automatic anchor logic as long as this persists.

Yup, I realized looking at the code afterwards that it's likely a stock issue. I think going left/right only is a good bet as the up arrows seem to have a rendering error anyways where the arrowhead is off center and looks weird as a result.

I disabled up/down attachments locally and the stock tree is then displayed exactly like it is in vanilla.

I do think having the ability to override the automatic assignment and specify your own attachment points in the config files as a catch-all backup could be very handy however.

The KSP data model actually is "RDTech has a list of assigned parts (as reference)", not the other way round. AvailablePart just has a string (techId) that is used to initialize this list. (and thats what modders use to assign parts to the tech tree, so i know where you are coming from).

Fair enough, I didn't realize that was the case internally. However, at the level at which it is exposed through config files, the "has a" is firmly in the part's court. I don't think flipping it back a second time is necessarily wise, in a "two wrongs don't make a right" manner

[Ixonal]

@ SirJodelstein

Thanks for taking the time to consider my points man

I had an idea last night as to how we might get the best of both worlds here. How about the following:

...

What do you think? If you're keen on it, I'd be down with coding that all up myself, like...immediately

Ooooo, that looks nice.

[SirJodelstein]

I like where this is going.

@ SirJodelstein

I had an idea last night as to how we might get the best of both worlds here. How about the following:

What if instead of ATC_SETTINGS pointing to files, it points to tree config-nodes, so it would look something like this by default:

ATC_SETTINGS
{
    TechTree = Stock
}

//..

@TechTree[Stock]
{
    @NODE[node2_stability]
    {
	    @title = New Fancy Technology
    }

IMO, this would make things very "Squad-like" in how everything is setup, going a long-way to future-proofing any work tree authors put in, while preserving the kind of flexibility that you're looking for.What do you think? If you're keen on it, I'd be down with coding that all up myself, like...immediately

Yes, lets do this. You write the Stock-Tree-Dumper class and make sure that it can be called before TechChanger starts modifying the nodes? Actually, i think we could just do that every time the plugin starts, writing such a small configfile should not take a noticable amount of PC resources. This way, there is no need to distribute a stock-config with the plugin, and it is automatically future-version proof.

Further, I've decided to axe the "PARTS" section since there already is a proven way of assigning parts to the tech tree via ModuleManager. Single point of data entry, no room for inconsistencies, and less code for ATC that can break.

FC, do you have a GitHub account so i can add you to the project?

[Streetwind]

A TreeLoader replacement has been needed for a long time, and I want to thank you greatly for tackling it (and FlowerChild for helping)!

[FlowerChild]

I like where this is going.

Cool stuff

Yes, lets do this. You write the Stock-Tree-Dumper class and make sure that it can be called before TechChanger starts modifying the nodes? Actually, i think we could just do that every time the plugin starts, writing such a small configfile should not take a noticable amount of PC resources. This way, there is no need to distribute a stock-config with the plugin, and it is automatically future-version proof.

Well, it's a little more complicated than that IMO:

The tree needs to be generated before ModuleManager processes files, rather than before your code processes the tree. Otherwise, on a first run any .cfg file modifications that are done by other mods to the stock tree won't register (which would obviously be "why this no work?" support hell). Now, whether I can insert code before ModuleManager is one question (I suspect I likely could figure that bit out), and another question is whether the stock tree is even initialized at that stage (and I suspect it isn't which would be a much bigger problem).

I'm also wondering if shipping ATC without the .cfg file already present might just result in confusion as that's what people will be likely using as a reference in their own modding work.

Really though, if we go with a pregenerated file, what I'm thinking is that this would be a couple of minutes work with each new vanilla release (so every few months) to uncomment the code that dumps the file and run KSP once to get it to execute. If it comes to that I'm willing to take responsibility for maintaining that file myself.

I'll get right on the base tree-dumper right away though, and submit a pull request with it soon as I'm done so you can find me on github (My user name is "FlowerChildX" over there). After that's done we can decide where precisely it winds up being called.

Edited September 11, 2014 by FlowerChild

[landeTLS]

This is pretty cool. Iwe been waiting for someone to make something like this. Tho its the new node function im mostly waiting for.

[FlowerChild]

This is pretty cool. Iwe been waiting for someone to make something like this. Tho its the new node function im mostly waiting for.

You'd be surprised what you can do with just the stock nodes, especially considering the 8 additional invisible nodes that Squad included (more info here if you didn't know about those: http://forum.kerbalspaceprogram.com/threads/53025)

IMO, the stock tree actually has way too many nodes as there just aren't enough stock parts to make purchasing each of the nodes worthwhile. Granted, this changes as you integrate more mods into the tree, but through consolidating some of the more useless stock purchases, you wind up with a whole lot of wiggle room in terms of extra nodes to play with.

Anyways, what's already in this mod is already beyond what I personally need for BTSM. If anything, I'm most looking forward to being able to delete some extraneous nodes rather than add any

[Ixonal]

makin me wanna actually install visual studio on this machine to help out...

[FlowerChild]

Here's the output on the stock tree dump I was talking about:

// Config file representing the stock tech tree
// WARNING: This file should not be edited directly, but rather should either be altered using ModuleManager commands within your own .cfg files OR
// a new tree .cfg should be created which settings.cfg can then be set to point to.

TECH_TREE
{
	name = stock
	TECH_NODE
	{
		name = node0_start
		title = Start
		description = The technology we started out with.
		scienceCost = 0
		icon = START
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -2022.448
		posY = 896.566
	}
	TECH_NODE
	{
		name = node2_generalRocketry
		title = General Rocketry
		description = More engines, more fuel, more ambitious ideas.
		scienceCost = 20
		icon = GENERALROCKETRY
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1652.237
		posY = 1074.484
		PARENT_NODE
		{
			name = node1_basicRocketry
		}
	}
	TECH_NODE
	{
		name = node2_survivability
		title = Survivability
		description = The art and science of landing and walking away from it.
		scienceCost = 15
		icon = SURVIVABILITY
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1732.888
		posY = 699.7489
		PARENT_NODE
		{
			name = node1_basicRocketry
		}
	}
	TECH_NODE
	{
		name = node1_basicRocketry
		title = Basic Rocketry
		description = How hard can Rocket Science be anyway?
		scienceCost = 5
		icon = BASICROCKETRY
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1901.18
		posY = 896.566
		PARENT_NODE
		{
			name = node0_start
		}
	}
	TECH_NODE
	{
		name = node2_stability
		title = Stability
		description = Reaching for the stars starts with keeping our spacecraft pointed generally in the right direction.
		scienceCost = 18
		icon = STABILITY
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1693.861
		posY = 896.566
		PARENT_NODE
		{
			name = node1_basicRocketry
		}
	}
	TECH_NODE
	{
		name = node3_advRocketry
		title = Advanced Rocketry
		description = A new step ahead in rocket technology.
		scienceCost = 45
		icon = ADVROCKETRY
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1469.98
		posY = 1184.784
		PARENT_NODE
		{
			name = node2_generalRocketry
		}
	}
	TECH_NODE
	{
		name = node3_scienceTech
		title = Science Tech
		description = We are going to ask all the big questions of the Universe... eventually. For now, we're starting with these.
		scienceCost = 45
		icon = SCIENCETECH
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1469.98
		posY = 580.6995
		PARENT_NODE
		{
			name = node2_survivability
		}
	}
	TECH_NODE
	{
		name = node3_generalConstruction
		title = General Construction
		description = New equipment to help out in keeping things stable, especially useful when the size of the spacecraft defies the current bounds of sanity.
		scienceCost = 45
		icon = GENERALCONSTRUCTION
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1469.98
		posY = 1037.423
		PARENT_NODE
		{
			name = node2_generalRocketry
		}
		PARENT_NODE
		{
			name = node2_stability
		}
	}
	TECH_NODE
	{
		name = node3_flightControl
		title = Flight Control
		description = Tumbling out of control may be fun, but our engineers insist there's more to rocket science than that.
		scienceCost = 45
		icon = FLIGHTCONTROL
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1469.98
		posY = 796.7432
		PARENT_NODE
		{
			name = node2_stability
		}
		PARENT_NODE
		{
			name = node2_survivability
		}
	}
	TECH_NODE
	{
		name = node4_advConstruction
		title = Advanced Construction
		description = New advances in construction make it possible to build larger than ever before.
		scienceCost = 90
		icon = ADVCONSTRUCTION
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1247
		posY = 1037.251
		PARENT_NODE
		{
			name = node3_generalConstruction
		}
	}
	TECH_NODE
	{
		name = node4_advFlightControl
		title = Advanced Flight Control
		description = The latest advancements in keeping the correct end of the ship pointing towards where you want it to go.
		scienceCost = 90
		icon = ADVFLIGHTCONTROL
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1247
		posY = 796.7432
		PARENT_NODE
		{
			name = node3_flightControl
		}
	}
	TECH_NODE
	{
		name = node4_electrics
		title = Electrics
		description = We did know about electricity before inventing space flight. The big breakthrough here was combining the two.
		scienceCost = 90
		icon = ELECTRICS
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1247
		posY = 665.3614
		PARENT_NODE
		{
			name = node3_flightControl
		}
		PARENT_NODE
		{
			name = node3_scienceTech
		}
	}
	TECH_NODE
	{
		name = node4_spaceExploration
		title = Space Exploration
		description = To boldly go where no green man has gone before.
		scienceCost = 90
		icon = EVATECH
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1247
		posY = 580.6476
		PARENT_NODE
		{
			name = node3_scienceTech
		}
	}
	TECH_NODE
	{
		name = node4_landing
		title = Landing
		description = Our Engineers are nothing if not optimistic.
		scienceCost = 90
		icon = ADVLANDING
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1247
		posY = 493
		PARENT_NODE
		{
			name = node3_scienceTech
		}
	}
	TECH_NODE
	{
		name = node4_heavyRocketry
		title = Heavy Rocketry
		description = The next logical step for rocketry technology is to just go bigger.
		scienceCost = 90
		icon = HEAVYROCKETRY
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1247
		posY = 1249
		PARENT_NODE
		{
			name = node3_advRocketry
		}
	}
	TECH_NODE
	{
		name = node4_fuelSystems
		title = Fuel Systems
		description = Advancements towards a better understanding of how fuel flows through a rocket.
		scienceCost = 90
		icon = FUELSYSTEMS
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1247
		posY = 1121
		PARENT_NODE
		{
			name = node3_advRocketry
		}
		PARENT_NODE
		{
			name = node3_generalConstruction
		}
	}
	TECH_NODE
	{
		name = node5_advExploration
		title = Advanced Exploration
		description = They are Self-Deploying Astronaut Mobility Enhancement Devices, I don't know what you mean by "ladders".
		scienceCost = 160
		icon = ADVEXPLORATION
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1043
		posY = 580.8679
		PARENT_NODE
		{
			name = node4_electrics
		}
		PARENT_NODE
		{
			name = node4_spaceExploration
		}
	}
	TECH_NODE
	{
		name = node5_precisionEngineering
		title = Precision Engineering
		description = Precise engineering techniques allow for construction of ever smaller parts.
		scienceCost = 160
		icon = PRECISIONENGINEERING
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1043
		posY = 753.5361
		PARENT_NODE
		{
			name = node4_advFlightControl
		}
		PARENT_NODE
		{
			name = node4_electrics
		}
	}
	TECH_NODE
	{
		name = node5_advElectrics
		title = Advanced Electrics
		description = We're fairly certain no one will ever need more than 64kw of power for anything.
		scienceCost = 160
		icon = ADVELECTRICS
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1043
		posY = 665.3614
		PARENT_NODE
		{
			name = node4_electrics
		}
	}
	TECH_NODE
	{
		name = node5_specializedControl
		title = Specialized Control
		description = A new state-of-the-art in control technology. 
		scienceCost = 160
		icon = SPECIALIZEDCONTROL
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1045.195
		posY = 844.1075
		PARENT_NODE
		{
			name = node4_aerodynamicSystems
		}
		PARENT_NODE
		{
			name = node4_advFlightControl
		}
	}
	TECH_NODE
	{
		name = node5_heavierRocketry
		title = Heavier Rocketry
		description = There may be an upper limit to how large a rocket can be built, but we're not there yet.
		scienceCost = 160
		icon = HEAVIERROCKETRY
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1043
		posY = 1249
		PARENT_NODE
		{
			name = node4_heavyRocketry
		}
		PARENT_NODE
		{
			name = node4_fuelSystems
		}
	}
	TECH_NODE
	{
		name = node5_specializedConstruction
		title = Specialized Construction
		description = Specialized construction techniques provide new ways of attaching things together, and detaching things on purpose.
		scienceCost = 160
		icon = SPECIALIZEDCONSTRUCTION
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1043
		posY = 1121
		PARENT_NODE
		{
			name = node4_fuelSystems
		}
		PARENT_NODE
		{
			name = node4_advConstruction
		}
	}
	TECH_NODE
	{
		name = node4_aerodynamicSystems
		title = Aerodynamics
		description = New breakthroughs from C7 Aerospace allow for new types of craft to be built. We're looking into hiring some of their engineers as well.
		scienceCost = 90
		icon = AERODYNAMICSYSTEMS
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1247
		posY = 897.689
		PARENT_NODE
		{
			name = node3_generalConstruction
		}
		PARENT_NODE
		{
			name = node3_flightControl
		}
	}
	TECH_NODE
	{
		name = node5_advLanding
		title = Advanced Landing
		description = Further advances in landing devices, allowing for more controlled descents and a much higher number of parts still attached to the ship after touchdown.
		scienceCost = 160
		icon = LANDING
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -1043
		posY = 493.0854
		PARENT_NODE
		{
			name = node4_landing
		}
	}
	TECH_NODE
	{
		name = node7_metaMaterials
		title = Meta-Materials
		description = An advancemement in spacecraft construction so revolutionary, you won't even mind that its naming was wildly inaccurate.
		scienceCost = 550
		icon = METAMATERIALS
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -635
		posY = 1121
		PARENT_NODE
		{
			name = node6_advMetalWorks
		}
		PARENT_NODE
		{
			name = node6_composites
		}
	}
	TECH_NODE
	{
		name = node7_heavyAerodynamics
		title = Heavy Aerodynamics
		description = Advances in construction technology enabled new breakthroughs in aerospace materials. 
		scienceCost = 550
		icon = HEAVYAERODYNAMICS
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -635
		posY = 969.6069
		PARENT_NODE
		{
			name = node6_composites
		}
		PARENT_NODE
		{
			name = node6_advAerodynamics
		}
	}
	TECH_NODE
	{
		name = node6_composites
		title = Composites
		description = Lightweight and strong! and don't worry, we're sure the glue will dry off in no time.
		scienceCost = 300
		icon = COMPOSITES
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -832.9991
		posY = 1037.229
		PARENT_NODE
		{
			name = node5_actuators
		}
	}
	TECH_NODE
	{
		name = node6_fieldScience
		title = Field Science
		description = Freedom to roam as far as curiosity will take you, or as long as batteries last.
		scienceCost = 300
		icon = FIELDSCIENCE
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -832.9991
		posY = 532.4777
		PARENT_NODE
		{
			name = node5_advExploration
		}
		PARENT_NODE
		{
			name = node5_advLanding
		}
	}
	TECH_NODE
	{
		name = node6_nuclearPropulsion
		title = Nuclear Propulsion
		description = Nuclear engines don't burn fuel, they totally annihilate it. We just hope it doesn't begin any conflicts.
		scienceCost = 300
		icon = NUCLEARPROPULSION
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -832.9991
		posY = 1184.784
		PARENT_NODE
		{
			name = node5_heavierRocketry
		}
		PARENT_NODE
		{
			name = node5_specializedConstruction
		}
	}
	TECH_NODE
	{
		name = node6_ionPropulsion
		title = Ion Propulsion
		description = Turns out, it's not science fiction.
		scienceCost = 300
		icon = IONPROPULSION
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -832.9991
		posY = 722.2196
		PARENT_NODE
		{
			name = node5_precisionEngineering
		}
		PARENT_NODE
		{
			name = node5_advElectrics
		}
	}
	TECH_NODE
	{
		name = node7_veryHeavyRocketry
		title = Very Heavy Rocketry
		description = While ever-larger rockets may not be the answer every time, for all other times, we've developed these.
		scienceCost = 550
		icon = VERYHEAVYROCKETRY
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -635
		posY = 1249
		PARENT_NODE
		{
			name = node5_heavierRocketry
		}
		PARENT_NODE
		{
			name = node6_nuclearPropulsion
		}
	}
	TECH_NODE
	{
		name = node5_supersonicFlight
		title = Supersonic Flight
		description = A new line of aircraft parts that allow for unprecedented maneuverability and speed. 
		scienceCost = 160
		icon = SUPERSONICFLIGHT
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1043
		posY = 932.9431
		PARENT_NODE
		{
			name = node4_advConstruction
		}
		PARENT_NODE
		{
			name = node4_aerodynamicSystems
		}
	}
	TECH_NODE
	{
		name = node6_largeElectrics
		title = Large Electrics
		description = Maximize your energy production and storage potential by maximizing the size of the electrical components on your vessels.
		scienceCost = 300
		icon = LARGEELECTRICS
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -832.9991
		posY = 665.3614
		PARENT_NODE
		{
			name = node5_advElectrics
		}
	}
	TECH_NODE
	{
		name = node6_electronics
		title = Electronics
		description = Hopefully these won't become obsolete in the next couple of months.
		scienceCost = 300
		icon = ELECTRONICS
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -832.9991
		posY = 607.9579
		PARENT_NODE
		{
			name = node5_advElectrics
		}
	}
	TECH_NODE
	{
		name = node6_highAltitudeFlight
		title = High Altitude Flight
		description = New breakthroughs in engine and intake development to enable flying through the upper reaches of the atmosphere.
		scienceCost = 300
		icon = HIGHALTITUDEFLIGHT
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -832.9991
		posY = 897.7428
		PARENT_NODE
		{
			name = node5_supersonicFlight
		}
		PARENT_NODE
		{
			name = node5_specializedControl
		}
	}
	TECH_NODE
	{
		name = node6_unmannedTech
		title = Unmanned Tech
		description = Warning: May contain traces of sentience.
		scienceCost = 300
		icon = UNMANNEDTECH
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -832.9991
		posY = 788.2225
		PARENT_NODE
		{
			name = node5_precisionEngineering
		}
	}
	TECH_NODE
	{
		name = node6_largeControl
		title = Large Control
		description = A newer state-of-the-art in control technology. 
		scienceCost = 300
		icon = LARGECONTROL
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -832.9991
		posY = 844.1075
		PARENT_NODE
		{
			name = node5_specializedControl
		}
	}
	TECH_NODE
	{
		name = node6_advMetalWorks
		title = Advanced MetalWorks
		description = These new construction techniques allow for craft designs that were considered insane not too long ago... and still are. But they're now possible!
		scienceCost = 300
		icon = ADVMETALWORKS
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -832.9991
		posY = 1121
		PARENT_NODE
		{
			name = node5_actuators
		}
		PARENT_NODE
		{
			name = node5_specializedConstruction
		}
	}
	TECH_NODE
	{
		name = node7_advancedMotors
		title = Advanced Motors
		description = Wheel technology is just rolling along now. You could even say our engineers are on a roll with it.
		scienceCost = 550
		icon = ADVANCEDMOTORS
		anyParentUnlocks = False
		hideIfNoparts = False
		posX = -635
		posY = 500
		PARENT_NODE
		{
			name = node6_fieldScience
		}
	}
	TECH_NODE
	{
		name = node7_hypersonicFlight
		title = Hypersonic Flight
		description = Push your aircraft to the upper limits of airspeed and sanity.
		scienceCost = 550
		icon = HYPERSONICFLIGHT
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -635
		posY = 897.7428
		PARENT_NODE
		{
			name = node6_highAltitudeFlight
		}
		PARENT_NODE
		{
			name = node6_advAerodynamics
		}
	}
	TECH_NODE
	{
		name = node5_actuators
		title = Actuators
		description = Perfecting the art of making things mobile, without the explicit use of explosives. Our engineers assure us, this is actually a good thing.
		scienceCost = 160
		icon = GENERIC
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -1043
		posY = 1037.229
		PARENT_NODE
		{
			name = node4_advConstruction
		}
	}
	TECH_NODE
	{
		name = node7_specializedElectrics
		title = Specialized Electrics
		description = Experience the warm glow of the latest in electrical technology. Figuratively, of course, and maybe also quite literally as well. Actually, try to avoid direct exposure.
		scienceCost = 550
		icon = SPECIALIZEDELECTRICS
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -635
		posY = 665.3614
		PARENT_NODE
		{
			name = node6_largeElectrics
		}
		PARENT_NODE
		{
			name = node6_electronics
		}
	}
	TECH_NODE
	{
		name = node7_advUnmanned
		title = Advanced Unmanned Tech
		description = Improvements in remote control technology for a new generation of probe designs.
		scienceCost = 550
		icon = ADVUNMANNED
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -635
		posY = 788.4528
		PARENT_NODE
		{
			name = node6_largeControl
		}
		PARENT_NODE
		{
			name = node6_unmannedTech
		}
	}
	TECH_NODE
	{
		name = node7_advScienceTech
		title = Advanced Science Tech
		description = Scientific advancements allow new advanced technologies for advancing Science.
		scienceCost = 550
		icon = ADVSCIENCETECH
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -635
		posY = 574.0369
		PARENT_NODE
		{
			name = node6_electronics
		}
		PARENT_NODE
		{
			name = node6_fieldScience
		}
	}
	TECH_NODE
	{
		name = node6_advAerodynamics
		title = Advanced Aerodynamics
		description = Advances in fluid dynamics research technology have allowed development of a new set of streamlined aircraft components, And also these parts here.
		scienceCost = 300
		icon = ADVAERODYNAMICS
		anyParentUnlocks = True
		hideIfNoparts = False
		posX = -832.9991
		posY = 969.6069
		PARENT_NODE
		{
			name = node5_actuators
		}
		PARENT_NODE
		{
			name = node5_supersonicFlight
		}
	}
	TECH_NODE
	{
		name = node8_experimentalRocketry
		title = Experimental Rocketry
		description = Don't take "experimental" lightly.
		scienceCost = 1000
		icon = EXPERIMENTALROCKETRY
		anyParentUnlocks = False
		hideIfNoparts = True
		posX = -475.6188
		posY = 1249
		PARENT_NODE
		{
			name = node7_veryHeavyRocketry
		}
		PARENT_NODE
		{
			name = node7_metaMaterials
		}
	}
	TECH_NODE
	{
		name = node8_aerospaceTech
		title = Aerospace Tech
		description = The absolute cutting-edge in aerospace technology. Quite literally, some of those edges are very sharp. Handle with care.
		scienceCost = 1000
		icon = AEROSPACETECH
		anyParentUnlocks = False
		hideIfNoparts = True
		posX = -475.6188
		posY = 897.7428
		PARENT_NODE
		{
			name = node7_hypersonicFlight
		}
	}
	TECH_NODE
	{
		name = node8_experimentalElectrics
		title = Experimental Electrics
		description = The very latest in electrical systems technology. Our engineers are buzzing with excitement over it. They also seem to glow in the dark now. Fascinating!
		scienceCost = 1000
		icon = EXPERIMENTALELECTRICS
		anyParentUnlocks = False
		hideIfNoparts = True
		posX = -475.6188
		posY = 665.3614
		PARENT_NODE
		{
			name = node7_specializedElectrics
		}
	}
	TECH_NODE
	{
		name = node8_experimentalAerodynamics
		title = Experimental Aerodynamics
		description = Winged flight technology is soaring to unprecendented heights. It could even be said that it's properly taking off now.
		scienceCost = 1000
		icon = EXPERIMENTALAERODYNAMICS
		anyParentUnlocks = False
		hideIfNoparts = True
		posX = -475.6188
		posY = 969.6069
		PARENT_NODE
		{
			name = node7_heavyAerodynamics
		}
	}
	TECH_NODE
	{
		name = node8_experimentalScience
		title = Experimental Science
		description = Explore novel fields of science that we didn't even know were there. 
		scienceCost = 1000
		icon = EXPERIMENTALSCIENCE
		anyParentUnlocks = False
		hideIfNoparts = True
		posX = -475.6188
		posY = 574.0369
		PARENT_NODE
		{
			name = node7_advScienceTech
		}
	}
	TECH_NODE
	{
		name = node8_experimentalMotors
		title = Experimental Motors
		description = The latest breakthroughs that are driving motor technology forwards, and in reverse, and steering too.
		scienceCost = 1000
		icon = EXPERIMENTALMOTORS
		anyParentUnlocks = False
		hideIfNoparts = True
		posX = -475.6188
		posY = 500
		PARENT_NODE
		{
			name = node7_advancedMotors
		}
	}
	TECH_NODE
	{
		name = node8_robotics
		title = Robotics
		description = The rumours of robot-led world domination are greatly exaggerated.
		scienceCost = 1000
		icon = ROBOTICS
		anyParentUnlocks = False
		hideIfNoparts = True
		posX = -475.6188
		posY = 744.2099
		PARENT_NODE
		{
			name = node7_advUnmanned
		}
	}
	TECH_NODE
	{
		name = node8_automation
		title = Automation
		description = We can't think of anything that could go wrong with letting an experimental AI handle every aspect of a mission.
		scienceCost = 1000
		icon = AUTOMATION
		anyParentUnlocks = False
		hideIfNoparts = True
		posX = -475.6188
		posY = 827.1248
		PARENT_NODE
		{
			name = node7_advUnmanned
		}
	}
	TECH_NODE
	{
		name = node8_nanolathing
		title = Nanolathing
		description = The very latest in construction technology.
		scienceCost = 1000
		icon = NANOLATHING
		anyParentUnlocks = False
		hideIfNoparts = True
		posX = -475.6188
		posY = 1037.222
		PARENT_NODE
		{
			name = node6_composites
		}
	}
	BODY_SCIENCE_PARAMS
	{
		name = Sun
		LandedDataValue = 1
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 11
		InSpaceHighDataValue = 2
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 1E+09
		RecoveryValue = 4
	}
	BODY_SCIENCE_PARAMS
	{
		name = Kerbin
		LandedDataValue = 0.3
		SplashedDataValue = 0.4
		FlyingLowDataValue = 0.7
		FlyingHighDataValue = 0.9
		InSpaceLowDataValue = 1
		InSpaceHighDataValue = 1.5
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 250000
		RecoveryValue = 1
	}
	BODY_SCIENCE_PARAMS
	{
		name = Mun
		LandedDataValue = 4
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 3
		InSpaceHighDataValue = 2
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 60000
		RecoveryValue = 2
	}
	BODY_SCIENCE_PARAMS
	{
		name = Minmus
		LandedDataValue = 5
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 4
		InSpaceHighDataValue = 2.5
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 30000
		RecoveryValue = 2.5
	}
	BODY_SCIENCE_PARAMS
	{
		name = Moho
		LandedDataValue = 10
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 8
		InSpaceHighDataValue = 7
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 80000
		RecoveryValue = 7
	}
	BODY_SCIENCE_PARAMS
	{
		name = Eve
		LandedDataValue = 8
		SplashedDataValue = 8
		FlyingLowDataValue = 6
		FlyingHighDataValue = 6
		InSpaceLowDataValue = 7
		InSpaceHighDataValue = 5
		flyingAltitudeThreshold = 22000
		spaceAltitudeThreshold = 400000
		RecoveryValue = 5
	}
	BODY_SCIENCE_PARAMS
	{
		name = Duna
		LandedDataValue = 8
		SplashedDataValue = 1
		FlyingLowDataValue = 5
		FlyingHighDataValue = 5
		InSpaceLowDataValue = 7
		InSpaceHighDataValue = 5
		flyingAltitudeThreshold = 12000
		spaceAltitudeThreshold = 140000
		RecoveryValue = 5
	}
	BODY_SCIENCE_PARAMS
	{
		name = Ike
		LandedDataValue = 8
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 7
		InSpaceHighDataValue = 5
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 50000
		RecoveryValue = 5
	}
	BODY_SCIENCE_PARAMS
	{
		name = Jool
		LandedDataValue = 30
		SplashedDataValue = 1
		FlyingLowDataValue = 12
		FlyingHighDataValue = 9
		InSpaceLowDataValue = 7
		InSpaceHighDataValue = 6
		flyingAltitudeThreshold = 120000
		spaceAltitudeThreshold = 4000000
		RecoveryValue = 6
	}
	BODY_SCIENCE_PARAMS
	{
		name = Laythe
		LandedDataValue = 14
		SplashedDataValue = 12
		FlyingLowDataValue = 11
		FlyingHighDataValue = 10
		InSpaceLowDataValue = 9
		InSpaceHighDataValue = 8
		flyingAltitudeThreshold = 10000
		spaceAltitudeThreshold = 200000
		RecoveryValue = 8
	}
	BODY_SCIENCE_PARAMS
	{
		name = Vall
		LandedDataValue = 12
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 9
		InSpaceHighDataValue = 8
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 90000
		RecoveryValue = 8
	}
	BODY_SCIENCE_PARAMS
	{
		name = Bop
		LandedDataValue = 12
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 9
		InSpaceHighDataValue = 8
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 25000
		RecoveryValue = 8
	}
	BODY_SCIENCE_PARAMS
	{
		name = Tylo
		LandedDataValue = 12
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 10
		InSpaceHighDataValue = 8
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 250000
		RecoveryValue = 8
	}
	BODY_SCIENCE_PARAMS
	{
		name = Gilly
		LandedDataValue = 9
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 8
		InSpaceHighDataValue = 6
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 6000
		RecoveryValue = 6
	}
	BODY_SCIENCE_PARAMS
	{
		name = Pol
		LandedDataValue = 12
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 9
		InSpaceHighDataValue = 8
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 22000
		RecoveryValue = 8
	}
	BODY_SCIENCE_PARAMS
	{
		name = Dres
		LandedDataValue = 8
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 7
		InSpaceHighDataValue = 6
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 25000
		RecoveryValue = 6
	}
	BODY_SCIENCE_PARAMS
	{
		name = Eeloo
		LandedDataValue = 15
		SplashedDataValue = 1
		FlyingLowDataValue = 1
		FlyingHighDataValue = 1
		InSpaceLowDataValue = 12
		InSpaceHighDataValue = 10
		flyingAltitudeThreshold = 18000
		spaceAltitudeThreshold = 60000
		RecoveryValue = 10
	}
}

A few notes:

-I exposed the hideIfNoparts flag within the nodes as this effectively allows you to delete nodes from an existing tree by getting rid of the parts inside and setting this flag.

-I changed stuff like "celestialBody" and "gameObjectName" parameters to the more generic "name" because this allows for using standard ModuleManager syntax like "@BODY_SCIENCE_PARAMS[Kerbin]" or "@TECH_NODE[node1_basicRocketry]"

-I ordered the output by tech level to make the file a little easier to navigate. Unfortunately I couldn't figure out how to insert any white-space into config nodes which is why the formatting is so dense

-I've moved parent node dependencies into their own individual config nodes as this allows for stuff like manipulating individual node dependencies with commands like "!PARENT_NODE[node1_basicRocketry]" (to say delete an individual parent relationship), and because it allows for additional parameters to be associated with each parent (like, I'd still really like to get the ability to manually specify where the arrows appear for connections).

-I decided to include the planet science params in the tech tree itself, as this allows for stuff like specific tech trees for RSS or what have you, where the bodies may have completely different names. I figure individual trees will be balanced around those kind of values so I think it makes sense to associate them directly, and if someone wants to blanket edit them across all trees there is always the "@TECH_TREE[*]" catch-all available. I'm still not convinced on whether these values should go in or outside the tree mind you, so if anyone has any feelings on that point, I'd love to hear them.

If anything seems out of whack, let me know, as the next thing I'll be working on is adapting the existing ATC code to read in the above style of .cfg files.

[sgt_flyer]

Here's the output on the stock tree dump I was talking about:

A few notes:

-I exposed the hideIfNoparts flag within the nodes as this effectively allows you to delete nodes from an existing tree by getting rid of the parts inside and setting this flag.

-I changed stuff like "celestialBody" and "gameObjectName" parameters to the more generic "name" because this allows for using standard ModuleManager syntax like "@BODY_SCIENCE_PARAMS[Kerbin]" or "@TECH_NODE[node1_basicRocketry]"

-I ordered the output by tech level to make the file a little easier to navigate. Unfortunately I couldn't figure out how to insert any white-space into config nodes which is why the formatting is so dense

-I've moved parent node dependencies into their own individual config nodes as this allows for stuff like manipulating individual node dependencies with commands like "!PARENT_NODE[node1_basicRocketry]" (to say delete an individual parent relationship), and because it allows for additional parameters to be associated with each parent (like, I'd still really like to get the ability to manually specify where the arrows appear for connections).

-I decided to include the planet science params in the tech tree itself, as this allows for stuff like specific tech trees for RSS or what have you, where the bodies may have completely different names. I figure individual trees will be balanced around those kind of values so I think it makes sense to associate them directly, and if someone wants to blanket edit them across all trees there is always the "@TECH_TREE[*]" catch-all available. I'm still not convinced on whether these values should go in or outside the tree mind you, so if anyone has any feelings on that point, I'd love to hear them.

If anything seems out of whack, let me know, as the next thing I'll be working on is adapting the existing ATC code to read in the above style of .cfg files.

so, you're going to make the arrows default origin the right side of the nodes and default endpoint the left side of the nodes (in case it's not precised into the tree ?)

[FlowerChild]

so, you're going to make the arrows default origin the right side of the nodes and default endpoint the left side of the nodes (in case it's not precised into the tree ?)

No, the intention is to use the auto-node-connection code there that SirJodelstein has already written up, but I'd like there to be a way to also manually specify which sides you want them to attach to so you can override that behavior if you like.

[FlowerChild]

Just committed a whack of changes to github. Kept track of them as I went, so here's the change log:

-Added ATCTreeDumper to generate config file based on stock tree.

-Added processing of \n newline characters in node descriptions (needed this for BTSM)

-Removed code that clears all part assignments to nodes within LoadTree()

-Added ability to specify if a tech node is hidden in the R&D gui if it contains no parts, just like the hidden config nodes squad included. This effectively adds the ability to remove nodes from the tech tree if you so desire (which I definitely do in BTSM ).

-Switched reading of anyParentUnlocks .cfg entry to use bool.Parse for consistency and to eliminate case sensitivity.

-Split the "REQUIRES" config node into separate "PARENT_NODE" nodes for each parent. This allows for manipulating individual parent node connections with standard ModuleManager syntax (e.g. "@PARENT_NODE[node1_basicRocketry]"), and leaves room for future expansion in assigning specific attributes to node connections (like specifying the side they connect to ).

-Rearranged settings.cfg to support the new tree-node format, and to make it easier to refer to through ModuleManager commands.

-Fixed bug in auto connection assignment code that caused stock tree to display incorrectly. Please see the related (long) comment in the code, as I don't think that the autoassign code is practical overall due to related issues.

I've converted *most* (I still need to migrate my planet science values over) of BTSM's tech-tree changes over to the new format to test out various things, so if anyone is interested what using this thing looks like in practice:

// config file to modify the tech tree using ATC

@TECH_TREE[stock]
{
	@TECH_NODE[*],*
	{
		@anyParentUnlocks = False
	}

	@TECH_NODE[node1_*],*
	{		
		@scienceCost = 4 // 5 stock
	}

	@TECH_NODE[node2_*],*
	{		
		@scienceCost = 16 // 21/16/15 stock
	}

	@TECH_NODE[node3_*],*
	{		
		@scienceCost = 45 // 45 stock
	}

	@TECH_NODE[node4_*],*
	{		
		@scienceCost = 90 // 90 stock
	}

	@TECH_NODE[node5_*],*
	{		
		@scienceCost = 180 // 160 stock
	}

	@TECH_NODE[node6_*],*
	{		
		@scienceCost = 360 // 300 stock
	}

	@TECH_NODE[node7_*],*
	{		
		@scienceCost = 1800 // 550 stock
	}

	@TECH_NODE[node8_*],*
	{		
		@scienceCost = 16000 // 1000 stock
	}

	@TECH_NODE[node0_start]
	{
		@description = Welcome to Better Than Starting Manned!\n\nTIP: If you're having difficulty initially, balancing the weight of your rocket to keep it pointed upwards is key!
	}

	@TECH_NODE[node1_basicRocketry]
	{
		@description = How hard can rocket science be anyways?\n\nTIP: Staging boosters to fire at different times will help you gain altitude!
	}

	@TECH_NODE[node2_generalRocketry]
	{
		@description = More engines, more fuel, more ambitious ideas.\n\nIMPORTANT: Includes improved launch capacity, allowing vehicles up to 25 tons.
		@posX = -1693.861 // align all the tech 2 nodes horizontally

	}

	@TECH_NODE[node2_stability]
	{
		@description = Reaching for the stars starts with keeping our spacecraft pointed in the right direction.\n\nTIP: Using fins to steer your rocket will allow you to reach new heights!
	}

	@TECH_NODE[node2_survivability]
	{
		@posX = -1693.861 // align all the tech 2 nodes horizontally
	}

	@TECH_NODE[node3_generalConstruction]
	{
		@description = New equipment to help keep things stable, especially when spacecraft defy the currents bounds of sanity.\n\nIMPORTANT: Includes 75 ton launch capacity.
	}

	@TECH_NODE[node4_heavyRocketry]
	{
		@title = Fuel Systems
		@description = Advancements towards a better understanding of how fuel flows through a rocket.
		@icon = FUELSYSTEMS
	}

	@TECH_NODE[node4_advConstruction]
	{
		@description = New advances in construction make it possible to build larger than ever before.\n\nIMPORTANT: Includes 250 ton launch capacity.
	}

	@TECH_NODE[node4_fuelSystems]
	{
		@title = Heavy Rocketry
		@description = The next logical step for rocketry technology is to just go bigger.  We've also made refinements to our existing technology along the way.
		@icon = HEAVYROCKETRY
	}

	@TECH_NODE[node4_aerodynamicSystems]
	{
		@description = New breakthroughs from C7 aerospace allow new types of craft to be built.\n\nIMPORTANT: Includes integrated heat shield for the Command Pod Mk1.
	}

	@TECH_NODE[node4_spaceExploration]
	{
		@description = To boldly go where no green man has gone before.\n\nTIP: Having not yet developed space suits, going EVA may be a rather bad idea.
	}

	@TECH_NODE[node5_specializedConstruction]
	{
                @title = Thrust Vectoring
		@description = We noticed awhile ago that aiming rockets in different directions causes them to go that way, so we decided to do something with that.
	}

	@TECH_NODE[node5_advExploration]
	{
		@description = Everything necessary to send Kerbals to the Mun without worrying about getting them back again.\n\nTIP: Research Advanced Landing for space suits.
	}

	@TECH_NODE[node5_advLanding]
	{
		@description = If we're heading to the Mun, these should help with the survivng it bits.\n\nIMPORTANT: Includes space suits, but we still don't have RCS thrusters for them.

		PARENT_NODE
		{
			name = node4_spaceExploration
		}
	}

	@TECH_NODE[node5_actuators]
	{
		@title = Modular Design
		@description = By adopting modular construction techniques we've greatly increased the reliability of our structures.\n\nIMPORTANT: Includes 600 ton launch capacity.
	}

	@TECH_NODE[node6_fieldScience]
	{
		@description = Freedom to roam as far as curiosity will take you, or as long as the batteries last.
	}

	@TECH_NODE[node6_nuclearPropulsion]
	{
		@title = Very Heavy Rocketry
		@description = While ever-larger rockets may not be the answer every time, for all other times, we've developed these.
                @icon = VERYHEAVYROCKETRY
	}

	@TECH_NODE[node6_ionPropulsion]
	{
		@title = Miniaturization
		@description = Ever more refined engineering techniques have allowed us to create parts that will blow your mind without even having to buy them dinner.
                @icon = EXPERIMENTALROCKETRY
	}

	@TECH_NODE[node6_advMetalWorks]
	{
		@title = Refined Rocketry
		@description = The epitome of traditional rocket design.  Are you proud?  You should be, and we don't appreciate our achievements being diminished like that.\n\nIMPORTANT: Includes the ability to tweak fuel pre-flight.
	}

	@TECH_NODE[node6_composites]
	{
		@description = Lightweight and strong! Don't worry...we're sure the glue will dry off in no time.\n\nIMPORTANT: Includes 1,000 ton launch capacity.
	}

	@TECH_NODE[node7_veryHeavyRocketry]
	{
		@title = Experimental Rocketry
		@description = Turns out, it's not science fiction.
                @icon = IONPROPULSION
	}

	@TECH_NODE[node7_metaMaterials]
	{
		@description = An advancement in spacecraft construction so revolutionary, you won't even mind that its naming was wildly inaccurate.\n\nIMPORTANT: Includes 1,500 ton launch capacity.
	}

	@TECH_NODE[node7_heavyAerodynamics]
	{
		@title = Multidisciplinary Studies
		@description = Combining the accumulated knowledge of multiple fields, we have made great strides forward both in what we can achieve, and how we can learn more about the cosmos.
	}

	@TECH_NODE[node7_advUnmanned]
	{
		@title = Not Potatoes
		@description = Ok, we admit it.  We were using potatoes in our batteries.  Let's just move on.
                @icon = EXPERIMENTALELECTRICS

		PARENT_NODE
		{
			name = node6_ionPropulsion
		}
	}

	@TECH_NODE[node7_specializedElectrics]
	{
		PARENT_NODE
		{
			name = node6_ionPropulsion
		}
	}

	@TECH_NODE[node7_advScienceTech]
	{
		@description = Scientific advancements allow new advanced technologies for advancing science.\n\nIMPORTANT: Includes integrated RCS thrusters for space suits.  You're welcome.
	}

	@TECH_NODE[node7_advancedMotors]
	{
		@title = Advanced Field Science
		@description = In case you were still curious: additional roaming goodness beyond what anyone thought healthy, reasonable, or sane.\n\nTIP: The Klaw allows for Asteroid Redirect Missions for added science!
	}

	@TECH_NODE[node8_experimentalRocketry]
	{
		@title = Uber Rockets
		@description = Want to launch insane payloads with little to no effort or rocket design skill?  Then Uber Rockets are the rockets for you!\n\nIMPORTANT: Includes 2,000 ton launch capacity.
                @icon = NUCLEARPROPULSION
	}

	@TECH_NODE[node8_nanolathing]
	{
		@description = Matter to energy conversion and back again, stirred, frothed, and squirted into a tasty beverage?  No problem.
                @icon = PRECISIONENGINEERING

		!PARENT_NODE[node6_composites]
		{
		}

		PARENT_NODE
		{
			name = node7_metaMaterials
		}

		PARENT_NODE
		{
			name = node7_heavyAerodynamics
		}
	}

	@TECH_NODE[node8_aerospaceTech]
	{
		PARENT_NODE
		{
			name = node7_heavyAerodynamics
		}

		PARENT_NODE
		{
			name = node7_advUnmanned
		}
	}

	@TECH_NODE[node8_experimentalElectrics]
	{
		@title = Colonization
		@description = It has been said that Kerbin is the cradle of Kerbality, and there is only so long you can live in the cradle before you start developing a rash.
                @icon = START

		PARENT_NODE
		{
			name = node7_advUnmanned
		}

		PARENT_NODE
		{
			name = node7_advScienceTech
		}

		PARENT_NODE
		{
			name = node7_advancedMotors
		}
	}

	@TECH_NODE[node8_experimentalMotors]
	{
		@title = Science Fiction
                @icon = EXPERIMENTALSCIENCE
	}
}

Edited September 13, 2014 by FlowerChild

[SirJodelstein]

Just committed a whack of changes to github.

Yes, thanks!

-Fixed bug in auto connection assignment code that caused stock tree to display incorrectly. Please see the related (long) comment in the code, as I don't think that the autoassign code is practical overall due to related issues.

It is still practical, but a correct topological ordering is required for processing the anchors. My simple recursive search ignored the fact that some nodes have multiple parents. I'll fix that in the next commit.