Patch 1.4.3 to be released next week!

[LoSBoL]

1 minute ago, Errol said:

I stand corrected. However, that is just a small discrepancy in the chronology of my post. My points still stand. Also.....the mass exodus was more of a gradual trickle, if I remember correctly.

Your points still stand, absolutely. I pointed out the chronology, because I think its important that stories don't get lives of their own.

It indeed all went south from their on, I also think the console port fiasco attributed to the damage and where we are now with KSP.

[Lisias]

2 hours ago, nanobug said:

I'm not so sure that releasing a patch that introduced a game breaking bug was a business decision.  Pushing the 1.4 release before it was ready to get the DLC out?  Sure.   But this landing leg thing feels more like typical code debt that piled up well before Take Two ever got involved.  They probably need to do a bunch of refactoring because the code base is getting sloppy and fixing one thing breaks 2 other things.  It's a common problem.

 

Disclaimer: It's all pure speculation, I'm pulling all of this out from my... hat... :-) and I'm extrapolating using what I learnt from my previous work on a multinational corporation. It's essentially a fictional short story. :-) A plausible one, nevertheless.

The 1.4.0 launching date was a business orientated decision (ie., something that must happens to satisfy a business interest, and not necessarily decided by a business man). I think this is what happened due the somewhat large number of unhandled bugs - but hey we got Parachutes and some product Localizations (Brazil, Italy, German and French - exploring new markets may be the business need to be addressed ASAP). The 1.4.1 version was probably already scheduled (or at least planned) by the tech staff, as these guys are not stupid and already knew that 1.4.0 was going gold before being ready.

Something messed up in the mean time, and 1.4.1 was launched before being ready too. *THIS* is the real issue, as it appears.

1.4.2 was so *fiercely* rushed into production, in the most corporate style: in the blind believe that 9 pregnant women can deliver a baby per month in the next 9 months.

Edited April 21, 2018 by Lisias
bad grammar...

[Mark Kerbin]

@BLN.... Rockstar does not own KSP....

    Take2 Interactive

           /         \

Squad           Rockstar 

     |                        |

  KSP                  GTA

 

 

Also lets be honest about the DLC here. It isn't bad, just buggy. As it gets polished and people figure out how it works, the overall experience improves. 

Edited April 21, 2018 by Mark Kerbin

[StrandedonEarth]

I'm one of the generally silent ones that prefers they take their time and get it right, even though there are major bugs right now. As for the complaint that content is holding up bugfixes, well, I, and presumably most if not all of the modders, would prefer one patch instead of two.

Disclaimer: I've been on the edge of KSP burnout for awhile now, and haven't even touched 1.4.x yet. But I'm still fairly active in the forum (even if I'm just lurking a lot of the time), it's my goto website. So I've just been patiently waiting for the game to get back to a point where I feel comfortable downloading the newest version, and the required mods, to see if my 1.3.1 save plays nice with 1.4.x. Yes, I usually start a new save with a new version, but I'm not done with my old save yet. Until then....

Edited April 21, 2018 by StrandedonEarth

[HafCoJoe]

And honestly speaking all of us could be wrong. It could be that they released 1.4 without knowing the extent of bugs. The Devs almost never give a release date, the reason demonstrated in the last four pages here. It might not even be tied to a predetermined date. The DLC certainly wasn't.

Going into personal opinions now, Take Two is a lot less sketchy than the previous corporation that owned Squad. I have no qualms with them. Also, I think the slow trickle of players leaving wasn't caused by a bad release or series of releases. I think it was caused by people 'finishing' what they came here for, and leaving. Simple as that. I've been here for 5+ years and I've come ans gone multiple times when I got bored. Still do. These are just my own opinions though.

[LoSBoL]

8 minutes ago, Mark Kerbin said:

@BLN.... Rockstar does not own KSP....

    Take2 Interactive

           /         \

Squad           Rockstar 

     |                        |

  KSP                  GTA

 

 

Also lets be honest about the DLC here. It isn't bad, just buggy. As it gets polished and people figure out how it works, the overall experience improves. 

Almost...  I think its a little different

Take 2 Interactive -> owns Private Division label, the label has been created for Indie game development.
Private Division-> owns the Kerbal Intellectual property, and therefore own KSP.
Squad-> Doesn't own anything, they just continue developing KSP, because either Private Division or Take 2 Interactive let them. (It could even be a condition for the sale to Take 2, but we don't know that)

