Squadcast Summary (2016/01/28) - What's not in 1.1 edition

[bewing]

5 hours ago, samstarman5 said:

So you are saying that Squad wouldn't consider that, and just add clouds on a whim?  Squad has had weather in mind for a long time. This gives me reason to believe they have had plenty of time of considering ways to deal with piloting through heavy cloud cover. And they already have a foundation for a radar system, using the framework for the mining survey scans.

There are already mods that do add clouds, and they already do make you pilot blind through them. So obviously programmers in general are capable of just throwing them in on a whim to see whether it works out or not. Squad may not be that cavalier, but I think a bit of concern is justified.

 

Edited February 1, 2016 by bewing

[BloodDusk]

So...It seems the usual 'the cake looks weird and kind of wobbles so more icing should fix it.'. My hopes are not high for 1.5. 

[Xavven]

14 minutes ago, BloodDusk said:

So...It seems the usual 'the cake looks weird and kind of wobbles so more icing should fix it.'. My hopes are not high for 1.5. 

I'm guessing you meant 1.1? Just curious -- what specifically were you hoping to see them fix in this update?

[Guest]

22 minutes ago, BloodDusk said:

So...It seems the usual 'the cake looks weird and kind of wobbles so more icing should fix it.'. My hopes are not high for 1.5. 

Squad never announces features that far in the future.  That would require they have a roadmap.

If you're talking about 1.1, well, I don't know what you're expecting from a major game engine version change aside from a lot of work that doesn't involve your pet new content.

[BloodDusk]

13 hours ago, Xavven said:

 

13 hours ago, regex said:

 

Edited February 2, 2016 by BloodDusk

[BloodDusk]

Well, apparently, I can't multiquote and post at the same time...Oh well.

What I expected? Optimization is a big one. Maybe Unicode support or compliance, so people can translate the game to other languages, since not everyone speaks English? Maybe consider that...asset loading may be a bigger issue than multithreading support? Other optimizations? Cause, I checked a few things and...a good portion of things that come in new versions are either more assets or more features.

And...not really into baiting mr. regex. I'll pass.

[Guest]

9 minutes ago, BloodDusk said:

Optimization is a big one.

Have you been reading the dev notes?  I know there's a very busy member of the staff working on that.

9 minutes ago, BloodDusk said:

Maybe Unicode support or compliance, so people can translate the game to other languages, since not everyone speaks English?

Yeah, can't speak to that, although Unity 5 and the GUI overhaul probably makes that a much easier prospect; that's the kind of stuff you do during a refactor if you didn't start on i18n from the beginning.

9 minutes ago, BloodDusk said:

Maybe consider that...asset loading may be a bigger issue than multithreading support? Other optimizations?

Oh huh, really?  That must be why they're working on making that a reality.  It'd be nice if people stayed up on the dev notes and the chatter therein, would make conversations like this a lot less painful.

Can't come soon enough, yeah?  I used to think like that.  Squad added a few more coders though, and they're good ones, so hopefully things will be speeding up nicely.

9 minutes ago, BloodDusk said:

And...not really into baiting mr. regex. I'll pass.

Too bad.  One good turn deserves another.

[AbacusWizard]

14 hours ago, BloodDusk said:

So...It seems the usual 'the cake looks weird and kind of wobbles so more icing should fix it.'.

You can adjust the amount of cake wobble, for both internal and external views, in the settings menu, even during the game. (More icing can be accessed via graphics settings but may require a restart.)

[Superfluous J]

40 minutes ago, AbacusWizard said:

You can adjust the amount of cake wobble, for both internal and external views, in the settings menu, even during the game. (More icing can be accessed via graphics settings but may require a restart.)

Also there's KJR, or the Kake Joint Reinforcement mod, to fix that right up.

[samstarman5]

16 hours ago, bewing said:

There are already mods that do add clouds, and they already do make you pilot blind through them. So obviously programmers in general are capable of just throwing them in on a whim to see whether it works out or not. Squad may not be that cavalier, but I think a bit of concern is justified.

 

That is what modders do. They do things on a whim because of inspiration on their part and then they share it with the community. Many modders also listen to community feedback in order to improve the features of their mods.  But that also only goes so far, because modders don't have the same resources of staff or access to the entire code of the game as Squad does.

Squad isn't the ragtag group of guys that started a model rocketry simulator way back when.  And they don't do anything on a whim that they aren't prepared to put actual effort into to make it work.  Not only that, there is a large group of QA testers who not only look for bugs, but also look for the little things that might be missing to make a feature work for the game and not leave something out. It's not perfect, but nothing is, but it hardly warrants a lack of faith in a group that is quite experienced by now in developing a game and is quite serious in making KSP the best it can be. You only need to follow the devnotes posted every week to see the passion these guys have.

