RalphKerman

I suspect this is connected to the report of "Phantom debris" that was posted yesterday, in there it is mentioned that the debris is shown as RCS thruster sometimes. Link to this post: https://forum.kerbalspaceprogram.com/topic/218030-phantom-debris-spawns-behind-vessel-during-flight/ If that is true maybe both bug reports can be merged.

I am sorry if the following sounds a bit negative or cynical.... but .... asking us for sending in craft files and "working on reproducing this" is hopefully just a copy&paste answer and not the actual intention? YOU ship a stock rocket with the game (Kerbal K-2) that has this problem as has ANY OTHER rocket that can be the most simple rocket you can make in this game: 1 command pod, 1 decoupler, 1 tank, 1 engine, hell, skip the tank, just use a solid motor, so the most basic 3-part rocket anoyne can build in the game shows this problem. And you are asking for craft files to reproduce this bug? Many people here have taken the time to make crystal clear youtube videos that show exactly what is going on. And the ones who did not do that described it very well in text form. That should really be enough as a starting point for investigations. Your answer is just a time-delay that makes me feel "They have no clue what is happening or the code is so messy they can't debug it properly". I don't want to believe that..... And speaking of "believing": Your own creative director Nate Simpson wrote today in the posting about names of vehicles not being changeable that the team "believed to have fixed that bug in 0.1.3" but it was not the case. What shall we think if you are communicating that you "believe" in having bugs fixed instead of having run tests that "proof" that the bug was fixed (which you haven't (properly) since the bug is still there). Again: Messy codebase that is unmaintainable? Or severe lack of testing procedures and protocols? I apologize, this was NOT a constructive posting but I am so sad and frustrated with the current game state that I just had to vent this thought. I will continue to write bug reports if I can add something valueable and refrain from ranting. I just love this game too much to give up on it. That's why this answer was emotional.

Very good video and with the commentary it is perfectly clear what is going on! This sums up the problem very well and is a nice compact demonstration of what happens. I am surprised about the sounds though. The mechanical "clanking" noise and that dramatic music when the pod skips up again is something I did not hear so far although I have all sound enabled and quite loud as well.

I did some more testing and it it is way more strange than I wrote in my original post.... Craft with unmaned probe cores: EC is consumed but a tiny fraction of what it should be and as @Mitokandria wrote, it is depending on decouplers. Craft with manned capsule: The behaviour is partially reversed (see description down below) Scenario 1: 3 part craft: Probe core (for example HECS, but does not matter, all unmanned probe cores behave identical) a decoupler (I used the "small" one but that does not matter also as all decouplers behave identical) a solid motor (here I used the "flea" but again: it does not matter) to make 100% sure I have no engine with an alternator that might produce some EC. Solid rocket boosters don't do that. Expectation: There is no power source so the internal storage of the probe core should deplete at the given rate stated in the VAB tooltip. Using the built-in reaction wheel should increase the rate of EC depletion when I use it in flight. Test: Craft on Launch pad, open Resource Manager window -> EC is depleted at the expected rate (btw, in the resource manager you have decimals, in the vehicle status in the upper right corner where vehicle resources are shown you round to integers, so you only see changes when the value passes .5 and the rounding down occurs -> inconsistant display) Fire the solid rocket motor and fly -> EC is depleted at the expected rate When the motor has burnt out, decouple -> EC depletion rate is going down to approximately 1/10th of what it was before for the rest of the flight -> that is wrong, it should remain constant Using the reaction wheels at any point (while engine is burning or not, while decoupled or not) does NOT increase the EC depletion rate despite the craft using its reaction wheels which should consume more power. Scenario 2: Same as Scenario 1 but instead of an unmanned probe a manned capsule was used (size does not matter, tested it with MK1, MK1-3 and the largest one (name eludes me at the moment). Result: There is NO EC depletion while the engine is attached (Craft on launch pad, resource manager open -> zero loss of EC; flight with engine fireing -> zero loss of EC, no matter if reaction wheels are used or not) After decoupling the EC starts to deplete at about 1/10th of the expected rate (same as Scenario 1) Scenario 1 and 2 (extension of test parameters): When I add several reaction wheels to both manned and unmanned craft (tried adding up to 4 reaction wheels of different sizes, all behave identical) there is NO EC used from any of these consumers, the only depletion of EC is the slow ticking from the probe core/crew capsule without taking any extra consumer into the calculation Summary: EC usage is implemented in the game but is entirely wrong. EC depletion rate is changing with decoupled state, happens at way too low rate and does not consider anything but the core/capsule.

