johnsonwax

What's the issue? I mean, you're only going to unlock nodes in order to get to parts that you want. That means in order to use those parts, you need to research all of the technology that you need to make it possible. So, you don't always get a cookie.

That looks pretty much exactly what NASA would approve. It's a bit longer than they would do in the 3 segment variation, but it's also more conservative than they would do on the diameter relative to base. It'll still be too short and narrow for many players (like me) but if you're looking for realism (without being perfectly historically accurate) then I think you've really got it dialed in well.

Oh, speaking of icons - if anyone can point me to the location of the engineering 101 icon, please do. I can't find it anywhere.

He's posted many times that he does not currently have a computer capable of running KSP, and won't for a while longer yet. He can run the modeling apps, but he can't test, so development is, to say the least, challenged. I think we should be very thankful that he gets anything at all released before he's back into a proper computer again. My suggestion to anyone that is interested in seeing this updated: 1) Make a github account 2) Star the project(s) you are interested in 3) Every day that you play KSP, check for an update there and in these threads and spend half an hour or so testing some parts, making sure nodes and animations work, that you can build reasonable things, chuck them in orbit with hyperedit, make sure things work - particularly the stuff he's just changed, and then post issues in github, even if the issue is 'I checked x, y, z, all nodes are working, this worked, that worked, etc.' 4) If you find a problem, follow up on it the next time you play. Install the updated parts, test the specific problems, stick with him until it's fixed. Tell him when you think it's good enough to release. Sumghai can't even tell what's working right at the moment. He's effectively working blind.

Updated the schematic for 2.1: PDF SVG I updated it so that the required/optional paths are noted. Dashed lines indicate any tech will unlock, solid is every tech needed.

If the science was needed in order for the tech to advance, why is it a problem to pay for it even if you don't get a part in return? Wouldn't the Manhattan program still have cost us roughly the same amount even if we didn't produce bombs? Had we waited for nuclear power to apply that technology we still would have had to cover all that same territory and paid effectively all the same costs.

Ok, that's what I figured. So for a 2 booster Falcon Heavy craft, the physics cutoff shouldn't make a difference once you sort out the powered landing stuff as you'll be jettisoning those boosters more than high enough to miss the cutoff and they should be going slow enough to not burn up. When you get to 4 or 6 booster asparagus craft, that's a different matter and you may well be dropping those first stages soon enough that you won't hit 22K before the booster hits the ground. Something new to think about in the design. As for dV estimates being too high, I personally think that's fine. The reason why SpaceX powered landing is such a game changer is that you recover 95% of the cost of the stage, and so instead of building minimally-viable stages to cut down on the amount of cash you are literally going to dump into the ocean, you build maximally-viable stages that are larger, stronger, safer, and likely overpowered and overfueled, because your only real cost is the fuel you use up. It's a completely different way to design a launcher because you can stick anything you want in your lifter stage and so long as you can get it home in one piece, you get it all back for the next launch. So, I wouldn't worry about the dV calculation being too high so long as we can predict what it will be. If we know it's about 400dV, then we can work out the mechanics for how to drop that stage with that much dV in the tank, and the cost of fuel for that number vs 200 or what it realistically would be is effectively zero.

My guess is that BDAnimationModules.dll was just updated as BahamutoD just released his landing gear today.

This is exactly what I used to do as well. And then you can unlock your buildings much faster and then start to flip a ton of money into science late game. Might now have to write a kOS script to fly the first stage home. - - - Updated - - - The other problems is the physics cutoff, no? If the first stage remains in physics range when it hits the ground, it needs to land intact? You can't just add up the amount of dV and call it a day, correct?

Well, he's yanking out the functionality moving to KIS and making KAS work with KIS. He's updating models. He's got to get it to 1.0. I think that's quite a bit of difference.

Try doing 'ckan remove KIS'. It'll complain that it can't find it but will remove it from the registry. Then do a regular install and it should be fine.

Modders are certainly intelligent enough, but we're a week into 1.0 and the mod landscape is still pretty ragged because modders take breaks from the game, etc. Some players can't repair things, others can but then they have some manner of a fork, etc. I'm sure that 2.0 won't be the last word in the tech tree, so when 2.1 lands, how much breakage will occur? That's why I suggest pursuing something a bit more bulletproof.

Unfortunately CTT can't ensure that and still have dependencies. Most nodes have a single dependency, and therefore 'any' and 'all' are equivalent. In order for this to work as intended, MM would need to be expanded to attach some kind of part info to each tech node and provide the ability to query other nodes in a selector. Then you could hide/show based on whether there are parts up the tree or not. That said, implementing #3 is a one-line MM patch that users can implement as they wish. Doing any of the others is hardly so easy.

