02:35 <lamont> awang: piles of this NRE spam on scene loading prior to physics being ready: https://gist.github.com/9412d75eb2b438cdc071e4af8f815feb

02:42 <lamont> yeah it stops once “[LOG 18:41:25.118] Unpacking RSB Atlas V HLV” so maybe check that the vessel is unpacked

03:13 <awang> That's interesting

03:13 <awang> Wonder why that wasn't an issue prior to the change

03:14 <awang> Is vessel only nonnull after unpacking?

03:16 <awang> lamont: If it's the vessel parameter that's behind the NREs, I'm slightly confused that the NRE only appeared well into FAR code instead of in MJ code, since MJ queries vessel properties too

03:17 <lamont> it looks like the FAR code isn’t valid until the vessel is unpacked

03:18 <lamont> so Vessel is fine (which sorta makes sense because packed vessels have a position, velocity, parts and all that jazz)

03:19 <awang> So I just need to add a check for !vessel.packed?

03:19 <lamont> but it looks like the FAR APIs you’re touching don’t work when the vessel is packed

03:19 <lamont> yeah more or less, whatever that looks like

03:19 <awang> Hmmm

03:19 <awang> Could you try it?

03:19 <awang> Since you can reproduce the NREs, and I can't?

03:19 <awang> Sorry for asking you to do it

03:20 <lamont> sure?

03:20 <lamont> although i was gonna step away for a bit

03:20 <awang> Ah

03:20 <awang> I mean, that's fine

03:20 <awang> It's not like we're in a hurry?

03:21 <awang> Oh wait

03:21 <awang> Never mind, I'm blind

03:21 <awang> it is in my logs actually

03:21 <awang> Along with some unrelated FAR NREs

03:21 <lamont> yeah i’m surprised you didn’t have those as well

03:22 <awang> I'm just blind

03:23 <awang> Still curious what Vessel part FAR relies on that isn't available when packed

03:23 <awang> Might it be more appropriate for FAR to handle this?

03:23 <lamont> FAR just might not be running on packed ships?

03:23 <awang> Or is this something for the FARAPI caller to handle?

03:24 <awang> ferram4: ^?

03:25 <awang> Now that I take a closer look at my log, Trajectories also has NREs

03:25 <awang> From the same calls, it looks like

03:27 <lamont> yeah i’m guessing until physics is running and the ship is unpacked, FAR doesn’t bother with it and doesn’t do physics outside of the bubble. that probably means if you do some kind of reentry trajectory and leave the vessel for awhile and it gets packed that you’ll get stock trajectory behavior? and that optimizes for the case of discarded boosters and stuff, since FAR doesn’t need to do detailed calculations on the trajectory

03:27 <lamont> they fall.

03:28 <awang> Might FAR still need to run to calculate aerodynamic breakup and such?

03:28 <lamont> (but that’s entirely speculation)

03:29 <lamont> for outside-the-physics-bubble aero breakup why does it matter?

03:29 <awang> Oh, outsides physics bubble

03:29 <awang> Never mind then

03:30 <lamont> if you’re doing some kinda crazy falcon 9 multiship stuff it might start to matter, but typically you’d need to hack the physics bubble or use that mod that lets you rewind time and land the booster

03:33 <awang> Does RSS touch the physics range?

03:33 <awang> Thought I remember seeing things staying in-atmo without being destroyed even tough they are well outside the 2.5km range for stock

03:33 <awang> Unless the 2.5km range is for somethign else

03:34 <lamont> https://ksp-kos.github.io/KOS/structures/misc/loaddistance.html

03:34 <lamont> vessels outside of the load distance exist, they’re just on rails and they don’t do anything and code won’t run on them, and they’re just a dot.

03:36 <lamont> vessels that are loaded, but still packed, will render, but its a single packed object and physics isn’t running across the parts tree

03:36 <lamont> unpacked vessels get the full physics simulation and are fully controllable

03:36 <awang> I see

03:36 <awang> I was mistaken then

03:39 <lamont> so if you’re doing multi-ship stuff where it probably matters that aero is correct, everything is probably unpacked. “vessels” that are packed/loaded/unloaded in the atmosphere are probably spent stages.

03:40 <lamont> (but might ask ferram, i’m just guessing)

03:53 <ferram4> What are you doing, exactly?

