BlackholeKS

I am unconvinced that implementing a basic version of commnet occlusion which just calculates relay graphs based on line of sight with sphere occlusion and draws some lines on the screen would be an infeasibly complex addition for a subsequent patch. I'm pretty sure that there's a mod that already does this and the underlying math/implementation would not be overly complex - I've coded similar systems myself in the past and presumably Intercept has a whole team of programmers. If they want to further extend and iterate on that system, that's great! But it'd appreciate having at least the basic version of the KSP1 feature present first.

I'm not going to yell at anyone, but I do think that KSP 1 CommNet is a pretty essential part of the gameplay design of KSP that KSP 2 has ported over, especially in how certain transmitter types are designed. At the moment we have all the parts from KSP 1 that were meant to facilitate this part of the gameplay - relays being big dishes that need fairings, receivers being foldable, the different range levels increasing with size for different usages and craft types - except in KSP 2 it's all aesthetic and has no reason for existing, in fact if anything it all just gets in the way now. Such a big missed opportunity if not fixed, that shows that the core design of KSP 1 with respect to probes and comms just was not understood properly when developing the sequel. Maintaining signal on the ground and around other planets has always been a key consideration when I play. It's the whole reason to send probes, to set up satellites before landing like IRL, a reason to not just stick a Kerbal on every craft to begin with, therefore increasing mission variety. It's not something that should really need to be "explored again" because it's integrated with the entire scenario design, not something extra that is bolted on. And if the reason is to try to discourage players from having to launch as many missions and have less space infrastructure, then respectfully, huh? Is the entire point of KSP 2 not to have more off-planet infrastructure, larger and more numerous craft, etc... and yet you're saying that they are trying to encourage a playstyle where players have fewer craft in orbit than the original due to performance? To the extent that they may cut an important and well loved feature that was the impetus for a huge swathe of the original game's content and gameplay loop? That seems like a fundamental failure of this project, and I highly, highly hope that it will not end up being the final state of things. I wanted to take the next step from KSP 1, building on what was there, not be offered cheat codes that sap the fun out of exploration.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 10 | CPU: AMD Ryzen 7 3700X 8-Core | GPU: NVIDIA GeForce RTX 3070 | RAM: 15.95 Severity: Mid Frequency: High As noted in the title, When timewarping under xenon thruster acceleration, depleting vessel EC results in thrusters continuing to work while not depleting xenon, giving infinite acceleration without depleting propellant. I have confirmed this with some users in the KSP discord. Apparently this is due to an improper resource check that lacks parity between the timewarp controller and the engine resource depletion. I have attached a save that includes a craft that this can be done on. In my case the xenon does deplete, albeit too slowly, slowly as the solar panels will recharge the EC enough for both to deplete, but the same principle applies. Included Attachments: quicksave_433.json .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 10 | CPU: AMD Ryzen 7 3700X 8-Core | GPU: NVIDIA GeForce RTX 3070 | RAM: 15.95 Severity: Low Frequency: (Unsure) I did a Jool atmosphere dive today and noticed that when I got below a few kilometers above sea level, strange pitch black markings appeared in the sky. Might be related somehow to cloud occlusion? Or map UI? One of them appears to be an arrow, and they seem to be symmetrically ordered, implying that these are icon graphics of some sort, but I'm not sure. More of these appeared incrementally as I descended lower. My graphics drivers are up to date as of yesterday. Screenshot attached. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 10 | CPU: AMD Ryzen 7 3700X 8-Core | GPU: NVIDIA GeForce RTX 3070 | RAM: 15.95 Severity: Med Frequency: Med I just sent a very large craft to Jool. I was getting extremely low framerates on launch and transfer, but I expected this given the part count. At Jool I split the craft into seven sub-craft, and moved them all away from each other. While this did reduce the lag somewhat, it did not reduce it to the extent I would expect for just one of the sub-craft on its own. I later staged off roughly half the mass of one of the craft, turning it into a fairly small low-partcount station, and was still getting slideshow frames. Upon saving and reloading to the same craft in the same situation, the framerate seemed to near double, so I think there may be some issue going on here with decoupled craft staying partially loaded.

I think this might be the direction vectors being calculated from the point of control rather than the craft CoM, meaning that distances and speeds in relation to the target change when the craft rotates. Would need to test to be sure, however.

