[Planning] Community Tech Tree

[RoverDude]

Coming about beautifully.

Custom icons would also be incredibly sweet (saw your cross post).

I'll give the nodes another pass but so far I think we're in incredibly good shape. I have one of my own constellation releases this weekend, but figure what I will do is right after, convert everything I have to the new tree for my next one. At that point I fully expect we'll start seeing other folks hop on board either with MM configs by the community or by direct support.

[Starstrider42]

While my knowledge of programming is pretty good, yay college and years of fun with writing programs, my knowledge of how .cfgs for kerbal is a bit limited right now so correct me if I'm wrong but wouldn't it be easier to, instead of needing the mod writers to make two seperate trees, instead have a tag that they can add to their trees to check for the community tech tree and then shunts the parts into the appropriate node as CTT defines like a simple if else statement. Assuming of course you could load multiple trees this would mean little extra work on the modders part and the user just needing to load the trees for the mods s/he is using.

I gave an example of exactly how to do this to let a mod work with both stock tree and CTT in http://forum.kerbalspaceprogram.com/threads/98409-Planning-Community-Tech-Tree?p=1507750&viewfull=1#post1507750. It requires ModuleManager, but no other special support, including no special CTT or TechManager features.

Sorry for dropping off the grid, all, but RL means I probably won't have much KSP time for the next week or so. Good luck, everyone!

[Bishop149]

I don't have very much practical to contribute to this thread but would just like to say that idea of some kind of multi-mod spanning unified tech tree structure is an excellent one, which I wholeheartedly support and its very nice to see everyone co-operating to bring such a thing into being.

Well done, more of this sort of thing!

[Serino]

I gave an example of exactly how to do this to let a mod work with both stock tree and CTT in http://forum.kerbalspaceprogram.com/threads/98409-Planning-Community-Tech-Tree?p=1507750&viewfull=1#post1507750. It requires ModuleManager, but no other special support, including no special CTT or TechManager features.

Sorry for dropping off the grid, all, but RL means I probably won't have much KSP time for the next week or so. Good luck, everyone!

Not sure how I managed to miss that post but I still see a need for a tech tree download that contains the community tech tree for that to work but that seems just a simple matter of being a cfg download. The only issue I see is doing that requires all the modders who want to participate and already have mods to go into their code and update it part by part is there no simpler method that can be released as a download with the tree we will already need to get?

[DMagic]

is there no simpler method that can be released as a download with the tree we will already need to get?

For adding parts to the new nodes? Someone is going to have to assign Part A to Node X for everything that supports this, presumably that would be the addon owner, or someone making an MM config set for someone else's addon. I don't see any way to automate this process, nor would I think that was a good idea if it were possible.

[RoverDude]

For adding parts to the new nodes? Someone is going to have to assign Part A to Node X for everything that supports this, presumably that would be the addon owner, or someone making an MM config set for someone else's addon. I don't see any way to automate this process, nor would I think that was a good idea if it were possible.

That's pretty much what I'm doing... the entire point for mods to use this is to take advantage of this and distribute it as a core part of their mod. I know I won't have any MM configs, and given I probably have as many parts as Nertea, I didn't even blink at the idea of having to do a tech tree run with my stuff.

[Serino]

For adding parts to the new nodes? Someone is going to have to assign Part A to Node X for everything that supports this, presumably that would be the addon owner, or someone making an MM config set for someone else's addon. I don't see any way to automate this process, nor would I think that was a good idea if it were possible.

I have noticed that the Interstellar tree cfg defines what parts go in what nodes while the part cfg has nothing and since this is a COMMUNITY tech tree that modders have the ability to join then wouldnt it make more sense for the modder who want to join put up what they want in what nodes, after of course a set tree is determined, and then distribute a tree that has those parts set into those nodes automatically there by making it simpler for everyone and making it truely community based rather than having to read from each mod where things are going to go. This would also allow the individual modders to distribute a tree specifically for their own mod, just like what was discussed, if someone only wants one mod.

[RoverDude]

