Claw

Oh no, I've ignored you guys for almost a week already?! Yes, I am trying desperately to finish my Tylo mission. Which has been challenging...from both a time and adventure standpoint. It is, strangely enough. I still remember the first time I drove to Kerbin's north pole (so long ago). That felt like a long adventure, and it was quite amazing to see the varied and vast landscape. Consider this belated good luck, and current congratulations on finishing! I love kerbal powered stuff! (Though it's been a while since I built some.) I have a glider around here somewhere from a kerbal powered glider challenge. That was pretty fun! Good luck to you as well!

If you've been reading the devnotes, you'll see that there is discussion in there about where things are headed. The devnotes will likely not give you a full "road map," but it will give you a sense of what's going on. If you've read them long enough, you'll also see that there's an underlying cycle to how they progress (regardless of what format they take). The inherent issue is that with each release, the initial devnotes get filled up with all the great stuff that's planned for a particular release. Over time, the juicy details start coming out. Eventually though, it gets to the point where the introduction of new elements into a release stops to focus on the necessary bug fixing before it can go on to QA and experimentals. The devnotes start getting thin on "what's all the fun new stuff" and gets down to "here's all the bugs we're attacking and the side things being implemented." People get antsy about what's going on, but quite frankly bug fixing, balancing, and tweaking isn't particularly exciting to talk about for weeks on end. And that's about where we are in the cycle right now. Yes, and some new things have already been announced such as the multiplayer, probe telemetry, and KSPedia (all of which I will probably get nitpicked for saying.) Also, as much as I've stressed it when I was a moderator, not every feature is going to be universally excitable to everyone. The Space Plane Plus incorporation was a huge one, but there were plenty of people who didn't care because they thought the rockets needed some love first. I'd rather not get into a debate in here about what updates are the most important because it involves a lot of people's personal opinions, which are all valid, but don't always coincide. But I did want to point out that new stuff is coming down the pipe and (as was stated when 1.0 came out) development continues.

The launcher is indeed inoperative and has been for some time. Sorry for the confusion, but yes...you will have to download the updated version from where ever you purchased the game.

This one isn't really fixable via add-on, but rest assured that I'm aware of it.

I was repetitive because I'm not saying "check if they are off." I'm saying, "go back and reset everything." Because, in my case, everything was set properly but not being honored. I switched power modes and back, then reset everything, and that made a big difference.

Yes, there were a few overheat bugs in 1.0.4. Updating to 1.0.5.1028 should help out with the overheating.

@CommanderSpock If you have a stock save where this is happening, I'll see what I can do. I know of the bug where the ship warps to the ocean floor, but I'm unaware of where it flips into the air.

Which one? Are you referring to the spring up for the fixed landing gear? Or something else?

I know we're of like minds with the Elcano. I've done all of my Elcano missions in stock KSP, 32-bit (with scatter at 100%) and haven't had it crash from being out of memory in a really (really) long time. That includes many quickloads and driving for hours on end. Usually what causes me to have to restart KSP during Elcano is when the vessel just keeps wanting to randomly explode...or the kerbals ragdoll and turn into spaghetti. I'm not saying that KSP's terrain is leak proof now, but seems much better than it was (pure stock, at least). I don't know if it's fragile to add-on interactions.

When I had bought my most recent laptop, I had adjusted the power settings so that it would run pretty fast. At some point, Windows updated and it reset the power settings. It took a while for me to figure it out, because the power settings appeared to be still set, but they weren't being honored the same way that had been. So I went back and readjusted all the power settings, to include remapping the NVIDIA card for KSP and running it up to full power. As with the others, I don't know for sure that you have the same issue, but it wasn't fully obvious to me (at the time) that the power settings had been somehow reset. Might be worth readjusting them even if they look okay.

I'm sort of like a gator....at least I think they have claws. How about @NathanKell (since I know he's still awake)