I never had major issues with the KSP1 CommNet causing lag. It was always due to part count. Honestly the KSP 1 calculation system for CommNet seemed pretty robust. Obviously I doubt they're as-is compatible in any sense but if the devs just ported over the exact system from KSP 1 and then maybe iterated on it a bit I would not be unhappy with that at all. Pretty sure that the CommNet geometry calculations were a layer over the top of the game and could potentially be implemented as a self-contained module irrespective of whatever new engine features have been added.

A lot of people from reddit have been saying that they thought the same as me; that the lack of full CommNet was an EA thing and that it'd be in a subsequent patch. I think most people are assuming that, and so I think that the importance of this feature is greater than you might thinking looking solely at responses, because people seem fairly unimpressed when told that this might be the final planned system.

Can confirm still very much a major issue.

The route: The vehicle (including some battle scars from crashes I didn't both to revert): Valentina, previously stranded, is now safely back in orbit, and I have a new in-depth insight into the KSP 2's quirks and issues involving ground rovers, typical surface glitches, and save/load mechanism. The journey took me in excess of 7 real world hours, I didn't count exactly. Using the distance measurements to my vessels as an approximation, I drove approximately 240km, or 120km there and then back. Most of that time was spent loading quicksaves. (The game should really not just infinitely generate new quicksave files; I have had to delete several hundred manually to stop them piling up). The KSP 2 kilometre-floating-zero-reset glitch with rovers is loveing awful and makes long distance ground vehicle journeys like pulling teeth. Every 1000m your rover will spin around, and there's a 30% chance you won't be able to recover. Loading in KSP2 is weird. It often takes a while for the loading quicksave bar to even appear. It happens a lot faster if you load after getting the "vessel crashed" screen. I don't know why this is. The orphaned particle glitch affects rover wheel dust as well as rocket plumes. It is also tied to the local coordinates instead of world ones. When I eventually took off again, I managed to carry the perpetual wheel dust of my rover into the upper atmosphere with me, with it warping back to my lander every kilometer, falling behind, then reappearing again. There are some terrible performance issues with ground rovers. This got better over time, but only after time warping to night for the first time. This was irrespective of graphical settings or other craft being loaded in. Initially I was getting 10 fps. Even with decent 1x framerates, they absolutely tank when using timewarp. Because of the low framerates, even 4x timewarp resulted in the game only running approximately realtime per the in-game clock, so I did essentially the entire drive in "realtime". I am a maniac, but devs, please fix the ground rover bugs next patch, I shouldn't have to be as much of a maniac as I proved to myself I was by stomaching the worst glitches doing this. Oh, and doing all this somehow entirely broke the KSC! Look, it's all dark now, and my rover wheel dust from Duna has followed me back! Additionally, attempting to load the rover again on Duna after seeing this broken main menu revealed that it had been turned into a mess of square textures covering the screen, and Valentina was somehow aboard the rover, despite actually being in orbit. Thankfully, starting the game and loading the most recent save resolved all of this.

Graphics settings did not affect this at all, reckon it's a CPU-bound issue.

Something else very confusing; I timewarped to night, and suddenly I'm getting roughly twice as many frames, despite loading another vessel in. Some strange things happening with planetside performance. Maybe something to do with solar panel tracking? I'm spitballing though.

It's the same one from a bug report (unrelated) I put in yesterday. Interestingly, the performance seems to be less bad when moving at higher speeds? Or maybe it's because there is less complex terrain on the flats. Hard to say.

I'm running an 8-wheeled rover with Duna, which I had hoped to drive quite some distance to do some Kerbal pickups. I'm noticing however that my performance on the ground is terrible. Even with no other nearby craft loaded, I am getting 10fps or less. This is weird because I had much better performance landing on Duna which had the larger landing craft loaded in, and earlier I was docked to a large orbital station, with a craft that was carrying this same rover, and my performance wasn't this bad even then. Turning down graphics settings doesn't seem to help. Is there some issue with rover wheels that is taking my framerate perhaps? Any workarounds?

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 10 | CPU: AMD Ryzen 7 3700X 8-Core | GPU: NVIDIA GeForce RTX 3070 | RAM: 15.95 Frequency: High Severity: Low I'm not 100% sure that this is a bug, but it feels wrong to me. In my mind, setting the control point to "forward" should face... well, forward, with the Kerbal inside looking out the window as would be the case for an eventual inside-pod POV. Instead it points out the back, where the hatch and ladder are. This has resulted in some of my craft controlling in the wrong direction. At the very least, there should be an option to flip the control orientation to point forwards out the window in the dropdown, as this feels natural for rovers and so on.