I can fix the heavy ammo bug

Have a new variable with the current ammo count in it that is written to when the player dies or goes to orbit / enters a cutscene.

Spawn the player and apply all perks.

Check to see if the current ammo count matches the value of the new variable.

If it does not, overwrite the current ammo count with the value in the new variable.

Programming is easy yo :-p Just hack it in until you can fix the root problem.

locked

2400 views

Programming is easy yo :-p Just hack it in until you can fix the root problem.

I cannot tell you how much of my time has been spent over the past 20 years fixing problems caused by this thinking.

locked

2104 views

Programming is easy yo :-p Just hack it in until you can fix the root problem.

I cannot tell you how much of my time has been spent over the past 20 years fixing problems caused by this thinking.

I thought that's what comments were for!

locked

2073 views

Programming is easy yo :-p Just hack it in until you can fix the root problem.

I cannot tell you how much of my time has been spent over the past 20 years fixing problems caused by this thinking.

I thought that's what comments were for!

Oh man, sometimes commenting just makes it worse. They add in a huge chunk of code and then 2 paragraph description, then when they realize it doesn't work any more they remove the code and forget to remove the comments...

I'm so glad I got out of Computer Science at college.

locked

2031 views

[image]

locked

2041 views

Still doesn't excuse a bug being left unfixed for months on end. If the feature is so broken as to to require a complete re-write of one of your game's core systems, CUT IT. Swap out the ammo perks for something else, and increase the base max ammo for all weapons.

locked

2047 views

Make it give all Heavy Weapons Field Scout instead.

No idea how feasible that is, mind.

locked

1982 views

Check to see if the current ammo count matches the value of the new variable.

If it does not, overwrite the current ammo count with the value in the new variable.

That's silly, since

If(y!=x){
y=x;
}

is equivalent to

y=x;

...Seeing as the occasional success of the system means that they're already *trying* to track the variable, the solution probably isn't as simple as "just store the variable somewhere."

locked

2038 views

...though I'm sure it's pain of their own making due to how the system is set up.

I'm sure the problem is something to do with bringing the player back to life.

I suspect they "reconstruct" a new player rather than re-constituting the old one, in a.

1- start with the base player.
2- add the talent modifications.
3- change stats based on gear

I suspect that in stage 1 they are applying ammo pre-perks.

I also suspect that ammo isn't a simple number, as your ammo definitely changes in other ways at death (other than the loss of heavy ammo).

locked

2020 views

I'm no programmer, but I had a similar theory.

The exact number of steps is probably much more complex obviously, and might not be grouped exactly like that, but I think the logical flow makes sense.

locked

2008 views

