Squadcast Summary 2015/09/11 - Max's Coccyx

[basic.syntax]

Thanks 5th! Whatever content they decide to ship, I hope they take a month of back and forth with QA and Experimentals to find and fix bugs. The biggest complaints about 1.0 were that they rushed to meet a ship date, needing multiple patches to nail down the Aero rebalance, so from that PR perspective, Squad should try to create the impression that they aren't rushing.

How's this idea for not rushing: v1.1 by Christmas, with the antennas, PorkParts, contextual contracts, and something else they haven't mentioned yet, as a surprise on top.

[MiniMatt]

Q to stream: Would you rather have the unity update (64 bit, optimizations, etc) sooner or wait longer and have things like antenna overhaul thrown in, "far later"?

Personal thought, would prefer U5 first, extra bits can come later.

This is dependent upon the following assumptions:

U5 includes wheel physics rewrite and native 64bit

Wheel physics/re-jiggle I see as key, as a lot of mods depend on reliable ground transport; 64bit goodness I see as key to be able to load EVE style pretties *and* extra stuff to do mods like life support, parts, antenna modifications, etc.

The extra gubbins being suggested on top of the U5 rewrite are excellent, but strike me as things that mods can do in the meantime.

[Lukaszenko]

I'm all about a sooner release. And more releases. If they can fix a small bug with a quick update, for example, just release that NOW. What's the sense in waiting 6 months just so it's in a big bundle?

[Alshain]

It also looks exactly like a real antenna on Hubble. I suspect both were modeled after that, and neither was modeled after the other:

Makes sense.

[Red Iron Crown]

I'm all about a sooner release. And more releases. If they can fix a small bug with a quick update, for example, just release that NOW. What's the sense in waiting 6 months just so it's in a big bundle?

This causes troubles for mod users and modders, as the version checking stuff goes a bit nuts after an update even if the mod still works.

Not to mention that judging by the reaction to the 1.0.x releases many people don't want quick updates that fix a couple of things.

[passinglurker]

I'd prefer the less frequent but more stable kind of releases so wait for extra features seems fine to me it might give squad a chance to stop and balance it's parts for once

[Grumman]

Not to mention that judging by the reaction to the 1.0.x releases many people don't want quick updates that fix a couple of things.

What we don't want is quick updates that break things. If the game is "strictly better" after the change, then do it immediately. Adding a new part, for example, does not break people's savegames or spacecraft (unless you happen to give the new part the same name as an existing mod part). Doing things like nerfing parachutes or adding life support requirements does break people's savegames, and so should not be done lightly.

[Yellowburn10]

Just out of curiosity, how many days has it been so far developing 1.1? It seems the U5 update alone is taking about as much time to develop as 1.0 did.

[Alshain]

Just out of curiosity, how many days has it been so far developing 1.1? It seems the U5 update alone is taking about as much time to develop as 1.0 did.

More. Hard to believe it's been almost 5 months. 0.90 to 1.0 was 4.5 months, which if they release next week (not going to happen) would be about where 1.1 is.

[Joshwoo70]

should there be a setting where you can specify how many core will be using? like 3?

[Renegrade]

Q: What will 64 bit do to the game?

A: [We all know that answer. ] No physical changes. You won't notice much [except I assume performance on large ships] for non-modded games. Modded installs will notice they can mod a lot more

64-bit won't help performance one tiny bit. It'll just let you add tons of texture-heavy mods. Even a thousand part ship isn't using up much in the way of memory...

Most of the purported advantages of 64-bit are generally overwhelmed by the increased data load (especially with 'modern' languages, which tend to be nested webs of virtual pointers, which are all now going to be twice as long), and the rest of the 'advantages' are actually just the 'advantage' that a programmer can enable optimizations for specific features without having to worry that a 486 doesn't have SSE support (which can also be done by specifying a later-generation CPU as a minimum).

Most of this 64-bit rah-rah comes from two sources:

1. The marketing departments at AMD and Intel, for what I assume are obvious reasons.

2. Old timers (or maybe a kinda..genetic memory) recall the 286-386 (or 68000-68020) era, when jumping from 16-bit systems resulted in huge improvements in performance. However, most of those improvements were because the 286 (and 68000) had a 16-bit data bus, and the 386 (68020) had a 32-bit data bus, and many data objects were 32 bits in size (multi-word instructions, far pointers, floating point values, etc), and also as the newer generation processors had much shorter execution times on common instructions. When the Pentium was released, it had a 64-bit data path (save for some of the special chips, like the Overdrive units that go into 486 boards), and CPUs have largely had the same IPC values since the Pentium Pro, so any step from a 32-bit to 64-bit environment will be a fairly subtle change as the data paths aren't going to get better, and nor are execution times.

All of that being said, I am looking forward to not having to sheepdog the damn memory counter for KSP in the task manager constantly. Hopefully they'll nail some of the memory leaks too; that'll give me even more playtime.

[Bill Phil]

64-bit won't help performance one tiny bit. It'll just let you add tons of texture-heavy mods. Even a thousand part ship isn't using up much in the way of memory...

Most of the purported advantages of 64-bit are generally overwhelmed by the increased data load (especially with 'modern' languages, which tend to be nested webs of virtual pointers, which are all now going to be twice as long), and the rest of the 'advantages' are actually just the 'advantage' that a programmer can enable optimizations for specific features without having to worry that a 486 doesn't have SSE support (which can also be done by specifying a later-generation CPU as a minimum).

