purpleivan

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.

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: The node adjustment GUI should be drawn on top of the contents of the scene, so that all parts of it are visible at all times. so that they are displayed in front of the render of the scene and not intersecting it, hiding parts of it from view. Observed Behaviour: The node adjustment GUI appears to be rendered into the depth buffer as if part of the scene contents, so that parts of the GUI visually intersects bodies (typically Radial In), if close enough to them, hiding some of it from the player. Here are two examples of this. Steps to reproduce: Launch a vehicle and place it in a 75km orbit or Kerbin. Add a manoeuvre node on the orbital path of the vehicle and click on it to display the adjustment GUI. Zoom out to a difference that gives a similar view of Kerbin as in the image of it above. Notice that the arrow for Radial In is visually intersecting Kerbin (although it is still interactable). Notes: The behaviour of much of the "in scene" GUI is like this, I've used the manoeuvre nodes as an example. Things like the icons used for objects on the surface of planets (e.g. for the KSC, as seen in the image below) are drawn camera aligned, so when the camera is rotated, their angle to the planet changes, causing them to cut into the surface of it. These also should be drawn on top of the scene contents. However, this behaviour is not consistent, as the PE and AP markers on trajectories are always drawn in front of bodies, something that can be seen in the image below). Notice how on the KSC icon at the right side of the equator is partially obscured by the planet, hiding the part of it with the rocket launch part of the icon image.

I had a similar issue but reversed, with a game save that I loaded after landing a capsule on a beach to the NE of the KSC. Jeb camera was looking at Jeb who was standing next to the capsule on the beach, but instead of the HUD you'd expect for EVA, the Space Center menu was displayed and the EVA controls did nothing.

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]) Description: Expected Behaviour: That the entire manoeuvre node GUI is displayed at any angle of view when close to a planet. Observed Behaviour: That the Radial Out arrow disappears at some view angles (seemingly when it is close to overlapping the center circle of the node GUI), when close to Kerbin. Steps to replicate: Put a vehicle into orbit of Kerbin (365km was used in my example images) Go into the Map view. Create a manoeuvre node on your vehicle’s trajectory. Click on the node so that the 6 arrows adjustment GUI is displayed. Rotate the camera, so that the angle of view to the node is approximately the same as that in the angle in the image below. 6. While holding the right mouse button move the mouse up and left, so that the angle is similar to that in the image below. Notice that the blue Radial Out arrow has disappeared. Other Notes: The issue only seems to occur when the node is close to a planet. I burned so that the vehicle was on an escape trajectory of Kerbin and placed a node on its trajectory, at about 2000km, which was not affected by this issue.

I have a similar setup to many on the thread (GTX 1070 and a Ryzen 5 2600X) running at 1080p and getting (as you might expect) similar performance. The graphics settings seem to make very little difference, either to performance or to the visuals. On the pad before launching, looking at the stock Kerbal K1, I get 31fps with graphical settings at minimum and 29fps when set to maximum. The most noticeable thing is a drop in shadow draw end distance and quality (where shadows are seen closeup) Strangely, only one of the 3 settings for "Environment Props" actually works (Environment Prop distance), Off and density do nothing. That being said reducing prop draw distance makes little difference to performance. Looking at the LODing of the rock scatter objects, it looks odd. When pulling the camera back I could see a drop in LOD level, when there's a change in the texture resolution, that appears to drop several MIP levels in one go, but at that distance there's no apparent drop in mesh detail.

I have already said that any performance test that we come up with would of course ask those posting results, to include the resolution that they ran the tests at, as part of their system description. That is because (as I have already stated) resolution would be a critical factor in the FPS figures obtained from the test. In the context of what I have stated above, I don't see what you are trying to get at in relation to the tests that we were trying to specify on the other thread. I wasn't disagreeing with you about the importance of the resolution the game is rendered at. However, you are now quoting things that I have said about our efforts at defining the scenarios for perf tests. with a reply that suggests we are ignoring the impact of render resolution. That is something that we were clearly not planning to ignore.

