Starstrider42

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.

Thanks for the link. I'll contact IGNOBIL and see if they're interested. BTW, did you mean to give the 88-88 the wrong stats? It should be max 40,000,000 km, covers KEO at 6,600,000 km, covers Kerbin at 1,100,000.

If you haven't specifically added FAR support, then it won't work. It's a pretty severe override of the stock system. I know (Atmospheric) Trajectories supports calculation of drag for both stock and FAR, and it's trying to solve the same problem as you, so that might be a good place to look at what's involved.

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!

Looks nice, and I agree with the general strategy comments you've outlined above. A few quibbles: You made a few mistakes in the stock part of the tree. The two that are likely to affect the CTT are that nanolathing now derives from composites, while meta-materials leads to experimental rocketry (along with very heavy rocketry). Can you clarify what sorts of breakthroughs go in the Heavy Construction path? That's the only one where I can't really visualize what is involved. Making ISRU a branch of Field Science was pretty clever, I wish I'd thought of that. Would it also have interconnections with surveying, or not so much? Can you spell out the children of Automation and Robotics, along with the prerequisites for Spaceplanes, Colonization, and Gigantic Rocketry? The intersecting lines make it hard to tell if we're all on the same page. That's about it. Thanks for putting this draft together so fast!

Ah, ok, I see how my original post was unclear. I was not trying to imply any implementation for steps 3 and 4, and AFAIK the implementation for steps 1 and 2 is forced by the KSP API, so you don't get a choice there. What I meant is that tree.cfg, like every other .cfg file in the game, defines ConfigNodes -- not techs, not tech tree nodes, just generic ConfigNodes whose meaning depends what your code does with them. Whenever KSP finds a .cfg file with valid syntax, it loads those ConfigNodes into GameDatabase (step 1). ModuleManager edits the ConfigNodes in GameDatabase (step 2), so MM compatibility is a matter of making sure you use the copy that's in GameDatabase instead of loading it directly from the individual file. Here's a code snippet that does that: UrlDir.UrlConfig[] configList = GameDatabase.Instance.GetConfigs("NODE"); foreach (UrlDir.UrlConfig curSet in configList) foreach (ConfigNode curNode in curSet.config.nodes) { initTechNode(curNode); } } where I'm assuming initTechNode() is your existing implementation for step 4. EDIT: Ok, so I'm assuming one thing about your implementation, which is that however you process tree.cfg involves reading ConfigNodes from the file in one form or other. Is that a good guess? My original point was that having multiple tech tree configs (say, for different mods) only affects what ends up in GameDatabase, and you most likely want to find and load all available configs anyway. The only way that mods could overwrite each other in this scenario is if you get duplicate techIDs (if I understand the framework you described correctly), and that's easy to avoid by encouraging mods (including the community tech tree) to give their NODE names and techIDs a unique prefix.

I just discovered that RSS has a Custom Asteroids config. They could have told me. Anyway, now that I know there is such a file, I suspect you may have accidentally installed it at some point. Can you check whether you have a file in your KSP install called "CustomAsteroids.cfg" that looks like this: // Real Solar System Custom Asteroids Configuration // A modified version of excellent Basic Asteroids.cfg by Starstrider42 // For Custom Asteroids 1.0+ // Compatible with Real Solar System v6.0+ @AsteroidSets:FOR[RealSolarSystem] { !DEFAULT,* { } !ASTEROIDGROUP,* { } ... Also check your Custom Asteroids/config/Basic Asteroids.cfg file. I suspect one of those two files is nonstandard.

I don't see how these implementation details change anything. Can you please clarify what point you were trying to make? I think I've missed it.

