Realism Overhaul Discussion Thread

[SnappleTap]

13 hours ago, komodo said:

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!

Yes, resizing works much better. And MechJeb's dV readout helps immensely (before I was calculating mass and ISP and using those to calculate dV- a little bit time consuming). Plus, Ferram's launch vehicle tutorial helped me figure out which engines to use. And now that I know the TWR that I need for each stage, I can use basic physics to calculate the kN range that I need engines to be for future rockets. Finally put my first satellite into orbit!

RO makes a world of difference (see what I did there?). With stock KSP physics I would just build whatever I wanted, stick the biggest rocket I could make stable under it, and shoot away. It got almost... Boring. RO may be many things (a good way to lose hair comes to mind), but never boring.

Anyway. For the moment I'm working on my first manned mission. I'm sure I'll have more dumb questions later, but for the moment I'm happily building away. Thanks for your help!

[Apexazimuth]

Hi, my name is Apex and i'm an RO-holic.

I've been playing KSP since 0.22. I started an RO/RP-0 career a few months ago and it's changed the way I look at spaceflight and rocketry, and forever spoiled stock-KSP for me.

I tried going back to stock-KSP recently after I accidentally saved my game after unknowingly updating to 1.0.5 (Damn you Steeeaam!).  Since RO/RP-0 was on hiatus for a while, I tried stock KSP with some graphics overhauls because eyecandy.  I found myself watching my orbital velocity climb to 2400 m/s and instinctively, passively thinking; "Ok, still have a ways to go, looking good".  Then I'm interrupted by a "world first orbit" contract only mere seconds later.  "This... Is like a baby's toy.." I thought to myself.

Now I can't go back to stock-KSP and take any accomplishment seriously because landing on the Mun isn't even as hard as reaching orbit around Earth.   And landing on the REAL moon?!  Apollo was always spectacularly impressive to me, but after doing it in RO/RP-0, I have a wholly different understanding of the miraculous achievement humanity undertook with Apollo.  Then I have to realize that RO is as much a simplistic caricature of real life as stock KSP is to RO, and I'm even more impressed.

Since playing with RO, I've found myself obsessively indulging my curiosity about the chemistry of different rocket fuels, the physics of supersonic flow, and even the electrical and computer systems of 1960's era spacecraft.  I'm ever more interested and curious about spaceflight.  RO has realized the educational magic of KSP for me.  Stock KSP is like the pre-school version of rocket science, but it got me familiar and interested in the basics.  RO is training wheels off, where we learn what the REAL challenges of rocketry and spaceflight are.

I hope one day RO gets integrated into the base game as sort of a "Manley" mode that users can unlock after a certain point of progression in the stock career mode.

 

TLDR:  I LOVE this mod!  This is a game of its own.  THANK YOU THANK YOU to all of you hard-working modders that have brought this magic to life.

 

[NathanKell]

Posts like that keep me going. So glad you're getting so much out of RO, it's the best I could ask for.

[MissMolly]

Hey Nathankell

i just got you mod with Rss and it looks so cool but when I launch my engine fire burn for a few seconds then go out. My SRB's are running fine but my mains die. Something about ignitions or along the line. 

[Activity]

50 minutes ago, MissMolly said:

Hey Nathankell

i just got you mod with Rss and it looks so cool but when I launch my engine fire burn for a few seconds then go out. My SRB's are running fine but my mains die. Something about ignitions or along the line. 

You need ullage motors or hot staging to settle the propellents in their tanks.

[MissMolly]

ok thanks 

 

as I'm new to RO what is hot staging i did some looking on line but it seems if i do what it stats theres going to be some fried Kerbals, I'm still get some info together so i can enjoy it fully. I'm going to try this today some time and hope for the best.

 

thanks again.

[NathanKell]

@MissMolly whenever you throttle an engine back to 0%, it shuts off. Engines in real life (and thus RO) have limited ignitions, so once you shut an engine off you probabyl can't turn it back on again. That's why you were getting the "no ignitions remaining" messages. Note that if you have an autopilot mod (like MechJeb) make sure you've left turned off any throttling options (like Maintain Acceleration, or Limit Dynamic Pressure) since they don't realize that throttling an engine to 0 is bad in RO.

In order for an engine to start and/or keep running, you need to make sure that only propellant (and not pressurant vapor) is in the feedlines. To do this, the engine and the tanks need to be under, or recently under, positive acceleration. You can do this as mentioned above: via ullage rockets that fire before and during ignition (solid or RCS), by firing the next stage while the lower stage is still firing ("hot staging"), or by having sufficient cryogenic boiloff vented out the rear that positive acceleration is maintained.

