Patch 1.4.3 to be released next week!

[klgraham1013]

1 hour ago, XLjedi said:

Any clues yet as to why the Mk3 Cargo Ramp causes deployable solar and radiator arrays to explode on exit?

Squad Bug Tracker 18017

I'd like to be able to transport my rovers via spaceplane again...

 

Man.  My decision to stick with 1.3.1 continues to look better and better.

[Just Jim]

28 minutes ago, Jeb's Pirotecnics Guy said:

Was there a problem with landing legs exploding with the slightest of nudges. Because I have that problem.

Yes, it's one of the fixes @UomoCapra said is in this patch.

19 hours ago, UomoCapra said:

The issues with the wheels and legs have also been reviewed for this patch. For instance, 1.4.3 fixes the suspension issue for wheels and legs that made them bounce uncontrollably, as well as the issue that caused legs to explode when these got in contact with the ground in some situations. There has also been a lot of work put into improving the ground positioning routines for landed vessels.

 

Edited April 13, 2018 by Just Jim

[RoverDude]

FYI - Cheetah and Wolfhound had a lot of twiddling done to get their thrust center improved.  Usual caveat that we're at the mercy of floating point math, and a thrust transform tied to the gimbal.  

[Poodmund]

Quote

FYI - Cheetah and Wolfhound had a lot of twiddling done to get their thrust center improved.  Usual caveat that we're at the mercy of floating point math, and a thrust transform tied to the gimbal.  

Can you not just align the thrust transform directly in line with the attachment node on the vertical axis and make sure it is angled perpendicular to the attachment node, ergo, no net force will be induced?

Please could you elaborate if this is not the case? I am very intrigued in case engine mod devs have been doing something wrong all this time. 

Edited April 13, 2018 by Poodmund

[CobaltWolf]

39 minutes ago, RoverDude said:

FYI - Cheetah and Wolfhound had a lot of twiddling done to get their thrust center improved.  Usual caveat that we're at the mercy of floating point math, and a thrust transform tied to the gimbal. 

4 minutes ago, Poodmund said:

Can you not just align the thrust transform directly in line with the attachment node on the vertical axis and make sure it is angled perpendicular to the attachment node, ergo, no net force will be induced?

Please could you elaborate if this is not the case? I am very intrigued in case engine mod devs have been doing something wrong all this time. 

What floating points? Wouldn't the X/Z (X/Y in Blender if I remember?) just have to be set to '0' for the engines to have proper thrust? I agree with @Poodmund, I'm curious if there is some sort of existing issue that could be affecting my engines and these two stock engines are just particularly affected.

[Mark Kerbin]

Am I the only one notice that fairings have a tendency to cause solar panels to self destruct? 

[XLjedi]

Just now, Mark Kerbin said:

Am I the only one notice that fairings have a tendency to cause solar panels to self destruct? 

Are they the deployable type solar panels, and radiators?   If so, I've been having the same problem exiting the Mk3 Cargo Ramp.  (see my post above)

[Capt. Hunt]

1 minute ago, Mark Kerbin said:

Am I the only one notice that fairings have a tendency to cause solar panels to self destruct? 

I've noticed that too, but only on rare occasions with some mod panels.

 

What about the engines with swapped Isp stats?

[Mark Kerbin]

1 minute ago, XLjedi said:

Are they the deployable type solar panels, and radiators?   If so, I've been having the same problem exiting the Mk3 Cargo Ramp.  (see my post above)

Ah yes. Yeah same as that basically. It would appear the closer they are to to base part of the fairing the more likely to explode. No clue if proximity to the sides/ center has any effect.

1 minute ago, Capt. Hunt said:

I've noticed that too, but only on rare occasions with some mod panels.

 

What about the engines with swapped Isp stats?

I have a heavily modded game but its definitely stock panels and fairings doing it.

Edited April 13, 2018 by Mark Kerbin

[RoverDude]

8 minutes ago, Poodmund said:

Can you not just align the thrust transform directly in line with the attachment node on the vertical axis and make sure it is angled perpendicular to the attachment node, ergo, no net force will be induced?

Sure... until you need a gimbal   And you still have floating point math.

