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"
_whitelogger has joined #RO
SirKeplan has quit [Ping timeout: 180 seconds]
_whitelogger has joined #RO
ferram4_ has joined #RO
ferram4__ has joined #RO
ferram4__ has quit [Remote host closed the connection]
ferram4 has quit [Killed (NickServ (GHOST command used by ferram4_))]
ferram4_ is now known as ferram4
ferram4_ has joined #RO
stupid_chris has joined #RO
stupid_chris is now known as stupid_chris_
stupid_chris_ is now known as stupid_chris|AFK
stupid_chris|AFK is now known as stupid_chris
stupid_chris_ has joined #RO
stupid_chris_ has quit [Client Quit]
stupid_chris has quit [Quit: THE BEES]
stupid_chris has joined #RO
schnobs has quit [Ping timeout: 183 seconds]
blowfish has joined #RO
<blowfish>
Does RO hava an Algol?
Mike` has quit [Ping timeout: 190 seconds]
Mike` has joined #RO
_whitelogger has joined #RO
wb99999999 has joined #RO
_whitelogger has joined #RO
<github>
[RealismOverhaul] Theysen opened pull request #1933: [BUGFIX | DECQ R7] Fixed core stage vernier setup and plume (master...master) https://git.io/fxBMq
blowfish has quit [Quit: Leaving]
schnobs has joined #RO
ferram4 has quit [Read error: Connection reset by peer]
ferram4_ has quit [Read error: Connection reset by peer]
ferram4_ has joined #RO
ferram4 has joined #RO
wb99999999 has quit [Quit: webchat.esper.net]
stupid_chris has quit [Read error: Connection reset by peer]
<Qboid>
[#1049] title: Does Ascent Guidance / Cirularization take retro SRB into account? | It seems that the dV of retro SRB to get rid off spent stages is calculated as positive dV because all circularization burns since I use the dev 804 are offset.... | https://github.com/MuMech/MechJeb2/issues/1049
<Starwaster>
OMG Gordon Dry again...
<Starwaster>
I cant wrap my head around Gordon Dry so soon after the MFI inanity... I need coffee
<Starwaster>
It is by caffeine alone I set my mind in motion...
<Starwaster>
well some of those look legit but some... automatically adjust gimbal limit... wtf no gordon NO. Stay off the carpet
<Starwaster>
WHY is he f***ing linking the SRB (non)issue to other totally unrelated mods' issues?
<Starwaster>
oh and MJ2 is apparently now at fault for causing his flag errors... DAMMIT Sarbian I thought you fixed the issue with MJ2 causing flags to cause errors when planted!!!
<xShadowx>
well i mean...without a proper dv calc, the flag might not stay planted!
<xShadowx>
which btw id love if flags could fall over ;3
<Starwaster>
bornholio can I make a suggestion about where he can plant those flags...?
<Starwaster>
lol
<xShadowx>
o.O
<Starwaster>
ok enough of GD for the afternoon... I just skimmed through some of his posts on the forums.... I usually have those filtered for my sanity...
<Starwaster>
can hydrates exist in in a rocky body heated to over 900K?
<soundnfury>
probably, just not anywhere near the surface
<soundnfury>
(any body that got baked while still forming from a rubble pile, however, will be dry right the way through because it was _all_ surface.)
ProjectThoth has joined #RO
<awang>
Bornholio: Nope, definitely not around right now
<awang>
Gordon Dry?
<Bornholio>
his attempts at mod assistance hurt others brains
<awang>
I see
<Bornholio>
awang i was having problems with test flight in 1.4.5 and was wondering of you still have it with working troubleshooting code in it
<awang>
Bornholio: Most likely not, but I can probably find a way to add troubleshooting code back in
<awang>
If I still have a version with debugging code, it's probably on my half-dead MBP
<awang>
Which is currently at home
<Bornholio>
no problem, i should just put in mods ONE AT A TIME for good measure
<awang>
Bornholio: What issues are you facing?
<awang>
Also, I recommend using a git repo for your install
<awang>
Annoying to set up, but man the benefits are nice
<awang>
Pretty much free "clean installs", git bisects, and a nice install log at least
<Starwaster>
hmmmm asteroid mining.... might be time to give that another look
<Mike`>
awang, btw, that aerothermal limit field you put into MJs autostaging doesn't seem to remember the values you put in it :S
<Starwaster>
doesnt matter since aerothermal data as calculated doesn't match what the game says it is, and that's the only data that matters
<Mike`>
it doesn't matter that i have to keep adjusting it because it doesn't remember it's value? well, maybe not for you, that does matter for me, however
<soundnfury>
that's odd. The Castor 4 has a lower ISP (both SL and Vac) than the Castor 2.
<Starwaster>
the data that you're using to base your fairing staging on doesn't actually have relevance as to whether it's actually safe to stage them
<awang>
Mike`: Between launches?
<Mike`>
awang, yeah
<awang>
Do the other fields remember their values?
<awang>
Hmmm
<Mike`>
most others do, i'm not sure if all do
<Mike`>
Starwaster, that might all be well and true, but doesn't matter. i want my fairing to stage earlier, and as long as nothing blows up i know it is safe. ;)
<awang>
Mike`: I think it's supposed to be persistent?
<Qboid>
[#952] title: Add aerothermal heating constraint for fairing autostaging | Allows fairings to be automatically jettisoned at a more realistic time.... | https://github.com/MuMech/MechJeb2/issues/952
<awang>
Mike`: Yeah, you need to be a bit careful with that number. As Starwaster pointed out in the comments on my PR, aerothermal flux isn't the be-all-and-end-all of heating
<Starwaster>
most likely it is not staging earlier. The most likely outcome is that it stages later
<Starwaster>
it all depends though
<Mike`>
....
<awang>
Especially because the model used by MJ is fairly simplistic and calculates flux through a plane normal to velocity
<Starwaster>
there is a point at which... before that point it will underestimate the true value
<Starwaster>
after that point it overestimates
<awang>
Which is also how real-life launches calculate flux
<Mike`>
Starwaster, if i increase the limit it surely won't stage later
<Starwaster>
also it depends on physics settings
<awang>
That too
<Starwaster>
that is, the TRUE value depends on physics settings
<Starwaster>
the so-called aerothermal flux does not
<Starwaster>
it will never take into account your PhysicsGlobals and it is dangerous to rely on
<Starwaster>
especially since it feels 'safe' for the application of staging
<Starwaster>
anything changes?
<Starwaster>
...
<Starwaster>
things can get ugly
<Starwaster>
I said it from the start when that damned field was put in that it should just read the game data directly instead of relying on an equation that will never be accurate
<Starwaster>
well... it's accurate at one time in flight... I guess even a broken clock is right once per day
<Mike`>
which is totally irrelevant to the problem at hand that it's not persistent (for me)
<Mike`>
the field, that is, not the calculated value and its application
<awang>
Mike`: You're talking about the field with "1135" in it?
<Mike`>
awang, exactly
<Mike`>
i keep increasing that but it keeps resetting to 1135
<Mike`>
most other fields seem to be persistent, i haven't tested the other fairing stage limits though, i left those at default i think. "stop at stage x" also doesn't seem to be persistent.
<awang>
Mike`: I mean, it at least looks similar to the other fields in the code that are persistent
<awang>
Starwaster: Just curious, how would you do fairing jettison code the right way?
<Mike`>
i'll test the other limit fields and see
<awang>
As you pointed out, the current code assumes that the game is working like real life, which isn't the case
<awang>
But the code seemed to produce real-life-ish results in the tests I did, so I PR'd it
<Mike`>
awang, do you know what the difference between Pass.Type and Pass.Global is?
<awang>
Mike`: Not at all. You'll have to ask someone who knows the KSP API better than I do :(
<Mike`>
the delays have Pass.Global and those are persisted for me, those without Pass.Global might not.
<awang>
I just copied the existing code
<Mike`>
hm.
<awang>
Starwaster: Would you happen to know what game state I should read to get accurate heating data?
<awang>
I think I toyed with that before landing on the copy-existing-launch-manuals, but I think I abandoned that due to getting what looked like nonsensical numbers
<lamont>
[Persistent(pass = (int)Pass.Type)]
<lamont>
just change that to [Persistent(pass = (int)(Pass.Type | Pass.Global))]
<awang>
Starwaster: Would adding a PhysicsGlobals.HeatingMultiplier or equivalent at least partially address your concerns?
<Mike`>
lamont, thanks, but do you know the meaning of local, type and global?
<awang>
(not that I mean to deman anything with "concerns", but I can't come up with anything less diplomatic-y and more direct right now)
<awang>
Also, how well does PhysicsGlobals play with RealHeat or such?
<lamont>
its just kinda like variable scope
egg is now known as xn--wr9h
<lamont>
so if something is set to Global there’s just one global variable that gets tweaked
<lamont>
if something is set to Type then its per-ship-type (i think by name) but you always get the default value
<lamont>
if its Type|Global then you have per-ship-type settings that get remembered and take precedence, but the global value also gets updated for the next new ship
<lamont>
and local…. i dunno...
<Mike`>
interesting. maybe i should try to relaunch a rocket with the same name. :D thanks.
ProjectThoth has quit [Ping timeout: 202 seconds]
xn--wr9h is now known as egg
<awang>
Does MJ have a way of knowing whether a part is a fairing?
<awang>
Starwaster: ^ Relevant for fixing fairing jettison based on heating
<lamont>
yes, theres a PartExtension
<soundnfury>
The M-1 costs more than 18 J-2S, and the F-1 costs more than 22 RS-27. Why would you ever use the big engines?
<awang>
lamont: Glad to know
<awang>
Hrm
<Starwaster>
awang dont need PartExtension, just read it right off of the part; convective (and optionally radiative) heating
<awang>
Starwaster: The question is how to know what part you should be reading off of
<awang>
The nice thing about the real-life equation is that it's independent of rocket design/shape
<awang>
It only relies on location and velocity
<Starwaster>
if you want to generalize it you could do that
<Starwaster>
I'll have to work it out later though, I have a pizza in the oven needing attention
<awang>
It's not really a matter of generality
<awang>
Alright, enjoy!
<Starwaster>
V = Pi(z*z)a
<lamont>
i am incorrect. someone should add IsFairing to PartExtensions.cs and probably update isUnfiredDecoupler and the other bits of fairing-specific code that grep turns up
<lamont>
really fairing jettison needs to be made into its own controller though
<soundnfury>
pizza is the crowning accomplishment of human civilisation
<lamont>
like MechJebModuleDeployableAntennaController.cs there needs to be a MechJebModuleFairingManager.cs or something like that — so that Fairings can deploy when autostaging is paused
<awang>
lamont: Does MJ currently have the capability of staging decouplers/fairings independent of their location in the staging list?
<lamont>
no, that’s what i’m saying….
<awang>
Ah
<awang>
Unity still hasn't added the sgen GC collector, right?
ProjectThoth has joined #RO
<github>
[RealismOverhaul] raidernick pushed 3 new commits to master: https://git.io/fxRcS
<github>
RealismOverhaul/master 07089e8 Mike: don't set diameterIncrement twice
<github>
RealismOverhaul/master 361c43f Mike: fix mass calculation of engine clusters
<github>
RealismOverhaul/master 4158d3d raidernick: Merge pull request #1930 from MikeOnTea/sstu_mass_fix...
<Starwaster>
hmmm so every time I load my asteroid miner in... it is buried in the asteroid. At random depths... I dont recall having seen this before but then I don't usually bother with asteroids except when a contract calls for it and then I don't mess with that asteroid again
<Starwaster>
anyone know how I stop that?
<Starwaster>
also, awang, I'm testing some code to pull cached thermal data off of the vessel and its FlightIntegrator (which will also need to be cached if MJ isn't already doing so somewhere, like the vessel extensions)
<awang>
Starwaster: Wish I can help you there
<awang>
That's starting to delve far deeper into modding territory than I am familiar with :(
<Starwaster>
what, the asteroid thing or the other thing?
<awang>
Both, I guess
<awang>
Originally intended for the thermal code
<Starwaster>
I've got half of what I need reliably pulled off of the FlightIntegrator, which is the radiative term, but the only thing I see cached is the convectiveCoefficient which I'm not quite sure how that gets used on a part by part basis so I need to poke at that and see what they're really doing with it
<Starwaster>
but basically it's going to look like this: aeroThermalFlux = this.part.vessel.convectiveCoefficient + (this.flightIntegrator.backgroundRadiationTempExposed * PhysicsGlobals.StefanBoltzmanConstant * PhysicsGlobals.RadiationFactor);
<Starwaster>
except of course that the convectiveCoefficient is only part of what I need...
<awang>
The part in the parentheses is the blackbody radiation?
<Starwaster>
or maybe it's all of waht I need except that I'm thinking of it in watts... when it's probably kilowatts...
<awang>
From the fairings?
<Starwaster>
no
<Starwaster>
it's part of the bodyflux calculation which lerps between the atmospheric temp (using externaltemperature) and space temperature using a density lerp that is calculated somewhere else
<Starwaster>
basically it's how much raw flux is going to come in from radiation alone
<Starwaster>
which there's going to be quite a bit of it at supersonic and hypersonic speeds
<Starwaster>
none of which matters much, the relevant bit is cached so it can be used as is from in those parentheses
<Starwaster>
but on a part by part basis, that calculation is what is used to determine the net flux (incoming radiation - part radiation)
<Starwaster>
long story short is it's half of the aerothermal flux you want
<awang>
Radiative flux would really only matter for stock atmo, right? Seems to me that at the altitude you'd jettison fairings at in RSS the atmosphere would be far too thin for radiative flux to matter
<awang>
Makes sense
<awang>
You're going for a more general solution than I was
<awang>
I'm guessing this is all stuff you had to do for DR at some point?
<Starwaster>
no, making it up as I go along right now... but I think I'll incorporate the radiative stuff into DRE's PAW readout because ATM it only shows pure convection
<Starwaster>
but... I thought a general solution was what you wanted for this? rather than just pull it off of one of the parts?
<Starwaster>
because otherwise you could just grab it from the fairing part
<awang>
My thinking was that I was really only concerned about high-altitude heating in RSS
<awang>
You're trying to come up with something that would work in other situations, namely stock
<awang>
And also taking into account things that would matter more in stock, like radiative heating
<awang>
I actually thought you were going for the part-based solution
<Starwaster>
actually, radiative heating during ascent is more extreme in RO
<awang>
How do you plan on getting a vessel-independent solution?
<awang>
Is it at the altitudes you're going to be jettisoning fairings at?
<awang>
I have little knowledge of heating loads, so maybe I just don't understand what the rocket is going through