[DECORATE] +AMMO_CHECKBOTH
Moderator: GZDoom Developers
[DECORATE] +AMMO_CHECKBOTH
I apologize if this post is rather convoluted. I can deliver a summed-up version if needed.
Most current methods of creating reloading weapons involve two ammo types: an ammo reservoir (e.g. "Clip") and a loaded clip which counts the bullets currently in the weapon itself. A common oddity in this system, however, is that usually the clip count is defined as AmmoType2 and the reservoir as AmmoType1. This lends itself better to being properly displayed on the default HUD, but this usually means that the primary fire generally takes away from AmmoType2 (via A_TakeInventory) when firing normally.
This winds up causing some trouble when ammo becomes scarce. In the event that the player loads the last of his or her ammo into their gun (resulting in zero spare ammo but a few shots left in the clip), the engine notices the zero ammo count and will suddenly switch the gun away when attempting to fire, thinking that the weapon is empty when in reality it is not. The common solution I have seen has been to simply add +AMMO_OPTIONAL to the weapon definition, but while it fixes the zero-ammo problem, it also allows the weapon to be selected even when its ammo supply has been completely exhausted. Needless to say, this botches up auto-switching entirely, which can quickly become a major hassle. This issue manifests itself most noticably in mods such as Zen Dynamics, in which any weapon is inconveniently selectable at any time regardless of whether the weapon is empty or not.
A noble fix: the AMMO_CHECKBOTH flag. This flag, if checked, will disallow auto-switching until both AmmoTypes are depleted. The above scenario will be mended perfectly, as the engine will autoswitch if both the ammo reservoir and current clip are empty but not until then. In further practice, this would also allow a weapon that uses, say, "Clip" for AmmoType1 and "Shell" for AmmoType2 to stay selected if one ammo type is empty while the other is full. I always found it odd that such a weapon is switched away if I run out of Clips and accidentally tap my primary fire key, even though I still have a plethra of Shells remaining.
A lengthy explanation, but hopefully a justified one.
Most current methods of creating reloading weapons involve two ammo types: an ammo reservoir (e.g. "Clip") and a loaded clip which counts the bullets currently in the weapon itself. A common oddity in this system, however, is that usually the clip count is defined as AmmoType2 and the reservoir as AmmoType1. This lends itself better to being properly displayed on the default HUD, but this usually means that the primary fire generally takes away from AmmoType2 (via A_TakeInventory) when firing normally.
This winds up causing some trouble when ammo becomes scarce. In the event that the player loads the last of his or her ammo into their gun (resulting in zero spare ammo but a few shots left in the clip), the engine notices the zero ammo count and will suddenly switch the gun away when attempting to fire, thinking that the weapon is empty when in reality it is not. The common solution I have seen has been to simply add +AMMO_OPTIONAL to the weapon definition, but while it fixes the zero-ammo problem, it also allows the weapon to be selected even when its ammo supply has been completely exhausted. Needless to say, this botches up auto-switching entirely, which can quickly become a major hassle. This issue manifests itself most noticably in mods such as Zen Dynamics, in which any weapon is inconveniently selectable at any time regardless of whether the weapon is empty or not.
A noble fix: the AMMO_CHECKBOTH flag. This flag, if checked, will disallow auto-switching until both AmmoTypes are depleted. The above scenario will be mended perfectly, as the engine will autoswitch if both the ammo reservoir and current clip are empty but not until then. In further practice, this would also allow a weapon that uses, say, "Clip" for AmmoType1 and "Shell" for AmmoType2 to stay selected if one ammo type is empty while the other is full. I always found it odd that such a weapon is switched away if I run out of Clips and accidentally tap my primary fire key, even though I still have a plethra of Shells remaining.
A lengthy explanation, but hopefully a justified one.
Re: [DECORATE] +AMMO_CHECKBOTH
Makes sense, and I can definitely see a use for this.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49072
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [DECORATE] +AMMO_CHECKBOTH
Easier said than done, unfortunately...
Re: [DECORATE] +AMMO_CHECKBOTH
Setzer, can you try this exe and tell me if it works? I think it should but I have no weapon mods installed so I haven't tested it.
<link removed>
<link removed>
Last edited by Gez on Thu May 07, 2009 5:42 pm, edited 1 time in total.
Re: [DECORATE] +AMMO_CHECKBOTH
I apologize for the latent response.
Unfortunately, the executable crashes when attempting to use the new flag. I cannot procure an error message either; there is no crash log aside from the standard Windows "illegal operation" routine.
Good to see you're looking in to this, however. Perhaps this may help isolate the problem:
Unfortunately, the executable crashes when attempting to use the new flag. I cannot procure an error message either; there is no crash log aside from the standard Windows "illegal operation" routine.
Good to see you're looking in to this, however. Perhaps this may help isolate the problem:
- Attachments
-
- zpwtest.zip
- A single reloadable weapon, ripped from Zero Tolerance and given the appropriate flag. It is assigned highest priority in weapon selection order as well. See if you can produce the intended behavior with this wad. I seem to be too sparse to do it myself in good time. ;)
- (53.42 KiB) Downloaded 41 times
Re: [DECORATE] +AMMO_CHECKBOTH
Thanks, I'll take a look at it.
Okay, the crash is easy to understand, given the stupid goof I made. Oops. Infinite recursion.
But I've made a working implementation of it now, and I like it enough to suggest this thread be moved to code submission.
By the way, don't forget to give values to both Weapon.AmmoUse1 and Weapon.AmmoUse2, otherwise the flag will behave just as AMMO_OPTIONAL... The default values for those is 0, and since it checks for at least as much ammo as AmmoUse, and the amount in inventory will always be at least 0...
Okay, the crash is easy to understand, given the stupid goof I made. Oops. Infinite recursion.
But I've made a working implementation of it now, and I like it enough to suggest this thread be moved to code submission.
By the way, don't forget to give values to both Weapon.AmmoUse1 and Weapon.AmmoUse2, otherwise the flag will behave just as AMMO_OPTIONAL... The default values for those is 0, and since it checks for at least as much ammo as AmmoUse, and the amount in inventory will always be at least 0...
Last edited by Gez on Sun May 31, 2009 12:04 pm, edited 1 time in total.
Re: [DECORATE] +AMMO_CHECKBOTH
Another bump for this to be moved in code submission...
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49072
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [DECORATE] +AMMO_CHECKBOTH
If you have a moderation request (thread moving is one!) please use the report function. That's what it's there for.
Re: [DECORATE] +AMMO_CHECKBOTH
I used to think that doing that was abusing the report feature (because it doesn't state anywhere on the forum that you can use it to move threads), but I went "eh what the hell, this is the most guaranteed way to get a mod's attention"...Graf Zahl wrote:If you have a moderation request (thread moving is one!) please use the report function. That's what it's there for.
Sorry for the offtopicness. We return you to your regular feature implementation marathon!
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49072
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [DECORATE] +AMMO_CHECKBOTH
Added. No idea why I overlooked it so far...