boolybooly

With KSP2 I find there are some bugs lurking and rather than get frustrated I give it a try, report one or two bugs then leave it for the next update. I am confident it will be fixed I just dont want to get too jaded with it while waiting. My hope is that when all in your face bugs are fixed and it is ready to play through to interstellar, it will still seem fresh and new!

Thanks for your mission video @Martian Emigrant which is very welcome. I think you can award yourself a K-Prize plus an Utilitarial Commendation, congratulations, as always. @Vanamonde thanks for your encouragement, much appreciated. I like to think people will be doing this for real one day, when SABRE becomes fully functional, if someone else doesn't get there first! I feel sure spaceplanes are going to become an important method for getting stuff into space. Which is why I feel the K-Prize is bigger than one challenge thread or curator. TBH my secret hope is that for this reason the K-Prize mission or equivalent, to fly a space plane to orbit, will be adopted by Intercept and added as a side mission in KSP2. So for that reason I feel it is best to let go of the K-Prize and let it take on a life of its own, which it deserves. Also I am not in a position to take it further, due to difficulties created by a longstanding medical condition involving immune dysfunction diagnosed as ME CFS, which has become worse after COVID, possibly due to longcovid plus ME. I just dont have the boosters to take it on and would love to see someone else take the idea further in KSP2. What do you think?

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: i7 9700 | GPU: RTX 2700S | RAM: 32Gb See screenshot, RCS thrusters placed near to a heat shield do not operate at all. Progressively fewer of a circle of thrusters will operate the closer the circle is to the heat shield. Progressively more operate the further away it is. See attached screeny of size S set up, where there are four circles of 4x thrusters, the RCS is firing in response to two translation keys being pressed, in my case using IJKL translation keys J & K are pressed ... the row of thrusters on the right shows two thrusters firing but the row on the left shows three. This is because the second circle of thrusters is firing fewer thrusters than the third circle. Ideally all the thrusters should be firing in each active row. See screeny below of size MD, where several circles of 8 thrusters are showing differences in thruster activation related to distance from heatshield, pressing K. This happens with thrusters in proximity to all heat shield sizes XS S MD LG XL. The extent of the effect appears related to the dimensions of the heat shield. This affects all RCS thruster types but is most pronounced with the Place-Anywhere-7 Linears RCS Port, less pronounced with the block or vernier. Included Attachments:

I see, thanks for explaining. I just tried the same configuration and it messed up the thrusters completely just as you describe. Only one of the four lateral thrusters fired, on key H while its opposing key L fired one of the rear thrusters, which would mess up control completely and has to be a bug. I will try to simplify the conditions and then report it. EDIT Done, it is the heat shield, happens with all of them.

