Real Numbers: When they're wrong

No, that's just poor programming. If I program the computer to add 1 + 2 when I really want it to tell me what pi is, it telling me the answer is 3 isn't a bug. If you aren't clear on what you want, the computer can't read your mind and return what you actually wanted, unless you actually tell it to return what you actually wanted. The computer returns expected results provided you're clear on what you actually asked it. In this case, it's literally returning the accuracy of the power. The power itself has an accuracy rating that is never used (as the power itself autohits to "summon something"). You just aren't asking the right question (the right question being, "what is the accuracy of whatever gets summoned").

It makes perfect sense to me as a programmer. Though these are the sorts of demons in the program that can drive you crazy. Technically the information returned is exactly what you asked for, but not what you thought you asked for. Probably without knowing the info or being able to see the table, you could go nuts trying to figure out why it's telling you the power's accuracy is 200%. I've had to tangle with unexpected results like that before. The answer is usually something simple and stupid (such as in this example).

Also for some reason now I'm thinking of Deep Thought. All we know is the answer is 42.

Originally Posted by PRAF68_EU Dispari has more than enough credability, and certainly doesn't need to borrow any from you.

If I buy that program off you and there is a button labelled "pi" that returns the value 3, that is a bug. If you argue that places where the code is doing the wrong thing aren't bugs then there is no point reporting anything because the only 'real' bugs are hardware problems outside the ability of the developers to correct.

The code is literally returning the accuracy of the power, which is what it was told to do. What you EXPECT it to return is the accuracy of a pet's powers. The real numbers returns the accuracy of the power just like it's supposed to do. The problem is not a bug, but in the expectation of the user, who thinks the code should just "know" to go return the accuracy of the actual pet (even if it has multiple powers, which would be an issue). Note that it COULD do that if it was explicitly programmed to do so, but that doesn't make it a "bug." Just mis-matched expectations and incomplete programming.

"Missing a feature" isn't a bug. If you buy a tax software and it doesn't have the feature to convert USD to AUS, that's not a bug, it's just something that never got programmed in. If THAT qualified as a bug, we'd have an INFINITE supply of bugs to report, as things like "there are no back options like backpacks" would be a bug.

The function does its task, but you're expecting it to go a step further and do something more complex than it was designed to do. That would be adding a feature, not fixing a bug.

It's an issue of expectations. The feature is designed to report the accuracy of a power, which is exactly what it does. However, you expect it to do more than advertised, and report the accuracy of the pet. To you that is logical (and it makes sense), but that's not what the computer was told to do -- however useless its actual returned information may be.

Originally Posted by PRAF68_EU Dispari has more than enough credability, and certainly doesn't need to borrow any from you.

Not if you're an engineer. In that case it is in fact returning the exact value of pi with which all engineering feats are performed.

Pi is exactly 3!!

They ALL float down here. When you're down here with us, you'll float too!

@Starflier

Computers are stupid. They always do exactly what you tell them to do. Erroneous output is still a bug, no matter how the erroneous output was achieved.

Debuff HOs enhancing buff powers is exactly the way HOs were coded. But it's still a bug. In beta testing, Touch of Lady Grey proc firing for billions of damage was exactly the way it was coded. That's still a bug. Players getting stuck inside geometry is exactly the way the game's physics is coded. It's still a bug. A Warshade putting all 67 slots into one power and one-shotting Hamidon was exactly the way the game was coded. It's still a bug.

Of course, none of my examples are things that were/are "Working As Intended". But the game's Real Numbers initiative is intended to show players exactly how their powers work, and telling them that ?Rain of Fire has a 2.00 accuracy is false, and is therefore a bug.

In all cases of this issue the power itself deals no damage and it is the pet that does so; if the damage dealt by the pet is part of the power so is the accuracy with which that damage is applied.

Except that we're talking about tax software that doesn't apply tax to any expenditures done after the 28th of a month. For most of the time the output is correct and it is doing exactly what it is coded to do, it still doesn't perform the task for which it is intended, so it is bugged.

What? When? How?

For tough, sure. but Temp invul for Defenders?
also, I've checked it. It's reading that way in both the PvE and PvP descriptions.

Originally Posted by Samuel_Tow City of Heroes is a game about freedom of expression and variety of experiences far more so than it is about representing any one theme, topic or genre.

It's not erroneous output though. In fact it's so accurate that most people don't understand why it's returning what it does. Real numbers tell you the accuracy of the power. Which it does, exactly. I'm not sure how "user expected function to return something other than what it's supposed to return" could be a bug. It just boils down to, we aren't asking the right question.

I don't believe it's a bug, because it literally does what it's told to do, exactly. It tells you the accuracy of the power -- it's just that in the case of powers that summon pets, the accuracy of the power itself is totally irrelevant. In fact if it did take the extra steps to find the accuracy of the powers of what it's summoning there would still be issues returning a "correct" answer.

Here's a thought exercise. What do you consider the "correct answer" in any case? Call Bruiser is listed as having an accuracy of 1.00x. Is this correct output? Do you believe that's working as intended and returning correct information, a bug, or incomplete programming?

Originally Posted by PRAF68_EU Dispari has more than enough credability, and certainly doesn't need to borrow any from you.

That's what I get from City of Data anyways. Res vs S/L in PvE; Res vs All in PvP.

They ALL float down here. When you're down here with us, you'll float too!

@Starflier

In Call Bruiser like all full pet powers individual powers used by the pet are included in an expandable list which states the accuracy for each power, usually 1.00x but 0.60x in the case of Hand Clap and 1.20x for Knockout Blow. The obvious 'correct answer' for pseudopet powers is to either fully hide from the player that these powers use pets by making the accuracy number be that of the power the pet uses (the same as the list of effects is), or to not hide how the power functions by letting the power state that it summons a pet and list the power(s) that pet uses with full information. The current half-way-house implementation fails to provide the end user with the information that is required.

One is working as designed. The other was not. Some day, they might get around to changing the design, because the design is not actually doing everything they way they wanted it to, but it's not a bug.

There does seem to be a significant number of cases where a power does nothing except summon a pseudo-pet, where listing the pseudo-pet's powers down below as they are for "actual" pets would provide useful info with a hopefully minimal programming investment. Having a "Rain of Arrows" displayed down below, expandable to show the "RainofArrows" power, and so on would be arguably better than nothing.

Looking at it in another way, if the game *knows* that the number in the Accuracy column is never used, wouldn't displaying "Special" or some such be better than an unhelpful number? Or both; "2.00 (Special)" in a browner shade of yellow than usual would present the most information for instance. Are there any cases where a summons actually does need to make a to-hit check for the summons itself? (And what would it be checking against if so?)

Probably, but there are a lot of special cases like this that each require special code to handle in real numbers: this just happens to be one of those not currently handled.

What matters for Rain of Arrows is that its a location power: it doesn't actually have a target, so obviously accuracy is meaningless. Is there a summons power that actually makes a tohit check? Oooh, that sounds like a great trivia question. Off the top of my head, among player powers I can think of... eight, not including archetype variants. Three in one set, two in another set, one in a related set, one in another set, and one that I bet most players don't even realize summons a pet at all.

If anyone wants to test their game knowledge, I'll post the ones I'm thinking of tonight unless someone guesses them all.

Hmm.

Pretty sure three in one set is Transfusion, Siphon Power, and Transference in Kinetics.

Two is probably Jolting Chain and Synaptic Overload in Electric Control, with Chain Induction in Electric Melee being the one in the related set.

Twilight Grasp in Dark Miasma.

I'm stumped on the mystery pet, unless it was TG and I'm missing another more obvious one.

Lightning Rod is a pet, it doesn't break a stalker's hide. That would imply shield charge is a pet too.

But I didn't think Chain Induction was a pet, I thought it was a power that was given to the enemy that was hit with it.

Wow, that's pretty good. That's seven of the eight I was thinking of.

The eighth one was one I thought would be difficult. Blind. Few people probably even know or remember that Blind has a sleep component, much less that it uses a pseudo-pet to generate it.

Warning: Incoming wall of text.

As a member of a team that develops applications for a very broad user community, I disagree very strongly with that koan.

A key difference in what you may be thinking there and what I am thinking of is this: I think this is stuff for which there is no end-user requirement that it work this way. Broadly speaking in regards to software (and not games in specific) if the end users of software don't tell the developers exactly how they think something should work, thus leaving the implementation details to the designers and developers, and then dislike how the end product works when it's working both as specified by the users and as intended by the developers, then that is not a bug. Instead, it's a failure to produce good requirements. That may seem like a really ridiculous distinction to make, but I promise you there's a good reason for it.

Allowing gaps in requirement to be classified as bugs allows end users to dictate that "common sense" on the part of designers and developers should fill in the gaps in software specification. "You should have known this is what we wanted" isn't a valid software requirement - it's far too subjective. Among other things, users given such leverage will often classify anything they didn't adequately specify (and which the designers or developers didn't realize was poorly specified) as a defect on the part of the developers or designers, even though they never actually said they wanted it to work a given way. This leads to scope creep, as defect reports are being used to change (or insert) requirements. Sometimes allowing the scope creep really is the right thing to do, because sometimes the failure in requirements is so severe the software would not be fit for purpose, but that's an extreme scenario, and one the requirements gathering process should strive hard to avoid.

Now, from our perspective as players, we are not actually in the position to provide our input to a game's developers as user requirements. If we're lucky we get to provide feedback during betas, but any actual "user" requirements are developed internally by some part of the game's design team. If we players don't think the resulting software does what we think it should, either in a beta or on live servers, the best we can do is question whether something is working as the devs intended, and if it is we can make a request for a requirements change.

Since we players are external to the whole process, including most of the requirements gathering, I can see where you might want to classify seemingly common-sense failures in the game makers' requirements gathering as "bugs" too, but I still wouldn't agree with even that. I still feel that something like that is a request for change, not a bug fix. It may just be a request for a very sensible change. I do think this discussion about Real Numbers and power accuracy is a good example of that. As a developer, though, I do take a pretty uptight stance on what constitutes a bug fix versus a change request. I understand that end users often do not care about that distinction, but the two often have very different prioritization paths in a development organization, so identifying which category a given issue belongs in is very important to them.

Edit: Specific to the matter at hand, Real Numbers is a retrofit onto a system where we actually were never intended to see the numbers in question. Based on things Statesman and probably some other original devs posted, that we not be shown the numbers was actually probably a software requirement. Based on that, the developers probably created a system that did not care about what the users would see if shown the numbers, because the users were never supposed to see the numbers. Once that requirement about not showing the numbers changed, it was probably too late - they couldn't reasonably rework how the system was built internally. They also probably had limited time for handling display of special case powers, like pseudo-pet attacks. As a result, we probably got something that met a limited requirement, and so it displays most things right but a few things confusingly at best. I wouldn't be surprised if there's not a post-it-note or whiteboard somewhere with "improve real numbers display" as a to-do on it. That still doesn't mean what it's doing now is a bug!

I find myself pretty torn on this one..
I don't have any trouble with the principle of distinguishing between a defect report and a change request, but when you DO have a system whose requirements were not completely delineated, or whose requirements have changed over time without the application being refactored, the difference between a defect and a change request gets VERY fuzzy.

That's really the core issue here; City of Heroes has had its requirements change both internally and externally over the years, both in explicit and in less explicit fashions. Sometimes identifying where the development correctly met old requirements that are no longer in force is itself identifying defects. You've found bugs not in code, but in the logic leading to the code being implemented the way it was.

Originally Posted by Arcanaville Softcapping an Invuln is fantastic. Softcapping a Willpower is amazing. Softcapping SR is kissing your sister.

fixt