NathanKell

Razorcane: by setting multiple resources? But I thought the class only internally supported one resource! Weird.

Spooks: I'll check.

A question. Much as I love the BPC etc., any chance you could make an Apollo-style tower for Big Gemini? Only the slightest nose cone.

DRE does have issues with .23. Fix imminent, by the uber-helpful taniwha (since I was busy with Stretchy, he stepped up and fixed DRE).

Spooks: struds? Sorry, no idea what you mean by all that. MAKC: Weird. I don't see anything bad in the log, on first glance. Any more info?

FlowerChild: That probe looks like it would have a Cd of approx 0.01 or so, which is 1/20th what stock KSP assumes. That's on the order of a normal rocket's Cd (~0.002 or so?) so terminal velocity will be far higher. What you need to look at in FAR's panel is the Frac SL Density (the current atmospheric density) and, once you open the flight details, the current Cd (coefficient of drag) and reference area (multiply the two for a sense of how much drag you're getting). So your terminal velocity at sea level should be ~400m/s, and probably closer to mach 2-3 some km up. Note that FAR doesn't change visual effects; they don't mean "over terminal velocity", they just mean "fast." I can't argue with feel, except to say that KSP _really_ trains us wrong. Especially since KSP rockets are *denser* than real-world rockets, and should suffer less drag as a result! That said, it _does_ indeed change the feel of the game (in atmosphere at least). Thus if you want an experience like stock KSP--replete with "get clear of the soup before you pitch over", low terminal velocity, and limited aerodynamic forces (i.e. you don't flip out or disintegrate for not flying forwards)--then itt's really hard to replicate with FAR. Regarding DRE: Oh, cool! (Although it's not really my work either, just some maintenance and a few new features. ). I'm absolutely down with it, and BTSM (like the little I know of BTW) is a class act; I have no worries there. And you've already been super helpful on this thread, doing the balancing-for-stock-KSP work that I never got done myself, for example.

If the body science params isn't null, but just zeroed out, you can use RSS to change those values.

AbeS: Sounds like you have multiple engine configs. Make sure the newest RealEngines is the only engines file you have (no RftSEngines.cfg or Engines.cfg in any folder under GameData)

IIRC, the default version of Isp adjustment for KIDS is "assume SRBs are sea-level rated". Instead you should choose the version of thrust adjustment where EVERY engine and SRB is assumed to be vacuum rated. That'll cut sea level thrust to, say, ~92% of what it was. But it sounds more like just an issue where stock KSP solids have pretty ridiculous burn times for their thrust, if used as cores rather than boosters. Remember they're SRBs, not SRMs. Especially since you're using them for starting probes, you might want to make (or grab from MFS) 0.5x rescales of the two solids, for use with probes. Also, you should definitely use HoneyFox's thrustCurve plugin (available from source or from the Space Shuttle SRB Replica thread); that lets you set a curve (like atmosphereCurve or velocityCurve) that takes burntime and outputs thrust multiplier. Actually, you've been mistrained by KSP's [lack of an] aerodynamics model. In FAR terminal velocity is completely respected; it's just that the TV of an object is, well, real--unlike stock KSP. In stock KSP (1) the atmosphere is assumed to be pea-soup thickness all the way up to 10km or so and (2) all vessels are assumed to have the same coefficient of drag and the same ballistic coefficient (that of, basically, the blunt end of a capsule), whereas in FAR the terminal velocity of a pod at sea level is ~100m/s or less, whereas that of a nice pointy rocket is >400m/s (both as in real life), and density (and with it, drag), decreases appropriately with altitude. That, of course, I can't argue with. It's amazing what going from "doesn't have an aerodynamics model" to "has a very realistic one" does... Now that I've said all that, I actually really like your proposal, if you're indeed willing to take that on I think it makes the most sense by far (heh). The one thing I'd ask is that you keep "stock-DRE" available as a standalone rather than it being integrated into BTSM, so people who don't want to use full BTSM (although...why? ) and don't want to use FAR (again...why?) have an option. Although, since DRE is share-alike I don't think the license you have for BTSM would allow that anyway. Uh, but wait a day or two before forking? There's some stuff I have to commit tomorrow that taniwha (uber-generous soul that he is) fixed for me while I was working on Stretchy, that I have locally but haven't posted yet.

I create a ModuleGenerator that's alwaysEnabled, give it a single OUTPUT_RESOURCE, ElectricCharge, with a negative rate.

Yes. That's true of Jool, for example. Great stuff btw!

Ooh, TACLS generators respect full containers? The stuff Starwaster was talking about was exactly the process I went through making Real Gemini (I even had the generator code commented out in the CFGs for a while ) and eventually decided it wasn't worth the hassle, and I didn't have time to write my own generator handler. But if TACLS generator code can do that, woohoo.