This tutorial covers that sort of thing, I believe: https://github.com/KSP-RO/RP-0/wiki/Tutorial:-Reaching-Orbit

[MissMolly]

11 hours ago, NathanKell said:

@MissMolly whenever you throttle an engine back to 0%, it shuts off. Engines in real life (and thus RO) have limited ignitions, so once you shut an engine off you probabyl can't turn it back on again. That's why you were getting the "no ignitions remaining" messages. Note that if you have an autopilot mod (like MechJeb) make sure you've left turned off any throttling options (like Maintain Acceleration, or Limit Dynamic Pressure) since they don't realize that throttling an engine to 0 is bad in RO.

In order for an engine to start and/or keep running, you need to make sure that only propellant (and not pressurant vapor) is in the feedlines. To do this, the engine and the tanks need to be under, or recently under, positive acceleration. You can do this as mentioned above: via ullage rockets that fire before and during ignition (solid or RCS), by firing the next stage while the lower stage is still firing ("hot staging"), or by having sufficient cryogenic boiloff vented out the rear that positive acceleration is maintained.

This tutorial covers that sort of thing, I believe: https://github.com/KSP-RO/RP-0/wiki/Tutorial:-Reaching-Orbit

Thanks Nathankell ill give it another go bit later i had a ton of problems with it to day.

[MissMolly]

Thanks again Nathankell the link you post is working out with a few part differences but achievable, just one this i get to about 1500m with the first stage but the engine cut out with a message vapour in feedlines. how do i fix this?

 

Also the craft thats in the tutorial that i made will only fly to 4400m then shut down with over ¾ of the fuel left am i missing some thing.here is my craft file if you want to take a look 

https://www.dropbox.com/s/cp0i7f193x7tiqu/Sol%201%20MKI.craft?dl=0

Edited January 1, 2016 by MissMolly

[NathanKell]

Can you post an image of your craft? That message means that you probably had high drag and not enough thrust to counteract it, so had negative acceleration and thus the fuel 'sloshed' to the top of the tank.

[MaxL_1023]

You can also get this when turning - if you try and pitch too quickly you can briefly get negative acceleration at the engine and get vapor problems. 

If your engine shuts down with 3/4 fuel and no vapor message, you are probably using an incorrect propellant mix. For example, your engine might want 65/35 of something while you have it reversed, meaning you run out of one propellant type quickly and leave a large amount of the second remaining. Double check that your engine requirements are met by your fuel tanks, and no non-crossfeed parts are blocking fuel flow (the A4 guidance unit is bad for this).

[PLAD]

  I like the lower H2 boiloff rates! Back in 0.90 I'd lose roughly 5% of my H2 in one orbit of Earth, now I lose the same 5% in the typical 4 days it takes to get to the Moon. This means that LH/LOX is now practical for Moon missions! Now I can use the nice selection of H2/O2 engines that RO offers for a lot more, especially the throttlable CECE variant of the RL-10, and the RL-60.
   So now I've redesigned my old Moon ships to see what LH2 can do. I tried big RL-10 landers but it is awkward with those huge LH tanks, in my largest the crew has to go down 10 meters of ladders to get from the cabin to the surface. (Reminiscent of the proposed Altair lander from the 2000's.) That seems too dangerous to me, as does the high cg at landing when the H2 tanks are empty. Then I found this Lockheed-Martin paper on concepts for landing LOX/LH on the Moon. The best idea to me is to use an efficient but unthrottleable cryogenic motor to decelerate out of Lunar orbit, then switch to small throttleable Aerozine/NTO for the last few hundred m/s, when the ship is much lighter. Ideally the same stage would do the TLI (3200m/s), the LOI (900m/s), and the descent (1900m/s), but the loss of about 220m/s of dV during the flight to the Moon puts the stage dV at 4300m/s before descent, and I found that past about 5200m/s there's usually no further savings. So I can either have the storable (low-isp) stage do the last 900m/s, or split the L2/O2 into 2 smaller stages of 3200m/s and 2600m/s with the landing motor doing about 300m/s. But the extra staging parts reduces the benefit of this. And if I'm landing near an asset I have to worry where the discarded H2 stage falls. It's all fun to test out.
    I keep an album of my experiments here. The thought of a 'lowest mass piloted Moon mission in RO' challenge is intriguing, but the huge variety of installs we have would make it tough to compare approaches.
    
