RoverDude

I think the guy who's the author of both of those mods already knows I'll be correcting it in this weekend's release anyway. Not in the threads since I kinda just found out like... today, and I'm still in the office.

@Fractal_UK I'll go ahead and address the next elephant in the room since it was not clear form your post. Is it your intent to: (a) participate in the community tree so users can use USI mods, NFT, and KSPI simultaneously (and given the efforts other folks have spent making this happen, it appears to be where the users want to go) ( keep KSPI as it's own tech tree without interop with the Community Tech Tree © Do both (participate in the community tech tree and also have a KSPI-only tree)? It would be good to address this now as it likely affects how Nertea is laying things out. (Edit) I don't see why the community tech tree would have MM configs? The entire point is that a set of common nodes and their relationships is defined, and the mod authors drop their stuff in there as part of our regular configs - i.e. I don't see it as a special case, more just a largish tree that multiple mods share. My concern, and hopefully it turns out I am incorrect, is that we will miss the interop boat again.

So how do we support multiple trees at once? Or can we? For clarity, how does a user load the community tree and the kspi tree simultaneously, or would a user wishing to use MKS/NFT and kspi simultaneously require a single tree?

@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).

Thanks! The USI page is just a Github Pages site - you can add this to your repo and it's free. Google GitHub pages

I'd also add.. this is more something a mod would have a dependency on and bundle (which you'll see happen out of the gate) and less something a player would or would not elect to install. I think that goes back to the confusion about standardized nodes vs. dictating what goes in those nodes.

Let me phrase it a different way. If a mod decided that they actually needed an extended tree, it's a pretty basic assumption to assume said mod would not say 'gee, let me put this fusion drive out on a leaf where I can't get to it to even test that it actually works...'. Again, I think you're over-extending scope. This really is not a particularly hard problem space. You have a tree with nodes... folks are free to use it, or MM it or whatever... but use common sense (like, don't stick your mod on a dead end). So in your example of a fusion drive, if he tossed it so far up the tree that he couldn't even test that it worked in career... yes, that's willfully ignorant. And up to the modder to sort out, and very likely out of scope for this tree to act as police for all of the mods out there. Given the audience is modders, I have a lot more faith in their ability to work with config files, and I expect that even if one messed up and put it in a black hole, that's something for the modder to address, hence no consideration needs to be added for this project other than to make sure we have paths to the stock tree. Nice and simple. @KaiserSoze My impression is that the final product will be a tech tree compatible with TechManager that defines a standardized set of config nodes that encompass the needs of the few mods that used to rely on TreeLoader, as well as open things up for other people to use the same standardized tree, primarilly because in it's current state, it wipes out and rebuilds the tree, so there is no dynamic merging. Hence the need to have something we can share without stomping on eachother.

@Starstrider42 I'd take it one step further - don't worry about TAC-LS unless Taranis wants to participate I expect the problem space will rapidly diminish.

@Streetwind I really don't anticipate empty child nodes being an issue because this is something we haven't had an issue with in the past - that is to say, any mod who actually *needs* an extended tree (and there are very few of those) would know to not paint themselves in a corner with an empty node - i.e. I would assume the mod author would test their tree with just their own mod + stock - so the empty parent node should never occur unless someone is willfully ignorant. I would advocate not making any assumptions for any mod out there whether it's TAC-LS, DRE, etc. - those ones remain best served by working in stock nodes because in most cases, people simply don't have one of the few tech-extending mods installed. That being said, a mod *might* chose to shuffle them around, but I would see that as completely out of scope. This is just framework stuff. At the end of the day, this would just be the DLL distributed with possibly a MM config at the mod level for any rearrangement. Your worst case scenario there is having two of us move the same stock element, but again given the audience and scope, I expect that will be a weird edge case solvable by a simple conversation (tbh I don't know if even NFT moves anything around in stock - USI does not, and I don't believe KSPI does). Best bet is to be careful on scope and not over complicate things. This is just scaffolding for people to use responsibly, and the number of people that would actually need this can probably be counted on one hand. @Starstrider42 I don't think there needs to be a limit to the depth since these are in support of mods that will by definition already need to fill in that tree. I think the right answer is 'if your mod is going to use this, you can't leave any gaps between your parts and stock, nor gaps in your tree. i.e. common sense, and issues that would pop up the second they tested their mod.

@undercoveryankee Good deal. And it looks like Nertea is already adding ones sufficient to cover KSPI. We may have interop yet

That's it

You already have all of those other than KSPI So ball is in Fractal's court. I'll move forward using Nertea's community tech tree project regardless.

