Kerbal Space Program 1.12.3 is live!

[dok_377]

8 hours ago, Krazy1 said:

I started playing on 1.8... not very optimistic

On 1/10/2022 at 9:34 PM, Lisias said:

I bought KSP on the 1.3.1 era, but only started to play with it about 1.4.1 - and until 1.4.3, I was pretty happy with the product (being the reason I'm playing on this version nowadays).

I would say that past 1.3-1.4 the development has pretty much gone downhill. There was maybe one or two "good" relatively speaking versions, but after that the QA started getting worse and worse, more bugs were spilling into releases, less bugs was being fixed afterwards. I haven't even moved my game to 1.11 or 1.12, probably never will. Just because these two versions basically destroyed the game. Squad just bit off way more than they could ever chew. 

Edited January 12, 2022 by dok_377

[AtomicTech]

2 minutes ago, dok_377 said:

I would say that past 1.3-1.4 the development has pretty much gone downhill. There was maybe one or two "good" relatively speaking versions, but after that the QA started getting worse and worse, more bugs were spilling into releases, less bugs was being fixed afterwards. I haven't even moved my game to 1.11 or 1.12, probably never will. Just because these two versions basically destroyed the game. Squad just bit off way more than they could ever chew. 

Ouch.

[Lisias]

3 hours ago, dok_377 said:

I would say that past 1.3-1.4 the development has pretty much gone downhill. There was maybe one or two "good" relatively speaking versions, but after that the QA started getting worse and worse, more bugs were spilling into releases, less bugs was being fixed afterwards. I haven't even moved my game to 1.11 or 1.12, probably never will. Just because these two versions basically destroyed the game. Squad just bit off way more than they could ever chew. 

I do not agree that it's a Q/A problem (using the strict definition of the term Quality Assurance). Let me explain:

Q/A is not about "finding bugs", it's about non-compliances. A bug is a bug if and only if there's a Requirement (being it functional or non-functional) that it's not being satisfied by the artefact. Of course, there're many ways for handling Requirements (formally or informally), but in essence, if there's not a Requirement for something, Q/A has their hands tied.

Spoiler

Being yet more picky, we can discuss about the insufficient Q/C (Quality Control) of the product - this guys are the ones that are usually allowed to "complain" about things not working as they think they should. But looking on the bugtrack, I think that the Q/C is not that bad (terribly chaotic, no doubt, but not that bad). In fact, WE THE PEOP .. uh... USERS are the Q/C around here and, frankly, this is OK. It's a valid development model, Open Source do it all the time with variable degree of success (things can go horribly wrong this way, but from the many KSP problems, this is not one of them).

In a nutshell, the product bugs are known and are (informally and formally) documented, so definitively we don't have a Q/C problem.

And it's out of the scope for Q/A to address the bugs not being fixed, as this is not their job: they are not the one calling the shots.

The Q/A guy can report (usually internally, as formal Requirements are not usually published) any perceived non-compliance ad nauseam, the report can be easily dismissed by the Product Owner (or whatever they name the guy that call the shots on the product) as "works as specified" - and end of the history. Of course, the Q/A guy can try to file a "bug" against the Requirement itself, but not rarely this is out of scope for him - as I said above, Q/A are not the one calling the shots.

And when the Project doesn't have a formal tracking for the Requirements, it's even hard to blame the Q/A for the product going downhill: without a clear and detailed list of Requirements, their calls can be easily dismissed by the Product Owner without hope of appeal. Worst, the P.O. can easily second thought things later, and this makes the Q/A guys tipping on their toes all the time: they never know for sure when they will be blamed for wasting time reporting some things and when they will be blamed by not reporting them.

IMHO, the whole Development Process is flawed beyound measure, and your perception about Q/A is nothing but the most visible symptom of the real, inherent and subjacent problem.

Edited January 12, 2022 by Lisias
being yet more picky. :)

[Staticalliam7]

Wouldn't automatically locking parts if they are not in motion actually fix the drift?

[dok_377]

7 minutes ago, Lisias said:

IMHO, the whole Development Process is flawed beyound measure, and your perception about Q/A is nothing but the most visible symptom of the real, inherent and subjacent problem.

Sure, however you want to call it. I'm not very familiar with software development, so I might get some terms wrong and point at the wrong people. Somewhere in the process was a flaw and the final product suffered from that immensely, that's what I was saying primarily. 

[Lisias]

18 minutes ago, Staticalliam7 said:

Wouldn't automatically locking parts if they are not in motion actually fix the drift?

As long you never unlock them (what kinda defeats their purpose at first place).

Everytime you unlock something, they will start to drift a bit until locked again - and these small drifts are permanent once happened, so they are cumulative.

For the most simple use cases, this appears to be enough - but on really Kerbal designs, the drift sooner or later will hurt the craft: you are only postponing the unavoidable.

Edited January 12, 2022 by Lisias
better grammars. I'm evolving!

[Staticalliam7]

13 minutes ago, Lisias said:

As long you never unlock them (what kinda defeats their purpose at first place).

Everytime you unlock something, they will start to drift a bit until locked again - and these small drifts are permanent once happened, so they are cumulative.