I'm sorry, but the relative performance of specific hardware and that hardware's perception of being "high", "low" or otherwise, is irrelevant to a discussion of the content of performance tests (the subject that was being discussed on the other thread). We simply wanted to put together a set of standardised perf test, that anyone who could get the game to run (regardless of perceptions of their hardware's performance), could carry out and so collect a set of useful data.

I think my original reply to this was lost when I hit Submit Reply, but it was to a thread that by then didn't exist thanks to the merge I'd say that the "Kerbal X to the heavens test" is a fine one at the lighterweight end of the spectrum, as the vehicle has a pretty low part count. I'd add something to say "Don't move the camera until at over 70km" just in case people think it's ok to move it once over the pad and in the ascent. In addition I think a little more detail for the +70km test items would be good. For the "+70km" I'd add "make sure that none of Kerbin is in view" if that's the view we want for that test item. For "+70km, looking towards Kerbin." I'd add something like "make sure Kerbin fills the screen". As for other tests, I think something like the one proposed by @intelliCom that has a bunch of large boosters raging all at once would be good, especially if the vehicle is clamped to the ground, so not moving away from it's exhaust plume. As for snacks?... Aways Which is why @intelliCom @MARL_Mk1 and I have been trying to put together a set of standardised test scenearios, without which, any FPS numbers will be equally irelevant.

I was hoping that either one of the mods might have some info on that, or better still one of the developers. It might have come up in conversation at some point. Agreed that anyone providing test results needs to state what resolution they are running the game at, however the we don't need the physical screen size as it isn't relevant. Well aware of the presence of 4k monitors... have a couple of them sitting in front of me These were just examples of a specification, the final ones would of course require the use of the available stock vehicles. If we manage to go the route of using a set of game saves to allow for custom vehicles to use, then the use of stock vehicles would not be necessary of course.

Hopefully gamesaves do include the parts for the craft in the saves, the same as in KSP1, but I don't have any info on that. Anyone else know if this is how things work in KSP2?

I think having a set of games saves with the desired angle/distance already set up, with "don't move that camera!" as part of the instructions would be the way to go. That would remove small differences in framing of the scene and FX having an effect on the results. No idea of how straightforward sharing gamesaves is in KSP2 though. I'd be up for providing my own results for whatever tests are agreed on, once the game is released, so I have access to it. BTW... when I started writing up my test suggestions, I wasn't considering using game saves as a way of standardisng the camera view. Therefore my suggestions were a bit on the lightweight side (so no "Engine Cluster's from hell"), but if we make use of saves, then we'd get the range of tests that we'd want and reliable results.

Argh... a while since I edited a post here and the forum editing behaviour seems to have changed since I last did. Fixed that now... thanks! I was guilty of quickly skimming through a new and interesting thread and missed your post. Mine does indeed cover a lot of the same ground as yours. One of the main points I wanted to make in my previous post, was that the camera view when FPS times are noted is going to be critical for the usefulness those FPS numbers, hence my including that in the my test descriptions. That's going to be a key factor in determining FPS in scenarios that include visual FX , as well as the time since effects started for things like enging plume FX, as these build up over time, affecting FPS accordingly.

If this infomation is going to be useful and allow for for replicable tests, then a set of standardised tests should be agreed on, to remove as much as possible, differences in how the game is being played and viewed at the time the framerates are being noted. Here's some suggested scenarios. Static (no engine firing) tests. On the pad with the Mk1 capsule as the only part in your vehicle (to minimise the physics impact on FPS), with the camera unchanged from it's orientation when the launch pad scene loads. Wait 3 seconds after the scene becomes visible to allow for any processes related to spawning to finalise, before noting the FPS. This test should give a good baseline test of the game's performance in a very low intensity situation, in terms of both physic and graphics, and is quick and easy to replicate. In an 80-81km orbit of Kerbin in the Kerbal X1, with the camera pointed towards the center of the planet, after doing a scene game save/reload, to reset the positioning of the camera . Not Dynamic (engines running) tests. In the VAB adjust the the Slim Shuttle (or similar stock vehicle if it's not in KSP2), by moving the launch clamps out out the stage to be triggered at launch (so the vehicle does not lift of the pad when fired). Send the vehicle to the pad, trigger the 1st stage and let the engines run for 10 seconds to allow for maximum emission of plume effects) and note the FPS. This to be done in the camera view of the pad when the scene is loaded. The rocket plume effects are fill rather than vertex heavy, so it's critical to ensure as much as possible that the distance of the camera, the angle of it to the vehicle, amount of time the engines have been running, speed of vehicle etc. is consistent, for FPS measurements to have any usefulness. Therefore test of this are best on with the vehicle clamped to the launch pad and using the default camera view, to standardise that. A measurement of the FPS of stock vehicles in-flight, with their engines running would be useful, but more tricky to standardise. The same is true of re-entry effects. If gamesaves are easliy accessible in KSP2 (I'd hope that they are), then a set of standard tests could be created that way. e..g. a save of a vehicle that is mid re-entry could be loaded, the camera controls not touched and an FPS noted after 5 seconds, to allow for any build up of visual effects and settling of other state. Of course any visual or potentially physics affecting settings would need to be standardised around a minimum and maximum settings, pair of test. For those with less powerful rigs, just post the minimum settings tests, or even just 1 test if that's all you have time for. If people want to post other tests that's fine and will bring up some interesting edge cases, but having some standardised tests (with agreed names for tests to avoid confusion) will be the most useful. Standard names should be used for reporting of the agreed tests, as this would allow for a simple post of easy to understand/refer to results, such as that below, rather than relying on people repeatedly describing the same tests, with an FPS figure at the end. KSP2 Standardised test results. Standard Test Static 1 = 93fps Standard Test Static 2 =78fps Standard Test Dynamic 1 = 36fps You could even add it as a little graphic to your sig