03:57 <ferram4> Wait, you're trying to run code on vessels that aren't loaded?

03:57 <ferram4> Of course that's gonna throw, vessel doesn't even exist properly until they're loaded in.

03:58 <ferram4> Nothing outside of physics range has any real existence in physics and you can't do any traditional physics with it.

03:58 <lamont> calling FAR APIs on packed vessels

03:59 <awang> I didn't even know that was something I had to consider

03:59 <lamont> like in scene loading when switching to the launch pad before physics loads

03:59 <ferram4> It throws on vessels that are within 2.5 km in space, but further than ~300 m?

03:59 <lamont> it throws on a vessel which is on the launchpad, but before it is unpacked

03:59 <ferram4> Because that's what "packed" means: everything is loaded, but physics aren't applied.

04:00 <ferram4> Uh...

04:00 <lamont> right

04:00 <lamont> that’s what i was saying “just don’t do that then"

04:00 <ferram4> So you're trying to run physics sims before physics is set up. :P

04:00 <lamont> right

04:00 <lamont> “doc it hurts when i do this”

04:00 <lamont> “stop doing that"

04:00 <awang> Oops >_<

04:01 <lamont> all its doing though is spamming some NREs to the log before physics loads, so its just debug log cleanup

04:02 <lamont> and its just a side effect of MJs VesselState module running when physics isn’t loaded, which i don’t entirely know why its doing that, but it just means the new FAR code needs a check around that to not NRE

04:04 <awang> Would it be more correct to stop VesselState stuff from running when physics isn't loaded?

04:05 <lamont> IDK, i wouldn’t mess with that

04:06 <lamont> it might be there for some horrible reason, and you’ll break someone’s use case

04:06 <awang> ferram4: Does a vessel being packed also matter for FARAPI.VesselAoA/VesselSideslip/etc? Or does it only matter for CalculateVesselAeroForces?

04:08 <ferram4> Those will only read the instantaneous AoA and Sideslip, not the simulated, so you probably don't want to be grabbing that.

04:08 <ferram4> That's just reading what would already be displayed in the GUI for if you want that for MJ windows and such. It should probably be okay, but I'm not 100% sure.

04:12 <awang> What would the problem be with grabbing instantaneous AoA/sideslip?

04:16 <awang> Er

04:16 <awang> I guess I'm more just confused

04:16 <awang> Do I not want to be grabbing AoA/sideslip using VesselAoA/VesselSideslip/etc? Or is using those probably ok?

04:18 <ferram4> If you're using it for simulations, the numbers will be wrong, because it's the vessel AoA and sideslip in reality, not in your simulation.

04:19 <awang> Oh

04:19 <awang> I think I want AoA/sideslip in reality, so sounds like it should work

04:21 <awang> lamont: btw, are you planning on PRing your PEG changes soon? Or is there still work to be done?

04:22 <lamont> still some work, don’t want to PR it quite yet

04:22 <lamont> i’ve got known bugs to fix still and i’m sure there’s probably some other ones out there for stuff i haven’t tested recently

04:24 <awang> Alright

04:24 <awang> Created MJ and Trajectories PRs

04:45 <awang> Hmmm

04:46 <awang> ferram4: I think I know why Trajectories is causing FAR to emit NaN Prediction Section Errors

04:46 <awang> Stuff like [ERR 23:38:10.034] [FAR] NaN Prediction Section Error: Inputs: AtmDen: 0.257691 Mach: 0 Re: 0 Kn: NaN skin: Infinity vel: (0.0, 0.0, 0.0)

04:47 <ferram4> That should have been fixed in a FAR update.

04:47 <awang> I'm building from master

04:47 <awang> Definitely still see them in logs

04:47 <ferram4> During what situation?>

04:47 <awang> Rocket launch, in flight

04:47 <lamont> oh i wonder if my drag loss NaN above the atmosphere is due to being behind on FAR updates?

04:48 <awang> Or at least I think so

04:48 <awang> The atmospheric density numbers seem to be right for an ascent

04:48 <ferram4> There are only two options.

04:49 <ferram4> 1) You're launching a vehicle that has parts that have stupid meshes and so FAR has no ability to voxelize them properly, so you should have no drag or lift forces at all.

04:49 <ferram4> 2) Trajectories is feeding NaN into the system.

