[Planning] Community Tech Tree

[RoverDude]

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

[Starstrider42]

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

That's why I said it was a *hypothetical* example. I picked TAC-LS because Nertea already suggested adding life support nodes (which IMO are a good idea whether or not any specific life support mod uses them), but it can obviously get by just fine with the stock tree, and so is unlikely to ever have a hard dependency on CTT no matter how Taranis feels about the project.

Edited October 28, 2014 by Starstrider42

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

Yes, this has never come up until now because so far, mods that required it were also required to supply their own tree. But now, with this community tree, you will be defining what nodes are there for modders to use. The modder that peviously made sure that he has just the right amount of nodes for his stuff now needs to fit the same stuff into the potentially quite different framework that you're developing here. It also seems a bit naive to imagine that every mod out there has plenty of parts at its disposal. There is a mod that simply adds a fusion drive, for example. Nothing else, just a fusion drive and its constituent parts. Right now those get tossed somewhere into the upper end stock nodes, and that's fairly lame, so if the community tree comes and says "we have a high-end node perfectly suited for fusion drives to be in!", then would you fault the author for wanting to put his parts into it? Would you call him "willfully ignorant" just because his mod never had the scope for anything other than a fusion drive, and is thus unable to populate the way up there?

If you're aiming to provide a service to the community, then it needs to at least make an honest attempt at addressing the needs of all possible mods, not just a few large ones. That would be a "USI / NF / KSPI cooperation tree", but it certainly wouldn't be a "community tree". It may not be possible to hit every corner case, but why dismiss them outright?

[KaiserSoze]

I am also curious about the "final product" of this.

Will this be a "tree.cfg" compatible with TechManager (or any other mod with similar scope)? If this is the case the work will be in creating that file including all the mods that want/can be compatible and maintaining it in case a new mod arises or an existing mod requires new node. If that is the case I already have a tree with KSPI and NFT (no more changes). It was quite simple, just merge the two trees and move icons to avoid overlapping.

I'm pretty sure I was not the only to this for personal reason, but I'm willing to release it as soon as I test that it works with Remotech (it was made for treeloader in .24.2) in case it is useful for this.

[RoverDude]

<words>

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.

Edited October 28, 2014 by RoverDude

[Streetwind]

That line of reasoning doesn't satisfy my concerns. If you expect modders to just dump their parts into "stock+1" nodes in case they can't build a path themselves, then that won't result in a tech tree, but rather in an unstructured dump of parts. It carries no advantage for any but the largest mods to adopt, and for me as a player, it sounds less and less like something I'd actually want to install.

I think we'll just have to agree to disagree on this point.

[Starstrider42]

That line of reasoning doesn't satisfy my concerns. If you expect modders to just dump their parts into "stock+1" nodes in case they can't build a path themselves, then that won't result in a tech tree, but rather in an unstructured dump of parts. It carries no advantage for any but the largest mods to adopt, and for me as a player, it sounds less and less like something I'd actually want to install.