I hesitate to say "physics FPS" because I don't want to confuse the difference between a physics calculation frame (where physics is occurring) and a gameplay frame (where input is taken and the graphics are built). I've been using FPS to refer to the gameplay frames, and not about the physics frames (which I've measured in Seconds / UT). Yes, any gameplay FPS above 50 is "wasted" in the sense that there will be some frames where no physics changes have happened. In that case, as you say, nothing moves for that gameplay frame. Physics updating, however, is different than the visuals updating. The user may have (for example) panned the screen camera around. In that case, the picture does update even though the physics might not have updated. Higher FPS gives the user a smoother play experience, but does not always give a good indication of physics performance. Also, the physics is fixed to a maximum of 50 physics frames per second. The physics timestep is fixed at 20ms, but it may take longer than 20ms to actually calculate the physics change. In which case, gameplay time (UT) runs slower than real time.

Every gameplay frame. I'm not sure off hand, I'd have to go look. If so, then it's handy in a certain way, but probably not useful for most people.

It's in my long-standing list of bugs to kill. It's just that it's rather difficult and time consuming to replicate. Someone did just recently hand me a save that they apparently triggers the issue a majority of the time, but I've yet to be able to sit down and play through it.

A save file might also really help out in this case.

Yes, [KSPField] has to be right before the variable definition, and is a way of telling the game "Go look in the .cfg file and see if there's a specified value." If there's not a value in the .cfg, then it'll use whatever the variable initializes to in the variable definition. Without [KSPField], the game doesn't bother to go look in the .cfg and just uses the initialization value from the variable definition. So in this case, even though it's specified in the .cfg, KSP doesn't bother to go look.

In addition to what Padishar said...if it only takes 10ms to calculate the 20ms timestep, KSP does not move to the next physics frame because then (at 1x warp) game time would be happening faster than real time, and it's no longer 1x warp.

First (so that it's not confused) the accuracy of physics are not at stake when using the Time-Delta per Frame slider (that's a main point of my writing the original post). Moving the slider around does not change any of the math during a physics frame. If you want more FPS, then generally set the slider lower. 0.04 is the default, which gives a minimum of 1 graphic frame per every 2 physics frames. You are telling the game that you would rather do fewer physics calculations per second in favor of keeping the FPS up. However, setting the slider to 0.04 does not guarantee a set FPS, because the game will still only show graphic changes after it's been able to calculate at least two physics frames. So if it takes a full second to calculate two physics frames, then you would still only end up with 1 FPS. Maybe another way to think of it is as if you're telling the computer: A low slider value (0.04) means "Keep the FPS up, even if that means you have to slow game time progression." A higher slider value (0.12) means "If you start having any problems keeping up with physics, ignore FPS." With a high slider value (0.12) it's entirely possible to get to orbit with a big ship at 9 FPS in the same amount of real-life time as a smaller ship that's running at 60 FPS. My pleasure. Hopefully it'll help some folks out. It's pointless from the standpoint that you're not necessarily helping KSP out for physics, since (to some extent) KSP already dumps FPS in favor of physics. The default slider set to 0.04 means that physics will not start to "slow down" until the FPS goes down to 25 FPS. It can, however, help in the sense that when KSP does start to slow the FPS down, you won't really notice it as much. Sometimes when people go from 60 FPS to 25 FPS quickly, it's more jarring than if you're already used to seeing 30 FPS, and then it slows down to 25 FPS. So it's a bit of a personal perception thing. The other thing it can help with, is when you do have spare CPU/GPU capacity, you're not letting KSP constantly use it up. Which can mean an overall cooler running computer (since it's not working at full capacity all the time). This can be handy for older computers who might not have as good of cooling capability as they used to...or on a laptop if you want to try to save some battery life (and you're happy with 30 FPS).

I didn't mean to get hung up on vernacular, since each OS has it's own style. "Force quit" isn't really defined for windows, since it's "End Process" (and even then, it varies by Windows version). ALT-F4 makes KSP immediately stop playing, regardless of what it's doing. Which means if it's in the middle of writing out the save game, it simply stops. (Which was what I was meaning to convey.) In either case, your statements remain valid. It would certainly be nice if KSP didn't corrupt the save when pressing ALT+F4. I personally don't know if that's "just how Unity is," or if it can be captured...but probably something to look into. A smoother "Exit To Desktop" option (as originally suggested) might also be handy. But right now, if using ALT+F4 to exit the game in-flight, the safest way is to press escape first to pause (so it doesn't try to save), then press ALT+F4.

