[0.25/0.90] TechManager Version 1.5

[anonish]

In other words, TechManager is fully compatible with TreeLoader files?

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.

[Nelien]

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.

Ok, I'm with you now. It seems like a converter isn't strictly needed but could be handy to cover for expected deleted stock nodes as undercoveryankee mentioned. I might have a quick play around tomorrow after work to see if I can get a converter running.

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.

I genuinely have no clue. I only worked with a very small set of trees to test with and none of the had anchor point definitions in them, don't think it's very common, but I wouldn't know. I only made the converter in a rush since I already had the core functionality in another tool I'm currently developing anyway. I would imagine it's not too common to be honest, the default anchor layout is generally fairly well suited and most people don't care too much how the tech tree looks.

PS. In case you're curious, the other project I'm working on is a standalone, visual, external editor for tech trees. I actually will most likely have an alpha ready to test this weekend so I'd be happy to hand it over for people to play around with. Should make creating and editing tech trees loads easier and it will obviously have the option to output into TechManager cfg files (it already has support for TreeLoader and ATC configs internally).

[Fractal_UK]

I've now added the option to select the stock tree in the menu and created a .cfg file (in the savegame folder) that stores your selection of tech tree. If, for whatever reason, it can't find tech trees it will always default to using the stock tech tree.

To answer your earlier question anonish, I try to avoid directly writing to the persistent.sfs file because something just feels unsafe about manually iterating through the nodes and writing bits and bobs to them. It's a very unlikely circumstance that doing so would destroy someone's savegame but I don't want to risk being responsible for that so I prefer to use a distinct file for plugin-specifc stuff. Obviously you're free to edit my code to make it use the persistence file directly if you prefer, it's just one of those things that I, possibly irrationally, avoid at all costs.

I chose KSPITechTree and the result was the creation of a new "TechManager.cfg" in the savegame folder with content

techTreeID = KSPITree
useStockTree = False

Next thing to do is make it read the cfg file before showing the popup and it should be fit for consumption.

Updated Source

[anonish]

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.

Edited October 30, 2014 by anonish

[Fractal_UK]

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.

I've just pushed some more changes which now load the tech tree without showing the selector if the tree selection file already exists, so the options look something like this:

If the tech tree selection file exists -> Load tech tree

Else -> Show tech tree selector -> Create a tree selection file for the savegame based on selection

If, for some unknown reason, at any point the chosen tech tree is invalid, revert to the stock tree.

These latest changes pretty much complete the functionality objective I was aiming for so I'll largely just be testing this now while you fiddle with it until you're happy with the final result.

[pjf]

I am delighted to see this. Thank you *so* much. I've scanned the last eight pages of activity, and have just a question and an understanding check:

1) Is this up on GitHub anywhere? I can find FractalUK's fork, but not the original.

2) Is my understanding of existing discussions correct that we'll be moving towards a ModuleManager accessible approach, and it won't require a tree.cfg in the user's save directory?

The second is something I'd desire greatly, because it means that mods can supply updated tech-trees with each version, allowing tech-tree developers to not have to get everything right on their very first go.

For those folks using the CKAN pre-releases, this can now be installed with `ckan install TechManager`. Our cloud of bots should pick up new releases from KerbalStuff automatically.

Many thanks!

~ Paul

Edited October 30, 2014 by pjf
URL fixes

[Fractal_UK]

I am delighted to see this. Thank you *so* much. I've scanned the last eight pages of activity, and have just a question and an understanding check:

1) Is this up on GitHub anywhere? I can find FractalUK's fork, but not the original.

2) Is my understanding of existing discussions correct that we'll be moving towards a ModuleManager accessible approach, and it won't require a tree.cfg in the user's save directory?

The second is something I'd desire greatly, because it means that mods can supply updated tech-trees with each version, allowing tech-tree developers to not have to get everything right on their very first go.

For those folks using the CKAN pre-releases, this can now be installed with `ckan install TechManager`. Our cloud of bots should pick up new releases from KerbalStuff automatically.

I don't think the original code is on Github, I got the sourcecode from the download and just created a new repository to host my work.

In the version that I'm working with, it is possible to make changes to each tree with module manager but it would generally not be neccessary to do so. Each mode can simply distribute a tech tree with their mod and that tech tree would appear as an option in the list of selection options the user has available.

A group of modders here are working on a community tree that the tech nodes for many mods should appear in, allowing the user to select this community tech tree and have a unified tree from a whole bunch of mods.

[anonish]

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.

[Nertea]

annonish, what's the chance that we could get some kind of support for custom node icons? I realize from my own attempts at tech stuff that it's an internal enum that's defining them, but I'm wondering if it would be possible to hack some kind of overwrite by getting the renderers or UI components being used to draw the nodes and replacing their textures. Would not be pretty but... not having new images bugs me more than it should .