What lies in the future? Nobody knows. What we should be able to say is, that Take 2 purposely created Private Division for indie type game development, to give indie developers creativity room with a solid financial backing from Take 2, but without Take 2 taking charge over development route. 

 

[Mark Kerbin]

Just now, LoSBoL said:

Almost...  I think its a little different

Take 2 Interactive -> owns Private Division label, the label has been created for Indie game development.
Private Division-> owns the Kerbal Intellectual property, and therefore own KSP.
Squad-> Doesn't own anything, they just continue developing KSP, because either Private Division or Take 2 Interactive let them. (It could even be a condition for the sale to Take 2, but we don't know that)

What lies in the future? Nobody knows. What we should be able to say is, that Take 2 purposely created Private Division for indie type game development, to give indie developers creativity room with a solid financial backing from Take 2, but without Take 2 taking charge over development route. 

 

I was going for general idea of who does what. BLN was under the impression that Rockstar was the KSP dev team

[LoSBoL]

Just now, Mark Kerbin said:

I was going for general idea of who does what. BLN was under the impression that Rockstar was the KSP dev team

That makes sense

I thought I'd clarify a little about how KSP is really set up. There are a lot of stories out there about Take 2 having taken charge over KSP, but the current construction 'should' actually stop that from happening and gives more freedom to take choices on development route without Take 2 calling shots.

[GDJ]

41 minutes ago, StrandedonEarth said:

I

[Raptor9]

2 hours ago, Avera9eJoe said:

It might not even be tied to a predetermined date.

I remember way back in the day when Maxmaps (one of the original producers that streamed KSP on Twitch every Friday) mentioned that they usually projected a fixed release date fairly far in advance, based on a running estimate on when the next version would be ready with the features they prioritized for that version.  He said the main driving factor was coordinating press releases, syncing the website update with the new KSP game files, the Steam update, etc.  Pretty much a bunch of stuff that was logistical in nature and for the most part not game development related.

But I think that only applies with major updates, not patches; since those probably don't require huge database updates or press information.  I regretfully don't have a citation link provided, it was quite a long time ago early in the alpha stages of development and I don't recall if he mentioned it in the forums or on one of his streams.  I also realize that the current development cycle/team itself is undoubtedly much different than back then, with different producers, team members etc; but it would stand to reason that the logistics of getting updates "out there" hasn't changed much.

Of course, I could be completely, blatantly wrong for all I know.  The first paragraph is relying solely on my personal memory, and the second paragraph is pure conjecture on my part.

2 hours ago, Avera9eJoe said:

The Devs almost never give a release date, the reason demonstrated in the last four pages here.

Completely agree.  Better to have speculation on when the next release will happen and let the "Soon^TM" memes flow than let the pitch forks assemble when an update or patch is delayed beyond the announced date. 

[HafCoJoe]

2 minutes ago, Raptor9 said:

I remember way back in the day when Maxmaps (one of the original producers that streamed KSP on Twitch every Friday) mentioned that they usually projected a fixed release date fairly far in advance, based on a running estimate on when the next version would be ready with the features they prioritized for that version.  He said the main driving factor was coordinating press releases, syncing the website update with the new KSP game files, the Steam update, etc.  Pretty much a bunch of stuff that was logistical in nature and for the most part not game development related.

But I think that only applies with major updates, not patches; since those probably don't require huge database updates or press information.  I regretfully don't have a citation link provided, it was quite a long time ago early in the alpha stages of development and I don't recall if he mentioned it in the forums or on one of his streams.  I also realize that the current development cycle/team itself is undoubtedly much different than back then, with different producers, team members etc; but it would stand to reason that the logistics of getting updates "out there" hasn't changed much.

Of course, I could be completely, blatantly wrong for all I know.  The first paragraph is relying solely on my personal memory, and the second paragraph is pure conjecture on my part.

Completely agree.  Better to have speculation on when the next release will happen and let the "Soon^TM" memes flow than let the pitch forks assemble when an update or patch is delayed beyond the announced date. 

Yo! Huh, I didn't know that before and that definitely makes a lot of sense. Thanks for the insight!

[LoSBoL]

33 minutes ago, Raptor9 said:

Completely agree.  Better to have speculation on when the next release will happen and let the "Soon^TM" memes flow than let the pitch forks assemble when an update or patch is delayed beyond the announced date. 

I do think there is a big diference in Squad giving expected release dates, or giving a week in advance notice they are dropping a new patch upon their players. I've commended Squad for doing the last because I like to get a heads up. I hope Squad keeps week notices for next patches, but finish all the bug testing first, and only then announce the release for next week. There are going to be comments anyway.

[pandaman]

I am disappointed by the delay, but much rather that than a rushed and buggy patch.

Just a thought, but...

I know they gave the reason for the delay as a fault affecting the new airstrip etc, but I suppose it's possible that it is, or they fear it could be, a symptom of an issue that could have much deeper implications and affect other things.  Not sure why they didn't say so if that is the case, but...

[Capt. Hunt]

In all fairness, 1.4.2 is far from unplayable.  There are a handful of bugs, but nothing that is totally game breaking.  There's even a few work-arounds for most of them in the forums.   I for one am just focusing on LKO and cis-munar stuff while I wait.

 

The thing a lot of people don't seem to realize is that coding is hard.  This isn't an industry where you can always look at something, instantly see that it's wrong and know how to fix it.  It's not like they're dealing with a few misplaced commas or typos (if anything the coding software will catch most of those by itself).  A lot of bugs happen in the unintended consequences.  You write a piece of code for something, it looks perfectly fine, it passes the compiler check, it might even be working completely as intended by itself, but somehow it messes up some process that's seemingly unrelated, and suddenly landing legs have the tensile strength of wet paper instead of steel.  It's almost like that old chaos theory standby; "A butterfly flaps its wings in Peking, and in Central Park you get rain instead of sunshine."  That kind of bug is hard to track down, and even harder to fix, because you don't want to break the intended function in the process.

Edited April 22, 2018 by Capt. Hunt

[DeliriumTrigger]

9 minutes ago, Capt. Hunt said:

In all fairness, 1.4.2 is far from unplayable.  There are a handful of bugs, but nothing that is totally game breaking.  There's even a few work-arounds for most of them in the forums.   I for one am just focusing on LKO and cis-munar stuff while I wait.

 

The thing a lot of people don't seem to realize is that coding is hard.  This isn't an industry where you can always look at something, instantly see that it's wrong and know how to fix it.  It's not like they're dealing with a few misplaced commas or typos (if anything the coding software will catch most of those by itself).  A lot of bugs happen in the unintended consequences.  You write a piece of code for something, it looks perfectly fine, it passes the compiler check, it might even be working completely as intended by itself, but somehow it messes up some process that's seemingly unrelated, and suddenly landing legs have the tensile strength of wet paper instead of steel.  It's almost like that old chaos theory standby; "A butterfly flaps its wings in Peking, and in Central Park you get rain instead of sunshine."  That kind of bug is hard to track down, and even harder to fix, because you don't want to break the intended function in the process.

Being a machinist is hard too but I don't get to give my customers products that don't meet specification because it's hard.  This isn't an early access game, we paid for a finished game and we deserve better.  The landing leg bug is game breaking, and if it can be addressed by a work-around then said work around should have been pushed out as a patch instead of making people break out a text editor to do Squad's job for them.

I sympathize with their struggle but they don't deserve a pass on this.  We can still support the game, be fans of it, and state that this is unequivocally unacceptable. 1.4.2 was released on March 28th.  That's nearly a month with a major bug and we're still waiting for a fix.

[Gargamel]

 

16 hours ago, steve_v said:

While I would sometimes like some names, so I can say "Gus the PR guy is clearly a moron, he orchestrated this whole debacle", it's probably best for everyone that we don't have those details.

Actually, we do, and it's linked at the top of this very page:

https://forum.kerbalspaceprogram.com/index.php?/staff/

But, no, we don't have staff assignments for who's working on what code. 

[Bill Phil]

58 minutes ago, nanobug said:

Being a machinist is hard too but I don't get to give my customers products that don't meet specification because it's hard.  This isn't an early access game, we paid for a finished game and we deserve better.  The landing leg bug is game breaking, and if it can be addressed by a work-around then said work around should have been pushed out as a patch instead of making people break out a text editor to do Squad's job for them.

