Thanny

I recently accepted a mission to test the KR-2L while splashed down, because it paid a goodly sum. I realized too late that it also said on Eve. So now I have to go fly a huge %?$#ing engine to Eve and drop it in the purple soup. I'm going to use an ion drive for the transfer.

The orbit changed without me adjusting warp speed - KAC did all the adjustments. And it only happened when in ship view, not on the map. And it wasn't the controlled ship which had its orbit changed. I do still have the save, but I can no longer replicate the orbit change. It was apparently tied the running game state. All the other cases I've encountered (somewhere around a half dozen) in the past were also with ships not undergoing SOI changes and on rails the entire time. I'm leaning towards it being some kind of buffer overrun. If I ever find a reproducible case again, I'll run through more scenarios, and also dump the process memory.

You need fuel lines, separators, and struts. All else beyond the basic rocket parts is gravy.

That's a maneuver that a lot of real airplanes can do routinely, so not a very good example of something silly.

I know what you're talking about, which is why I let KAC add SOI alarms by default, and try to go through them with the active ship at normal speed. However, in this case, neither the ship I'm controlling nor the ship that has its orbit changed undergo any SOI changes during the time warp in question.

Is the problem I describe here plausibly caused by KAC?

Yes, KAC halted the warp. Can you explain what you mean by higher than normal and stock warps? I don't have any mods that affect warp speeds.

I've been playing KSP since 0.23.5, initially without any mods, now with the following: Editor Extension Enhanced NavBall Kerbal Engineer Precise Node TAC Fuel Balancer Kerbal Alarm Clock The problem I'm talking about here is returning to a ship that's been on rails for a while, only to discover that it's way out of its original orbit. I'm all but certain that I saw this in 0.23.5 with no mods installed. At a minimum, it would be with only KAC installed, which I now consider essential to sanity. I recently had it occur twice within a couple days in the same career. The first time, a ship was on course from Duna to a Kerbin intercept, but after controlling a number of other ships and time-warping, I found it was no longer on that course at all, but instead was in a strange orbit with perihelion inside of Eve's orbit and aphelion inside of Kerbin's orbit. I backtracked among the available saves (KAC's backup on ship jump feature comes in handy) until the orbit was back where it belonged, and proceeded from there (with plenty of repeat burns and time-warps, each followed by checking the return ship's orbit). The second time, it was a different ship which was on course from Kerbin to Duna, with a maneuver node at an inclination node to adjust the intercept. When that node came up in KAC, I found the orbit was changed significantly, so that the ship was no longer intercepting Duna. I again backtracked until I found a save with the correct orbit, and when warping a particular ship to redo its burn, found that the orbit changed again. I was able to repeat this process several times - reload the save, warp at top speed for 30 days, see changed orbit. It only happened when in ship view mode. When in map view, the orbit did not change. Here are the before and after orbit characteristics as shown by Kerbal Engineer: I'll link to the graphical map view sections, since they're a bit on the large side: Before Warp and After Warp. As you can see, the ship was on an intercept course with Duna before the time warp, and falling far short of Duna afterwards. The change to the orbit was the same each time I repeated it. Figuring I had a reproducible case, I decided to exit KSP and deactivate all mods to see if I could replicate the bug in stock. Unfortunately, I could not. I tried several times to do a 30d time warp with the same ship in view, but the orbit didn't change. Moreover, when I reactivated all the mods and relaunched, the same save game no longer let me reproduce the orbit change. So it seems it was tied to the running game state. Has anyone else encountered this problem? If I find a repeatable situation again, would it be useful to get a process dump of KSP in that state?

RAR with CSV results here.

That's Unity garbage collection, and happens with or without mods installed. Whether or not KSP can do anything about it is a question I don't know the answer to. I'd be inclined to think there is, however, since it doesn't happen all the time, even with the same ship, and seems linked to game run time. There's probably some more explicit object freeing that could be done to prevent the engine from doing this annoying pause routine.

I believe this is an acknowledged bug. And it's not at all about being picky, as you don't want to set one engine to 50% while the other refuses to be anything but 49.5 or 50.5%.

If any mod is to be made part of the stock game, it has to be Kerbal Alarm Clock. It's so essential to basic functionality that I can't imagine playing without it now. Next on my list after that would be something like PreciseNode, where I can fine-tune a maneuver node by typing numbers. The graphical UI in the stock game just doesn't cut it for long-distance transfers of any kind.

Something I didn't see mentioned in this thread is that it isn't just physics that makes the game CPU-bound with a relatively decent graphics card. You can see this easily in the VAB with this rocket loaded. GPU usage is far below max, and the frame rate is below the limit set by the game. There's no physics going on in the VAB. That means we're hitting a draw call wall. With a ship of over 600 parts, you're adding lots of draw calls. With higher graphics settings, each part (visible ones, at least - not sure how well Unity does occlusion culling) will have more draw calls. That's why I did the test launch four times: 32-bit and 64-bit version; lowest and highest graphics settings (including 4xAA with the latter). I'm using an i7 3930K at 4.6GHz with a Radeon 7970 at 1200MHz. I ran the test in a borderless window at 2560x1600. I monitored GPU usage the entire time, and at no point was I GPU-bound. Usage stayed below 50% for the duration of all tests. My results. I can provide the FRAPS CSV files if desired. The difference between high and low graphics settings really didn't start to matter until about a minute and a half into the launch. Right around when the frame rate approached 60, which means they don't end up mattering at all. Surprisingly, the 64-bit version shows a non-trivially higher frame rate throughout, if you ignore the Unity garbage collection pauses. I'd have to know a lot more about how Unity works than I do (i.e. very little) to even guess why that's so. But it shows there's a definitely advantage to using that version if you can. Unfortunately, the 64-bit Windows executable is incredibly unstable, so there's also definitely a disadvantage.

Memory usage goes up after initial load, obviously. The game doesn't load any saves until you choose to, and those game states take up memory. The more flights you have, the more memory you need.

The instability of the 64-bit Windows version has nothing to do with how much memory is in use. All of the crashes I've experienced were during the loading process (i.e. if you would normally see the loading graphic on the bottom right, it's a candidate crash situation). They were all random in nature, as well. Repeating the behavior as precisely as is possible (i.e. same steps from program launch) did not reproduce the crash. For example, loading the game, going straight to VAB, and loading a ship. Crashes on one attempt, doesn't crash on another.

