Forums » Suggestions
Ammo as a separate item & varieties
Ammo does not currently exist as a separate object, but instead is tracked per module/launcher as a property of that module.
Here I propose that ammo be completely separated from relevant modules and tracked as an actual object. This would allow for less magical means of replenishing ammo in the field, but would also give the ability to more easily add variety and unpredictability to the game through the possible addition of different types of ammo.
Having separate and different types of ammo does not invalidate the need for multiple launchers, since the launchers could dictate base range and accuracy, with the ammo providing base velocity and damage. Specialty ammo (manufactured?) could provide additional bonuses.
While all ship equipment must currently be changed at a station, I would further suggest that ammunition drums be interchangeable in space, allowing for the ability to adapt to a given situation on the fly.
Perhaps the biggest question is: should ammo still require reloading by simulating ammo drums/magazines or should all ammo of a type in the hold be available to linked launchers until it is depleted? Regardless of the method of availability, I think that ammo weight should be calculated per round.
[e1]
In the case of missiles and rockets, the launcher wouldn't contribute quite as much. Since these projectile's ranges are dictated by the amount of fuel they carry, and their accuracy or lack thereof is typically determined by any on-board steering and tracking capability. The launcher could still determine the rate of fire.
[/e1]
----------------------------------------------------------------------------------------------
Details
Launchers
* base range
* base accuracy
* rate-of-fire [e1]
* reduced weight due to ammo no longer being included
Ammunition
* base damage
* base velocity
* other bonuses (+/-)
* weight tracked per round
Launchers would need to have their active ammo linked to them until that link is changed. If launchers require reloading, when reloading is initiated they will reload from the linked ammo.
Ammo changes, whether instantaneous or delayed, should dump remaining ammo in any possible magazine/clip back into the pool before loading the new ammo.
[Edit1] Added Rate-of-Fire and rocket/missile info.
Here I propose that ammo be completely separated from relevant modules and tracked as an actual object. This would allow for less magical means of replenishing ammo in the field, but would also give the ability to more easily add variety and unpredictability to the game through the possible addition of different types of ammo.
Having separate and different types of ammo does not invalidate the need for multiple launchers, since the launchers could dictate base range and accuracy, with the ammo providing base velocity and damage. Specialty ammo (manufactured?) could provide additional bonuses.
While all ship equipment must currently be changed at a station, I would further suggest that ammunition drums be interchangeable in space, allowing for the ability to adapt to a given situation on the fly.
Perhaps the biggest question is: should ammo still require reloading by simulating ammo drums/magazines or should all ammo of a type in the hold be available to linked launchers until it is depleted? Regardless of the method of availability, I think that ammo weight should be calculated per round.
[e1]
In the case of missiles and rockets, the launcher wouldn't contribute quite as much. Since these projectile's ranges are dictated by the amount of fuel they carry, and their accuracy or lack thereof is typically determined by any on-board steering and tracking capability. The launcher could still determine the rate of fire.
[/e1]
----------------------------------------------------------------------------------------------
Details
Launchers
* base range
* base accuracy
* rate-of-fire [e1]
* reduced weight due to ammo no longer being included
Ammunition
* base damage
* base velocity
* other bonuses (+/-)
* weight tracked per round
Launchers would need to have their active ammo linked to them until that link is changed. If launchers require reloading, when reloading is initiated they will reload from the linked ammo.
Ammo changes, whether instantaneous or delayed, should dump remaining ammo in any possible magazine/clip back into the pool before loading the new ammo.
[Edit1] Added Rate-of-Fire and rocket/missile info.
-1
Too complicated, too tedious.
Too complicated, too tedious.
+1; if only for the event and combat possibilities. I understand Greenwall's position, but while the current system "works" it sure ain't flexible. I personally would like to see more types of launcher-styled weapons, and of course it would be cool to stuff a swarmtrailing missile into a stingray launcher.
Should ammo be sold under a new tab if such a system were implemented? Possibilities for hive-exclusive missile drops? etc?
Should ammo be sold under a new tab if such a system were implemented? Possibilities for hive-exclusive missile drops? etc?
When I was writing this suggestion, I completely blanked on missiles and rockets being the more popular choice of projectile weapons. The initial suggestion is slanted more towards conventional weapons like rails and flechettes. That said, I neglected to take rate-of-fire into account which would be largely launcher dependent.
In the case of missiles and rockets, the launcher wouldn't contribute quite as much. Since these projectile's ranges are dictated by the amount of fuel they carry, and their accuracy or lack thereof is typically determined by any on-board steering and tracking capability. The launcher could still determine the rate of fire.
In the case of missiles and rockets, the launcher wouldn't contribute quite as much. Since these projectile's ranges are dictated by the amount of fuel they carry, and their accuracy or lack thereof is typically determined by any on-board steering and tracking capability. The launcher could still determine the rate of fire.
A lot of work for little effect but there is a case to be made for it. It would add a measure of flexibilty to the sytem overall but rebalancing the whole system would be required.
Worth a discussion but I think there are far more important issues that need attention first.
Worth a discussion but I think there are far more important issues that need attention first.
like all suggestions, this is to discuss merit and not a guarantee of feasability, timescale, or anything more than just suggestions >.<