FourSpeed

Legend
  • Posts

    1554
  • Joined

  1. 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
  2. Quote:
    Originally Posted by jwbullfrog View Post
    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.
    Simple. Via Gleemail.

    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
  3. Quote:
    Originally Posted by gameboy1234 View Post
    You 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.
    As a quick caveat/wrinkle to the rule of 5's. Unlike ED penalties, the Rule of 5
    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
  4. Quote:
    Originally Posted by kchammy View Post
    Then how do people afford to buy purple sets?
    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
  5. 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
  6. Quote:
    Originally Posted by Arcanaville View Post
    Not 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.
    Sorry. You must work with complete buffoons (assuming you're in the software
    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
  7. Quote:
    Originally Posted by Arcanaville View Post
    However high you think your standards are, there exist people with higher ones. Or in this case, more rigorous ones.
    Exactly the point I was making...

    So, explain to me how these two statements do NOT conflict?

    Quote:
    Originally Posted by Arcanaville
    The industry has never valued quality.
    Quote:
    Originally Posted by Arcanaville View Post
    However high you think your standards are, there exist people with higher ones.
    If some folks have higher standards, and they're in the industry, then clearly
    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
  8. Quote:
    Originally Posted by Scarlet Shocker View Post
    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.
    I have CoH on three home networked PC's, all of which are running XP (SP3)
    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
  9. Quote:
    Originally Posted by mauk2 View Post
    As 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.
    Me too. All of my toons have a bio/story to explain why they're "here" (although
    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
  10. 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
  11. Quote:
    Originally Posted by kchammy View Post
    Thank you for the definition of soft cap there...now I need to know what "hard cap" is...
    Hard Cap is what you'd probably think.

    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
  12. Quote:
    Originally Posted by kchammy View Post
    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"?
    Well, it depends on the level.

    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)
  13. I can also confirm having character(s) that are still in the original Outbreak.


    Regards,
    4
  14. Quote:
    Originally Posted by kchammy View Post
    If I slot 3 IO's that contain damage, and then slot an SO Damage....am I in ED territory?
    In short, yes, if they're common IO's - If they're duals, or triples, maybe not.

    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
  15. Quote:
    Originally Posted by Arcanaville View Post
    There are a lot of people who seem to think there was a golden age of commercial programming. There wasn't.
    I agree. There were times when things were much less complicated, but "better",
    no, not really, depending on your definitions of "better" and "Golden Age", I guess.

    Quote:
    Originally Posted by Arcanaville View Post
    The industry has never valued quality.
    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:
    Originally Posted by Arcanaville View Post
    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.
    Agreed, particularly with point b. The end result of *that*, definitely shows
    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:
    Originally Posted by Arcanaville View Post
    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.
    We do, and rightfully so imho.

    That's basically what I'm calling for here -- "Raise the Bar" ... a bit.

    Quote:
    Originally Posted by Arcanaville View Post
    We have *never* as a profession even *pretended* that we aspired to that level of basic competency.

    And it shows.
    Again, I disagree somewhat, as outlined above.

    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
  16. Quote:
    Originally Posted by DarkGob View Post
    Still waiting for this "test" to be deleted.
    It'll be handled in an upcoming patch... ("well, that's what I heard")


    4
  17. 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
  18. 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
  19. Quote:
    Originally Posted by MajorPrankster View Post
    As 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.
    You raise some good points. I stand by the position that it is a reasonable comparison
    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 "ClawsandEffect
    And 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.
    I get the sense that you seem to think that programming is this semi-magical,
    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
  20. Quote:
    Originally Posted by Ironblade View Post
    Probably. 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.
    hehehe... not sure if that is a good thing or not, but I got one of the original
    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
  21. Quote:
    Originally Posted by Wing_Leader View Post
    I 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.
    First, I did not say the highlighted piece - there are programmers of varying
    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
  22. Quote:
    Originally Posted by Rajani Isa View 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.
    You are correct - it isn't a car... That is the only viable point in the post.


    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
  23. Quote:
    Originally Posted by Electric-Knight View Post
    Serious question: Has the English language been decimated?
    Only on the internet...

    Quote:
    Originally Posted by Primary_Unit
    I'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.
    Are you trying to tell me that "autopsy" doesn't mean "psychic car" ??? Curses!!!


    Cheers,
    4
  24. Quote:
    Originally Posted by ClawsandEffect View Post
    You 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?
    So, your position is that the game's programmers are not competent enough
    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
  25. 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!