ferram4 changed the topic of #RO to: Welcome to the discussion channel for the Realism Overhaul (meta)mod for KSP! Realism Overhaul Main Thread https://goo.gl/wH7Dzb ! RO Spreadsheet http://goo.gl/Oem3g0 ! Code of Conduct http://goo.gl/wOSv2M ! | Maximal & soundnfury's RP-1 Race Into Space Signup: http://bit.ly/2DEVm2i [15:01] <soundnfury> Straight Eight Stronk (and) RP-0/1 is basically "Space Agency Spreadsheet Simulator"
<soundnfury>
zilti: what, tides? I don't think those are supposed to happen, I think the sea level just glitches around sometimes.
<soundnfury>
but idk, there might be for all I know
Hypergolic_Skunk has quit [Quit: Connection closed for inactivity]
stratochief has joined #RO
<zilti>
soundnfury: ...yeah definitely a glitch.
<lamont>
global warming
ProjectThoth has joined #RO
<xShadowx|2>
this is RO, how could it be RO without global warming ;)
<blowfish>
!tell camlost* I think you didn't update the .version file again
<Qboid>
blowfish: I'll redirect this as soon as they are around.
<schnobs>
It looks as if someone had just taken some real-life thrust curve and imported it.
<schnobs>
The curves you find on the web (or anywhere, really) plot thrust over time.
<schnobs>
However, Real Fuels uses thrust vs remaining fuel.
<schnobs>
See how thrust diminishes to zero as fuel runs out?
<schnobs>
The less fuel there is, the slower it will be consumed...
<schnobs>
The resulting thrust/time curve is bound to have a very long tail. infinitely long.
<Maxsimal>
Is that plot you showed thrust vs time or thrust vs remaining fuel? Or thrust vs 1-remaining fuel?
<schnobs>
Strictly speaking, the plot is just the data we have in the RealFuels Engine config.
<schnobs>
key = 0.00845 0.207
<schnobs>
key = 0.00649 0.169
<schnobs>
key = 0.00484 0.142
<schnobs>
<schnobs>
and so on.
<schnobs>
I've plotted it as X,Y pairs, then had an algorithm connect the dots.
<Maxsimal>
Gotcha. Yeah, looking at the real engine's curve, it's definitely the rocket moving right to left over time if it matches the real data
<schnobs>
RealFuels interprets that data as key = (thrust) (fuel level)
<schnobs>
ouch. stop
<schnobs>
It's the other way round: key = (fuel level) (thrust)
<Maxsimal>
Yeah I don't see how that works out at all. So if you tell RF that this thing burns for 130 seconds like the real one, it always ends up burning for something well over that because thrust is always less than 100%?
<schnobs>
Yes. No.
<schnobs>
You put it in the game, note how long the burn time is, then adjust thrust to fit.
<schnobs>
because doubling thrust will still halve the burn time.
<schnobs>
And, having a closer look, it's not as bad as I thought: this engine maintains <10% thrust down to 2% fuel, so it pretty much *does* get there.
<schnobs>
Or does it?
<schnobs>
I know from using these things that it takes a long time for them to spool down. Over the course of like ten seconds, it's not clear whether it's safe to stage them yet.
VanDisaster has quit [Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/]
<schnobs>
This one tapers out but does eventually shut down.
<Maxsimal>
Yeah because it's always above 0
<schnobs>
Maxsimal: note how thrust exceeds 100% a few times.
<schnobs>
In a nutshell, the given "thrust" figure for SRBs is of limited utility.
<Maxsimal>
Yeah - it looks like what RF should be doing is taking the thrust vs time curves from the real world, and then integrating them to produce for itself a thrust vs remaining fuel curve so that it can then just thrust vs remaining fuel since I guess it (for some reason) can't keep track of how long it is since an SRB started firing.
<schnobs>
The Castor Curve closely matches #3, including the long tail.
<schnobs>
Maxsimal: I'm not sure if RF could do this, at reasonable effort or at all.
<schnobs>
But we can integrate the data ourselves and only need to do it once, when drawing teh thrust curve.
<schnobs>
The Castor is an example of a job well done. The tapering out looks like a straight line in thrust/propellant, but as it plays out in thrust/time you get the curved slope from the diagram #3.
<lamont>
which version of MJ and what is in the PEG ascent path window?
<lamont>
and delta-v stats window would be useful as well
<zilti>
lamont: the latest on CKAN for 1.3.1
<lamont>
generally though that’s why i added the manual launch azimuth window to PEG — because its not an actual trajectory optimizer, and can’t reliably converge on the launchpad (and was never designed to do that) so sometimes you have to manually enter the launch azimuth
<lamont>
oh yeah, old PEG
<lamont>
it is probably disco balling because it can’t converge
<zilti>
Thing is, it would be easily countersteerable, but MJ doesn't even try. Actually MJ fights me when I steer closer to the actual trajectory it is supposed to fly. Also I have to say I don't understand all parameters yet; e.g. "Corrective steering Gain", would that what I need to change?
<lamont>
PEG doesn’t use corrective steering at all
<lamont>
that button does nothing
<lamont>
(i have a TODO item to overhaul the UX and make it go away)
<lamont>
its been too long since i’ve looked at that version, so i don’t know what could fix it on that version short of moving forwards to shuttle PEG
<lamont>
i think i’ll do a backport of current MJ dev today and re-release the shuttle PEG code
<zilti>
Also, is this correct that MJ does no steering at all during the "Vertical Ascent" phase? I'll try the one you linked later
<zilti>
Yeah definitely no steering happening during Vertical Ascent
<lamont>
vertical ascent is vertical. although it should roll properly to align the body axis for rockets that aren’t symmetric around their roll axis
<zilti>
Well, it definitely does no steering at all to keep the rocket pointed up here
<schnobs>
lamont: is there a writeup of what PEG does (or tries to do), somewhere?
<lamont>
yeah particularly the newer stuff doesn’t need “num_stages” at all any more and it just calculates the dV left in the burn and walks up your rocket stack to find that much dV
<schnobs>
Asking because it worked well for me, until I started to introduce restartable upper stages, which were supposed to have enough dV for (say) TLI after making orbit.
Hypergolic_Skunk has joined #RO
<lamont>
in old-PEG you have to make sure that num_stages gets bumped to include your TLI stage, in new-PEG it just handles that
<lamont>
but
<lamont>
if your TLI stage is low-TWR both may have issues
<lamont>
old PEG you may wind up not being able to use it
<camlost>
can someone tell me what's the difference between RP-0 and RP-1?
<Qboid>
camlost: blowfish left a message for you in #RO [16.04.2018 01:22:58]: "I think you didn't update the .version file again"
<lamont>
new PEG it should still converge but if you don’t loft it enough manually it may not find orbit (the burning straight down thing which happens when phi = 45.0 at 40.0 seconds tgo)
SirKeplan has quit [Ping timeout: 186 seconds]
<awang_>
camlost: RP-0 is what's currently out, RP-1 is a (nick)name we sometimes use for the upcoming version of RP-0
<awang_>
The increment is because the new version is drastically different from the current one
<awang_>
So RP-1 = RP-0 dev
<awang_>
RP-0 = sometimes RP-0 dev, sometimes RP-0 1.2.2/1.3.1
<camlost>
awang_: i see
<schnobs>
Pap: regarding avionics, the problem are pre-fab vessels.
<schnobs>
FASA Redstone, Atlas and Titan have no dedicated avionics parts for the user to place on the model.
<schnobs>
So the tanks themselves are supposed to include the avionics.
<lamont>
schnobs: +1
<schnobs>
This gives the user the ability to build and launch Titan rockets without ever investing in avionics.
<lamont>
oh heh, yeah, i was wondering how pre-fabs with a bunch of different technologies in the part would only unlock when all the technologies were met
<schnobs>
(though probably not all that bad: one still needs avionics research in order to get a worthwhile payload)
<schnobs>
lamont: I call it the "Gemini Conundrum".
Olympic1|Work has joined #RO
<lamont>
the RSB common centaur core has a pile of different stuff wrapped in one single part
<schnobs>
Gemini service module has advanced RCS, Fuel Cells, and LOX->O2 converters.
<zilti>
Oooh I get some fancy vectors in the game world with the Shuttle PEG?
<lamont>
sorta?
<lamont>
they’re really debug vectors, and i think i’m the only one that can really translate them
<lamont>
the important ones are actually in the map view which is the vp and vd vectors at the rp and rd locations — predicted and desired velocity and position — with the velocity multiplied by some large constant factor so its easy to see.
SirKeplan has joined #RO
<lamont>
at launch there’s clipping involved when phi is clipped at 45.0 or else the algorithm mathematically doesn’t converge so you’ll see two parallell vectors. the difference in those vectors is the rbias term which is caused by the clipping.
<schnobs>
So what's the right tech to unlock the Gemini Service Module? RCS, or Electrics (for fuel Cells) or Life Support (for the converter)? Is it necessary to have dependencies on each?
<lamont>
if rbias never goes to zero and those vectors never match up then you’re going to have a happy outcome.
<zilti>
I get two parallel lines in map view, a red and a greenish one
<lamont>
yeah
<lamont>
that’s what i’m talking about
<lamont>
those should merge and become yellow
<zilti>
Ahh yes, they're getting closer
<lamont>
its probably more useful, as a player, to try doing a launch to a 90 degree inclination and then play around with “leading angle to plane” — put in 1 or 2 or -1 or -2 there instead of 0
<lamont>
you should see those lines jump around eastwards or westwards
<lamont>
which is a nice graphical explanatin of “leading angle to plane"
<lamont>
if you put 0 in there you will target the plane of KSC when you launch, which is more expensive than allowing the rocket to drift a bit east and more gradually zero out the coriolis velocity
Addle has quit [Ping timeout: 190 seconds]
<lamont>
put 1 or 2 in there and it’ll shift those lines eastwards
<zilti>
"target the plane of KSC" meaning that it is above the KSC after one orbit?
<lamont>
no
<lamont>
KSC will rotate with the earth
<lamont>
so picture the non-rotating inertial earth-centered coordinate system. slice a plane through KSC at the time of launch.
<lamont>
it will target that plane.
<lamont>
so once you launch you immeidately start moving away from your target at 400 m/s and then have to burn back west in order to find it again — which incurs dV expense
<zilti>
Ah, that way. Yes, I see.
<zilti>
Hmm well that was a perfect ascent with the Shuttle PEG.
<lamont>
for eastward 28 degree launches it doesn’t matter
<lamont>
yeah shuttle PEG is better than the atlas-centaur PEG
<lamont>
it still has confusing edge conditions though
<lamont>
and i have to explain all that stuff about leading angle to plane
<zilti>
Perfect as in Apoapsis of 151km and Periapsis of 150.5km without a circularization burn
<lamont>
yeah
<lamont>
if you’ve got RCS on the stage it should be better.
<lamont>
although i think i’ve got unpushed work which will make it even better
<schnobs>
lamont: I'd have a wish...
<lamont>
again, i need to do another release
<lamont>
schnobs: ?
<schnobs>
in early RP-0 career, it would be nice if once could have a kinda-sorte PEG thing to lob the first stage to X altitude.
<lamont>
fah yeah
<lamont>
ah ykeah
<lamont>
fuck typing
<lamont>
yes
<lamont>
PEG can’t do that at all
<lamont>
it does a very restrictive orbital insertion with fixed altitude, velocity, inclination and flight path angle and that’s it
<lamont>
i realized the other night that i know enough now to write a basically perfect vacuum trajectory optimizer (and can even add variable ISP effects from an atmosphere — but aero forces and path constraints are a bit hard). that means i can replace PEG with something substantially better without all its approximations. and in the process i can do different kinds of terminal conditions. and i’ve got the math which will optimize a traject
<lamont>
to an altitude, inclination and flight path angle for a fixed burntime which will optimize the orbital energy of the burn.
Olympic1|Work is now known as Olympic1
<lamont>
and that solves the “i’ve got 8200 dV and I want to get to 145 km with 0.5 degree of upwards flight path angle and the maximum velocity possible” early RP-0 problem
<lamont>
it’ll also work in kerbin’s idiotic gravity well and can optimize coasts and can optimize coasts inserted optimially into the middle of relightable stages
<lamont>
so i’m working on that
<lamont>
(which is why PEG development has been largely halted lately — i’ve been teaching myself trajectory math in matlab)
<schnobs>
well... for starters I'd be happy enough if it tipped over smoothly to begin with.
<schnobs>
In my KOS scripts, I made it tip over to (say) 70deg by the time I reach 250m/s -- slowly at first, faster later.
<schnobs>
Though it was a simple algorithm (something SQRT-based IIRC) it looked very convincing and naver deviated from actual prograde very much.
<schnobs>
The current °/s approach of MJ is rather crude in comparison.
<lamont>
heh, well i want to fix that with real trajectory optimization, so far though constant pitch rates haven’t been too far off
<zilti>
Oh wow. Now according to MJ my orbit has degraded to 165x145km. Thanks, Principia
<lamont>
it hasn’t
<lamont>
that’s Earth’s J^2 effect and you’re looking at the keplerian tangent orbit to your actual orbit
SirKeplan has quit [Ping timeout: 182 seconds]
<lamont>
you need to look at what principia’s actual orbital integration in the map view is telling you
<lamont>
again, if yoiu want to play with principia you have to understand that concepts like “apoapsis” and “periapsis” start getting very fuzzy
<zilti>
Well the satellite definitely went down to 145km altitude. Where is that actual orbital integration shown in the map view?
<lamont>
that’s the purple lines
<zilti>
Also I love how the part positions are off, except for in time warp where they jump back to their correct position