jclovis3

I found this online JSON editor handy for branching down the nodes in a collapsible node tree. https://jsonviewer.stack.hu/ In my instance, I did dock with another ship to get fuel, and they use the medium size docking node, both inline. Later, I used to newly refueled ship to dock with a newly launched ship. They wouldn't dock. I checked their states in the save file and found the refueled ship to have the bad state. The online tool doesn't make editing easy so I had to go back into Wordpad and make my way down with the Find tool using the node tree as a guide for what to search for. Multiple searches brought me along the stack to the right part on the right ship. Some thing I think we might want to test is weather this bug occurs from using the docking port on the affected ship to undock in the previous instance, or use the docking port from the ship we previously docked with to undock and see if this decision can reliable trigger the bug. In old KSP1, you could not choose either docking port. Only one would have the undock action available.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 While trying to figure out what state my docking ports are in when they fail to dock, I noticed in the json files under attachNodeStates there are a couple of lines that look like they could cause some problems with a capitalization error: "attachNodeStates": [ { "nodeId": "top", "IsDynamic": false, "attachedPartGuid": null, "AttachedPartGuid": { "Guid": "00000000-0000-0000-0000-000000000000", "DebugName": null } Not sure if this is the result of changes made in parts along the way that weren't all updated correctly across newer parts but it does look suspicious to me. Feel free to downgrade this as not a bug if I am mistaken. Included Attachments: quicksave_16.json

The problem is, when you dock two vessels together each having stages remaining, say a ship going to land on a moon or planet, and another ship designed to get it there, the stages suddenly get mixed up in a terrible way and you may not want your lander to stage anything at all along the way there while your delivery hauler may need to. This can become very cumbersome when there are a lot of sepratons involved. Idea 1: After coupling is complete, the game pauses automatically and puts the staging of one ship along side the other in a different color but in a single block. You can swap which one is primary (blue and on the right) and which one is to be merged (orange and on the left of primary). Then, you can edit the primary to create a stage, say at the top or anywhere in between, and insert the secondary into that stage. The secondary will resume remaining as a unified block until you click a button to merge. At this point, the unified block is released as it's individual stages all inserted over the new empty stage you created. Having only a primary left, you can now edit this as you see fit before unpausing. Idea 2: Similar to Idea one, only you can't insert the secondary into the primary. You simply show two groups, primary and secondary, with secondary on top of primary and a button to swap them, which would move secondary down and primary up and swap colors, making one the other and such. When you click a button to finalize, the groups are merged in serial order and all one primary blue color. Then you can unpause. In both scenarios, you should not be able to unpause until you have resolved this staging decision.

Back when I played KSP1 a lot more, I was running a major tourism operation. You might briefly see my spreadsheet in this video. I had a craft that seats up to four with a two stage launch from Eve's surface. I made use of the refueling tech to allow me to burn retrograde entering the atmosphere so I could top off my tanks after landing. Upon launch from the surface, of course I left the refueling rig behind. The rest of the tourists on this trip were in orbit of Gilly so that craft would head to Eve Low Orbit to rendezvous with the lander after it returned to orbit. The KSP2 missions says the Kerbals have to return, but I don't know if they have to return on the same ship that carried them to the surface. In either case, I would recon I would have to use a transport ship to carry the lander back to Kerbin. Without having fuel refineries yet, this contract is going to be a headache. I might have to go back to the old onion peel approach.

I found these across many of the radiation scans in various places. A search in your code for any use of this default text should reveal what still needs to be filled out.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 What Happened: I had a rather unusual event happen today. A ship headed to Moho had spherical hydrogen tanks docked around it across six different docking ports. I was manually draining the docked tanks in opposing pairs into the main ship and then undocking them. One pair, I managed to undock while paused and they seemed to just disappear, but I moved the camera and found them aft of the ship a ways. While resuming time to continue the burn and the parts were well beyond reach of the bracket keys to switch craft, they somehow came together and docked with one another. This then triggered the new debris to take focus and I had to pause to asses what was going on. They looked like two bacteria cells bonding together because I had them covered in little lights. Anyway, I was able to use map view and take control of my ship again, then resume the burn. What was expected: Focus should never jump automatically to any craft without an automatic pause. Focus should never jump to debris as you can't even use brackets to cycle between ships and surrounding debris. When parts are decoupled or undocked from a vessel having control and the newly released parts have no probe or kerbal control, focus should remain with the departed vessel, regardless of which docking port was activated. It seems if the outer docking port is used to undock, focus stays with the debris having that docking port.

