LeroyJenkins

Actually I found this intriguing, so I did some research. You CAN convert mile to km and km to mile in terms of Fibonacci sequences. It is because the conversion ratio between km and miles is almost the same as the Golden Ratio (1.609 km/mi and GR ~1.618), which the Fibonacci sequences approach the GR as the numbers get larger. And in Space terms we usually are dealing with very large numbers for distance. Unless we are using AUs or LYRs. Though if we are just displaying the distance value in terms of Fibonacci sequences, then the display readout would need to be "HUGE". Example: Instead of "100 km", it would be "3,8,89 Fb" Which are the Fibonacci sequence numbers that total 100. So something that is 1,000,000,000 km, would be a LONG sequence. But hey, why not. Everything else takes forever in this game.

I have only one thing to say....

@Untoldwind Very cool stuff, well done! Just one question, with Multiplayer functionality in the game in the future, will the two player be able to play Pong against each other?

Listening to Shana's answer about resources and how it relates colony building and interstellar exploration, I took it as the 15 resources are base/raw materials, that when processed together will create new materials. Therefore with base 15 units to combine, if you make only 2 part combos, there's 105 options (unique non repeating). If you make 3 part combos, that's another 455 options, 4 part combos that's 1365 unique non repeating potential combinations. Thus, based on the base 15 elements, one could see (15+105+455+1365=) 1,940 possible combos. Now not all combos would be valid substances, but still that's of variability potential just off the 15 for the developers to work into the game. Shana did mention that one of the other developers (forgot name) who put together a material interaction combo tree diagram with all the combos possible and what they create, and Shana hoped that they could release that diagram to help players. So I think there will be lots to enjoy and explore, and create.

Have you seen this happen in a non-modded (no lazy orbit) KSP2 scenario? I've done rendezvous and docking in both a bland install of KSP2 and with a modded KSP2. I agree it is more difficult than KSP1, seems like I can never get relative speed to exactly 0.0, but I've never seen my target 'jump' away. We I switch between controlling the main craft to the target craft to adjust alignment, and then go back to controlling the main craft, its not where I left it, both position and attitude. Are you seeing similar?

Well darn it, then they are even more useless than I thought. Thank you for confirming what they are.

Though I agree with you, that the UI needs some clean up and improvement in the UX area. 1A 1B and 2A and 2B are the close approach point pars for the rendezvouses with your target (Dres). These were the two sets of flag markers in KSP1. The 1A/1B set is the first approach opportunity and 2A/2B is the second. You sent up your maneuver node so that one or both of these sets are as close together as possible, just like getting the to marker flags halves in KSP1. Yes, not intuitive at first. Took me some time to figure out which ones were a pair. The number or the letters. I think those circles are to represent the SOI boundary and the dot in the middle represents the planet. Though the circles should not be the same size for every planet, since each planet has a different gravitational force (ie, SOI). Again, more work needs to be done on cleaning the UI/UX up, have better help bubbles and explanations in the tutorials which are still being developed.

@Starhawk, @Scarecrow71is on the proper track. The Oberth Effect is related to the Gravity Assist (or sling shot) maneuver. Without performing a dV burn, the sling shot maneuver uses the celestial body's gravity force to add to the vehicle's velocity. Thus increasing the vehicle's energy, and direction. Oberth is just adding more kinetic energy to the sling shot maneuver through mechanical means (ie, thrust). The bigger benefit of the Obreth Effect is when one compares a powered sling shot (vs non powered, gravity assist only, like what the Voyager s/c used - see graphic. At each flyby the s/c velocity get a boost) that is performed at a lower Pe altitude (ie, higher initial vehicle velocity) than the same dV at a higher Pe altitude (ie lower initial vehicle velocity). Vector Geometry helps illustrate this, for a non powered Sling Shot Vector U and V are the components of the total velocity vector of the spacecraft before and after the sling shot fly by. The V+U is larger after the fly by due to U gets added to by the gravitation force (pull) of the celestial body. Or V+U+Vg > V+U (keeping U constant). Now Vg is based on F = (Gc*m1*m2)/(r^2), Gc is the gravitational constant. m1 and m2 are the masses of the two objects, and r is the distance between the two objects. As r gets smaller (ie, the spacecraft gets closer to the celestial body), F increases exponentially, thus velocity (Vg) increase exponentially (as long as you don't enter the atmosphere). Now, for the Oberth effect. One plans an orbital transfer burn at Pe (ie, where r is its smallest and U is its max) and add a dV burn, you have V+U1+Vg1+dV. If you perform the same dV at an higher altitude (ie, r is larger, U at Pe will be slower, and Vg will be lower as well). Therefore (V+U2+Vg2+dV) < (V+U1+Vg1+dV). So plan your flyby sling shot burns at a lowest as possible Pe altitude, without getting into the planets atmosphere for minimum dV needed.

