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.

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?

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.

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.

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.

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.

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.

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.)

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).

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?

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.

I would give all of the coins for that.

-Disciple