NathanKell

RangeModelType = Additive Yes, multiple antenna support will not work on the Standard range model.

OK. It really does sound like they do a second pass and compress based on the texture's usage after all...wait, unless mbm has something in the header to say how to compress it? ...heh, yup, looks like they might. Offset C, the non-compressed mbm has a 01 instead of an 00. My guess is if you flip that to 0 in a non-compressed MBM KSP will compress it on next load. EDIT: Spot-checked a few more, and that's indeed what it looks like. And since Unity does the export to mbm (right?) then the "compress / don't compress" checkbox there will presumably set that byte. EDIT 2: Are your tgas compressed or uncompressed? Try and see if it DXTizes a compressed TGA, if you were only feedng it uncompressed TGAs. Note that TGA compression itself is lossless, but KSP may be smart enough to notice it's LZW-compressed and decide to convert to DXT.

Wait, a partmaker who is willing to do her/his own RF conversion!? Amazing! :]

That's _really_ weird. So it's not that there's a leak in TGA loading, it's that they're never compressed! I wonder what makes a texture imported as RGBA32 rather than DXT5, since it looks like some mbms in gamedata are pulled in as one, some as the other. Unless they make a second pass after all models are loaded and _then_ do the compression, once they know what things are used for? Hmm. Are all those mbms, or are you running any texture reduction packs that replace the mbms?

Cilph let me add my range model. Open remotetech settings.cfg and change the range model line from stock/standard/whatever to Additive. Also set the NK Multiple Antenna Support to true. You get: Multiple antenna support: each additional omni antenna beyond the longest-ranged adds 25% of its range to the satellite's max omni range. New range model. For any connection style (omni-omni, omni-dish, or dish-dish) between two nodes a and b, let node a be the one with the shorter max range. Then the maximum connection distance between a and b is range_a + sqrt(range_a * range_. If an omni is involved, the distance is clamped to 100x the weaker link; if both are dishes, then the distance is clamped to 1000x the weaker link. This tries to simulate max gain, transmit power, etc., while still being game-y and simple. This means, for example, that with a 500km omni and a 50,000km Mission Control, you get a maximum range of 5,500km, enough for medium earth orbit. For stock KSP, that means with the largest dish at home you only need a small dish to go to Duna. Etc. Cilph, it'd be real nice if you could add this info to the OP.

Dante80: try with RF, just in case. Also, try this. Place a tank. Go to action groups, click on it, check the Tank Volume it says at the top of the new gui. Go back to part mode, rescale it. Go back to actions, check tank volume again. Has it changed?

rbray: I'm wondering if maybe the uncompressed ones are ones in KSP_Data? IIRC everything in GameData is loaded as DXT1 or 5. Since the loader has no way of knowing what a texture is going to be used for, I doubt it would handle normal maps any differently than anything else; whereas all the textures in KSP_Data, well, Squad knows exactly what they'll be used for so they may be loaded "by hand" as it were rather than automatically. Well, it might be worth checking if memory usage really does go down with mbm instead of tga--I know for KW they found it did quite a bit, but reports sometimes conflict. I wouldn't recommend PNG, as you're using huge textures for planets that will end up taking up only a dozen pixels by a dozen pixels, at times (far away/zoomed out in map view), which means the texel:pixel ratio is going to be mad high and you'll definitely want mipmaps.

KSP/Unity does the following: For each file in GameData, if it's recognized as an image: (a) generate mipmaps* ( if it has no alpha channel, compress as DXT1 and unload the original+ © if it has an alpha channel, compress as DXT5 and unload the original+ *PNG loading has a bug where no mipmaps are generated +TGA loading has a slight leak, so apparently not everything used in conversion gets unloaded (compared to MBM).

Ah, that's even better! I was thinking you can just strip the alpha from the file, and then KSP will load the file as DXT1 rather than 5, thus halving storage space, but if you do it ingame, that's cool too.

I've done it in 3100dV expended. If you're just going off vacuum dV, and/or you don't fly insanely optimized trajetories, assume nominal vac dV to orbit of 3500. Unless your rocket is unaerodynamic, of course.

Please post in the current thread. Link is in the post directly above yours. Yes, just set loss_rate to 0 for each loss_rate line in RealTankTypes.cfg

