Davidian1024

Seems fixed as of 0.1.4.0

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB System Specs: Description: The extra info provided for parts seems to be displaying incorrectly. The size of the text seems extremely large causing nearly all of the text to be rendered off screen. Often the text area where the text would get displayed is blank as well. Included Attachments:

This still seems to be an issue as of 0.1.4.0

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB System Specs: Frequency: High (present in all scenarios, all different resource types) Description: During flight the resource manager isn't reporting the text values of the individual resources. It's now reporting what I assume is the variable name. Included Attachments:

Fixed!

I'm not sure where to post this, so I'm gonna post it here. For the past few days the Discord Dev Tracker hasn't been working for me. I'm seeing this issue on multiple devices. My Linux desktop, my work MacBook, my wife's Windows laptop. Is it just me? I assume not. It says: Error Ahoy! Error loading messages We are currently experiencing issues communicating with discord.

Here are some other bug reports that I think are related to this: Electric Charge Generation + Dawn Engine = Incorrect Battery Behavior Thrust while time-warp not working when above the atmosphere. Acceleration during time warp doesn't work

Thanks for the update

This is definitely still a problem. Though I think the cause might be a number of other related issues. I just tried to accelerate a Dawn/Xenon based craft to high speed to see if that situation is still as bugged as I remember it being. And yes, it is. I actually had two different outcomes. One that I think I've seen very rarely in the past, and another that seems to happen nearly every time. On the first attempt I launched a vessel with nothing but the smallest probe core, a single Dawn engine, the largest Xenon tank and two Gigantor solar panels. I got this craft out of Kerbin's atmosphere and began accelerating prograde. This time when I started time-warping I was actually still able to accelerate. But, other things were going wrong. Xenon fuel wasn't being consumed. The craft reached something like 70000m/s before the solar panels were too far from Kerbol to keep powering the Dawn engine at full throttle. On every subsequent attempt, with the same vessel, and a variant with the second smallest Xenon tank, things went very differently. As soon as I would start time-warping while my craft was already accelerating, the acceleration would immediately halt. I was able to tell that it had halted because my apoapsis stopped rising. As soon as I stopped the time-warp, acceleration would resume. On these runs I would also notice something else that definitely shouldn't have been happening. The electric charge behavior would be... wrong, in a way that's hard to describe. Here's a link to another bug report that describes it in detail: Electric Charge Generation + Dawn Engine = Incorrect Battery Behavior

I think the main reason generators exist in real life is for very long term deep space missions. Missions where the distance from the sun is so great that solar panels become ineffective. Right now it would seem that performing missions like that in KSP doesn't really make sense. I think that even at the furthest reaches of the Kerbol system the solar panels in the game are probably good enough, if the craft is only doing low power tasks. A communications relay satellite, a science gathering satellite, etc. Another reason generators might make sense is for very high speed interstellar missions. Missions involving accelerating for long periods of time with the Dawn engine. This is something of particular interest to me. I've made many attempts at creating a craft with a large amount of Xenon fuel in order to see if I could achieve something like 1 or 2 percent of light speed. I was basically trying to see how quickly I could leave Kerbol's sphere of influence. The problem is that this basically makes time-warping while accelerating a requirement. And at the moment it would seem that time-warping while accelerating is not possible. It used to work, but was broken by one of the patches. Flight Thrust while time-warp not working when above the atmosphere. If/when acceleration during time-warp is fixed, we will have one reason for generators. And for what it's worth, I think it's very likely that this will be fixed. I think interstellar will make it a requirement. This is because of the amount of time it takes to accelerate up to the speeds that make interstellar travel practical. I gather some of the real world planned interstellar missions involved accelerating for years or decades. Even right now, a vessel with one or more Dawn engines and enough Xenon should be able to reach these speeds in a reasonable amount of time. But, only if acceleration during time-warp was possible. I gave up trying to do this when I worked out how much time it takes the Dawn engines to burn through just one of the largest Xenon tanks. It's like several hours if I remember right.

The way bugs are being tracked on the forum is great. The submission form, classification system etc. Could something like that be added for suggestions/new feature requests? Sometimes a change can't really be called a bug fix, but it can still be crucial to improving the experience of the game. So called quality-of-life improvements are the main thing I'm thinking of here.

