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.

Ok, not sure if this is a Bug or not, but I saw the same thing in KSP1. I have two spacecraft in orbit. I want to dock them to each other. I set SAS on Vehicle number 1 to point a certain direction to orientate the vehicle to assist with the docking alignment I want. Then I switch to and control Vehicle number 2, get it SAS orientated just right and start my rendezvous approach to Vehicle 1. As I approach Vehicle 1, I see it is not in the orientation I want or left it in. So I go back to controlling Vehicle 1 and SAS is disabled. Is this by design, a limitation of the game or a bug? Any insight help from anyone is much appreciated.

Hello Shana - Loyal KSP1 Fan and Excited KSP2 player here. I have two semi related questionsL 1) How do you and the Team learn about and imitate real world rocket and spacecraft systems, to ensure the realism of the game? For example how does the designers figure out or learn how an exhaust plume changes shape in different atmospheres or vacuum, or how a solar array's angle to the solar vector changes amount of power generated. I saw a video about the engine sounds, where a KSP2 team went out and recorded actual rocket engines being fired, very cool way of getting those sounds. Where and what resources does the Team use to gather the "aerospace" knowledge to design parts, planetary science, orbital mechanics and the like? 2) In relation to "game experience and content" as a Game Designer, are you and how are you seeing the development of the design of rocket/spacecraft system telemetry (status)? Not just from a single vehicle standpoint, but from a Mission Control view of multiple, concurrent spacecraft in operation? This is more than just the Tracking Station currently in the game, but monitoring multiple operating craft. Like NASA/JPL or ESA does from their Mission Control Centers. With Colonies/Mulitplayer this may be a huge benefit to managing and knowing the current state of all the players space assets. Thank you!

I know, right?! Totally The BOMB of a setup. I want to have more digital read outs, though if I couple the hardware console with an external UI from KSP2's UI, I can get to Multiple Screens (I have 3 right now). One 52" 4k for the flight visualization, and two 32" for external UI display. I can setup the two smaller ones as Mission Control to monitor multiple concurrent mission status (especially time to next maneuver), and another for Vehicle Flight Status. Then the console just needs to be current vehicle controller. I've been watching ebay for a real navball that I can use instead of a digitized one. I am going to stick with kRPC2 like this guy did, Though I may go with a raspberry Pi instead of an Arduino. He has to use a lot of shift registers and muxes for all the inputs/led controls off of a singe Arduino.

I agree. My ultimate goal is to have something like what this guy did for his KSP1 setup. I got the 3D printer and a CNC machine to make my own parts for the console. Just need to do the electronics and software for it. https://photos.google.com/share/AF1QipPuRt7_324s4sK9Ffx6HBCRnqTzMGuNKDL-YnXn4pnNGxPzry9WkzvVWIYOh0A4DQ?key=cS03S3NYODhoSERVQUZpZ2dnNDdET2NZc0tWTU53

Agreed, I would think the notes get posted first, then the patch becomes available. Watching Discord and nothing posted for patch notes yet either......

There is no set time for patch release. 10am MT is just an assumption based on when Patch 1 was released.

kRPC2 API allows you to use either Python, C#, C++ or Java. Choose your poison and develop away.

Look! A human!

@AVaughan Yep, missed that part. You are correct, for the same amount of fuel the TWR does not change when using the same engine Isp on small number of larger tanks. Thank you for clarifying!

Yes, this can be done. There are a few of us looking/working on the starting of this type of Mission Control Telemetry display, outside of the KSP2 UI. KSPSerialIO, kOS, KWP and kRPC are options to use to build what you are looking for. What I am trying to manage right now is the processing load on the CPU with the different architecture options. kRPC seems to be the best to minimize CPU load while updating all the possible TLM data points, since its a stream data source that can be throttled on data point updates. See this forum thread - kRPC2 has a Discord Channel as well, to monitor development progress.