Black-Two-

I started playing KSP again after taking a little break. I updated my modlist and started a new save and now the game freezes if I try to warp to the next day at the KSC. It looks like this: https://imgur.com/a/9E0IfN0 Here's my modlist: https://imgur.com/a/o4rg6nE It seems like it's the same problem described here:

As one of those who've had issues with GPP crashing, deleting the settings.cfg file and starting a new save solved it for me.

I've been using the latest for version for a little while now with great success! Now all I need is gravity assist planning but Wayfinder by @Muetdhiver seems like it is exactly that, with the caveat that I'll have to go back to stock, but I'll probably do that anyway at some point. Two questions about RSVP have arisen though! 1) "Error 205 - Destination is not orbiting a direct common parent or grandparent of ship". If I want to go to Ike from Kerbin's orbit I get this error and I don't understand why. Isn't the sun the common grandparent of Ike and a vessel orbiting Kerbin? 2) How does the script detect whether to use ship:obt:period or body:obt:period? I'm working on a script to execute RSVP without having to edit stuff between uses and I've been stuck on this problem for a little while now. I understand when to use each (ship:obt:period when origin and destination have the same parent, orbiting Kerbin with destination Mun; body:obt:period when origin and destination have different parents, orbiting Kerbin and destination Duna, for instance). Is this the correct part? if ship:body = destination:body { setting("origin_type", "vessel"). } else if ship:body:hasbody and ship:body:body = destination:body { setting("origin_type", "body"). } Yeah, that's the part I understand. I suppose what I don't understand is why there's a need for a minimum velocity at all, like why would it matter if a craft enters an SOI too slowly? But I suspect I might not understand the explanation anyway...

I'll be honest, I understand what the problem is but not why it's a problem. The relative velocity is greater than the minimum possible velocity, sure, but the relative velocity only(?) matters when the craft is outside the relevant SOI while the minimum possible velocity only(?) matters when the craft is inside the SOI, so why is it a problem? As for solutions... Changing line 407 in orbit.ks to "local sin_E is sqrt(1 - min(cos_E, 1) ^ 2)." avoids the crash, but then again it might create problems down-the-line. I'm really in over my head when it comes to this kind of stuff...

That's really weird. Pod-R at the bottom of the list in the tracking station shows up for me. When or where are you getting these part errors? I'm asking because the only part mod I use is kOS which presumably you also use. Let me try to understand this. "Circular" means that RSVP really, really wants the final orbit to have 0° inclination, but "polar" means inclination it isn't particularly concerned with inclination, is that right?

Hey there, I ran into a different problem. https://imgur.com/a/jvbkGbK I have a craft in a very eccentric orbit of Gratian, wanting to get to Geminus, Gratian's moon. Ten days (day 78 is today) into a search I get the error above. It looks like cos_E is greater than 1 and sin_E then tries to get the square root of a negative number. Here's a save: https://www.dropbox.com/s/8x14sqaz1ug8t7n/GPPrsvpgratian.zip?dl=0

You're welcome! I really enjoy these detailed write-ups, by the way! I hadn't even thought of messing with search_interval before, but it makes a big difference.

Right, so I think I have everything set up. There are two test vessels orbiting Gael. Test-1 is in a 100x100km orbit with an inclination of 8.3 degrees. A pretty standard launch orbit for GPP. Test-0 is in a 500x500km orbit with no inclination. I launched this after just to be absolutely sure inclination wasn't an issue. I've tested Iota, Niven and Tellumo. Iota is the closest moon, and Niven and Tellumo are the nearest planets inside and outside Gael's orbit respectively. For reference, current date is year 9, day 92. Here are some trials runs I ran just to make sure. Test-0 Iota: Starts slowly (doesn't anything for some seconds), then seems normal, stops at day 115 which corresponds with Iota's orbital period. Test-0 Niven: Finishes completely in a few seconds, and only prints out six times at day 92, 230, 368, (new year,) 81, 219, 358. It does find a very good transfer though. Test-0 Tellumo: Takes a few seconds to start, but is faster than Iota. It's then pretty similar to Niven. Test-1 Iota: Runs very quickly, to the point where I went back to Test-0 to see if it was still slow (it was). The final maneuver is not very good though, as it has rather substantial radial and normal values, and it drops the periapsis into the atmosphere. Test-1 Niven: Again, runs very quickly, and again only prints six times. The maneuver is worse, but this is probably due to the inclined orbit. Test-1 Tellumo: Runs slower than the other two, but is other than that very similar to the Niven run with few prints and a pretty bad maneuver. The Iota tests are pretty much what I'm used to from stock (lots of prints, sometimes faster or slower) but the Niven and Tellumo ones are the ones I wondering about. Here's the save file: https://www.dropbox.com/s/0vjeatjv397pntt/GPPrsvptest.zip?dl=0 Here's the code, just in case the script isn't saved. I use a different script when actually playing, but it's really just this plus a nifty little way to input a new maximum search duration in the terminal. Both scripts have the same issue. Config:ipu is 2000. parameter dest. runoncepath("0:/rsvp/main"). local options is lexicon("create_maneuver_nodes", "first", "verbose", true). rsvp:goto(dest, options). Edit: I don't use part mods other than kOS but let me know if you need a modlist as well.