I production tested games for more than 12 years. This bug was definitely found in the very early stages of the game, but was probably marked as a "C" class bug (unimportant, not worth fixing) because (shock) there were no PvE situations where heavy ammo was both scarce and necessary at the time the bug was found (because the raids weren't in yet), and since heavy ammo resets to zero on death in PvP, the bug didn't apply there.

Later, when raids became a thing, no one bothered to upgrade the bug. At that point, it was already a "legacy" issue and therefore was effectively signed off on by the producers. In addition, heavy ammo synthesis is a thing, so the bug isn't game breaking by any stretch of the imagination.

The failure here seems to be more systemic than individual. Lots of individuals are doing their individual jobs correctly, but no one took the initiative to step outside of their fiefdoms and see the big picture in this one case. Guaranteed there were many other bugs that were squashed, such that we never saw them and don't know about them.

Now, I get why this feels like a dumb bug. It seems like counting should be a thing that computers are good at, and that programmers should be good at, too. Remembering a single number also seems easy. Common sense does dictate that the fix should be easy because: Counting.

But there's another thing at play here: Heavy Ammo isn't a number. Notice how when have 5 rockets, and change to a machine gun, you don't have 5 bullets, but more like 63 or something? That's because Heavy Ammo is a percentage, not a number. Player X has 100% heavy ammo. Because he has boots of awesome on, his max value is 5 (rockets) + 2(boots) = 7. So he has 7 heavy ammo. Oh, he died? Well he's still at 100%, which is 5 (rockets). Now add boots back in, and he's at 71%. So he died again, and was at 71%? Okay, so 71% of 5 is 3.6 Well, the game rounds down, so he's got 3 rockets out of 5. Oh yeah, he has boots, 3 of 7 is 43%... and so forth.

So obviously the order of operations is ass backwards for figuring out what the max heavy ammo is for a player, and then applying the percentage of heavy ammo that they have. But the order of operations is, as others have mentioned, probably a fundamental thing.

The work around fix, as far as I can guess, would be something really wonky like when a player dies, creating invisible ammo packs that are percentages equal to what they had when they died, respawning the player, and then dropping those invisible packs onto the player. Super weird, and then there's a chance that that something unexpected happens, like the player spawns in midair and the ammo packs hover above their head and then the player has to jump after spawning to get any ammo at all.

I don't know why I'm so forgiving about obvious bugs and so unforgiving about terrible design decisions. Oh wait, yes I do.

locked

2037 views

As one of my CS professors liked to say (in his Chineese accent) "You think counting is easy? Counting is haaard".

locked

1964 views

He's right!

locked

1942 views

This sounds correct. Probably have a Guardian object or model and for whatever reason they can't store the ammo params and pass it into the new object. I wonder why they chose to destroy the Guardian on death (eliminate the current Guardian object) rather than having an `alive` param set to true or false. Although a part of me is curious about this because the Sunsinger can resurrect, so there can't be an immediate destroy method call on the Guardian object.

I've never coded a video game, but as a programmer, I have first hand knowledge of unexpected bugs manifesting themselves in complex systems. I also know that I often have to prioritize new features in our upcoming apps over fixing bugs in our apps on prod. If this is the same mode of thinking at Bungie, then I understand why this isn't fixed yet. Since this affects two of my characters, I'd like to see it fixed, but I'm not holding my breath.

locked

1908 views

Well surely nothing is destroyed right away anyway because most times you can be revived either by your fireteam or by random players in patrol areas.

locked

1961 views

Although a part of me is curious about this because the Sunsinger can resurrect, so there can't be an immediate destroy method call on the Guardian object.

As long as you're waiting for a revive you're not really gone yet - that's true for all characters, not just sunsingers. The character object's probably not destroyed/unloaded until actual death occurs, i.e. the downed player hits the respawn button (when available) or the team wipes/goes to orbit (or, oddly, enters a cutscene).

locked

1951 views

Or in Purgatory, because ammo synths don't get applied during "waiting for respawn" the way they would during life. There is some state there that is different, has different parameters, and different information that makes it over to "life".

locked

1919 views

Have a new variable with the current ammo count in it that is written to when the player dies or goes to orbit / enters a cutscene.

Spawn the player and apply all perks.

Check to see if the current ammo count matches the value of the new variable.

If it does not, overwrite the current ammo count with the value in the new variable.

Programming is easy yo :-p Just hack it in until you can fix the root problem.

I am sure all bugs in Destiny that persist are due to Bungie not having any programmer as good as you.

locked

1931 views

So now every time a warlock uses their rez they get heavy ammo. Good job fixing it hero.

locked

2020 views

- No text -

locked

1988 views

- No text -

locked

2002 views

So now every time a warlock uses their rez they get heavy ammo. Good job fixing it hero.

They wouldn't at all because the values would be the same. You don't lose ammo when you are rezed, only on wipe / orbit / cutscene.

Warlock dies with 7 heavy ammo. New variable is set to 7 ammo.

He is resurrected.

His ammo count is set to the new variable, which is 7. What he had before.

Where's the problem?

locked

2004 views

They pointed out that it's probably tracked as a percentage, not a value.

Besides, if the fix was as simple as you say, they'd have done it already.

Obviously, it's not.

locked

2005 views

They pointed out that it's probably tracked as a percentage, not a value.

Besides, if the fix was as simple as you say, they'd have done it already.

Obviously, it's not.

Why does that matter? Save the percentage instead of the actual number. Just make the new variable equal to whatever the current ammo count is on death, be that a percentage, number, irrational number, string value, whatever.

locked

1977 views

Because you have 7 rockets of 7 with the perk, which is 100%. Save 100%. Apply it. You now have 5/5 rockets. Apply the perk, now you have 5/7 rockets.

Someone else already pointed this out, and there's probably something fundamental about the order in which things are applied or reconstructed or whatever.

I'm no coder, but if the fix was as simple as you think, it should have been fixed by now. It hasn't been. So it's probably not nearly so simple a fix.

locked

1988 views

Because you have 7 rockets of 7 with the perk, which is 100%. Save 100%. Apply it. You now have 5/5 rockets. Apply the perk, now you have 5/7 rockets.

I suspect a significant problem with the 'fix' is that it would end up being exploitable. If they change (what we're calling the order of operations) then you could die with armor that gives you 5/5, swap to armor that gives you a max of 7, & boom, you suddenly have two more rockets when you're ammo is placed at 100%.

locked

2019 views

Because you have 7 rockets of 7 with the perk, which is 100%. Save 100%. Apply it. You now have 5/5 rockets. Apply the perk, now you have 5/7 rockets.

Yes, that's why the bug happens.

That's why AFTER ALL PERKS ARE APPLIED you restore the ammo with the value that they had right before they rebuilt the character. This also has the benefit of preventing any monkey business with swapping armor and stuff on death.

The game decides to spawn you and rebuild your character.

1. Save the value of the current ammo count. This is done the instant before your character is rebuilt.
2. Rebuild the character and apply the perks.
3. Restore the ammo count.

Because the value is saved the instant before the character is rebuilt, you will always have whatever you had right before the rebuild.

locked

2027 views

What happens if I die, and before resurrecting I swap either my heavy weapon OR my armor?
If you simply save off a number, swapping weapons will be very broken.
If you simply save a percentage, swapping armor will be very broken.

Both would be broken in a way that could be taken advantage of, or really screw the player. At least the way it stands right now it's predictable and there is no way to game the system.

locked

1990 views

[image]

locked

1984 views

What happens if I die, and before resurrecting I swap either my heavy weapon OR my armor?
If you simply save off a number, swapping weapons will be very broken.
If you simply save a percentage, swapping armor will be very broken.

I don't see the problem. If you are dead, and you swap armor, then the game would adjust the value as if you were alive. There would be literally no difference.

locked

1963 views

Because it'll reapply the values over it from that little temp file you said it should store. Maybe it wouldn't do that, maybe it would; it depends on how it's all set up.

locked

1990 views

What happens if I die, and before resurrecting I swap either my heavy weapon OR my armor?

I don't see the problem. If you are dead, and you swap armor, then the game would adjust the value as if you were alive. There would be literally no difference.

I'll write it out a little bit longer.

If you simply save off a number, swapping weapons will be very broken.

If I save off the number "7", then swap to a machine gun, I would expect to have more than 7 bullets. Very broken, and in a worse way than it currently is.

If you simply save a percentage, swapping armor will be very broken.

If I save off "50%" ammo, and in death remove two armor pieces that increase my max ammo by 2, than when "50%" is applied upon respawn I will have 1 less rocket than expected. More concisely, I would go from 3 of 6 to 2 of 4, even though my original ammo count was within the bounds of the maximum count.

We also don't know what methods are being used to save or configure this information. Good development is finding an operation that is done in multiple locations and using a single method/function for it. It could be that "save ammo" is used in dozens of different situations, and this bug only shows up in 3 of them. Obviously the method wasn't as multi purpose as they hoped, but they can't simply rewrite the method without breaking the 9 cases where it DOES work.

It really is sort of hard to understand, but it's very much like any sort of architecture. Beautiful, simple, fast architecture is also some of the most interdependent and hardest to "move a wall" or "move a beam" without having to modify lots of other pieces. It really can be like Janga, which is when a developer looks into a bug and instead of it being a one line fix they start swearing and banging their head into the desk.

locked

1996 views

What if they keep percentages separate from actual armor capabilities? I.e. have percentages go over 100% and have max possible percentage also stored as a separate value.

That way, it is stored, for example, you have 120% heavy ammo of current gun with a 150%-capable armor. You switch back to a 110%-capable armor. Since it blows the cap, your ammo is reduced to 110%. Now, I can't see anymore problems with it than this expected ammo-depletion (which is fair, imho), but I'd be glad to hear any criticism from you guys.

locked

2141 views

...would work. At least I can't think of a way to break it. I'll keep sitting on it though :)

locked

1982 views

That way, it is stored, for example, you have 120% heavy ammo of current gun with a 150%-capable armor. You switch back to a 110%-capable armor. Since it blows the cap, your ammo is reduced to 110%. Now, I can't see anymore problems with it than this expected ammo-depletion (which is fair, imho), but I'd be glad to hear any criticism from you guys.

& easily done with a float. 1.0 = 100%, 1.2 120%... etc.

locked

1934 views

If I save off "50%" ammo, and in death remove two armor pieces that increase my max ammo by 2, than when "50%" is applied upon respawn I will have 1 less rocket than expected. More concisely, I would go from 3 of 6 to 2 of 4, even though my original ammo count was within the bounds of the maximum count.

You are not understanding. You save the value THE INSTANT BEFORE THE CHARACTER REBUILD HAPPENS. The glitch happens when the character is rebuilt on spawn. So you determine how much ammo you have the nanosecond before spawn, then restore it after spawn.

Also, if you remove the armor in your example while you are alive, the same thing would happen. There is no problem at all with the scenario. If you have 7 ammo, and remove armor pieces that let you have that 7, or course your ammo is going to go down.

locked

1933 views

You are not understanding.

I was not understanding the assumptions you were making. I was making or allowing for a greater number of scenarios.

You save the value THE INSTANT BEFORE THE CHARACTER REBUILD HAPPENS. The glitch happens when the character is rebuilt on spawn. So you determine how much ammo you have the nanosecond before spawn, then restore it after spawn.

You assume two things:
1. That the nanosecond before spawn that the ammo count is still available. It may get wiped on death, and rebuilt on life.
2. That there is no scenario where the player does not have time to change the capacity. If the capacity is no longer available after death, and doesn't get instantiated again until life, than you have anywhere between 3 seconds and an infinite time between next spawn.

Also, if you remove the armor in your example while you are alive, the same thing would happen. There is no problem at all with the scenario. If you have 7 ammo, and remove armor pieces that let you have that 7, or course your ammo is going to go down.

That was not my example. My example was having 3 rockets with a capacity of 6. Removing armor while alive that drops your capacity to 4 should have no effect on the 3 rockets you have. If you simply use a percentage total capacity, and there exists time for the player to adjust that capacity between when the current value is no longer accessible and when the value is instantiated again, you will have a problem

That said, ZackDark came up with a solution based on percentage weapon capacity instead of total capacity that I can't find a way to break yet. It might involve changing the variable type (which isn't always an easy task) but functionally I don't see an issue with yet.