I think what RoverDude is saying is that modders will be smart enough to find the solution that works best for them. For example (to repost a suggestion of mine that seems to have been buried), they could put your hypothetical fusion drive at the tip of the community tech tree, and then use MM to force a chain of prerequisites to be visible whether or not they contain parts. Clumsy, but better than an unstructured dump. Or they could use MM to add a direct link from the stock nodes to the fusion node, conditional on there being no parts installed that use the intermediate node (using MM's :HAS and :NEEDS for the programming). There's tons of possible solutions from the modder's side, and that's not even counting "they could just not use this tree".

[RoverDude]

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.

[K3-Chris]

I've always had problems conceptualizing what kind of tech tree would make sense for KSP, problem with the stock tree is that it limits your choices to basically force a version of a tutorial on you whether you want or need it or not, the "better than starting manned" tech tree seems a more realistic route which mimics how actual space tech progressed, but it's run by a crazy person that hates all mods.

But entirely sandbox removes even the few goals we have from the game.

I don't fancy biome hopping the mun, minmus and kerbin to get to half finished tree when you can actually make interesting craft, and since my primary focus is logistics via TACLS/UKS and SSTOSPs etc using B9 the fact that most of those parts are really far up the tree is annoying to me, I've started to just "cheat" to that point in the tech tree and go from there, lower half doesn't hold any interesting challenges for me, just boredom at this point, though I wonder if that "guided" experience has a benefit for new players or not.

But opening up small rockets, small planes and small rovers at the start seems a sensible idea, fine print has missions to explore nearby KSC in rovers, small rockets can go to orbit and perhaps fly past the mun etc, allows you to put satellites in fine-print orbits with ScanSAT instruments, small planes can explore kerbin and do fine print missions to fly to specific places on kerbin.

I liked the old KSPi tree at the top end, let you have harder to reach endgame goals.

[gameguy600]

I seriously hope b9 will start supporting this. A lot of its parts just don't feel right in the stock tree.

ps: This is shaping up to be something amazing. I've always wanted some sort of ''one tree to rule them all'' type mod tree and this might be it. Anyway i wish you good luck with this project. I might even provide support to this if i ever have the time to create my own mods and learn modeling.

[Tellion]

Words fail to describe the awesomeness of this community ._.

[undercoveryankee]

I think what RoverDude is saying is that modders will be smart enough to find the solution that works best for them. For example (to repost a suggestion of mine that seems to have been buried), they could put your hypothetical fusion drive at the tip of the community tech tree, and then use MM to force a chain of prerequisites to be visible whether or not they contain parts. Clumsy, but better than an unstructured dump. Or they could use MM to add a direct link from the stock nodes to the fusion node, conditional on there being no parts installed that use the intermediate node (using MM's :HAS and :NEEDS for the programming). There's tons of possible solutions from the modder's side, and that's not even counting "they could just not use this tree".

ISTR seeing TreeLoader trees (e.g. Realistic Progression Lite) that had empty nodes visible as prerequisites for occupied nodes. If that was something TreeLoader did and TechManager doesn't, it could be worth contributing an automatic "prerequisites of occupied nodes are visible" behavior to TechManager.

[Nertea]

I think that most of these issues are surmountable, but really in general I aim to provide a framework. It'll be up to modders to support that framework with a fair idea of its limitations, or not to use it.

The issue with one off parts is that they're one off. Do they expect tech tree support off the back? Is it a bonus, instead? I can think of a few ways to address these. More when I get home.

[anonish]

Try not to lock yourselves into thinking the end result of this has to 1) be a static tree.cfg file and 2) can only use existing ConfigNode properties

The empty node problem could be solved by simply including a hideIfPointless flag to the config file. Then TechManager looks at the parts and at the tree and deletes / hides / never bothers to create in the first place any nodes that have that set and who have no parts anywhere in their subtrees (children's children's children...)

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

well... I'd love to see something more API based. I think Toolbar works that way. Mods use a generic interface to play along. Each mod can request a subtree that it defines. Common techID's are merged into one. Placement is an issue, maybe some k-means clustering to put things so they don't overlap -- but that kind of dynamism would probably lead to occasionally ugly trees.

ModuleManager is awesome, just don't forget that TechManager can do some lifting too.

[Nori]

I really love this idea. I use Rover's plethora of mods along with NFT and a variety of other smaller mods and they just feel odd where they are in the stock tree. But so far the other trees people have made seem kind of odd too.

So yeah, simple expansion of the stock tree.

A few people mentioned some nodes earlier in the tree. I really like this idea. Mods that would heavily benefit from this is Station Science, DMagic's Orbital Science and TAC LifeSupport. None of these mods fit right in the stock tree IMHO and 3-4 more nodes early on would be awesome.

[dtoxic]

hello all

@Nertea: maybe you wanna give some information about tech tree and all other stuff conserning nodes to this guy so he can implement them in his tool too

maybe it;s worth it

https://github.com/jcalero/ksp-techtree-edit

[Fractal_UK]

I'm working on some modifications to the TechManager so that it's possible to simply select a tech tree from a selection of tree.cfg files installed in the player's GameData folder.

You define tech trees as follows, using the "id=" part to determine the unique name that you want your tech tree to have, the user can then select between all of these possible trees for a given savegame.

