NathanKell

Kalista: thanks! I wonder if that antenna has its physics disabled; DRE won't add heat to physicsless parts, which means they make excellent shields. It's a C32 from RT2, right? Have you changed its stats at all, or added any mods that change its stats? In the VAB, what is the C32's max temperature listed as? Taki117: check the last page or so; swamp_ig just released 2.1.3. panarchist: Actually yes! ialdabaoth has a partly-written successor to DRE that turns off the stock heating model and allows us to substitute our own, which sounds like a great springboard for you. If you want to take that on, we'd both be super-happy! (As would basically everyone else ever.)

Cool! Suggestion: divide out the rescaleFactor on all parts (or at the very least the parts that are likely to be used as root parts) since a non-1.0 rescaleFactor on a root part will break things on revert. Example (fixed cockpitMk2B) MODEL { model = Squad/Parts/Command/Mark2Cockpit/model position = 0.0, 0.0, -0.13823 scale = 1.131, 1.131, 1.0053 rotation = 8.0, 0, 0 texture = model000 , Squad/Parts/Command/Mark2Cockpit/model000 texture = model001 , Squad/Parts/Command/Mark2Cockpit/model001 texture = model002 , Squad/Parts/Command/Mark2Cockpit/model002 } MODEL { model = Squad/Parts/FuelTank/mk2SpacePlaneAdapter/model position = 0.0, 0.0, 0.0 scale = 1.25, 1.25, 1.25 rotation = 0, 0, 0 texture = model000 , Squad/Parts/FuelTank/mk2SpacePlaneAdapter/model000 texture = model001 , Squad/Parts/FuelTank/mk2SpacePlaneAdapter/model001 } scale = 0.1 rescaleFactor = 1.0 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_top = 0.0, 9.443, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -9.38277, 0.0, 0.0, 1.0, 0.0 node_attach = 0.0, 0.0, 6.1987, 0.0, 0.0, -1.0, 1

Are you using ATM? 1.2scaled? You mean non-power-of-2 dimensions? Unity doesn't support that, it'll be upscaled or downscaled to the nearest power of 2. Or do you mean 1/2 scaled?

thetrystero: add fuel the old-fashioned way. Go to action group editor mode, click on the tank, get a menu on the left. Add whatever resource you like.

e-dog: a request regarding weight for bases: allow setting (in KSPField) not only the multiplier, but also the power, since interstages (IIRC) don't grow quite by the cube of the radius, but by something like the 2.25 power.

Also, the fact that PNG is lossless doesn't matter; KSP converts loaded textures to DXT1 (if RGB) or DXT5 (if RGBA). Since DXT5 uses the same compression for RGB as DXT1, we'll just talk about that. DXT1 is lossy, and is only 16-bit color (5+6+5 bits), so there's even more reason to be sure spatial neighbors aren't color neighbors.