The reorientation thrust only works if you have RCS enabled so the workaround is to give a little translation thrust and then immediately switch off RCS or give the thrust with SAS disabled when you will see the craft rotate and translate from the same thrust, then switch off RCS, then switch on SAS and realign using reaction wheels only. Believe me when I say it is doable but not ideal. Best when making the craft to check CoM behaviour with full and low fuel and place thrusters accordingly. Oh sorry, my mistake, I assumed you had a monoprop tank buried in the rear half somewhere. I tried to recreate your craft from the image and the lateral thrusters worked OK using translation keys (which I have mapped to IJKL) when connected to the TD-12 stack decoupler (even with fuel pass through OFF which really shouldn't happen) or anything else. But I could not identify the tube between the TD-12 and the Explorer pod on yours. It looks like a short section of TOOB-125 but I cant see its base segment, which would be wider than adjoining structures and cannot be hidden inside them by widgit translation, so is not that, I cannot find an equivalent among stock parts. What is that?

did you check fuel pass through on the decoupler and any intervening structures was enabled? I think there is monopropellant in the capsule so you might be using that for the forward thrusters

Overflew Kerbin and gathered air sniffer data from 5 biomes for 200 points. No screenshot or else you will notice that I accidentally put the wings on in 2x radial symmetry rather than bilateral reflection *oops* Flew OK though!

Playing this I am finding the dynamics of the research look potentially much better than the original but it needs the fine tuning for progression which the original never got. So for an example atmospheric survey is in tier 2 but only provides a tier one science boost at Kerbin unless you can run it outside Kerbin SOI which is what the small light radial version is suitable for. So I would suggest splitting the two versions, as was done with the environment survey modules, and putting the heavy 1t in-line nose cone air sniffer after light aviation in tier 1 for 50 points and the light radial module stay where it is in tier 2 for 250. That way people can run some meaningful flight experiments in the early game after getting aviation.

that caught me out with Bob but I reran the mission and found the flying cylinder trick works, if you get down to 35km region you can tilt a cylindrical rocket to give lift i.e. fly retrograde and then try to get the navball pointer on the brown bit, pointing the nose down so the forward engine end lifts up and gives lift, thereby avoid plunging into the inferno of thick atmosphere at high speed and gradually lose speed to friction by skipping along at high altitude, Bob lives and he brought home the science

Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: i7 9700 | GPU: RTX 2070S | RAM: 32Gb Every time the game loads it uses default input settings and fails to load custom input settings, including reversed pitch and other commands like numpad / for staging instead of space bar. I can get it to load all custom settings by tweaking one of them, I usually reenter pitch. Expected behaviour would be to remember and load custom input settings at game start, like KSP1 did... pls! EDIT to say this is still happening in the For Science! update. v0.2.0.0.30291

Val came home from Duna.

Today the Private Division login failed and I was presented with a login screen again. Clicking login resulted in an error message, see screenshot below. Once the server got over itself, clicking login resulted in yet another login via my web browser. Part of the promise relating to using the launch screen and requesting a PD login to participate was that login would be one time only. It is not functioning as promised / intended, therefore this is a bug. Expected behaviour would be that no further login would be requested if the servers are not working, since it would be futile to request a manual login attempt at such a time QED and the only viable option is to skip it, so under these circumstances the launcher should automatically skip login. Further to this... As this must be the actual behaviour to comply with the one login promise and simple userfriendly logic, later in development the game will need to be able to relog in game if there is a log failure at startup due to temporary server glitches, in order to enable multiplayer server access without having to restart the game. This makes the pregame launcher and login redundant. This is why the login procedure should be part of a single click game launch, not a separate launcher requiring redundant clicks and waiting to get the game running which is a bad way to do it not simply because of the above experience when it goes wrong but also because of the poor user experience and gratuitous obstruction it creates even when it works right.

Suggest that when you start a bug report (or a support request) it comes with the required information headers itemised in the "Stock Support & Bug Reporting Guide" preincluded as editable text headers. As this will save everyone time and effort, will encourage good practice and an atmosphere of mutual support. I got the idea from the Empyrion boards where new bug threads have exactly that kind of support which is helpful, see for yourself at https://empyriononline.com/forums/bugs.24/create-thread .

I have also noticed the emphasis on the "very Kerbal" approach of learning through disaster being used to persuade people that if things go wrong at first it is not the end of the game and if we (and by we I mean they) keep trying we (they) can overcome the erm... misfortune. This applies to simulated rocket crashes in the physics sim and also to the bugs in the software creating the sim, is what they are trying to say. i.e. they are learning by error, which I am prepared to believe. We are too in playing the game. The comparison of errors is an attempt to communicate and explain and gain our sympathy. Its true the only way this comes right is if they do keep going and debug the game. They did give us notice of this intent before the launch if you read between the lines, by saying it was going to be like KSP1 development so I am waiting to see the proof of this with their first patches. As I said at the time this is kind of a tradition with KSP. We had a huge number of bugs to deal with during KSP development. Unfortunately we still do, in both KSP and KSP2. I am not happy with the way unmodded KSP plays at the moment, mostly to do with map, maneuvers and intercept predictions. I dont want to waste development focus on that though and would rather they got KSP2 working as that is what we will be playing for the next decade. My message to the devs would be to please make the current version more playable before adding new features, like curing the tank draining issues, both across stages and in timewarp/reload when there is no throttle but the game adds phantom throttle and drains tanks. Those are gamebreaking bugs. Also the severe Kraken shoving which is going on in low orbits increasing or decreasing AP and PE at alarming rates. This kind of thing is beneath minimum playability and IMHO these have to be fixed before trying to advance as the game needs to stay playable to succeed in EA. 2c

KSP Version 0.1.0.0.20892 Operating System - Windows 10prox64 latest CPU and GPU models, I7-9700K, RTX 2070S, 32GB DDR4 Description of the bug. Expected Behavior - craft reloads with fuel present when the game was saved Observed Behavior - craft reloads with fuel missing from active stage Steps to Replicate - Fixes / Workarounds (if known..) - A list of ALL mods. none Other Notes / Screenshots / Log Files A craft landed on minmus with fuel worth over 3000dv in the active stage (two medium tanks and a poodle) was saved. On restarting KSP2 in a new boot session and controlling the craft from the tracking building, the craft loaded with zero fuel in the active stage and zero dv and the throttle set at 100%. This is not the state it was saved in as the throttle was shut down to zero and there was fuel in the tank. The next stage still had all its fuel. This craft had no landing legs or wheels at any time and only standard engine to decoupler fairings.