boolybooly

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.

All you need, to learn how to use wings effectively in KSP, is to toggle on the center of mass and center of drag widgits in the VAB. Make sure drag is behind mass but not so far that the authority of control surfaces cannot counter the leverage created between the two. Gravity pulls mass down and lift surfaces hold the craft up at the drag center, ideally they should be close to each other but never allow the drag center to precede the mass center or the craft will flip and fly backwards. Its really very logical. It is simply a Goldilocks problem, drag behind mass but not too much not too little and then factor in shifting center of mass due to tank draining and you are there. Procedural wings wont make any difference in KSP2 if you understand these rules, is my guess.

Phew, I can probably just about playtest it ! I think its good they released minspec before allowing any orders. I was recently thinking of going 1440p (currently 1080p) but am glad I didn't now. Saving for a card upgrade but want something more power efficient than a 2070S and I try and I try and I try and I try but I don't get no ... satisfaction!

The wiki page on the Mun might help you. There is a biome map down the page. https://wiki.kerbalspaceprogram.com/wiki/Mun

This is the point at which IMHO we should derail the hype train and play it down. If you think about it, if expectations are unreasonably high the result of reality, no matter how good it is, will be disappointment. If expectations are delusionally low then the result of reality will be happiness. Happiness will fill the internet with reports of delight whereas disappointment will cloud perceptions and make people hesitate. Which is why we should have minimal expectations for a bare bones Early Access release with half the game still a WIP. See how that works? *Grabs a shovel and adopts a workman like posture.* Nothing to see here, move along now please, we will let you know when its ready, thankyou for your interest.

Steam because it will be the majority mode, so the priority portal. I am sure they will all be looked after by the devs and none left waiting for long but if there is ever a point where a priority list comes into play, I think it is likely Steam will be at the top. Plus I already repurchased KSP1 for Steam. Plus I expect to review KSP2 on Steam, which I hope will be positive but you got to keep the devs on their toes.

Very interesting. What I am wondering is, if agencies can compete with human players guiding them in multiplayer, will it be possible to create a game mode where a single player can compete against AI agencies?