NathanKell

Everything gets printed to the log listed in this post (location varies Win/Mac/Linux): http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

Plus KSP won't parse a key-value pair without a value, as of (.25? some time). So if you want to delete a value, you need to do -val = SOMETHING (or DEL or foo or asdfasd or...)

Dr. Walther: You're most welcome. I made that config when I was first testing RSS for 1.0 and didn't have RO patched enough to work. It's literally just a quick hack; it's designed to give stock things realistic thrust, Isp, and dry mass. However, it doesn't change the size of things, which means reentries will be much harder than they should be (due to higher BC). Since the parts have (mostly) realistic efficiencies, that means you'll need real-life mass ratios (and get only real life payload fractions), so no, it won't make KSP-sized craft magically able to do RSS-size things. But you won't have any more engines and tanks 4x as heavy as they should be. Also, if your orbital velocity is 10km/sec...yikes. Something's wrong. It should be 7700m/s or so in LEO (7200 surface), which takes about 9.3km/sec of vacuum delta V. A better solution (IMO) would be to install RF and RF Stockalikes--it will do the same thing, just much better, and give you rather more options too. Regarding clouds, you'll want to look at the RSS Visual Enhancements thread in the dev forum, but EVE doesn't work right with RSS/Kopernicus right now... Blacks: Sorry, that's (to my knowledge, anyway, and with much testing in 90) not correct. EVE in .90 worked fine with every single texture exept the cloud mask marked unreadable. That's how RVE shipped (I wrote the configs for what textures to be kept readable and what not). In 1.0, the issue with terrain is that Kopernicus replaces planetary terrain shaders, so EVE can't modify them. I made an issue on the EVE repo about it, I'll work out with rbray what he and I need to do. Regarding not using the cbNameLater and instead just using name, I couldn't get that to work. KSP is very deeply tied to the PQS being named 'Kerbin' (Space center won't display right otherwise, etc) and the best I could do was rename only the CelestialBody, and only later (not at start). That's the reason EVE has trouble on Earth--it's looking for a CelestialBody and PQS/Scaledversion named the same and not finding them. Dr. Walther: I would _love_ to include those textures in RSS. You wouldn't happen to have made heightmaps too, would you? sebi.zzr: Kopernicus ought to be able to do that, but there's a bug in 0.0.8 which isn't letting it. Thomas P has almost got it fixed, and I'll be trying my hand as well tonight. Blacks: I wish I knew why there's the 100mb leak. And I rather bet Mu wished he knew too :] Ralathon: I'll check. It should be loading those, not spamming. NoPanShabuShabu: See, this is one reason we're rather chary about the hacks: because none of what you describe is even a bug, it's just log spam. And now there's a post on my mod thread worrying about a "bug in x64" when the bodies get sorted differently from their entry order in the cfg, when...that's exactly what Kopernicus does. And same for the OD logspam, though as I said to Ralathon it should not be spamming that much. Jeef, Lazzy, it's not enough to rename your old textures folder. The new RSS10 textures are different and downloaded from a different place (not the OP). You get them here: https://github.com/KSP-RO/RSS-Textures/releases Assuming I can finish Thomas P.'s work on fixing AtmosphereFromGround I hope to get RSS out quite soon--thanks everyone for the testing!

rkman: post the next log then please. Carraux: RF has no trouble on the stable, released x64 build (aka Linux). enroger: Rates are about 600lb/hr in LEO for LH2, much less for LOX. If you want the cold hard numbers, loss rate is calculated as (tank temp - boiling point) * loss_rate * maxAmount liters/sec. where loss_rate and boiling point are specified per resource per tank definition in RF/Resources/RealTankTypes.cfg (Cryogenic tanks have lower loss rates).

Get SmokeScreen. That will fix the FX.

The thing that makes engines perform better at sea level is chamber pressure. The thing that makes engines perform better in vacuum is a larger area ratio (not a larger nozzle per se, but a larger change in area from throat to exit). If you take an engine with high chamber pressure, even if you give it a high area ratio nozzle, it'll still perform decently at sea level. That's Merlin 1D. If you take an engine actually designed for vacuum use, like RL10, it will perform quite horribly at sea level if it even works at all.

Need the log (the right one)...

What mods do you have installed? That sounds like something else is interfering.

Well, hope it doesn't come back. :]

Welcome aboard! There are two things that control maneuverability: 1. Torque. 2. Stability. Torque is the product of the control force times the lever arm--the larger the control surface the more force, and the farther away from the center of mass the longer the lever arm and the more that force gets magnified. Stability is determined by how far the center of pressure is from the center of mass. If it's behind the center of mass (ye olde KSP axiom of "CoL behind CoM") the craft is statically stable (will follow the prograde marker when you take your hands off the controls), and if it's not, the craft is statically unstable (will tend to deviate ever further from prograde). If they're right on top of each other, you have neutral stability (the plane will move neither towards nor away from prograde). The further away the CoP is from the CoM, the stronger that stabilizes (or unstabilizing) force is. Most KSP aircraft have their center of mass towards the rear, because that's where the heavy engines are. That means when you add canards at the front, they're both (a) larger than the control surfaces you usually add at the rear and ( much, much farther from the CoM than the ones at the rear. So they provide a lot of torque. Next, because they're in front of the center of mass, they move the center of pressure forward compared to the center of mass, thus lowering stability and making the plane even more maneuverable.