You can edit the contract in your save game to push the altitude requirement above the game's confused notion of Jool's atmosphere (supposed to around 138K, but parts of the game still think it's 200K).

I routinely start with 1000+ parts, which makes for ~5fps launches. After launch, the worst performance I got was with around 1400 parts, which I got to by attaching parachute modules to a fuel depot I wanted to de-orbit. Single-digit frame rate most of the time when flying the modules into place. I haven't found the line, really, but one ship at 465 parts in the VAB was pegged at 60fps. Another at 1082 parts was at 30fps. Not a GPU limit, either. Since there are no physics in the VAB, that leaves draw call spam as the culprit. Seems there's a lot of room for optimization there.

I started by accepting literally every contract. I then constructed strange contraptions that completed multiple contracts with a single launch, which makes for a high profit ratio, even if you get nothing back from the ship. Recouping costs outside of the contract pay is more complicated. Without mods, it's not practical to recover any parts that you detach in the atmosphere. So you want to leave as much as possible of the ship intact until orbit, at which point you can use probe cores and enough fuel to de-orbit the stages that are no longer necessary. With enough practice, you can put these stages down right on the runway, getting you 100% of their value back. In general, make good use of SRB's, as they're very cheap for the amount of lift you get out of them, and you won't feel bad about ditching them. With lighter vehicles and adjusted max thrust (to avoid going too fast at too low an altitude), you can get halfway to orbit before touching liquid fuel.

Vernors on the top with RCS active is definitely the way to go for top-heavy rockets. I got my fuel station into orbit in one piece that way, with 20 of the big Kerbodyne tanks (empty).

You're building bigger ships. As part count goes up, physics calculations go up. It's trivial to build a ship that brings any processor down to slide-show performance.

It's hard to see how, since the fact that the game does essentially all processing on a single thread, as you're clearly aware, means single core speed is of paramount importance. Of course, you need to be CPU bound to notice. If you have a particularly slow graphics card, you might be GPU bound in most situations. There's a lot wrong with this statement. Let's start with the fact that computer memory timings are not measured in nanoseconds. DRAM used to be marketed by access time, measured in nanoseconds, but those days are long past - nearly two decades so. The numbers in a timing string such as 9-9-9-24 are clock cycles. As such, their values in time units depend entirely on the memory clock speed. For example, DDR3-1333 memory with a 666.667MHz bus clock and 9-9-9-24 timing has latencies of 13.5ns-13.5ns-13.5ns-36ns. DDR3-1866 memory with a 933.33MHz bus clock and 10-11-10-30 timing has latencies of 10.7ns-11.8ns-10.7ns-32.1ns. Despite having higher timing values, it's faster in every respect. In order to compare timings between two different memory speeds, you must scale the timing value by the same factor as the speed, so a 40% faster memory clock means 40% higher timing values to get the same latency. The goal of faster memory, of course, is higher throughput, and clock speed has a higher effect on that than latency. The "PC" designation on memory indicates maximum data throughput, not clock speed (PC1333 is not a real term). So DDR3-1333 memory can also be called PC3-10666 (or 10600, 10660), and DDR3-1866 can be called PC3-15000 (or 14900), where the number indicates the number of megabytes (10^6 bytes) per second. Finally, going from really slow memory to really fast memory will net you at best 3% more performance in any game. When the bottleneck is processor speed, as it is in KSP, faster memory is going to do next to nil. PS - Memtest86[+] must be run for days to reasonably conclude one is free of intermittent memory failures.

This is absolutely the radial separator bug, and Sepratrons don't work against it (save that sometimes using a multitude of them blunts the impact enough to prevent destruction). There's a workaround that involves editing the part.cfg for each separator, and makes them actually work. Note also that the bug disappears without modification after 750m/s, apparently because there's a different code path after that speed.