Realism Overhaul Discussion Thread

[AviatorTrainman]

Thanks. I wonder if someone has made a list of all the underground sites.

[komodo]

Hey-o all! How's everyone?

I am hoping this is the right place to enquire about the ro-mini.cfg that is floating around. I decided to pick it up for a run through on 6.4x, and thus far i'm having a blast. 

My enquiry though is about SRB's; they too are having a blast. A big blast. Such as 20:1 TWR and the like. I am unfortunately away from my KSP machine for exact numbers, but I was blown away by a staging accident, when a 'small' solid retro thruster fired on the pad, and sent the capsule on a nice 4 km arc. Gave Jeb a nice 15g pulse or so as well. (He of course had a ball.)

I had a look through the cfg, but it all seemed in order. The density and quantity of the solid fuel seemed alright, as did the corresponding thrust increase, but... well. I don't know if it's intended or not, that fun TWR.

The rest of the cfg is working marvelously, so i'm very happy in that respect. 

Thanks all, and sorry for the puns, inadvertent or otherwise!  

[CorvusCorax]

12 hours ago, komodo said:

Hey-o all! How's everyone?

I am hoping this is the right place to enquire about the ro-mini.cfg that is floating around. I decided to pick it up for a run through on 6.4x, and thus far i'm having a blast. 

My enquiry though is about SRB's; they too are having a blast. A big blast. Such as 20:1 TWR and the like. I am unfortunately away from my KSP machine for exact numbers, but I was blown away by a staging accident, when a 'small' solid retro thruster fired on the pad, and sent the capsule on a nice 4 km arc. Gave Jeb a nice 15g pulse or so as well. (He of course had a ball.)

I had a look through the cfg, but it all seemed in order. The density and quantity of the solid fuel seemed alright, as did the corresponding thrust increase, but... well. I don't know if it's intended or not, that fun TWR.

The rest of the cfg is working marvelously, so i'm very happy in that respect. 

Thanks all, and sorry for the puns, inadvertent or otherwise!  

which SRBs - the procedural ones?

There was a bugfix to procedural parts recently that got triggered when there was more than one procedural SRB on the same craft. all the srbs would then share the same fuel flow (and as such thrust) picked up from a single one of them (usually the largest) - that led to some pretty crazy effects on staging.

you can of course build a SRB with crazy TWRs - the maximum thrust possible depends on the diameter of the srb (larger srbs you can give larger nozzles) so a short but wide srb with a large nozzle might have an effect more acin to a shaped explosive charge than a rocket

[NathanKell]

It's been so long since I wrote that file that I don't recall too well. @komodo can you post some examples of SRBs, i.e. dry mass, wet mass, thrust, and sl/vac Isp? Then I can give them a sanity check.

In general case mass is going to be ~5 to ~20% of the wet mass. Thrust varies, but IIRC I increased the base thrust a bit so you have more options (i.e. you should generally plan to run at 50% on the thrust limiter for solids, but higher than that is available if you want high thrust kicks).

[komodo]

2 hours ago, NathanKell said:

It's been so long since I wrote that file that I don't recall too well. @komodo can you post some examples of SRBs, i.e. dry mass, wet mass, thrust, and sl/vac Isp? Then I can give them a sanity check.

In general case mass is going to be ~5 to ~20% of the wet mass. Thrust varies, but IIRC I increased the base thrust a bit so you have more options (i.e. you should generally plan to run at 50% on the thrust limiter for solids, but higher than that is available if you want high thrust kicks).

I will certainly check when I get home later, and post some numbers. The base thrust increase might be all that is amiss, I had them set to 100% still.

EDIT: @CorvusCorax, no, they were just some normal SRBs. I haven't gone full bore PP yet, as 6.4x is a decent compromise between kerbal parts and requisite min/maxed performance, at least so far.

On an unrelated note, I also peeled the resizing/tech tree changes for Procedural Fairings out of RP-0 for my own playthrough. Would it be worthwhile to clean that up and patch it in to RO-mini.cfg? I know pull requests are always/often welcome  

Edited December 14, 2015 by komodo

[NathanKell]