I'll investigate myself when I have time if you don't . Just thought I'd mention it in case you had any ideas.

[anonish]

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.

Edited October 30, 2014 by anonish

[anonish]

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:

Edited November 3, 2014 by anonish

[G2000]

Nelien, this GUI sound so good. I've been messing around for days trying to find a tech tree editor that works so I can finally finish up on my mod-pack. I'd be happy to take part in the testing stage for you and could hopefully put it through it's paces, plus, get a usable result! I hope that I can help test this. G2000

[UAL002]

Lookin good anonish. Can't find the other thread but how is the community tree coming? Everyone on board yet?

[RoverDude]

Lookin good anonish. Can't find the other thread but how is the community tree coming? Everyone on board yet?

It's over on the General Add-on Affairs forum. I can say that Nertea (since he's running the project) and anything USI (i.e. everything I do) will be on board. Fractal_UK expressed the possibility of doing both (CTT and his own tree), but have not seen any feedback from him RE KSPI support recently.

[anonish]

This is the only feedback I've seen so far on tree switching, so I'll reply to this here:

making them switch trees back and forth in the R&D center is a sub-optimal solution

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.

Like the idea of CTT but are concerned because the tech nodes don't fit your vision for your mod, but still don't want to be a jerk to users? Speak up!

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.

[RoverDude]

@anonish - Context is kinda important

The context of those statements was in using tree-switching as a way to have multiple trees simultaneously. And it's sub-optimal. If a mod played nicely with CTT... they would either use CTT, suggest a new node for CTT, or be a perfect puzzle piece of goodness with no overlaps or confusion. I am not confident in that last bit

I will bet a cookie that within two weeks of launch, we have a tree conflict which in turn is going to a mess in our mod threads. But that's for modders to sort out among themselves (or through pressure of our user base) - there's no bit of curly braces that will make people play well together.

Not saying it's a bad thing to switch trees on the fly - it's an excellent feature, and vastly better than forcing a single choice (which is horribly bad). But it's not an optimal solution (And I don't mean that in a negative way, just that as you said yourself, given the choice between a shared tree and this, the shared tree is better). Still, much better than what we have currently and it's a perfectly valid fallback (similar to how our fallback for resources works today, or how ORS used to work before it was broken as a multi-mod system).

Edited October 31, 2014 by RoverDude

[UAL002]

Well, Im not interested in full fledged KSPI as there is just too much involved. But I do want to try Interstellar light maybe this weekend now that we have the trees working. I hope this prods squad into improving the tech tree a bit.

[Fractal_UK]

The context of those statements was in using tree-switching as a way to have multiple trees simultaneously. And it's sub-optimal. If a mod played nicely with CTT... they would either use CTT, suggest a new node for CTT, or be a perfect puzzle piece of goodness with no overlaps or confusion. I am not confident in that second bit

I will bet a cookie that within two weeks of launch, we have a tree conflict which in turn is going to a mess in our mod threads. But that's for modders to sort out among themselves (or through pressure of our user base) - there's no bit of curly braces that will make people play well together.

Not saying it's a bad thing to switch trees on the fly - it's an excellent feature, and vastly better than forcing a single choice (which is horribly bad). But it's not an optimal solution (And I don't mean that in a negative way, just that as you said yourself, given the choice between a shared tree and this, the shared tree is better). Still, much better than what we have currently and it's a perfectly valid fallback (similar to how our fallback for resources works today, or how ORS used to work before it was broken as a multi-mod system).

For the record, ORS was never broken and never will be broken as a multi-mod system, it was, in fact, designed with that overriding goal in mind. Some people chose to use it incorrectly despite the documentation on the thread indicating how to do so correctly but that is beside the point of this thread.

Ultimately, CTT is tangentental to the purpose of TechManager. The point is to provide the KSP's players with a system by which they can choose which tech tree they want to play with. CTT is one option for those tech trees and, assuming it continues to be supported by a sizeable group of modders, it will be a tech tree that many people choose to play with. However, there have been previous attempts to create tech trees that incorporate the parts from a wide variety of mods in the past (MedievalNerd's work springs to mind) in order to achieve different aims. Greater realism or better gameplay experience might be valid reasons for such projects and I guarantee within a very short time of the latest changes to this mod becoming available, people will be making those mods again to serve all sorts of different purposes.

Some of these mods might involve sweeping changes to the tech tree compared to stock, while others might involve very small tweaks or merely extensions to the stock tree. All of these are valid and all serves the needs of different groups of players.

Ultimately, I intend to remain neutral on the issue of which tech tree to actually use.

From my point of view, it's better to provide people the tools to solve a problem in a way that they are happy with than to excessively favour one solution which may be suboptimal to a sizeable group of players, hence the reason for Interstellar maintaining a unique tech tree in addition to the CTT. More choice for the player is generally a good thing and that is what TechManager should aim to provide.

[RoverDude]

For the record, ORS was never broken and never will be broken as a multi-mod system, it was, in fact, designed with that overriding goal in mind. Some people chose to use it incorrectly despite the documentation on the thread indicating how to do so correctly but that is beside the point of this thread.

For the record, it broke horribly with duplicate keys. So when we had to fix it for 0.24.2 in your absence, we patched it. Then upon your return you up-versioned the fork, ignored the fix the community had made in your absence, and rebroke it. And broke interfaces to SCANSat and the resource overlay along the way (i.e. people who were actually trying to extend it's functionality), and pretty much ignored any attempt at communication.

Last I checked, ORS atmo definitions (which were never broke) were to require a player to select which definition set to use. Has that changed and will ORS now allow a player to have two different atmospheric definitions operate simultaneously then? Would be good to know, since that last tweak pretty much rendered ORS useless for anyone playing with two mods that wanted to define atmospheres. Less important for me personally as I learned my lesson and forked, but might be important for other people to know who might want to consider using the original fork.

(EDIT) And feel free to PM me, or (since that has not worked in the past), feel free to address this in the ORS thread.

Edited October 31, 2014 by RoverDude

[Fractal_UK]

For the record, it broke horribly with duplicate keys. So when we had to fix it for 0.24.2 in your absence, we patched it. Then upon your return you up-versioned the fork, ignored the fix the community had made in your absence, and rebroke it. And broke interfaces to SCANSat and the resource overlay along the way (i.e. people who were actually trying to extend it's functionality), and pretty much ignored any attempt at communication.

Last I checked, ORS atmo definitions (which were never broke) were to require a player to select which definition set to use. Has that changed and will ORS now allow a player to have two different atmospheric definitions operate simultaneously then? Would be good to know, since that last tweak pretty much rendered ORS useless for anyone playing with two mods that wanted to define atmospheres. Less important for me personally as I learned my lesson and forked, but might be important for other people to know who might want to consider using the original fork.

(EDIT) And feel free to PM me, or (since that has not worked in the past), feel free to address this in the ORS thread.

The version which was broken would never have been called by a mod which followed the versioning rules layed out in the post. The very fact that it didn't work correctly proves that it was not being used properly (Edit: improper versioning, for the record, opens the mod up to problems between dlls from different game versions and hence should never be done.)

Edited October 31, 2014 by Fractal_UK

[RoverDude]

The version which was broken would never have been called by a mod which followed the versioning rules layed out in the post. The very fact that it didn't work correctly proves that it was not being used properly (Edit: improper version, for the record, opens the mod up to problems between dlls from different game versions and hence should never be done.)

We already had this discussion and you were proven incorrect It broke into oblivion with the same DLL. We covered this. We were ignored. Now, if you would like the last word please feel free to take it, otherwise PM me or answer that question about atmo definitions over on the ORS thread. I'm genuinely curious if the issue I noted is still the case.

[anonish]

The context of those statements was in using tree-switching as a way to have multiple trees simultaneously. And it's sub-optimal.

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.

[Fractal_UK]

We already had this discussion and you were proven incorrect It broke into oblivion with the same DLL. We covered this. We were ignored. Now, if you would like the last word please feel free to take it, otherwise PM me or answer that question about atmo definitions over on the ORS thread. I'm genuinely curious if the issue I noted is still the case.

If you genuinely believe that (rather than are trying to avoid admitting to an error) you should go and reread the thread. I suspect you still don't understand how the versioning system works, in which case I really recommend looking at it again until you do because it may actually be of use to you if you need to strongly version dependencies.

Regardless, I'm getting a little tired of being used as an example of bad community interoperability for your error, whether you accept it or not.

I've tried to be civil and ignore your persistent snipes and I apologise to the rest of the community for this unnecessary diversion but I felt it was about time the record was set straight.

[Fractal_UK]

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.

Moving on from the horrible diversion, I actually really like the subtree idea. It could be ideal for a wide variety of use cases, especially if it could be applied to the stock tree directly but maybe you can determine better than me if that's actually a plausible idea.

I know I had problems in the past when the stock tree was changed between game versions.

[Nelien]

Nelien, this GUI sound so good. I've been messing around for days trying to find a tech tree editor that works so I can finally finish up on my mod-pack. I'd be happy to take part in the testing stage for you and could hopefully put it through it's paces, plus, get a usable result! I hope that I can help test this. G2000

Glad to hear that, I'm actually fairly confident I'll have a testable version this weekend so I'll send you a notification when its ready to test. I'm definitely happy to have more people testing and giving feedback. I wouldn't expect too much from the first version but I think it'll be enough to help people design new trees.