Node Transform -> Model -> Gimbal transform -> Bell -> Thrust Transform (or Gimbal -> Thrust with the bell in parallel).

Now compound this with multiple transforms, part compression, etc. - i.e. take a very long skinny craft that's nose heavy with a beefy engine, and you'll get drift pretty quick.  Some combos are worse than others.  

2 minutes ago, CobaltWolf said:

What floating points?

Unity Vector3 x/y/z components are float.  

Also - here's an easy exercise.

Take a Mk1-3 pod. 
Attach an empty Rockomax 64 tank.
Add a Vector.
Debug cheat into orbit and turn on infinite fuel.
Point prograde.
Full throttle, no SAS.

Wait for the drift.

The Cheetah and Wolfhound had a couple of 0.0001's that exaggerated this, which is what got sorted.

 

[CobaltWolf]

8 minutes ago, RoverDude said:

The Cheetah and Wolfhound had a couple of 0.0001's that exaggerated this, which is what got sorted.

That's more what I was wondering. I know that sometimes when I import into Unity I'll see things like the X rotation of my thrustTransforms is like 89.99whatever instead of 90 and thought I was lucky to have noticed it by clicking the wrong thing in the outliner. Still, always nice to have easy/simple fixes to issues.

Also, I haven't seen any official response on the subject of the RCS effects being borked? What was the reason for the change, and does it mean that we should be switching to ModuleRCSFX? If so, I've gotten a number of issue reports of people returning to crafts in orbit (which used RCSFX and not RCS) and having the thruster fx firing in all directions without producing torque. I'm a bit worried because at the time the fix was to switch the affected parts back to ModuleRCS.

[RoverDude]

Yes, Unity will sometimes eat parts on import... and having your Gimbal at the top of a long bell rotated to 89.9997 degrees will cause drift.  But even setting this to 90 in unity does not change that it is stored as a floating point (as evidenced by your 0's and 90's getting occasionally wonky in Unity).

[Anth]

Heres a blessing in disguise.

The fairing/legs/gear/wheel issues allowed me to focus on my first ssto space plane in over 1300 hours of KSPing

https://imgur.com/a/SW3Tr

 

[CobaltWolf]

31 minutes ago, RoverDude said:

Yes, Unity will sometimes eat parts on import... and having your Gimbal at the top of a long bell rotated to 89.9997 degrees will cause drift.  But even setting this to 90 in unity does not change that it is stored as a floating point (as evidenced by your 0's and 90's getting occasionally wonky in Unity).

Anything re: my RCS question?

[StarStreak2109]

When KSP was in its pre-release stadium, I took all the bugs with a sense of humour seeing that there was a dedicated small team dabbling away on a new game, learning many things as they went. Then Squad moved onto Version 1.0, which IMHO indicates a full release. We still have bugs. Many of them. WIth the recent release, stupid many new bugs have been introduced.

And especially with the recent takeover by Take 2, I had expected that certain things might be "professionalized". Instead I find that it does not get better, but worse. A shame. Why wasn't there any QA being performed? Why was there no pre-release, or an extended QA round by a select group of users?

I do hope, that 1.4.3 brings a resolution to this mess, otherwise I will definitely loose the will to bother with this. Why, why, why...

Frustrated greetings,

   - Sebastian

[Mrcarrot]

Just now, StarStreak2109 said:

When KSP was in its pre-release stadium, I took all the bugs with a sense of humour seeing that there was a dedicated small team dabbling away on a new game, learning many things as they went. Then Squad moved onto Version 1.0, which IMHO indicates a full release. We still have bugs. Many of them. WIth the recent release, stupid many new bugs have been introduced.

And especially with the recent takeover by Take 2, I had expected that certain things might be "professionalized". Instead I find that it does not get better, but worse. A shame. Why wasn't there any QA being performed? Why was there no pre-release, or an extended QA round by a select group of users?

I do hope, that 1.4.3 brings a resolution to this mess, otherwise I will definitely loose the will to bother with this. Why, why, why...

Frustrated greetings,

   - Sebastian

