[Planning] Community Tech Tree

[RoverDude]

@Arlax - Cpt Kipard is correct, this project is about giving mods enough room to breathe with a lot more nodes to plunk our stuff in, and to share that work. Actual rearrangement of parts other than those created by participating mods is not within it's scope (and for clarity, said arrangement is the responsibility of the mod owner, not Nertea - well, other than for NFT ).

[madlemur]

Are you aware that this tree still retains the stock tree as its foundation?

As it should, or you'll effectively lock out legacy mods, or mods that aim to integrate with the stock tree. What it does is provide an expanded set of nodes for mod authors to put their parts into. It does not reshuffle any parts into a specific tree, nor does it alter the stock structure (aside from possibly adding the new nodes to the stock tree). Others can build configurations that reassign parts and restructure the tree.

[WhiteWeasel]

I've only managed to skim though this thread, but I was wondering if it is possible to add a multiple branch or radial tech tree? I think it would really cool because allow you to research multiple "subjects" at once so you don't have issue of aircraft showing up after rockets, because you just simply explored the rocket branch first.

As for the branch configuration I think four branches should suffice. Say one for general rocketry, mainly fuel tanks and engines. One for aircraft, wings, fairings, parachutes etc... The third for structure and command. Structural parts, command pods, decouplers etc... and the fourth for science and electronics. Power generation, science instruments, rover parts, electric and nuclear engines.

[CaptainKipard]

@WhiteWeasel

This thread is not the right place for these "wild" ideas but if you'd like to discuss a tree overhaul, which is more intuitive like in your description then I'll probably start a thread, just like this one, except with blackjack and logically divided branches.

I'm glad I'm not the only one looking for something like this.

[Nertea]

Wow.

I'm so disappointed with this.

You want to keep things simple. That's fine, but can I suggest that for your next project you make a community tech tree that's actually a whole new community technology tree, and not a forced progression tree?