For the most simple use cases, this appears to be enough - but on really Kerbal designs, the drift sooner or later will hurt the craft: you are only postponing the unavoidable.

Ah, ok. Any clue as to what causes drift?

[Lisias]

4 hours ago, Staticalliam7 said:

Ah, ok. Any clue as to what causes drift?

Yep. This was diagnosed by a fellow Kerbonaut and posted on the KSP 1.12.2 release thread:

 

[Staticalliam7]

2 hours ago, Lisias said:

Yep. This was diagnosed by a fellow Kerbonaut and posted on the KSP 1.12.2 release thread:

Ah, makes sense. Is there a mod that corrects this, or is it too deep within the game's code to mess with (without losing your mind)

[Lisias]

On 1/12/2022 at 11:52 PM, Staticalliam7 said:

Ah, makes sense. Is there a mod that corrects this, or is it too deep within the game's code to mess with (without losing your mind)

Not yet, AFAIK.

[BezKartuza]

PEOPLE! Someone tell me how to fix this: All my landers skim the surface of planets (Laythe, Eve). Am I only one with this problem?
Is there any mod that fixes this?

[Krazy1]

9 hours ago, BezKartuza said:

PEOPLE! Someone tell me how to fix this: All my landers skim the surface of planets (Laythe, Eve). Am I only one with this problem?
Is there any mod that fixes this?

Me too... I believe they were trying to improve rovers rolling over when driving by making the surface much more slippery in 1.12. It's like driving on ice now. Problem is everything slides around when parked. Everything slides downhill... all the way down until you get below a couple degrees slope. AND if you're sliding too fast you can't save your game or change ships! Ugg. I had to use RCS on my lander to stop sliding so I could change ships. That was on the Mun.  Bigger planets are probably worse. What if the RCS trick doesn't work? Just wait 10 minutes until you slide to the bottom of the valley?

[BezKartuza]

40 minutes ago, Krazy1 said:

Me too... I believe they were trying to improve rovers rolling over when driving by making the surface much more slippery in 1.12. It's like driving on ice now. Problem is everything slides around when parked. Everything slides downhill... all the way down until you get below a couple degrees slope. AND if you're sliding too fast you can't save your game or change ships! Ugg. I had to use RCS on my lander to stop sliding so I could change ships. That was on the Mun.  Bigger planets are probably worse. What if the RCS trick doesn't work? Just wait 10 minutes until you slide to the bottom of the valley?

When the "lander" (it's a whole rocket!) weighs over 120 tons (on Eve) RCS doesn't help at all. 
So it's like that for everyone.

[Lisias]

8 hours ago, Krazy1 said:

Me too... I believe they were trying to improve rovers rolling over when driving by making the surface much more slippery in 1.12. It's like driving on ice now. 

Huge mistake as it appears. Another one, by the way.

We are coming to a point in which we will probably need to replace most of the stock Modules in order to get a decent KSP experience…  

[Anth]

On 1/15/2022 at 9:19 PM, BezKartuza said:

PEOPLE! Someone tell me how to fix this: All my landers skim the surface of planets (Laythe, Eve). Am I only one with this problem?

And @Krazy1 and @Lisias

There's an issue with the friction. I cant remember if it was fixed in 1.12.2 or not. For wheels simply increase the friction until the wheels operate as they should

For Landing Legs the friction adjustment in the action menu for the landing gear can be turned on by setting autoFrictionAvailable = True in the following files: landingLegLT-1.cfg, landingLegLT-2.cfg, and landingLegLT-5.cfg and their locations are in the KSP folder location: GameData\Squad\Parts\Utility\

@Marlus was the one who figured out how to enable the friction adjustment for the landing legs

Then the sliding should stop. 

Here is his video for that fix:

 

[BezKartuza]

22 minutes ago, Anth12 said:

@Marlus was the one who figured out how to enable the friction adjustment for the landing legs

Then the sliding should stop. 

Here is his video for that fix:

Thanks! Need to try

[Lisias]

9 hours ago, Anth12 said:

There's an issue with the friction. I cant remember if it was fixed in 1.12.2 or not. For wheels simply increase the friction until the wheels operate as they should

For Landing Legs the friction adjustment in the action menu for the landing gear can be turned on by setting autoFrictionAvailable = True in the following files: landingLegLT-1.cfg, landingLegLT-2.cfg, and landingLegLT-5.cfg and their locations are in the KSP folder location: GameData\Squad\Parts\Utility\

Good to know! Really.

On the not so bright side, I fail to understand how a so simple fix for a very annoying and widespread problem is not yet on the mainstream.

They had the code ready to be used on the codebase, why nobody had the idea to activate it - or at least, create an option to activate it under user's choice if, by some reason, some collateral effect is expected from it?

[Anth]

9 minutes ago, Lisias said:

They had the code ready to be used on the codebase, why nobody had the idea to activate it - or at least, create an option to activate it under user's choice if, by some reason, some collateral effect is expected from it?

I think Wheels and Legs are the same as far as KSP1/Unity is concerned. But I don't remember there being any issues with Legs friction wise until 1.12.0 so that might be why

[Lisias]

On 1/16/2022 at 8:35 PM, Anth12 said:

I think Wheels and Legs are the same as far as KSP1/Unity is concerned. But I don't remember there being any issues with Legs friction wise until 1.12.0 so that might be why

What leads to the unavoidable conclusion that Squad had made crucial changes on the engine without the proper planning, care or testing. They are plain throwing… things.. into the wall in the hopes they stick…  

Look, I'm not complaining about the enhancements (besides not agreeing with the "price" being paid until the moment for them). I'm not even complaining about the bugs anymore. I'm really worried about the current Modus Operandi on the "development" (that, frankly, is more as undevelopment than anything by this time).

I'm doing what Squad should had done at first place: I'm doing regression tests for the complains I find here to see when and where they started to happen. Dude, this is not pretty - we have versions and versions of KSP with bugs pilling up on each other, what unavoidably leads to being trapped into a corner: you can't fix a nasty bug because some workarounds were build around it and by fixing the problem you will be reopening a lot of issues that would be needed to be reworked properly this time.

And we know that, at this current state of affairs, reopening issues is the last thing they are willing to do.

— — POST EDIT 2022-0122 — --

I think some people will be interested on my findings reported here:  https://github.com/net-lisias-ksp/KSP-Recall/issues/27#issuecomment-1018550508

Edited January 22, 2022 by Lisias
post edit.

[mike1131]

i wish they would allow 1.3 on steam

 

[Lisias]

1 hour ago, mike1131 said:

i wish they would allow 1.3 on steam

 

Try Download Depot.  There's a tutorial on Steam called "Guide :: How to Download Older Versions of a Steam Game" (link to the google search, can't link directly to the page because the dude used some Non Forum compliant images, mas perhaps the reddit link would?). It's dated Mar 25, 2017 .