Hello! I've been using RSVP in stock KSP for a while now and it's been working great. However, I recently switched over to Galileo's Planet Pack and now RSVP is running much, much faster when searching for interplanetary transfer windows, but it finds a lot fewer of those windows. I wasn't really expecting a search with a maximum duration of 500 days to find fewer than 10 transfer windows to certain planets in the outskirts of the solar system as in stock similar searches would not only take a lot long (tens instead of single-digit minutes) and I'm curious if you can think of why this would be the case. Maybe it's just the layout of the solar system (I've tried JNSQ but can't remember noticing this), but I just wanted to make sure.

Aha! A pattern emerges... If the problem only appears in career mode, it could be something that isn't as obvious, like contracts or milestones or something else career-specific. If it was due to bodies (or textures etc.) not loading the bug should show up in both science and sandbox modes too, I think.

Are you by any chance playing in career mode? Because I did and that's when this bug showed up, but in my quest to figure this problem out I switched to science mode and, hopefully I don't jinx myself, I haven't crashed or frozen once in ~10 trips to Iota and Ceti. Maybe try switching to science or sandbox and see if that solves it for you.

Another thing I discovered trying to figure out what's causing this: if you're playing with kOS, Gael and Ciro are still called Kerbin and Sun "behind the scenes". For instance, if you're in orbit of Gael and print body:name you get "Kerbin" which is wrong, but if you print body:description you get Gael's description, which is right, and if you're orbiting Ceti you get both the correct name and the correct description. I suppose this is due to Gael and Ciro being reskins(?) but it's something I hadn't noticed before.

I'm getting some weird freezing. In my current save (first with GPP), every time I exit time warp near Iota the game freezes completely. I've tried with only the bare-bones setup for GPP (GPP, Kopernicus, ModularFlightIntegrator, ModuleManager, all latest versions) as well as with the bare-bones + these mods (DistantObject, kOS, ReStock, scatterer, all latest versions) and the game crashes at the same place no matter which setup. It's pretty much exactly the same issue as is mentioned here: https://forum.kerbalspaceprogram.com/index.php?/topic/152136-ksp-1121-galileos-planet-pack-v166-23-sept-2021/&do=findComment&comment=3902277 https://forum.kerbalspaceprogram.com/index.php?/topic/152136-ksp-1121-galileos-planet-pack-v166-23-sept-2021/&do=findComment&comment=3959179 https://forum.kerbalspaceprogram.com/index.php?/topic/152136-ksp-1121-galileos-planet-pack-v166-23-sept-2021/&do=findComment&comment=3939523 I have logs, but I don't know where to upload them...

The release of this would be an excellent opportunity to recreate the "Twin Suns" moment from Star Wars. Just sayin'... Edit: Also, the last .dll seems to be working fine for me! Sorry about being slow about reporting stuff...

I've retrieved (some of) my probes and I think I've narrowed the problem I've been having down a little bit. It's craft-independent and it happens if I switch to a craft that is about to enter Kerbin's sphere of influence from the Sun and 1) keep the craft's Kerbin periapsis above Kerbin's atmosphere and then enter Kerbin's SoI, and 2) decouple/undock while on Kerbin's night side, while in the shadow, or 3) perform a maneuver node burn that drops the periapsis into the atmosphere. Of course, it could be due to something else entirely, but these are my most likely sources this far. I still have probes coming back though (JNSQ is big...) so I'll keep testing!