Oh, I see no reason why it won't work, mostly because we have no better alternative, and have no choice. I'd go one step further and say it already has worked, because I'll be migrating 100% of the USI mods (what I already have, plus all future expansions including my upcoming ELP integration) into this. And given we have... what? Two major mods out there today that have custom trees - NFT and KSPI. And between Nertea's constellation and mine, we're already hitting a significant chunk of the userbase. So the only outstanding question will be if Fractal wants to play on the playground or not. If so, awesome. If not, then I don't see it in any way diminishing the success of the project.

@Angel-125 - do me a favor and do your pull request as separate part modules/etc, since I want to fiddle a bit with how I integrate it Thanks!

@Paul Heads up - the USI Tools folder will change this weekend to better support CKAN. I have an all-in-one experimental version of all of the USI stuff on dropbox and you can get the new folder there. Note this does not conflict code wise with the prior version but wanted to give you the proverbial heads up

If you use MKS + Karbonite there are some duplicate LEGACY folders - get rid of the Karbonite one. Also - Nertea has started up a community tech tree thread. This is awesome. It would be double awesome of KSPI were interested in participation as it gets us back on the right path towards interop. @Fractal_UK any interest in KSPI participation?

Love it The options you have up there make sense, with the only distinction off the top of my head being colonization type construction (I'd toss MKS/OKS/Asteroid mining there) and 'Make really big ships' construction (for FTT, 5m+ rocket parts, ELP, etc.) 110% in and will use or adjust to whatever you end up with!

Probably not nearly as bad as all of that. If you look at what, say, NFT and KSPI do (and where I would have had USI except we kinda lost treeloader)... we all tend to add new sub-branches, not monkey around with the current tree. KSPI adds a few nodes, NFT adds some, and I was planning on adding a Colonization branch. I daresay between those three (KSPI, Nert's constellation, and mine) you've pretty much covered all of the advanced tech mods. Not placement IN those nodes (go nuts), but the node relationships themselves. Others I am aware of (say, LLL, etc.) just use the existing expermental nodes). So right now we have three choices - given that (as of now) we have to wipe the whole tree: 1. Only allow one mod to use this (boo!) 2. Force players to choose which mod to use (double boo!) 3. Put on the big boy pants, toss the tree nodes together, and agree not to be jerky-jerks stomping over eachother until such time as we can use this without stomping the tree. 3 should not be that hard. Fractal's stuff is on far-end tech tree progression. Mine is on colonization and construction. Nert has his own sub-trees that are more.. um.. 'near future' than KSPI. Lack uses the existing nodes. 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. Again, once we can merge different sub-trees on a mod by mod basis, we're pretty golden because then we just do our own sub-sections and be done with it. But that has some thorny problems of it's own (duplicate nodes, positioning, deletion of stock nodes, etc.) that get a little weird. So much better for everyone to cooperate.

The rub unfortunately as always will be getting folks to agree or even acknowledge the existence of a shared playground (hence why I was finally forced to fork ORS because it was that, or forever have Karbonite and KSPI incompatible). I would REALLY hate to see the same thing happen here, where users are forced to choose KSPI, or NFT/USI/etc. but ultimately that's not really up to me. I'm more than willing to start up a shared tree that keeps KSPI in it's current form and merges in NFT, etc. and start a thread - but it's going to be pretty much worthless unless everyone agrees to distribute it, and would be a waste of my time if it's just going to get stomped on by a KSPI install. So if someone other than me can convince Fractal of the value of playing on this particular shared playground, I'll start a thread. Otherwise, I'll just have to wait till this can be configured in a way that precludes aggressive over-stomping by other mods.

What would be lovely is if those of us with mods that wish to extend the tech tree (since this just defines the nodes and not the parts) could agree on a community-standardized advanced tech tech-tree that we can all share (i.e. the USI Constellation, KSPI, NFT, etc.)

Here's mine You can see the jettisoned last launch stage in the pic. Key is to launch dry, and accept that the launchpad is toast.

Supplement. A lot of it is that mod's code broken out and made a bit more generic. When WaRi and I worked on it, we agreed to remove some of the resource complexity and move it into it's own mod (hence why resources got simplified in ART). Going further, it would be nice to have one backend resource system to support asteroids/planetary/atmospheric/oceanic stuff - so this will also supplant OSX (but bring along the 'X' bits, like animation groups, etc.) and be done in a way that's very friendly to multiple mods, breaks the dependency on PNGs, and will work automatically on new planets (think Star Systems, etc.) This is kinda why there's been less stuff lately as I've been hip deep in this - lots of design, code, and modeling going on. Thanks

Toolbox, not yet used Wait a few days - I have an all-PNG replacement coming out

11/1 is mostly a maintenance release. TGA->PNG, new DLLs, some MKS fixes, various bug fixes, etc. so not a whole bunch of new content - working on other bits behind the scenes