Most of this 64-bit rah-rah comes from two sources:

1. The marketing departments at AMD and Intel, for what I assume are obvious reasons.

2. Old timers (or maybe a kinda..genetic memory) recall the 286-386 (or 68000-68020) era, when jumping from 16-bit systems resulted in huge improvements in performance. However, most of those improvements were because the 286 (and 68000) had a 16-bit data bus, and the 386 (68020) had a 32-bit data bus, and many data objects were 32 bits in size (multi-word instructions, far pointers, floating point values, etc), and also as the newer generation processors had much shorter execution times on common instructions. When the Pentium was released, it had a 64-bit data path (save for some of the special chips, like the Overdrive units that go into 486 boards), and CPUs have largely had the same IPC values since the Pentium Pro, so any step from a 32-bit to 64-bit environment will be a fairly subtle change as the data paths aren't going to get better, and nor are execution times.

All of that being said, I am looking forward to not having to sheepdog the damn memory counter for KSP in the task manager constantly. Hopefully they'll nail some of the memory leaks too; that'll give me even more playtime.

Yeah, but the under the hood rebuilding should add something tangible.

[Lord Aurelius]

I'll cast another vote for an earlier 1.1 update. Even if no new features are added, the game is pretty much being rewritten entirely by the sound of things and I believe that it would be wise to unbundle that massive change from yet more new features. Better to make sure everything still works before trying to add new features on top of it, and the optimizations alone are a substantial feature in and of itself (that and the new wheel model, looking forwards to that one).

[basic.syntax]

They can try to make sure the changes and planned new features work, with a good long test program, aiming for a release date in December.

[StarStreak2109]

Release it, when it is ready and and stable. Make sure that sufficient debugging has been done. If waiting for the new features like "RT lite" means waiting for a few months, maybe release 1.1 w/o those new features. If they are integrated so that a "pre-release" isn't possible / feasible, then it's tough luck, we'll just have to wait a wee bit more...

[Renegrade]

Yeah, but the under the hood rebuilding should add something tangible.

I'd reserve judgement on that too until we see it. I've followed some other games through U5 updates and they had kinda mixed results. The dev blog about the changes to heating sound.. computationally expensive, and changes like that could wipe out any speed improvements.

Hope for the best, but expect the worst. That way, all of your surprises will be pleasant ones~

[Alshain]

should there be a setting where you can specify how many core will be using? like 3?

Windows has this ability, but why would you ever want to gimp your computer?

[Superfluous J]

64-bit won't help performance one tiny bit. It'll just let you add tons of texture-heavy mods. Even a thousand part ship isn't using up much in the way of memory...

True. I was watching and typing quickly, and was thinking more "all of U5" instead of "just 64 bit".

- - - Updated - - -

Windows has this ability, but why would you ever want to gimp your computer?

I'm not familiar with this ability. Can you tell it "This program only gets access to these 3 cores, and this other program can use this one?" In that case you'd not be gimping the computer so much as KSP, presumably in order to run something else that KSP would potentially clobber in its race to take every resource possible for itself.

[Thegamer211]

I'd rather have sooner the Unity 5 update than the new parts.

[Jasper_f]

Thank you very much, 5thHorseman, for your summary! It turns out that regarding KSP news I look forward to devnote Tuesday and your summary on Saturday!

[severedsolo]

I'm not familiar with this ability. Can you tell it "This program only gets access to these 3 cores, and this other program can use this one?" In that case you'd not be gimping the computer so much as KSP, presumably in order to run something else that KSP would potentially clobber in its race to take every resource possible for itself.

In Task manager - you can right click a process and go to "Set Affinity" - this will allow you to set which cores the process is allowed to run on.

Generally speaking - this is not necessary. Your OS should be good at load balancing by itself, so it can do more harm than good. In fact, the only time I can think of where I have ever had to do this, was on very old games that didn't understand dual core, and crashed when they found one.

[Temeter]

Thx a lot for the summary 5thHorseman, always love to read them!

Personally I'd rather prefer a soon release. It's taken already so long, and performance improvement/64 bit/wheel physics seem to be the most interesting updates. Nice to see Squad is aiming for a sooner release, too.

[boxman]

I really hope they release unity5 version first and then the extra content in a later patch. That way the unity5 port will be properly tested by the large playerbase, so that eventual bugs can be caught before 1.1 is released.

And will also give modders more time to get their mods updated for 1.1

[godefroi]

In Task manager - you can right click a process and go to "Set Affinity" - this will allow you to set which cores the process is allowed to run on.

Generally speaking - this is not necessary. Your OS should be good at load balancing by itself, so it can do more harm than good. In fact, the only time I can think of where I have ever had to do this, was on very old games that didn't understand dual core, and crashed when they found one.

And it's important to note that setting (for example) KSP to run on 3 cores out of your four, does NOT reserve these three cores for KSP. Your OS is still free to schedule other processes' threads on those cores.

At the end of the day, all you'll do is hamper performance. Might as well get yourself a memory compressor and a registry cleaner to go along with your processor affinity.

[magico13]

I'd rather have one big release than two smaller ones. Partly that's selfishness because two updates means more work on modders (usually), and the other part is that means the Unity upgrades will get more internal testing time.