purpleivan

It's not dead, in fact I have the rest of the story laid out, but just need the time to work on it.

A lot of players liked the elements that you've referred to, especially the slighty (and it is only slightly) junk yard aesthetic of KSP 1, myself included. Being so overly dismissive and using the language you have to convey your opinion of them is a bad look. Additionally, for someone who's being "scarred" by it, you seem to have spent an awful lot of time playing it and discussing it on these forums.

But is there a green light mounted in the trunk for the appropriate radiactive glow when it's opened?

Could you give some details of the vehicle that experiened this issue. For example is it two vehicles docked together and does it have some some engines disabled and others enabled? Just wanting to see if there is something in common between yours and mine, that might be problematic for the game in its current state. Breaking news... I have a workaround If I undock the vessels and re-dock them, then the "Not enough fuel to place maneuver node" issue is gone. So all is not lost for my brave crew in Eve SOI. ARRRRGH!! Spoke too soon. After undocking my lander the issue is back again. At least I'm in orbit around Gilly so can waste as much fuel as I want getting back to my transfer vehicle after landing and returning to it.

Could you give some details of the vehicle that experiened this issue. For example is it two vehicles docked together and does it have some some engines disabled and others enabled? Just wanting to see if there is something in common between yours and mine, that might be problematic for the game in its current state.

Agreed, this "feature" is more of a problem than it's worth and currently biting me hard. I managed to avoid getting the errant error by only disabling my Terrier engine after going to the space center and warping, but a few burns and warps later, once in Eve SOI, the issue returned and I now have a perfectly good ship, stuck there without the ability to plan maneuvers. Something else that I noticed after initially avoiding the issue around Kerbin, was that after that, the time to burn figure was much higher than it should have been (e.g. around 10 minutes instead of 2), as if the thrust of the enabled engine was much lower than it should have been (although the burn remaining bar works fine). So I suspect that the game is calculating the burn time based on my disabled Terrier and not the enabled NERV.

