55 replies to this topic

[TamerSA]

Burakumin1979, on 03 June 2014 - 04:38 PM, said:

PGI,

Please, for the love of all that is software development, please develop Configuration Management/Version Control. I'm trying my hardest to imagine a scenario where code gets pushed to the production environment like this (not testbed/development environment).

I would forgive this if the clan missile code wasn't a glaring example of you not having these systems in place or being used.

It's not like this was really a huge bug, and they did catch it fairly early which is good.

But I do agree that a completely unrelated problem showing up after a patch does stink of old code versions or bad source control before the patch...

VSS is fairly easy to use for small teams, it works in our company. And there are even completely free options like Tortoise SVN if they don't want to budget for it. Just putting it out there

[Burakumin1979]

Although I thank you for listing some solutions to help them, it's more an organization-wide climate of strict controls on systems thats necessary.

You can tell that a systems engineer wasn't in place managing development when you hear things like having an alteration of missile code affecting all missiles types. When the clan code, that somehow "accidentally" made it into a patch release, broke all three classes of missiles, the instant possible explanation was that there hasn't been true separation of their code and that it was developed as "spaghetti-code" with variables clearly out-of-scope. The trebuchet issue is certainly also indicative of this. They made no changes to that mech yet code somewhere broke its internals.

Further, exhaustive testing on a truly base-lined and accurately representative testbed means that errors like the missile issue are simply caught prior to going live. A base-lined testbed is yet another configuration management responsibility.

Edited by Burakumin1979, 04 June 2014 - 11:28 AM.

[TamerSA]

Burakumin1979, on 04 June 2014 - 11:28 AM, said:

Although I thank you for listing some solutions to help them, it's more an organization-wide climate of strict controls on systems thats necessary.

You can tell that a systems engineer wasn't in place managing development when you hear things like having an alteration of missile code affecting all missiles types. When the clan code, that somehow "accidentally" made it into a patch release, broke all three classes of missiles, the instant possible explanation was that there hasn't been true separation of their code and that it was developed as "spaghetti-code" with variables clearly out-of-scope. The trebuchet issue is certainly also indicative of this. They made no changes to that mech yet code somewhere broke its internals.

Further, exhaustive testing on a truly base-lined and accurately representative testbed means that errors like the missile issue are simply caught prior to going live. A base-lined testbed is yet another configuration management responsibility.

I could have thrown more jargon at the issue too, but I didn't want to bore people

[Burakumin1979]

TamerSA, on 04 June 2014 - 11:47 AM, said:

I could have thrown more jargon at the issue too, but I didn't want to bore people

Hehe, fair enough.

[Burakumin1979]

Russ just posted:

The game client itself goes into lock down on a 2-week testing protocol to achieve approval status before release to live production."

I want to believe this. While this would, admittedly, still allow an issue like the trebuchet internals to slip through testing, the missile issue would NEVER have made it through.

Edited by Burakumin1979, 04 June 2014 - 12:12 PM.

[TamerSA]

Burakumin1979, on 04 June 2014 - 12:11 PM, said:

Russ just posted: The game client itself goes into lock down on a 2-week testing protocol to achieve approval status before release to live production." I want to believe this. While this would, admittedly, still allow an issue like the trebuchet internals to slip through testing, the missile issue would NEVER have made it through.

Would depend on how good their testing process is, whether they have proper unit tests to cover baseline scenarios to ensure that no existing functionality was broken in the process etc etc.

But a two week code freeze (assuming that is what "client lockdown" refers to) and a proper testing window should have gone a long way to preventing these kind of problems.

However with all that said and done.... it's easy to point this out when it's not your team making the mistakes. I can honestly admit that even with very strict processes in place I've seen my share of things falling through the cracks in some of the software companies I've worked for

[Burakumin1979]

Yeah, here's to hoping they've identified the holes in their testing process and plugged them up.

The matter of a code-rewrite...you know, at this point, they should choose a stable client build and put someone on the rewrite. In 2-3 months it should be ready to reaplce the stable build and they can continue on with a stronger code base and the ability to make the correct types of changes.

[Zerberus]

AdamBaines, on 03 June 2014 - 04:49 PM, said:

It is an interesting issue. Being a software QA analyst, I'm guessing this was out of scope in their regression test bed. Nothing that was changed (on the surface) would have effected this mech, unless show how the two Hero chasis (Treb and BJ) shared some component.