I sympathize with their struggle but they don't deserve a pass on this.  We can still support the game, be fans of it, and state that this is unequivocally unacceptable. 1.4.2 was released on March 28th.  That's nearly a month with a major bug and we're still waiting for a fix.

Well, in truth, machining and coding are not comparable. I've got a little bit of experience in both, and I can tell you that coding was way more complex and sensitive. Just changing where a line of code was could improve the performance of the software massively. In my experience coding and software can be different based on what day of the week it is, the position of the planets, season, and the state of the weather... There's a very real possibility that 1.4.2 was extensively tested and some of these issues never occurred during testing. How software behaves is so sensitive to things like OS setups, hardware, and so on, that there's never a guarantee to how it will behave. The real issue here is likely to be that the testers probably have very specific hardware and software setups that do not adequately represent the average user's setups, thus leading to inconsistencies with how the game behaves. Of course, the game was never very stable to begin with.

Imagine if a machined piece changed shape massively based purely on who was using it and on random other factors and that you had to find the root cause in the tooling, and you'd get somewhat close to the issue at hand. 

I've had the landing legs explode on one mission - and work perfectly fine the next. I've had probes destroyed and probes not destroyed, even when doing the same thing. Software is just a different beast.

One time I read a thread about the Forum not working on Firefox. Thing was, I was using Firefox and it was running fine. The product can be perfectly fine and still not work.

Of course, these bugs do need to be squashed. They're very problematic if not downright game-breaking and should be eliminated ASAP. Hopefully 1.4.3 is stable.

[Eskandare]

6 minutes ago, Bill Phil said:

Well, in truth, machining and coding are not comparable.

CNC machines require coding; parts are made via the code to specification; QA inspector checks parts to meet specification; part goes to packing if it passes inspection. hmmm... 

KSP is not a simple game and bugs are inevitable, but there should be better QA to intercept these issues. At least they patch fix and patch again to correct these issues, and luckily software can be fixed. Machining, no; bad part equals loss of a contract, or someone gets hurt or dies due to failed part, so machining must have higher QA standards. 

Edited April 22, 2018 by Eskandare

[steve_v]

47 minutes ago, Bill Phil said:

Well, in truth, machining and coding are not comparable.

As someone who has spent some time digging around in the low-level code of (usually decrepit) CNC machines, I can assure you that it is. A CNC is a computer. It has an operating system, it runs user code. It usually has bugs. It has difficult to predict hardware issues to make finding the bugs more fun.

 

47 minutes ago, Bill Phil said:

In my experience coding and software can be different based on what day of the week it is, the position of the planets, season, and the state of the weather.

That is ridiculous. Computers, and the code they run, are logical and deterministic systems. There is no voodoo, no astrology, and unless you try quite hard to create it, no true randomness.
Sure, the code in a game like KSP is complex and there are many places bugs can creep in, but it's not magic, it's not alive, and it certainly doesn't react to the phase of the moon.
One does need to test on a variety of hardware configurations, that's simply the nature of supporting the "PC compatible" architecture. It's annoying, but that's how it is.

"It's complicated" does not excuse buggy code. It might make people more understanding of delays finding the bugs, but they're still bugs, and they still need to be fixed.
 

Edited April 22, 2018 by steve_v

[DomiKamu]

On 13/04/2018 at 2:03 AM, Hunony said:

thanks i cant wait for next update but i hope my mods still work

Yes, all developers will compile all of their plugins especially for you. :-)

Edited April 22, 2018 by DomiKamu

[DoToH]

- My car has no windshield
- Uh... Sorry.. our QA missed that, please forgive us.
- Please, install the windshield ASAP
- No. We have the windshield and the tools, but we'll wait until we receive the new trunk colored led light, becuse that's what you really want. You can drive your new car without windshield, wait one week more or use your old car instead.
- That's unacceptable.
- Don't be a whiner. You have to understand that cars are a very complicated piece of harware, with hundreds of different parts and the windshield is only one of them, an acceptable mistake. Please be patient and wait

I don't understand why this kind of conversation only happens when the broken/faulty product is software. None of the people of the "coding is hard" mantra would step out of their car dealer with a car with no windshield or their computer store with a keyboard without space bar and enter keys.

Coding is hard, so is manufacturing proccess design. Your keyboards have enter key and your cars windshield.

 

[Kerbart]

13 minutes ago, DoToH said:

-- Don't be a whiner. You have to understand that cars are a very complicated piece of harware, with hundreds of different parts and the windshield is only one of them, an acceptable mistake. Please be patient and wait

I don't understand why this kind of conversation only happens when the broken/faulty product is software. None of the people of the "coding is hard" mantra would step out of their car dealer with a car with no windshield or their computer store with a keyboard without space bar and enter keys.

Coding is hard, so is manufacturing proccess design. Your keyboards have enter key and your cars windshield.

 

What an adorable analogy. So cute. A windwshield is a pretty essential part when you drive a car though. It's like maneuver nodes not working. Sure you can play the came but it's very, very unpractical.

What you're attempting to describe though, is something like a recall. Dear Kerbart, we'd like to notify you that under certain conditions the seatbelts in your Rockomax Thunderbird might fail. Please call your dealer to make an appointment to have them replaced. Dealer: Yes, visit us 3 weeks from now. We'll need your vehicle for one afternoon. Three weeks later, dropped off the car, taking a taxi to work. At 3PM: Mr Kerbart? We discovered we need some extra parts for the replacement, and we don't have them in stock. You can pick up your vehicle this afternoon but you will have to bring it back two weeks from now...

Well imagine that would happen with cars. Impossible! They'd never treat you like that! Well... been there, done that. Half of Detroit apparently thinks this is the normal way to do things.

So yeah, this kind of behavior isn't really that special. Don't be a whiner.

[LameLefty]

5 hours ago, steve_v said:

As someone who has spent some time digging around in the low-level code of (usually decrepit) CNC machines, I can assure you that it is. A CNC is a computer. It has an operating system, it runs user code. It usually has bugs. It has difficult to predict hardware issues to make finding the bugs more fun.

 

That is ridiculous. Computers, and the code they run, are logical and deterministic systems. There is no voodoo, no astrology, and unless you try quite hard to create it, no true randomness.

If KSP was a DOS program circa 1988, that might be accurate.  Except that it's not. Software like KSP these days is not a uni-tasking, all-consuming piece of self-contained code that controls every aspect of the hardware it's running on. Rather, KSP.EXE is just one of dozens or even hundreds of processes running on multi-core processors, spitting off bits of code that are themselves running on GPU cores, borrowing and returning assets and subroutines from the operating system the machine is running, interacting with OS routines at every level from mouse inputs to screen and audio outputs ... 

Further, how many variants of "Windows" or "OS X" or "Linux" is KSP expected to run on?  Do each of these have dozens or hundreds of variants based on OS minor revision, hotfixes and security updates applied, graphics driver and revision? Of course. How many hardware variants are there among the customer base? Even more.

So no, software today is *NOT* truly deterministic at the level of KSP except on whatever specific machine and configuration it's being developed on.

 

[klgraham1013]

Costumers should not need to (and should not be expected to) know how the sausage is made.  A consumer only needs to compare a product to it's peers.  They don't need to concern themselves whether a chair was hand made by one person, by a team, or by a machine.  Only how that chair stacks up against other chairs on the market.

To a consumer, that your product is hard to make is no excuse.

[steve_v]

37 minutes ago, LameLefty said:

If KSP was a DOS program circa 1988, that might be accurate.

If KSP was a DOS program circa 1988, you wouldn't have all those handy OS facilities and abstraction toolkits to do half the work for you. Win some, loose some.

Again, "It's complicated" isn't an excuse for releasing code with major regressions. It might, to some extent, explain how they happened in the first place, but that's beside the point.

 

Ed.

37 minutes ago, LameLefty said:

Software like KSP these days is not a uni-tasking, all-consuming piece of self-contained code that controls every aspect of the hardware it's running on.

FWIW, neither is your average CNC system. The last one I worked on had 4 cpus and 3 monstrous FPGAs scattered around in various locations, each running their own code, in different languages, and communicating with at least 3 different protocols, not counting the various microcontrollers. And that one was built in 1988. They're even worse now, as they tend to run on Windows PCs with a stack of large and obscure proprietary co-processing PCI cards.

Despite all this complexity, (and running the frontend control software on Windows, of all things) somehow the manufacturers manage to find time to test them sufficiently that they neither produce defective parts, nor kill their operators while swinging 10+ ton components around at 1500RPM.

Edited April 22, 2018 by steve_v