Here's some more info and my save file for the issue reported. I won't give full repro steps as that would involve launching and docking 3 different vehicles, but a synopsis of the events leading up to the issue appearing is as follows. I launched a nuclear transfer vehicle into Kerbin orbit, then a tanker that docked with it and filled it with fuel. After that I launched a lander vehicle and docked that with the transfer vehicle, then re-entered the tanker. After that I carried out the next 4 steps, which seem to be critical. 1. Deactivate the Terrier engine on the vehicle (it's the only one in the game save) via the right click menu. 2. Go to the KSC and then to the Tracking Station. 3. Use the menu on the left to take control of the vehicle again, named "(Combined)-4" 4. Try to place a maneuver node on its orbital path and the error "Not enough fuel to place maneuver node." is displayed, even though the tanks are full and the Nerv engines are enabled. The order above of deactivating the Terrier and going to the KSC/Tracking Station is important, as switching the order of those steps results in the error not being displayed. I'm providing the save files for before and after the issues arises. The working version (before the 4 steps above are followed) and broken version (after the 4 steps) are here (save files are named "Broken" and "Working" to identify their state). https://drive.google.com/file/d/1siT9Fs03zyMfyQH8jtnqYlp4OCD7WNpH/view?usp=sharing My setup is Windows 10, 1070GTX and the version v0.1.2.0 of the game, which was modded at the time I found the issue, but I have since tried it with an unmodded install and that has the same issue. I'll see if I can repeat this behaviour starting with a new build and vehicle. ok, I couldn't repeat this with a simplified version of my description above, by docking a smaller Nerv powered vehicle and a Terrier powered one, then disabling the Terrier, followed by going through the KSC/Tracking Station to the docked ships, as this did not result in the "Not enough fuel to place maneuver node" error. So, it looks like something more specific is required for it to occur. However, I've had this occur twice with the same vehicles, in the same situation, except for location (once was around Kerbin, the other around Duna). Given that both times I was in the process of setting up an interplanetary transfer when the issue occurs, I think it's almost certain that when in Duna orbit, I also disabled the terrier on my docked vehicles, then went to the tracking Station (in order to use high warp to a transfer window), then went back to the vehicles and experienced the issue, just as happened around Kerbin today.

aaaand just had it again with a ship in Kerbin orbit that's brimming with fuel.

I also had this issue with a lander that had just been detached from its transfer vehicle in orbit of Ike. The "Not enough fuel..." warning came up when I tried to place a manoeuver node, even though I had full tanks and was able to burn and alter my trajectory. After I'd landed and done a reload the problem was gone.

Today... well, after a week or so of running with the v0.1.2.0 patch I think I'm going to put the game down for a while and see what it's like after the next patch, as I'm just hitting to many serious bugs to continue playing. It's a shame as (in spite of dealing with various minor issues) I've been able to venture out to multiple planets and tick them off my list of planets (re)visited, but for the last couple of days I've been fighting an unending series of major issues. These include multiple parts falling off the vehicle when it appears on the the pad, uncontrollable rolling of a large vehicle after launch, even when rigged up with a ridiculous amount of control surface area at the rear end, as well as multiple lock up's of the game (5 today). I also found that the game suddenly (from 3-4 days after installing v.0.1.20) no longer likes multi monitor setups, with the game appearing on one screen and my mouse pointer on the other, requing a semi blind trip ro the graphics settings menu to fix, each time I load. Hopefully over the next couple of patches KSP2 get bashed into a more stable shape, but until then I think I'm done, which is unfortunate as I had been thinking about starting a couple of new story series to put up in the fan art section, but I think I'll leave that until it's going to be less of a chore to make the imagery for them. I know that many are having a less problematic game experiences, and congrats to them, but it looks like I'm not as lucky. Anyway... it's not been all bad, as my team has had some nice travels since the new patch. Trip to Dres Trip to Eeloo

An additional piece of information is that the issue seems to go away (at least until the next reload) when a vehicles parts are "rebuilt" after docking with a nother vehicle. This happened to me once I docked my lander with the main vehicle, after my landing on Dres.

Looks like the same issue that a few of us have reported here.

A few from my recent trip to Eeloo.

I am also having this issue. Reported behaviour The skybox was fine when I arrived at Dres, then after shutting down and restarting the game a few hours later, the skybox is no longer visible. It looks to me that it might be rendering it as a single sampled pixel drawn to the full skybox, as the colourof it shifts rapidly when rotating the camera and the colours shown are those common in the skybox textures (greys, blues and purples). Reloading some of my other gamesaves, I get the same missing skybox issues for all that are within Dres' SOI, but the previous ones outside it (e.g. the one for my plane change burn) are fine. When switching to the map view while in Dres SOI also shows a correct skybox. System and game specs System is is a 1070GTX (latest driver as of today), Windows 10, dual monitor setup (4k each) but only using one for the game. Game version is v0.1.2.0 and I'm get this when playing unmodded. I verified local files via Steam and uninstalled then reinstalled the game, which did not fix the issue. Game files Player log and a gamesave in Dres SOI are here. Basic repro steps Launch a vehicle, fly to within Dres SOI, save a game, then reload it. After this the skybox will appear as a single colour.

I'm also experiencing this, but in my case I can also see that the resolution is also resetting to the default of the native monitor resolution (4k in my case) instead of the 1080p that I select in settings. This is in v0.1.2.0 both when moded or unmodded. Adding some information as I made changes due to another bug (skybox disappearing near Dres, that I've reported elsewhere) to my install, after which I still have this issue. The change was to nuke my install (uninstalled via Steam, made sure program files (x86) and registry entries were deleted) then reinstalled, so was able to test with a completely fresh install. After this I still experienced the issue of the Game Screen Modesetting, not getting saved. However the Resolution setting does now seem to be getting saved, which it didn't appear to be prior to reinstalling. Setup Windows 10, 1070GTX, game version 0.1.2.0, unmodded. Repro steps These work either from a fresh install, or one already used. Start the game via Steam. From the main menu screen go to Settings>Graphics and change the Game Screen Mode setting to one not currently used. Go back to the main menu and Exit the game. Restart the game, go to the Settings>Graphics menu and notice that the Game Screen Mode setting is not correct for the change made in step 2.