04:49 <awang> I'm launching the stock Kerbal X, so hopefully it isn't the former

04:50 <ferram4> That, or it's feeding in (0,0,0) as velocity or something.

04:50 <awang> I was just about to say that

04:51 <awang> Because Knudsen number is NaN, machNumber / (reynoldsNumber + machNumber) needs to be 0.0 / 0.0, so velocityWorldVector must have been zero

04:53 <awang> idk why Trajectories is feeding in the zero vector

04:54 <lamont> oh my gawd, the new PEG code works well

04:55 <lamont> 184.951 x 186.375 with 9548 m/s burned on this awful rocket with a 0.33 TWR upper stage

04:57 <lamont> (and the fairing popped off on the lauchpad due to autostaging lolwut so ferram punished me a bit for pushing a cube through the atmosphere)

04:57 <awang> Oh wait, I'm a moron

04:57 <awang> The FAR error tells me what the velocity is right ther

04:58 <awang> s/ther/there

04:58 <Qboid> awang meant to say: The FAR error tells me what the velocity is right there

04:58 <awang> Wow

04:58 <awang> Excuse me, I'm going to go punch a hole in the wall with my head

05:38 <awang> Seems the Trajectories cache is to blame for the FAR NaNs? Disabling the cache seems to cause them to go away

05:39 <awang> Hmmm

05:39 <awang> Still appear to be getting some NaNs after the ship is unpacked

05:39 <awang> ferram4: Are there any constraints on vessel state that CalculateVesselAeroForces has beyond being unpacked?

05:40 <awang> Looks like I'm still getting FAr NaNs due to MJ even after checking whether the vessel is packed

05:40 <awang> Er

05:40 <awang> I guess besides 0 surface velocity, too

05:40 <awang> I should add a check for that...

10:17 <Probus> o/

10:34 <Probus> If you were to name one thing that you seem to always forget about when you build your rockets/probes, what would it be?

10:35 <Probus> For me, it seems to be batteries. I always forget to have enough battery power available... As is the case right now! Grrr...

10:38 <ProjectThoth> I'm surprised fuel cells aren't more popular in stock.

10:38 <Probus> You're right ProjectThoth. I've just recently found the usefulness of them.

10:39 <ProjectThoth> I've got an expedition going on right now (attempting to drive from KSC to the inland space center), and like seven smol prop tanks is enough for ~1,100 km of driving.

10:40 <ProjectThoth> It's kinda cute. https://i.imgur.com/Y3u0rfL.png

10:41 <ProjectThoth> The turbines are for the very brief part of the journey that has to deal with water.

10:42 <Probus> lol. You're right

10:43 <ProjectThoth> I think I finished up about 560 km earlier this evening. Really hope I can make it, the margins ain't great.

10:43 <ProjectThoth> Probus: Stock gas station wen?

10:45 <Probus> How long is that going to take you?

10:46 <ProjectThoth> Uhhh... well, so far, total drive time is 4ish hours in-game (had to stop overnight because terrain is hard to see).

10:47 <ProjectThoth> I've basically made my way to the other side of the continent KSC is located on, then it's a brief sail over and an extremely long drive through desert.

10:48 <Probus> Are you going to visit all the anomalies?

10:49 <ProjectThoth> I don't even know if I have the margin to drive to KSC2.

10:49 <ProjectThoth> But if I ditched the turbines and replaced them with OSCAR-Bs, I might have enough to take the scenic route.

10:51 <ProjectThoth> Probus: Sadly, no good mapping resources for this kind of stuff.

10:52 <Probus> I've got a large rover on the Mun. Pretty difficult to not fall in a hole.

10:52 <ProjectThoth> I've had to reload three times now because I drove into something at 28 m/s.

10:54 <ProjectThoth> Driving is hard!

10:54 <Probus> Yes it is.

11:00 <ProjectThoth> Also hard to do when winded.

12:17 <Probus> I've been playing around with Sarbian's rover utilities in mechjeb. Pretty cool stuff.

13:00 <taniwha> I think fuel cells are unpopular in stock because they are woefully underpowered

13:00 <taniwha> by a factor of 30-45

13:00 <taniwha> (I did the math: they have, at best, 1.3% efficiency. Real fuel cells have 40-60% (up to 85% for some))

18:09 <awang> lamont: MJ PR to check whether vessel is packed before using FAR has been merged