locked

1986 views

If you're right, then I don't really see any problems with your solution. However, if it takes longer than a single frame/timestep (whatever the refresh rate for user interaction is), there is a possibility of gaming the system. And, by now, we all know how they feel about gaming their game.

locked

1986 views

Well that and just about everybody's assumptions seem centered on this bug as if Destiny was solely a single player game when it isn't. I'm not entire sure that the concept of a host player still exists in Destiny but I've seen bad connections and sync issues cause all sorts of weirdness. Players' positions can jump around. Enemy AI units will sometimes blip backwards in time and repeat an action like jumping down from a ledge, firing from around an obstacle, or even dying multiple times over. I'm fairly certain I've even seen lag affect things like ammo counts where you can fire a whole magazine from your point of view but a moment later have a few bullets left.

Now take the heavy ammo bug with all the potential causes and imperfect solutions people have identified and try to keep things sane and in sync with two, five, or eleven other players! If an enemy's position or alive vs dead state can drift out of sync and be reset to what the various clients think is canonical then so can the amount of heavy ammo, or which sets of armor you have equipped, or which weapon you've swapped to. What happens to Cody's overly cute solution of "just write down the correct number and restore it exactly when it is appropriate" when a bit of lag pushes your game state back half a second? Or the other clients tell yours that you actually fired off another rocket that you didn't think you did?

