anonish

And you are positive the default wasn't 'None (disable TechManager)'? Because that starts selected, and while selected, the other trees are not displayed. The trees are loaded at the main menu, and the selection dialog is populated once, before it is shown. I won't rule anything out, I just don't know how it could be doing what you describe. Screenshot if you get a chance?

thank you for the extra info xfrankie, I'll be taking a closer look when i get home.

Do you mean parts you get access to as part of a test contract? Where you normally wouldn't be able to build with them but the game is giving you an exception because of the contract and is shows up blue in the VAB? Gotta admit, I didn't even think to test that. What mods did you have installed, which trees selected and what was the missing part?

so, you start a game. it asks you to select your trees, but there are none? And this is not 'None' being selected? (when none is selected, it doesn't show options). Then when you click the empty space below none it shows up? I'll have to think about that. No idea at the moment.

Nertea, if you are interested in having the tree reside in GameData instead of the save game folder (like a proper mod), then the whole config should be wrapped in one more layer of confignode, like: TECHNOLOGY_TREE_DEFINITION { id = CCT_Version1 label = This is the awesome Community Tech Tree! <the rest of the config> } The id is to identify the tree, the label is what will show up at the start of a game for tree selection and in the R&D center drop down to jump between chosen trees. I tried it out.. Looks like some nodes aren't defined, stock nodes. This causes TechManager to remove those parent references and you end up with this: If you aren't targeting TechManager, no problem. If you are, you'll need to define those nodes (and get rid of that REMOVENODE entry). If you want to only *reference* those techs, but have them researchable in another tree (I very much doubt it), use the 'external' field on the nodes representing them. EDIT: oh, you'll need TM 1.2 for the multi-tree ability (and to load using TECHNOLOGY_TREE_DEFINITION instead of just a tree.cfg in the save game folder)

7 downloads of the 1.2 test and no complaints, so i have released version 1.2 on [Moderator removed defunct website link]. I'll try to stay on top of any bugs that pop up, but I think i'm done with features now.

edit: 1.2 pushed to kerbalstuff.com

allow me to quote the installation.txt file that comes with the mod:

I just posted there (one minute before your post here). Hopefully I'll try it out soon.

Hello. I'm the developer of the TechManager mod. I just heard of this tree today, so I haven't tried it out yet, but if it worked with TreeLoader it should work with TM. I recently added sub-tree support and in-game tree switching which you may be interested in, although that hasn't been released yet. Would love some feedback if you think you could use something like that. I've been trying to help the ATC guys out, but outside of telling them to do exactly what I do, I'm not sure what is preventing their nodes from showing up, and really I've been buried on my own mod. If there is a feature of ATC you like that I'm missing (custom anchors?) then maybe I can roll that into TM. Thanks.

Fixed the earlier posted problem. I force a rendering of the node if its tech has been researched, even if the current tree you are looking at shows it as having unfulfilled dependencies. I revamped the tree selection process. You now choose from a list at the start of the game, instead of just picking one. That list of what you choose is then what's available in the drop down while on the R&D screen. I think this gives a better feel to the gameplay, as you aren't constantly being given options for tech trees you didn't want to use for that particular save game. Added a new feature. There is now an 'external' property that can be set in a tech tree node. This is essentially a way to reference only the techs that you want from another tree. Let's say i wanted to reference Ultra-High Energy Physics from the KSPI tree, but I didn't want to allow it to be researchable from my tree. That way, I don't have to worry about parts, or science cost, or its parents, just if its been researched or not. Such an external node has no parents, and you can't click on it to peak at what it is before you research it. But, once its researched in another tree, it acts more like a normal node. You can look at it and use it as a dependency for later nodes. The idea here is to allow for a real sub-tree implementation. You can start your sub-tree with external nodes derived from the stock tree, the CTT, or whatever 'base' tree you would like, and then build from there. No need to include the entire tree from Start all the way to the few nodes you want to add. And the player still gets visual feedback -- they see a gray node that 'needs to be researched' before they can continue on the sub-tree. (Without the 'external' property, any node that doesn't have parents is automatically researchable. You can see how that would be a game breaking problem for sub-trees.) Hope that makes sense, let me know what you think. I think I'm ready for another release now, but i'll double check things first, after some sleep. Fractal_UK, I would *really* like to get rid of part assignments as a part of the tree definitions. They can clash horribly. If one part is assigned to multiple techs in different trees, there is no obvious way to resolve that. I'd rather part cfg files or MM sorted all the part assignments out before TM ever starts. Part assignment is still in there for now, but its a 'first come, first served' approach. First tree to assign a part wins. Although it is limited to only the trees you select for your game, not all of them. Let me know what you think of moving KSPI to a non-tree-cfg based way of assigning parts.

I'll just add to the chorus and agree that techs and parts should be thought of totally separately. Even in TM they are handled differently and only merged to display the tree. ATC had it right when they didn't include part assignment in their tree mod. Nertea has it right to only be defining techs for CTT. That older tree.cfg files defined both in one place should be considered a historical accident.