Confirmed. I've done normal orbit changes but only for very short burn times (100-200 m/s dV) and all seemed fine. Seems the error is magnified when performing longer burn times.@Spicat video shows a burn of 2000 m/s dV. I recreated this bug at 1000 m/s dV. I did it twice for Normal, with SAS set to track Normal and second time to track Maneuver. Same results as Spicat. I also performed it for an Anti-Normal maneuver, at Pe ( just in case this effect was for non-circular orbits only, and the normal burn was not done at either An or Dn) of the orbit. Again, same result. The post burn maneuver arc does not properly show the final orbit of the actual planned normal/anti-normal burn. Nice catch @Spicat I used the stock Kerbal K2 Rocket for my tests, not a custom build. [LOG 17:57:45.138] Version Info: 0.1.2.0.22258 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16 All graphics settings at max

I believe it only is available in Flight Mode, not VAB. It is select-able from the AppMenu/Waffle Button by the Launch Button. Works fine for me.

Confirmed, I've only seen this in Patch 0.1.2.0.

This makes me wonder how the activeVessel.Orbit data is organized and tracked for each patch. It would be good to be able to know which patch pre or post maneuver, and now inner SOI and after leaving SOI the current values are for. KSP1 had this a bit better organized in the orbit parameter readout, in the lower left hand corner of the UI, and one could select which parameters (before or after maneuvers). This would help with understanding the values when doing a gravity assist fly- by orbit planning.

[LOG 17:57:45.106] [System] ******* Log Initiated ******* [LOG 17:57:45.138] Version Info: 0.1.2.0.22258 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16 All graphics settings at max Multiple (4-5) spacecraft in LKO. Reload of save game returns to last controlled vehicle, however it stages (all staging deployed) or is corrupted Expected Behavior: With multiple spacecraft in orbit about Kerbin, all of which have 2-3 decouplers left in the staging, I save the game while in flight mode controlling one of the spacecraft. I return later, load the saved game, it loads into flight mode of the last controlled spacecraft. I expect the staging to still be intact and the view perspective to be the same as when I last saved the game. Observed Behavior: When I load the saved game, the view perspective puts me in the middle (inside) the spacecraft, and it has been autostaged. (all decouplers are detached). The other spacecraft in LKO that were in the same saved game are all fine, its only the one that I was last controlling when I saved the game. Patch 0.1.2.0 notes states these fixes. I don't think they are fully fixed yet. Saving and Loading Camera now returns to saved position and orientation when game is reloaded Fixed issue where reverting or loading results in disappearance of vehicle Steps to Recreate: Plan any orbital maneuver node with a burn time duration of more than 30 seconds. Start Burn in Vehicle View, while burn is occurring switch to Map View. It also happens when starting in Map View and changing to Vehicle View. Workaround: I haven't tried it yet, but before saving, I'd get out of Flight mode and save from KSC or the VAB, so that when the game loads again it takes me there instead of the spacecraft in orbit, then change to flight mode of the last vehicle I was controlling, as see if that helps. Mods: None Logfiles: Not sure where the save game files are located on my machine. Still looking for them to send the saved game file to you.

The mission report that pops up when a vehicle break apart provides some information on what broke. Just the part numbers and names, but if you have multiple parts of the same type, it very hard to know which one out of them it is. It would be good for the Engineer's report in the VAB to provide a pre-launch part failure assessment (bad joint connections).

It would be a benefit if a player could also set SAS to maintain a ROLL attitude not just Pitch and Yaw. And/or to set SAS to Track a Target in a ROLL attitude, not just Pitch/Yaw. This would aid in rendezvous maneuvers, keeping Solar Arrays pointed to the Sun, or Comm Antennas pointed to Kerbin. Finally having the game maintaining SAS ON and the attitude last set when switching control between multiple craft.