TECHNOLOGY_TREE_DEFINITION
{
    id = KSPITree
    NODE
    {
	name = newnode_7144
	techID = interstellarTechFusionPower
	pos = -404.5,1175,-18
	icon = NUCLEARPROPULSION
	cost = 3000
	title = Basic Nuclear Fusion
	description = This technology represents the first steps into fusion power using large reactors compressing a plasma with large magnets or initiatiating the reaction with tiny quantities of Antimatter.
	anyParent = False
	hideIfEmpty = False
	parents = node6_nuclearPropulsion,node7_metaMaterials
	PARTS
	{
		name = FNFissionFusionCatReactor
		name = FusionReactor250
		name = FusionReactor375
		name = KSPIMagneticNozzle1
		name = KSPIMagneticNozzle2
		name = KSPIMagneticNozzle3
	}
    }
    NODE
    {
	name = newnode_71440
	techID = interstellarTechFusionPower2
	pos = -321,1063.667,-17
	icon = NUCLEARPROPULSION
	cost = 3000
	title = Advanced Fusion Power
	description = The development of Inertial Confinement fusion technology allows the miniaturisation of fusion power as well as the production of massive new engines that really unlock rapid transit throughout the solar system.
	anyParent = False
	hideIfEmpty = False
	parents = newnode_7144
	PARTS
	{
		name = FusionReactor0625
		name = FusionReactor125
		name = vista
	}
    }

.....


}

You can see the results of this here when I make two tech trees - KSPITree and KSPITree2.

I'm still working on the code and it isn't finished yet but the idea is to save the results of this choice into the savegame folder so that the user can have different tech tree choices for different save games.

The result is that individual modders can distribute a set of tech nodes required to play their own mods or larger projects aiming to unite tech nodes can distribute packages allowing players to play with the tech nodes from multiple mods at the same time.

Edited October 28, 2014 by Fractal_UK

[Fractal_UK]

Here is the current state of the source code for this: https://github.com/FractalUK/TechManager/tree/master/TechManager

[anonish]

Now that I read up on GameDabase and actually follow how configs are loaded from various mods and made available to TM, I like it a lot. Every mod gets to define their own tree, no stomping. The community tree can then be its own mod.

In addition to the 'id' field of TECHNOLOGY_TREE_DEFINITION, we could also add 'format'. That way TM could import and parse various tree formats. Like, maybe the ATC format. Although it might make more sense to convert ATC trees into the TM style tree, at least if TM gets extended to support arbitrary anchor points (an exclusive feature of ATC atm).

Edited October 29, 2014 by anonish

[Joshwoo70]

run by a crazy person that hates all mods.

K3 chris. Wby you said that?

[RoverDude]

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?

Edited October 29, 2014 by RoverDude

[Joshwoo70]

So how do we support multiple trees at once? Or can we?

We can support multiple tree IINR (if I am not wrong. )

you will need to define it.

[anonish]

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?

I see the community tree being a separate mod. One that has a base tree defined under the TECHNOLOGY_TREE_DEFINITION header that also comes with appropriate MM configs to figure out how to modify itself before TM gets ahold of it. Then its simply chosen from a list of tree's using Fractal_UK's recent addition. The user gets to choose between various static trees that come from the mods individually, or a community tree that tries to do some intelligent merging.

[Joshwoo70]

I see the community tree being a separate mod. One that has a base tree defined under the TECHNOLOGY_TREE_DEFINITION header that also comes with appropriate MM configs to figure out how to modify itself before TM gets ahold of it. Then its simply chosen from a list of tree's using Fractal_UK's recent addition. The user gets to choose between various static trees that come from the mods individually, or a community tree that tries to do some intelligent merging.

so this tree is basicaly adds all the mods and rearranges it nicely.

[RoverDude]

I see the community tree being a separate mod. One that has a base tree defined under the TECHNOLOGY_TREE_DEFINITION header that also comes with appropriate MM configs to figure out how to modify itself before TM gets ahold of it. Then its simply chosen from a list of tree's using Fractal_UK's recent addition. The user gets to choose between various static trees that come from the mods individually, or a community tree that tries to do some intelligent merging.

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

Edited October 29, 2014 by RoverDude