[godefroi]

On 2/1/2016 at 5:16 AM, Curveball Anders said:

Just moving code to a multithread capable environment doesn't require any changes or induce new bugs but neither does it give any advantages.

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.

[NoMrBond]

3 hours ago, godefroi said:

Unity 5.x changes

Unity 5 did add a native multithreaded job scheduler as well, although I'm not entirely sure what the benefits from that are, or would be

Plus I'm pretty sure Unity 5 still isn't thread-safe, even if multi-threading is better supported.  If you can't break down a big task to spread it around how much will it help in the end?

At least PhysX 3.3 handles its own threading internally which could/should help in some situations

[BloodDusk]

15 hours ago, regex said:

Have you been reading the dev notes?  I know there's a very busy member of the staff working on that.

Yeah, can't speak to that, although Unity 5 and the GUI overhaul probably makes that a much easier prospect; that's the kind of stuff you do during a refactor if you didn't start on i18n from the beginning.

Oh huh, really?  That must be why they're working on making that a reality.  It'd be nice if people stayed up on the dev notes and the chatter therein, would make conversations like this a lot less painful.

Can't come soon enough, yeah?  I used to think like that.  Squad added a few more coders though, and they're good ones, so hopefully things will be speeding up nicely.

Too bad.  One good turn deserves another.

-Where are these dev notes? Are they marked as such? I don't have time to watch livestreams.

-I was talking about 'bare metal' and stability optimizations, mainly. The game still is loaded all into RAM and its performance varies greatly depending on the number of assets that are present. Or some mods can break the game. Or some mods introduce arbitrary behavior, etc. Correct me if I'm wrong, but when reporting a bug, I was told that it spanned across several versions without being fixed.

 

[razark]

8 minutes ago, BloodDusk said:

-Where are these dev notes? Are they marked as such? I don't have time to watch livestreams.

http://forum.kerbalspaceprogram.com/index.php?/forum/66-the-daily-kerbal/

Every Tuesday.

[Guest]

15 minutes ago, BloodDusk said:

-I was talking about 'bare metal' and stability optimizations, mainly.

I was too.

Quote

The game still is loaded all into RAM and its performance varies greatly depending on the number of assets that are present.

Yes, the devs are aware and have stated that this is Something To Be Looked At in one of the recent dev notes.  The Unity 5 overhaul provides a good refactoring time to consider this sort of improvement.

Quote

Or some mods can break the game. Or some mods introduce arbitrary behavior, etc.

Not all issues stem from the base code and sometimes, just sometimes, someone outside of Squad may be at fault for that crash you experienced.

Quote

Correct me if I'm wrong, but when reporting a bug, I was told that it spanned across several versions without being fixed.

Sometimes bugs do span across several versions.  In my own work, the corporate office has been known to push less important bugs back to future versions, in some cases nearly indefinitely.  Some other bugs may be fixed or sidelined by new, refactored code.  Sometimes the bug isn't considered a bug or isn't reproduceable in a controlled environment,   That's software for you.

Edited February 2, 2016 by regex

[Archgeek]

I recall someone brought up bringing the gimbal rate (deg/s) in line (like Claw's GimbalPlus Stock Bugfix module), but was initially misconstrued as referring to the existing gimbal limit (max deflection).  Once clarified it was said they'd have QA look into it.

[godefroi]

15 hours ago, NoMrBond said:

Unity 5 did add a native multithreaded job scheduler as well, although I'm not entirely sure what the benefits from that are, or would be

Plus I'm pretty sure Unity 5 still isn't thread-safe, even if multi-threading is better supported.  If you can't break down a big task to spread it around how much will it help in the end?

At least PhysX 3.3 handles its own threading internally which could/should help in some situations

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).

[BloodDusk]

1 hour ago, godefroi said:

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).

That doesn't matter much. If you don't have an nVidia GPU, PhysX will do all the calculations on your CPU. Plus, the fact that your engine is multithreaded doesn't make your game multithreaded. PhysX was never meant to take advantage of multiple CPUs/cores, since it's nVidia's marketing ploy to make you use their cards instead.

[Sandworm]

20 hours ago, regex said:

I was too.

Yes, the devs are aware and have stated that this is Something To Be Looked At in one of the recent dev notes.  The Unity 5 overhaul provides a good refactoring time to consider this sort of improvement.

