godefroi

There hasn't really been a "regular" update cycle. We're nearing the end of the current one, however, and once "experimentals" start (which is the last stage before the update is released), you'll know it's imminent, and could be coming in as little as 2 weeks or so. It often takes a few days to a couple weeks for mods to update, but the most popular ones often update immediately (as the authors are involved in the experimentals). Updates don't ALWAYS break mods, but this one likely will break most of them, as the underlying engine underwent a major version upgrade.

I haven't seen a CTD for more than a year, and I play with a rather solid list of mods. On top of that, I've never, ever seen data loss or save corruption, and I've been playing since 0.23. By all rights? Only one right matters, and that's what Squad says. They're the only ones whose opinion matters on whether it's beta or not. There is no ISO standard for beta; it's a marketing label only.

I think you misunderstand me; I'm not implying that your Xeon isn't good enough, I'm implying that whatever you had before was almost certainly good enough. My brother plays on an e8400, two generations behind my i5-2500k, and it's fine. Your 10-minute load times weren't related to your hardware, something else was up. If you're happy with your system, then go with it. I'm certainly not planning any near-future upgrades. Last I did was replacing a Radeon HD 5850 with an R7 370; I will likely run with this system the way it is for several more years without making a change.

Your experience with mods is, I would guess, atypical. I play with a large list of mods, and I think the last time I saw an actual CTD was somewhere around 0.23. Besides, if the game only crashes for you when mods are involved, how do you arrive at the conclusion that the game engine is somehow at fault? The fact that the game runs slow with large rockets is a result of the game design, not the engine. The game creates rockets from lots of various parts; when the rocket flies, it's still a bunch of connected parts, all of which the engine must manage, and simulate separately. This would be an issue regardless of engine. We're talking about this Squad, right: http://www.squad.com.mx/SquadSite/index.htm? Under services (http://www.squad.com.mx/SquadSite/index.htm#s02) a lot of things are listed, almost all of which are not related to software. Even if we're talking about a different, "split off" Squad, that only makes what I said MORE true, not less.

You can't expect a new version using the same assets to look any better than the existing version. If the art isn't pretty enough, it's the assets that are the problem, not the engine. The existing mods (RSS, etc) prove that scaling up the system is completely possible in the existing engine. Plus, there's always the elephant in the room: Squad isn't a software company, and they have neither the manpower nor the expertise to work in a different engine. Either way, I've seen no evidence that the chosen engine is the limiting factor...

No, on any given machine, it should run better than 1.0.5 did. There's no reason to run out and upgrade your stuff.

Again, I doubt it. I load the game (and 29 mods) off of a 6-year-old HDD in under 30 seconds. My CPU is an i5-2500k, which is only a couple years newer than your new Xeon.

Why the W3550? It's an ANCIENT and very power-hungry CPU. Unless you're getting a killer deal on it, I'd recommend against it. Also, 16GB of RAM has been my baseline for a couple years. Finally, if you went from 10 minutes to 30 seconds, and you weren't even loading any eye-candy mods, it wasn't your CPU that was the problem (unless it was something like a Pentium 3 or some such). Did you have Hamachi installed on the old machine?

It's RoverDude. For sure it's going to be top-notch. He's never heard of "bare minimum".

Multithreading is oh-so-much-easier in VM languages, compared to something like C++. .NET makes it especially easy, what with things like async/await and the TPL.

Some classes of problems (and many more classes of solutions) just can't be thread-safe. Whatever was or wasn't, or will be or will not be thread safe in 4.x or 5.x, doesn't change the fact that Unity 4.x was multithreaded. I'm not a Unity dev, but as far as I understand it, PhysX 3.3 in Unity 5 is still limited to a single thread per set of connected RigidBody instances (for us, that means vessel). Unfortunately, most situations we see involve only one vessel; this means that we shouldn't expect much benefit from the new multithreaded-ness (though we could see performance improvement simply because PhysX 3.3 is faster).

Unity 4.x was already a multithread capable environment (and indeed, KSP 1.0.x is currently multithreaded). If you want proof, pull up the task manager/process explorer/whatever and look at the thread count. What Unity 5.x changes is that it uses a multithreaded PhysX implementation. That's it.

Because of this thread I priced out initial components for a dual 3-axis joystick Arduino Uno-run box; I'm looking at some $80 for the hardware, no enclosure, and I haven't even started shopping around. Realistically, I think I can create a custom controller board for under $100 (USB, dual joystick, up to 14 switches), and I think others have done similar already. The best part is that I can get started for under $50 with one joystick plus the board and a few switches and go from there. If you're interested in building a custom controller, then you might want to look into the range of NETMF devices by GHI. You write code for them in C#/VB.NET using Visual Studio, just like you would a KSP addon.