Yes. In fact, that's where I ALT+F4 out of probably 90% of the time.

Yep, this one. Phys warp increases the timestep used in physics calculations, for all levels (2x to 4x). (ninja Padishar)

Yes, that was a typo (now corrected and annotated). Thanks The short answer is that it's locked to UT. 1 UT second is always 50 physics frames because each physics frame is locked to 20ms of game time (UT). The game tries to keep 20ms in UT equal to 20ms of real-time, but when craft get large and things get laggy, that "real time to UT" relationship starts to break down (hence the Seconds/UT). Real-time continues at it's normal rate, but UT slows down because it takes longer for the game to do all the math required to calculate the physics change of that 20ms step. In other words, it's physically taking more than 20ms of real time to calculate the 20ms of physics changes in-game. The game never increases the physics step size to "catch up" to real-time.

Please try not to infer meaning where I intend none (it's tempting, I know). My aim really is (as I've done as a community member in the past) to explain what some of these esoteric things are, and how they impact the game. Like I said...I was surprised at some of the folks I know directly who have played for a long time and misunderstand how all this ties together. I was guilty of the same thing once upon a time, so I thought I'd share the knowledge.

It's not exactly a tell tale of anything. Every update has an impact on performance. Consider, for example, the impact to 1.0 and it's overhauled aero and thermo. But really, at the moment, I'm more interested in dispelling the myth that KSP's measure of performance is rooted in FPS. I've seen this question of FPS come up several times lately as 1.1 approaches, and I was actually surprised at the number of veteran players who still misunderstand the slider. As you're aware, KSP performance is much more complex than what FPS portrays. Seeing statements such as "doing XXX doubled my FPS" doesn't necessarily mean that it's double the physics performance. It might look like better performance, but I wanted people to be aware of what actual performance they are getting...so that they make their choices with proper information.