Again, its sub-optimal some of the time in some circumstances, not all. It is the best available option in some as well. At least, I'm trying to see if that 's possible. There are certainly still issues to work out. But its not hard at all to imagine small sub-trees that only add a couple techs that branch off of stock (or even CTT), but where the developers don't want to or can't get CTT updated to include those techs. And they definitely wouldn't want to include an all encompassing tree that includes CTT / stock / a bunch of mod's parts they have no control over. Some ability, one way or another, for developers to provide sub-trees could be very useful. In-RD tree switching would avoid the 'you got your tech on my tech' problems as well as allowing everybody to worry about their own techs without having to worry about everyone else's. This is not isolationist. Isolationist would be refusing to consider the CTT, not considering it but choosing to go another way if its a bad fit or unresponsive.

This is the only feedback I've seen so far on tree switching, so I'll reply to this here: It depends. If the mods in question can all play nicely on the CTT, then sure. One tree makes for more integrated gameplay. I'm 100% in favor. For this category though, its a nice option. Especially for mods that come out after the CTT is developed and miss the boat on this. Switching trees really feels quite natural, no different than scrolling over to explore an unfinished branch. As a player, I know I'd much rather switch trees as a natural part of doing research than have a mod's parts shoehorned into the stock tree or the CTT.

I added the drop-down button to the R&D screen (top right corner). You can now jump between tech trees (including stock/native), with nothing stopping you from researching all the techs in each tree. I've got one graphical glitch to fix, and I've got to see if purchased parts go missing between jumps, but i think that's it. Left-Alt-F7 now toggles the visibility of the selection box. I'm still not sure if it should be enabled by default. There is also an odd rendering case: When a tech's parent(s) has been researched in another tree, but the parent(s)'s parents have not been researched in the current tree, it gets shown as 'Researchable' but with arrows going into it that come from nowhere. I could totally isolate each tree, so that 'advanced duct-tape' in one tree is different from 'advanced duct-tape' in another, with only stock nodes being common between them, or just expect the tree makers to 'fix' things, or scrap the tree switching entirely (pick one at start-up and be done). idk. odd case:

I've thought about it to the point that I agree it would be really nice, but I have no idea how to implement it. Somewhere there is bound to be an array or dictionary of textures used for the nodes.. but where and is it possible to extend it? idk. I'll try to take a half decent shot at it maybe this weekend. Right now I want to finish up the tree selector.

I like clean breaks. If you are going to create one node, might as well make them all. Keeps the logic simpler as I don't have to determine what is new and what is a rewrite. Also I don't have to implement a REMOVENODE cfg entry type if someone *doesn't* want a stock node -- in that case, they just don't put it in the file.

Well, i have my combo box where i want it. Shouldn't be too much more to roll in the rest. I set it up so that if there is a tree.cfg in the save game dir, it gets an entry in the selection list. Native does as well (its not really stock.. as MM could have mangled it..) and the rest come from TECHNOLOGY_TREE_DEFINITION nodes.

Fractal_UK, notice how your combobox is flush with the bottom and to the left? I've been working on that, using GUILayout.getRect to reserve some space and changing the interface to combobox. It looks a bit nicer this way, imo, but the extra code is bit heavy for the result. As for the stock option, I was just planning on having TM try this: look for trees in GameDatabase, if there are some, show a selector to choose one, if nothing there check the save dir for tree.cfg, if thats not there, do nothing. I'll obviously look at your new code and go from there.

No. But it is compatible with the KSPI and NearFuture trees. TreeLoader had support for a REMOVENODE entry, so that you could remove a stock node. In TM that's moot because (as undercoveryankee pointed out) you *only* get the techs in the cfg file for TM. This really simplified the logic, and the two big trees had everything defined anyway. Nelien, I've been curious about something and maybe you know, having worked on the converter. How common are the anchor point overrides in ATC cfg files? I *think* that's the only feature ATC has that TM doesn't.

About the worst it can do (assuming no bugs) is cause you to repurchase some parts that move from one tech to another. Make sure treeloader is not installed, stop using that hotpatch, install techmanager, put the tree.cfg in your save game dir and give it a shot. The tree.cfg file defines the techs and how parts are defined to those techs, but if a part isn't mentioned in the cfg, it will continue to be assigned to whatever tech it was at originally. So, if you are using KSPI's tree.cfg (and you likely would be) it would add the KSPI techs and move the KSPI parts, but the other mods' parts would still show up in your stock tree. There is another thread that is trying to create a 'community tree' with the intention of merging KSPI, NearFuture and some other mods. When they are done, it should make for a nice option.

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

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

The two calls to render properly i've seen, the zooming and exception i have not. But those all sound like what i would expect when starting with dirty GameObjects. Did you switch to the clean instantiation i suggested?

I see the community tree being a separate mod. One that has a base tree defined under the TECHNOLOGY_TREE_DEFINITION header that also comes with appropriate MM configs to figure out how to modify itself before TM gets ahold of it. Then its simply chosen from a list of tree's using Fractal_UK's recent addition. The user gets to choose between various static trees that come from the mods individually, or a community tree that tries to do some intelligent merging.