RemoteTech has that feature. In practice, it was (for me) a bit clunky, so the only time I ever relied on it was to build out the initial ring of satellites for Kerbin. AR doesn't require line-of-sight to KSC, only Kerbin, so it's a non-issue. Like MeCripp, I build out the network as I go.

If you're arguing that we need bigger SRBs, then I'm 100% on board with you. I like to launch all my reasonable-sized rockets with a solid 1st stage, so a bigger one would be extremely welcome. A larger SRB would allow us to scale Vector's thrust back a bit. I personally do not think it's especially necessary, but if I had to trade a 25% cut in Vector's thrust for a bigger SRB, I'd do it in a heartbeat. One other thing (while we're on the topic of SRBs) that we need is a selectable thrust profile. A payload that results in a reasonable (~1.5) TWR at launch on top of a kickback also results in a difficult-to-control (~4-5) TWR at burnout. Even if we couldn't draw it ourselves, just being able to switch between "classic" and "tapered" would be plenty.

Please close this necro, the thread topic itself is no longer useful.

So, it turns out that RemoteTech is NOT installed, however, the folder for it was still there,and there was a settings file in it. Once I remove the folder, AR works as designed. Thanks!

Er, I have RemoteTech installed there (I'll have to check when I get home)? Well, no wonder it's not working. Sorry for wasting your time.

I PMd you my logfile. I didn't see anything obvious (or much related to AR in general), but maybe you know what to look for.

Is there any kind of debugging output? I've got a level 2 tracking station, and a HECS with one of each antenna is completely locked on the launch pad; the icon is red. I've tried extending the Communotron-16 in the VAB, but it makes no difference; I'm completely unable to launch a probe. What might I be doing wrong?

The RS-25 (SSME, Space Shuttle Main Engine) is a liquid oxygen/liquid hydrogen staged-combustion cycle engine that produces ~1900 kN of sea level thrust. The F-1 (Saturn V, or more accurately, S-IC main engine) is a liquid oxygen/RP-1 (basically kerosene) gas-generator cycle engine that produces ~6800 kN of sea level thrust. While rockets might not have changed much, these two engines are very different.

Nothing was "dumped to the page file". Memory that wasn't in use anyway (but might be soon, so it was left assigned to KSP) was removed from KSP's "working set", which is the bunch of memory pages that are currently assigned to KSP. Note that memory pages in a program's working set aren't necessarily IN USE, they're just assigned. At any moment, the operating system can take away any not-in-use memory pages in an action known as "trimming the working set". That's what happened here. Windows trimmed the working set because you alt-tabbed out of the program, and Windows said to itself, "hey, self, look at this program over here that has a huge number of unused pages in its working set. The user just alt-tabbed out, so the program is probably going inactive and won't need any of them for a while. Let's go ahead and grab those so we can use them for more productive things, like giving them to whatever program he alt-tabbed into, or maybe assign them to the disk cache or something." In fact, you actually made performance worse, because now, when KSP asks for more memory, Windows has to go find unused memory pages and assign them to KSP before KSP can use them. Furthermore, modern operating systems do fancy things like remembering what was in a memory page, and if you free that page, and later put the same thing back in, it all happens instantly, because it was all already there. That kind of thing can't happen if the working set is trimmed between the free and the allocate. Like I said, memory management in modern operating systems is extremely complex. I've been developing software (professionally) on Windows for almost twenty years, and I have what I would consider only a moderate understanding of it. Lastly, even if the memory had been "dumped to the page file", it wouldn't have mattered. When KSP "runs out of memory", it doesn't actually run out of memory, it runs out of address space. Even when memory pages are swapped into the page file, they still consume address space. The swapfile doesn't

The "Memory" number is lying to you. It shows the "working set size", which is not related at all to how much memory is in use by the process. When you alt-tab out (or minimize, or whenever Windows decides to) the working set size is being "trimmed" down to the actual in-use memory size. So, you didn't change the amount of RAM it was using, you just trimmed the working set. It's kinda like Windows asking KSP to give up all the empty memory that it's not using so it can be allocated to other programs. Do understand that memory is an extremely complex subject; modern operating systems use all kinds of techniques to manage memory that makes it pretty difficult to provide a simple "how much memory is being used" number. If you want to understand the working set, start here: http://blogs.msdn.com/b/salvapatuel/archive/2007/10/13/memory-working-set-explored.aspx If you want to understand memory compression in Windows 10, start here: http://www.tenforums.com/windows-10-news/17993-windows-10-memory-compression.html

None of that is a reason why it wouldn't work. Yes, it'd be slower, but as we like to say, "slow" is still infinitely faster than "crashed". Also remember, none of this relates to PAE in any way. If you have a 64-bit CPU, PAE does nothing for you. At all. PAE is a CPU thing, not a software thing. Doesn't change how much RAM your program can access, doesn't change address space size. Only lets your 32-bit machine have more than 4GB physical RAM.