Yep, that`s actually the point people seem to miss, and it`s ironically not even specific to software development or even the IT industry, it`s actually nothing more than basic common sense used to streamline a process. That being that you do not usually recheck things that you know (or at least assume) did not change and have no known reason to do so without outside factors.

Or do you people check your car every day if your winter (or summer, dep. on season) tires are still mounted, even if you put them on yesterday? After all, you could get a ticket if someone swapped them for you overnight as a surprise favor....

Or do you unpack your suitcase again, just to make sure that you packed everything, even though you checked off every item as you packed it? After all, maybe the daughter you don`t have yet just suddenly materialized in ethereal form and deviously took your toothbrush or favorite underwear back out....

Or maybe you walk into the kitchen every 5 minutes to turn the oven off just in case, even though you haven`t used it since January? After all, maybe your cat suddenly developed a penchant for weed brownies and turns out to be a mad baker but forgot to turn it off (possibly because it was baked )

This is exactly the same thing, you do things step by step, check and verify your work at each step, and when it`s done you continue with the next task or phase of the process and don`t waste thought ot time on work that is already "done". You don`t go off looking for completely random unexpected issues that may or may not pop up just "because you can", becasue that is almost always an absolute waste of resources.

There are just some things that no amount of planning and quality control can avoid. For example I build rollercoasters, and the degree of precision and planning is just staggering (and also a fair portion of the approxmately 12 months it takes to build one). Track parts are fit to tolerances of .05mm in the shop... and every once in a while still end up entire centimeters off when the boys are out in the parks assembling them, which is a huge *********** for them, but in 99.99% of the cases it was not something that anybody could have realistically expected (Nature!!). Still means we have to fix it, though, and damn fast, becasue the ride is opening next week.

However, hat does not in any way change that I spent approx. 8 hours making sure the fit on both ends was absolutely perfect, that all the welds were perfect, that the trusses were in the proper order... And checking it all another 30000000000 times wouldn`t have changed the final outcome, either.

In real life, sometimes **** just happens, and it doesn`t matter who you are, it will eventually happen to you, too. All you can do is deal with it.

Now, PGI admittedly doesn`t have the best track record as far as things like this go, so at least an audit of their QC standards is probably warranted, and maybe somebody even needs to get bitchslapped. But these constant accusations that PGI is completely incompetent and /or making mistakes "on purpose" help nothing and serve only to undermine yourt own credibility, especially when accompanying statements are just dripping with ignorance of the subject at hand.

To which point: those "laughing" at the 7kb /20 minutes statement obviously have a knowledge deficiency with regards to server farm maintenance in general, especially ones that are supposed to be simultaneously readily accessible from the WWW and secure.

Edited by Zerberus, 05 June 2014 - 09:52 AM.

[Burakumin1979]

Zerberus, I have to argue with you.

The presence of spaghetti code isn't something that happens to all of us, its something that is purposely avoided during the design process. A logical map of modular objects in their code was undoubtedly done (or hopefully done) so that inserted clan LRM missile code affecting all types of missiles is fairly impossible UNLESS they modified the generic missile template, but the level of incomptency or just lack of common sense that that would take to do that....I'm not going to assume is present at PGI.

The truth is, they have a history of poor game design and they are living up to it. Its just unfortunate that they are doing it with such a beloved title.

[Zerberus]

You `re not arguing with me even if you think you are, bro. I NEVER said that PGIs code was flawless and that they make no mistakes, but that people constantly assume that they have no interest in doing their job properly, and attack them from that standpoint. Which is BS.

Because every dev in the world (and actually every job in the world, period) functions off of one basic intangible: That you are in fact doing it correctly.

As a rule, people assume they are in fact doing it correctly until shown otherwise. Like how most people eat a banana in a way that even a monkey can't understand, and then the monkey teaches them how to do it the right way.