This question has come up a couple times recently, and after some discussions, I've realized people still aren't sure about the concept of FPS and Physics Timesteps in KSP. KSP is physics bound, and will be for quite some time (if not always). Plus, with 1.1 looming around the corner, now might be a good time to discuss FPS and physics, since 1.1 will definitely have an impact on performance. Additionally, people may misinterpret low FPS in KSP as (by itself) an indicator of poor performance. While FPS and physics are linked, KSP offers a somewhat unique tweak that most games don't have, the "Max Physics Time-Delta per Frame" option (which I'll call Time-Delta). That Time-Delta slider will be the "TLDR" outcome of this explanation, but it'll take a moment to get there...and I know how this forum likes details, so here we go. Historically, the Time-Delta tweak has been understood that "lower is better, drive that thing down to the lowest value (0.03) so that your ship doesn't fall apart." However, that's not exactly true. The Time-Delta setting has no impact on the physics timestep. It will have an impact on visible game performance, but not the physics timestep itself. In order to understand what it's really doing, it's important to understand that KSP runs gameplay frames and physics frames. (Probably most Unity based games do, but KSP is especially physics hungry.) Gameplay Frames: Where all the overhead of running the game occurs, such as checking user input and building graphics frames. Physics Frames: Where all the internal interactive parts of the game occur, which includes things like calculating engine thrust, wing lift, aerodynamic drag, and all the rigid body (classic physics) interaction that goes with it. The two actual measures of performance for KSP that the user sees: Frames Per Second (FPS): Most people latch onto FPS as the measure of performance for traditional reasons. Many first and third person perspective games have direct linkages of FPS to gameplay speed. If the FPS is really low, the game itself also runs quite slowly. Gameplay speed (things moving, monsters shooting, etc...) is directly linked to the ability of the game to pump out frames. FPS isn't directly shown in KSP, but people seem ever in search of an FPS indicator. Real Time per Gameplay Time (Seconds per Universal Time) - KSP's performance is highly bound by physics. Game-time passes in the form of Universal Time (UT) and is often visible as that little green and/or yellow (hopefully not red) blinky time stamp in the upper left corner. There's no direct measure of how many real seconds of time is passing for each second of UT, but KSP's physics performance is tied to this statistic. Maximum Performance: In KSP, FPS maxes out at 60 frames per second (or whatever you have your max set to, but lets use 60 for discussion). This means that the gameplay frames happen 60 times per second. It's important to note that this isn't tied to physics calculations, which is (again) the bottle neck in KSP. Seconds/UT can never be less than 1 when running at 1x timewarp (i.e. can't be less than one second of real time to do one second of game time). The physics timestep is fixed at 20 milliseconds (ms). So, if I'm doing the math right, that means that there are 50 physics frames per second. So together, at maximum performance, there are 60 gameplay frames, and 50 physics frames running every second in KSP... What happens during lag? -- When the game starts to lag, both the FPS and Seconds/UT start to suffer. FPS - FPS starts to decrease, and the user sees this directly. The game starts to take longer to display each frame, and the game begins to look like a flip-book or slideshow. It also may become less responsive to input, unless the user is holding down keys. Seconds/UT - The Physics Timestep never changes, it's always 20ms. That means that when things start slowing down, the Seconds/UT goes up (more real-life seconds pass for every second of game time).There are less physics frames being calculated each second, so it physically takes longer for your ship to go some fixed distance. If it takes 2 seconds of real time for every 1 second of UT, then physics is only running 25 frames per second, instead of the maximum 50. But Claw, you told me FPS and physics are not interlinked, but it sure sounds like they are. I didn't say they aren't interlinked, just that FPS is not the sole measure of performance in KSP (though it seems to be the one many people focus on). They are, in fact, interlinked directly through that Time-Delta slider that I mentioned in the beginning. So then what is "Max Physics Time-Delta per Frame"? It's the user's way of saying, "I'm willing to let X amount of physics time to pass for each gameplay frame." The user is directly trading off gameplay frames for physics frames, but only when physics can't run at 50 physics frames per second (i.e. more than 1 second passing for each gameplay second, or higher than 1.0 Sec/UT). So, at the default setting of 0.04, the Time-Delta indicates that "I'm only willing to let 0.04 physics seconds pass for each frame that I see." Or, up to 2 physics frames per gameplay frame. What? So at the default Time-Delta setting (0.04), if a ship is getting 15 FPS (out of a max of 60 FPS), it is still calculating 30 physics frames per second (out of a max of 50). So running at 25% of the FPS is still giving 60% of the physics speed, and 1.67 Sec/UT. If FPS was the direct measure of performance, 15 FPS would result in running at 4 sec/UT. So what does that mean for the slider? (Here's your TLDR.) The player has a bit of a choice of how much FPS to sacrifice for physics (and game time) to progress "normally." A higher Time-Delta setting, say 0.12, means that you're willing to let the computer spend more of it's time calculating physics than at a setting of 0.04. Up to 6 physics frames (at 0.12) can pass instead of 2 (at 0.04). When the computer can't keep up with doing 50 physics frame calculations per second, it will start to sacrifice visual frames. At worst, it will only show 8.3 FPS (slider at 0.12) before starting to sacrifice physics speed. So in this instance, while the game will only give 8.3 FPS, it'll still be running at 1 Sec/UT, or "real-time" physics...pumping out 50 physics frames per second. It's important to note that this isn't a 1 for 1 trade. The game isn't converting 10 gameplay frames into 10 physics frames, just that it's spending less time doing the gameplay frames in favor of the physics frames. This is why FPS isn't the pure measure of performance in KSP. -- Indicator? Yes. Only source? No. It's entirely possible to have low FPS, but still get your ship into orbit in the same amount of real-life time as someone with a "beefier" computer who gets to see a less "choppy" version.