[Planning] Community Tech Tree

[Nertea]

Huh, that is indeed a critical thing that I hadn't considered.

[RoverDude]

@madlemur - I'll honestly be taking the opposite approach. Basically, CTT is mandatory. So if you use any USI stuff, you're going to be grabbing TM and MM and this specific tree. If you don't my configs won't work But then that's my case given I have lots of large mods that really need better space to grow. For a smaller mod, an MM config makes perfect sense. Just not how sure that will work given there is no DLL to load (could always do what I did with K+ and have a dummy one specifically to support MM)

[madlemur]

@RoverDude: You have a good reason, and a hard dependency. But if a module merely wants to be KSO-0143 compliant, and be CTT compatible, all they have to do is include the appropriate MM config file...

[RoverDude]

@RoverDude: You have a good reason, and a hard dependency. But if a module merely wants to be KSO-0143 compliant, and be CTT compatible, all they have to do is include the appropriate MM config file...

I think I agree.... but what the heck is KSO-0143

[madlemur]

Kerbal Standards Organization standard #0143: Technology Taxonomy standards.

Sheesh!

[EMKAY]

Hi everyone!

Firts of all kudos to Nertea for working on that tree and Rover pursuring community standardisation projects to assure everyone can play on a big playgroud, if he/she wants. Just checked out the tree. It's nice. Nervertheless I have some remarks:

1. I belive Specialized-Plasma-Technologies should be a prerequisite of Ultra-High-Energy-Physics. I think a warp drive, if it becomes reality one day, will ejaculate a kind of exotic-matter-plasma in order to create a spacetime bubble. Maybe Advanced-Aerospace-Composites should also be connected to UHE-Physics, in order to assure that the warp-ring is build of proper material (or maybe it sholud built of Kerbitanium aka K++ --> inspiration to Rover).

2. In my opinion Off-World-Manufactoring is definitely a prerequisite of Self-Sufficien-Outposts, because how can be a colony self sufficient if the can't produce the sstuff they need by themselves. If I think of OKS (or even of OKS+ or something) maybe Orbital-Megastructures should be connected to Off-World-Manufactoring as well.

3. Rename Subsonic-Flight into Advanced-Subsonic-Flight because, regarding to its position, it seems to deal with advanced high efficiency high-bypass-turbo-fan, turbopro and unducted-fan engines, big jumbo-jet wings (B9 Heavy-Wing) etc. In order to integrate firespitter it is nescessary to make nodes before the start-node (or at least aerodynamics-node) or/and to move parts around the stock nodes, which is (unfortunately but understandingly) not the aim of the community tree.

4. It could be interesting to add cheap (0.5 sience-costs) "side-nodes" to the rocketry (or other) nodes for KW-SRBs (like cvod did in his mod-oriented-techtree) or other special rocket engines like space-shuttle-engines (or other stuff).

Best Regards and sorry for my bad English!

PS: If some knows about internship positions in the aerospace-industry outside of Germany pm me please :-)

[Serino]

I'm not fond of this idea. It means whenever someone wants a new tree, then there needs to be a new release of TechManager, even if TechManager itself hasn't changed.

+1 for this. It also means you're not making new CTT releases with every new version of KSP, because TechManager/ModuleManager has been recompiled.

I dont understand what you are talking about cause a new tree doesn't need a new release of TM all the mod needs to do is bundle the tree with them. The reason I suggested we bundle CTT and TM is cause we are doing this as a way to integrate all current and future mods into a single usable tree. Also if you do this there isn't 10 different copies of CTT in your files or you forget to download it for some reason. Duplicate files overwrite each other this way so you only have the 1 TM file and the 1 CTT file. No problems, no worries, and no extra work on anyone's part aside from having to include it into your mod's zip file.

[Nertea]

I think my opinion is that we should bundle TechManager but not ModuleManager. I think my reasoning here is that yes, this is basically a single cfg, but to improve uptake, it would be nice if people looking through the forums get the whole package to run the tree with a single download. I don't mind updating the package when TechManager gets updated, or every KSP version (because I'll need to anyways, they seem to like to make one minor annoying tweak at least to the tree every version).

