Ammo= on weapons

Bug #894991 reported by Bug Importer
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ares
Fix Released
Wishlist
AlexB

Bug Description

Could you include an "Ammo=" on weapons to define the amount of ammo the weapon uses when attacking? This would for example allow for a unit which can fire against vehicles and infantry with unlimited fire because the relevant weapon has "Ammo=0" set, while only being able to use its highly-destructive anti-building superblaster (or whatever) twice, because it has Ammo=4 and the Uberblaster has Ammo=2.

It would give alot of tactical possibilities to include this feature...

Revision history for this message
Bug Importer (bug-importer) wrote :

Well, why not have Ammo= and Reload= entirely defined on the weapons themselves rather than having them set on the units?

Revision history for this message
mireazma (mireazma) wrote :

a possible explanation would be - because a weapon can be used by several units.

Revision history for this message
MT1337 (mt1337) wrote :

A pretty good idea, in favour of this.

Revision history for this message
Beowulf (genkosygin) wrote :

I am in favor of this win. Seriously. Weapons should have Ammo, not units. That was silly.

Revision history for this message
Black Temple Gaurdian (black-temple-gaurdian) wrote :

So the Ammo= on the weapon is how much ammo from the firer is used?

Revision history for this message
arielby (ariel-bys) wrote :

Certainly

Revision history for this message
FS-21 (jagarni1983) wrote :

If you have a unit that can have 5 of ammo and you have a weapon that requires 5 of ammo then this works like a charge indicator (this remembers me the mobile EMP from TS:Firestorm).
If you have other weapons with ammo=0 then those weapons not reduces the ammo necessary to charge the weapon that require ammo.

Revision history for this message
Bug Importer (bug-importer) wrote :

How this got paired with 726 in DFD? Nice lose-lose you got yourself into. Why cloudn't this issue get compared against something

Revision history for this message
arielby (ariel-bys) wrote :

Last AnnoySumo was me. I meant "something like 375". Hate it when you have to choose 1 of 2 of the best feature requests.

Revision history for this message
Bug Importer (bug-importer) wrote :

maybe ammo should be in the unit, and there would be more than one slot
for example a soldier that fires his m16 at 5m with burst fire and at 7m at semi-automatic, but has another bag of grenades, well, i think that would be useful if more than two weapons become possible

Revision history for this message
Renegade (renegade) wrote :

Note that when this is implemented, the entire set of Ammo control flags should be "weaponized", and weapons on AircraftTypes should use their own Reload and ReloadIncrement flags, rather than the global ReloadRate.

Revision history for this message
arielby (ariel-bys) wrote :

Renegade: Weaponizing all Ammo is gonna look odd - how do you plan to display more then 1 row of pips?

Revision history for this message
Renegade (renegade) wrote :

Maybe we just drop one?

What's your argumentation? "We shouldn't put Ammo on weapons because there might be minor graphical glitches if and only if an ammo pip is displayed?"

Seriously, I recognize the issue (it's not the first time I thought about that - the request is old, after all), but that's a pretty minor thing.
As said, maybe we just don't show the secondary, or switch pips depending on which weapon is active.

Revision history for this message
WoRmINaToR (worminator) wrote :

For curiosity's sake, how will the current Ammo= system be affected? Will mods that don't play around with this new system of Ammo on weapons have to change their code?

Revision history for this message
Renegade (renegade) wrote :

Clearly the lemons will have to be painted blue so the melons don't affect the event horizon.

Seriously, how the hell would I know? We'll see when it's actually implemented. Usually, no changes are necessary if you don't want to use something.

Revision history for this message
WoRmINaToR (worminator) wrote :

If you don't know, then don't answer.

Revision history for this message
Renegade (renegade) wrote :

Hey, you're the one asking the stupid question. *shrugs*

Revision history for this message
WoRmINaToR (worminator) wrote :

was a simple, legitimate question, you're the one giving a stupid answer -_-

If you don't have any idea of how the new Ammo= system would affect the current one, simply say so or say nothing.

Perhaps try this:

"Since there's no real plan for implementation yet, we don't know how the systems will interact, but usually no changes are necessary if you don't want to use a feature."

or maybe:

"It's too early to say yet. Wait on asking that until we have a plan for implementation."

Let's skip on the bullshit for once, shall we?

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Ladies, please don't fight. Ren's "how the hell would I know" looks like a perfectly reasonable answer to me.

Revision history for this message
Renegade (renegade) wrote :

Survived DFD.

Revision history for this message
reaperrr (reaperrr) wrote :

Something that came to my mind recently:
There's one somewhat annoying aspect of the ammo logic.
Let's say a unit has a weapon with Ammo=5.
Now it engages an enemy unit that takes more than 5 shots to destroy. Assuming ROF is low enough that all 5 shots are fired before any ammo point is reloaded (which should be the most common case), after the 5 ammo points have depleted it will fire only a single shot whenever another ammo point has been reloaded until the fight is over and it has time to reload all ammo.

When you implement Ammo= on weapons, could you possibly, "while you're at it", implement something that prevents a weapon which has fully depleted its ammo from firing before it has restored ALL ammo, and prevents it from reloading ammo before the full magazine has been depleted?

This would allow for units to reload a whole "salvo" instead of just one round before they start firing again, allowing for "charging" weapons, and it would possibly render many BurstDelay issues obsolete, as people could simply setup their weapons like this:

[Weapon]
(...)
ROF=1
Ammo=8
Ammo.Reload=90
Ammo.ReloadMagazineLogic=true

This would fire a salvo of 8 rounds with 1 frame delay between them every 90 frames. Once all 8 rounds have been fired, the weapon can't fire again before a full new ammo pack has been loaded.

Once #504 is implemented as well, issues #1203, #935, #955, #749, #1202 and to some extend #1226 could all be worked around/avoided this way. Improving/extending the BurstDelay logic would no longer be necessary, I think (unless I missed some negative side-effects).

Revision history for this message
falaka21 (falaka21) wrote :

I am inclined in favor with this...If you know American Commanche Helicopter
from Generals,you must know its ammo system...It has got 4 ammo pips I think...
But for Rockets only(its main big gun...)When it is out of ammo for rockets,it
continues firing with its Secondary Weapon,(machine guns) until it reloads its rockets.

But even though it has rockets,it prefers to fire with "Machine Guns" against enemy infantries..(That is the "real right thing" what does "Primary" mean ?)

"Ammo on Weapons" with "Firing two weapons at the same time" (I know this issue is different but it is time to mention it) feedback ,would be great...That's it for me now...Your turn guys.. :)

Revision history for this message
AlexB (alexander-b) wrote :

See the blueprint for more information

Changed in ares:
status: Incomplete → Fix Committed
assignee: nobody → AlexB (alexander-b)
milestone: none → 0.b
Revision history for this message
mevitar (mevitar) wrote :

16.76.569, works fine with any value, and objects wait if the ammo they have isn't enough to fire the weapon. It has to be noted, though, that Ammo lower than 0 works as if the value was 0.

Revision history for this message
AlexB (alexander-b) wrote :

Ammo only makes sense if 0 or positive. Firing can never reload.

Changed in ares:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.