I am in love with KSP 1 and bought KSP 2 on the first day clearly thinking that the road to a fully working and feature-complete game will be long. I want KSP 2 to be a success but my relationship with this game is a rollecoaster and with yesterday's 0.1.3 patch I have more mixed feelings than ever. Version 0.1.0 was a catastrophe for me. I have an older machine (when I bought it in 2016 it was crazy, I7 with 2 x 1080 cards in SLI, about one month after they came out, truely obscene for the time back then, only SSDs, 32 GB RAM, full water cooling, still a very respectable system which I use daily for both work and games and I can play most games very very well on it, KSP 1 runs with loads of mods smoothly and as I said I love it) and when I fired up KSP2 for the first time I had a slide show with single digit FPS when I looked around and pointed the camera towards Kerbin. Not many features at all (but I knew that of course and the long time it will take to get everything we were promised). I played for less than 3 hours, was quite sad and started waiting for updates. Did not get a refund because I want you to get my money (although the price for that quality was borderline insane) and see it as an investment into the future of the game. Version 0.1.1 and 0.1.2. were steps in the right direction. I was optimistic that we are getting somewhere, performance improved a little bit and (still without meaningful content) I could at least build a few non-complex craft, fly them, crash them and have a bit of fun. Satisfied but quickly bored I waited for this new update. Version 0.1.3. came out yesterday and I quickly saw that performance was really boosted. I now have some 30 - 40 FPS and it feels playable and enjoyable (still only built a few "your first rocket" types of craft to test stuff, done nothing "serious" yet). I even registered here on the forum and wrote several bug reports and commented on some from other people as I really want to do my part now in helping finding bugs and reporting them so your devs can fix them (I work in IT and am in a role between customers and our devs so receiving and communicating bug reports and their fixes as well as solving problems is my daily business). But this version has also filled me with great doubts. The release day was postponed 2 days because some major bugs needed to be fixed I read somewhere and they had to pass QA. And here is my biggest concern: I have no faith in your QA process anymore. Let me explain why: It took me literally 3 minutes of playing this latest update yesterday to discover 2 major bugs that are reported many times by now in the Bug Report forum. The camera bug took me exactly 2 key presses before I even launched my first craft. Make a craft, go to launch pad, press M for map, press M again to leave map and your camera is 180 degrees turned around in the middle of the launch tower. This bug is so frustrating that it kills a lot of my enjoyment when after every map switch the camera points into the default direction and the view looks nothing like what it did before entering map mode. My very first test craft (the fun craft that everyone builds, a capsule, parachutes, decoupler, one tank, one engine, built in 1 min by everybody) was launched and I flew to orbit, deorbited, decoupled and wanted to slow down and land. That's when I found out that there is no drag for the command pod in Kerbin's atmosphere. The pod accelerated till it got grabbed near the surface and blown into orbit again by some magical force (documented in the bugs reports forum and in many videos on Reddit and YT meanwhile). This is the most basic thing you can do in Kerbal Space Program. It does not get any more basic than this! How is it possible that such a game breaking bug can make it into a release version (especially since the patch explicitly states that a lot of aero rework was done and therefore I guess everything was tested and tested again and again....)? And that's where I stand now. I am happy about the technical improvement (30 - 40 FPS vs. single digt ones) but worried that even the most basic physics bugs do not get caught before a release of a patch more than one month in the making. What shall I expect from more complex topics in the future? Must I assume they are broken on release as well if QA is unable to find even basic bugs? I am still loving the game but again I am in the "waiting for things to get better" mode. No content added yet that will make playing meaningful (science mode.....) and a game state that prevents me from landing the most basic Kerbal space craft. This is a huge blow to my morale. I personally will stick around and wait for everything getting better but I fear many players will not and even more people will lose interest in the game. Please have a look at your internal QA processes, get things in order in that department and make sure that such game breaking bugs do not find their way into 0.1.4 and beyond.

From watching the video I assume BGM = BackGroundMusic The craft jumps across the waves and in some frames the altitude jumps from 0 or 1 to 2777 and the game changes the music from "landed music" to "flying music" and back as the altitude quickly returns to 0 or 1. But the music is so quiet in the video that this is just a guess from me (it sounds strange though and cuts in and out). More important to me is the question: Why does the altitude fluctuate that much 0 to 2777 can't be correct. Something strange is happening here with the calculation of the altitude level.