Hmm, in that case just delete the ModuleEngineConfigs from the SRB part cfgs. That should make things work, I think.

Hey, I'm back with yet another texture optimization suggestion. :] Why not use the RGB channels of the cloud opacity textures for the opacity, rather than alpha? As far as I can see you're not really using the color channels of the main cloud textures--I mean, the shader supports it, but they're always white in practice, colored by the cfg. Then you don't need an alpha channel, and your memory usage per texture is cut in half. Further, it lets you use 16 bits of alpha rather than 8. (You'd think 24, but DXT1 compresses it to 5:6:5 bits RGB).

Heh, it's near a full quarter of Mercury, tanks dry. Which means the Mk1 pod with a chute and some RCS is also spot on. (Not counting the retro module, obviously, since that isn't shielded). Maybe you're thinking Gemini? Looks like it's (ablative) shielding was only about 7.5%, but it's not clear how much of the structural mass should be counted as part of the shielding too (going by http://www.braeunig.us/space/specs/gemini.htm which also has nice breakdowns for Mercury and Apollo, and less detailed but still excellent ones for about everything else).

Nah, I mean 90% of the engines in Nova Punch, other than the 1.25m Old Bearcat. And 100% in KW. (I knew the stand from the Ares/DIRECT/SLS studies.)

You, sir/madam, are a hero. That's going well out of your way and I thank you heartily for it! If you do that, I just realized one other super-helpful thing to do while doing it: could you also get rid of the "lower quarter of fueltank" base that these engines have? So they can be placed on a fueltank of any size. The Spinnaker is fine, but the others, it's a bit of an issue fitting them on larger or smaller tanks, as you can imagine! Also, while I can easily generate the engine stats for conventional engines, would you be interested in doing a realistic-stats version of your other parts? I get somewhere between 1.3EC/s (with EC/s as kW) to 5.3EC/s per ton for RTGs, depending on tech level. (I made the AIES one a SNAP-19 and the stock one the Voyager MHW-RTG). But I'm totally out of my depth with electric propulsion. If you can find realistic masses and kW usage for your engines, that'd be wonderful. (I'm putting together a realism tweaks thread).

Pressure. KSP just calculates density as a linear function of pressure. So even if you check atmosphere density, you just get a multiple of pressure. Ferram is about to add support for different-composition atmospheres, though, so we may not have to worry about density on this end, other than specifying per-body atmo compositions. SSTScale is for scaling the models that show up in map view or when in orbit (the scaled space mesh; we're scaling the scaled space transform). Because I haven't regenerated them yet (although ZRM kindly told me about an easier way than I was planning) they don't match perfectly, so sometimes you have to scale them a bit differently than just (newRadius/oldRadius).

If you're going to be that rude, the least you could do is post a source.

Thank goodness, another engine without the whole bottom quarter of the tank attached to its top! They look _very_ nice, Tiberion!

Here's what I ended up using, based on some googling: it tries to get the fallloff approximately right by messing with the exponent too. Just a holdover until we get a pressureCurve. atmosphereScaleHeight = 30 maxAtmosphereAltitude = 245000 atmosphereMultiplier = 1.5 staticPressureASL = 2 Note that max Atmosphere altitude is just for show; what actually cuts the atmosphere off is when (staticPressureASL * e) ^ (-alt_in_km / atmosphereScaleHeight) < 0.000001 Regarding orbital params: asmi pointed out I can just borrow the ones Orbiter uses for J2000 for the moons. So that'll be in the next release too. Your config looks cool! I'm very leery of depending on PlanetFactory, though, given all its issues, but for those who have it, that's a cool config! I believe FAR does support Firespitter, although there are some issues with combined wing/control surface parts. But check the FAR thread and post there, and I'm sure the kind folks who use them both will explain.

Just use radial attachment points or cubic struts.

Yeah, that was buried in the Realism Overhaul thread in Addon Dev. It's easy to miss....

Dynamic Warp.

Right, I misread, and edited my post to that effect.

No, it's not. DO NOT throttle back. As ferram said, that's the worst thing you can do. Keep your vessel's forward-marker near the surface-prograde marker at all times (don't turn too fast). With the FAR details panel open, make sure AoA and Sideslip is no more than 5 (or less than -5) at any time. Sorry. Misread, thought you meant throttle back to 70%. Yes, follow ferram's advice.