Have not posted to a "What did you do in KSPx today" thread for a long time... time to put that right. My brave team has headed out into the system, facing the hazards of early access space exploration, namely mission threathening bugs. Mostly of the "huh... I'm sure my trajectory wasn't like that the last time I looked at it, kind. But with grit and determination (plus some reverting to previous saves) they struck out to far flung parts of the system. First stop was the moon, then Duna, followed by a trip to the Jool system, with flybys of Laythe and Vall, as well as landings on Bop and Pol. First to Eeloo More recently was a trip to Eeloo, which is where our tale of today (well... the last couple of days actually) begins. As always, it's a tale that begins with fire and fury, in this case, it's the launch of the imaginatively names "Eeloo 1st". This arrived in orbit without a hitch, well... except for poor Bill being stuck up there on his own, the other memeber of the crew Corlo, having inecplicably missed the launch. So a 2nd launch was required, this time of the SSTO "Reuso 1", to get this mission on the road. Once in orbit, Corlo wasted no time in making a rendezvous with Bill in the Eeloo 1st. Ah yes... magnetic boots, so much better for making well times selfies with. With Corlo safely aboard the Eeloo 1st, it was time for Reuso 1 to re-enter and head for it's landing site (wherever that might end up being). Ah... a nice flat(ish) plain. aaaaand... touchdown. With the full crew aboard, it was time to head to Eeloo. Well, time to set up the transfer manoeuvre, then... next stop, Eeloo. Once in orbit, it was time to let Corlo loose in the Eeloo 1st's lander. So where to land, where to land? Ah, next to that crevasse would make a handy spot. Landing was made, but Corlo decided that as it was on a fairly steep slope, it wasn't a good spot to park, so with fuel supplies dwindling, she headed a little South, closer to the crevasse, looking for a safer spot. ok... a little too far South, and down. Corlo had to spend valuable fuel hauling the lander up a few hundred metres to the top of the crevasse again. And that's it for the descent stage fuel. With it detached, Corlo needed to make a fairly rapid landing in the ascent stage. Once down, Corlo stuffed a handful of salted choro nuts in her mouth and headed for the hatch. On leaving the pod, the lander's descent stage was visible in the distance. Time for another selfie (these kerbals and their magical floating cameras eh!). With the obligatory pictoral documentation of the trip out of the way, it was time to head back to the transfer vehicle. After a few orbits the pair of explorers met once more. Bob: "So how was it down there". Corlo: "Chilly". Following their passage to the outermost planet of the system, all that was left to do was to wait... then wait... then wait some more, for their departure window. Most of their remaining was fuel expended exiting Eeloo, but fortunately enough remained for a plane change a little to slow the vehicle down before hitting Kerbin's atmosphere. Although of course, that's not such an issue not that we're back to suicidal re-entry speeds being back on the table (hurrah!). With the pair on the kerafirma once more, it was time for some kerthly exploring... around the KSC. Step 1. Make rover and launch it. Step2. Escape the launch pad. The later was not so easy to do, given that it's surrounded by safety rail, that too several attempts at getting over (reversing seemed to be the best method), in order to escape the pad. Really... a safety rail! These are kerbals we're talking about. They live for danger. With escape made Bob (the rover's sole occupant and lover of 4 wheeled expoloration) headed for the buildings of the KSC. Well hello there "unnamed kebonaut" (ok... we all know it's Jeb, having greased enough palms with deep fried snacks to make sure it was his mug on that statue). Hello there Tracking Station, looking good in the early afternoon sun. BTW... note to engineering dept. Why is my rover floating? Round the KSC With the trip around the central buildings of the KSC completed, it was time to head out to the the further flung parts of the complex. This is one of the never used, support launch pads. Billions of funds spent constructing them, millions more on keeping them spotlessly clean and fully operational, but never licked by the flames of a rocket. What a waste! But at least the pipe trenches make for some entertaining ramp jumping. Until you get stuck of course. So, while no-one was looking, Bob took a wander under the great tracked beast known as The Krawler. Usually it takes piles of paperwork and a big blue badge to get close to one of these things. However, as it's just me and you watching, Bob decided it was worth the possible stern talking to from the Work and Safety dept. for this transgression, to get a good look. With much time spent in the rover and on some on foot, Bob wanted to end his trip around the KSC by scaling the launch pad tower. I mean, look at all those inviting steps, just waiting to be climbed. Here we go... a long vertical hike and grand views await. What... this thing's a hologram! Bob took another couple of attempts at climbing on the first step, only for his boot to fall through it. Hmmm.... billions of funds spent eh! I wander if there's a ground services engineer sunning themselves on a beach right now, looking at their fleet of sports rovers. Ah well, I wonder what holograms taste like. Hmmm... digital.

"Updated collision meshes and materials for KSC parking garage " Hurrah! Other nice things too of course, but came across this about 1/2 hour before finding out about the update, when tooling around the KSC in a little rover.

I had been thinking that once boats become a working thing in KSP2, that I'd retrace my steps in the Kerbin Sorta-Circumnavigation and take a trip around the whole of the mainland coastline of Kerbin, and compare how that looks compared with the same trip in KSP1. Weeeeell... that took playing and writing up reports almost everyday for 3 months, so it might have to wait until I do some other things, like visiting somewhere further afield than the Mun (once) in KSP2. Lots of steps to retrace.