Or you can use the Steam Console.

You will need the hashes for the 1.3.1:

• Windows 32 bits
  • download_depot 220200 220201 6129985237511607976
• MacOS
  • download_depot 220200 220202 740055444469864354
• Linux
  • download_depot 220200 220203 7676773296554629902
• MacOS
  • download_depot 220200 220204 4879731577466528628
• Common:  Optional Language Packs
  • Spanish
    • download_depot 220200 220205 143373120223001808
  • Russian
    • download_depot 220200 220206 5929644944683924316
  • Japanese
    • download_depot 220200 220207 2345161979639010300
  • Simplified Chinese
    • download_depot 220200 220208 8519037663549102451

— — POST EDIT — — 

Unless you are looking for an Add'On that works only (or best) on KSP 1.3.1, I would recommend trying KSP 1.4.3 instead. While developing DOE, I learnt that Unity 2017 have huge visual improvements over Unity 5, and it may worth the change - not to mention Making History (I really enjoyed this one).

Additionally, if you are using an old rig with a 512MB GPU, KSP 1.4.3 is the last version that works fine on these old potatoes. On 1.4.4 they increased the PQS Cache (or something like that) and since then old potatoes started to sweat on it (KSP 1.4.3 runs fine on a MacMini 5.1 : Mobile i5 with Intel HD3000 and ~380MB of VRAM; from KSP 1.4.4 and newer, you will need at least a HD4000 with more than 512MB to have some fun on KSP).

Edited January 23, 2022 by Lisias
POST EDIT

[kerbiloid]

The cumulative dock drifting is just realistic.
It's not a bug, it's a feature.

Look at any real spaceship description.

"Maximum flight duration.
Autonomus: 14 days.
Docked: 270 days,"

So, as you can see, even the real world ships can't stay docked for a year.
You should undock and deorbit them much sooner, and the redocking doesn't help.

While the permanent station modules stay docked for decades without problems, being never undocked.

So, either the real world has the same bug as KSP 1.12.x, or KSP 1.12.x simulates the real world perfectly.

It just makes you plays nicely, without the gamish time cheating.

Edited January 24, 2022 by kerbiloid

[Starwaster]

On 1/24/2022 at 6:14 AM, kerbiloid said:

The cumulative dock drifting is just realistic.
<snip>

So, as you can see, even the real world ships can't stay docked for a year.

This is wrong.  The lifetime of spacecraft docked at the ISS has nothing to do with 'dock drift'. That's just a KSP thing resulting from math errors with the craft as it is continously serialized/deserialized over time.

The reason why real world spacecraft have to be undocked and de-orbited is due to deterioration of the craft and its propellants and other consumables.

Edited February 1, 2022 by Starwaster

[kerbiloid]

11 minutes ago, Starwaster said:

This is wrong.  The lifetime of spacecraft docked at the ISS has nothing to do with 'dock drift'. That's just a KSP thing resulting from math errors with the craft as it is continously serialized/deserialized over time.

The reason why real world spacecraft have to be undocked and de-orbited is due to deterioration of the craft and its propellants and other consumables.

But that was the easiest way to simulate the reality.

[Starwaster]

On 2/1/2022 at 10:25 AM, kerbiloid said:

But that was the easiest way to simulate the reality.

It's not simulating reality.

It's broken. It's a bug. It's defective.