I splashed down near by and swam to this feature on Laythe. Could hardly get a sample as you have to climb up on it. Then I went over to the mud and got my science, but realized I was stuck and couldn't go back in the water or walk anywhere.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 I have a craft with 3 antennae connected in symmetry and when I send all data science from my roster, it sends only one at a time and the part status on the three antennae show only one of them to be transmitting. I was under the impression that I should get 3x the bandwidth to send data faster. In KSP1, multiple antennae helped to increase the signal strength at long range. I know KSP2 is quite different, but there should still be a benefit to having multiple antennae and not just to balance the weight of the vehicle. .ipsImage { width: 900px !important; }

Related issue maybe is that you can't set a low orbit on Bop to do low orbit science. The divide between low and high orbit is so low that the impact icon shows up and you can't set an orbit that you can simply leave in place. I read in another article that the low orbit was raised to 30 km, but it needs to be raised much higher as the warp speed automatically reduces you to 4x while still in high orbit above this level. See: Edit: I just landed in the giant crater and the low orbit triggered below 25 km, which is already within the lip of the crater. Warp is reduced to 4x well above that so I think low orbit needs to be raised to at least 55 km if they're going to keep warp speed limits where they are.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 I guess I got used to the alarm clock added to KSP1 that stops warp and tells you when you have a maneuver coming and you can jump to the effected craft. Don't have that in KSP2. Don't know what the planned feature for this is and when it comes but I'm filing this as a bug because it turns out there is a red warning of an inactive maneuver that jumps up on the screen but the warp speed doesn't pause or reduce to 1x so by the time to read this warning, it's too late. You kind of half implemented what we need. You give the notification, but you don't take the simple step to abandon warp. This affects craft that you leave focus by returning to the KSC or any of its buildings, excluding the tracking station. You can warp time from the KSC waiting for the sun to come up before entering the VAB to select a craft and during this warp, I noticed this issue. .ipsImage { width: 900px !important; }

Duplicate of:

What celestial body (CB) and what Ap/Pe is your orbit? Each one has warp speed limits at various altitudes. This was the case in KSP1 as well. The reason for this, at least while you have control of the craft, is that collision physics is processed and the risk of hitting the CB increases as positional accuracy decreases. If you want to warp fast while flying low to a low gravity moon like Gilly (Eve) or Pol (Jool), then exit to the KSC first, then go into the tracking center. While in flight, entering the tracking center does not unload your physics simulation.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 Text reads, "We are detecting several areas of increased temperature on the surface. There is no evidence of volcanic activity, but that doesn’t mean some is impending." This seems logically incorrect. I believe the last part should say, "... but that doesn't mean some isn't impending." Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 The description text for a radiation measurement around Pol Low Orbit has not been set. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 With the OSL-25 "Starlab" collecting biome specific science in low orbit, you pass over each biome rather quickly and with some, those biomes have very small areas. Shores on Kerbin or Shallows on Eve are just two examples. The Starlab retracts all probes and booms every time it pauses and time warp doesn't speed this animation up either. When you finally do get to continue your scan as you pass by the same type of biome you started it on, you have to wait for these parts to extend before the timer can continue and often, you exit the biome before it can make any more progress. It took me over three hours to scan just the shallows biome on Eve because of this nonsense. In contrast, KSP1 allowed us to extend science parts and leave them out to perform their functions whenever we were ready to. The only reason to retract said parts is for atmospheric reentry, or when they present a hazard to docking or maneuvering close to other vessels. Mechanically, this doesn't make sense to keep moving them back and forth for every use as this should increase the wear and tear on these pieces and ideally, even cost EC to move them in and out. I actually wouldn't mind if we had to spend EC to extend, retract things like landing legs or solar panels either as they do use motors to enact motion and engage/disengage locks. It may just be a bug that the Starlab even collects biome specific science at all since it needs 6 minutes to perform this. If this is intended, please add to the part status in the parts manager an indication of the biome it is working on when it is paused, or allow it to run scans on each biome without restarting on others. Other options are to decrease the time it takes to perform a scan, or make the parts extend/retract faster, but I'd much rather just make us have to extend/retract them manually or only leave them extended during pauses in science but let them retract after the collection is complete. Edit: The same problem with the OSCM-01 "Mini-Lab", which is the unmanned equivalent.