Given that the US parts are generally better than the stock counterparts - shielded to heat, smaller in many cases - I would request that they be suitably either more expensive or deeper in the tech tree. Otherwise, why bother with the stock ones? If users never use the stock part, that should be a problem. There should always be a case, at some point in the game, that they are a better choice - either because they haven't unlocked the more advance part, or they're smaller/lighter/cheaper/more durable, etc.

But what if you want to get to a node that does have parts you need, but you can't unlock it because a requisite node is hidden? You're completely shut down at that point - you can't get to that node at all, ever.

I like how the kerbals need to burrow to their food like gophers.

The problem with the hidden nodes is that if they are a dependency and nobody unlocks them (regardless of whether parts are installed) then you're just screwed - there's no remedy. So, my vote would be to make the terminating nodes hidden, but leave all dependency nodes visible simply to address this problem. I don't see the problem with having to unlock empty nodes - it's just intermediate R&D needed before something can be viable - the capacitance multitouch screen pretty much only existed in R&D form until it was combined with a bunch of other technology to make the modern smartphone viable. Happens all the time. Now, the right solution might be #4: changes to MM that can parse the parts list after first pass, and attach a parts list to each node and put that in the techtree cache. That way you could have (admittedly often huge and convoluted) selectors that could check for parts in a given node, as well as any subsequent nodes in the tree, and then hide or unhide as appropriate. And if it's written to cache, devs could dump that file and see where all of their parts land in the tree along with stock and others to help balance things out. With this approach devs would only need to attach a part to the node they want it in, and the CTT MM file would do all the rest. It would also handle the case where CTT is inserting nodes ahead of stock.

Here's a draft of the flowchart. Rather than use descriptors it uses the node name, so if you are trying to put a part in a given node you can trace the dependencies back and see exactly which node names you need to unlock. If you have access to a printer that can print tabloid, it will be legible (tiny!) and you can scribble all over it. SVG Version PDF Version I didn't incorporate the comments above (mine or others) - it's based on the currently released version. I took some liberties with the various branches and expanded them into what I felt were logical stock nodes, along with a bit of guidance as to what I thought went in each branch. Please: Point out any structural errors. Provide feedback on the branches and the notes. Any other feedback.

I think simpleCommandModules should default to hideEmpty = False because its the only part of the tree that is a prerequisite to a stock node, and therefore it should always be visible, even if empty. Also, this is a bug: // Unhide Nanolathing @RDNode:HAS[#id[nanolathing]] { @hideEmpty = True @pos = -1118,1412,-1 } Should be @hideEmpty = False

Your price for advSolarTech is off a bit. Should be 550 instead of 500. I'm working on a flowchart that uses the node ids to make it easier to figure out what modders need to turn on and off. Should have it done by tomorrow. It's based off the actual tech tree and not the gliffy doc. I think it's all correct. I'll be putting some MM files together to rearrange parts into the new tree. I cannot stand that I need to go 6 nodes deep into the tree in order to get a ladder that will let me get back into a plane. I've been to Minmus 4 times, and I still don't have that ladder.

I would suggest the following change to each of the overrides: @PART[*]:HAS[@MODULE[ModuleCommand],[COLOR="#FF0000"]!RESOURCE[Supplies],[/COLOR]#CrewCapacity[>0]] { Add the bit in red to each of them. It'll stop it from overriding parts that already have specified supplies, which are inevitably coming.

FWIW, I've run a few missions and had no problems with the nodes. Haven't hit all of the parts, but most of them. (1.1.0.2)

No apologies needed. My suggestion for the community plug-in approach is a recognition of these things, thinking that perhaps if we could change the culture from 'person A is wholly responsible for all of these things working or not working' which is probably how snjo etc. feels, to 'these things are managed by a group of people', at the very least it would keep that kind of energy not so much directed at individuals and perhaps would help everyone feel like this isn't a job (for no pay, no less). I think it's a positive sign that Roverdude has stopped distributing MM with his mod. It's still a dependency but it's now clearly one the user is responsible for tracking down. Now if we can get CKAN working a bit more smoothly... All easy for me to say, I'm not a plug-in developer either, but just a thought. And by disaggregating the ownership from individuals, it might make it easier for Squad to pull these into the game.

Alternatively, you could partner up with one or more of the other widely distributed plugins and get them to extend to cover your needs. I have KSPAPI all over my system, for example, and firespitter as mentioned. I can see some benefits to fewer but more widely distribute plugins especially when we hit these major breakage points. So long as its under a license and hosted in github that others can pick up the project if the devs take a break, that's a pretty clean setup. We've certainly had these kinds of community comings-together in the past.

Oh, well ...., that's not going to be good for the ship currently in orbit.