locked

1966 views

If ammo count is modified while dead (e.g. Changing to an LMG changes from 2 rockets to 60 bullets (or 2 rockets to 1 in a different launcher) BEFORE respawn) this might work.

If that count isn't modified until spawn (seems likely, considering the bug is a respawn-related issue, and the fact synths don't work while dead) then we get 2 problems:
1) Saving numbers wouldnt work, because of the rocket/bullet conversion
2) Conventional (0-100) Percentages wouldn't work because you could game the system - Die with 4/4 Hunger of Crota rockets = 100%. then equip heavy ammo boots, and 100% is now 6. You could GAIN ammo.

ZackDark's way sounds good though.

locked

1921 views

at least i can fill it back up faster.

locked

2003 views

Yes people will game the system by wearing boots, buy packs, equip other boots during combat.

But they have bought a few months of cheese with all their past suffering.

-PS or whatever it is that gives the perks (in case people think I have a boot fetish)

locked

1996 views

- No text -

locked

1938 views

Why haven't they just disabled the perk (like they did with black hammer) or temporarily replaced it with another perk (like with the big exotic weapon patch a while back). I don't know if it would make more sense to change every piece of armor with that perk or just change it on the raid boots, but at the very least the raid gear needs to be fixed.

Right now, you're required to wear this armor to be a 32 and enter a raid that requires you to have tons of heavy ammo available. There's no way around losing a ridiculous amount of ammo to this raid unless you're cool enough to pull it off in one or two attempts. And if that's you (anyone reading, not specifically Cody), I might hate you just a little :p