PRs are definitely welcome!

[CorvusCorax]

I have a question regarding reentry and aerobreaking in RO - specifically asteroids.

I am trying to capture an asteroid using the upper layers of earth (rss) atmosphere to decelerate it. Orbital speed is between 10k and 11k m/s.  Both my tug and the asteroid itself heat up to extreme high temperatures and desintegrate/explode in the remote outer parts of the atmosphere. The b class asteroid i assumed I could use as a headshield explodes in a cloud of dust in space at >120 km alt. My (retracted) solap panels overheat and explode at around the same alt. Below 120 even more sturdy parts like fuel tanks and my attachment claw exploded.

I'm using RO on KSP 1.0.4

Is this behaviour realistic? I always thought meteors only lite up at around 50 km to 90 km. Is this a problem of KSP's heat model (and heat effects on asteroids) or of the aerodynamic friction model used?

Obviously a real asteroid would start loosing parts of its outer layer, not so unlike an ablative heat shield - while not heating up at the core that quickly - While in KSP the asteroid just heats up and vanishes when getting too hot - not unlike a pressurized fuel tank would. But then again this could be correctly modelled by increasing the (surface) heat tolerance of asteroids.

And then again I wonder if KSP just generates far too much heat that far out in the atmosphere at these speeds. Maybe RO (or a module in RO - realistic reentry maybe? or FAR?) needs to fix the thermal friction modelling?

what's at fault here?

 

[komodo]

Ahoy! I come bearing numbers!

Lets see if I can spoiler this such that it doesn't eat the thread... Hmm.

Spoiler

 

So, using a RT-5 Flea as a starter, aka, trashcan full of black powder, mated to a mk1 capsule, we have a:

• 7905 kg wet mass.
• Empty mass of 1836 kg.  ~23.25 % case mass if I mathed correctly.
• ISP of 196/231 asl/vac.
• Thrust of... 1883.229/2219.52 kN!
• Fuel load of 809.2 solid fuel.
• From KER, if we wish to send Jeb on a particularly wild ride, we have a TWR (MAX) of 21.91 (71.43) at the lower thrust rating. 2271 m/s dV. 6.2 s burn time. (This would be the shaped charge mentioned above, heh.)

For the RT-10 Hammer, similarly we observe:

• 19316 kg wet mass.
• 3060 kg dry mass. ~15.842 % case mass.
• ISP 238/273.
• Thrust 2287.694/2624.12 kN
• Fuel load of 2167.5.
• Jeb's wild ride: 11.56(59.61) TWR, 3829 m/s dV. 16.6 s burn time.

BACC Thumper:

• 41667 kg wet mass.
• 6120 kg dry mass. ~14.688 % case mass.
• ISP 245/294
• Thrust 2890.0/3468.0 kN
• Fuel load of 4739.6.
• Jeb's wild ride: 6.92(42.24) TWR, 4345 m/s dV. 29.6 s burn time.

Amusingly, we also have from Blue Dog Rockets, their explorer engine module:

• 780 kg wet mass.
• 347 kg dry mass. 44.49 % case mass.
• ISP 224/378. (This may be a balance issue to take up with them, but I digress.)
• Thrust 102.756/173.4 kN.
• Fuel load of 57.8.
• Jeb's mild ride: 6.42(8.75) TWR, 679 m/s dV. 9.3 s burn time.

That last one on a 100 kg explorer probe core is a wild ride indeed: 2514 m/s in 9.3 seconds.

c.f. all of the above to a pair of FL-T200 tanks with a LV-T30 Reliant,

• 7000 kg wet tanks + 800 kg engine.
• 200 kg dry tanks mass. ~2.85 % case mass.
• ISP 280/300
• Thrust 513.707/550.4 kN.
• 612 LF, 748 Ox.
• Jeb's mild ride: 10.68(30.10) TWR. 2864+ m/s dV, 18.2 s burn time.

 

In any case, i'm not certain how to interpret these numbers entirely. The larger boosters seem a bit more... sane? I'm not sure what the function of the smaller boosters is, aside from the explorer model. Anyway, thanks for any feedback you might have. If the numbers are legit, I will design around that. (I'll design around that regardless, as i'm not sure what numbers to poke at in the cfg )