However, to make that statement about the code quality, I`m going to have to assume you have decompiled the game files into their original form and have a proper working knowledge of C++? At which point I have to ask you why, with your skill set, you have not directly submitted this feedback with corrections and /or applied for employment?

Because if you really want to help and can, then flaming them on the forums is by far the greatest waste of your time and skills imaginable considering the myriad of useful alternatives.

[Burakumin1979]

First, I'm not flaming them. Pointing out obvious deficiencies in their development, testing, and configuration management processes isn't flaming, it's stating the obvious.

Second, my time is valuable and I won't do their job for them. The fact that they can't afford me is why I don't apply for a job with them.

This is a released software title. Not a beta. With that distinction comes the basic premise that basic and fundamental mechanics work.

Hit registration isn't a bug, its a failure to reach a basic set of design goals. The first of those being a fully-functioning game.

I could forgive balance/meta concerns. That comes with time and evaluation. I can forgive delayed additional maps, mechs, weapons by manaufacturer, etc., thats all secondary to what is missing:

A fully functioning game.

The resistance to focusing ALL assets on meeting that one goal is a little unnacceptable. They put one guy on it.. Is that guy working 90+ hours a week? Because he should be.

You can white-knight all you want, they need to fix the basic mechanics of their game. Until then I, and many others, aren't going to toss disposable income at a waste of time.

[AdamBaines]

Zerberus, on 05 June 2014 - 09:31 AM, said:

Yep, that`s actually the point people seem to miss, and it`s ironically not even specific to software development or even the IT industry, it`s actually nothing more than basic common sense used to streamline a process. That being that you do not usually recheck things that you know (or at least assume) did not change and have no known reason to do so without outside factors.

Or do you people check your car every day if your winter (or summer, dep. on season) tires are still mounted, even if you put them on yesterday? After all, you could get a ticket if someone swapped them for you overnight as a surprise favor....

Or do you unpack your suitcase again, just to make sure that you packed everything, even though you checked off every item as you packed it? After all, maybe the daughter you don`t have yet just suddenly materialized in ethereal form and deviously took your toothbrush or favorite underwear back out....

Or maybe you walk into the kitchen every 5 minutes to turn the oven off just in case, even though you haven`t used it since January? After all, maybe your cat suddenly developed a penchant for weed brownies and turns out to be a mad baker but forgot to turn it off (possibly because it was baked )

This is exactly the same thing, you do things step by step, check and verify your work at each step, and when it`s done you continue with the next task or phase of the process and don`t waste thought ot time on work that is already "done". You don`t go off looking for completely random unexpected issues that may or may not pop up just "because you can", becasue that is almost always an absolute waste of resources.

There are just some things that no amount of planning and quality control can avoid. For example I build rollercoasters, and the degree of precision and planning is just staggering (and also a fair portion of the approxmately 12 months it takes to build one). Track parts are fit to tolerances of .05mm in the shop... and every once in a while still end up entire centimeters off when the boys are out in the parks assembling them, which is a huge *********** for them, but in 99.99% of the cases it was not something that anybody could have realistically expected (Nature!!). Still means we have to fix it, though, and damn fast, becasue the ride is opening next week.

However, hat does not in any way change that I spent approx. 8 hours making sure the fit on both ends was absolutely perfect, that all the welds were perfect, that the trusses were in the proper order... And checking it all another 30000000000 times wouldn`t have changed the final outcome, either.

In real life, sometimes **** just happens, and it doesn`t matter who you are, it will eventually happen to you, too. All you can do is deal with it.

Now, PGI admittedly doesn`t have the best track record as far as things like this go, so at least an audit of their QC standards is probably warranted, and maybe somebody even needs to get bitchslapped. But these constant accusations that PGI is completely incompetent and /or making mistakes "on purpose" help nothing and serve only to undermine yourt own credibility, especially when accompanying statements are just dripping with ignorance of the subject at hand.

To which point: those "laughing" at the 7kb /20 minutes statement obviously have a knowledge deficiency with regards to server farm maintenance in general, especially ones that are supposed to be simultaneously readily accessible from the WWW and secure.

THIS THIS THIS THIS!!!!!!!!!

[Colonel Fubar]

Round and Round PGI goes where its stops nobody knows!

[C E Dwyer]

Choice, on 03 June 2014 - 04:32 PM, said:

So people really use the Bucket's.

Never had an issue with trebs, tag, alrm,(this was before the buff) medium lasers, and the biggest xl you can fit.

The K gauss and erppc

[C E Dwyer]

I'd just like to point out that, at least, in the UK it is infact, illegal to set out on a journey with a vehicle that does not meet the legal road requirements and that drivers are supposed to check their car.lorry, bus etc, before every trip.

However I doubt more than 0.0001 % of the uk population actually do this, and would rather blame the government, various dieties, or any thing but themselves, along the lines of I parked illegally, I got a ticket, and so its the traffic wardens fault for being an asshead, not me, as I needed to park there as the legal parking spot was another 75 yards away.

So can we have another example please Zerb though I do agree with what your saying