NathanKell

Welcome to the forums! I think you're talking about making a custom *part* with RCS transforms? And I think you'd get the best answer in the Modeling and Texturing subforum, so off we go. Meanwhile you can check and see if there's anything relevant to you in this sticky.

ATM loads and compresses textures each time it runs. So does KSP. The advantage here is doing that step ahead of time, so the texture can simply be loaded into memory directly, already compressed. What ATM does cache is when it *rescales* a texture. But it caches them uncompressed, so it has to compress on load whether or not it has cached a rescaled texture. And yes, it's fine to use ATM too, although ATM only touches textures in GameData which aren't DDS, and this converts them all to DDS, so...ATM won't be doing much of anything.

It is now, yes. regex ported the Alternis Kerbol light shifting code. You can add sunlightIntensity = $SOMETHING to RealSolarSystemSettings.cfg, and also scaledSunlightIntensity and IVASunIntensity (as well as various other keys, see each if() test here and below for supported keys, like setting shadow intensity, color, etc.).

Yes, it will be moot. RealHeat will have the actual physical laws, and shield performance will be balanced vs stated reentry angle and velocity, shield max temperature, and total ablative mass before and after reentry (and a decent guess at emissivity). As for DRE, I'll throw in a my two cents. I think for "normal" the max temperatures of most unshielded items should be much lower, on the 600C range (where nylon melts). Then, shields should be about as good as they are currently in DRE, and no exponent or multiplier added. I would also suggest perhaps setting density exponent to 0.5 and reducing the heat transfer multiplier, if you want heating to occur higher in the atmosphere (I think it should). In sum, I think, in "normal" mode, it should be very hard to impossible for one to reenter without heat shielding, and quite easy with it. Otherwise, from a gameplay perspective, we're not taking advantage of the new mechanic (the necessity for shielding, and how shielded payloads should be heavier/costlier than unshielded ones). In easy mode, you probably should be able to deorbit most things safely from low orbit on Kerbin, but you would need shielding for interplanetary reentries. No G limits either for parts or crew (or maybe only past like 20Gs). In hard mode, you should have to work to survive even when shielded: narrow reentry corridors, low G limits, just enough ablative to survive.

Realistic for what, though? Applying real laws to Kerbin's known characteristics? Or making reentry as difficult as in real life? Those are diametrically opposed things. That's why realism doesn't factor into this; those two are known (observe physical laws, or scale velocity up and *then* observe physical laws), and thus Starwaster doesn't have to ask about them.

Please do not change folder names That will break mods, and just leads to more posting here. :] Just make a second "dev" install, and remove any unneeded-for-testing mods from that install.

There is nothing that can be done by you or I to fix x64; that's why Squad warned you it was unstable before you could download it, let alone before you could run it.

It's due to how KSP positions items; apparently it gives them a *giant* kick from the world origin to the launch position, so you briefly see incredible G forces and high speed before it's all canceled.

I seem to have fixed the red/white city textures by converting them to DDS (and using Sarbian's DDS loader). That PR was emrged.

Good thing RemoteTech supports groundstations then. You can *definitely* add the DSN to it. The one issue is that IRL you never really lose communication due to distance, just bitrate. Suggestion: if you want orbit to be not just a hop-skip away, try 6.4x Kerbin. You can still use stock parts (and with stock parts, it takes nearly as much rocket to get a payload to orbit as RSS does with Realism Overhaul).

Please start a new thread in the Support (modded installs) forum, and follow the instructions in the How To Get Support sticky. Support for modded KSP now goes to that forum, under those rules.

If you're shooting straight up, you're going to have one awful whallop of G force coming straight down. Even for suborbital flights, you need to be going sideways *much* more than up; your suborbital arc should be at least 3x as wide as it is tall. Do *not* expect to launch straight up and survive the return. I *love* the X-800 mini as the XLR11! Perfect!

camlost, that's really weird. ThorBeorn, I take it you're not on High terrain detail? Also I don't seem to get it with parachute-landing capsules...

Yes, there's an interaction issue between a proc part and a tweakscaled part. Problem is both change their shape and then move the other part to the new attach node position...but since *both* of them change, the moves conflict.

Get the latest RSS release from the RSS thread, and replace the dll in Better Atmospheres with the new one.

Then I really don't know. That's weird. It's what people on Macs get when they try to use 8192 textures, and it's what I got trying RVE on my 2GB card before I reduced the city textures, so I figured that's what it is. Check in your output_log.txt and see if there's references to d3d failing to create a given texture. pingopete: pull request sent!

Yeah, KSP lurves its hard-coded numbers, sadly.

For a guy who notionally dislikes functional programming, I actually like Excel a good deal, though a Python script would be more flexible (albeit it would need a crapton of work to get results in a GUI for configuring-and-seeing-results). That said, the spreedsheet is heavy enough to crash Google Docs; I'm not surprised it's causing trouble. Regarding cost: as of the current spreadsheet, cost/liter is the cost in $USD1965 per liter of that resource (though per discussion in the RF thread, EC should be 0.5/liter and SolidFuel should be 17.8 ($10/kg). When exported, however, they are multiplied by 0.001, so that one fund (root) = $1000USD. These costs have very little in common with KSP resource costs. Kerosene and LOX are 195,000x and 4,000x cheaper respectively than LF and Ox, for example (or 39,000x and 800x, if you take into account that resource quantities increase by 5x going from KSP to RF liters-only measurements). As for engines, the cost column is the old formula I used for Mission Controller Extended's auto-costing algorithm. It's basically (IspSL * 0.2 + IspV*0.8 - 200)^2 * thrust_in_MN*(1+gimbal*0.2). NTR get a 4x multiplier. Finally, an efficiency multiplier is assessed, by considering how effective it is per ton, with cost increased for low-mass engines. Scale it however you like, but it should cost things according to performance given, more or less. Scale it by some constant factor to make it adhere to KSP's general engine costs, if you like.

Great to see this alive again

Yargnit: white/red textures are symptomatic of being out of *video* memory (vs. system memory). That, not even 64bit can fix, alas.

They're all real, albeit rounded, with the exception of g0, which is usually 9.81 but sometimes (in ModuleEngines/ModuleEnginesFX/ModuleRCS) it's 9.82.

Linux should work fine with highres; only OSX disallows 8192 textures.

Sorry, we really do need the detailed info the guidelines ask for (all mods with their versions, and a log file from after experiencing the problem--the guide will tell you where to find it). We don't have enough info right now...

EricSan: Welcome to the forums! 1. RL-10 is not a pressure-fed engine; only pressure-fed engines require ServiceModule-type (highly pressurized) tanks. 2. That sounds like the built-in antenna for the part is set to use too little ElectricCharge. Phredward, I'm thinking you meant to post that on the Proc Parts thread.

launchpad_liftoff: yes. I have no idea why it wouldn't; it doesn't add wings... SSR Kermit: I don't know of a name for that, but that is what Skylon plans to do, and it was how the F-104 got up to speed most quickly and efficiently, so there's precedent.