PS: They call it a "Dual Thrust Axis Lander", but I call it a "Space:1999 Eagle".

PPS: I wrote a spreadsheet, "Moonfinder", that gives you the next launch windows to the Moon from any higher-latitude site (including Canaveral). Now you don't have to guess. It's at the end of the FF for RSS first post.

 

[MissMolly]

so here are them photos 

https://www.dropbox.com/s/byg8ehex3li9awm/screenshot0.png?dl=0

https://www.dropbox.com/s/vwa84gikykzfg52/screenshot1.png?dl=0

https://www.dropbox.com/s/f5nkyoq9bfj8a25/screenshot8.png?dl=0

https://www.dropbox.com/s/ql44ewe29pn23yq/screenshot9.png?dl=0

[MissMolly]

@PLAD nice Album i can wait till i can go to the moon. I'm still trying to get in to LEO, I'm making my first launch today t-120m testing today.

@NathanKell love the mod but WOW its hard but i think thats why we like it getting in to, space is suppose to be, and that much more rewarding in the end.

[Sanic]

RealPlume never works for me, so I guess I am running on lqdmagic for now. Well, kerosene fueled engine's plumes work fine.

[NathanKell]

@MissMolly you have "Limit Q" checked. That's what I meant above with turning off "Limit Dynamic Pressure" (Q is the symbol for dynamic pressure). Uncheck it and the problem should go away.

[MissMolly]

@NathanKell ok i thought "Limit Q" was better then "limit acceleration to i.e..18 m/s as of the kerbin way but i know that all i know from being on Kerbin is wrong on Earth.

I'm still trying to get that ship into orbit in the sim it works, but when i launched it blew up. "jeb was happy to see this" 

[NathanKell]

@MissMolly You don't want to be limiting acceleration, not least because your engines do not throttle at all so you can't limit acceleration. When MechJeb tries to limit acceleration, as you see it ends up shutting your engine down.

Here's some useful "conversion tips" for going from KSP to RO: https://github.com/KSP-RO/RealismOverhaul/wiki/False-KSP-Lessons

[komodo]

Right! So! Brainstorming time!

It's not a big secret that i've been poking around the ROMini.cfg, seeing what limits can be stretched there. A big limitation it appears to have vs its big sibling is the scaling bugs. The rescaleFactor != 1 for root parts one in particular. I digress. Inspecting full RO configs shows judicious use of scale, rescaleFactor, etc, to work around this.

While the ROMini method of uniformly scaling parts up by 1.6x is a crude approximation, it does get the job done if absolute realism isn't the desired goal.

Alright, having said all that, the brainstorming: MM 2.6.16 is very new off the press, but it has a promising new feature, the addition of vector arithmetic to the toolbox. (See relevant github link) My thought (and the authors, in particular!) was to avoid the use of rescaleFactor by applying the scaling to the MODEL nodes, (or just scale = foo if the old mesh = bar variety), which has the detrimental side effect of not scaling the attachment nodes in 1.0.4/5. So they're often trapped in the now larger model. Boo!

So I thought to myself: "node definitions are basically keys in the PART{} module, right?" (One dimensional array? 1x7 matrix? all the same, really.)  And, well. It almost worked. (The most frustrating kind of working!)

What happened was that the following code did apply to some nodes correctly, but others wildly incorrectly. It took a little bit to figure out the pattern, and I still don't quite understand it. So, the snippet.

Spoiler

I'm trying to match all node_* instances in module PART, and of those matched, apply a scalar to the first indexed value in the key. The default separator is already a comma, so we don't have to specify it. The additional two lines, [1],[2], should do the same thing, but on the second and third indexed value respectively.

@PART[*]:HAS[@MODEL]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	testnode = #$rescaleFactor$
	@node_*,*[0] *= #$rescaleFactor$
	@node_*,*[1] *= #$rescaleFactor$
	@node_*,*[2] *= #$rescaleFactor$
}

Where rescaleFactor was defined earlier as

@PART[*]:HAS[#rescaleFactor[*]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@rescaleFactor *= 1.6
}
@PART[*]:HAS[~rescaleFactor[]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	rescaleFactor = 2.0
}