New question: are nodes hide-when-empty, or are they always shown? Hidden is cleaner if less mods are installed, but runs the risk of creating unreachable nodes if a mod uses a non-accessible node. Always shown will have nodes always accessible, but it's not as clean looking.

Hi everyone!

Firts of all kudos to Nertea for working on that tree and Rover pursuring community standardisation projects to assure everyone can play on a big playgroud, if he/she wants. Just checked out the tree. It's nice. Nervertheless I have some remarks:

1. I belive Specialized-Plasma-Technologies should be a prerequisite of Ultra-High-Energy-Physics. I think a warp drive, if it becomes reality one day, will ejaculate a kind of exotic-matter-plasma in order to create a spacetime bubble. Maybe Advanced-Aerospace-Composites should also be connected to UHE-Physics, in order to assure that the warp-ring is build of proper material (or maybe it sholud built of Kerbitanium aka K++ --> inspiration to Rover).

2. In my opinion Off-World-Manufactoring is definitely a prerequisite of Self-Sufficien-Outposts, because how can be a colony self sufficient if the can't produce the sstuff they need by themselves. If I think of OKS (or even of OKS+ or something) maybe Orbital-Megastructures should be connected to Off-World-Manufactoring as well.

3. Rename Subsonic-Flight into Advanced-Subsonic-Flight because, regarding to its position, it seems to deal with advanced high efficiency high-bypass-turbo-fan, turbopro and unducted-fan engines, big jumbo-jet wings (B9 Heavy-Wing) etc. In order to integrate firespitter it is nescessary to make nodes before the start-node (or at least aerodynamics-node) or/and to move parts around the stock nodes, which is (unfortunately but understandingly) not the aim of the community tree.

4. It could be interesting to add cheap (0.5 sience-costs) "side-nodes" to the rocketry (or other) nodes for KW-SRBs (like cvod did in his mod-oriented-techtree) or other special rocket engines like space-shuttle-engines (or other stuff).

Hey, not bad ideas, but (re 1 and 2) adding too many dependencies could be bad. Let's examine the first one - that would mean that KSPI would need to populate all those nodes to get to warp drives. This may or may not happen, and probably wouldn't in the case of advanced aerospace composites.

The last option is interesting, but I'm against adding quite single-purpose simple nodes like that. Might as well not even have those nodes if they only cost a tiny bit.

Thanks for the input!

[anonish]

I suggested we bundle CTT and TM

Not a good idea, imo. I know I don't want to spin a release of TM every time the CTT changes and I'm sure they feel the same way. I only bundle unofficial copies of KSPI and Near Future's tree's because they haven't released their own versions with the new cfg file format yet. When they do, I'll likely stop distributing them.

[Nertea]

I don't want you to bundle CTT with TM, just the other way around . That being said, it's your product, so if you're against that bundling then I'll do something else for sure.

[anonish]

New question: are nodes hide-when-empty, or are they always shown? Hidden is cleaner if less mods are installed, but runs the risk of creating unreachable nodes if a mod uses a non-accessible node. Always shown will have nodes always accessible, but it's not as clean looking.

I floated the idea of adding a 'hideIfPointless' parameter that would hide a node if it *and* all its children were empty of parts. Didn't get any response to that, so I'll mention it again as a possible option.

[anonish]

I don't want you to bundle CTT with TM, just the other way around . That being said, it's your product, so if you're against that bundling then I'll do something else for sure.