Hmmm... looks like mine is something around a minimum spec build here, which has surprised me a bit. However, I do plan to make a major system rebuild that will match the recommended spec for GPU and go considerably beyond it for CPU. I have and AMD Ryzen 5 2600X CPU, so considerably higher spec than minimum, but not up to the recommended. However, my GPU, my trusty old GTX 1070, is below minimum spec, although not by much (about 10-15% lower than the RTX 2060 in most game benchmarks). CPU thoughts The recommended spec for the CPU surprised me as I thought it would be a lot higher than that of my Ryzen 5 2600X, rather than just the 3600X of the same series. Given that physics load in KSP1 was the defining keyfactor for performance, I expected a larger bump in the requirements of KSP2 for its CPU, relative to its predecessor, so expected the recommended CPU spec to be further beyond what I have now, as when pushed physics wise in KSP1, my Ryzen 5 definitely feels some pain. So I'd expect that either their physics is quite a bit less CPU intensive than that of KSP1, or that their expectations of what will be thrown at it, in terms of ship complextity, is lower than mine. GPU thoughts That minimum GPU spec is a bit of a surprise to me, as I use my trusty 1070 for KSP1 with a bunch of graphical addons, including KS3P (so lots of fullscreen fx goodies), and I have a good experience with that (running at 1080p), as well as a decent experience with many other games, although most with the graphical settings turned down a notch or two. The recommended GPU is what I would expect, at a 30 series Nvidia card, but having minimum spec just 1 generation lower is bit of a surprise. Because of this I suspect that there won't be much range in the scaling of graphical features, to account for lower than the recommended GPU's, if turning from max to min only gets you from a 30 series to a 20 series card. Other thoughts To me it's hard to see the minimum GPU spec that's been set, as not being a departure from KSP1's implicit "physics is King" status, to a more mainstream gaming one of "graphics is King". This is especially true when it's coupled with what seems to me, an unexpectedly low recommended CPU spec, that seems to be very much out of sync with that for the GPU. It seems strange to me that in a physics heavy game, that the recommended CPU can be picked up for under £100, but the GPU is around £1000. Yes GPU prices having been crazy the last few years, and we're talking about the recommended end of the range, but for a physics based game, the balance seems to have shifted in major way towards to graphical side of things. KSP1 has always had always had a pretty low entry level in terms of GPU, which has allow it to be played on a very wide range of machines, in many cases having much lower spec than that required by other games. However, that has definitely changed now, as the minimum spec for KSP2's GPU is a £250-£300 card and recommended is about £1000. That, plus many comments in this thread, tell me that a very large proportion of those who have enjoyed KSP over the years, will not be moving on to KSP2. At least not in the near future.

I'm a little confused by the description, especially "go to every planet in the lowest mass". Does "lowest mass" mean that I should attempt this with the lowest launch mass? Also, does "every planet" include moons (I'm assuming it does)? Finally, just to confirm, this can by done with multiple launches, so not a Grand Tour using single one? Thanks.

Hit me up with a Hard... Stock+DLC.

Shuttle era you say...