This one is definitely annoying. I swear it wasn't a thing before patch 0.1.3.0.

Oh ok, no worries then. And, I do appreciate the explanation. And I must admit, I was lazy here. Even before I made this post in the back of my mind I knew there was probably a reason there was no way to turn them on/off. I decided to just post without doing any research first. All I knew was what was written in the games info box. So, all I knew was the full name. I assumed they were some sort of reactor. I did finally go read some articles about the ones in the voyager spacecraft. So now I know. I really do love how rooted in real world science KSP is.

Whoa, no need to condescend. I don't know what real world processes these parts were modeled after. Maybe you'd be so kind as to explain.

No, EC drain has no effect here. The info on the RTGs says they're always active. I'm hoping they could change the way they work to at least allow them to be inactive until you decide to enable them. Ideally, I'd like them to be just like the fission reactor, where you can turn them off/on and control their conversion rates, etc.

The RTG-500 currently has no enable toggle switch. It runs for nearly 22 years starting from the moment the mission starts. I think it should have an enable switch, similar to the KR4-P3 deep space fission reactor. Or at least a switch that can only be enabled, similar to the OX-4L 1x6 non-retractable solar array. Maybe this is the most realistic? The idea being that once the reaction is started, it cannot be stopped. It seems to be modeled as a large version of the PB-NUK radioisotope thermoelectric generator. Both have the same lifetime. Both have the same amount of EC output per unit mass. My justification for this is that I can imagine missions where you would not want to start running the reactor until after years of mission time has already elapsed. I'm writing this after having just tried to execute such a mission. I didn't try to start running my dawn engines until after I had timewarped for a few decades. I went to start my engines to find the my RTGs were depleted before ever being used. Perhaps this is an example of the game trying to lean in favor of realism? Is the idea that it's not feasible or practical to start the reaction on the craft? Like, it needs to be started on the ground and then installed in the part? I have a hard time accepting that considering the KR4-P3 can be enabled and disabled at will.

Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB Specs: (Obtained from Steam via Help > System Information) Severity: Low (This can be worked around, but it is rather annoying. I think on rare occasion it could cause the player to inadvertently send their vessel into an uncontrollable spin.) Frequency: High (This can always be reproduced when following the steps below.) Description: Capslock is the default keybinding for precise.vessel.control. Typically the state of capslock within the OS along with the light on the keyboard match the state of precise.vessel.control. If you change the state of capslock outside of flight mode (in the VAB for example) it can become out of sync with respect to precise.vessel.control. As the UI only indicates the state of precise.vessel.control while the keys are being pressed, this is confusing at best and rather irritating at worst. Steps to reproduce: Load a controllable vehicle in the VAB. Ensure capslock is on. Click the big green launch button to start a mission. Wait for the simulation to finish loading and for the vessel to become ready to be controlled. Observe the little green arrows above, below and to the right of the navball, that indicate roll, yaw and pitch input. Press and release the Q/E, A/D and W/S keys and observe that the little arrows move the entire span of their input indicator. This demonstrates that precise.vessel.control is off while capslock is on. Turn capslock off. Press and release the Q/E, A/D and W/S keys and observe that the little arrows move a small amount respective to the span of their little input indicator. This demonstrates that precise.vessel.control is on while capslock is off. This is counterintuitive. Normally, the state of precise.vessel.control should match the state of capslock. If you switch focus to another application, say a web browser for example, change the state of capslock, and then switch back to KSP2, the game notices the state change of capslock and updates precise.vessel.control accordingly. It seems to me that there is a simple way to fix this. Have the game check the state of capslock when the launch button is clicked, or as the simulation is starting up and set precise.vessel.control to match it. Another option might be to have the state of capslock checked with every press of the capslock key. If the game can learn the state capslock is changing to when a keypress occurs, it could change the state of precise.vessel.control to match the new state. As opposed to simply toggling it with every keypress, which seems to be the current behavior. Alternatively, the UI could provide some sort of visual indication about the current state of precise.vessel.control. In KSP1 I believe the arrow color indicated the state of precise.vessel.control. Actually, both of these changes would be great to have.