-Disciple

locked

1967 views

The bug doesn't effect PvP, but the perks for extra heavy ammo certainly effect PvP. I quite enjoy walking around with 4 Truth rockets.

locked

1933 views

...like being able to select between arc and solar damage on Murmur. I wish they had done something similar for Black Hammer. I would be totally fine having to choose either White Nail or Hive Disruptor. For me, the Hive Disruptor perk would be the more useful of the two in most situations.

I do realize, though, that these are all things that have been applied to weapons, but not armor. There may be some HUGE difference between the two that would make this just as difficult to implement as the actual bug fix.

-Disciple

locked

1963 views

...is a fix for a defect that is a half assed temporary patch. "If you can't say anything nice, don't say anything at all" applies to software engineering, and some of the worst code is code that started as a clever patch, but was not thought through as a design/architecture level and with the thought that things may change over the years.

But it's a problem. The "Right" way to fix things almost always takes longer and/or costs more. It's borderline a fact of life. So if this truly is a difficult bug, I applaud Bungie from a software engineering perspective for taking the time to fix it correctly, instead of applying a quick hack that will eventually fail and likely in a more catastrophic (money/time/defects) ways.

locked

1958 views

What's wrong with them hacking in a fix to hold us over while they work on fixing it for real?

locked

1958 views