This sounds like a bug. Is there a save file you could post to Github (https://github.com/RemoteTechnologiesGroup/RemoteTech/issues)?

To quote the builder: If they want to include ModuleManager support, as they've stated, then the processing flow must change to: KSP compiles a list of all tech tree nodes to GameDatabase ModuleManager, if installed, compiles and applies a list of node patches TechManager deletes the stock tech tree TechManager reconstructs the tech tree using the configs compiled in step 1 Which would completely avoid the "wipe out" problem you're describing. (Mind you, I still support the idea of a common tech tree, but to provide players with a consistent experience rather than to avoid mass clobbering.) @Diazo, there are any number of ways to prevent trees from getting broken by missing mods. One (letting mods disable the "hidden" flag on any prerequisite nodes they need) will even work with no extra work from anonish besides ModuleManager support. A more complex approach might be to figure out which techs are prerequisites (though with OR prerequisites the correct behavior might be hard to define). In any case, I don't think it's a fundamental problem, more of a feature request.

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

Very neat. One implementation question: does the flight computer override player input (like MechJeb) or does it trigger action groups etc. separately (like Smart Parts)? I'd be very interested in RemoteTech integration, and this would effect whether the two mods are compatible or not.

I'm confused. When you say "the same", are you saying stock trim locks your controls? That hasn't been my experience.

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.

The problem of whether players have tech-extending mods installed could be easily solved on the modder's side by doing what Nertea did with Near-Future: use both a stock node and an extended node, depending on whether a custom tech tree is installed. Taking TAC-LS as a hypothetical example: PART { ... title = Life Support Container, Large techRequired = heavyRocketry @techRequired:NEEDS[CommunityTechTree] = longTermMissions ... } So I agree, we shouldn't worry about every edge case. Just make a tree that's both robust and flexible, and everything else will take care of itself.

I would think the simplest solution to this problem is to make the tree extensions fairly shallow -- say, never going more than one or two nodes away from the nearest stock node. I don't think hidden if empty was ever designed to be used on more than leaf nodes. EDIT: another possible solution is to make all extended nodes hidden if empty by default, then remind modders that they can use MM to change that flag if they feel the need.

Now that I'm officially de-Grinched... While I don't have a mod of my own to add to the list (RemoteTech makes more sense in the stock tech tree, and Custom Asteroids doesn't have a single part), I have been working on a tech tree rearrangement for my own use (https://github.com/Starstrider42/IntegratedTech/blob/master/integratedTech.png). That's given me a few ideas for what would be useful tech areas to have: A ground bases branch (possibly partially overlapping with your construction and ISRU extensions). This would include not only MKS, but also EL's survey station and mining capabilities, and possibly PorkJet's ground-based habs. Could be the same size as the stock space station branch (which I define to be Specialized Construction, Advanced MetalWorks, and Meta-Materials, but I'm sure others have their own interpretations). An orbital surveys branch -- probably just one or two nodes, and located near the middle of the tech tree rather than at the end. This would cover ScanSat, Kethane, and ORS(X). Otherwise, I think you pretty much have things covered. I guess I'd rather Life Support were mixed in with the stock crew space nodes rather than being its own branch (as I argued on the TechManager thread, these kinds of advances tend to go together), but that's a secondary issue.

Ok, I misunderstood the scope of the project. If we're sticking to relatively small extensions of the stock tech tree, then most of my comments don't apply. Objection withdrawn, and good luck.

Agreed. Maybe we'll have contracts for specific constellations at some point in the future, but for now just use Fine Print. Keostationary, keosynchronous, kolniya, and tundra orbits were basically designed for communications satellites of various sorts.

And Faark nailed it. Switching to fields works. The second function is (or was, as of 0.23.5) pretty badly broken: http://forum.kerbalspaceprogram.com/threads/7544?p=1083531&viewfull=1#post1083531.

Sorry to be the voice of pessimism again, but I don't see it happening and I don't think it should happen (with one very challenging caveat, see end of post). Looking at the proliferation of tech trees and tech tree mods, it seems most players have sharply different ideas about what a "good" tech tree would be. And I mean structural ideas, not just placement of individual parts. To take an extreme example, there was a recent mod (that I can't find now) that proposed a very stringy tech tree, where you have e.g. a liquid engine branch, an SRB branch, a solar panel branch, a battery branch, etc., and you could choose to unlock more powerful technology of each type arbitrarily. Like most tech tree mods, it used words like "realistic" and "believable" to describe itself. I, personally, wouldn't want to play on that tree, because I find it both gameplay-unfriendly (it encourages specialization, with no incentive to invest in more than a handful of branches) and blatantly unrealistic -- who would try to develop an ultra-heavy engine, for example, unless they already had a reason to launch heavy payloads? Were I to make a "realistic" tech tree of my own, it would have far more interconnections, on the grounds that no invention occurs in a vacuum -- and I'm sure I'd come under fire from people who complained about "silly" tech dependencies, and would prefer the stringy version as much more realistic. The only ways I can see to make everyone happy are: Keep to the status quo of a variety of separate trees. This would, of course, hurt mod interoperability. Create multiple "standard" tech trees, which share a common set of tech names but connect them in different ways. Players can then choose whichever tree they like, and modders would use the standardized tech names to support them all simultaneously. I'm no mathematician, however, so I can neither prove nor disprove that it is even possible to create multiple mutually consistent trees like this.

Modding all the workshops is not that hard if you have ModuleManager. Here's a (fairly masochistic) config I've been using: //-------------------------------------- // Bring EL build times in line with KCT build times // Goal: a fully staffed Workshop (productivity 10-20) is about as good as a primitive KCT pipeline (speed 1.0) // That should ensure that, while KSC construction is still faster, a dedicated spacedock can compete if the // player puts in the effort -- and not just because building in space, you don't need moar boosters @PART[*]:HAS[@MODULE[ExWorkshop]]:Final:NEEDS[Kerbal_Construction_Time] { @MODULE[ExWorkshop] { @ProductivityFactor *= 0.01 } } Just delete the ":NEEDS[Kerbal_Construction_Time]" if that's not why you want to slow things down, and change the multiplier to suit your taste.

Cool. Just to be 100% clear, does that work even for new tech nodes?

Looks very cool. Two questions: Can the tech tree be edited using ModuleManager? One big disadvantage of TreeLoader IMO was that all changes needed to be made in the tree.cfg file, which made it vulnerable to overwrites, etc. Do we need to declare parts as belonging to new tech nodes, as in TreeLoader, or can we use the stock system of just passing the tech name to the part?

Not in stock KSP, no. FAR and NEAR introduce an "isShielded" value that tells you that; see the RemoteTech code for an example.