NathanKell

Hey, cool! Bothersome, have you tried ModuleManager? It's a must-have for doing what you're doing. You can just write, in one big CFG: @PART[partname] { @TechRequired = newTechToBeRequired @entryCost = newEntryCost } for each part. Where partname is the second half of the "name = " line in the part cfg. Regarding planes. I've actually found planes--well-designed planes, that is--to be quite easy to fly with FAR. Far (heh) easier than stock! And if it actually looks like a plane, and you keep CoM at or slightly ahead of CoL, then it probably is well designed. But ideally I'd have the Firespitter parts be the first plane parts, and only MUCH later do you get access to spaceplane parts. Regarding experimentation early. I said early I was going to work on a clone of the RemoteTech SPU that let you do science but not control your rocket. It works. This means you can build rockets with no probe core, only a "science core" that lets you stage, perform action groups, and right-click to do and transmit science. This effectively simulates the early, uncontrollable satellites (and, indeed, early--and later--uncontrollabe spin-stabilized upper stages).

1. Yeah. It's just there's something weird in having an iceball 1,350,877km or so away from Earthbin. And I was totally planning on changing the orbital parameters (SMA, ecc, inclination, etc) to be real-life, since that's the easiest way to pull appropriate orbits vs. sizes, rather than a fixed scale-factor, and I figured might as well replicate arrangement of bodies too, where possible. (Good thing Canaveral is at the latitude it is, considering the moon's inclination...) Is there some fixed scaling factor you'd suggest, for planets and/or orbits? 2. Yup, that's what I was planning. Just wondering at the interaction.

Yeah, so I was a _bit_ snippy. Sorry. It's just that was about the sixth time it's been brought up, over the last three-odd pages (sometimes only three posts apart!) in this and the other MJ thread. You happened to be the camel-back-breaking-straw.

ferram, that's exactly what I'm working on now, spurred by asmi. All those parameters look easily changeable (though I'm unclear on the interaction between rotational period and angular velocity, i.e. which informs the other). And presumably we can borrow hyperedit's orbit-changing code to change the orbits of planets. I'm thinking moving Minmus to Duna, so there's a Phobos and Deimos both? Dunno what to do about Dres though. Given what was said when Kragrathea was talking about it, she ran into memory problems adding more planets because the quadtrees are such hogs. I wonder if we could instance them? I'd rather have six moons that all look like the same rocky ball (but different sizes) than only one, any day.

Make sure in KSP\GameData you have both ModuleManager.dll and a folder called ModularFuelTanks. Is either missing?

Join up? Heck, I'm already playing with CelestialBody, figuring out if I can get the orbital parameters to work. Thanks so much for pointing the way and, most importantly, kicking me out of "nahimpossible"! The best part is the balancing gears don't need any turning--this thread is already about balancing for reality and then dividing Isp by 3 (which scales _very_ closely for both Earth->orbit, and Earth->other planets/moons, to KSP values.). So we can just do without KIDS and all the work of this thread so far needn't be changed.

That looks amazing, and well worth playing with. The main issue with dV scaling, after all, apart from planes, is time to orbit/thrust. What CelestialBody params are you playing with? I can guess most, but the question for me is after the rescale how to get a 100km atmo. ....and good gracious, you must be going fast on the surface! 6h period for a planet that big! EDIT: Gotta say, never eaten tastier crow. :}

Apologies! My reply was flip and I got just what I deserved. :] I had read (and based on how the numbers fluctuate, thought I saw confirmation) that orbits were floats. So I muffed it, then. (Are you sure about off-rails as well? The references I had was to PhysX using floats internally, though velocity when queried is returned as a double) I have not tried rescaling planets, no. And since it is indeed technically possible to add new planets, presumably with different orbital and physical parameters, I see no reason to believe it is impossible per se, although I am not sure whether KSC would relocate properly. It's the latter--the breaking other things--I'm more worried about. But you've got me fair and square. I haven't tried it. And as I said, I'd love it if it happened, but for now I was going for the low-hanging fruit. :\ EDIT: This was the Best Ninja Ever. Kudos to you, asmi. That's right awesome.