Hardcoding a *= 1.6 scalar gave identical results. (That's why that testnode is in there, so I could hopefully see what the variable was set to at this step. (It was 1.6, or 2))

If the node was defined explicitly, e.g., @node_stack_top, it would apply and fail (as described below) for that node specifically, and not act on any others.

I fully admit that this is horrible code that likely wouldn't even work before two days ago. The best way to learn is to try it, so I did.

What I observed was that for the last defined node_* in a config, the scalar that was applied was *insane*. I had numbers anywhere from 100000 to 25 mil. The ratios of the values in a given node were proportional to their original values, however.

That is, only node n, in nodes 1, 2, 3, n-1, n was mangled. The other keys had the scalar applied appropriately. I was not able to determine a common factor or mathematical operation that would result in the hugely inflated values. I suspect that however it worked is by luck and not design, vis a vis the syntax MM expects.

I'm not looking for a precise answer or debugged code, but instead for more general thoughts if this is a valid avenue to pursue. (Thoughts on the code are welcome too, of course! ) If valid, i'll keep poking at it until I get a reproducible enough case to bring over to the MM side of things. It might just be the code isn't quite able to do this sort of thing.

It's also getting to that cross-eyed, late at night stage of coding/debugging, where it's a good idea to put it up until the morning. Have a pleasant night, all!

(I'll try to get some specific examples up in the morning, concrete numbers are always nice, right?)

Edited January 3, 2016 by komodo
Postscript

[MissMolly]

15 hours ago, NathanKell said:

@MissMolly You don't want to be limiting acceleration, not least because your engines do not throttle at all so you can't limit acceleration. When MechJeb tries to limit acceleration, as you see it ends up shutting your engine down.

Here's some useful "conversion tips" for going from KSP to RO: https://github.com/KSP-RO/RealismOverhaul/wiki/False-KSP-Lessons

ya i figured as i red one of the first posts you sent the other day (face in hand) i have red the info you link it has helped a lot thanks, the tut craft can it make it in to orbit? if so how  i can't keep it on a heading of 90º and 15-0º pitch @ 135km. let alone the lack of ∆v. if this craft can make it ill keep at it maybe ill recored it to see what I'm doing wrong just a thought.

so i think i may have figured part of my question out, i just need it verified, if i need 6400.9 m/s worth of ∆v is it safe to add all of my ∆v from all stages left? i.e stage 5 has 2450 stage has 450 and last has 100 to = 3000 m/s? 

Edited January 3, 2016 by MissMolly

[MissMolly]

Hey Nathankell

i think i found a bug. i hope this is where I'm to put it. this has been happening on and off today.

 null @PART[FASASaturnUllage]:FOR[RP-0] Config(@PART[FASASaturnUllage]:FOR[RealPlume]) RealismOverhaul/RealPlume_Configs/

this does seem to be the same in all my crashes.

 

heres the player log please let me know if it is or not or if its KSP it self i only have the mods Ckan put in under RSS and RO.

https://www.dropbox.com/s/dutcgt0pukoxfau/Player.log?dl=0

Edited January 3, 2016 by MissMolly

[Phineas Freak]

It looks like a memory - related crash (out of memory and/or memory corruption). Are the crashes exactly the same regarding parts or actions?

Edited January 3, 2016 by Phineas Freak

[MissMolly]

28 minutes ago, Phineas Freak said:

It looks like a memory - related crash (out of memory and/or memory corruption). Are the crashes exactly the same regarding parts or actions?

no there not other then @PART[FASASaturnUllage]:FOR[RP-0] Config(@PART[FASASaturnUllage]:FOR[RealPlume]) RealismOverhaul/RealPlume_Configs/

 i can't see how its mem as i have 26gigs heres the other log file https://www.dropbox.com/s/85kqpzgrukl7hwc/Player2.log?dl=0

[Requia]

The configs for the CryoEngines J-2 aren't the same as the SXT J-2 (more powerful and lighter).

 

In the interest of not breaking my launch vehicles when this next updates, which is the correct version? Looking up J2 specs I can't actually find a version with a vacuum thrust less than 1MN, which suggests the newer CryoEngine config.

[Phineas Freak]

@MissMollythe 26 GiB of RAM won't do any good since KSP only uses 4. Also, have you tried removing part mods to see if it is different? Macs unfortunately don't have a great "relationship" with KSP.

@Requia the J-2 should have the following parameters:

Dry mass: 1560 Kg
Thrust (VAC): 1023 kN
ISP (ASL): -
ISP (VAC): 424 s

But in  your case, you are trying to compare the original J-2 (used on the S-II, S-IV and S-IVB stages) with the J-2X (proposed for the Ares I insertion stage and the Ares V EDS). The two engines have nothing in common except for the name.

Keep in mind that in the next Realism Overhaul release (probably) all engine configurations will be unified, so any launch vehicle stats might get broken anyway.