Dude. You are the most antagonistic, passive-aggressive poster on this forum, and I'm kinda sick of it. If you want to make your own thing, go... over there and do it yourself. No need to come badmouthing other people's things. I stated my goal precisely in the first post of this thread (which you didn't read obviously).

Nertea,

The tree that I downloaded earlier (from the front page of this thread) doesn't have the node "Nanolathing". Is there an equivalent where the stocl parts that live there would end up?

It does appear that I snipped it by accident. I will re-add it.

This is looking great, and it looks like we're adopting it for RP-0.

I'm now going to be the packaging and standards dude who wants us all to agree on naming and conventions. I know some folks will be bundling the CTT, and I know others will require that it be downloaded. So the important question for us to answer now is: where in GameData will this sit?

I recommend GameData/CommunityTechTree/tree.cfg. That means we don't end up with multiple mods putting it in different places and us ending up with duplicates. It means that ModuleManager will produce a pass for CommunityTechTree, so parts can :REQUIRE or run :AFTER that. It means that CKAN packaging will run out of the box.

In terms of updates, we've got a few options. New versions can release with the same path, but then players run the risk of ending up with an old version of the CTT if a mod bundles an older version of it. If we're targeting TechManager (which I hope we are), then the tree should be ModuleManager friendly¹. One possible solution then would to then have tree.cfg be invariant across new versions, and changes be made by having update files (tree-update-1.1.cfg, tree-update-1.2.cfg). Those update files will run after the original tree.cfg and can update it appropriately. This means someone installing an older bundled CTT won't be changing any files, and the player won't end up with a surprise backgrade to their tech tree.

CKAN installs are of course immune to all of this, because the CKAN will always install the most recent compatible version of the CTT. I'm happy to do the CKAN packaging, although having releases on Github or Kerbalstuff will help a lot there, as our bots are then able to detect new releases automatically.

Thanks again for all your hard work on this, Nertea, I very much appreciate it!

~ Paul

¹ Anonish, I'd love your confirmation that my beliefs on the awesomeness of TechManager and ModuleManager are correct here.

This is pretty much what I though we'd do. That also seems like a clever way of handling the update situation.

[CaptainKipard]

Dude. You are the most antagonistic, passive-aggressive poster on this forum, and I'm kinda sick of it. If you want to make your own thing, go... over there and do it yourself. No need to come badmouthing other people's things. I stated my goal precisely in the first post of this thread (which you didn't read obviously).

No I'm not. You're reading a lot into nothing. Stop it. There has been no badmouthing, and please re-read my posts if you're so sure I've been trying to derail this project. Cheers.

[sal_vager]

Guys, it's really hard to get across ones real thoughts and feelings via text on a screen, so it's really easy to misinterpret peoples sentiments when they post.

Please keep this in mind, and use more emoticons

[Claw]

This still keeps the stock node names and structure. I'm asking for a complete overhaul.

And please can people stop saying what THIS tree is? I'm not asking for THIS tree to be changed.

Maybe this is the crux of the issue? If this isn't what you have in mind and perhaps if you are asking for something wholly different, then maybe it deserves it's own thread where you can fully articulate the ideas you have laid out in your mind.

That might prevent some of the misunderstandings and confusion about what you're talking about, if your ideas are off topic from the discussion about this plan.

Cheers,

~Claw

[RoverDude]

I'd concur with Claw. I expect a lot of the 'issues' are because certain people are trying to turn this thread into something that it is not. If you want something else - start another thread. If you have a question on Tech Manager itself - go to that thread - for in all of these cases, I suspect your princess is in another castle (or thread).

If you want to chat about how awesome it is going to be to have a tech tree that is unified with lots of breathing room for more advanced (and node hungry) mods, without mucking up all of the mods that use stock, then you've come to the right thread.

I for one can't wait to move all of my stuff in here

[DaveS]

I for one am looking forward to you're moving your stuff in here. While you are at it, karbonite plus I think currently gives fusion stuff too soon. But that's the kind of thing that this tree will accommodate nicely.

[RoverDude]

I for one am looking forward to you're moving your stuff in here. While you are at it, karbonite plus I think currently gives fusion stuff too soon. But that's the kind of thing that this tree will accommodate nicely.

Yep, By pure coincidence Nertea added a Fusion section

[dtoxic]

forgive my ignorance (and laziness) but i have a question regarding this upcoming tree and it;s nodes

will the stock nodes remain? (and as far as i understand it the new nodes will be connected to the stock ones right? )

[Chyort]

you can see a preview of the tree in the first post(pretty much the first line in fact). But yeah, all the stock nodes should be left intact, just new nodes added to give a bit more end game content.

Stock tree takes 9,000 or so science to unlock. i want to say someone added it up and this will take more like 90,000. (But don't quote me on that heh)

[Serino]

I do have a question. Whats left to be done, besides add nanolathing back in, cause it seems we have our tree and there seems to be no complaints about it currently. Unless there are more nodes that needed to be added is it time for modders who want this to start editing and others to start writing MM configs for those mods that haven't yet joined?

[RoverDude]

I believe we're in testing mode right now. Have been hip deep in another mod so I have not tested it in-game myself yet - any word on Tech Manager's stability, etc.?

[Serino]

I know for me it's stable. I have had no issues even with switching tech trees. MM is taking my config and placing the parts in the right nodes so far. Only thing I see that could be an issue is the amount of science needed gets severely prohibitive if you don't have mods that add more science parts or are playing on anything besides normal. Of course that would probably be offset by the fact that having a complete tree of parts would mean that you are very likely to have additional science modules.

[Nertea]

Yeah I've got no issues now.

Re: distribution, I'm wondering what to bundle. Some people are very against bundling, but I'm not, so... haha. Opinions? The two requirements are going to be TechManager and MM, should we bundle one, both, or none?

-edit: there's a repo now, feel free to peruse, comment and make ye olde pulle requestes.

Edited November 10, 2014 by Nertea

[madlemur]

Yeah I've got no issues now.

Re: distribution, I'm wondering what to bundle. Some people are very against bundling, but I'm not, so... haha. Opinions? The two requirements are going to be TechManager and MM, should we bundle one, both, or none?

-edit: there's a repo now, feel free to peruse, comment and make ye olde pulle requestes.

I would say neither. I would even go so far as to suggest that the CTT be an add-on to TM. This isn't as much a plugin itself as it is a configuration option.

Although I suppose there is an argument that all three should be bundled together...

[RoverDude]

I can go either way. What do you plan on doing with NFT? I think in the end it makes sense to do the repo as just the tree, and leave it up to the mods to bundle or not bundle, since folks really aren't going to grab this on their own, they will likely nab it with one of the larger mods using it.

[Serino]

Since techmanager already comes with a couple of trees I think it should be done like the old tech loader was with the tree in the techmanager folder and then the mods that absolutely need a tree bundle techmanager with their mod. Those mods that don't need a tree but want to add support for it can add the required tech to their mods and if the player has techmanager and loads CTT then those parts will already be set up for it if not then no worries.

[Nertea]

I guess what I want is for there to be a minimum of effort required by the end user and the modders who want to add support for their projects. It would be nice if the only extra thing I had to ship to support CTT was a single cfg file for each mod detailing the changes in the TechRequired field.

[pjf]

Since techmanager already comes with a couple of trees I think it should be done like the old tech loader was with the tree in the techmanager folder and then the mods that absolutely need a tree bundle techmanager with their mod. Those mods that don't need a tree but want to add support for it can add the required tech to their mods and if the player has techmanager and loads CTT then those parts will already be set up for it if not then no worries.

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.

I can go either way. What do you plan on doing with NFT? I think in the end it makes sense to do the repo as just the tree, and leave it up to the mods to bundle or not bundle, since folks really aren't going to grab this on their own, they will likely nab it with one of the larger mods using it.

+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.

[madlemur]

My vision (and it's admittedly astigmatic and I think there may be at least one cataract) would also be for integration with CTT to be a single .cfg file with a :NEEDS[CTT] (or whatever the correct MM syntax is) that put the mod parts in the correct nodes from the CTT node set. I'm assuming the mods will default to appropriate stock nodes.

Then, anyone can rejigger the CTT to their taste using TED, or their own l337 cfg coding skills.

In addition, there may be people who want to shuffle parts around the nodes (or expand the CTT with new nodes), and that's fine if they warn the end user that parts are going to be shuffled around.

[madlemur]

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.

Huh? New tree is just an additional .cfg file. No need to change TM.

+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.

Again, CTT is at most a tree .cfg file, and would never need updating unless TM changes cfg file formats.

[madlemur]

At its core, CTT is a standard. Not a plugin, not even a configuration. Just a standard. I think a default/sample tree should be published with Tech Manager, so that there is an implementation available. But that's about it.

Although I just had a horrible thought. How do we know which tech tree TM is using? If I have TM/CTT installed, but I've chosen to use the stock tree, how do the mods make sure that their CTT .cfg files are not processed (and parts stuck into non-existent nodes)?