You know what would be more awesome still? If people read more than the last page of the thread, where (a) this has already been discussed and ( it's been pointed out that MJ already has this functionality. You can blacklist modules from the CFG, and they won't be available to the part.

I can add max, sure.

Does anything come up when you click on a tank in Action Edit mode?

Nope, because float errors. Orbits are bad enough as it is, even after ScaledSpace. If KSP switches to 64-bit and gets double-precision floats for free, and if we get a way to change all those attributes without breaking other things...then yeah, I'd prefer to do that too. But this at least we _can_ do, right now.

Correct, there isn't one. I was saying 1/160 would be _justified_ in that case, whereas in general use 1/200 is the proper value. If people really are using non-cylindrical tanks with only one fuel in them (not RCS or Xenon, btw, that's handled separately), then I could do some sort of special handling. But I figure 1/200 works well enough. Also, recall that as of MFSC, engines have realistic Isp, so non-hydrolox engines will be lucky to hit 350 vac, and nukes (eventually) will have their real 850-950s Isp. I've done tests and hydrolox beats the pants off kerolox for upper stages where TWR matters less (heck, it even wins at equal TWR for lower stages!), and nukes are even better, even with their low TWR.

This post in the FASA thread has lots of Atlas reference pics.

Aw, that's sad. That's what's so cool about the Atlas, that it's stage-and-a-half! Won't be a real Atlas otherwise. Do you need reference pictures of it after staging? Or is it just too much work?

I trust 6 is actually 6 and 7, for Atlas core+sustainer, and boosters+boattail, right? Since the latter decouples about a minute and a half into flight... Liking the LM!

Um no. Like I said in my post, since we have to divide by 3, Mach 5 _is_ 500m/s in "real" mode. The point is that while Mach 5 on Earth is 1500m/s or so, that' still only 16% of the dV needed to orbit. So spaceplanes in KSP should also be limited, in their airbreathing mode, to 16% of 3100m/s, or 500m/s. Again, unless they're scramjets, in which case they can top out where KSP planes normally do (1/2 to 2/3 orbital dV)

As numerous people have said in just about _every thread you've posted that in_. .22 DID NOT BREAK PLUGINS. Unless you've tried it and CONFIRMED it doesn't work, please don't spam with that question.

That's not how trees work. Trees control WHERE the nodes are. The part.cfg files control WHICH nodes unlock which parts. These custom trees just happen to do two things. First, they move some nodes around. Second, they override the values in (some) part.cfgs as to which node is required for that part.

Yes. While the second I don't yet know enough Rocket Science to adequately account for. Ideally, you'd just feed MFS the actual engine stats (area ratio, ox:fuel ratio, combustion mode, etc). So for now I am adding to the spreadsheet an ability to modify Isp per engine, with a consequent change in TWR. But you wouldn't do that in game, though, only beforehand.

Oh, you mean the original volume unit = 1/160th m^3 thing, whereas I'm using 1/200? I went with 1/200 because the only tanks we have to go with are not actually tanks, they're tanks + outer structure. So it makes sense there's wastage. (Coincidentally and usefully, it means that you get the same energy density going from LF/OX at stock density to RP-1/LOX with 1 unit volume = 1/200 m^3). So tanks that have only 1 subtank, and that are shaped in a tanklike manner (toriod, Stratus, Cylindrified stratus) could have 1/160th their volume in m^3 as KSP volume, but the cylindrical tanks where it's assumed there's two internal capsule-shaped tanks? 1/200.

Ah. Don't the part names have weird characters in them, like periods or something?

An animated heatshield dropping down would be pretty awesome, too, one that crumples on impact to absorb landing force.

Right, sorry, I guess I wasn't clear about that when I copied the convo over? From http://spacecraft.ssl.umd.edu/academics/483F09/483F09L13.mass_est/483F09L13.MER.pdf I find: Where V = volume (in m^3) of fuel LH2 tanks: 9.09kg * V All other tanks: 12.16kg * V However, the data for LOX seems to fit the linear regression less well. Further, there's additional mass for cryo insulation: LH2 is 2.88kg * tank surface area; LOX is 1.123kg * tank surface area. We can estimate that the tanks are capsules, of approx the same radius as sidelength (works for most normal stages). Volume is 7/3 * pi * r^3, whereas area is 6 * pi * r^2. So we can say that insulation should not be proportional to volume, but to the 2/3 root of volume. I can add precise calculation of that to MFS, of course... (You might want to read the whole pdf; it's quite helpful for us. Also details estimates on fairing mass.) EDIT: Since we're talking about the whole stage, we can use the fairing estimate. Stage height we can guess as two capsule tanks. We will consider only the walls of the tank, since presumably the engine and the nose fairing or decoupler will account for the two ends. So 2 * pi * r * h. All that * 4.95, then raised to the 1.15 power.

And I've just written a module for RemoteTech that will allow for an uncontrollable but science-returning satellite, just like Explorer 1. So I'm all gung-ho for you making it.