Same here and I want to clarify that the problem is a discrepancy between the visible button and the clickable area. The "prograde" button for example (I am using 1920 x 1080 full screen res, no UI scaling that I am aware of, everything default) ist showing its tooltip when I mouse over it even at the edge but the actual "clickable" area is much much smaller and offset to the upper right. So I need to click within the small circle of the prograde icon to actually press the button and trigger the action. I thinkt it has some relation to the new UI elements scaling that also causes blurriness on the navball and other odd stuff. So to sum it up: The tooltip shows in the right places but the clicking is not registered anywhere but within a much smaller area.

The problem persists for me when I build a "normal" craft, not just the pod. I made a nice re-entry vehicle (parachute on top, capsule, heat shield) and the "zero drag" incident happens again exactly as described. The whole vehicle has (when pointed retrograde) zero drag and accelerates till very near the surface then experiences the "slingshot" back to orbit. So I doubt they "just did not test the extreme case of pod re-entry only". I am not on my PC right now so I can't test the save/load workaround yet (nice if it really works but unacceptable from a QA standpoint).

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: Intel Core i7-6700K | GPU: 2 x NVIDIA 1080 | RAM: 32 GB Scenario: Having no engine on a craft but consumers of EC will have no effect on EC level. The level of EC remains at max no matter how long you use anything that is supposed to consume EC. Test vehicle: MK1-3 pod with 150 EC internal storage capacity, 2 medium sized reaction wheels right underneath it, a medium decoupler underneath them, a tank and an engine (mainsail, but that does not matter at all). Test: Launch vehicle to some point where it can fly for a bit, decouple the engine and tank bit so that only the command pod and the 2 reaction wheels remain. While flying keep pressed any key that performs an action that requires the reaction wheels, e.g. keep q depressed to roll faster and faster. The wheels are supposed to consume 2.xx EC per second (according to tooltip in VAB) so it should drain the 150 EC from the command pod fairly quickly. Result: The EC level remains at 150 EC without any change at all no matter how long I use the EC consumers. Either the EC consumption is 0 or the EC production is constantly at a very high level without any engine or solar panel. Both of these conditions are wrong and should be classed as a bug.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: Intel Core i7-6700K | GPU: 2 x NVIDIA 1080 | RAM: 32 GB Scenario: Brand new campaign save file, normal difficulty, no mods installed. Brand new craft (simple rocket Mk1 command pod, a parachute on top, decoupler, tank, engine, nothing fancy, just "your first rocket"). I launched to a high suborbital flight and decoupled. I activated the parachute stage with "safe release" enabled (has worked previously in KSP 2 and of course in KSP 1). The craft was high up in the atmosphere at around 2100 m/s (and with the new bug that there is no drag it did not slow down much at all) when suddenly the parachute was released (at still > 2000 m/s). Strangely it stayed there for some good 10 seconds (not doing anything to slow the craft) and then ripped off as the speed was of course way too high for deployment. Repeatable: Yes, I tried several times, always the same result. Parachute deployed at ridiculously high speed and was ripped off.

I have started with 3 completely new save files for my tests today and I am getting this "no drag" bug in all craft I created there from scratch. I watched the video of "The Aziz" who started this topic and my pods behaved exactly like that. Falling down with almost no drag and close to surface getting picked up by some strange force and thrown back into orbit like a leaf being picked up by a huge gust of wind. This physics interaction is really strange.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: Intel Core i7-6700K | GPU: 2 x NVIDIA 1080 | RAM: 32 GB No command pod gets slowed down on descent through the atmosphere of Kerbin, they even gain velocity as if no atmosphere was present. Reproducable: yes, tried it with all pods after multiple game restarts (of course each time with a brand new campaign file, deleted all saves when patch came out) Build any rocket, send it up and decouple, turn the command pod retrograde -> you will see no slow down at all, just as if there was zero drag Included Attachments: .ipsImage { width: 900px !important; }

Most simple way to reproduce: Build any vessel, go to launchpad, press M for Map and M again -> you camera is 180 degrees off from where it started in the middle of the launch tower. Win 10, Steam install, version 0.1.3 (released 2023-06-22), no mods installed