Well, its open license and anyone can bundle whatever they want. The only thing I don't like about TM being packed in other mods (another tech tree already does this...) is that it leads to multiple copies of TechManager.dll floating around in GameData. I know I've played 'find all the ModuleManager.dlls!' before (although now I think that wasn't necessary) and I'd like to avoid that if possible.

I added some rudimentary duplicate detection to TM 1.2 such that (hopefully) only one TM dll will load. Which one? Well, that I don't control. I couldn't make a lot of sense of KSP's AssemblyLoader class. It would claim to see all the dll's in my tests, but then only instantiate the ones with the highest version number. Was that intentional? An accident? I don't know. So, I can't guarantee that multiple dll's will work out properly.

[Nertea]

I floated the idea of adding a 'hideIfPointless' parameter that would hide a node if it *and* all its children were empty of parts. Didn't get any response to that, so I'll mention it again as a possible option.

Must have missed that, or I would have clamoured for it loudly. Yes please .

Well, its open license and anyone can bundle whatever they want. The only thing I don't like about TM being packed in other mods (another tech tree already does this...) is that it leads to multiple copies of TechManager.dll floating around in GameData. I know I've played 'find all the ModuleManager.dlls!' before (although now I think that wasn't necessary) and I'd like to avoid that if possible.

I added some rudimentary duplicate detection to TM 1.2 such that (hopefully) only one TM dll will load. Which one? Well, that I don't control. I couldn't make a lot of sense of KSP's AssemblyLoader class. It would claim to see all the dll's in my tests, but then only instantiate the ones with the highest version number. Was that intentional? An accident? I don't know. So, I can't guarantee that multiple dll's will work out properly.

I'd hope that I could place it such that people who install properly would just have an overwrite occurring. Incorrect placement of my mods generally breaks them due to texture sharing, resulting in at least one unnecessary support post/PM/email per week for me, so I already have no sympathy for people who don't follow install instructions.

[madlemur]

Must have missed that, or I would have clamoured for it loudly. Yes please .

I'd hope that I could place it such that people who install properly would just have an overwrite occurring. Incorrect placement of my mods generally breaks them due to texture sharing, resulting in at least one unnecessary support post/PM/email per week for me, so I already have no sympathy for people who don't follow install instructions.

Aye, and aye!

By bundling, I think Nertea means as its own folder under GameData, not as one of the plugins "inside" the CTT "plugin". At least, I hope that's what s/he meant. So it's still under the TechManager directory, not as a .DLL in the CTT directory.

[Streetwind]

Can TechManager maybe check which folder it is run from, and if it is not /GameData/TechManager, just quietly exit?

This means everyone who distributes TM.dll must place it into /GameData/TechManager, and therefore, multiple installs will simply overwrite. Anyone who places the DLL anywhere else, or distributes it to be placed anywhere else, will simply see it not running, avoiding all conflicts.

[anonish]

Can TechManager maybe check which folder it is run from, and if it is not /GameData/TechManager, just quietly exit?

This means everyone who distributes TM.dll must place it into /GameData/TechManager, and therefore, multiple installs will simply overwrite. Anyone who places the DLL anywhere else, or distributes it to be placed anywhere else, will simply see it not running, avoiding all conflicts.

Having it not run is itself a conflict. I could put a message in the log file, but how many users are going to check it?

Even if everyone follows instructions and puts TM in /GameData/TechManager, what is to stop them from putting an older version of top of a new one?

I think the developers here have decided that bundling CTT with each mod doesn't make sense, so I don't see why the same logic doesn't apply to bundling TM with each tech tree. I think there is an expectation that any plugin download should be more than one .cfg file, but there is nothing wrong with that if that is what makes the most sense, and I believe it does.

[RoverDude]

Actually, I was going to bundle CTT (strictly speaking for myself here) as well as bundle TM.

(Edit) I view this in the same way that I do bundling FireSpitter, CRP, Toolbar, or Module Manager. Again - just speaking for my intent in this case.

Does TM use KSP-AVC? And Nertea - do you plan on using KSP-AVC with CTT?

[scerion]

Does TM use KSP-AVC? And Nertea - do you plan on using KSP-AVC with CTT?

TM doesn't use AVC yet.

Just wanted to say this looks awesome, really really looking forward to the release

[madlemur]

Having it not run is itself a conflict. I could put a message in the log file, but how many users are going to check it?

Even if everyone follows instructions and puts TM in /GameData/TechManager, what is to stop them from putting an older version of top of a new one?

I think the developers here have decided that bundling CTT with each mod doesn't make sense, so I don't see why the same logic doesn't apply to bundling TM with each tech tree. I think there is an expectation that any plugin download should be more than one .cfg file, but there is nothing wrong with that if that is what makes the most sense, and I believe it does.

You could do like MM does, and incorporate the TM version into the filename of the DLL. If you could also borrow the logic to only use the most recent version, the problem kind of goes away. Even if someone distributes an older version of TM, it won't overwrite a newer version, and the version checking would cause only the newest version to actually run.

I'd like to take a minute to review the use cases I've gleaned from the thread...

1) A mod wants to be "CTT-Compliant"

The mod builds everything out with parts in the

stock

tree, but provides a CTT cfg file to place them in the expanded nodes as needed, if CTT is being used.

2) A mod wants a hard dependency on CTT, forcing the user to use the expanded nodes

The mod builds everything out with the parts in the correct nodes from the expanded CTT set

The mod either leads the user to install CTT as a prerequisite, or co-bundles CTT with their mod

3) A mod wants to rearrange the CTT nodes to better fit their preference

The mod builds out everything per #2, but also includes their own tree.cfg that includes all the CTT nodes

4) A mod wants to rearrange and expand the CTT to better fit their vision

Per #3, but we're starting to drift away from the CTT at this point, since they are adding new nodes, and likely won't be able to reassign any mod parts other than their own

Note that this is probably the use case for complete re-theming mods (like BTSM) that are meant to be comprehensive and self-contained, but it's also comparable to just having a flat-out custom tech tree

Caveats: In cases #1 & #2, the mod builder should not base any part-node assignment based on node dependencies (except perhaps "XX", "Advanced XX", "Mo' Bettah XX", "Trancendental XX" style progressions)

In case #3, the tree modder should not take into account what parts are in what node for determining dependencies (except as noted above)

In case #4, the modder is on their own, and it's assumed they know what the heck they are doing.

Now, how does one "install" the CTT? My suggestion is that even if the "mod" is just one tree.cfg file, it should be in its own directory, and either be co-bundled with TM, or have big ole' warning text that TM is a prerequisite. Personally, I'd go with co-bundling it (if the license allows, I haven't read the license). This would be akin to the co-bundling of MM and Firespitter that so many mods do. TM and CTT are relatively small mods, so byte-bloat isn't really an issue. Version checking in TM would solve overwrite issues with that. That leaves two issues: CTT overwriting & CTT usage checking.

CTT Overwriting: I'm not sure we can prevent overwrites, unless the file is also named with the version number, in which case the user has to be sure to choose the correct version. Or if TM incorporates a way to do versioning.

CTT Usage Checking: This is the tough part. How do we check that the user is actually using the CTT? How can we communicate that back to MM? Assuming use case #1, the additional MM patches should only be applied if CTT is the active tree, not just if it's installed. I don't know what could be done with a simple plugin that checked which tech tree is being used, and unloaded itself if it's not being used (allowing :needs[CTT]), or some other method for toggling MM processing.

Will there still be problems? Sure. Every time you foolproof something, the universe comes up with a better fool.

[anonish]

You could do like MM does, and incorporate the TM version into the filename of the DLL.

I considered this. There is nothing preventing it, but I consider it bad form. C# has some crazy rules about assembly version management. All the information is in the dll, that *should* be all that I need.

If you could also borrow the logic to only use the most recent version, the problem kind of goes away.

I looked at that. Particularly the logic inside MM. It is based off of using reflection to gather the assembly information, and then it has a process for trying to choose the winner if multiple dlls are present. As I mentioned, the KSP AssemblyLoader is a bit of a black box. It will print out 'loading dll x' and 'loading dll y', but only *actually* instantiate the master class from *one* dll, so the dll reflection logic is moot.

Even if someone distributes an older version of TM, it won't overwrite a newer version

Yes it would, if it was being installed to /GameData/TechManager. If it is installed to multiple places, then we are right back to having multiple dlls and trusting AssemblyLoader is doing the right thing.

My preference is that nobody bundle TM and that any players that want it download and install it like any other mod. Obviously, people are going to bundle it anyway. We'll just have to see if that ends up creating issues or not.

4) A mod wants to rearrange and expand the CTT to better fit their vision

