boolybooly

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.

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 - input settings are saved and reloaded Observed Behavior - saved input settings are overridden by defaults in new boot session Steps to Replicate - Fixes / Workarounds (if known..) - A list of ALL mods. none Other Notes / Screenshots / Log Files What is happening is I reset the W and S keys to S and W, I reverse their pitch effect so they correspond with the navball movement (instead of being inverted for pitch but not inverted for lateral controls A and D). The settings for pitch input are consequently applied reading [S W] and this works fine for the boot session, between reloads etc. Every new boot session for my PC when I fire up KSP2 for the first time and go into the saved game previously played, the gameplay effect of W and S keys are reversed from the way I saved them in a previous play session. The input settings still read [SW] not [WS] as for default but that is not what is happening with the navball relative to key presses which is inverted again as if reverting to default. To get the input working again as I want I have to reenter the exact same input change which saves as [SW] again and apply and then it is back the way I want it. Expected behaviour is that the saved setting for input keys is reapplied as it was saved and is not overridden by defaults when first starting KSP2 in a new boot session.

Thanks for the infos vid, readers can view a discussion of Kerbal assymetry at time segment 5:35 - 6:15. I was expecting Jeb to be as handsome as Val is beautiful, for equality and was disappointed. I like the idea of characterful Kerbals but the three originals look a little too ugly and remind me of Vince from Rex The Runt (early absurdist oddball Aardman Animation TV series) who has Random Pavarotti Disease and is disturbingly eccentric, given to eating Chihuahua's and randomly making statements like "I like Jam" and "Tuesday" and outbursts of Pavarotti classics like Figaro. Maybe I have been traumatised by British TV but I just dont feel that is the look they should be going for like I say I just feel the staring wandering eye could be dialled back a bit.

Same thing happened to me, with a launch from launchpad2. Eject solid boosters with separation thrusters built in and trajectory line for main craft is gone.

Jeb Bill & Bob kerbals have all got assymetrical eyes which look wierd and disturbing. One eye is distended and looks manic, without an eyelid and seems to be a mad staring eye, the other looks normal. The combination is odd. Val is beautiful with symmetrical eyes, as are all the other Kerbals' eyes. Maybe the intent was to try to give them a special steely eyed missile man look but imho its not working, suggest adjusting this and dialling the mad staring eye thing back a bit.

This also applies to the AP and PE markers, which you cannot see at the same time as adjusting a maneuver node. AP and PE marker infos are not reliably displayed on mouseover most of the time. The workaround is to left click blank space and try again when you might get lucky, this looks like a focus issue where focus on some other object is obstructing AP PE info popup on mouseover, which is should not. Once you get it up, if you lose it you cannot get it back again until repeating the above workaround, which is not as it should be. If you can right click the AP or PE info when it is up it will stay until you click a MN, when the focus change the AP PE info vanishes which is undesirable as MN adjustment requires knowing what it is. If the right logic was applied to enable real world usage it could be a really slick and useful interface but as it is, the wrong focus and visibility logic has been programmed making it really difficult to use FYI This is also a problem with KSP1 so I would urge devs to give top priority to making it work right with KSP2 because the interface is where the game meets the player and it has to be right if you want the game to reach its potential.

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 should collide with planet surface Observed Behavior - Craft does not collide with planet surface Steps to Replicate - save with craft landed on planet, quit, reboot, reload Fixes / Workarounds (if known..) - reload the game save A list of ALL mods. none Other Notes / Screenshots / Log Files I have just had the exact same problem as MarkAtk loading a gamesave immediately after starting the client, with a craft landed on Minmus. It just sank straight through the surface, but obeyed thrust physics. Here is a screenshot of halfway under the planet with thruster firing. Fix as above was to exit to menu without saving and reload the game save, when it worked as expected. Only the first load of the play session seems to have the problem of surface collision not being present.

Minmus today, with Bill. Am beginning to get the hang of it.

Went to the Mun and back. Booked Jeb in to see an opthalmist.

There is a lot to like in KSP2 launch version and I enjoyed getting Jeb to land on the Mun and back to Kerbin by the skin of his flight suit. Graphics are lovely. Fuel balance seems interestingly different from KSP1 but there are bugs interfering with gameplay. I have to say I noticed quite a few things that deserve fixing. I am sure intercept devs know this but I will try to be useful by itemising the ones that I encountered as a player and which stuck in my memory. Firstly the Kraken is alive and well and living in low Mun orbit. I noticed creeping PE and AP values in low Mun orbit below 20km, also apparent tank draining after lift off to return from Mun, even in timewarp, when engines were shut down by pressing X, which continued until above an altitude of about 20km. This cannot be atmospheric drag from a light atmosphere as the engines were shut down, so there is a bug in the midst of low orbit calcs. Could not double click the Mun to focus on it in map, unlike Kerbin and unlike the tutorial advice, had to right click and select focus for the Mun. Also the ship just exploded spontaneously in low orbit when applying time warp during a fairly swift rotation and then coming out of timewarp. Just blew apart, spaghettified. Luckily I was able to reload. Fairings (interstage scallop type) also repeatedly jumped about as they drifted away after separation. I got a vessel recovery tutorial message on landing on the Mun. Surely you should not be able to recover a vessel from the Mun (I didnt try) and the message should only apply on Kerbin? The navball is illegible at 1080p. Cannot read the numbers properly, they are too small and are pixelating. I would comment there is a lot of navball display area being wasted with thick black empty borders, which we dont need and the navball could probably be >10% bigger if these were removed, the other indicators in the central roundel optimised (moved out and slimmed) and the numbers on the navball given a larger font too. The peripheral shading/dithering on the navball to indicate spherical shadow doesnt work very well as it is obviously pixel sized black dots when the shade of the ball hue needs to be greyed. Wrong effect is being used here imho. EVA input control settings have the jetpack RCS down button hard coded to left CTRL. You cannot change it to any other value. I usually set mine to E and up to Q. You can change the up key from left SHIFT but for some reason not the down key. Looks like an oversight. That will do for now, looks like you have plenty to do but I will try to help.

I am just drawn to be part of the future for Kerbal and Human kind, like a moth to a fusion torch!

Well I haven't tried KSP2 yet but in KSP the shape does not make much of a difference that I can tell. It would be nice if it did, one hopes it would but its not that complex an aerodynamic model. As I understand it, HarvesteR (Felipe Falanghe) had decided that KSP was focused on rocketry, which is fair enough as that is the core gameplay of KSP. So wings use a straightforward model with a lift value and an attach point in KSP and the changing shape simply changes the amount of wing area creating a lift value and maybe the attachment point location. If you see no change in the drag indicator on changing the KSP procedural wing shape then if it is not a refresh bug it means there is no difference because the two wings have the same effective function and the aerodynamics model has remained relatively simple. I dont know if that is the case but I think that is a likely explanation. Saying that HarvesteR has since started developing a game called Balsa, all about winged aircraft models, on Steam EA though it is very early days! I think the aerodynamic model in that does mean wing shapes make a difference.