No problem. You can get the GUI for EVE by hitting ALT+N in spacecenter or flight; it will show you the settings for your current planet/moon. You want a height of at least 10000 (10km) for Kerbin, and probably something proportional for the other planets. When done, click apply and then save. However, IIRC EVE 7.x has GUI issues, so you might have better luck, instead of doing that, editing the files directly. Open GameData/BoulderCo/Clouds/cloudLayers.cfg (or the cloud layers of any addon texture pack for EVE if you're using a replacement) and find the altitude = NNNN (where NNNN is some number) lines. Increase them as above.

['imgur]uwd5t['/imgur] Remove the ' and note the letters between the tags are the letters that correspond to your album's link. Regarding flaps and spoilers themselves, though: your problem is you're using them on a delta wing; flaps (or spoilers) in *that* position are essentially just action-group-controlled elevators. If you want to use spoilers (whose effect, btw, is to reduce lift; any pitch moment is a side-effect, just like with flaps) on a wing layout like that you need to place them mid-wing. You can't do the same with flaps... Anyway, your best bet is to stay away from flaps and trailing-edge spoilers on a delta or canard-delta. They're really for traditional-wingplan wings.

tl;dr: no. blackheart: that will give you at best an adapter of a different length, or an adapter with an oval top and bottom. Galane: Unless the stock part is made up of different MODEL nodes referencing different model files, then no. (Now, if the model itself is made from different submodels, you could use a plugin to scale those different submodels, but that can't be done purely by cfg, and I doubt the adapters actually have different submodels). To change the scale at the top of the model without changing the scale at the bottom (for example) you'd have to be scaling the positions of some vertices and not others (or rather, scaling some one amount, and others a different amount), which as you can imagine is something you'd have to do with a plugin.

romie: thanks! ThorBeorn: Thanks! It's the Mettworks inline cockpit, though I had to fix the nodes a bit (and I recolored it). It'll be in RftS v3. Also, I plan to make a full thread in Releases for RftS v3, I've just been shamefully ignoring it...got making prop planes, like the Eule, Hawk Mk II and Mk V, and Tomcat. Turbojet: The British jet...which one do you mean? The long post about the JRC Mk 3, or the Swift, or the remade JRC Mk 3 a few posts up (only 1 picture)?

sovereign: cool! Cryocore: known issue; it's called z-fighting, and occurs when two meshes have faces that are not very distant from one another in the screen Z axis and the camera is far away; due to the precision limits of the Z-buffer, some pixels will think that one face is above the other, and some vice versa. You can try to limit it by raising the cloud layer's altitude above the default, but to keep the same ratio (600 vs 4 for Kerbin in stock KSP, and EVE) you'd have to raise the cloud layer to 40km, which looks super-weird. The next version of EVE will have a workaround though. Also, you should raise the cloud layers anyway (to at least 10km) on EVE 7.x, since there's *another* issue with RSS that the clouds suffer from (and incidentally that will help lower z-fighting).

Padishar: ah, gotcha! Thanks for clearing that up. Rabble: 1. Ah, ok. Mixture ratio will *probably* follow a trend of increasingly lean (i.e. oxidizer-heavy) ratios as TL increases (i.e. switching to staged combustion). Also, the higher the Isp for a given type and TL, *probably* the higher the mixture ratio. However, that is not always true; increases in specific impulse can also come from other factors, and low-Isp / high TWR engines in a given TL may not even be using staged combustion (normally TL4/5+ engines have Isps appropriate to staged combustion cycles). Besides astronautix's engine list, you can look here for tables of liquid engine stats, usually including mixture ratio, and try to derive a correlation between Isp, TWR, year of introduction, and mixture ratio. (Note of course that this is all per bipropellant pairing...) You might want to read http://alternatewars.com/BBOW/Space/Propellants.htm which talks about mixture ratio (and how chamber pressure and expansion ratio influences what the optimum mixture ratio is). Also this (and other) pages from Bob Braeunig: http://www.braeunig.us/space/propel.htm 2: RF assigns masses to tank parts as follows: the total volume of the part * basemass (those top mass values in the page), and (sum) total volume of each resourcetank * that tank's tankmass (for each resource). You can see to the right of those mass listings where I compute what the dry:wet ratio would be for the tank part alone, and the tank part with some extra mass (interstage, ullage rockets, guidance, whatever). I then match those figures against real life examples (you can see a few calculated at the top of the page, like S-IC, Titan II-1, Atlas sustainer, etc). So it's a lot of guesswork to try to get about the right basemass and right mass for each resourcetank (which varies depending on tank type, Default/Cryo/SM).

Benoit: really! That's weird. It should increase the PQS detail level. Hmm, can you post your settings.cfg from the root KSP folder? (Also, on re-reading your earlier post I saw you mentioned having uncommnted this; apologies for missing and asking you to do something you've already done). Have you tried switching to other KSC locations (via tracking station)? Do they all exhibit this problem? The only other thing I can think of at the moment: try a clean install of KSP and add *only* a fresh RSS v6.1. Does the problem persist?

Zyglrox: Ah, thanks! I'm not sure what RealEngines should do with the LES, but RftS will certainly be using something like that. Also, good spot on the docking hub. Jimbimbibble: yep, use PF interstage. Also, which engine pack are you using?

GregroxMun: do it in flight. It doesn't work in other scenes. Kalista: Thank you for an excellent bug report! Might be a drag issue, yes, since the "sudden onset of massive drag" seems to be related to weird interaction between ship design and FAR. What I'd like you to do is try that again with the DRE debug GUI up (ALT-D-R) so when you right-click on things it will tell you whether they're shielded. That said, the shielding algorithm needs replacement (which ferram is doing) since it raycasts against a part's center (and so that antenna might well count as shielding the probe core, since it shields the center of the probe core). Also, you have errors in your long from Distant Objects, from CLS, from KerbQuake, and from Final Frontier. Might want to show this log to those authors as well. Einarr: as Taki117 and Starstrider42 say, MM2.1+ does not require any new format of anything, it merely supports mod makers using more commands. If you do upgrade, however, make sure you get the latest (2.1.2) ModuleManager and delete older copies (including the one in DRE).

You should be safe doing it OnLoad. Speaking of--the "jumping" on launch is symptomatic of scale being set OnStart rather than OnLoad. Stretchy moved to setting scale OnLoad and it doesn't have that issue anymore. Sorry, I wasn't clear, I meant more-than-one-axis, i.e. non-uniform scaling.

Long time no update. DMagic just released a science param changer. Using, AFAICT, the same process I do. Does that work for you? http://forum.kerbalspaceprogram.com/threads/80220-Celestial-Body-Science-Multiplier-Editor?p=1162076#post1162076

IIRC Duna uses a vertex color map rather than landclasses. So you'll need to point it to a different colormap texture.

This is awesome! A suggestion: my plan for this (and boy am I glad I don't have to write it ) was to do the stats changing via confignodes and reflection. For instance, in the MODULE: ChangeStats { // key = member to change, value = power (applied to scaleFactor) to use mass = 2.0 ModuleDeployableSolarPanel { chargeRate = 2.0 panelMass = 2.0 //note that flowRate is set automatically each tick by the module and doesn't need to be changed. } } Note that this would allow the plugin to be applied to arbitrary parts/modules via only cfg changes, not source changes, and would allow users to specify how stats should be changed. Two questions: 1. How do you handle parts with multiple MODELs? I assume you're changing the part's root model transform, not the individual submodels' transfroms? 2. Have you considered allowing non-linear scaling? That would be very useful for, say, scaling fuselages.