This is a good use case for *multiple* trees. TM can switch between them.

Edited November 11, 2014 by anonish

[madlemur]

I considered this. There is nothing preventing it, but I consider it bad form. C# has some crazy rules about assembly version management. All the information is in the dll, that *should* be all that I need.

I looked at that. Particularly the logic inside MM. It is based off of using reflection to gather the assembly information, and then it has a process for trying to choose the winner if multiple dlls are present. As I mentioned, the KSP AssemblyLoader is a bit of a black box. It will print out 'loading dll x' and 'loading dll y', but only *actually* instantiate the master class from *one* dll, so the dll reflection logic is moot.

Yes it would, if it was being installed to /GameData/TechManager. If it is installed to multiple places, then we are right back to having multiple dlls and trusting AssemblyLoader is doing the right thing.

Oh, hell no. When I say "co-bundling", I mean the archive has a GameData directory, and under that is TreeManager and CTT in separate directories. There is no reason to put someone else's plugin inside your mod. Just put it in its correct location.

My preference is that nobody bundle TM and that any players that want it download and install it like any other mod. Obviously, people are going to bundle it anyway. We'll just have to see if that ends up creating issues or not.

I can see that, but if you use AVC or something similar, even if it's bundled with another mod, the user will be immediately notified if they have an out of date version.

This is a good use case for *multiple* trees. TM can switch between them.

Hrmmm... Forgotten that tidbit. TM can switch between trees in-game? That could be... useful.

[anonish]

I can see that, but if you use AVC or something similar, even if it's bundled with another mod, the user will be immediately notified if they have an out of date version.

AVC shouldn't be used as a band-aid to fix older copies being installed on top of newer copies. Simply as a way to keep one install up to date. Image a user installs TM, latest version. Then installs UMI with an out of date version. Now they get an 'out of date' popup which is rightfully confusing.. didn't they *just* install it? They resolve it and move on. A week later they download a crazy tech tree some modder made, which included TM, perhaps another old version. Again, another notification.

If a mod has external dependencies, the player should be directed where to obtain them. Or better yet, use an installation manager to resolve those dependencies.

Looks like miniAVC has its own 'multiple copies everywhere' check. I'll have to take a look.

TM can switch between trees in-game? That could be... useful.

yep. Choose more than one tree when you start the game. Then, when in the R&D building looking at the tech tree, click on the drop down button in the top right. It will have the name of the currently displayed tree.

[madlemur]

AVC shouldn't be used as a band-aid to fix older copies being installed on top of newer copies. Simply as a way to keep one install up to date. Image a user installs TM, latest version. Then installs UMI with an out of date version. Now they get an 'out of date' popup which is rightfully confusing.. didn't they *just* install it? They resolve it and move on. A week later they download a crazy tech tree some modder made, which included TM, perhaps another old version. Again, another notification.

If a mod has external dependencies, the player should be directed where to obtain them. Or better yet, use an installation manager to resolve those dependencies.

Looks like miniAVC has its own 'multiple copies everywhere' check. I'll have to take a look.

Yeah, an installation manager would be great, but I see your point.

yep. Choose more than one tree when you start the game. Then, when in the R&D building looking at the tech tree, click on the drop down button in the top right. It will have the name of the currently displayed tree.

Can they have different nodes? If you maintain the node id across trees, will it remember what's been unlocked? Oh, my... The mind boggles... Ow! Owow!

edit: I would have realized that if the damned Unity checkboxes didn't look like radio buttons...

[NathanKell]

anonish, my understanding is that taniwha got around that limitation of the assembly loader by tagging his (internal) classes with the version number.

[Nertea]

anonish, do you have plans to implement that hideIfPointless business anytime soon? If so, I'd like to wait for it, if not, well, this is almost ready for prime time.