Devnotes Tuesday: Bugs and more bugs to be fixed!

[Speadge]

The KSPedia is great. I was really overwhelmed by the content. Respect for that!

I also like how some feedback from the tracker found its way into the improved screens ("easy, right?")

 

7 hours ago, DrD said:

Looks great!

On the Orbit nodes (continued) page, is Patch 1, Patch 2, Patch 3 supposed to be path?

Thats about the "patched Conics" calculated by the game
https://en.wikipedia.org/wiki/Patched_conic_approximation

 

 

Edited April 6, 2016 by Speadge

[Curveball Anders]

9 hours ago, NoMrBond said:

I mean, I don't want 1.1 to enter Valve time or anything, but the idea of addressing 500+ bugs in a week sounds punishing, if not impossible.

It sure looks like a herculian task and they'll have to grind but note that those 500+ (534 right now) open issues includes all kind of stuff.

Including, but not limited to, duplicates, mis-reports, itty-bitty details, bugs created by other bugs and so on.

But anyway, I'll stick to my prediction of two more weeks.

Good job Squad, now keep that pressure up

 

Edited April 6, 2016 by Curveball Anders
Speling ond gramer

[Sheppard]

One small thing: the KSPedia page for the science parts is missing an image of the Mystery Goo Container. All other experiments are there, except this one.

 

 

Edited April 6, 2016 by Sheppard

[NoMrBond]

1 hour ago, Claw said:

There were two issues. One appears that a lot of garbage was being created and destroyed in the process of spawning the meshes. A second problem appears to be a slowdown in a Unity function that was previously in use, but seems to be much (much) slower in the new version of Unity.

Turns out there wasn't really a perfect storm required. It was just the sheer volume (and possibly type) of colliders in the fairings interacting with the slower Unity function. This might have also been an issue with really high part count craft.

Thanks for the answer Claw,

Hope there's nothing else like that hiding back there!

[taniwha]

2 hours ago, Majorjim said:

Be afraid. Be very afraid.

Actually, most of the initial and final equations for orbital mechanics (and even rockets) are amazingly simple, and sometimes quite beautiful. It's the steps in between that can get rather hairy.

[T-Bouw]

Yeah! Good going Squad and bug-testers!

Though I have one friendly tip for the ones that keep on hanging on the notion that 1.1 will be released directly after these 2 weeks.
Don't count on it so blindly. Squad never said that.

I mean, this is a period of finding and fixing bugs, but think about it. There are sure to be some bugs to be found at the end of the Pre-release.
Those last few have to be dealt with as well, or at least most of them, right?

Give it some time after this bughunt is al I'm saying.
I can't wait as well though...

[steve_v]

I have always held the opinion that "it's ready when it's ready" - i.e. when the bugs are fixed.
(This is the main reason I was somewhat... unimpressed when KSP went 1.0).

I really don't care if 1.1 comes out in 2 weeks or 2 months, what I do care about is squishing all the serious game-breaking & CTD bugs. It takes as long as it takes.

IMO, a release that doesn't randomly crash, and doesn't need 6 hotfixes, is preferable to getting it out on the promised day.

Please Squad, take your time and don't just "too hard bin" the engine bugs - even if they are Unitys fault.

Let's make sure the thing's properly stable on all platforms, and not repeat the win64 fiasco, eh.

So far, so good. Still needs a bit more debugging though.

Edited April 6, 2016 by steve_v

[Padishar]

1 hour ago, NoMrBond said:

Hope there's nothing else like that hiding back there!

Like deleting 4000 parts in the editor locking the game up for 3 hours...

[virtualizerocket]

But I'd like to find a way seeing IVA inside only through windows.

[Superfluous J]

3 minutes ago, virtualizerocket said:

But I'd like to find a way seeing IVA inside only through windows.

This. There should be 3 modes. Normal, windows are see-through, and cutaway.

And there should be a way to state which one is always the default.

[klgraham1013]