Make sure (1) the range of Mission Control is sufficiently large (check the Remotetech2_settings.cfg file for MC's range in meters) and (2) the dish is targeting KSC (right click on dish, choose target, choose Mission Control).

GoldForest: at the top of the very page you posted on: http://forum.kerbalspaceprogram.com/threads/24867-22-FASA-3-12-Fairings-and-Rescue-G%21-Dec-10th?p=842442&viewfull=1#post842442 frizzank: looking VERY good! MOL was to launch with Titan IIIM: A stretched-core Titan III with two 7-segment SRMs. Note however that, going by how you made the UA1205 look (6 full segments, rather than a half, then 5, then a half) I suggest making it 8 full segments. Here's IIM: Here's IIIC for reference: And here's the whole family

Heh. Eh, they vary so much! Hard to keep track of them all, let alone balance. I mean, the Apollo Command Module only had ~4kWh of batteries. But with the SM detached, the current draw was doubtless far less than 2kW. I would recommend a base capacity of ~24,000 and then about 12h of charge (EC/sec used, total, * 43200). Avionics for the smaller pods should be substantially less, like maybe only 0.1EC/s for the 1-person pods. This should yield about a day's endurance for 1-person pods, and somewhere around 14 hours for the 3-person. Those are because I added decouplers to them.

Ok. Cool. I'll release v5.4 then. EDIT: Posted. v5.4 \/ *Solar panels finally fixed (really!) thanks to StarWaster. *Fixed atmo editor keychange

All your questions excepting Saturn I or V (of which there are already models, though not to frizzank's standards) have been answered in the last page or two.

Install issue? Make sure you install it exactly where you're supposed to, and don't rename the folder or remove parts.

jrandom: I meant in terms of it using LH2 and LOx, so no need to add more resources. Frankly, I'm not sure _anything_ uses GH2 (except boiloff-driven thrusters, but better to treat it as LH2 IMO, and futz with the Isp). Regarding electricity. The issue is that your pods will last ~3 hours for the Mk1-2, and less than that for the Mk1. That's kinda frightening. Especially since even the 2.5m battery is only like 64,000 charge, which is only another 8 or so hours for the Mk1-2. Regarding FAR: Yes, it's in, but it's 0.1 in your zip, not 0.01 Re: masses etc. Welcome to the world of modding I have to do more research into fairing mass, but as a geusstimate...well, just use the same mass for your new rings I did for mine? Or maybe 90% mine? (Since they're lower-profile).

jrandom: very cool! Check out the fuel cell in the Gemini service module in FASA.cfg You can add the output resource Water in addition to electricity (in the proper mass ratio, considering the kg/sec of LH2 and LOx being used). Regarding pod electricity: note that the ~4kWh figure for Apollo is because it had massive fuel cells. Mercury, for example, had 13.5kWh (48600EC) in batteries. So (while I'm sorry to say this) you might be better served hand-rolling the battery capacity for each pod. MM really needs a "is this value < this" check, then you could detect unchanged pods. Second, that 2kW figure I quoted is for Apollo with all its guidance and comms; Soyuz makes do on less than 1.3kW from solar panels, and Mercury used only a bit over 500W. Also, in FAR, incompressibleRearAttachDrag should be 0.01 Finally, regarding the pFairing rings. Are you using my modified masses? I use less than cubic scaling, and a smaller original mass anyway, since the masses don't seem to follow real fairing/base/interstage masses that well.

Yep, tab-opolis here too. Starwaster: The only change I see in that source file you posted is the reversion of the typos you yourself found (I should be changing node, not pNode). Did you mean to change anything in the source?

Ah. Right. And same for the other new parts.

NBen: I download DRE v4. I start a new career. 1.25m heatshield shows up, and there's no duplication (There is a similar-looking 0.625m heatshield in the parts list, however). All I can say is, if you have duplicate shields, you have an install issue; and if it's not unlocking for you, you've been hit by the KSP issue where adding mod parts to an install, and resuming a career that has already unlocked the node they're in, can sometimes lead to issues even if you go back and unlock the part. That's a KSP thing, don't think I can do anything about it on my end...

Goozeman--thanks so much! When I get some time after .23, in combination with hooking this into FAR's atmospheric density system (and using code Ferram is helpfully giving me for determining shockwave temperature in non-Earth atmospheres) I'll try to implement that model for ablation. Also, a PSA. As part of that effort (and necessary for it) I plan to make DRE require FAR. It will make my coding life much easier, and also means fewer environments for me to try to balance for and support. Speak now if you Have Issues with this plan. (FlowerChild, I know right now you don't support FAR, but you were looking into it with KIDS. How much of an issue would it be for you if DRE required FAR?)

#1 I still don't see why it fails. I'll work on it. #2 is very cool, but not something I have time to tackle right now. It would be VERY nice though, I'm annoyed at how long it takes too.