NathanKell

Not for long.

QFmaximalT. Dragon01, EC is, if you go by the RTG, kW-s. If you go by the lights, much less than a kW-s. I would suggest using maybe deka-watt-second? So 1Kw = 100EC/s. Does anyone have a rough estimate on weight vs. charge for batteries over the last 50+ years? I know it's advanced by leaps and bounds, but I don't know numbers. So far this graph is all I found: http://www.batterypoweronline.com/images/PDFs_articles_whitepaper_appros/ReddyBatteryFuture.pdf

And also changing the loss rate. Otherwise it's useless. :]

Ohai. Check sig. I have the same style for Procedural Fairings too. Both will be updated Real Soon Now . ferram, nice! I'll have to try that too. Delta-IVH sounds good, but I want to make the original SLS, the Space Launching System. (And it's only 7.62m diameter, core stage!) In case anyone's wondering, that's why the high-end KWs are hydrolox in MFS, so you can do stuff like that.

Yes. And shortly I'll release an update of my patch that works better with MFS and finally only sends message to MFS, it doesn't store anything itself, as AG wished.

I wouldn't say that's true of all hardcore folks. The only mods I make are realism mods, and I love MJ. But (do as I say, not as I do, oops) let's PLEASE not turn this into another argument about MJ. This thread is not the place.

Change fuels how? Change an engine's fuel mode, or change what a tank holds? Either way, go into action editor in the VAB and select the engine or tank respectively. For insulation, use tanks that say they are Cryogenic. The Jumbo 64 is, for example. p3asant: that's actually right in line with current large solid rockets. The plan to redesign the Shuttle SRB had a dry ratio of 14.9%

pina_coladas, please repost that on the MFS thread and we'll talk about it all there. v2.1 hotfix *Went back to scaling Mun's scaledspace transform for now *Fixed Mun's inclination to avg vs. Earth's equator (since we can't tilt Kerbin's rot axis, we tilt what orbits it)

Decouple on the interstage adapter does absolutely nothing. It is there only so MechJeb and KER calculate dVs properly (and don't crash). The way that top node _actually_ decouples is when a majority of side fairings attached to the interstage adapter are decoupled (the fairings hold what's on top of the adapter).

ferram, great! Another thing you might try at least as a temporary thing is to write your own launch clamp module that keeps parts rigid until it's disengaged, as a lot of the stability problem is the first few milliseconds on the pad. I mean, in flight things dance around some, but the first few ms are killer. And LaunchClamp makes things worse rather than better at the moment, must be something weird in the joint code.

For rescaling...yeah. Batch would be good, but scaling is inconsistent. Some part makers use 1:1, some use 80%, some use 64%. And often while crewed craft are scaled down, uncrewed probes are left 1:1. I mean, heck, for Squad, the two capsules are roughly 64% (the Mk1 is more like 66%), but the probes are all over. Probably the best bet would be to write an offline script that would process a list of partnames and rescale values, and output corrected part CFGs. I mean, you could do it ingame too, I guess. On another note: Just to see if everything's working right, Dragon01, do you want to try manually rescaling and matching data for the Soyuz? I'll handle Gemini. We can then see if they perform the way they should given correct stats. Or if the MFS stuff is confusing just get the sizes and dry weights right and I'll do engine/tank configs for you. (Those are the two LV/spacecraft configs that I know are complete simulations--are their other complete models with many real-world stats available to check?

Heat is being dealt with. p3asant, that config looks fine. You can just make a new cfg anywhere in gamedata and put that in it and it should be applied...check the log for details if it's not. Oh, maybe because the partname has a space? KSP no like. Try removing the space from the part's name line in the part cfg, and from your reference to it above. MFT has support StretchySRB from day one. I need to release an updated StretchySRB with ModuleEngineConfigs in it, though; the public release of StretchySRB may not be up to date.

MAKC: part of the problem is DREC doesn't yet model detached shockwaves. So it makes everything easier by having a low enough heat mult that everything can survive. I encourage you to experiment and try to find good settings...I honestly spend so much time coding I don't have much time to play and try things out.