I wasn't aware this was a decay as my Ap was actually going up. So it wasn't like there was any drag but more like it received thrust heading radial out. I tried flipping to each of the six directions to see if the pattern changed any and it didn't. So if parts were causing the force, the rotation of the craft should change the way that force is applied. I'm not sure the bug is related to any forces created by parts. The consensus seems to be 10 km at every CB so something in the code switches calculation methods at that point. Might be a hard coded figure, rather than a set constant or variable. IIRC, this bug was in KSP as well. In my lander, the only parts that clipped were the deployed antenna with the deployed solar panels, which rotated into a clipping position. There are also some small girders that I rotated to an angle so part of them clip the craft a bit. Cheat menu doesn't seem to work in science mode so I'll have to test this out in Sandbox with the simplest ship build with no clipping. Then I'll add suspect parts mentioned by other players with no clipping and see if that makes a difference, but I'm still leaning towards the hard coded change at 10km as the culprit.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 To reproduce: Enter Gilly Low Orbit with Pe/Ap both below 6 km. I tried to set them to 5,500 m when I discovered this bug. Reduce thrust to zero and ensure RCS is turned off. Toggle SAS on or off as you notice what is happening. What happens: Ap begins to rise and Pe begins to fall, making it impossible to maintain a circular orbit under 6 km for a full lap to perform orbital scans that require unique biomes at low orbit (such as with the science lab). SAS on or off does not solve this problem. I retracted solar panels as well to see if they were behaving like solar sails (is that even implemented). What should happen: Ap/Pe should not change. The orbit should be stable around Gilly as there is no atmosphere, or if there even was, both should go down. Evidence: Attached save file is of the lander going in to discover the low orbit parameters needed to descend my orbital science lab, which is still attached to the transfer module in orbit of Gilly. The lander will of course be headed to "The Crater Conundrum" marker but can be used to test this bug. Notice: Warp speeds are extremely limited around Gilly so plan to spend a lot of time if you continue with this save. Included Attachments: BugPhantomForcesatGillySaveFiles.zip .ipsImage { width: 900px !important; }

After some further testing with the same ship, I found it is not the state of the engine before docking, nor anything to do with parachutes. On my craft, after docking, I found that if I rearranged the staging to move my hydrogen engines back to a new stage and fired the staging to activate them again (throttle was at zero), this allowed the vessel to display the new deltaV and acknowledges that I have fuel again.

Same issue here. Checked each vessel and none are running experiments. I switched to the KSC, then the tracking center, to center camera on the sun and time warp waiting for a transfer window to Eve and this spam pops up but quickly clears itself when I drop out of time warp.

I have an update on this. It seems that if you turn off the engine of the lander before docking, it creates this bug. As a standalone unit, it will be out of fuel and carries this status on after being docked. The way to get around this is to make sure it is activate during docking, then deactivate it before you burn. Still, this is a bug that needs to be addressed. Edit: or, perhaps not. I relaunched my explorer and still have this bug regardless of when I turn the engines off. Now, even with the engines on and before docking, it says I am out of fuel. Oddly, there are empty fuel gauges next to the parachutes? Could this be a problem? Yes, that is a problem. You will have to modify your staging to get those parachutes staged without decoupling anything else. Once staged, I was able to set maneuvers again, even with the lander engines off. So the bug here is that unstaged parachutes provide fuel blockers for maneuvers.

Except the OSL-25 "Starlab" actually performs unique science over each biome in low orbit but not high orbit. So you will need to either keep continuing as you pass over the correct biome, or begin a landing and hover over it if it is something small like a crater.

I was just thinking about multiplayer and how time warp would or could be affected. I used to think time warp would just not be allowed in multiplayer, but then I came up with an idea that I think can work and players can rejoice. First off, I understand there will be a four-player maximum, so this shouldn’t take too long for them all to partake in the process. Initiating a time warp will not be an instant action unless you are the only player. If there are other players, then the process turns to a request to warp and you have to specify a time stamp to end at. This request is proposed to each player who will have an opportunity to deny the request (any denial will deny the warp) or propose an earlier time to stop. When all requests have been responded to, the warp will proceed to the earliest stop time authorized. The warp speed will be the lowest safe warp for each player’s-controlled ship situation and can still automatically increase or decrease as normal. Any player may abort the time warp while in warp. This also means that at no time can a player just increase the current game speed with the warp bar at the bottom and this UI element would be non-interactable. The methods of requesting a warp-to moment can be from any orbital line (conical) like the current warp-to point method, or it can be from a new button on the warp bar to open a dialog for setting the stop time. This will actually be helpful in single player as well. Additionally, and only if this makes sense, you can include in the warp request a starting time-stamp as well so all players will have a chance to prepare for it or coordinate a group action. Thoughts? Opinions?

In the video link below, I encountered two bugs, including this one, which might just be related. Not sure. So yeah, when I set throttle to full to burn prograde for a Mun intercept, I observe the Ap is increasing rapidly. Then when I time warp, it suddenly drops to a crawl. I am departing from low kerbin orbit (below 150 km). The other issue I experienced in this video is the bug where you dock two ships together and now you are unable to plot a maneuver due to not having any fuel. This is clearly a bug since I am able to fire thrusters manually. I contributed to the following post on that:

I have a similar issue where my lander and orbital science module is reverse of my reusable transit module and the lander engines are turned off. I can fire the rockets on my transit module manually but can't create a maneuver. Version: v0.2.0

To help all who are stuck with this bug, hover your mouse cursor over the collect sciences button on the left to see your current biome situation so you know when to resume the research.