If players are finding that their gameplay is abruptly hindered by the many mission ending bugs that are in the game currently (and I'm speaking from personal experience), then the game for them is unplayable. If others are lucky somehow, or have the huge patience to push through the bugs and mission resets, then yes the game is playable (for small values of playable) for them. However, to be so dismissive of the great many players who have bought the game, expecting a fun and at least vaguely reliable playing experience, only to find that it is very far from that, is not a good look.

Something that should be helping to maintain retention rates for KSP2, relatative this most others, is that it's a sandbox game (even if you play science or career), as your route is your own to choose and the is no end. The majority of games do have definite ends, a proportion of which of which can be achieved in 7 days, especially at the cheaper and smaller end of the range. Even it it's feature set and content is somewhat less than its predecessor, KSP2 still has a whole solar system to explore, planes to fly, rovers to drive. So that reduced feature set shouldn't have a serious impact on retention rates after just 1 week. What's driving players to cease playing is the current state of the game, which is frankly terrible, not a lack of content.

Could some of those signing the praises of KSP2's artwork, post some images of what they're seeing (they can be hidden for those who don't want spoilers) as I'm curious (and I'm sure others are too) to see what's being described. Currently the game is very buggy (I don't think that's a contentious statement), so it's time consuming and more than a little frusutrating to get to far flung locations in the game, so some screenshots would be interesting to see. There used to be a screenshots thread in the Fanart section of the KSP1 forum, which I think might be a good idea to have resurected for KSP2.

50 hours. You way more patience than me. I'm less than 10 hours in on KSP2, but I'm already done and will leave the game unplayed until there is an update that fixes a lot of the bugs. Possibly I'll spend some time in parts I've not looked at yet, with the aim of adding bug reports, but I'm not feeling very motivated to do that currently. After all, I can spend time hunting down bugs in my day job. It's not as if I'm expecting a perfect experience in order to play the game. Back in the day, when I started playing KSP (2014), it was normal practice to have to go into game save files and edit them, to free kerbals that had got stuck in bind pose and we unmoveable, or to free vehicles from docking ports that wouldn't undock. KSP2 however is different in that it's not just a number of known issues that have to be worked around, but a near constant stream of issues, many which are terminal for your vehicle and have no workarounds. The worst thing for me are not the large number of now known issues, but the seemingly endless (and frequent) steam of random issue that crop up. So far I've tried to get to the moon surface twice and both time I've been thwarted by weird and serious bugs with no workarounds. That's not to mention the myriad little issues that came up along the way, that weren't catastrophic. I just hope that enough of these issues can be fixed, before the publisher starts to get cold feet and consisders pulling the plug, at the prospect of the actual cost of getting the game into a respectable shape (which given the current state will be considerable). That would be a risky move for Take Two to make, given how high profile the project is and how large and vocal the fanbase, but stranger things have happened. Keeping fingers and toes crossed here though.

Has the way that SAS functions radically changed for the Lander Can Mk1, going from KSP to KSP2? I managed (not helped by weird fuel flow behaviour) to get a vehicle into Mun orbit, then did my descent burn for the surface. On the way down I detached the return capsule, that was still attached to my lander (don't ask why) and once separated, started to burn to decelerate, in preparation for my landing. It was at this time I found out that I couldn't change the orientation of the capsule other than roll it... slowly. Pitch and yaw did nothing. I checked the various control options for SAS in the parts menu, but changing them did nothing to help. I wasn't out of power and SAS was fully enable (not just stabilisation). On the way to the moon, SAS on the launcher seemed to work fine, on the Lander Can it seemed fine before detaching from the return vehicle, but once on it's own it was useless. So, is this some crazy new way that SAS works, or (as I think more likely) just yet another serious bug in KSP2?

Yep... just checked and it's showing up as landed alright.

Note: after a prod from @LameLefty it seems this is another case of a known issue, that the vehicle is deemed to be "Landed" (I confirmed that is the status shown for the vehicle in the Tracking Station). I'll leave the bug thread here, so that it provides more date for this issue, including gamesave files. Version: 0.1.0.0.20892 System description: OS: Windows 10 (10.0.19045) 64bit CPU: AMD Ryzen 5 2600X Six-Core Processor (12) RAM: 16334 GPU: NVIDIA GeForce GTX 1070 (8081MB) SM: 50 (Direct3D 11.0 [level 11.1]) Expected Behaviour: That all vehicles in flight have the trajectory GUI displayed for them in the Map view. Observed Behaviour: In some circumstances a vehicle can end up in a situation in which it is in orbit of a body (in this case the Mun) and have no trajectory displayed in the Map view. (see image below). Repro steps: Full repro steps would be difficult, as this occurred after placing a vehicle in Mun orbit, as well as some quicksaving and reloading, but I’m including a description of the events leading up to the issue, as well as game save files. On my first flight to the moon, I place a vehicle in orbit of it, then made a burn to lower my orbit to a few km from the surface. I then placed a manoeuvrer node near PE, ready to circularise a lower orbit. I then warped until the vehicle was near it’s the nodes , then returned to normal speed and made a quick save. A short time later, while approaching my manoeuvrer node, the vehicle ran into the terrain (high peaks on the surface), so I reloaded the save game, so that I could burn away from the surface, to avoid the collision. The collision was avoided, but when I went to the Map view, I found that my vehicle had no trajectory displayed, but from its motion it was clearly in the orbit of the Mun. Further burns to adjust my orbit did not fix this issue, as well as subsequent saving and reloading, did not either. Files: The full contents of the game save folder structure can be found here. The game being played "Test2" and the specific save to look at was "quicksave_35", as this most clearly shows the issue.