All software, no matter what, when, or which version, has bugs. You may not always experience them, but they exist. All it takes is a small typo in someone's C#, and it takes a month to debug. KSP may be in the release stage, but it is still under development.

[StarStreak2109]

1 minute ago, Mrcarrot said:

All software, no matter what, when, or which version, has bugs. You may not always experience them, but they exist. All it takes is a small typo in someone's C#, and it takes a month to debug. KSP may be in the release stage, but it is still under development.

That is so. But I would expect that the most glaring ones are being caught during the QA phase. Stuff like the exploring landing gear, broken RCS fx, is IMHO stuff, that should have been caught before release. I am no software engineer, but I have a fairly good knowledge about (project) management and I know that going double rounds on quality assurance costs way more. I guess I am mostly frustrated because instead of making the game better, in many ways they have made it worse (at least in my view). And while the bugs may all be fixable, what gets me is that this could have been avoided. Just a few more weeks of QA involving some experienced players and it could have been avoided to some extent.

[Tfin]

Good. I guess I'll leave everyone in orbit of or enroute to the Mun for another week so I don't need to bat down all those contract completions over and over.

[Not Sure]

I really hope the fairing abnormal (some experience much more, some like my myself experience none) drag bug is fixed. Its all so wonky.
Don't forget to play test it this time
Good luck

[RoverDude]

9 minutes ago, Not Sure said:

I really hope the fairing abnormal (some experience much more, some like my myself experience none) drag bug is fixed. Its all so wonky.

Sorted.

[Not Sure]

1 minute ago, RoverDude said:

Sorted.

Awesome. Im quite enthusiastic for this release, it sounds nice!
Ill forgive the release if 1.4.2 lol

[FleshJeb]

2 hours ago, RoverDude said:

Yes, Unity will sometimes eat parts on import... and having your Gimbal at the top of a long bell rotated to 89.9997 degrees will cause drift.  But even setting this to 90 in unity does not change that it is stored as a floating point (as evidenced by your 0's and 90's getting occasionally wonky in Unity).

 

1 hour ago, StarStreak2109 said:

And especially with the recent takeover by Take 2, I had expected that certain things might be "professionalized"

As a professional draftsman with 24 years experience, your tools being "quirky" is not an excuse. A professional KNOWS where the tools fail, and incorporates a check stage into their workflow. Mistakes cost money (at least my $15).

Things like this are why I will NEVER get in a self-driving car, and I minimize my online financial transactions (I've also done backend webdev work for a firm that set up e-commerce sites).

We're long past the point where software engineers should have licensure by a professional board.

That said, I'm happy to see this patch, but I'm going to wait a few more months before I upgrade past 1.3.1.

[klgraham1013]

Good news.  Just say the banner saying they're looking for QA engineers.

[Guest]

Interesting. This might have a chance of enticing me back.

[Lisias]

6 hours ago, Mrcarrot said:

All software, no matter what, when, or which version, has bugs. You may not always experience them, but they exist. All it takes is a small typo in someone's C#, and it takes a month to debug. KSP may be in the release stage, but it is still under development.

What your are describing, sir, is the bad way of doing Software. Such small mistakes, exactly by be expected in normal day-to-day development, *MUST* be handled by the Q/A team (or by the devs doing Q/A), *not* by the Q/C team (and this is something that the development team should usually stay away).

An "acceptable" bug on a software this level and size is caused by a dozen of spurious iterations not usually realized on development (usually focused on the problem under the nose). The Integration Tests, ideally, should detect these - but not everybody has the juice to fund such tests properly, if one at all.

A huge, monstrous bug that crashes everything corrupting the savegame and that happens because you built a craft with vectorized thrust jet engine in the nose and fired it up in space on a radial out burn is something acceptable. A landing gear that explodes because someone typed an extra "0" on a single precision float on some source and caused an underflow that leaded to a DIVBYZERO exception, not that much.

Small, common errors are unacceptable on the release. They are expected to be handled by the Development Process (Q/A), not by product testers/users (Q/C). And this is not due the "severity" of the consequences, but because such errors are already expected to happen and then are expected to be already dealt with when the current iteration goes gold.

Edited April 14, 2018 by Lisias
typos, typos, typos everywhere!