What's wrong with them hacking in a fix to hold us over while they work on fixing it for real?

Because anyone who writes code for a living can attest that temporary hacks almost always become the long term solution.

Once you put something in place that "works well enough", the priority to go back and fix the actual root cause plummets to the floor

locked

1964 views

- No text -

locked

1945 views

What's wrong with them hacking in a fix to hold us over while they work on fixing it for real?

Because now you're paying for throw away code, both in the writing and the testing.
You're also risking MORE developer and tester time if the hack isn't perfect.
You're also risking a PR shitstorm if the hack doesn't go off as planned.
You're also paying employees to work on temp hack code instead of working on real lasting fixes. Even with infinite money their employee count at this moment is finite.

I'm sure there are more variables that I'm either not considering, or that are unique to Bungie.

It might make business sense for some defects, on some products, for some companies. Bungie has determined that isn't the right approach, based on a lot more information than we have. Deej has publicly acknowledged this defect, it *IS* on their radar, and the public's radar. It won't be forgotten.

Also a fun fact of software, defect lists are like icebergs, any single customer or general public is only aware of a fraction of the known defects. The ammo bug may be highly visible, but that doesn't mean it's the most harmful defect on Bungie's list.

locked

1942 views

- No text -

locked

1965 views

Heavy kills have a chance to generate heavy ammo

-or-

Super kills have a chance to generate heavy ammo

-or-

picking up orbs of light have a chance to generate heavy ammo

locked

1982 views

- No text -

locked

1958 views

- No text -

locked

1897 views

"Don't lose heavy ammo on death."

I would give all of the coins for that.

-Disciple

locked

2049 views

Logically, your argument is sound-ish. As previously pointed out: if (y != x) { y = x} is a functional nightmare, but I get where your going with it. Basically you're saying we need to save some parameters on death and be able to pass them into your next life. Not a crazy idea. It does suggest that the problem has to do with memory and Guardian instantiation which, frankly, is probably a pretty complex process. I think we all should have faith in Bungie that if the problem actually was simple enough to fix with something like this, then it would have been patched.

I would like to point out another problem with your function I'm not sure anyone has seen yet. When would this function be called? If you happened to use a heavy ammo synth while this variable is stored but before the function was called (very possible, since you would cache as much as you could to save system resources) you'd get yourself a situation where the variable saved would be 0, does not match the new variable of 100% heavy ammo, the variable would be set to the previous ammo number per your function, and then upon life you would have 0 ammo, despite taking a synth.

Thoughts?

locked

2005 views

Logically, your argument is sound-ish. As previously pointed out: if (y != x) { y = x} is a functional nightmare, but I get where your going with it. Basically you're saying we need to save some parameters on death and be able to pass them into your next life. Not a crazy idea. It does suggest that the problem has to do with memory and Guardian instantiation which, frankly, is probably a pretty complex process. I think we all should have faith in Bungie that if the problem actually was simple enough to fix with something like this, then it would have been patched.

I would like to point out another problem with your function I'm not sure anyone has seen yet. When would this function be called? If you happened to use a heavy ammo synth while this variable is stored but before the function was called (very possible, since you would cache as much as you could to save system resources) you'd get yourself a situation where the variable saved would be 0, does not match the new variable of 100% heavy ammo, the variable would be set to the previous ammo number per your function, and then upon life you would have 0 ammo, despite taking a synth.

Thoughts?

This already happens, actually. (If I use a heavy ammo synth when I'm dead, in the middle of a battle, it's gone when I actually respawn.)

locked

2008 views

I have the same problem with my Hunter and using Lucky Raspberry. For some reason, and I read it on the Bungie Forum, taking my heavy ammo synths, vaulting them and then taking them back, fixed the issue for me. It was a shitty thing to discover while up against Atheon.

locked

1972 views

Back to the forum index

RSS Feed of thread

DBO Forums

I can fix the heavy ammo bug (Destiny)