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.
<blowfish> hmm
<blowfish> I know I've seen that before but not sure I remember the cause
<blowfish> ohh
<lamont> i ran into issues with KSP 1.4 so i’m back on KSP 1.3.x and v2.1.1 of that repo from Jan
<blowfish> the directory containing the KSP dlls should only contain those DLLs, not System etc
<lamont> ohhhhh, i’m just pointing it at at game dir
<blowfish> yeah, I think I had issues with that
<lamont> that could definitely Be A Thing
<blowfish> I think that causes it to build against the KSP versions and then run against the non-KSP versions
<lamont> can you give me an `unzip -l KSP_DLLs.zip`?
<lamont> ah, nm, i found it in travis output
Felger has quit [Read error: Connection reset by peer]
<blowfish> I should probably think about a better solution at some point
<blowfish> I think this only works because KSP has DLL signing off
<blowfish> although I don't expect that to change, if DLL signing was on a lot of things would break
<lamont> now i wonder if mono 5.10.0 is too new
<blowfish> lamont: I have been using it without trouble
<blowfish> well, without trouble aside from some weird warnings
<lamont> that’s what i’m getting now off of master w/KSP-1.4.2 libs + mono 5.10.0.160 that i just installed
<blowfish> ugh, I'm glad camlost came back to work on AJE, but it would be nice to have some consideration for the stuff I've set up in the mean time
<blowfish> lamont: did you add the reference path to the build command?
<blowfish> should be msbuild /p:Configuration=Release /p:ReferencePath=/path/to/ksp/dlls solution.sln
AmbulatoryCortex has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
SirKeplan has quit [Ping timeout: 383 seconds]
<lamont> yep
<lamont> msbuild /p:Configuration=Release /p:ReferencePath="/Users/lamont/test/ksp/" B9PartSwitch.sln
<blowfish> and that contains Assembly-CSharp.dll etc?
<blowfish> huh, I guess it does based on the output
<blowfish> that's really weird
aradapilot has quit [Remote host closed the connection]
aradapilot has joined #RO
<blowfish> lamont: don't think it's an OS issue either. I can compile fine on my OSX work laptop
<lamont> hrm
<lamont> weird
<lamont> this is an OSX rev behind so 10.12 or whatever…
<lamont> and i’ve got multiple mono’s installed
<blowfish> should be ok, it seems to be referenceing the right one
<lamont> yeah ckan + nuget are wired up to the other one, which makes it difficult to uninstall
<lamont> (mono 5.4 in homebrew)
<blowfish> maybe make sure `which msbuild` is pointing to the right one?
<blowfish> although hmm, that actually shouldn't matter
<lamont> % which msbuild
<lamont> /Library/Frameworks/Mono.framework/Versions/Current/Commands/msbuild
<lamont> mono is there as well
<lamont> something is weird
<blowfish> ohh
<blowfish> ohh
<blowfish> I didn't read your thing closely enough
<blowfish> You must add a reference to assembly 'UnityEngine.CoreModule...
<blowfish> lamont: I know what's wrong
<blowfish> for some reason the OSX distribution of KSP splits up the Unity DLLs
<blowfish> this is super annoying
<blowfish> you need the UnityEngine and UnityEngine.UI from somewhere else
<lamont> lol
<lamont> % find . -name UnityEngine.UI.dll
<lamont> ./KSP.app/Contents/Resources/Data/Managed/UnityEngine.UI.dll
<lamont> ./Launcher.app/Contents/Resources/Data/Managed/UnityEngine.UI.dll
<lamont> oh now it compiled, still giving me warnings tho
Mike` has quit [Ping timeout: 186 seconds]
Mike` has joined #RO
Wetmelon has quit [Ping timeout: 186 seconds]
Senshi has joined #RO
ProjectThoth has quit [Quit: +++out of cheese error+++]
BadRocketsCo has joined #RO
<BadRocketsCo> Hullo
<BadRocketsCo> soundnfury: ya on?
BadMobileRockets has joined #RO
BadRocketsCo has quit [Read error: Connection reset by peer]
blowfish has quit [Quit: Leaving]
Shoe17 has quit [Quit: Connection closed for inactivity]
BadRocketsCo has joined #RO
BadMobileRockets has quit [Ping timeout: 186 seconds]
VanDisaster has quit [Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/]
VanDisaster has joined #RO
Shoe17 has joined #RO
SirKeplan has joined #RO
qwertyy_ has quit [Ping timeout: 383 seconds]
qwertyy has joined #RO
Olympic1 is now known as Olympic1|Work
Olympic1|Work has quit [Ping timeout: 186 seconds]
SirKeplan has quit [Ping timeout: 186 seconds]
Maxsimal has joined #RO
BadRocketsCo has quit [Quit: Bye]
Rokker has quit [Quit: Connection closed for inactivity]
Wetmelon has joined #RO
awang has quit [Ping timeout: 383 seconds]
Senshi has quit [Quit: Leaving.]
awang has joined #RO
Rokker has joined #RO
awang has quit [Remote host closed the connection]
TonyC has joined #RO
stratochief has quit [Remote host closed the connection]
schnobs has joined #RO
<schnobs> o/
awang has joined #RO
awang has quit [Killed (NickServ (GHOST command used by awang_))]
awang_ has joined #RO
camlost has joined #RO
aradapilot has quit [Read error: Connection reset by peer]
aradapilot has joined #RO
aradapilot has quit [Remote host closed the connection]
aradapilot has joined #RO
Senshi has joined #RO
<awang_> \o
<schnobs> new sub-project: create a catalog of thrust curves for SRBs.
<schnobs> Also, SRBs are both engine and tank. Is it possible to change the tank contents from an engine config?
SirKeplan has joined #RO
<schnobs> Problem detected.
<schnobs> The thrust curve of our UA1205: http://ksp.schnobs.de/stuff/UA1205.png
<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/]
VanDisaster has joined #RO
<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> Some general schematics stolen from OhioBob: http://www.braeunig.us/space/pics/fig1-14.gif.
<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.
<zilti> LOL MechJeb is at it again https://lyrion.ch/share/KSP/MechJebAgain.png
<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
<lamont> that’ll work better
<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> (when you’re using PEG)
<zilti> lamont: here's the pre-liftoff stats https://lyrion.ch/share/KSP/MJPreLiftoff.png
<lamont> heh “NaN” is really bad
<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> https://github.com/lamont-granquist/MechJeb2/wiki <— this is for the “OLD” version which is in released MJ
<lamont> https://github.com/lamont-granquist/MechJeb2/wiki/Space-Shuttle-PEG-Notes <— this is for “shuttle PEG” which is my branch
<schnobs> lamont: Can PEG handle excessive dV?
<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
<zilti> Ah, "predicted Earth Apoapsis: 150'421m, predicted Earth Periapsis: 141'649m"?
<lamont> yes
<lamont> that will be accurate
<lamont> and you shouldn’t use an orbit that low because of perturbations
<lamont> 185x185 is both more realistic and will keep you away from principia perturbing you into the atmosphere
<zilti> I used that because my plan was to first send up a fuel tank and engine, then in a second flight the capsule with more fuel
<lamont> 145x145 in reality is going to decay in a couple orbits
<zilti> Well, the idea, and the thing I typed into PEG, was 150x150 though
<lamont> sure
<lamont> but PEG doesn’t know about J^2 so it put you into a 150x150 keplerian tangent orbit
<lamont> again, i’m plowing through shitpiles of graduate level calculus which will let me fix that, but its just code in my brain at this point
<schnobs> zilti: give-and-take 30km of orbital altitude doesn't matter much in RSS.
<schnobs> lamont: +- 20m/s or thereabouts?
* egg|zzz|egg throws some calculus of variations at lamont
<zilti> schnobs: Probably not when just putting up a satellite, but all attempts of rendezvous go right out the window with that
<egg|zzz|egg> lamont: ping me if you have issues with the endpoints or feature requests for more of those
<egg|zzz|egg> lamont: also for optimization problems bofh might be a good contact
<lamont> yeah, i think i just abandoned PEG a few days ago
<lamont> me + PEG had to go our separate ways… i’ve found a sexier finite burn optimization algorithm…
<zilti> But thanks for linking the Shuttle PEG, lamont. It did a nice job just now for me, and it even "feels" more sturdy
* egg|zzz|egg afk restaurant
<lamont> yeah i need to make lunch
camlost has quit [Ping timeout: 182 seconds]
<schnobs> ^ thrust curves again. X248 still has kind of a long tail.
<schnobs> StarCut is what we currently have (eg) on Castor-1. Even that takes a good while to taper off.
<schnobs> Actual burn time is approx 1.15 and 1.5 times as long as with constant thrust=1.
<lamont> hah, that’s going to complicate accurate modelling of those
<lamont> is 0 to 1 time or it is remaining propellant?
schnobs has quit [Ping timeout: 198 seconds]
<zilti> LOL the community tech tree is funny. They placed the NK-33 under "basic rocketry".
TonyC has quit [Quit: Goodbye.]
camlost has joined #RO
<UmbralRaptor> Uh
<UmbralRaptor> What do they put at the end of the tech tree, Valkyrie antimatter rockets?
Hypergolic_Skunk has quit [Quit: Connection closed for inactivity]
TonyC has joined #RO
Olympic1_ has joined #RO
Olympic1 has quit [Ping timeout: 186 seconds]
Senshi has quit [Quit: Leaving.]
stratochief has joined #RO
<zilti> Heh neat, I managed to accurately(?) re-create the Explorer 1 start. Although spinning up the upper stages was awful
VanDisaster has quit [Ping timeout: 383 seconds]
VanDisaster has joined #RO
SirKeplan has joined #RO
camlost has quit [Ping timeout: 182 seconds]
qwertyy has quit [Ping timeout: 182 seconds]
qwertyy has joined #RO
Addle has joined #RO
stratochief has quit [Ping timeout: 186 seconds]
TM1978m has joined #RO
Wetmelon has quit [Read error: Connection reset by peer]
TM1978m has quit [Remote host closed the connection]
<Rokker> guys
<Rokker> GUYS
<Rokker> Bornholio: GUYS
<Bornholio> pants?
<Rokker> WE HAVE INFO ON THE NEW OATK ROCKET
<Rokker> Bornholio: also Israel might be burning Syria to the ground
<Bornholio> it burns and expells assad for fuel?
<Bornholio> C's eh
<lamont> solid rocket
<Rokker> The RL10 has risen, the BE-3U prospects for the new launcher are dead
stratochief has joined #RO
<Rokker> Long live the RL10
<lamont> BE-3U was the hydrolox one?
<Bornholio> the OA meg rocket
<Rokker> lamont: BE-3U is a vacuum variant of their current New Shepard rocket
<Rokker> so yeah hydrolox