4 hours ago, Claw said:

There's also an option now in the settings.cfg to disable it completely while in-flight. "INFLIGHT_HIGHLIGHT = False"

You are my hero.

[Majorjim!]

1 hour ago, taniwha said:

Actually, most of the initial and final equations for orbital mechanics (and even rockets) are amazingly simple, and sometimes quite beautiful. It's the steps in between that can get rather hairy.

I don't doubt it matey, I was mainly speaking for myself..

Just now, 5thHorseman said:

This. There should be 3 modes. Normal, windows are see-through, and cutaway.

And there should be a way to state which one is always the default.

Yes please!!

[TriggerAu]

3 hours ago, Sheppard said:

One small thing: the KSPedia page for the science parts is missing an image of the Mystery Goo Container. All other experiments are there, except this one.

 

 

Thats a little funny, I simply picked small parts and a number of em as a sample to fit under the text, never realised I had all of them except one

I'll have a look at it

 

[TriggerAu]

4 hours ago, Speadge said:

The KSPedia is great. I was really overwhelmed by the content. Respect for that!

I also like how some feedback from the tracker found its way into the improved screens ("easy, right?")

 

Thats about the "patched Conics" calculated by the game
https://en.wikipedia.org/wiki/Patched_conic_approximation

 

 

Not much point having a feedback process and loop if you dont pay attention  Hopefully all the feedback got in there - and some stuff you may not have noticed too

And as you noted it is the patched conic path that the game displays - I will not admit to tracing a screenshot for that one

[John FX]

As someone unable to play the prerelease who sees the amount of bugs and the time left, my hope is that a working version is released next week but the bugfixing carries on, and the prerelease thread for reporting bugs just turns into a release thread for reporting bugs and a few patches are applied for bugfixing after release in a similar way to 1.0.5 (I expect the really stable version to be 1.1.5 also)

 

To my mind that would be the good compromise between getting it out there, fixing the bugs, and also allowing Squad to have a life...

[KerbonautInTraining]

2 minutes ago, John FX said:

 and a few patches are applied for bugfixing after release in a similar way to 1.0.5 (I expect the really stable version to be 1.1.5 also)

That's not a bad idea. 

Just plan having a big patch a month or so after release, as opposed to lots of little ones.

[juanml82]

10 hours ago, sgt_flyer said:

next prerelease version has a fix coming in for wheels colliders messing stuff up, so once it's deployed, we'll be able to more properly test these wheels  (if those bugs altered somehow the performance of the wheels, - we'll need to give feedback on how they work after the patch )

Yes, but I'm more worried about the new mechanic of wheels only supporting a certain weight, which isn't a bug but a feature

[mudkest]

KSPedia album looks nice, but I'm missing some info on the altimeter, as explained in the linked topic. I only really noticed those indicators a couple weeks ago, then it took some effort to dig up the info on what they do

 

[soulsource]

On 6.4.2016 at 9:58 AM, microsoftenator said:

Is this with the proprietary drivers or the OSS radeon/radeonsi/AMDGPU drivers? I've been using the latter for the last ~3 years without issue, while the proprietary fglrx drivers have had a bunch of weird bugs for the last decade at least

If it's with the old, no longer maintained proprietary ATI drivers (fglrx aka. Catalyst, aka SirCrashAlot): I'd suggest not to worry too much about it. They are legacy drivers (I wrote ATI on purpose as they are their legacy...) after all, and will not be supported by future (and some current) Linux distributions anyhow (for instance Ubuntu 16.04, Debian Jessie with Gnome 3, Arch Linux and probably Linux Mint Sarah).

There are currently two official AMD drivers available, both under active development:

• The currently recommended [1] drivers are the open source stack (radeon or amdgpu DRI module, combined with radeon or radeonsi OpenGL drivers). They are at the moment still a few extensions away from OpenGL 4.5 and have no Vulkan support as of yet, but support Direct3D 9. The other driver is
• the hybrid stack, using the amdgpu DRI module, and the closed source OpenGL driver known as AMD GPU Pro, which is currently in Beta testing, and also doesn't yet support hardware that's not at least GCN 1.1 (officially GCN 1.2, with GCN 1.1 being experimental), but GCN 1.0 support is planned eventually. Performance is slightly better than with the open source stack, and the hybrid stack has superior OpenCL functionality, supports OpenGL 4.5 and Vulkan, yet doesn't support Direct3D iirc.

So, while currently about half of the Linux AMD gamers still run fglrx (I didn't expect that there are so many masochists [2]...), I'd predict this number to decrease dramatically within the next few weeks/months, when Ubuntu 16.04 and Linux Mint Sarah will be released. Due to this, I'd consider it acceptable if KSP works well with the open source drivers and AMD GPU Pro but not with fglrx. To only support AMD GPU Pro (and not support the open source drivers) would be a bad idea though, as AMD is still selling GCN 1.0 hardware as new (namely the R7 350, R7 370, and R9 370X).

I'd really love to help test 1.1 on the radeonsi drivers, but sadly I bought KSP through the store, and am too parsimonious to buy it again on Steam just for testing a prerelease version...

[1] If you are wondering why I'm linking to a forum post by "some random guy on the web" - that guy isn't random, it's John Bridgman from AMD, as one can rather well confirm by looking at other posts from the same account.
[2] Or, maybe, there are so many people who require OpenCL image support or certain OpenGL extensions not available with the open source drivers on GCN 1.0 or Northern Islands hardware... That's pretty much the only sane reason I can think of to suffer the horrible mess fglrx is, especially now that the open source driver is nearly on par regarding performance...

Edited April 7, 2016 by soulsource
added note about Direct3D

[swjr-swis]

15 hours ago, SQUAD said:

and save game files now store a list of the mods that have been installed and also which are currently active.

@NathanKell: Not to sound ungrateful (I love this addition, thanks!), but can that same code perhaps be reused to get this into craft files as well? I know, total feature request, but there's potential!

Instead of (or along with) the very generic messages 'incompatible with this version of KSP' or 'Contains locked or invalid parts' at the ship loading dialog, maybe a tooltip could appear that actually reports what specific mods are missing for a craft file to load without errors or parts disappearing, by comparing the saved mod list in the craft file with that in the current game.

[RW-1]

"Valve time" ....  ROTFL ....

Didn't you all know that when Valve Releases HL-3, for an extra $25, you get:

A limited Edition Crowbar, and ... a copy of KSP 1.1  !

 

Ok, seriously now.  Great moves forward on pre-release, looking forward to it when it hits.

Edited April 6, 2016 by RW-1

[Temeter]

Quote

[...] so the individual parts of each wheel will not rub against each other either, which was also causing problems for players [...]

@NathanKell This was btw the issue I ment in the bug tracker when I said that XL3 wheels would destroy themselves at high weight+physics warp on heavy vehicles. In higher timewarp their parts would collide with themselves, jiggle, and that would destroy the wheel. Even if the general weight was absolutely managable for the wheels in any other situation.

Edited April 6, 2016 by Temeter

[NathanKell]

@swjr-swis sadly those are two different things. The mod list is just that: a list of all the mods that have ever been loaded (i.e., existed) during the course of the save, with those which exist at the exact time the save was last saved being flagged as active. That info could be added to craft files, but I question its utility because as you say what would be useful would be a list of mods used by the parts and doing that is not easy at all. Consider that mods often clone stock parts, so even the config URL of those parts would point back to the Squad folder!

So short answer: sadly no.

[linuxgurugamer]

17 hours ago, SQUAD said:

save game files now store a list of the mods that have been installed and also which are currently active.

oh this is going to be sooo helpful, thank you

[linuxgurugamer]

12 minutes ago, linuxgurugamer said:

oh this is going to be sooo helpful, thank you

Where in the save file will that list of mods be?