So the scaled space fix of Mun clearly didn't work. I'll revert to the old one. Regarding Minmus, I originally had it even farther out but was encountering issues (which turned out to be unrelated) so I'll put it back farther out. I agree about the "one perceived moon" thing. asmi: yup. I'll set up the bug tracker on github.

A question. I don't know if it behaves this way in stock KSP or only with the rescale, but: 1. Clouds, looking from below, are quite dark. Is there any way to make them nice and bright white? 2. There seems to be fresnell falloff of the shader from below--it's visible only at the edges of the sky, not right above. Other than that, me likes! This keeps getting better and better!

Ok, I have updated to v2. Included asmi's fix; disabled Mun scaledspace rescaling (see if that fixes the Mun?); only change each planet once (I think the changes stick); fixed Minmus. Yeah, that should do it.

Rather than using KIDS I'm just using a real-Earth-size Kerbin. I posted how ferram could integrate KIDS with MFS, but I think he's working on rescale-related stuff too, i.e. to fix joint wobble. And frankly, why play with KIDS when you fix the cause (planet size), not the symptom (too easy to get to orbit)?

Synthesis, I'm afraid I find myself stumped. I see nothing on that log that would indicate a failure to compile the parts. 1. Do the show up in Sandbox? 2. Have you tried running without Vet-Tech, and checking if they show up in Sandbox? Were you, like, trying to load KSP in the background or something? You're getting a lot of GfxDevice Lost log entries. That's bad for KSP, IIRC.

asmi, super! I was looking at PQSCity, but that's for the buildings, not the terrain. I'll edit and compile and release. Also, I too support the option for moving KSC to 28d or 46d lattitude (although in the latter case, you'd have to launch to 51.6 )

TAC just checks time * crew electricity use, and tries to subtract that much EC from your batteries. It causes problem *because* it doesn't simulate energy generation too, IIRC.

Oh, ferram, one other thing, regarding the jump from Q of 30 to Q of 0 when leaving the atmosphere. I tried with atmo height of 135km, but after extensive testing, it looks like CelestialBody.maxAtmosphereAltitude is just for show; static pressure seems determined only by scale height (and SL pressure), and the clamping is when the exponential calculation drops below approx 0.000001, not when altitude above sea level is > maxAtmosphereAltitude. The only way to fix it would be to increase pressure at sea level above 1 atmosphere and then decrease CelestialBody.atmosphereMultiplier, but that would throw off the exponential curve since it looks like pressure ASL is multiplied in _before_ the exponent is applied rather than after (i.e. it's (p*e)^(-alt/scale) ). Or we could switch to the new atmosphere method? That operates off a floatcurve with arbitrary altitude and pressure values and tangent support.

@ferram: ah, right--I grab the maxradius and minradius offsets from original planet radius and use them to calculate new min and max radius based off the new radius, rather than getting them as multipliers. That's so Kerbin's mountains remain the same height ASL (although probably it should get a factor of about 1.3x, going from Kerbin's highest point to Mt. Everest). I just automatically did the same for the Mun. I can switch to scaling for now to fix it. Best wishes on that plugin! You mean decrease dT below the minimum offered in settings, I presume?

Great--thanks!

Please post all pics here, in this thread. Visari: thanks for that! I don't think there's anything we can do about Kerbin textures, I'm sorry to say--you can't load larger planet textures than 8192x4096 (check the UR thread). :\ Haven't been to Mun yet--wonder why that is. I'll try going there. Not having the peninsula KSC is on (which is a model, not part of the planet terrain) and the hard-to-click on are known bugs per readme. I'm working on them... Orbital lines...yeah, there's maybe some other place where planet radius is stored for Planetarium view. The G-force thing is weird, hadn't encountered that. I'll ponder, but nothing springs to mind why that is. Re: wobble, ferram was considering making a plugin to deal with joints. I (and every other person ever, I think) rather hope he does! ...now I'm going to see if I can get a probe to the moon myself!

Ah, cool. Great that's fixed. In RT1, MC uses polar coordinates too, but the radius is hard-coded at 600094. For LoS, it uses radius properly.