[0.25/0.90] TechManager Version 1.5

[Starstrider42]

So if you take 'random tree rearrangements' out of the equation for a bit, and do a little triage, the right (effective, etc.) thing to do would be to use a shared tree so we don't break eachother. Otherwise you will have stomping again, and everyone loses.

Ok, I misunderstood the scope of the project. If we're sticking to relatively small extensions of the stock tech tree, then most of my comments don't apply. Objection withdrawn, and good luck.

[Rabada]

Thankyou! This is very awesome! I'm excited to see where this leads!

[FreeThinker]

Left-ALT-F7 will perform a load while looking at the tech tree in the R&D building if you want to see the effect of making changes to the file in 'realtime'. If you expect this to work with Interstellar, be sure to remove / do not install the TreeLoader mod.

I removed TreeLoader and tree.cfg is inside safe folder. When I press Left-ALT-F7, nothing seem to happen.

Edited October 30, 2014 by FreeThinker

[Diazo]

Alright. One issue that has come up with my setup is what happens to empty nodes because I did not install all the big mods? I'm talking about the 'unified' tree the other thread is talking about, but this comment is more technical so I'm putting it here.

(I personally have the skills to directly edit the tree.cfg, but a lot of players won't.)

IE: I install Near Future and Karbonite but I don't install Interstellar.

I have two different mods installed (Near Future and Karbonite), each of which presumably comes with their own tree.cfg specific to themselves, but I want both so I use the unified tech tree the community is coming up with. But in doing that, what happens to the nodes that are empty because I don't have Interstellar installed? Do they hide themselves?

Looking at the current implementation, I suppose I'm really asking why use limit the mod to a single tree.cfg found in the save directory? This mod is dealing with adding/removing parts which is done by adding/removing mods. Why do I now have to remember to also edit the tree.cfg in my Save directory when I change the mods I have installed?

While more complicated, would a more modular approach work with a tree.cfg in each mod with the nodes it needs defined? The treeloader mod would itself come with a tree.cfg that covered all the stock node/parts and then any installed mods would have a tree.cfg to extend the tech tree as appropriate for their mod.

This approach does have its own issues of course.

First, this means that some nodes would be defined more then once in different mods. I would think a simple difference check would account for this though, if a node is defined twice, but all the information is equal, no problem, load that node as described. If there is a discrepancy, flag it for the player's attention and (probably) use the first loaded one.

Now, this does mean that there is no unified tech tree .cfg file so mod authors would have to coordinate to make sure their tech trees did work together following the unified tree layout that the community is working to produce in the other thread. But I don't see this being a huge problem, a lot of big names all already on board and so as other people produce alternative tech trees, they are likely to follow the unified tree as well to increase the likelyhood of players downloading their mod as if a mod does not play nice with the big mods, players are more likely to get rid of the small mod then the big mod.

So, thoughts?

D.

Edited October 28, 2014 by Diazo

[RoverDude]

@Diazo

As I recall, the issue (and someone please correct me if I'm wrong) is that right now this mod wipes the tree in favor of your single config... so there's no real way to have multiple configs coexist. Hence the reason why we're looking at pooling together on a set of nodes is that this way, if you install NFT you don't wipe out KSPI, and if you install KSPI you don't wipe out NFT.

Of course, that depends on whether KSPI wants to play ball (i.e. even if Nertea leaves plenty of space for KSPI in a shared structure, if Fractal_UK decides to bundle a KSPI-only set of nodes, we're going to have sadness and someone's going to lose).

To your example, since KSPI isn't on board yet it's really a moot point. But taking any other mods, it would be on us to make sure there are no holes... i.e. I can guarantee for anything a USI mod uses, there will be no gaps in the path. I expect the same is true with NFT, and combine the two we'll fill out more nodes. And if KSPI comes on board, they would need to do the same thing (which is no different than what they do today).

[Diazo]

@RoverDude: I'm not talking about gaps in the path, I'm talking about what happens to empty nodes with no parts installed?

I would certainly prefer a single unified tech tree as that would be so much easier to manage then each mod having its own tree.cfg, but if I don't install any of the life support/base building mods, what happens to the "colonization" tech nodes in the science screen?

I do install Karbonite however and its nodes are all okay, but they are in a different part of the tech tree.

Even if the node simply hid itself if it had no parts would be fine, but handling of some sort needs to be agreed on for empty nodes causing by only some mods being installed.

D.

[Starstrider42]

As I recall, the issue (and someone please correct me if I'm wrong) is that right now this mod wipes the tree in favor of your single config... so there's no real way to have multiple configs coexist. Hence the reason why we're looking at pooling together on a set of nodes is that this way, if you install NFT you don't wipe out KSPI, and if you install KSPI you don't wipe out NFT.

To quote the builder:

Try not to lock yourselves into thinking the end result of this has to 1) be a static tree.cfg file and 2) can only use existing ConfigNode properties

If they want to include ModuleManager support, as they've stated, then the processing flow must change to:

1. KSP compiles a list of all tech tree nodes to GameDatabase
   
2. ModuleManager, if installed, compiles and applies a list of node patches
   
3. TechManager deletes the stock tech tree
   
4. TechManager reconstructs the tech tree using the configs compiled in step 1
   

Which would completely avoid the "wipe out" problem you're describing.

(Mind you, I still support the idea of a common tech tree, but to provide players with a consistent experience rather than to avoid mass clobbering.)

@Diazo, there are any number of ways to prevent trees from getting broken by missing mods. One (letting mods disable the "hidden" flag on any prerequisite nodes they need) will even work with no extra work from anonish besides ModuleManager support. A more complex approach might be to figure out which techs are prerequisites (though with OR prerequisites the correct behavior might be hard to define). In any case, I don't think it's a fundamental problem, more of a feature request.

Edited October 28, 2014 by Starstrider42

[undercoveryankee]

Alright. One issue that has come up with my setup is what happens to empty nodes because I did not install all the big mods? I'm talking about the 'unified' tree the other thread is talking about, but this comment is more technical so I'm putting it here.

(I personally have the skills to directly edit the tree.cfg, but a lot of players won't.)

IE: I install Near Future and Karbonite but I don't install Interstellar.

I have two different mods installed (Near Future and Karbonite), each of which presumably comes with their own tree.cfg specific to themselves, but I want both so I use the unified tech tree the community is coming up with. But in doing that, what happens to the nodes that are empty because I don't have Interstellar installed? Do they hide themselves?

I would expect any empty subtrees to be hidden by default, similar to how the stock 1000-science nodes don't show up until you install parts that use them. We might need a little bit of extra code to enforce the right behavior if an empty node is a prerequisite for an occupied node.

Looking at the current implementation, I suppose I'm really asking why use limit the mod to a single tree.cfg found in the save directory? This mod is dealing with adding/removing parts which is done by adding/removing mods. Why do I now have to remember to also edit the tree.cfg in my Save directory when I change the mods I have installed?

While more complicated, would a more modular approach work with a tree.cfg in each mod with the nodes it needs defined? The treeloader mod would itself come with a tree.cfg that covered all the stock node/parts and then any installed mods would have a tree.cfg to extend the tech tree as appropriate for their mod.

This approach does have its own issues of course.

First, this means that some nodes would be defined more then once in different mods. I would think a simple difference check would account for this though, if a node is defined twice, but all the information is equal, no problem, load that node as described. If there is a discrepancy, flag it for the player's attention and (probably) use the first loaded one.

Now, this does mean that there is no unified tech tree .cfg file so mod authors would have to coordinate to make sure their tech trees did work together following the unified tree layout that the community is working to produce in the other thread. But I don't see this being a huge problem, a lot of big names all already on board and so as other people produce alternative tech trees, they are likely to follow the unified tree as well to increase the likelyhood of players downloading their mod as if a mod does not play nice with the big mods, players are more likely to get rid of the small mod then the big mod.

So, thoughts?

D.

The problem with combining different authors' tree bits is that the author of the config has to know where on the screen to put each node. If we can integrate code to automatically lay out nodes based on which ones are visible and how they're connected, then shipping partial trees with the mods that use them starts to make sense.

As long as each coordinating modder has to be aware of the locations of other participants' nodes, it seems easier to combine all of the added nodes into a single tree.cfg that everyone who's coordinating can distribute, and let any that end up empty just be hidden.

[Diazo]

Hmm, looking at treeloader's source, I see a ".hideIfNoParts" property, it looks like nodes can already be set to hide themselves if they have no parts which would be an okay solution and pretty much takes care of the issue I was worried about.

D.

[anonish]

But in doing that, what happens to the nodes that are empty because I don't have Interstellar installed? Do they hide themselves?

They do if they have they have the hideIfEmpty flag set

The rest of what you say is more or less what I've been thinking and what the community thread is trying to solve. I'll say that is really the better place to discuss this. TechManger will be a tool in the solution, but not all of it. We need to decide how all the involved mods are going to play along. Multiple tree.cfgs? An API? Where are part assignments done? how do we handle empty subtrees? etc.

[anonish]

Diazo:

The hideIfEmpty flag doesn't solve the problem you think it does. What if *that* node is empty, but its child is not? If you hide the node, its child gets hidden as well. I've suggested a hideIfUseless flag to solve the empty *subtree* problem.

StarStrider42:

One point of clarification about TM 'wiping out the tree'. I wipe out the unity GameObjects. Things that represent the graphical icons you actually see on the tree. I do not wipe out the techID's, nor would that even make sense. I just create new 'boxes' that point to the same 'techs'. We are getting really lose with our terms: 'node' and 'tech' are used interchangeably but there really are two different things there. In the tree.cfg file, you are specifying the nodes (as in GameObjects) that will be created, and the techID it points to is a parameter. I don't create those techs (unless they don't exist). Nor do I ever 'erase' techs, even if your cfg file doesn't reference them.

[Fractal_UK]

I have a possible solution for the woes of how you can determine which tree you want to use. This is just the beginning of a possible solution but I have made some changes to the TechManager source code that make it load nodes from a .cfg file in game data instead of in the savegame directory.

You wrap the nodes inside a TECHNOLOGY_TREE_DEFINITION{} node which has an id = to determine which tree it belongs to.

On my current changes, the mod will load only the first tech tree definition but it's pretty trivial to make it able to select between different options. Example node structure:

TECHNOLOGY_TREE_DEFINITION
{
    id = KSPITree
    VERSION
    {
	id = 2
    }
    NODE
    {
	name = newnode_7144
	techID = interstellarTechFusionPower
	pos = -404.5,1175,-18
	icon = NUCLEARPROPULSION
	cost = 3000
	title = Basic Nuclear Fusion
	description = This technology represents the first steps into fusion power using large reactors compressing a plasma with large magnets or initiatiating the reaction with tiny quantities of Antimatter.
	anyParent = False
	hideIfEmpty = False
	parents = node6_nuclearPropulsion,node7_metaMaterials
	PARTS
	{
		name = FNFissionFusionCatReactor
		name = FusionReactor250
		name = FusionReactor375
		name = KSPIMagneticNozzle1
		name = KSPIMagneticNozzle2
		name = KSPIMagneticNozzle3
	}
    }
    NODE
    {
	name = newnode_71440
	techID = interstellarTechFusionPower2
	pos = -321,1063.667,-17
	icon = NUCLEARPROPULSION
	cost = 3000
	title = Advanced Fusion Power
	description = The development of Inertial Confinement fusion technology allows the miniaturisation of fusion power as well as the production of massive new engines that really unlock rapid transit throughout the solar system.
	anyParent = False
	hideIfEmpty = False
	parents = newnode_7144
	PARTS
	{
		name = FusionReactor0625
		name = FusionReactor125
		name = vista
	}
    }

.....


}

https://github.com/FractalUK/TechManager

(anonish, your license is included in the source code)

Edit: Drop down box tech tree selection could be restored pretty easily by showing a selection box for the above nodes instead of FirstOrDefault()-ing

Edited October 28, 2014 by Fractal_UK

[anonish]

Fractal_UK! I'm trying to push the talk into the community tree forum, I know everybody there would love to see you (they've been asking).

What you suggest looks a lot like how ATC works, although I haven't spent much time looking at it. The community thread is trying to take a step back and solve the problem in a more global context that includes the mod developers (again, they'd love you). I hope / intend to modify TechManager as a result of their conclusions.

[Starstrider42]

StarStrider42:

One point of clarification about TM 'wiping out the tree'. I wipe out the unity GameObjects. Things that represent the graphical icons you actually see on the tree. I do not wipe out the techID's, nor would that even make sense. I just create new 'boxes' that point to the same 'techs'. We are getting really lose with our terms: 'node' and 'tech' are used interchangeably but there really are two different things there. In the tree.cfg file, you are specifying the nodes (as in GameObjects) that will be created, and the techID it points to is a parameter. I don't create those techs (unless they don't exist). Nor do I ever 'erase' techs, even if your cfg file doesn't reference them.

I don't see how these implementation details change anything. Can you please clarify what point you were trying to make? I think I've missed it.

[anonish]

Mostly I'm saying terminology is being confused. We have to talk about both techs and nodes to fully explain the problem, but we keep swapping what they mean.

If they want to include ModuleManager support, as they've stated, then the processing flow must change to:

1. KSP compiles a list of all tech tree nodes to GameDatabase
   
2. ModuleManager, if installed, compiles and applies a list of node patches
   
3. TechManager deletes the stock tech tree
   
4. TechManager reconstructs the tech tree using the configs compiled in step 1
   

(don't know why it insisted on the double quoting..)

To me 'tech tree' means the techs, but its the nodes that are deleted. So in step 1, 'nodes' means techs and in step 3 'techs' means nodes.

In step 1, where in the GameDatabase does KSP store these techs? (Not saying KSP doesn't, just TM doesn't use it if KSP does. TM reads techs from ResearchAndDevelopment.Instance.GetTechState() <which very well may access GameDatabase>)

In step 2, where are those patches applied against? (this I just need to lookup myself, I haven't looked at MM internals at all)

In step 3, TM deletes the nodes. And really, only inactivates them. The techs are never deleted, just created if need be and possibly modified if they 'lost' parts.

Step 4 was supposed to reference step 2 right?

Anyway, I get the general idea: KSP establishes a baseline, MM fixes things up -- possibly adding new techs as well, TM renders the results. Its just the way it was presented seems to suggest a particular implementation that doesn't make sense to me.

[Starstrider42]

If they want to include ModuleManager support, as they've stated, then the processing flow must change to:

1. KSP compiles a list of all tech tree nodes to GameDatabase
   
2. ModuleManager, if installed, compiles and applies a list of node patches
   
3. TechManager deletes the stock tech tree
   
4. TechManager reconstructs the tech tree using the configs compiled in step 1
   

In step 1, where in the GameDatabase does KSP store these techs? (Not saying KSP doesn't, just TM doesn't use it if KSP does. TM reads techs from ResearchAndDevelopment.Instance.GetTechState() <which very well may access GameDatabase>)

In step 2, where are those patches applied against? (this I just need to lookup myself, I haven't looked at MM internals at all)

In step 3, TM deletes the nodes. And really, only inactivates them. The techs are never deleted, just created if need be and possibly modified if they 'lost' parts.

Step 4 was supposed to reference step 2 right?

Ah, ok, I see how my original post was unclear. I was not trying to imply any implementation for steps 3 and 4, and AFAIK the implementation for steps 1 and 2 is forced by the KSP API, so you don't get a choice there.

What I meant is that tree.cfg, like every other .cfg file in the game, defines ConfigNodes -- not techs, not tech tree nodes, just generic ConfigNodes whose meaning depends what your code does with them. Whenever KSP finds a .cfg file with valid syntax, it loads those ConfigNodes into GameDatabase (step 1). ModuleManager edits the ConfigNodes in GameDatabase (step 2), so MM compatibility is a matter of making sure you use the copy that's in GameDatabase instead of loading it directly from the individual file.

Here's a code snippet that does that:

UrlDir.UrlConfig[] configList = GameDatabase.Instance.GetConfigs("NODE");
foreach (UrlDir.UrlConfig curSet in configList)
    foreach (ConfigNode curNode in curSet.config.nodes) {
        initTechNode(curNode);
    }
}

where I'm assuming initTechNode() is your existing implementation for step 4.

EDIT: Ok, so I'm assuming one thing about your implementation, which is that however you process tree.cfg involves reading ConfigNodes from the file in one form or other. Is that a good guess?

My original point was that having multiple tech tree configs (say, for different mods) only affects what ends up in GameDatabase, and you most likely want to find and load all available configs anyway. The only way that mods could overwrite each other in this scenario is if you get duplicate techIDs (if I understand the framework you described correctly), and that's easy to avoid by encouraging mods (including the community tech tree) to give their NODE names and techIDs a unique prefix.

Edited October 28, 2014 by Starstrider42

[anonish]

MM compatibility is a matter of making sure you use the copy that's in GameDatabase instead of loading it directly from the individual file.

I had to read up on GameDatabase. Things make much more sense now. I had no idea KSP iterated over the GamaData dirs and loaded all the configs in a manner that was then presentable to ALL the mods. Sounds like you would agree with Fractal_UK's approach then? Each mod can install their own mymod.cfg that defines a TECHNOLOGY_TREE_DEFINITION ConfigNode. Then TM picks one based on user input. In that case the mods *don't* need to have unique nodes or techIDs, as long as only one tree is used per save game (and switching trees could also work, you just might have to repurchase parts), as only one of the tree definitions would be used and the rest ignored. Whatever unified tree the community comes up with would also be an option.

Ok, so I'm assuming one thing about your implementation, which is that however you process tree.cfg involves reading ConfigNodes from the file in one form or other. Is that a good guess?

Yes that's correct. tree.cfg is as you suspect, a ConfigNode type file, just referenced by filename instead of via GameDatabase.

[Fractal_UK]

I've posted my latest work on the other thread. It still needs to actually save the user selection to a tech tree selection file but it's otherwise pretty much there.

[Joshwoo70]

*go to tell fractual_uk*

Nice job! Will it work with sci mode?

[anonish]

I've posted my latest work on the other thread. It still needs to actually save the user selection to a tech tree selection file but it's otherwise pretty much there.

is there really no way we can get that into persistent.sfs? why clutter a directory if we don't have to, especially to save one short string.

Edited October 29, 2014 by anonish

[Cybersneeze]

Sorry, this is probably idiocy as I have only skim-read the comments; but would it be possible for this mod to establish a fully functional, muti-mod, tree. I'm currently using a ksp build running KAS, interstellar, B9, KW-Rocketry, and a large number of other mods, like DR and TAC-LS. Will this mod break this build? I don't really care about my save, I was stuck using the KSPI hot patch, that adds all the parts to stock TT nodes, so had anti-matter within about 5 missions.

If anyone could just get me up to speed on how this mod works in comparison to tree-loader, and its effect on my build, if it will break it entirely, have no serious negative consequence, or just a break a small number of mods. Thxs for any input

[anonish]

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.

[DaveS]

I've set up my .25 career game with the new TechManager and the KSP-i tech tree, I hadn't moved far enough along that I had the parts, so there was no impact. Works like a charm. The interstellar parts show up in the new places just like one would hope.

Nice work.

[Nelien]

Just throwing this out there quickly since I'm on the run, but would a TreeLoader to TechManager converter be of any use? I wrote a converter between ATC and TreeLoader already so I can quickly throw together a converter for this if needed. However it seems like that's not needed is it? In other words, TechManager is fully compatible with TreeLoader files?

[undercoveryankee]

Just throwing this out there quickly since I'm on the run, but would a TreeLoader to TechManager converter be of any use? I wrote a converter between ATC and TreeLoader already so I can quickly throw together a converter for this if needed. However it seems like that's not needed is it? In other words, TechManager is fully compatible with TreeLoader files?

TechManager will use most TreeLoader files without modification. The only exception is that TreeLoader implicitly preserved stock nodes that aren't edited or deleted in the file, and TechManager leaves the tree empty except for what's in the file. A tool to add the stock nodes to a config that relied on TreeLoader's implicit behavior might be useful.