Not all issues stem from the base code and sometimes, just sometimes, someone outside of Squad may be at fault for that crash you experienced.

Sometimes bugs do span across several versions.  In my own work, the corporate office has been known to push less important bugs back to future versions, in some cases nearly indefinitely.  Some other bugs may be fixed or sidelined by new, refactored code.  Sometimes the bug isn't considered a bug or isn't reproduceable in a controlled environment,   That's software for you.

And some bugs are so persistent that they span years worth of development.  We regulars don't even notice them anymore.  They are now "character" and so remain forgotten and shall never be fixed.  Top of such true bugs would be several aberrant behaviors in KSP's control system, followed by the jittery orbit calculations/display.  Lower on the list are things more akin to content such as the total lack of engineering data.  These are so longstanding that fixing them would change much of KSPs character.  Nobody should hope that they will ever be fixed.

[Guest]

13 minutes ago, Sandworm said:

Top of such true bugs would be several aberrant behaviors in KSP's control system

Like what, the PID controller?  That just requires tuning, and it will never satisfy eveyone; it's not a bug.  Staging is being rewritten for the Unity 5 release.  What else?

Quote

followed by the jittery orbit calculations/display.

Very hard to fix when your physics engine runs on single-precision floating point numbers and your orbital calculations run on double-precision.

Quote

Lower on the list are things more akin to content such as the total lack of engineering data.

Not a bug, it's a lack of a feature.  Plus, they've given mass information in the VAB/SPH so you can easily whip out your calculator if you need to.

Quote

Nobody should hope that they will ever be fixed.

I used to be like that too.  Ah, the good ole' days of bitter...

Edited February 3, 2016 by regex

[Fearless Son]

12 minutes ago, Sandworm said:

And some bugs are so persistent that they span years worth of development.  

No joke, in a professional context I once saw a bug in a database that had spanned several major releases over the course of a decade.  As one dev commented in the notes, "Holy hell, I have kids in school younger than this bug!"  

It was a minor celebration among the QA and devs when it finally got closed.  

[Sandworm]

>> Like what, the PID controller?  That just requires tuning, and it will never satisfy eveyone; it's not a bug.  Staging is being rewritten for the Unity 5 release.  What else?

Like the wobble that occurs with certain sas holds.  They fixed it in relation to heading hold but not pro/retrograde holds.  Or the overcorrection when making large (ie 180*)changes.  Switch a space station from prograde to retrograte and watch the system struggle to decide how to move, inevitably overcorrection all the way and sometimes creating a perpetual loop.  Or the fact that engine movements are dictated from the perspective of the control pod regardless of the orientation of the engine at the end of the wobbling rocket, again resulting in constant over-correction.  While these behaviors are considered aberrant in any sane control system and are readily addressed, they have been so long a part of KSP's characteristic silliness they shall never be fixed.  What was once a bug is now a feature.

[Guest]

12 minutes ago, Sandworm said:

Like the wobble that occurs with certain sas holds.  They fixed it in relation to heading hold but not pro/retrograde holds.

So, wait, something that got introduced in, what, 1.0.x with the new controls "span years worth of development"?

12 minutes ago, Sandworm said:

they have been so long a part of KSP's characteristic silliness they shall never be fixed.  What was once a bug is now a feature.

Huh.  Okay then.

Have you asked Squad, maybe in the dev notes threads?  Reported that in their bug tracker?  They've been fairly open about that sort of thing recently.

I get the impression that there's no pleasing you, though.

[Sandworm]

>> Nope.  That wobble was there since 0.19 (.20?) when I started playing.  It used to rip apart space stations.  They fixed it for the heading hold prior to us getting the pro/retro grade holds.  The overcorrection also goes back a long way.

[Guest]

19 minutes ago, Sandworm said:

>> Nope.  That wobble was there since 0.19 (.20?) when I started playing.  It used to rip apart space stations.  They fixed it for the heading hold prior to us getting the pro/retro grade holds.  The overcorrection also goes back a long way.

The PID controller was rewritten in 0.21 and was tuned again in 0.22, which largely fixed the wobbling but it still has issues with using all its control authority.  So, basically, the controller just needs to be tuned for the other axes.  Anyway, a PID controller is reactive so you'll never get rid of wobble, you can only really minimize it.

E: I mean, you're basically asking for a system that can control pretty much any craft of whatever arbitrary shape, size, and available control authority the player throws at it perfectly.  Quite frankly I'm amazed it works as well as it does.

Edited February 3, 2016 by regex