RuBisCo: that would be because you spelled wrap wrong... Benoit: thanks! Yeah, it was just a quick thing thankfully. And no worries. For now I suggest uncommenting the maxlevels line; that should fix things, although it will increase the subdivisions in the PQS and therefore slow things down a bit. I take it you're still using the Cape location for KSC (apologies if you mentioned this earlier). AndreyATGB: my appending foo to the start of the node merely changes the node name and so RSS doesn't recognize it. It was easier than commenting every line. Here is a guide to all the settings you can add, and what they do.

After giving the Twin Wasp its real stats (RPMs were way off, e.g.) I had almost perfectly correct performance for the Wildcat. I'm therefore hopeful that by correcting engines' stats we'll get (close-to-real) prop-plane performance.

The Destroyer: http://forum.kerbalspaceprogram.com/threads/64804

A note on rescaling, since the ReStock parts suffer from the rescaleFactor issue. Three things affect scale. First, does the part use MODEL nodes? Skip to part B. A (MODEL node not used; instead "mesh = blah" used) 1. "scale = foo" determines how the first three numbers for each attach node line (the X, Y, Z coords of the node) are scaled. It does *not* affect anything else. Default = 1.0 if not present 2. "rescaleFactor = bar" scales both the model (and its transforms) *and* the attach nodes. Default = 1.25 if not present. B (MODEL node(s) used) 1. Inside the MODEL node, "scale = blahX, blahY, blahZ" determines the scaling of the model and its transforms. Default is 1.0, 1.0, 1.0. It does not affect node positions. 2. Outside the MODEL node, "scale = foo" works as above. 3. Outside the MODEL node, rescaleFactor works as above. HOWEVER, there is a bug in scaling. For parts with MODEL nodes, rescaleFactor is applied twice to the mu, *unless* (a) the part is the root part of the vessel and ( you've reverted to launch (or perhaps switched in flight? Don't recall). All other times, it is applied twice. What this means is that if you have scale = 1.0, 1.0, 1.0 in the MODEL node (or no scale at all), and rescaleFactor = 1.25, then your mesh will actually be 1.5625 as big, but your nodes will be scaled outwards 1.25. For this reason, when scaling parts using MODEL nodes, it is suggested to leave scale (outside the MODEL node) and rescaleFactor both at 1.0, and instead both change the scale = x, y, z inside the MODEL node and manually scale the positions of the attach nodes. Thus this bites the command-pod parts particularly badly, since they're likely to be root parts; on a revert (or quickswitch) their size changes and you likely get RUD.