EDIT an addendum, with 1 1/2 questions: Any idea what might cause a part to fail to rescale in the editor/in general? The backseat from MOLE seems to retain its 1.25/1.875 m sizing following reconfiguration.  The 1/2 part of the question is MM reporting 4 errors applying romini.cfg. Any idea where it might have logged the issue, or do I dive into player.log and pray? Thanks!

Additional edit: The four errors appear to be SRB related. Details after the cut below...

Spoiler

The offending MM block is thus:

@PART[*]:HAS[@RESOURCE[SolidFuel]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 4.8 // will multiply by 0.25 later, yielding 1.2x orig mass. With 1.7x resource,
	// we get decent mass ratios.
	@MODULE,*:HAS[#name[ModuleEngine*],!PROPELLANT[IntakeAir]]
	{
		key0 = temp
		key1 = temp
		@key0 = #$atmosphereCurve/key,0$
		@key1 = #$atmosphereCurve/key,1$
		@key0 ^= :0 ::
		@key1 ^= :1 ::
		@key0 *= 1.4
		@key1 *= 1.4
		@maxThrust *= 3.4 // double the resource multiplier, divided by all-engine multiplier
		// to keep pace with fuel change alone it'd be 1.0625 x 1.6 = 1.7
		@atmosphereCurve
		{
			@key,0 = #$../key0$
			@key,0 ^= :^:0 :
			@key,1 = #$../key1$
			@key,1 ^= :^:1 :
		}
	}
	@RESOURCE[SolidFuel]
	{
		@amount *= 1.7
		@maxAmount *= 1.7
	}
}

With specific errors from MM:

[ModuleManager] Applying node Tweaks/ROMini/@PART[*]:HAS[@RESOURCE[SolidFuel]]:FOR[zROMini] to RLA_Stockalike/Parts/Engine/so
lid_medium_upper/medium_upper/RLA_solid_medium_upper

[ModuleManager] Error - Failed to do a maths replacement: @MODULE,*:HAS[#name[ModuleEngine*],!PROPELLANT[IntakeAir]] : origin
al value="135 -20 -50" operator=* mod value="1.4"

[ModuleManager] Applying node Tweaks/ROMini/@PART[*]:HAS[@RESOURCE[SolidFuel]]:FOR[zROMini] to RLA_Stockalike/Parts/Engine/so
lid_small_boosters/long_booster/RLA_solid_small_long

[ModuleManager] Error - Failed to do a maths replacement: @MODULE,*:HAS[#name[ModuleEngine*],!PROPELLANT[IntakeAir]] : origin
al value="166 -20 -25" operator=* mod value="1.4"

[ModuleManager] Applying node Tweaks/ROMini/@PART[*]:HAS[@RESOURCE[SolidFuel]]:FOR[zROMini] to RLA_Stockalike/Parts/Engine/so
lid_small_boosters/med_booster/RLA_solid_small_medium
 
[ModuleManager] Error - Failed to do a maths replacement: @MODULE,*:HAS[#name[ModuleEngine*],!PROPELLANT[IntakeAir]] : origin
al value="166 -20 -25" operator=* mod value="1.4"

[ModuleManager] Applying node Tweaks/ROMini/@PART[*]:HAS[@RESOURCE[SolidFuel]]:FOR[zROMini] to RLA_Stockalike/Parts/Engine/so
lid_small_boosters/short_booster/RLA_solid_small_short
 
[ModuleManager] Error - Failed to do a maths replacement: @MODULE,*:HAS[#name[ModuleEngine*],!PROPELLANT[IntakeAir]] : origin
al value="166 -20 -25" operator=* mod value="1.4"

Hrm. So there're our four errors. They seem restricted to some RLA boosters. Not SRBs in general. What're they called... Floatcurves? It appears that RLA is using the intangent and outtangent arguments to the floatcurves for ISP on their SRBs. The MM doesn't appear rigged to handle that (I can't imagine how it would though... I'm not sure I follow the current math as it is, d'oh!)

Example of an 'offending' floatcurve:

atmosphereCurve
 	{
   	 key = 0 245
  	 key = 1 135 -20 -50
	 key = 6 0.001 -75
 	}

I haven't looked at those boosters in particular, I don't know how they're behaving. I imagine the ISP would be wacky, but otherwise ok?

At the hour of 11:30 PM as it is now, I think I will let this rest a while and come back to it fresh... Friday or so, most likely

Edited December 15, 2015 by komodo
WHOLLEEEEEELOTTAAAASTUFFFFFFF

[NathanKell]

Numbas!

 

So, I believe my reasoning for those high default thrusts was to allow use of the sep motor (and other small solids) in escape towers, and to allow replication of the Baby Sergeant (6s burn time). So yeah, it's just to give you flexibility--under normal circumstances you'd want 50 or even 25% thrust limiting set for your solids.

That Blue Dog Rocket thing sounds like it tries to balance its quite crazily high Isp with a low fuel fraction (and also that perhaps its Isp was not downscaled to align with KSP 1.0+ solids balancing).

As to the non-rescaling, wanna pastebin (or code-tag) any MODEL references in the part's original cfg, as well as any references to scale and/or rescaleFactor ?

[RoketMan]

OK, i'm having problems with the mod Salute stations and Soyuz ferrys,  because it crashes when I try and load it game, but when I remove it I don't have that problem. I would really like to use the progress spacecraft and Salute stations that it offers. Please help? The reason I think it's crashing, is because it's loading in the whole bunch of files that aren't  there. Says "cannot load file" a whole bunch of times.

[komodo]

On 12/15/2015 at 0:05 AM, NathanKell said:

As to the non-rescaling, wanna pastebin (or code-tag) any MODEL references in the part's original cfg, as well as any references to scale and/or rescaleFactor ?

So. Right. The parts in question source from the mk1 MOLE mod by Angel-125. This mod here.  Two example parts that don't seem to play nicely are the WBI_FCP,
 

Spoiler

 

// --- general parameters ---
name = WBI_FCP
module = Part
author = Michael Billard (Angel-125)

// --- asset parameters ---
rescaleFactor = 1

MODEL
{
	model = WildBlueIndustries/MOLE/Assets/FCP
}

 

 

and the Backseat,

Spoiler

// --- general parameters ---
name = WBI_Backseat
module = Part
author = Angel-125

// --- asset parameters ---
MODEL
{
    model = WildBlueIndustries/MOLE/Assets/Backseat
}
rescaleFactor = 1

 

The only thing I can piece together is that each uses some custom MODULES defined by a supplied .dll that the author has written. But Why would that cause a model rescale to not take? MM doesn't say anything regarding the parts, so I am left to assume that the patches applied cleanly. The relevant code from romini.cfg is thus: 

Spoiler

// RESCALE
@PART[*]:HAS[#rescaleFactor[*],!MODULE[ProceduralFairingBase|ProceduralFairingSide]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@rescaleFactor *= 1.6
}
@PART[*]:HAS[~rescaleFactor[]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	rescaleFactor = 2.0
}
@PART[*]:HAS[~scale[]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	scale = 1.0
}

 

which, as i'm slowly learning MM syntax, (and ignore the procedural fairings portion, that's another bug i'm hunting...), the first block matches any part with rescalefactor defined and multiplies the found value by 1.6, and sets that as the new rescalefactor; the second block matches if the part lacks a rescalefactor and sets it to 2. (I am also confused why 2. Is this that weird KSP internal thing where rescalefactor = 1 is based on 1.25? That's the only thing I can figure. Anyway.)

And the last block matches if a part lacks a defined scale, and sets that to 1.

So for the parts in question, would not the first and third blocks fire, setting rescalefactor = 1.6 and scale = 1.0? I realize i'm entering the kracken's lair of KSP model scaling, but i'm just trying to get a handle on how it all works Thanks!

EDIT: so, I fixed my procedural fairings hack up there, so disregard that... Also, what i've just noted is that although the models have not rescaled, the attach nodes have. I'm trawling through the plugin code now, but i'm becoming more certain that is where the issue is. I will report back soon...

Soon: Yep, that was it. They do some clever gameplay trickery such that the built in RCS ports on the pod/nose cone are activated based on a tech tree limitation. If the tree requirements haven't been met, the ports are disabled, as well as their presence on the model itself. In sandbox mode the scaling bug does not occur.  I will ask nicely over on their thread what might be able to be done in the code to account for crazies wanting to rescale their parts   Thanks for your attention! (Although I probably will be back if I can't figure out what is going on with the procedural fairings... *grumble*)

Edited December 23, 2015 by komodo

[NathanKell]

Ah, good catch! And you're most welcome whenever.

As to the 1.6 vs 2 thing. Unlike scale, which defaults to 1.0 (and 1,0, 1.0, 1.0, when in a MODEL node), rescaleFactor defaults to 1.25. So multiplying that by 1.6 yields 2, so if no rescaleFactor is specified, and we want to scale up 1.6x, then we insert rescaelFactor = 2 (i.e. we scale up the implicit default 1.25 by 1.6x)

[ColKlonk]

(v1.05) Not sure whether this is RSS/RO or Mechjeb.. but I get what seems the wrong readings (MechJeb) for Dv in the VAB... I only get around 60% Dv of predicted (= estimated between SL and VAC wrt to approximate altitudes). It's not rocket science :-)

Any clues ?

Edt: Using RD-120s

Edited December 25, 2015 by ColKlonk

[komodo]

Ok, i'm flummoxed. I've been crashing heads with ProcFairings vs rescaleFactor for a few hours now. When their parts are rescaled, it goes a little haywire. The bases visually are not scaled, although the nodes are corrected. The blue lines signifying the projected fairing shape are correct as well, WRT to undersized fairing base, but not the nodes. When a side is attached, the enclosed shape is quite a bit larger than projected, although the 'true' base diameter is 'correct'. While I think it is possible to reshape them by hand, it somewhat takes the fun out of the procedural part

I surmise that this results from the PF module being able to freely scale its parts internally, and it's getting confused when adjusted externally... scaling methods clashing, etc.

Basically I want to adjust the ROMini config such that the rescale is not applied to parts containing their modules, but I have not been able to find a suitable incantation in the MM thread that is similar to what is needed.

What i've got currently is this:

@PART[*]:HAS[#rescaleFactor[*]:HAS[!MODULE[ProceduralFairingSide|ProceduralFairingBase|KzThrustPlateResizer]]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@rescaleFactor *= 1.6
}

The !MODULE block w/ the | I borrowed from a sarbian post, so I'm hoping that syntax is correct... While no errors are generated, a glance through the MMCache shows the parts with the rescaleFactor = 1.6 applied.
My intention with the code above is to naturally match all parts with a value for rescaleFactor, but not any parts which contain the modules indicated.

What I haven't tried is them in entirely separate HAS: blocks. Does that even make a difference? Let me try that real quick... Nope, results in the same behavior. Maybe if the order is reversed? No, that isn't it either... Although I didn't expect that to work if the original order did not.

Ideas? And a merry christmas, as well!

[NathanKell]

Can't do multiple HAS blocks like that, and can't do | in the MODULE.

You want:

@PART[*]:HAS[#rescaleFactor[*],!MODULE[ProceduralFairingSide],!MODULE[ProceduralFairingBase],!MODULE[KzThrustPlateResizer]]:FOR[zROMini]:NEEDS[!RealismOverhaul]

[SnappleTap]

I'm new to RO, but enjoying it immensely (my math-nerd side is taking over).

I've built a rocket which I believe can make it to orbit, but I have a problem. The first stage goes off well enough, but whenever I try to ignite a stage after that I can't because the engine is vapor-locked. What causes this? How do I avoid it? I've heard of ullage, but I was moving about 500 m/s at the time so this doesn't seem like it...?

[leudaimon]

4 hours ago, SnappleTap said:

I can't because the engine is vapor-locked. What causes this? How do I avoid it? I've heard of ullage, but I was moving about 500 m/s at the time so this doesn't seem like it...?

Ullage has no relationship with your speed, but acceleration. Use a couple of separation motors in your second stage, and fire your main engine right after the separation motors, while the motors are still firing.

[NathanKell]

Yep, or hot stage (ignite the next stage, but don't decouple, while the lower stage is still burning (at about 2-3s of burn time left); decouple when the lower stage burns out.

[leudaimon]

2 hours ago, NathanKell said:

Yep, or hot stage (ignite the next stage, but don't decouple, while the lower stage is still burning (at about 2-3s of burn time left); decouple when the lower stage burns out.

Btw, I tried that sometimes, but with closed interstage fairings it doesn't work (it fails and says that the engine doesn't work while stowed). Is there any way to have a structurally strong rocket and use hot staging? Because if I use regular structural decouplers with larger rockets they tend to break apart.

[NathanKell]

As of RO 10.7.2 you should no longer have that issue. Make sure you're up to date.

[SnappleTap]

On 12/29/2015 at 5:15 PM, leudaimon said:

Btw, I tried that sometimes, but with closed interstage fairings it doesn't work (it fails and says that the engine doesn't work while stowed). Is there any way to have a structurally strong rocket and use hot staging? Because if I use regular structural decouplers with larger rockets they tend to break apart.

Thanks! Hot staging works for me. Haven't tried the small boosters yet but I imagine they would as well.

Still haven't made it to orbit, but I'm one step closer. The biggest issue now seems to be getting my dV/TWR in the right range. I don't mind crunching the numbers (I do love a good math) but for some reason it takes a ton of fiddling with fuel quantities in different stages to get even close to the dV I want. I think that this is because I'm using the wrong engines/fuels (kerosene/liquid oxygen [kerolux? Is that the right terminology?] for the first stage, hydrogen/liquid oxygen [hydrolux?] for the second stage, hydrogen/liquid oxygen for the orbital stage).

Just discovered Ferram's launch-vehicle tutorials on the wiki- we'll see if that gets me any closer to the stars.

Edited December 30, 2015 by SnappleTap

[komodo]

If using procedure parts for tanks, perhaps instead of varying the fuel load, resize the whole thing? 

If using discrete parts, well... Hm. I'm less sure. In any case realfuels should offer you a button to fill the tanks with the appropriate fuel/ratio for the engine in use. Combined with the numerical entry option (vs finicky sliders), it should get you going I'd think. Is it perhaps a atmospheric dV vs vacuum dV thing? That often gets me. Kerbal engineer and mechjeb both should have both read outs. It does take some feel for it to get the balance right, even more so in RSS.

good luck!

[Requia]

how do I delete this...

Edited December 30, 2015 by Requia

[komodo]

On 12/26/2015 at 3:47 PM, NathanKell said:

Can't do multiple HAS blocks like that, and can't do | in the MODULE.

You want:

@PART[*]:HAS[#rescaleFactor[*],!MODULE[ProceduralFairingSide],!MODULE[ProceduralFairingBase],!MODULE[KzThrustPlateResizer]]:FOR[zROMini]:NEEDS[!RealismOverhaul]

Yep, that did the trick! Thanks! It was a 'I coulda swore I tried that combo..."... I thought I could get away with the prior syntax due to This example, from the boss himself, but the context of the syntax may be different than I had thought.

Man, these rockets work a lot better with fairings on them, don't they?

[oktav]

I am having some difficulties with RO and RSS.. I am having the same issue with the minimal possible amount of mods and both in Linux and Windows.

I am trying to do my first orbital satellite but as soon as the rocket starts the gravity turn something weird happens, my roll indicator starts going nuts and starts pointing in one direction and switches every now and then

It makes it impossible for me to send the rocket straight, it uses all the gimbal and wings to make the rocket rotate even though I am not touching anything in the keyboard, nor the mouse and there is no controller attached!

In the picture I was trying to keep it straight pressing E to counter the rotation.. but it's practically impossible. I can provide a video in case it's needed.

 

 

But if I remove all the mods and create a similar rocket in stock with FAR and other mods to make it similar (or also pure stock) I don't have this behaviour...