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…
<queqiao-> ⟨Braden_lupus⟩ Hey! I am rather new to Principia, and am currently trying to send my early lunar probes (specifically, the Landers). What is the best way to figure out a launch window to the moon? I don't have much tech, so my ∆v budget is really tight. I am launching from Kennedy, but right now, the moon is at an inclination of about 23°, so I can't just launch into the plane. I tried launching to LAN, but that seemed to not quite align...
<queqiao-> ... things right, so when I did my burn at the ascending node, it missed the moon completely. Is the right solution to just wait for the moon to be at the right point of its orbit so that burning at ascending or descending nodes will meet the moon? Is there an easy way to calculate when that would be in the tracking station? Or do I have it all wrong? Thank you!
<paculino> Burns are not instantaneous; you need to get about half of the Δv of the burn before and after the location of the instantaneous burn to get the desired effect.
<paculino> Butcher has a script for this, if you are not opposed to kos automation.
<paculino> Well, it isn't much automation.
<queqiao-> ⟨Marsh⟩ The thing to remember is that since you can’t match planes with the moon from Florida, you have to launch to a specific LAN that will give you an encounter with the moon. Butcher’s mod figures this LAN out for you
<queqiao-> ⟨Braden_lupus⟩ Ok, thank you!
<paculino> The easiest solution is to go to India or the bit of France in South America, but you probably cannot afford a new launchsite and VAB in your current career
<queqiao-> ⟨Braden_lupus⟩ Not really. And I have wanted to figure this out so I can try another career from a higher latitude later, for even more fun and difficulty
<queqiao-> ⟨Butcher⟩ paculino, that is not as kos script - that's a standalone mod. Also it's on CKAN.
<queqiao-> ⟨sichelgaita⟩ I have seen repeatedly on this channel a pattern that I frankly find quite annoying: (1) it crashes, must be Principia (2) that's because of your RAM/CPU/GPU/whatever (3) random discussion about computers ensues (4) nobody opens an issue on GitHub or give us any logs (5) ok so I'll uninstall Principia.
<queqiao-> ⟨sichelgaita⟩ I mean, it's entirely possible that Principia is causing crashes, either directly or because of interactions with other mods, although that's not very common. But at any rate _we don't investigate or fix the bugs we don't know about_. Other than adding a lot of noise to this channel, discussions like the above don't contribute anything to improving the mod or helping the community use it.
<queqiao-> ⟨Marsh⟩ The pattern is probably due to “the community’s” belief that principia nukes your computer’s resources so any and all problems are probably principia. (It’s never caused any crashes for me, and I suspect visual mods put a greater strain on resources than principia…) I’ll try to break the chain and deflect off topic conversations away from this channel unless it’s a solid principia issue (such as crashing only stopped...
<queqiao-> ... when principia removed)
<queqiao-> ⟨Cirelion⟩ ⟪sichelgaita⟫ I have seen repeatedly on this channel […] ⮪ For me, the conclusion was drawn based on other people's suggestions and the fact that KSP specifically crashes when I'm playing around with principia transfers. I also checked the logs but couldn't find anything relevant. I'm sorry if it annoys you but I can't write a bug report without any relevant data. I asked repeatedly if people had alternative possibilities...
<queqiao-> ... but as you can see. People didn't, so for me, literally the only option is uninstalling because I cannot go interplanetary.
<queqiao-> ⟨Cirelion⟩ For me, the conclusion was drawn based on other people's suggestions and the fact that KSP specifically crashes when I'm playing around with interplanetary principia transfers. I also checked the logs but couldn't find anything relevant. I'm sorry if it annoys you but I can't write a bug report without any relevant data. I asked repeatedly if people had alternative possibilities but as you can see. People didn't, so for me,...
<queqiao-> ... literally the only option is uninstalling because I cannot go interplanetary.
<queqiao-> ⟨test_account⟩ Did you check principia logs specifically? They are in their own glog folder
<queqiao-> ⟨Cirelion⟩ Yep, only nothing weird there. All logs are expected
<queqiao-> ⟨Cirelion⟩ Maximum step counters etc. I can send the entire log file so you can check yourself if you want
<queqiao-> ⟨test_account⟩ The only thing I can check is if there are FATAL errors in principia logs
<queqiao-> ⟨test_account⟩ Principia crashes happen after those
<queqiao-> ⟨test_account⟩ * these
<queqiao-> ⟨Cirelion⟩ There aren't, but there also aren't any crash logs in the %LocalAppData%\Temp\Squad\Kerbal Space Program so I'm not sure if something else is wrong, I can't find any crash logs
<queqiao-> ⟨Zeusbeer⟩ How much storage space do you have left?
<queqiao-> ⟨Zeusbeer⟩ Could be that your pagefile is not able to keep up
<queqiao-> ⟨Zeusbeer⟩ Which is what windows 10 uses instead of RAM when it runs out of RAM
<queqiao-> ⟨Cirelion⟩ I have about 80 gigs left, I've set my virtual ram to 48000MB
<queqiao-> ⟨Cirelion⟩ I'll try clearing up some space and seeing if that helps
<queqiao-> ⟨test_account⟩ no, if there 80gb left, that's not the reason
<queqiao-> ⟨test_account⟩ +is
<queqiao-> ⟨Cirelion⟩ Hmm okay, I did notice that my lines start to flicker shortly before crashing aswell. (It isn't TAA, I already turned that off)
<queqiao-> ⟨Cirelion⟩ * about a minute
<queqiao-> ⟨test_account⟩ It's some mysterious crash, it's not Principia crash and not a KSP crash and not an out of memory crash and not an out of disk space for page file crash, so what else could it be?
<queqiao-> ⟨Cirelion⟩ That's the milion dollar question.. The 0 logs thing is the weirdest part about it all..
<queqiao-> ⟨test_account⟩ Or maybe the question is, can principia crash without any errors in the logs. Who knows, maybe 🤔
<queqiao-> ⟨Butcher⟩ I have had random crashes that I think are just leaky KSP eventually kills itself.
<queqiao-> ⟨Butcher⟩ Less so since increasing RAM.
<queqiao-> ⟨Cirelion⟩ I have a save that's right before I do my manouver. Last time I tried it crashed within minutes of loading the save. It's definately not that
<queqiao-> ⟨Cirelion⟩ * definitely
<queqiao-> ⟨Butcher⟩ Load it up, crash the game, find your logs. 🤔
<queqiao-> ⟨Cirelion⟩ There's no logs
<queqiao-> ⟨Cirelion⟩ I mean, there are logs. But no fatal errors or anything, just expected warnings
<queqiao-> ⟨Cirelion⟩ And the %LocalAppData%\Temp\Squad\Kerbal Space Program directory doesn't have a crashes folder so there's nothing there.
<queqiao-> ⟨test_account⟩ Are the crashes random or they always happen in that save when planning the same maneuver
<queqiao-> ⟨Cirelion⟩ Always when planning that maneuver
<queqiao-> ⟨Cirelion⟩ I've done lunar impactors several times with 0 issues
<queqiao-> ⟨test_account⟩ Maybe you could try starting a new game, putting something in orbit in sim and planning something like an interplanetary maneuver
<queqiao-> ⟨test_account⟩ If it's a RAM/whatever issue it should probably crash anyway, if the save is somehow bad then maybe not
<queqiao-> ⟨Cirelion⟩ I can't imagine how this would be a save issue but I can try I guess
<queqiao-> ⟨test_account⟩ It's unlikely to be a save issue , but I've had this happen in the past once because of bugs that are now fixed
<queqiao-> ⟨Butcher⟩ I have exposed a few bugs in the trajectory planning by doing crazy stuff, you might just be hitting something weird - though I'd expect something in the glog folder if that were the case.
<queqiao-> ⟨Cirelion⟩ Only maximum step counts logs near the crash itself. I can send the entire file if you'd like?
<queqiao-> ⟨test_account⟩ If it's not a FATAL file then it probably won't help I think
<queqiao-> ⟨Cirelion⟩ Yeah, no FATAL files
<queqiao-> ⟨test_account⟩ I have plenty of ERROR files in my log, but nothing crashes. Only FATAL matters
<queqiao-> ⟨Cirelion⟩ Nope it crashed again on a fresh sandbox save, although I did notice it crashed specifically upon zooming in to venus
<queqiao-> ⟨egg⟩ Discord is not an issue tracker. If there are specific steps or circumstances that cause issues, even if we cannot diagnose it, it should be filed as an issue, so that if it happens to others we can piece things together.
<queqiao-> ⟨Cirelion⟩ Right, I'll add a issue to the repo later today. Thanks for the attempts to help guys, guess I'll remove prinicipia for now
<queqiao-> ⟨test_account⟩ Zooming, flickering, GPU at 100% ... this cannot be right 🤔
<queqiao-> ⟨Cirelion⟩ Ignore the 100% GPU, that was a faulty reading from windows
<queqiao-> ⟨siimav⟩ ⟪Cirelion⟫ Nope it crashed again on a fresh […] ⮪ That does point at memory issues since zooming in at Venus would trigger the on-demand textures to be loaded.
<queqiao-> ⟨Cirelion⟩ Let me try to reproduce it by just zooming into a planet and not playing with the manouver planner at all
<queqiao-> ⟨Cirelion⟩ * maneuver
<queqiao-> ⟨Cirelion⟩ Yep, it's zooming into the planet specifically that crashes the game. So that'd mean it's not related to prinicipia directly I'd assume right?
<queqiao-> ⟨test_account⟩ Now the question is if it happens also without principia in your install
<queqiao-> ⟨Cirelion⟩ Right, let me try that. I have a feeling I should just lower the RSS textures and that that'd fix it
<queqiao-> ⟨sichelgaita⟩ https://github.com/mockingbirdnest/Principia/issues/3197 and https://github.com/mockingbirdnest/Principia/issues/3442 were crashes during flight planning that we never elucidated, but they were both on Linux so possibly irrelevant. The "flickering" part is somewhat reminiscent of https://github.com/mockingbirdnest/Principia/issues/3064, which was a Unity leak triggered by the way Principia was drawing the UI. Note how the...
<queqiao-> ... user who ran into the latter issue gave us _a lot_ of information to help reproduce the problem.
<queqiao-> ⟨Cirelion⟩ Siimav's suggestions made me figure out the exact moment it fails, upon zooming into a planet on map view. I just lowered textures and removed prinicipia but neither changed it. So this isn't a principia specific problem.
<queqiao-> But I also don't have any crash logs so I'm not sure where I should move this question now nor what could be the cause.
<queqiao-> ⟨test_account⟩ Now it looks like a topic for #ro-support channel, not that it actually helps to solve the issue 😦
<queqiao-> ⟨Cirelion⟩ Right, I'll ask the question there but at least I have more to go on than before. Thanks for helping me narrow down the problem!
<queqiao-> (If I just made an issue of this I would've never figured this out)
_whitelogger has joined #principia
<queqiao-> ⟨Braden_lupus⟩ Can hyperedit not mess with orbits with Principia? I was trying to test a lunar lander without running the entire launch, and no matter how many times I pressed the set orbit button
<queqiao-> ⟨Al₂Me₆⟩ Enable hack gravity first.
<queqiao-> ⟨Vee (She/Her)⟩ Is there a reason why flight plans might not render beyond like 10 hours while reference frame is set to target? I was attempting a rendezvous last night and could only get flight plans to render for around 10 hours no matter what I did with plan length/steps per segment. I think I'm probably just missing something obvious and this is not an issue with the software itself, as soon as I switched to earth inertial frame the...
<queqiao-> ... full plan is still rendered
<queqiao-> ⟨egg⟩ ⟪Vee (She/Her)⟫ Is there a reason why flight plans […] ⮪ This is limited by the prediction of the target vessel, which, when in the target frame, uses the prediction settings of the current vessel. So the workaround is to increase the _prediction_ steps or tolerance.
<queqiao-> This was meant to hide the dependency on the target prediction when plotting the active vessel’s prediction (you want a longer prediction, you get a longer prediction, and you don’t see that it’s limited by the target and not by you).
<queqiao-> However, this leads to a coupling between the flight plan and the prediction which is not at all intuitive. Could you open an issue so we remember to try to find a better heuristic?
<queqiao-> ⟨Vee (She/Her)⟩ oooohhh I see! I'll create an issue in Github, please give me a moment
<_whitenotifier-7bc1> [Principia] VeeDeltaVee opened issue #3471: Flight plan rendering length in target reference frame is limited by current vessel prediction settings, not just plan length - https://github.com/mockingbirdnest/Principia/issues/3471
<queqiao-> ⟨Vee (She/Her)⟩ I hope that's helpful, please let me know if you want me to include additional details, I know the pain of vague issues and don't want this one to get lost in the queue.
<queqiao-> ⟨egg⟩ now that we have the prognosticator we might just be able to bump the prediction settings based on the flight plan settings.
<queqiao-> ⟨lamont⟩ egg what is the non-inertially fixed burn frame called?
<queqiao-> ⟨lamont⟩ Frenet frame
<queqiao-> ⟨Vee (She/Her)⟩ Also, another question about flight planning: for some reason the RCS on my Gemini spacecraft isn't detected as RCS, so whenever I go to make a maneuver it seems to think it will take infinity time. This is easy enough to work around: set to impulsive burn and try not to do burns that will take longer than a minute or two of burn time. However, if I forget to set to impulsive before adding delta v, the plan length shoots up...
<queqiao-> ... to like 2000 days, because it seems to think my RCS is really underpowered or something and the burn will take that long to execute. It's not really a problem, more of an annoyance, is there something I'm missing here as well?
<queqiao-> ⟨Al₂Me₆⟩ Stupid question: did you rebase after activating the RCS?
<queqiao-> ⟨Vee (She/Her)⟩ yes, multiple times after executing burns etc. Is that an issue?
<queqiao-> ⟨Al₂Me₆⟩ No; I just wanted to make sure you're doing it. Not doing it would be an issue.
<queqiao-> ⟨Vee (She/Her)⟩ is it somehow picking up ullage RCS thrust from my upper stage
<queqiao-> ⟨Vee (She/Her)⟩ and not realizing Gemini spacecraft RCS is different?
<queqiao-> ⟨Vee (She/Her)⟩ hmm maybe I should do another test deliberately doing rebases after stage sep, rather than just ad-hoc
<queqiao-> ⟨Al₂Me₆⟩ Well the OAMS part is a bit weird, but not sure if that would actually affect things.
<queqiao-> ⟨Vee (She/Her)⟩ I'll try to do a deliberate test tonight once I get off work
<queqiao-> ⟨itsRyan⟩ There are two versions of the Gemini OMS engine, one is configured as RCS and the other as an engine. If you have the engine config on your craft you'd want those active and nothing else, then choose "active engines" for planning.
<queqiao-> ⟨itsRyan⟩ +Vee (She/Her)
<queqiao-> ⟨Braden_lupus⟩ ⟪Al₂Me₆⟫ Enable hack gravity first. ⮪ Thank you!
<queqiao-> ⟨Vee (She/Her)⟩ ⟪itsRyan⟫ Vee (She/Her) There are two versions of […] ⮪ yes, I deliberately configured the engine as RCS (makes for easier docking). Don't think it's being detected correctly, but maybe I'm not properly rebasing or something. I'll perform a test tonight with only the gemini spacecraft in a clean save and post logs if I can