jrandom: that's...random. Link dead though. Vannort86: I'd say try again, github can be annoying. If it's still a problem over a few days let me know and I'll see if I can find an alternate method for you. Dr. Walther: Have you posted on the CKAN thread? CKAN folks are quite good about helping people get CKAN working (although as mentioned, there isn't a release of RO for 1.0 out for CKAN, though one is expected quite soon). Meanwhile you can download just realfuels and stockalike engine configs and that should give you decently efficient rockets. If even that is too much, try this cfg that will just apply to regular old parts and make them more efficient: http://pastebin.com/DYvg603b Grav parameter is the product of mass and Big G. For some bodies that's known to more significant figures than just mass. rotationPeriod is how quickly the planet rotates. I'd suggest leaving it alone. SMA, however, you would want to reduce some. blub01: KSP engines are somewhere between 4 and 7x too heavy, yeah. Tanks are about 2-4x too heavy (depending on the use case). Blacks: I'm sorry to say I'm having real trouble understanding what you're saying. Can you try again? I'm aware that changing Kerbin's name to Earth like that can cause trouble for EVE, but EVE has enough issues as it is on 1.0, and it would be really, really annoying to have all the other bodies' names correct but Earth's wrong. EVE works fine with DDS for everything that doesn't have to be kept readable; due to an issue in KSP, no DDS textures are loaded as readable which means the cloud mask can't be DDS. Another issue with EVE is indeed that it has trouble with Kopernicus PQS shaders. Thomas P.: as I mentioned in IRC, it's because the RSS plugin does things other than body-changing (and now that's all it does, since Kopernicus handles the body-changing). SirKeplan: Are you using FAR? If not, that's your problem. If you are, things should certainly not be soupy (unless your LV has horrid transonic drag). As for reentry FX (not heating, FX) that's a known issue with 1.0.2 and we hope it'll be better tunable in 1.0.3. Certainly you should be getting heating at 95km and 4km/sec--not much, but some.

blub01: I'm not aware of RO doing anything to Infernal Robotics, and your log has a literal crapton of errors from...all sorts of mods. I think your best hope is to start with only a few mods and slowly build back up, checking the log for `Exception` after each run, and seeing what's causing them.

rkman: uninstall TweakableEverything. That seems to be the root of the problem.

Yes, RO is a mod itself. While what it does is patch other things, that makes it no less a mod. If you're playing on .90, you can install it via CKAN. Since the 1.0 release is not out yet, you will need to download from the repo: https://github.com/KSP-RO/RealismOverhaul/archive/KSP10.zip

The issue isn't DRE's fault, you'd get it with RO and no DRE. It's that aerofx is tied to convection (which is correct) but isn't scaled down when convection scales up.

Here's a prerelease of RF v10.3. Please try it out, but NOTE: if you are using AJE as well, you will need to update it to the latest version on the AJE repo (i.e. go to https://github.com/camlost2/AJE and download zip and use the GameData/AJE folder). RF: https://www.dropbox.com/s/vrtnru9i86h0yrn/RFv10.3.zip?dl=0 The major thing this adds is unlock costs for engine configs and TLs. RF Stockalike doesn't give configs costs, so you'll only pay for TL upgrades. Please try it in career and see what you think!

And the output log. Meanwhile: Here's a prerelease of RF v10.3. Please try it out, but NOTE: if you are using AJE as well, you will need to update it to the latest version on the AJE repo (i.e. go to https://github.com/camlost2/AJE and download zip and use the GameData/AJE folder). RF: https://www.dropbox.com/s/vrtnru9i86h0yrn/RFv10.3.zip?dl=0 The major thing this adds is unlock costs for engine configs and TLs. RF Stockalike doesn't give configs costs, so you'll only pay for TL upgrades; RO mostly doesn't use TLs, but its configs do have costs. Please try out career and see how it goes.

Final (?) pre-release version: https://www.dropbox.com/s/6s2u20uo9ro2ri6/RSSv10PRE.zip?dl=0 Please let me know if you encounter further issues. Known issues: Phobos and (especially) Deimos have wonky terrain Saturnian moons don't have heightmaps.

- and ! are synonymous.

That...seems an odd way to bump a thread three weeks on... arkie87, how goes the plugin-ing?

spbrhs07, welcome to the forums! However, this sounds like the mods aren't properly installed, since RO's purpose exactly is to give parts real values. If the FASA F-1 engine does not have correct thrust (7700 or so--remember, 6770 is the sea level, not the vacuum, thrust) then RO is not running properly.

Yep, if you change the size, change the mass. Or remove the mass line and just set geeASL, and mass will autoscale.

And yet if you actually add an umbilical (i.e. a fuel line) it will work as designed.

Why use an XP system, when there's the tech tree? (Indeed, that was how the tech tree was originally unveiled to the forums--nodes would unlock better performance for your parts. But then it was changed to just 'unlock new parts').

That's 500 minutes. That seems a bit much. I would expect 8192s to take about 40 minutes or less, though it depends on your CPU.