I'm thinking the SWERV might not be as OP as it currently is for much longer.

When I encountered this I wasn't sure what was being displayed. It was giving me different numbers for all three different modes. The number being displayed in target mode did seem close to the number orbit mode displayed, but it was significantly different. I think it was off by 10 or more m/s.

I was unaffected by this mistake. Because of the particular way I was bypassing the launcher. When I bypass it I know I'm not using the product as intended. So, I expect to have issues. I'm using it in a way that is not supported. I think they should be applauded for being so quick to fix this. And honestly, to fix it at all. The devs are truly going out of their way by "fixing" an issue that prevents us from using their product in a-not-as-intended way. I think this demonstrates that their intentions are truly virtuous.

I want to point out that it's possible that this could be due to recent updates Valve made to Steam. The Steam runtime could've contained an update that's causing this. I can say this much for sure. It's not that the Private Division launcher is being forced to be run. It's that the Steam Client is being forced to be run. Further, the PD launcher can still be bypassed. See @Spicat's comment on how to do that.

But they're not forcing people back into using the launcher.

I don't think it did. Something may have changed, but I really don't think they did anything to force you to need to launch the game from the launcher. I say this because I'm on Linux, and I've been having to launch the game directly from the .exe for quite a while. After Valve updated Proton (the thing that let's us Linux gamers play Windows games) to version 8.0 the launcher started crashing. So, I simply can't run it from the launcher. Were people launching it outside of Steam? It could be that the latest version can't be launched directly outside of Steam. At least not without some effort. I'm essentially doing this: (mentioned by @Spicat) "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program 2\KSP2_x64.exe" %command% I want to mention that the above command should probably be this instead: (note the added #) "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program 2\KSP2_x64.exe" #%command% Otherwise %command% will be expanded to whatever command Steam normally runs to launch the game, and that will get passed to KSP2_x64.exe as parameters. Which will probably be ignored. But, just to be safe. In any case, I don't think there's anything nefarious going on here.

Both seem fixed to me.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB Specs: (see further below for how to give us all the info we need here) Severity: Med (Can be highly disruptive to a mission. Could convince you that a particular engine is active when it's not or vice versa. The workaround is to keep a very careful mental note of which engines are active and which are not.) Frequency: High (I believe this occurs all the time with all engines. I've tested it with at least one of each of the methalox, methane, monopropellant, xenon and hydrogen based engines) Description: The engine Activate/Deactivate control within the parts manager has text that changes to report the current state of the engine. This text does not seem to always update when it should. It then ends up reporting that the engine is in the opposite state of what it actually is. Steps to reproduce: Launch anything with any engine. (This could be just an engine. The new extendable engines are good choices because their extended/retracted state visually shows what state the engine is actually in.) (Optional) Cut the throttle or set it low enough to not lift off or otherwise interfere with the test. Or build a craft with the engine on top pointing up. Right click the engine to pull it up in the parts manager. Click the Activate/Deactivate button. Observe the text of the activate/deactivate control. Use other means to determine whether the engine is actually active or not. Repeat steps 4-5 as needed. Sometimes, it would take multiple presses of the button to get the state to be out of sync with the actual engine state. Also, I think that triggering a stage that would activate and engine counts as a press of this button or call to some underlying function or whatever. FWIW, I've sometimes been able to get the state indicated by the text to match the engine's actual state by changing the throttle of a running engine. At least I think that's what did it, I'm not able to get this to work consistently. I also want to stress that the way this control is designed is highly counterintuitive. A toggle switch would be much clearer to the user. Seeing the switch in the green activated state or black deactivated state would make it easy to know at a glance what state the engine is in. As things currently are, you have to parse text and imply deduction in order to determine what state the engine is in. Example(when things are working): The engine is active. The button text reads "Deactivate". If you as the user want to know what state the engine is in, you first have to parse this text, which is telling you that if you click the button it will deactivate the engine. Then you have to deduce that this means the engine must be active. Nothing actually directly indicates the current state of the engine. This is much more complicated than it needs to be. It becomes problematic if you have many engines which need to be in different states depending on your mission. Included Attachments: