Notes on new team difficulty settings

I suspect that, since many of us noticed lower rates. The build may have simply led to the unknown value of the unititialized variable being different.

BTW, I appreciate the open posts from devs about some of the i16 bugs. It's a lot more satisfying to hear "uninitialized variable" than some mysterious obfuscation like you get at some places.

"Locally" in this context typically means "pushed onto the stack". It can mean a section of heap memory devoted to the routine, but in general it means it disappears when it is no longer needed.

Recovered memory is then reused for something else, which is why reinitialization, or the lack thereof, can be a problem. You get whatever was stored the last time you entered the code, or even a totally different section of code altogether.

That is correct

This is most definitely in the server code.

A "local variable" is a variable declared inside a function, as opposed to global variables that can be accessed by all functions (assuming this is written in C/C++).

By default, local variables are not initialized to anything: they have whatever values were in the memory assigned to them before the function was called. Local variables are "on the stack."

That means that previous functions that were called set the value of the variable's memory to some value. If the sequence of function calls changed, or additional local variables were added to some of the functions previously called, then the value that the uninitialized variable has now could very well be different from what it used to have. It may have always had the same value in the past, due to some fortunate accident, and now it essentially has a random value.

I actually nailed the cause of this, but can't really claim credit because I listed several other possible causes as well:

Both very good points. I would suspect that this has been a problem for some players/characters since i9 first came out, with greater and lesser effects depending on what else was happening along the way. For whatever reason, the current version happened to cause the effect to be wider than it had been in the past.

As far as the cause of the behavior, I absolutely agree. I absolutely love that the Dev team here is comfortable enough in the overall product that they're willing to be this forthcoming, ranging from Synapse saying that they were looking at things still to him stating they'd found something but he wanted Pohsyb to explain it, all the way to the exact nature of the bug from Pohsyb. I may still have my concerns about the "perception issue" description, but it's quite obvious that even having said that, Synapse and crew kept digging in to things to be sure they were dealing with it properly.

Well done, Devs. Especially Synapse and Pohsyb.

That's what I figured, thanks much for clarifying it to be certain.

Back in my heavy CounterStrike days, I could "feel" when badguys would be waiting for me around a blind corner. My friends called me crazy, my enemies called me a cheat.

As it turns out, my brain picked up on some very subtle clues. My cruddy video card would drop a few Frames Per Second when confronted with the opposing forces, and my Pavlovian response was always "DANGER!". I can't tell you how long it took to figure that out, but it definitely took help from some open-minded people. Upgrading that machine gave me mixed emotions...no more sixth sense.

You get the right information, move it in it's correct place, and even the strangest theories have some validity.

The odds are very small that your number of drops on each character compared to the next will be the same even if your kill counts are similar. We are talking random numbers here. If they were the same, I'd say there was something wrong with the code. Keep playing and you'll see the numbers get closer together.

In my estimates there are 5 TFs/SFs that require fixes:
Hess
KHTF
MoBSF
STF
RSF

Mis spell, not mi spell.
Mis spell, not mi spell.
Mis spell, not mi spell.

Now you'll never misspell it again.

Regular BSF needs the MM power to work, its not just the Masters version

So does that mean this bug could have (plausibly) been affecting some characters, (at least a rare few) for quite some time now?

Like, I always felt there were a couple of my (fairly numerous) alts - that almost never got anything but common recipes - and sometimes not even very many of those...

As far as the semi-recent "change" in the code that might have caused this - I'm gonna guess it was something related to adding in the chance for a Pool C/D Drop from Bosses.

I'm no code-monkey... But, that seems like a recent enough "add" to the drop code to be a plausible cause, that and the discussion thread about them where some people reported they've never gotten any of them "yet"...

Which at the time, would've seemed to have been long enough for people to have gotten at least as many of these as they did Purples or PvP recipes.
That and the repeated questions about "What is the Drop rate on these?" =(Pool C/D recipes from Boss kills) supposed to be - vs. - what people were perceiving it to be.

IDK, who all remembers the main thread on that, but it sounds pretty familiar to this one, no? *shrug*

Originally Posted by Arcanaville City of Heroes didn't fail, City of Heroes was killed. If a 747 dropped on your house, you'd say you were killed, not you failed to find a safer dwelling.

With uninitilized variable it can be ANYTHING, any change in code...

Delicious irony is delicious. Your spelling and grammar enforcement badge has been revoked pending review of how and why it was issued in the first place

Why think that, when no one generally perceived a difference until this issue?

QFT. With uninitialized variables, completely unrelated changes to the code can trigger them. They're often tickled by changes to address space layout, the state of variables set in a completely unrelated function (re-used heap or stack space), different compiler optimizations, etc.

They're about as close to non-deterministic behavior as you can get in computer code. Notoriously difficult to debug and impossible to predict.

Because the explanation doesn't really work for people that don't have experience with programming of any type (and don't understand the linked Wiki page). It's kind of hard to conjure up a suitable analogy or metaphor for it as well.

Bad Attempt at Doing So:
In a room of 100 people, you've been told to get a message from "Jaime". Unfortunately for you, you don't know who "Jaime" is, if they're male or female, or even if they're human. Additionally, you can't even verify if it's the right message.
So, it's not impossible that you'll find the right "Jaime" and that they'll have the "right" message but it's pretty damn unlikely.

In CoH's case, "Jaime's" message could have been replaced by any other subsystem currently making use of their place.

Maybe a toolbox analogy would be better?

You have a set number of toolboxes, we'll use 100 again, that various people use to store stuff throughout the day. When someone is through with that box, they free it up for someone else to claim, then remove their tools when someone needs to put their stuff in it. This is sort of like, someone claiming it, but the other person's stuff not getting removed, so you don't know if what's in there will be usable or not. For a long time, the other person using that box used the same general tools as you, so it wasn't a big deal, but recently something changed and a new person started using the same box, but they used a mostly different set of tools.

Well, it was mostly just speculation on my part.
I don't claim to really, fully understand the drop code.
But after reading the post by Pohsyb regarding the bug...

Well, from what I gathered, it seemed (IMHO) to be a "likely suspect" - so to speak, why?
Because:
1. Its a semi-recent change to "drops" - specifically recipe drops.
I was thinking this could be the change to the code, that might have seemingly put - said errant "uninitialized variable" into the "structure" of the "drop table"

2. The unknown but apparently very low rate % chance for these to drop, might have responsible for putting a "zero" (or whatever) in a place that was previously unused - or "not called on"?

3. Again, I'm kinda straining a bit to get my head around the general coding & bug mentioned - trying to put it into something resembling a meaningful context - that I might then actually understand.
4. Example - maybe the bug is "set off" by killing a grey boss mob & and getting a successful "percentage roll" that would award a recipe from the Pool C/D table - IF the boss wasn't grey...
I have no clue which of these it checks for first, or how that works at all really. I was just guessing based on my (admittedly limited) understanding of the whole mess.

5. In this old thread linked below - there is a good deal of perceived wonky-ness in how these drops are supposed to work, comparing the people's various experiences getting them (or not), as it were.
Pool C Boss Drops
http://boards.cityofheroes.com/showthread.php?t=131724

This disparity between people's perceptions of recipe drops - was one of the first things to spring to mind when reading the current thread today.

Does this make a little better sense now? And TBH even if it doesn't - I don't know how else to explain what I was thinking.

Originally Posted by Arcanaville City of Heroes didn't fail, City of Heroes was killed. If a 747 dropped on your house, you'd say you were killed, not you failed to find a safer dwelling.