egg changed the topic of #principia to: Logs: https://esper.irclog.whitequark.org/principia | <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly…
_whitelogger has joined #principia
Raidernick has quit [Read error: Connection reset by peer]
Raidernick has joined #principia
<queqiao-> ⟨Oslov⟩ hello. Obligatory cat.
<queqiao-> ⟨Oslov⟩ Kopernicus is now shipping the weird fake CB body hack by default, but we scrub it from the FlightGlobals.localbodies list. I am not sure if this helps you, but thought I should let you know JIC.
<queqiao-> ⟨Oslov⟩ * FlightGlobals.Bodies
<queqiao-> ⟨Oslov⟩ there is a config option for users to disable the hack, but they'd need to be aware. Most Principia users probably qualify, but still.
<queqiao-> ⟨Oslov⟩ +Config option is in Koperncius_Config.cfg, boolean option EnableKopernicusWatchdog
<queqiao-> ⟨egg⟩ ⟪R-T-B⟫ Kopernicus is now shipping the weird […] ⮪ … what do you mean by « by default »? Are you having this body around in all solar systems, or just the ones with stuff stupidly far away where the issue that it purports to solve occurred?
<queqiao-> ⟨R-T-B⟩ The issue had been found to produce graphical artifacts even in the stock system, particularly on some of the moons of Jool that don't align directly to the orbital plane. This was the driving reason. So yes all systems. There is a bypass if a mod needs it.
<queqiao-> ⟨R-T-B⟩ the issue is pretty well studies by now, as is the fact that the odd workaround works
<queqiao-> ⟨egg⟩ Have you figured out what the issue is, and why the hack resolves it?
<queqiao-> ⟨R-T-B⟩ the reasoning it works is sadly still a complete mystery
<queqiao-> ⟨egg⟩ I’m not sure that counts as well-studied :-p
<queqiao-> ⟨R-T-B⟩ the results of the introducing the watchdog is well studied
<queqiao-> ⟨R-T-B⟩ It fixes nearly every case of this occuring, which can actually happen as close as 3.5 kerbin AU's (closest I recorded) if one is to change the orbital plane much at all
<queqiao-> ⟨R-T-B⟩ not saying it's ideal, just, don't have a better answer right now...
<queqiao-> ⟨R-T-B⟩ I have found an absurd number of users needing to be pointed to the fix, and rather than point them all to it, I'd rather put it in an "opt-out" situation
<queqiao-> ⟨R-T-B⟩ * fix/workaround cfg,
<queqiao-> ⟨R-T-B⟩ if you have a better idea of course I am open to anything... and the moment I discover what is actually going on is the moment I remove this whole deal
<queqiao-> ⟨R-T-B⟩ I do understand the whole logic of this is very unscientific, treating a problem whose origin is completely unknown, but statistically speaking it has been well-vetted to work.
<queqiao-> ⟨R-T-B⟩ and yes even now the scientist in me wants to say "famous last words" lol
<queqiao-> ⟨egg⟩ so for instance, has it been extensively tried out with, say, RSS ?
<queqiao-> ⟨R-T-B⟩ RSS is known to work yes, but of course not with Principia
<queqiao-> ⟨R-T-B⟩ I'm unsure of Principias status right now, it depends on whether you read from more the FlightGlobals.bodies
<queqiao-> ⟨R-T-B⟩ I think you do
<queqiao-> ⟨R-T-B⟩ I'm unsure of Principias status right now, it depends on whether you read from more then FlightGlobals.bodies
<queqiao-> ⟨egg⟩ how else would I find that body if not in the Bodies?
<queqiao-> ⟨R-T-B⟩ body.orbitingbodies
<queqiao-> ⟨R-T-B⟩ that list
<queqiao-> ⟨egg⟩ what does it orbit?
<queqiao-> ⟨R-T-B⟩ the mock body is moved into orbit of whatever you are in orbit of
<queqiao-> ⟨R-T-B⟩ so it varies
<queqiao-> ⟨R-T-B⟩ interestingly, removing it from the body.orbitingbodies list somehow breaks the fix
<queqiao-> ⟨R-T-B⟩ which seems like a useful clue but it hasn't turned up anything
<queqiao-> ⟨R-T-B⟩ I used to theorize that a list read was being terminated too early in a loop somewhere
<queqiao-> ⟨R-T-B⟩ but never found any evidence to support that
<queqiao-> ⟨egg⟩ … what exactly do you mean by the effects of that hack being well-studied ? what you describe should be an instant crash with Principia.
<queqiao-> ⟨R-T-B⟩ yes, it would be, but users are warned about that in big bold text in the release notes, and told to set the appropriate config option
<queqiao-> ⟨R-T-B⟩ so Principia doesn't just read from flightglobals.localbodies then?
<queqiao-> ⟨R-T-B⟩ (and actually, now that I think about it, I can probably write a modulemanager patch to help with this if Principia is present)
<queqiao-> ⟨egg⟩ OK so neither you nor any of the people who test your thing have bothered to either install principia? nor search for orbitingbodies onthe repo?
<queqiao-> ⟨egg⟩ * principia nor search for orbitingbodies on the
<queqiao-> ⟨R-T-B⟩ I did, if you recall I made a patch for a far earlier version of Principia
<queqiao-> ⟨R-T-B⟩ so it would run properly
<queqiao-> ⟨R-T-B⟩ I believe, though it's been a bit, you use orbitingbodies at one point or two
<queqiao-> ⟨R-T-B⟩ but I am unsure of the present status
<queqiao-> ⟨egg⟩ None of that has changed in years.
<queqiao-> ⟨R-T-B⟩ so still the same likely, ok I will ship a config to protect your mod
<queqiao-> ⟨egg⟩ And installing Principia doesn’t take long, so it shouldn’t take long to find the crashes.
<queqiao-> ⟨R-T-B⟩ as a player of Principia, I'm somewhat embarassed to admit my fork is why I did not think of this sooner. My appologies on that front
<queqiao-> ⟨R-T-B⟩ fork works, forget it's a fork, etc...
<queqiao-> ⟨R-T-B⟩ I can easily have this fixed though likely before you get any issue reports
<queqiao-> ⟨R-T-B⟩ with a MM patch, I'll cook one up now
<queqiao-> ⟨egg⟩ well, otherwise you will have turned your issue where you had to direct lots of people to your watchdog to one where I have to direct a thousand people to you so you can direct them to the proper way of removing your watchdog…
<queqiao-> ⟨R-T-B⟩ this is true, although no offense but I'd argue more people use my mod than yours. Not that shifting the workload was my intention
<queqiao-> ⟨R-T-B⟩ I have nothing but respect for your work and will attempt to rectify this
<queqiao-> ⟨egg⟩ yeah, it is likely that almost all Principia users use Kopernicus one way or another.
<queqiao-> ⟨egg⟩ But the issue addressed by your phantom body wasn’t gamebreaking, this interaction very much is.
<queqiao-> ⟨R-T-B⟩ I agree, and apologize for my lack of vigilance. I should have acted the moment I suspected something could be wrong
<queqiao-> ⟨egg⟩ hence, about 1200 people crashing to desktop whenever they get around to updating Kopernicus.
<queqiao-> ⟨R-T-B⟩ and with CKAN, possibly not reading release notes at all even if they would otherwise, yes
<queqiao-> ⟨egg⟩ wheee
<queqiao-> ⟨R-T-B⟩ so my MM syntax is rough but I'm making something now, mind if I post it just to ensure we get this right?
<queqiao-> ⟨egg⟩ Try CCing Al2Me6 or DRVeyl who know MM.
<queqiao-> ⟨egg⟩ (or siimav or stonesmile who are probably more awake)
<queqiao-> ⟨R-T-B⟩ I got it it's pretty basic, no worries
<queqiao-> ⟨R-T-B⟩ the syntax guide walked me through it, all I'm really doing is deleting a body
<queqiao-> ⟨R-T-B⟩ @Kopernicus:FOR[Principia]
<queqiao-> {
<queqiao-> !Body[KopernicusWatchdog] {}
<queqiao-> }
<queqiao-> ⟨R-T-B⟩ that's it in a nutshell
<queqiao-> ⟨R-T-B⟩ will test ofc
<queqiao-> ⟨Stonesmile⟩ Might want ":NEEDS[Principia]" and a later pass, assuming that someone else could change it at some other point?
<queqiao-> ⟨R-T-B⟩ sure, I can do that
<queqiao-> ⟨R-T-B⟩ theoretically something else could change it so not a bad idea, though I am not aware of anything that actually does
<queqiao-> ⟨Stonesmile⟩ Yeah, what you have above should work too, especially since you are removing the body
<queqiao-> ⟨R-T-B⟩ I also added a config option, which I am toggling on just for good measure
<queqiao-> ⟨R-T-B⟩ code follows
<queqiao-> ⟨Got⟩ ⟪R-T-B⟫ ```@Kopernicus:FOR[Principia] { […] ⮪ No, never ever use "FOR" to check another mod presence. This doesn't work and as cascading side effects as it will actually register that mod as being installed.
<queqiao-> ⟨R-T-B⟩ ⟪Got⟫ No, never ever use `FOR` to check […] ⮪ this is appreciated, thanks, I alreadys switched to need
<queqiao-> ⟨R-T-B⟩ @Kopernicus_config:NEEDS[Principia]
<queqiao-> {
<queqiao-> @EnableKopernicusWatchdog = False
<queqiao-> }
<queqiao-> ⟨R-T-B⟩ should be fine
<queqiao-> ⟨R-T-B⟩ just doing a brief test and will push
<queqiao-> ⟨R-T-B⟩ what are the rules regarding BEFORE Got ? Similar?
queqiao- has quit [Remote host closed the connection]
queqiao- has joined #principia
<queqiao-> ⟨egg⟩ OK, so something to do with the terrain in all cases.
<queqiao-> ⟨R-T-B⟩ yes it seemed to be a bug with the PQS and I've been through that so many times it makes my head hurt
<queqiao-> ⟨R-T-B⟩ (of course skwod code is known to do that)
<queqiao-> ⟨siimav⟩ You know you can actually debug skwod code?
<queqiao-> ⟨R-T-B⟩ I do. It's a slow process figuring out the tools but I am learning
<queqiao-> ⟨R-T-B⟩ admitedly gotmachine and linx just introduced me earlier this month
<queqiao-> ⟨R-T-B⟩ I have two fixes in KSPCommunityFixes to my name so I must be doing ok though
<queqiao-> ⟨R-T-B⟩ (well one, one is in testing)
<queqiao-> ⟨siimav⟩ Nice! Thanks for the contributions.
<queqiao-> ⟨R-T-B⟩ Yeah if all goes well the longitudeRange scatters bug will be fixed. Most people don't even know, but if you set a partial range of scatters by longitude, it completely ignores the 4th quadrant
<queqiao-> ⟨R-T-B⟩ the reasons are rather hillarious but sort of OT for here
<queqiao-> ⟨R-T-B⟩ anyhow I'm glad I posted a cat because I was obviously due a fine of some kind tonight, hope I didn't cause too much trouble. Night all. It should be in CKAN by now
<queqiao-> ⟨egg⟩ nice cat
<queqiao-> ⟨R-T-B⟩ sometimes
<queqiao-> ⟨R-T-B⟩ boxes are forts, very dangerous
<queqiao-> ⟨R-T-B⟩ but shes so cute you can never stay mad
<queqiao-> ⟨egg⟩ prime cat, judging by the box
<queqiao-> ⟨R-T-B⟩ indeed
<queqiao-> ⟨Butcher⟩ My cats love amazon boxes. They seem to be ideally sized for cats
<queqiao-> ⟨Got⟩ To be a bit more specific, it is somehow affected by the (absolute ? relative to something ?) coordinates (and possibly rotation) of the body.
<queqiao-> For example, the sinking landing gear bug exhibit a quite reliable behavior, where depending on the current "quadrant" of the body orbit, and a craft with 4 landing gears, you get all landing gears sinkings, none of them, or only 2 on one side.
<queqiao-> ⟨Got⟩ To be a bit more specific, it is somehow affected by the (absolute ? relative to something ?) coordinates (and possibly rotation) of the body.
<queqiao-> For example, the sinking landing gear bug exhibit a quite reliable behavior, where depending on the current "quadrant" of the body orbit, and a craft with 4 landing gears, you get all landing gears sinking, none of them, or only 2 on one side.
<queqiao-> ⟨Got⟩ I've investigated this issue quite a bit, and it's entirely unclear what code path in KSP can be involved in this.
<queqiao-> Somehow it seems that some specific colliders/rigidbodies gets wrongly added to the PhysX exclusions (which is something that is quite difficult to check, the unity API for this stuff is quite sparse to say the least).
<queqiao-> KSP does quite a lot of messing around with those exclusions, but why
<queqiao-> ⟨Got⟩ an eventual bug in that code could be semi-randomly affected by the position of stuff is totally unclear
<queqiao-> ⟨Got⟩ And the sinking gears/wheels portion of the bug can be somewhat fixed by re-setting the wheel colliders gameobject layer, which is likely triggering a reset of the underlying PhysX state for those colliders/RB.
<queqiao-> A theory I have is that the terrain meshes/colliders gets moved around a bit post-creation when KSP decides to reposition them "precisely" using double-precision stuff after generating them initially with single-precision.
<queqiao-> It seems that this operation is causing some collisions between non-zero layer stuff (like wheels/gears) and the terrain mesh to be perpetually registered and stuck, causing new collisions to never be triggered again.
<queqiao-> When the above "layer reset" fix is used, new collisions invariably trigger tons of log entries like this :
<queqiao-> ⟨Got⟩ Which seems to suggest an initial "CollisionEnter" event was missed or never fired
<queqiao-> ⟨R-T-B⟩ Thank you for weighing in in so much detail gotmachine
<queqiao-> ⟨R-T-B⟩ one thing that has always bothered me is I have no idea why the watchdog fix works
<queqiao-> ⟨R-T-B⟩ do you have any theories on that front?
<queqiao-> ⟨R-T-B⟩ (yes I should be asleep, I am not)
<queqiao-> ⟨Got⟩ ⟪R-T-B⟫ do you have any theories on that front? ⮪ TBH, not sure I remember what you are doing with that fake body. Something like the issue only happening on bodies that have no orbiting bodies, and the fake body ensure this never happen ?
<queqiao-> ⟨R-T-B⟩ it ensures it never happens
<queqiao-> ⟨R-T-B⟩ the code that the fake body uses is actually quite odd. I will try and summarize it
<queqiao-> ⟨R-T-B⟩ I'm just going to read this out as psuedocode since it's a really odd block of code
<queqiao-> ⟨R-T-B⟩ if you are in orbit over the system root, the mockbody is moved out of the way, it is irrelevant since you won't be landing on the system root (at least I've never had that scenario tried)
<queqiao-> ⟨R-T-B⟩ if the body is not the system root, then it places the mockbody on an orbit as follows:
<queqiao-> ⟨R-T-B⟩ mockBody.orbit.SetOrbit(KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.inclination, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.eccentricity, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.semiMajorAxis * 1.001, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.LAN,...
<queqiao-> ... KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.argumentOfPeriapsis, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.meanAnomalyAtEpoch, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.epoch, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody));
<queqiao-> ⟨R-T-B⟩ to summarize that ugly blob, basically the exact same orbit as the last body in the tree right before the system root, with a SMA * 1.001
<queqiao-> ⟨R-T-B⟩ then there's another if statement, and this one was essential to make it work perfectly with multistar systems for some reason
<queqiao-> ⟨R-T-B⟩ if the referencebody of the current main body is the system root, it will place using this code instead:
<queqiao-> ⟨R-T-B⟩ mockBody.orbit.SetOrbit(KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.inclination, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.eccentricity, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.semiMajorAxis * 1.001, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.LAN,...
<queqiao-> ... KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.argumentOfPeriapsis, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.meanAnomalyAtEpoch, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).orbit.epoch, KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).referenceBody);
<queqiao-> ⟨R-T-B⟩ basically same exact code except rather than orbiting FlightGlobals.currentMainBody, it is moved to KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).referenceBody
<queqiao-> ⟨R-T-B⟩ as I said the whole thing is bizzarely complex
<queqiao-> ⟨R-T-B⟩ but it works
<queqiao-> ⟨R-T-B⟩ basically same exact code except rather than orbiting FlightGlobals.currentMainBody, it is moved to KopernicusStar.GetNearestBodyOverSystenRoot(FlightGlobals.currentMainBody).referenceBody, or what should amount to the system root
<queqiao-> ⟨R-T-B⟩ actually I just realized that last line is just orbiting the system root
<queqiao-> ⟨R-T-B⟩ no reason to declare it so complex
<queqiao-> ⟨R-T-B⟩ but anyhow
<queqiao-> ⟨R-T-B⟩ it seems to be a pretty precise positioning trick and related to where the body is relative to the system root
<queqiao-> ⟨R-T-B⟩ I was thinking maybe it is a precision boost type scenario, but how I have no idea
<queqiao-> ⟨R-T-B⟩ here is the whole method if you want to take it apart, as an atatchment
<queqiao-> ⟨R-T-B⟩ and yeah now I realize I've basically asked you why Pandoras box won't open, so nvm
<queqiao-> ⟨Got⟩ Well, frankly all I can say for sure is that this whole issue is somehow tied to how/in which order KSP initialize/create terrain colliders and mess around with collision ignore stuff.
<queqiao-> Somehow, the internal to Unity/PhysX collision ignore stuff end up in a weird invalid state.
<queqiao-> The fake body thing doesn't help much at identifying the root cause. It could be that it changes in which order stuff is initialized, or that since its collider intersect with everything in the scene it triggers a reset of the internal state of everything around.
<queqiao-> ⟨R-T-B⟩ I do know the collider has to be on for it to work, btw
<queqiao-> ⟨R-T-B⟩ of the mockBody
<queqiao-> ⟨R-T-B⟩ reinforces what you are saying
<queqiao-> ⟨R-T-B⟩ and yes there is another careful piece of code that ensures no vessel can collide with it
<queqiao-> ⟨Got⟩ Yeah, I suspect you could actually just instantiate a gameobject with a giant sphere collider on the same layer as what scaledspace objects are usually on and this would work just as well
<queqiao-> ⟨R-T-B⟩ I don't think it'd be in physics range but I was careful there
<queqiao-> ⟨R-T-B⟩ it doesn't, I tried
<queqiao-> ⟨R-T-B⟩ it has to be in the orbitingbodies list of whatever... wherever it's supposed to be
<queqiao-> ⟨R-T-B⟩ another odd detail
<queqiao-> ⟨R-T-B⟩ does not need to be in FlightGlobals.bodies though
<queqiao-> ⟨R-T-B⟩ at any rate I think we've explained sufficiently that it's a very complex issue
<queqiao-> ⟨R-T-B⟩ It was really frustrating when I discovered it actually can even manifest slightly in stock (bad shadows on some Joolian moons that aren't perfectly aligned with the plane)
<queqiao-> ⟨R-T-B⟩ It'd be so much cleaner though if I could find a way to do it without having to have it in a the CB.orbitingBodies list
<queqiao-> ⟨R-T-B⟩ -a
<queqiao-> ⟨R-T-B⟩ so it truly would be invisible
<queqiao-> ⟨Got⟩ ⟪R-T-B⟫ It'd be so much cleaner though if I […] ⮪ It would be much cleaner to fix the actual bug...
<queqiao-> In any case, this fake body thing is far from being a satisfactory fix.
<queqiao-> ⟨R-T-B⟩ yeah
<queqiao-> ⟨R-T-B⟩ I mean, I'd rather not spawn even a gameobject if I don't have to, but we are where we are for now
<queqiao-> ⟨R-T-B⟩ I still have an issue open that I will not close until the fake body thing is dead, to my credit
<queqiao-> ⟨R-T-B⟩ I just don't know where to even begin. The only clue I really have is the orbitingbodies list. It has to be linked to that somehow
<queqiao-> ⟨R-T-B⟩ also, people used to claim removing MakingHistory would help, but how that relates or if it was just placebo? Dunno
<queqiao-> ⟨Got⟩ Given how random the effects of this bug are, I would outright discard all random user claims.
<queqiao-> ⟨egg⟩ ⟪Got⟫ It would be much cleaner to fix the […] ⮪ yes, this, a thousand times this. I don’t think it is a good idea to waste energy on slight improvements to a hack that makes most of KSP’s stock madness look principled.
<queqiao-> ⟨R-T-B⟩ there hasn't really been any slight improvements. It's just been. I only mainlined it, because, well we discussed that
<queqiao-> ⟨R-T-B⟩ I'd love to find the root cause
<queqiao-> ⟨R-T-B⟩ I'm actually looking right now lol
<queqiao-> ⟨R-T-B⟩ I recall being highly suspicious of UpdateCBsRecursive, in Planetarium, but I'll continue any ideas off here with gotmachine privately
UmbralRaptor has quit [Remote host closed the connection]
_whitelogger has joined #principia
<queqiao-> ⟨egg⟩ TIL some new KSP madness https://mobile.twitter.com/whitequark/status/1532802068829945862
<queqiao-> ⟨leudaimon⟩ Is that RP or WF?
<queqiao-> ⟨egg⟩ I don't think it is either, I would guess stock
<queqiao-> ⟨R-T-B⟩ Egg, you probably know this from our discussion but linking in case you care, our official statement regarding the watchdogs intended "lifecycle": https://forum.kerbalspaceprogram.com/index.php?/topic/200143-181-1122-kopernicus-stable-branch-last-updated-june-3rd-2022/&do=findComment&comment=4141016
<queqiao-> ⟨R-T-B⟩ basically, use it until we can kill it and not a second more. This was always the plan, just wanted to reassure you I am not overtly in love with the thing
<queqiao-> ⟨lamont⟩ okay i hate it when the kids call things "cursed" but this whole bug/fix is "cursed"
<queqiao-> ⟨R-T-B⟩ I have already planned for it's eventual, hopefully soonish day of removal by ensuring Kopernicus will not launch a game with both it and Principia present without displaying a huge warning, about how this game may not be playable in the future (and you can only get there if you override the blacklist)
<queqiao-> ⟨R-T-B⟩ if you mean the watchdog hack yes it very much is
<queqiao-> ⟨R-T-B⟩ I have already planned for it's eventual, hopefully soonish day of removal by ensuring Kopernicus will not launch a game with both it and Principia present without displaying a huge warning, about how this game may not be playable in the future (and you can only get to the warning if you override the blacklist in an attempt to improperly play)
<queqiao-> ⟨R-T-B⟩ yay, Got deserves some praise. He sucesfully isolated the workaround from the celestialbody hackery, distilling it down to just a sphere collider we move as needed. I imagine this is much better? It's still in testing but it looks very promising.
<queqiao-> ⟨R-T-B⟩ it's still cursed I suppose but far less cursed and won't break principia, so, progress?
<queqiao-> ⟨R-T-B⟩ someday you'll know me for something other than cursed code, honest
raptop has quit [Quit: leaving]