You can use code to export any Texture2D to PNG. See here for an example. https://github.com/NathanKell/RealSolarSystem/blob/master/Source/RealSolarSystem.cs#L1263

Benoit, apologies for letting this lie so long! (And especial apologies for such a perfect bug-report post, well-described and with the needed log!) I've had a busy few days (sick, then out pretty much all day the last three days) and have only been responding to smaller issues on the forums. Regarding the terrain issue. What version of EVE, if any, are you running? What do you have your terrain detail level set to in KSP's graphics settings? (Is that what you mean by terrain texture details?) You can try uncommenting the maxLevels line in the Kerbin PQS in your RealSolarSystem.cfg and see if that makes a difference too. Regarding speed at launch. Thank you so much for including an output_log.txt unprompted! It appears likely that your problem is having TweakableEverything installed. I had thought the most recent version was compatible with RO, but perhaps not. Try removing it and see if that fixes things. Promp: the Mod Bundler is a bit outdated, but is the last best hope for such a thing. OtherBarry and I are working on updating it. Due to licenses and other issues, not one-stop-shop pack is available. antgeth: asmi has surmised with considerable confirmation that there *is* a memory leak in stock KSP regarding PQS terrain. RSS exacerbates it because it throws a lot *more* PQS terrain around. Though as SpacedInvader says, RSSv6+ adds another 200MB or so of memory usage on top of whatever extra memory the far larger number of PQS quads is taking up. Since you've been playing without ATM, however, that means that all your TGA textures have been sitting in memory uncompressed. Even if you only try ATM basic, you should see a considerable decrease in RAM usage. But Agressive is the way to go. Benskie: it's not the texture that's jittery, it's the [PQS] terrain. I don't know of a way to fix that right now... Tantalus792, RocketBlam: I have created a FAQ page. SpacedInvader: that biome map is looking awesome! Kitspace: you might want to look into TextureReplacer and its texture packs. DasBananenbrot: As AndreyATGB says, they're in there. However, I replied on the linked thread as to why it's a potentially dangerous thing to do (and thus why I left it disabled). SpacedInvader: that's not really how it works; the Squad code that outputs text strings is going to directly reference CelestialBody.name (or .bodyName, which, AAUUUGGH, is actually the same thing). (This maybe also answers Starwaster's point: you'd think so, but noooo, one just points to the other...) RuBisCO: Yargnit has it right. (I should never have defaulted to wrap=true in release. Sorry folks...). For now, set wrap=false at the top of the RSS config file, right below the first { griffin247: Check out the RSS wiki, in particular Ferram's Launch Vehicle tutorial.