NathanKell

Woo! New OP! Hodo: (a) that really kinda goes in the RSS thread, but ( then that file doesn't exist or is unreadable. Make sure that in fact you have GameData/RealSolarSystem/Plugins/PluginData/EarthHeight.png (and also EarthColor.png and EarthNRM.png). If not, then you did not install RSS fully; redownload from the RSS OP and reinstall.

Wait, are you *stripping* alpha? I thought you were compressing to DXT1+1bit alpha, which can be done for the same price as DXT1 IIRC.

Kitspace: if you want your reentries to be about 3x harder than they should be, then yes, you can just comment out the rescaleFactor and node_* lines in the the RO part configs (as long as MODEL nodes aren't used, rescaleFactor is all that controls scaling). If MODEL nodes are used, then it gets...complicated. I fully intend to replace Kerbals with human astronauts, btw. That said, you're welcome to try with realistic masses but smaller parts; just understand that aerodynamics will get *weird* if you suddenly have 1/3 the ballistic coefficient you used to. As for RCS: those "big blocks" are actually as powerful as the Apollo Service Module RCS, which was used on a 30ton (45 ton with LM attached) spacecraft. So even them firing full blast is very slow. KSP has trained you to think of dozens to a hundred degrees per second turnrate as normal; it's really, really not. Until we had ModuleRCSFX, due to bugs in Squad's code, stack-mounted RCS was broken. Now that we do have ModuleRCSFX, we can finally make stack-mounted and part-of-the-pod RCS... There's nothing wrong with flotation in RO; that appears to be a float precision issue regarding collision detection. If you actually calculate what the precision of a float is at 6,371,000, it's around one (i.e. can't be more precise than a meter). That seems to be why things sink into (or float above) the ground, and why things bounce on the water. tl;dr RSS issue, not RO issue. RedAV8R: actually, sounds like along with !RftS we also need !Stockalikes or whatever.... dlrk: From the file: FoodConsumptionRate = 3.0 WaterConsumptionRate = 1.7 OxygenConsumptionRate = 550 ElectricityConsumptionRate = 4320 BaseElectricityConsumptionRate = 17280 EvaElectricityConsumptionRate = 28800 CO2ProductionRate = 506 WasteProductionRate = 2.0393 WasteWaterProductionRate = 2.0 DefaultResourceAmount = 86400 EvaDefaultResourceAmount = 43200 MaxTimeWithoutFood = 2592000 MaxTimeWithoutWater = 259200 MaxTimeWithoutOxygen = 180 MaxTimeWithoutElectricity = 259200 This is TAC, so that's units per day. Food is 0.8kg/L, O2 and CO2 are at STP per liter, and wastes are around 1.01kg/l (you can find the exact numbers in RealFuels).

Did your rocket wobble? Swaying side to side also counts towards DRE's G limit.

leeham991: Look about 1-2 pages back where SpacedInvader posted that very thing. Hodo: the number one rule of troubleshooting is post log. My magic wand is even poorer than Sarbian's. Clearly something is breaking while RSS is loading, but unless you actually post the output log (not ksp.log), I have no idea what. velusip: nope, it's perfectly correct for EVE Overhaul, which you should be using instead of 7-3 anyway, since 7-3 has serious issues with RSS. If you want to use it in 7-3, you'll need to flip it along X and also move it 1/4 sideways. This is because Kerbin's mapping is weird. pingopete et al: here is a (code only! Unzip over your existing folder, don't nuke your exisitng folder first!) prerelease with a compatibility hack to play nice with EVE and Kethane and anything else. https://www.dropbox.com/s/1ib0fbxeswka3gp/RealSolarSystem_codeonly_v6.3pre1.zip

camlost: anything else? Uh, the entire way horsepower is calculated for piston engines? Intercooler and ram air modeling? Multiple boost ratings and settable maximum manifold pressure?

I'd say map view is a very poor substitute for the maneuver planning software NASA uses, but eh.

IIRC on that suborbital Soyuz abort the cosmonauts experienced ~15-18G. And that's with a lifting reentry! It'd probably be over 20 on a straight ballistic reentry like you'd get with Mercury or Vostok/Voskhod. pingopete: lemme try my workaround for EVE not handling scale changes. I'll get that fixed and post a beta, you can try it out and let me know if it helps at all.

Yep, those last two shots are the best so far IMO!

Just to follow up, RO energy density is 3600x what stock's is. (Based on the battery weight of Ranger 5 IIRC).

Very intriguing. The killer feature, for me, is the "use DXT5 only when necessary" bit--no sense in compressing pure-white alphas to DXT5.

You could look at how RT2 handles it: https://github.com/RemoteTechnologiesGroup/RemoteTech/blob/25ad7a5bba70d387b352bcdf546acf326e22b688/src/RemoteTech2/Modules/ModuleRTAntenna.cs#L386

Yeah, just to confirm, OnLoad is called before you get to add your module.

lolwut? Yes, exactly! That totally explains why when I burn radial+ I go up rather than changing my perigee. Oh wait. No, KSP exactly implements orbital mechanics. The fact that it doesn't implement n-body mechanics is not because it's easier for the users, but because it's easier for SQUAD. It's perfectly realistic within a 2-body system of point gravity sources. The fact that you've grown used to orbital mechanics should not make you think that something you *haven't* grown used to is harder, let alone more counterintuitive. EDIT: Post pics or we're shooting in the dark here.

cardgame: replace the file named the same as the file you downloaded (main.png) tmikesecrist3: 9535 should be enough. Launch directly east to a low apogee (~200km) with your main stage, line up prograde at apogee, and then fire your solids about 3 seconds before apogee. If you're getting 9535dV, though, you most certainly have realistic masses enabled. SpacedInvader: awesome! Expect a PM shortly, sorry for delay. pingopete: until rbray finally fixes scaling on his end, I'll do a workaround on mine... Major Gene: Sparker 99% answered this, but for the rest: you can use MechJeb. Target the satellite/station/moon/whatever whose orbital plane you want to match, and click "launch into plane of target" in the ascent guidance window. Then launch at T-0 seconds. If you want to do it by hand, you can again target the desired object, go to map view and look at the AN/DN, and launch when they're nearly 0? Sparker, that is a *very* handsome(ly done) mission! EliteAnax17: something's crashing during load. First guess might be Tweakable Everything (it's well known to have issues with RSS-related mods), but if you don't have that post your output_log.txt. pingopete: Sorry, not sure what you're asking about regarding PQS fade distance--what is it doing, and what do you want it to do? griffin247: enter 90 in the orbital inclination dialog box on MJ ascent guidance. That will give you a near-polar orbit. You really, really need to sit down, take a break, and learn some orbital mechanics (and other tidbits about rocketry). Like, say, what orbital inclination means, and how it's different from your heading and/or launch azimuth. RSS is not the sort of thing you can just pick up and run with, even if you know stock KSP cold. Kitspace: I don't know what's doing that to the water. I need to compare notes with rbray about the water shader, something's borked. It's not that the water is too shallow, it's that something gets broken in the shader regarding transparency. K3achas: known issue. regex and I tried mucking with the camera; regex fixed some issues, but neither one of us has figured out how to reset the camera in exactly the way that going into and leaving a building (VAB/SPH/TS) does. SpacedInvader: There's no math I'm aware of for figuring out what to put in an MJ ascent profile, other than match turn start to 100m/s (modulo your TWR; high TWR first stages need an earlier turn start, lower TWR ones need a later turn start). At one point Sarbian was talking about writing a FAR ascent guidance module for MJ, but I think got busy. (Note that as that implies, this isn't an MJ-RSS issue per se, but 90% an MJ-FAR issue made slightly more complicated by RSS). As it happens, trajectory optimization is hard (in the technical senses of both math and computer science); it's certainly not a problem that anyone's "solved" in real life, and KSP+FAR is not actually all that much simpler than real life. Here is a paper I found in a two-minute google, for example. TL;DR most everyone uses numerical methods. :] (Google optimal ascent trajectory, or trajectory optimization, or...etc.) The Big Guys use sophisticated 6DOF simulators to optimize their ascent profiles, which is basically Ye Olde trial and error, just done real fast by computer.

Looking snazzy!

While we're talking textures, there are some duplicates: in FASA\FASA_ICBM\ ICBM_Guidance_n_NRM.png and ICBM_Guidance_n_NRM.tga (the diffuse map however is not duplicated) Then in FASA\FASA_ICBM_Nosecone ICBM_Nosecone.png ICBM_Nosecone.tga and ICBM_Nosecone_n_NRM.png ICBM_Nosecone_n_NRM.tga Note that I haven't dug through the other folders; I just remember those from ~3.0 but I keep forgetting to tell you about them

Pshaw, you think *that's* brutal? Try a warhead reentry. Nearly as hot, but something like 10x the G load. Seriously, though--yeah, good luck on that! I wouldn't be surprised if you need .98+ reflectivity.

EliteAnax17: remove TweakableEverything. If it still bugs out, post your log. tmikesecrist3: they *didn't* control it. Explorer I was spin-stabilized. Here's what happened. 1. Jupiter-C lower stage burns out, establishing apogee. 2. Thrust section detaches. 3. The "bucket" with the solids and the guidance unit reorients for apogee kick. 4. The solids (and Explorer) are spun up (IIRC something like 1000RPM) 5. The first set of Baby Sergeants decouple and fire 6. The next set decouple and fire 7. The final Baby Sergeant detaches and fires, placing Explorer I in orbit griffin247: recall that polar orbits require ~500m/s more delta V. Other than that, please say more (and more clearly) what your problem is.

IronGremlin: that's exactly what the Mod Bundler is supposed to do. Only issue: it was out of date. OtherBarry has reworked the manifest, now it's waiting on me tweaking the code to point to the new stuff. ....you wouldn't happen to know Ruby and/or Java, would you? jrandom: "Your only enemy is physics." --sigged. Agathorn: RO has *always* been 100% real scale. When I was first bandying about the idea on the dev forum, we were thinking maybe 0.64x, but that was before I managed to make RSS. Since RSS v1 (which far predated any released form of RO) RO has always been 100% real scale and 100% real mass. The reason your engine sizes are wacky in career is because career is set up for the engines' original stats (and has many other problems). Use RPL. Sadly right now it only supports RftS engines, not RealEngines, but it's planned to support them too.

Kitspace: well, that's your problem. Of course your Gs are going to be higher. Ask yourself this: which will decelerate quicker in air, a rock or a piece of paper? Well, since you're not rescaling the size of the Mk1 pod, and yet it has Mercury's mass, it's going to behave more like a rock than a piece of paper, which means it's going to come in much hotter and faster and have brutal deceleration at the end. It isn't just for kicks that I rescaled stuff in RO--there's a reason that real life pods are the size and weight they are. If you want KSP sizes, you're going to have to proportionally decrease mass - right down to 0.2 tons for the Mk1 pod, plus 250kg for the shielding yields 0.45t, which is the Mercury's 1.12 tons divided by (1.6*1.6) due to the decrease in surface area. Starwaster: the latest DREC does set Ablative tweakable in the RESOURCE_DEFINITION (which is where you have to enable tweakability; the setting in the RESOURCE node will only disable it if it's already enabled, IIRC, it won't force-enable it).

Hmm. While engine TWRs are more or less correct, the tank mass ratios are much more guesswork, and also assume that you're loading down each stage with the appropriate other stuff (guidance, retro rockets, ullage motors, interstage bases and fairings, 3 axis RCS stabilization for uppers, etc). If you go "light"--and especially if you, say, use a balloon tank rather than a regular tank--your dry mass fraction will vary, and with it your dV.

Clouds folder has changed name for Overhaul. That would be why. Use this config. ACTIVE_TEXTURE_MANAGER_CONFIG { folder = BoulderCo enabled = true OVERRIDES { BoulderCo/Atmosphere/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = false } BoulderCo/CityLights/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = true } } }

TeeGee: the mod works fine with procedural tanks. However, make sure you have valid fuel crossfeed between the tank and the RCS thruster.

Ah. Um, RftS does include AJEInlet support now. Sorry I was so late with the commit. It's in the repo. Also, camlost, after banging my head one too many times on YASim's crappy piston engine modeling, I rewrote most all of it, borrowing some from JSBSim but also modeling intercoolers and (to some extent) turbochargers. https://www.dropbox.com/s/fjawbskq3zurcj5/AJENK.zip To take advantage, the engine configs need to be changed a bit. Here are the changes I propose. If you want more engines, you can grab the engines from here: https://github.com/NathanKell/ReachingfortheStars/tree/master/RftS/Parts/Props Note that I would request you not add the M82S, BMW801F, Fiat1600, Jumo222, and M85 to AJE as they are fictional RftS-verse engines. Finally, if you would like to create more engines, you can use the AJEProps page of my Calcs.xls sheet, which contains instructions for matching engine performance.