Sorry I'm not sure I understand what you're saying...

The point of a community tree is that we all share the same tree, Simple as that. No different than how CRP works. So if you install Karbonite, you have exactly the same set of nodes as Near Future, and vice versa. So my job is incredibly easy - I just toss stuff in via config like I always have, because I bundle this tree with my mods, no different than how I bundle FireSpitter or CRP.

You will have two exceptions to this (and again, exceptions not rules). A mod or someone extending a mod may choose to have their parts appear either in the stock tree or the CTT if it's present (i.e. TAC-LS). Or a mod, like KSPI, may choose to have their own tree but also have a configuration that works with the CTT.

I think the only person discussing a separate tree for their mod was Fractal_UK - which is kinda contrary to the idea of a community tech tree. Now what folks choose to do with TechManager is a whole different kettle of fish - that's just a tool that facilitates making trees. But make no bones about it, the point of this project (CTT, the thread you're in) is a *shared* tree that several of us will use. I for one (and I expect Nertea as well) plan on using what comes out of this as the sole tech tree for our mods. Distributing a unique USI tree in addition to distributing CTT makes no sense, since CTT *is* the unique tree.

Hence, why I was pretty firm about not steering into bad places when the whole 'mods should have separate trees' bit threatened to poison this thread, because that is precisely the opposite of what a community tech tree should be.

