-
Posts
1554 -
Joined
-
Ya Know...
Considering there's a thread out there arguing about "Spoilers", with the loose
consensus that it's mostly unwelcome if not outright rude and inconsiderate,
I can't help but wonder at the irony of you guys spilling the beans 2/3 the way
through the arc.
Epic Move.
/em facepalm
4 -
Quote:Simple. Via Gleemail.OK, I know I'm numerically challenged but that just sounds wrong. How can something sell for 2.5 billion but nobody can ever have more than 2 billion in their pocket.
Even if you somehow manage to buy it, the seller can't take in their profits. Well, perhaps with the market fees but there's still something wrong with that picture.
Step 1. Send me 900B in Gleemail
Step 2. Send me 900B in Gleemail
Step 3. Send me 700B in Gleemail
Step 4. I send you IO in Gleemail.
Done.
Regards,
4
PS> I've done this a few times - no problems at all -
Quote:As a quick caveat/wrinkle to the rule of 5's. Unlike ED penalties, the Rule of 5You can see your set bonuses, each by %, in the combat attributes window. They're global buffs, just like player buffs, and they show up. If you ever have a question "how much am I getting from this?" just use the combat attributes.
Re. the rule of fives: if you have five or less 3% bonuses, then each one adds an additional 3%, and ignores ED, just as you say in your original post. If you have more than 5, then each bonus after the 5th does nothing.
Now you could have five 3% bonuses, and 5 2.5% bonuses, and they stack (in this case a total of 22.5%), so that's how most folks get large bonuses from small ones. Stack up as many as you can.
is NOT based on percentages. It is based on the NAME of the bonus.
A couple illustrative examples:
Set A: Offers a 1% Endurance Recovery Buff -- listed in Combat Attributes
as "Tiny Recovery Bonus".
Set B: Offers a 1.5% End Recover Buff -- *also* listed in Combat Attributes
as "Tiny Recovery Bonus".
Even though the percentages differ, the name is the same, So any combination
of up to 5 Sets of A and B would give 5-7.5% bonus (depending on which exact
5 sets you have), but after that, adding another set (either A or B) will not
increase the Bonus at all.
On the Flip side, Set C offers a 7.5% Recharge Bonus listed as "Huge Recharge
Bonus".
A LotG Increased Recharge IO offers a 7.5% bonus listed as "Luck of the Gambler:
Recharge Speed".
In this case, even though the percentages are identical, the names differ.
You can actually have 5 of EACH (Set C AND LotG) and still receive the bonuses.
Regards,
4 -
Over time...
Also, using gleemail, and/or market slots, you can *access* a LOT of inf if you
have it and need to get at it.
If you have ~20 market slots with ~2B stored in each, along with your 2B "cash"
you're already sitting on 42 Billion on a single toon...
Regards,
4 -
A ViP character can have a maximum of 2 Billion inf on hand.
That said, you can effectively *store* inf in the market using transaction slots
to hold bids on A: Items that don't actually exist in-game (ie. L53 IOs) or
B: Bids on existing bids that are unlikely to fill (eg. 500M on a Glad Armor Proc
that normally goes for 2B)
I forget the max number of marketing slots a toon can have, but I have seen
a .jpg from one of our marketeers that had 16B stored up that way.
Finally, you can also store 999M on a single gleemail, and you have a limit of
20 gleemails, so there's another ~20B you could have available to any of your
toons.
Regards,
4 -
Quote:Sorry. You must work with complete buffoons (assuming you're in the softwareNot if they are a statistically insignificant number, and therefore have effectively zero representative value for the industry as a whole. And that number is vanishingly small. People will give lip service to quality, but would you jeopardize your job for it; your entire career for it; will you walk away rather than sacrifice it; will you replace yourself with someone better qualified to ensure it? The number of such people is exceedingly rare.
industry).
I personally know of several actual, tangible examples from at least two companies,
right off the top of my head, where quality was very much in the forefront of procedure,
review, and in some cases, enforcement.
I'm pretty certain I'm not the only programmer in the entire world that has ever
had that experience.
I find your assertion of "vanishingly small" highly suspect, especially when you
preface it just a few posts earlier with mutually exclusive and contradictory
statements.
Sorry, I'm not buying the Wild West programming standards you're implying are
the norm.
Of course, this is starting to get pretty far afield from the original post.
If you're pleased with the quality of recent releases, good for you.
I'm not, and I believe they can and should, pay more attention to the quality
that they're pushing out the door going forward.
Regards,
4 -
Quote:Exactly the point I was making...However high you think your standards are, there exist people with higher ones. Or in this case, more rigorous ones.
So, explain to me how these two statements do NOT conflict?
Quote:Originally Posted by ArcanavilleThe industry has never valued quality.Quote:However high you think your standards are, there exist people with higher ones.
the industry *does* care about quality.
If your first statement is true and the industry does not actually care about
quality, then clearly their standards are not higher.
You can't have it both ways Arcanaville.
The point I'm trying to make, is that the apparent standards exhibited here
with recent releases appear lower than mine - both as a customer, and as
a programmer.
I have no idea what point you're trying to make <shrug>.
Regards,
4 -
Quote:I have CoH on three home networked PC's, all of which are running XP (SP3)Well I tried your guide... and sometimes it even works. But I've had instances since reading and implementing your guide's suggestions, where the launcher crashes before I've even had a chance to start the game.
My rig is up to date and my drivers are current. I'm still on XP and not inclined to upgrade to 7 but I can't see that being an issue.
As for why I left the launcher running in the background: Because crashy game is crashy and so when I invariably crash during an iTrial it saved time.
with varying architectures.
I don't have any issues with the launcher on any of them.
I also make sure the launcher terminates when I run the game.
I'm starting to think there are other issues that are contributing to the trouble
you seem to be having. You may want to explore that a bit more.
GL,
4 -
Quote:Me too. All of my toons have a bio/story to explain why they're "here" (althoughAs for me: I will not play any toon that does not have a strong theme and back-story. Indeed, the first thing I do is work out the backstory, and write a full Bio entry.
Yes, I'm weird.
it's debatable how "strong" their story is - good enough for me tho).
I have a few movie homage toons (Ghostbusters, Johnny Dangerously, and even
Lord of the Rings), as well as a Starcraft and Mechwarrior homage toon.
I have an Arizona themed toon (based on Hopi Indian mythology).
I have a few aliens who got here in a couple different ways (one as a Rikti stowaway).
I even have an 11th century knight who ended up here (he thinks) due to "Foul
Sorcery"
I have a bunch that are more run-of-the-mill fits (a paid Assassin- stalker, a few
abused/deranged villains, a few in-game faction converts to hero or villainy, etc).
Deciding why a toon is in the "City of" universe is initially as fun as playing them.
Regards,
4 -
I've often thought that "Game News" would be a useful thing to repurpose
the old info kiosks for, but I wouldn't hold my breath waiting for it to happen.
Some of us old-school folks don't give a rat's patootie about all that social
media crap, but an In-Game place to find news might be helpful.
That said, I just read the forums...
Regards,
4 -
Quote:Hard Cap is what you'd probably think.Thank you for the definition of soft cap there...now I need to know what "hard cap" is...
Let's take Hit Points....
For a Blaster, the Hard Cap is 1606 - period.
Any powers that would Heal you or add to your total HP will not exceed 1606,
no matter what they are...
That is a Hard Cap.
Regards,
4 -
Quote:Well, it depends on the level.Thank you. Let me give a specific example....not for you, but for me to understand...
....and I should have specifeid "IO sets"....
Lets say I slot all 4 "Smashing Haymaker" in a melee power. As it happens, all four contain damage bonus. Then I slot an additional damage SO.
Your saying that ED wont ignore the extra damage SO unless it exceeds a percentage? Is this what they refer to as a "soft cap"?
For instance with L25 (I happen to know off the top of my head), Acc/Dmg,
you have a 20% damage component in that IO.
I don't know the rest of the set pieces (here at work), so, if you also took an
L25 Bruising Blow Acc/Dmg, and a Pulverising Fisticuffs Acc/Dmg, you'd have
3 set pieces that give you 60% Acc + 60% Dmg.
If you add a straight Dmg SO (33%) to that, you'd have 93%, and off the top of
my head, I think you'd get some slight ED effects (you're right at the edge with
that example).
If those were higher level set pieces, you'd definitely be in ED territory.
No, that's not a "soft cap". Soft Cap is a very specific term that basically means
adding more to a value won't add effectiveness. It commonly applies to Defense
where there is always a 5% chance to be hit, so adding more defense at that
point won't help.
Accuracy is the same way - Once you are 95% to-hit a mob, more accuracy
won't benefit you. You are allowed to add more accuracy, but it simply won't
give you a better number than 95%, no matter how much you add...
Regards,
4
PS> One other fine point to recall about ED - it doesn't ignore the benefit, it just harshly
penalizes/degrades amounts above the ED threshold... Adding a 4th and 5th SO
*would* raise the damage, but only by a miniscule amount (far less than the SO/IO
or slot is worth) -
I can also confirm having character(s) that are still in the original Outbreak.
Regards,
4 -
Quote:In short, yes, if they're common IO's - If they're duals, or triples, maybe not.If I slot 3 IO's that contain damage, and then slot an SO Damage....am I in ED territory?
It is not 3 of a type that matters, but rather total enhancement percentage.
I'm sure someone will provide the appropriate P-Wiki link, but for Schedule A
enhancements (Acc, Dmg, etc) ED starts kicking in around 90% or so, and for
Schedule B, it's around 50% or so (loosely speaking).
So, to your example, if they're 3 common IOs (L25 or better) + an SO, definitely yes.
If they're L25 Duals (20% Dmg component), + an SO (3X20 = 60 + 33), probably yes.
If they're L25 Triples (17%? Dmg), + an SO (3x17 = 51 + 33), probably not.
Regards,
4 -
Quote:I agree. There were times when things were much less complicated, but "better",There are a lot of people who seem to think there was a golden age of commercial programming. There wasn't.
no, not really, depending on your definitions of "better" and "Golden Age", I guess.
This, I disagree with as a blanket statement.
To be sure, different segments of the software industry prioritize quality differently, but
to say it was never valued at all? No.
Quality has always been a tradeoff between delivery and expense, and sometimes,
it gets treated like the ugly redheaded stepchild of the trio in some segments,
but completely omitted from the equation?
Even the CoH devs haven't descended that far.
Quote:There are fewer programmers and software engineers that are a) more than minimally competent, b) willing to draw a line in the sand to hold the line on quality, and c) still around.
in the end-product, and not in a good way.
I think we're seeing that more frequently here also, hence my initial post.
Quote:We expect - demand, even - that certain professions have a code of ethics that includes minimum levels of quality We expect doctors, pilots, engineers, to say "either you let me do this correctly, or you fire me and find someone else because I won't do it incorrectly." When they don't, we feel justified in basically crucifying them. Even when lives are not at stake, we still believe accountants are supposed to do the books right or not at all.
That's basically what I'm calling for here -- "Raise the Bar" ... a bit.
Quote:We have *never* as a profession even *pretended* that we aspired to that level of basic competency.
And it shows.
What I think is more common, is that the *consumer* doesn't seem to hold software
companies to the same standard they'd hold an accountant, doctor, etc. to,
except in certain areas (banking, being an obvious case), and if the customer
isn't concerned about it, the developer is less concerned as well.
That said, I for one, am concerned about it.
I don't expect 0 defect software here, but I'd like to see the quality standard
raised above the apparent minimum I've been seeing recently.
Regards,
4 -
-
My PB Guide back in I4 was aimed at Nova/Dwarf.
It's definitely viable, and one sideline benefit is that you minimize the slot crunch.
Most of the powers that help forms don't need very many slots compared to
builds that utilize the human attacks.
With IO's / sets, you can make those forms pretty effective.
The wrinkle these days, is the recent changes and perma Light Form really devalued
the forms in many player's minds, and that is leading to more and more human-centric
builds these days.
That said, Dwarf/Nova is still a viable choice, and it's even more effective these
days than it was when I wrote that I4 Guide.
Regards,
4 -
An amusing idea - I'm all for the 88's annual Solstice gathering.
I don't particularly care whether we re-take first place again or not, but I'm
sure Granny would willingly contribute a billion or two for eggnog and some additional
heat in the base...
Cheers,
4 -
Quote:You raise some good points. I stand by the position that it is a reasonable comparisonAs a professional in the software development of financial software myself, I can see where the OP is coming from, but there is more to it than code. I happen work in a building that also has a big-name game making company in it. I get to talk to both kinds of developers and to the people that run the companies.
First, the financial code we create is FAR more 'focused', making it far easier to debug and maintain, IMO. The fact that many of the same technologies used in highly mission critical software, like programming languages and databases, are used to create CoH as well, does not mean they are used in the same way. In fact, many of the underlying technologies were developed to create financial software and have been shoe-horned into creating games. Often, just as it does with financial software, the bugs lie not in the code written by the product developer, but somewhere in the underlying technology.
Second, and more importantly, highly mission critical code has an enormous amount of money and resources thrown into the QA phases as compared to games, where the development resources are placed elsewhere, like art and storytelling, etc. The amount of money spent on QA in the highly critical software, IME, often outweighs by far the amount spent on the actual development.
Games are art, where highly critical software is engineering.
There are two completely different mindsets at work between the two types of software, regardless of the fact they happen to use the same tools, like a welder that builds cars vs one that builds replicas of Transformers.
I am NOT saying this game developers should not unit test like everyone else. I am not saying that QA should not be done. But QA is not where the game industry spends the majority of it's money. The margins they have are small enough as it is, games would not get made if held to the same standards as the PCI complaint software of the modern financial world, or they would cost a whole lot more.
Comparing game code development to highly critical code development is not a reasonable comparison, for a number of reasons; to entertain is art, to track how much money I have in the bank is something else entirely.
IMO, it's like telling an artist his work has to be held to the same scrutiny as a bridge builder.
as we are discussing code and end-user application systems - we're not debating
apples and oranges.
In fact, the comparison is highlighting some key (and valid imho) differences
between various disciplines, largely in terms of funding, focus and prioritization.
Your point about a higher priority for the artwork aspects is a good one, although
I'll point out that there is plenty of room for quality improvement there also -
given clipping issues, pieces that don't fit, pre-tinting (a "feature" argument),
and various changed/missing items.
I can accept, and have essentially said, I don't expect QA to be as high here as
I would in other industry segments I've mentioned, but I definitely think it needs
to be raised higher than where it appears to be currently.
Good Points though - I appreciate you raising them.
Quote:Originally Posted by "ClawsandEffectAnd the part YOU are glossing over is the fact (and it IS a fact, the devs have confirmed as much in the past) that quite frequently, the cause of the bug has no apparent relation to what the bug is affecting.
It is entirely possible, and in fact likely, that these bugs aren't being caught at the programmer's desk because they are being caused by something that programmer had nothing to do with. The programmer's code could be working perfectly, and another code could be working perfectly, but when those two pieces of code start interacting it could have an unexpected effect.
It could be something like: Your map will break if you have ever teamed with someone in a different phase than you. In that case, the map code could be working correctly, and the phasing code could be working correctly, but the 2 codes break things when combined. Unless one person is working on phasing technology and the UI simultaneously, it is unlikely that connection will be made immediately, because the code appears to be correct upon examination.
Your example of the missing driver's side mirror is a poor one. In that case it is painfully obvious what the problem is, and the solution is just as obvious.
In the case of bug fixes in this game, it's more like the car is missing exactly one bolt and you have to figure out which bolt is missing before you can replace it.
And the bolt might not be missing, it might just be broken and still in place. Which means you'd have to go through the entire car and test each bolt individually until you find the broken one.
I don't think the game's programmers are incompetent in the slightest. I just think they have a mountain of unpredictable code they have to deal with that can do weird things when new code is added to it.
esoteric voodoo that is unfathomable to the average mortal.
It isn't.
It can be complex, it does require meticulous attention to detail, and in some
cases, interactions between various subsystems can cause erratic, and
difficult to isolate/fix results.
But by and large, it follows the 80/20 rule like a lot of things - 80% of the issues
are usually simple "Duh" mistakes that are often pretty easy to find and fix,
and 20% (or less) are the weird things where programmers really earn their pay.
I'm not complaining in this thread about that 20%.
I AM saying that lately, it appears to me that much more of that 80% is ending
up in the live, production game, and I think that some steps should be taken
to address that (ie. slow down a bit, test code, act on beta feedback sooner,
and prioritize quality a bit more than they seem to).
Now, if you wish to think that this stuff is all miraculous and incomprehensible
magic, fine by me. I don't know what your programming qualifications are, but I
do know what mine are - and based on those, I don't think we're seeing a magical,
issue here. I think it is much more an issue of attention to detail and elevating the
quality standards a bit.
Regards,
4 -
Quote:hehehe... not sure if that is a good thing or not, but I got one of the originalProbably. I seem to recall a study indicating that the average player age in this game was 28.
I, on the other hand, got my first computer about 35 years ago.... According to Wikipedia, the TRS-80 Model 1 came out in 1977, so 34 years. So while I wasn't employed back then, you're not the only long-term programmer.
4K Trash 80's the first week they came out in my town...
I had a lot of fun playing with Z80 assembler on it and had a full printout of
the ROM and all its Basic hooks (custom commands can be fun).
I still have it in storage (Hmmm... wonder if it still works)
Regards,
4 -
Quote:First, I did not say the highlighted piece - there are programmers of varyingI have noticed that this is true to wildly different degrees depending on the industry we're talking about. I don't think it is accurate to make the blanket assertion that all (competent) programmers in all application domains are going to be equally rigorous or effective at debugging and testing. I can't speak to what is "typical" in the video game arena, but in the two industries I've worked in as a software engineer, the attitudes towards testing and debugging have been almost diametrically opposed.
The programmer culture has, in my 30-year experience, shifted significantly over the decades. Having the Master of Debugging badge seems to be something few programmers (that I've met anyway) aspire to anymore. Unit Testing is an alien concept to most. You describe these skills and knowledge sets as something any and all competent programmers do possess, but if so, the world is simply not composed of as many competent programmers as you imagine.
skill and experience without a doubt.
What I did say is that if you put C or .NET or SQL on your resume I would *expect*
you to be able to take a piece of undocumented code in those languages and
A> Tell me what it does B> Tell me how you would change it if I wanted to
add some arbitrary feature. That IS competence, plain and simple. I'd further expect
you to be able to test it to verify that it works properly and debug and fix it if
it doesn't.
If you could not do that, those languages should NOT be on your resume.
(Let's not get into the sideline threadjack of folks who falsify their credentials).
In the same regard, I'd expect a competent plumber to be able to find and
fix a leak in my household plumbing or change out a faucet or whatever other
normal things come with the job description, and a competent electrician to
wire up a light switch or find out why a particular circuit breaker keeps popping
without burning my house down or creating a man-made lake in it.
Writing, testing and fixing code IS the job description of a competent programmer.
On another sidenote, I'll add and agree that there are a LOT fewer programmers
who actually understand wth goes on inside code these days (Thank You .NET
et al, where a lot of the inner workings are increasingly inaccessible blackbox
mysteries they don't want a programmer to see). Sadly, the field is becoming
more of a lego block process, but that's also a different discussion altogether.
Again though, that leads to different sorts of bugs (typically) than we're seeing
with non-anchorable UI elements, option switches that don't work and the like.
Regards,
4 -
Quote:You are correct - it isn't a car... That is the only viable point in the post.Fourspeed - This isn't a car. It does not have /mechanical/ reasons for failures. Which are easier to findthan why the maps or UI busted when they were not touched.
It's not financial or safety software. It's a seven year old game, with more years than that on it's code base, with many previous programmers who are no longer with the game who didn't document their work - it's not so much an issue with the current coders as the previous ones.
Be it game, flight control, or banking software, it is ALL code. From a conceptual
viewpoint many of the techniques are similar (processing a file, displaying to,
or querying from a device, testing conditionals, variable storage etc.).
In some cases, the actual code can be nearly identical. C for instance is an idustry
standard in a lot of software, including commercial aircraft (non-military) systems.
SQL is not unique to games.
Logical operations with these things are pretty standardized assuming
use of common best practices - A SQL Select is probably a near perfect example.
Age of software - non issue. Many of the computer processes that run in the
financial sector are decades old -- I've worked on several... Why so old?
Because they're well understood, safe and stable, and when millions of dollars
(or people's lives) are on the line, *new* things are far riskier in many applications.
A LOT of code is undocumented, and yes, it IS a pita (sometimes) to debug,
maintain, and enhance. It is no surprise in the software industry that the highest
cost of software is not development - it's maintenance (and people costs to
do said maintenance).
That said, CODE is what we programmers DO.
Undocumented code is NOT a showstopper - it is an annoying irritant.
Any competent programmer meeting the credentials on their resume can take
a piece of undocumented code (in a language they are proficient with) and
A> determine what it does and B> maintain and/or enhance it.
While true that interactions can have bizarre effects (sometimes), you are incorrect
when you say things don't fail for simple reasons. There are always reasons
(the vast majority of which are quite simple and straightforward) and clues to
the cause. Once again, seeing them, tracking them down and fixing them
is a large part of what programmers get paid to do.
Sure, it's not usually because Bolt A broke, but a piece of code that overwrote
a key variable another piece of code expected to use, or a misnamed variable,
or using the wrong variable, are most definitely simple, detectable, and actionable
reasons.
Case in point? The upside down Nemmie Staff animations were due (iirc) to
an improper table value - pretty darn simple... Should (imho) have never gotten
into the live build.
Assuming competent people given appropriate tools and time to do their job,
most of those things are really not all that hard to find, and in places with sensible
standards, many are often avoided in the first place, or caught where they should
be - in proper Unit Testing.
In short, the points you list are simply not viable or acceptable excuses to justify
untested, or substandard quality software in a production environment.
Again, I'm not saying bug free (some things ARE challenging), but not the types
of bugs we've been seeing recently...
I'm sorry, that argument simply doesn't fly wtih me.
Regards,
4 -
Quote:Only on the internet...Serious question: Has the English language been decimated?
Quote:Originally Posted by Primary_UnitI'm still waiting for "autopsy" to be banned from our paper for
(supposedly) not meaning what everybody thinks it means. I roll my eyes a lot.
Cheers,
4 -
Quote:So, your position is that the game's programmers are not competent enoughYou said it yourself: It's not game breaking.
How long do you delay the release of an issue while you search for the cause of something that isn't game breaking? A month? 3 months? A year? As long as necessary, even if it means the issue is never released?
As a programmer, can you say with any certainty that the borked code that's causing that bug is even IN the file the map is in? How do you know they haven't already looked everywhere and haven't figured out what's doing it yet?
to find this bug? Frankly, I'd disagree with that.
Let me flip the question around, if your new car was missing the driver's side
mirror when you got it, how soon would you reasonably expect the dealership
to fix that? Weeks, Months, Never?
In answer to your implication, Yes, I'd prefer the devs to slow the pace down
somewhat to give us a better, more polished, and professional product.
If that timeframe is months, or as you put it never, then I'd begin to question
the competence of their staff or management's prioritization of resource provision
and allocation.
The part you are glossing over completely is that these types of bugs should
not even be IN the build - many of these should have been caught at the programmer's
desk unless a couple things are happening: 1> The coder isn't also the tester
of their own work. 2> The work schedules are SO ridiculous (ie. sweat shop) that
reasonable quality is impossible or 3> They simply don't give a rat's patootie
about what they're pushing out the door.
ALL of those practices are suboptimal if not outright bad.
If I had to guess, I'd lean more towards 2, but that still doesn't make it acceptable
to the end-user.
At least, not to *this* end-user.
Regards,
4 -
Some very interesting commentary in here - I appreciate all the responses.
There are a couple points that I want to speak to, and I'm trying to be as non-acerbic
as possible although this issue bothers me a lot on both a customer level and
on a professional level.
I have been an applications programmer (primarily in the corporate financial
sector) with companies (who shall remain unnamed, but would be definitely recognized)
for ~34 years now (longer, I'd wager than many of our posters have been alive).
I'm not saying that to brag, but merely to point out that I'm quite familiar with
software, design/development paradigms, and large company software production.
I think the thing that is bothering me most lately is NOT that there are bugs,
that is truly inevitable in any sufficiently complex application, which CoH definitely
qualifies as.
It is rather, the kinds of bugs we're seeing lately.
The kinds of bugs lately, have been very simple, very obvious, and extremely
simple to detect had their been ANY testing at all.
The Fog of War is about as obvious as it gets. There is no way to NOT see
that one in the first 5 minutes of running a character, any character.
To be sure, it is not game-breaking, but the point I'm making is that it should
never have got out of Unit Testing.
Let's try the age-old car analogy.
There have been many car recalls over the years for some rather dangerous
issues - but how many new cars come off the lot with, say non functional headlamps,
or missing sections of paint, or missing mirrors, or glove boxes, doors and trunks
that don't open or close properly?
Can you drive the car with those problems? Probably.
Would you BUY a new car with those problems? I wouldn't.
If X Motors invited you to test drive the latest model (before it was available
to the public) and you saw these things, would you reasonably expect them
to be fixed before being sold to the public?
This is the caliber of "quality" we're seeing lately, and there's no other way
for me to categorize it as anything other than substandard and shoddy.
It reflects an attitude that is uncaring about either the quality of the product,
or the customer that is using and paying for it.
Getting back to software.
What would your opinion be if these issues were occurring with an ATM, or your
checking account?
What if this software was written for aircraft flight control and management?
I'm on record (in prior post) as saying I'm glad these devs work in the gaming
and entertainment industry, because quite frankly, if the lack of testing and
quality I see here was carried over to other industries, they'd very possibly
cost their companies millions in fines/penalties, or in the aircraft case, wind up
killing somebody.
These bugs aren't "critical", but they're simple, obvious, and should never have
left the coder's desk in the first place, let alone ended up in a live release.
On top of it, they certainly raise the question in my mind regarding what worse
bugs are lurking in the software, given that they can't be bothered to fix the
simple and obvious ones. Not exactly confidence inspiring in my book.
As a paying customer, I am calling for a higher quality product.
As a long-time programmer, I question their procedures.
As a player, I'm grateful to be invited to a beta, and I try to contribute useful
information, but I also have the expectation that it matters, and raised issues
will be addressed in something resembling a timely matter.
Once again, thanks all for your commentary. Obviously, it's a topic I feel strongly
about, and I'm very interested to see how the community views it as well.
Regards,
4
PS> I like cute puppies too!