At precisely 3:47pm (EDT) this reporter was in receipt of the latest in a long line of unusual packages, of unknown origin. These packages, all of which contained a single photograph and a transcript of an astronaut debriefing, have mystified this reporter since the very beginning. Here I relate the events of the arrival of this latest package. It was a warm summer afternoon. Weather perfect to take a walk in the park, to take a dog to the beach, or to pluck truth from the sea of mysteries and lies that is life in the big city. This reporter was hard at work on the later of those seasonal pursuits, when a package was dropped at his desk by one of the secretaries from the pool. On inspection of this unexpected arrival, it was discovered that mysteriously there was no return address on the delivery note that accompanied it. Stranger still it was wrapped in what appeared to be birthday wrapping paper, featuring a cartoon animal. The wrapping paper was bound in a neatly tied, large blue satin bow. Suspecting that the contents might be something out of the ordinary and noticing the lack of appropriate identification of the sender, this reporter hot-footed it to the stairs down to the lobby. On reaching the once grand, but now sadly dilapidated entrance to this newspaper's building, there was no sign of the courier. Only the usual lobby staff were there, plus a small group of college kids, one a male, sporting a rather fetching cravat, the other two being of the female gender. I approached the male of the group and enquired if they had seen a courier pass through the lobby, but unfortunately they had not. In reply they asked if I too had seen someone, another member of their group. A male, late teens, of rather unkempt appearance, and prone to getting lost, who had gone in search of a lunch cart, or other food provision that the building might offer. The student made mention of another missing member of their group, but as my focus was finding the vanished courier, I didn't catch their name. I then headed for the back stairs, to see if the deliverer of the package had exited the building in that direction. It would be no surprise if a person so negligent as to to fail to ensure delivery with the correct documentation, would exit the building via a dingy back alley. Having made it through the maze like corridors to the rear stairs without sighting the courier, this reporter heaved open the heavy door that secures the entrance to the alley. The alley, quiet at first, suddenly burst into life when a large dog, trailing a string of sausages from its mouth, sped out of a door on the other side of the alley and ran straight across, entering a door at the base of this building. Following rapidly behind was what appeared to be a person dressed in a poor halloween outfit. No more than a sheet with a pair of holes cut in it, presumably to allow vision for the wearer. Strange behaviour indeed for mid July. With my search for the courier now at an end, I turned my back on the alley and it's unseasonable occupants and made my way back to my office. At my desk once more I was again presented with the sight of the strange parcel and pondered its origin. Was the cartoon gift wrap a fiendish clue from the sender of the package? The same could be asked of blue ribbon? What did they mean? With no other avenue of investigation available to this reporter, the only remaining course of action was to tear off the gaudy covering of the package, a disguise if you will, to reveal the truth beneath. The truth inside being another of the by now familiar large manilla envelopes, that have brought with them truths from beyond this world. Speaking of the truth, some have accused this newpaper, even this reporter, of fabricating both the photographs and the accompanying transcripts. The same documents that I have toiled long and hard to get to the bottom of their mystery. But to what end dear reader, to what possible end would I, or this venerable newspaper, engage in such chicanery. Yes, circulation has increased 270% since publication of these photographs began. Yes I have been made many lucrative offers by competing publications? Yes I have moved from my tiny desk by the copy machine to a nice office next to the editor. However these trinkets would never be enough to sway the honesty of a seasoned newspaper man. It is this reporter's opinon that there can be no doubt. This documentation of otherworldly encounters is real. These are genuine encounters with alien beings in possession of technology; which although crude, possibly poorly constructed and diminutive in size, is at least a match for the best that this nation can build. But behind the mystery of these strange alien creatures lies an even greater one. Not a question that reaches towards beings across the cosmos, but to those much closer to hand. Who has been sending this documentation and to what end, why had they not sent them all at once, and why did all the photographs smell of liquor and fried chicken. This reporter is still in the dark as to the aims (possibly sinister) of those providing these packages and their unusual contents, but all I provide to you my readers, are the facts, such as they are. The rest remains a mystery. "On EVA-2 we were making preparations for the drive from Station 2 to Station 3 and I was to taking some photos of the rover at the end of the roll before swapping to a new magazine, while Jack was seated in the rover. I was lining up a good shot of the fender repair we made before leaving the landing site. It didn't look pretty, but that tape, clips and cronopaque maps did the job. Anyway, I was about to take the shot when one of those creatures ran into view from my right. I almost jumped out of my suit, it was a hell of surprise, but at least we'd seem them before during EVA-1 and they seemed friendly enough. It leaned in towards the wheel as if it was taking a look at my handywork on the fender. Then it reached out and grabbed the end of the map and started tugging away at it. That thing was only held on with clips and tape, so I reached out to stop that creature yanking it off. But as I did that it stopped tugging and turned round looking at me with this big grin on its face. I pushed in on the shutter button to take the photo, I was hoping to get a closeup of the creature as well as the repair and as I took the shot it gave me what looked like a thumbs up sign. I guess it liked what it saw. It then turned round to my right and lit up one of those rocket packs they have. I got sprayed with dust from that thing but could see it heading away up sun. I tracked it for about a half minute before it set down on the surface, maybe a quarter mile or so away, behind a large boulder. I moved around a little to see if I could get a view at where that thing landed, but after 10 to 15 seconds some kind of vehicle took off from behind the boulder. The thing headed straight up and then pitched over in our direction, it must have passed over us at about 70 to 100 feet up, then continued on down sun until it went out of sight about a minute later. It was an open vehicle and had that creature was sitting on top of it in some kind of seat. That thing looked like it was made from all sorts of weird parts, strung together with what looked like thin metal struts. Looked like somebody slapped together parts of a ride-on lawn mower and some welding tanks and called it a day. Made my work on the fender repair look like precision engineering. No idea how that thing of theirs was capable of flying."