(And by tree we're referring to node layouts).

[pjf]

Wow. From my skimming of this thread, I'm loving this. I have a desire to make a "Realistic Progression Zero" (RP-0) tech tree, which is to take the RealismOverhaul side of the of the modosphere, with as few dependencies as possible, and apply it lightly onto an existing (formally stock) tech tree. That means keeping the same nodes, but potentially moving the tech around a little (Mk1 pod would likely come in with survivability, Mk1-2 with recycling, etc). My expectation is that most later-game tech won't change location at all.

I would love to do this with the CTT, and am generally happy to work with whatever design comes out of the discussions (it's looking great so far!). While I'm currently working full-time on the CKAN, and so it's likely to be a while before I can pick up tech trees at all, but I am *very* excited about what's going on here. Thank you. <3

[Starstrider42]

That's pretty much what I'm doing... the entire point for mods to use this is to take advantage of this and distribute it as a core part of their mod. I know I won't have any MM configs, and given I probably have as many parts as Nertea, I didn't even blink at the idea of having to do a tech tree run with my stuff.

BTW, I don't think you should assume that everyone is going to want to *bundle* CTT, just because that's your preferred way of dealing with mod dependencies. Bundling tends to lead to dependency hell, as I'm sure you've noticed yourself, and this goes double when the whole point of the dependency is for everybody to have the same version. So modders should have the option of saying CTT is required for their mod but merely pointing players to the CTT release thread.

Edited October 31, 2014 by Starstrider42

[pjf]

BTW, I don't think you should assume that everyone is going to want to *bundle* CTT, just because that's your preferred way of dealing with mod dependencies. Bundling tends to lead to dependency hell, as I'm sure you've noticed yourself, and this goes double when the whole point of the dependency is for everybody to have the same version. So modders should have the option of saying CTT is required for their mod but merely pointing players to the CTT release thread.

This is very much a problem I'm working on solving with the CKAN. Mods depending upon the CTT can simply include that dependency in their metadata. That means we don't end up with everyone bundling the same resources, and it means it can be kept up-to-date without releasing new versions of the mods that require it. Mods which support (but do not require) the CTT can state they recommend, suggest or support the CTT, which means the user has the option of installing it, but it's not required. For example:

{
    "identifier" : "RemoteTech",
    "$kref"      : "#/ckan/kerbalstuff/134",
    "suggests"   : [ "CommunityTechTree" ]
}

While we're still in pre-release, the dependency code for the CKAN is quite stable, and works very well. Even when a mod bundles another mod, the CKAN still fetches the authoritative version of the bundled mod (which can be restricted by version, if desired), and installs that. (In fact, the spec will soon be updated to deprecated bundled mods altogether.)

So I'm *very* much hoping to provide the tech here to solve the dependency hell. (For more info, we've got a forum thread and github project, and further CKAN discussion is best done over there so we don't de-rail this thread).

All the best,

~ Paul

Edited October 31, 2014 by pjf
fix tpyos

[RoverDude]

@starstrider42 oh no debate, that's more of a delivery concern. But either way we land with a single shared tree not ten bolted - together trees with five separate branched distributions, or worse yet, incompatible trees where players are forced to choose mod a vs mod b

[Serino]

BTW, I don't think you should assume that everyone is going to want to *bundle* CTT, just because that's your preferred way of dealing with mod dependencies. Bundling tends to lead to dependency hell, as I'm sure you've noticed yourself, and this goes double when the whole point of the dependency is for everybody to have the same version. So modders should have the option of saying CTT is required for their mod but merely pointing players to the CTT release thread.

^^ This was why I suggested we have a tree that the community of modders who wants to use it informs someone who maintains the tree as to what nodes they want their parts in. It would be just a quick message or post to add or remove parts rather than having to worry about adding in anything or bundling anything. It also allows those who want/need their own trees, like Fractal, for their specific mod if someone just wanted that mod. A cfg wouldnt be that hard to maintain and it would be simpler for modders and users both that way, no bundling needed no worrying about overwriting a file that you shouldnt have or an accidental oopsie of forgetting to add a dependency or node requirement for a part just install the mods you want and the CTT takes care of the rest using the agreed upon tree and nodes that the modders have requested their parts to be in with no worries if you dont have CTT.

[jinks]

I gave an example of exactly how to do this to let a mod work with both stock tree and CTT in http://forum.kerbalspaceprogram.com/threads/98409-Planning-Community-Tech-Tree?p=1507750&viewfull=1#post1507750. It requires ModuleManager, but no other special support, including no special CTT or TechManager features.

I'd suggest going even one step further and making it a requirement to support CTT only per ModuleManager. Have a mod's part.cfg files reference only stock nodes and then rearrange them into the CTT per MM config. That way whatever happens with CTT players can be sure that their chosen mods will continue to work no matter what. Pressing high-tech mods into the stock tree isn't pretty and there will be a lot of shoehorning, but having fallbacks is a good thing.

This would have the CTT depend on MM, but I doubt that's really a big burden on players. Setting up a modded install without MM is essentially impossible these days anyway.

[RoverDude]

@Jinks... Sorry, No. As a modder with a large set of mods, the option of requiring MM for config simply offers no value, and if anything adds negative value because now a have a bunch of work to do vs. just establishing my dependency and being done with this. Bear in mind this is the case where, as a modder (and one who's 110% behind anything that helps with standardization and helps our users) will just take the hard dependency and call it a day. Easy peasy.

(edit) Naturally if this suddenly breaks (as we saw with 0.25) then I'd just do a service patch and revert the tech tree. But in my case, having stock nodes as a fallback is sub-optimal, and I don't want to propagate that unless forced. Also our 0.25 issue was pretty much a licensing problem. The issue was fixed pretty quick, but because people are grinches, we could not distribute a fix.

@Serino - In re-reading your post, you may not realize that Nertea is not including or dictating WHERE stuff goes. That's a horribly thorny problem. He's just making a web of nodes. There's no need for a maintainer to move stuff around because there's nothing to move around. We, as modders, are simply picking which tech tree to tie our horse to. And given I have a huge overlap with NFT, having myself and Nertea use the same tree is going to rock.

There will be config files... for the people who just want to be compatible and take advantage of this tree *if* it's there (or use a stock tree or a custom tree if it's not). But that's not the default case as relevant to this thread.

That being said, I fully expect you will see MM configs pop up to shuffle things around, but that's going to be something the community will do on their own - for example, I can pretty much guarantee that if Fractal_UK does not include his own config with Interstellar to support CTT, someone is going to make a KSPI version that fits in this tree within a week of launch, just because we have a lot of overlap in users (and making them switch trees back and forth in the R&D center is a sub-optimal solution)

Folks are kinda overcomplicating what is in effect a very simple solution. We have a set of nodes, no different than stock. The entire point of which is that as a player, I select my tree, and everything just works. From a modder's perspective:

Don't need a custom node?

Since stock nodes are not being deleted, anything stock... just works.

Want a custom node but still support stock, but don't want the hard dependency?

Awesome. Make an MM config with a stock fallback for your parts. Done.

Want a custom tree for your large mod and like what they have in CTT, and really don't want to deal with shoehorning into stock (this is the land where NFT, USI, and KSPI play)?

Rock on! Here are a few choices:

Want awesome interop (NFT/MKS/Karbonite/Anything USI land) on a shared playground?

Sweet. Use CTT. Take the hard dependency, and either bundle, use CKAN, or tell people in your thread when they see no parts that they need to download this.

Want the option of interop but use your own tree for folks who JUST have your mod (this is KSPI land)?

No problemo - just include a config that works with CTT so your users that have, say, MKS as well as KSPI have an easy tech tree to work with.

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! Now is the time to give Nertea feedback and see about making sure your tech node needs are addressed.

None of the above? No interest in interop?

Peace out. Do your thing, just don't be surprised when the community rejects isolationism and starts making compatability packs to make your mod play with others.

Offended by the very idea of people working together towards interop and want to grinch it up?

See above

Edited October 31, 2014 by RoverDude

[Jashin]

This idea is stunning and I'm glad some of KSP's best modders cooperate to create a smoother tech tree for us players. The project is looking great and I'm looking forward to implementing the tree in my new career save. Keep up the great work

[Nertea]

I very much do not intend to assign parts to nodes. That's a bloody nightmare for maintenance, imagine that every time a mod gets updated, I'd need to update the tree. Awful.

I'll start laying out the tree in game tomorrow. I don't have a huge amount of time this week, but maybe it'll be available by next weekend. I have my other projects to work on too.

[Serino]

@Nertea not sure how it would be a nightmare cause the suggestion I made just references the parts it doesn't define them so the only updating that would need to be done would be if someone wanted to add or remove a part from the tree. I get where you are coming from though considering you have your own mods to maintain.

@RoverDude it just seems like what you are suggesting requires more work for modders than mine, while I can see the thorny problem of overcluttering of a couple of nodes or parts going into nodes that aren't connected to others we will still need a CTT download to have the proper tree, I keep mentioning this cause your mods and nertea's mods may share many of the same nodes but there will be nodes nertea has that you don't and nodes you have that nertea doesn't. It just seems like it would be easier to have one person do a small bit of work with the ocassional need for update instead of having every modder having to update their mods to use this and all the players needing to redownload all of their mods that are using this just so that they can take advantage of it.

now I may be over complicating my explination or may knowledge of how the tree and such are handled may be too lacking for me to see some of the more complicated problems but it just seems like there would be an easier way to do a CTT than just having everyone use the nodes that are set out and include that into their mod.

Now a question for me own curiosity, but could actually be a problem later, is how would you get two different tree files to play nice when they use different nodes of the same tree without the ability to merge them together and then attach the needed nodes to the stock tree? Because in all the posts I don't remember if anyone answered this question.

[RoverDude]

@Serino - Nertea and I will have exactly the same nodes. 100% overlap. Because we use the same tree. If you only install USI mods, you may not see some nodes light up (and vice versa), but make no bones about it... it's the same tree behind the scenes. That's the entire point

The easiest way to use this is precisely what Nertea is doing. He's providing a stable framework we can build off of... in the context of our own mods. And since it's just nodes (which rarely change, if ever) then maintenance is pretty much zero. Counter to that, I add and move parts around every week or two for my mods (I have half a dozen new parts in this week's release alone, plus part deprecation, etc.). If I depended on a third party to maintain those configs, or had the misfortune of players using an old version of those node configs, I would be completely hosed. It's a non-starter.

Now, what I could see happen that IS in line with what you're saying, is if someone were to take Nertea's final layout and publish MM configs for popular mods that are NOT part of CTT to put them in new places, just as the different custom trees out there work today with ATC (an example will be KSPI, if Fractal_UK doesn't do this himself)

But that's not the modders doing it, and based on Nert's comment above, that's not going to be Nertea doing it, nor would it make sense for CTT as it's counter to what it is supposed to be (a node framework for people to leverage). But there is most definitely space for it to be done via MM... and it sounds like you're volunteering I look forward to your release thread

[Nertea]

@Nertea not sure how it would be a nightmare cause the suggestion I made just references the parts it doesn't define them so the only updating that would need to be done would be if someone wanted to add or remove a part from the tree. I get where you are coming from though considering you have your own mods to maintain.

@RoverDude it just seems like what you are suggesting requires more work for modders than mine, while I can see the thorny problem of overcluttering of a couple of nodes or parts going into nodes that aren't connected to others we will still need a CTT download to have the proper tree, I keep mentioning this cause your mods and nertea's mods may share many of the same nodes but there will be nodes nertea has that you don't and nodes you have that nertea doesn't. It just seems like it would be easier to have one person do a small bit of work with the ocassional need for update instead of having every modder having to update their mods to use this and all the players needing to redownload all of their mods that are using this just so that they can take advantage of it.

now I may be over complicating my explination or may knowledge of how the tree and such are handled may be too lacking for me to see some of the more complicated problems but it just seems like there would be an easier way to do a CTT than just having everyone use the nodes that are set out and include that into their mod.

Now a question for me own curiosity, but could actually be a problem later, is how would you get two different tree files to play nice when they use different nodes of the same tree without the ability to merge them together and then attach the needed nodes to the stock tree? Because in all the posts I don't remember if anyone answered this question.

That's exactly the nightmare though. What you are describing means that every time a mod adds a part, I need to update the tree. Thats not an infrequent thing, there's a lot of part mods out there. That modder has to communicate with me, the location needs to be defined etc. You could end up with needing several updates in a single day, even. That's not fair to me, and its not fair to modders either, waiting on an update for a third party. I'd hate it, if I was the modders waiting for a tree update and having to deal with support requests for something out of my control.

[anonish]

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.

[Serino]

Thank you for a better explination RoverDude. I understand that anyone who uses this will be using the same tree but I was more thinking of how would one mod, like kspi, that uses nodes yall dont be incorporated with the yalls mods. as in how is the game going to know to combine the two sets of needed nodes into the coherent tree that is trying to be made here, or is that done by techmanager? and as for Nertea while i frequent the forums daily I didnt realize that parts were added and removed that frequently so with that knowledge I could see how constantly adding and removing part ids would get tedious and annoying. on top of that i didnt think about the point that you both mentioned of having to wait for the update for the mods to be usable and i could see how that would be horrible. so my only real question is what i mentioned before how are all the parts going to be put into the tree? is each mod going to release a version with their parts in the appropriate nodes and techmanager takes care of it merger wise or is there going to be just a blank tech tree that players download and then in the part files each part points to the node it needs to be in?

[Dr. Jet]

Maybe you should use Gliffy for community project?

Look at my techtree draft example. Quite easy to see what goes where.

And Gliffy allows community editing if project master enables this option.

[Serino]

Maybe you should use Gliffy for community project?

Look at my techtree draft example. Quite easy to see what goes where.

And Gliffy allows community editing if project master enables this option.

After them pointing out the glaring flaw that I missed it would still require a download to make the mods work again which as they said would be a massive pain on top of the fact that allowing community editing would allow trolls to go in and jack things up just to mess with people or someone could make a mistake and screw it all up so that would definately become dangerous. They have had way more time to think about it than I have and so far after Rover and Nertea were so patient with me and my ideas it turns out that what they are planning would actually be the best option for everyone in terms of usability, unless some magical new options that none of us here have thought of show up.

[DaPatman]

Maybe you should use Gliffy for community project?

If you'd read the entire topic, you'd know that Nertea is already using it.