Forums » Suggestions
Make Basic Gatling a Pirate Weapon
As if they needed another weapon, right? But the idea came to me nonetheless and I think it could provide honorable Pirates with an alternative to using sunflares.
The basic gatling cannon could fire solid ammo. Nothing would change, except that it would take *no* energy to fire, but it would hold only 100 ammo. That way you could boost and fire this baby without losing energy :).
Just imagine, a pirate Hog says "jettison your cargo or be destroyed." You, the brave trader refuses of course, but instead of slamming you with sunflares the pirate starts peppering you with the gatling cannon! "Do you give up *now*?" heh heh. The advanced gatling cannon would still use energy, but the basic gatling would use no energy and consume ammo.
Note: I don't want this to turn into a discussion about how dishonorable pirates are. Just post what you think about the weapon and/or how it could be used/misused.
The basic gatling cannon could fire solid ammo. Nothing would change, except that it would take *no* energy to fire, but it would hold only 100 ammo. That way you could boost and fire this baby without losing energy :).
Just imagine, a pirate Hog says "jettison your cargo or be destroyed." You, the brave trader refuses of course, but instead of slamming you with sunflares the pirate starts peppering you with the gatling cannon! "Do you give up *now*?" heh heh. The advanced gatling cannon would still use energy, but the basic gatling would use no energy and consume ammo.
Note: I don't want this to turn into a discussion about how dishonorable pirates are. Just post what you think about the weapon and/or how it could be used/misused.
I love the not so adv gat as it is, maybe there could be a version of it that's slightly more powerfull and uses ammo.
Please don't take my gat away...
BTW, overall this is a very fine idea :)
Please don't take my gat away...
BTW, overall this is a very fine idea :)
The devs already tried giving the gatling guns ammo, but unfortunately something went screwy with the combination of ammo and high rate of fire. I guess it's a current engine limitation or bug, I'm not exactly sure what. I would however like to see the regular gatling gun available as an S-port weapon. It looks like it would be a fun weapon to use on the Centurion, and yet it's not too powerful or accurate.
Arolte> See http://vendetta.guildsoftware.com/?action=msgboard&thread=2194&page=1
I would like to see ammunition based ballistic weapons. There are not enough of those (read:none). Someone mentioned a Flak Cannon that sounded good. I would also like to see that damn aimbot fixed. Very hard to hit anything from anything more than medium range. Vultures especially.
FiReMaGe/vx: Well, please notice that I raise question marks after certain statements because of the very issues you raise. I honestly don't know the answer. Energy is apparantly client side. I don't know why ammo can't be either, or why any of the changes in the engine you mention (particularly the consistancy buffering) can't be implemented. I only know that they would be changes in the engine and at the present time the engine can't handle rapidly cycling ammo weapons and the devs have not mentioned fixing that as a high priority despite the fact that the original gatling was I understand designed to consume ammo.
So you're telling me energy is server side also and that it updates every millisecond so there would be no unlimited energy hack?
Energy is updated constantly on the client, which ever way it is handled. If energy is at a risk of being unlimited and you suppose everything is secured (meaning it's server side), why not just have the ammo server side (but I know why not, I'm kidding).
Say the energy is checked so it has a value that is close to what it should every few seconds, why not use the same method with this rapid ammo.
It's not like energy with no battery? Basically, couldn't the ammo be handled the way energy is. That way it's possible.
Energy is updated constantly on the client, which ever way it is handled. If energy is at a risk of being unlimited and you suppose everything is secured (meaning it's server side), why not just have the ammo server side (but I know why not, I'm kidding).
Say the energy is checked so it has a value that is close to what it should every few seconds, why not use the same method with this rapid ammo.
It's not like energy with no battery? Basically, couldn't the ammo be handled the way energy is. That way it's possible.
the gatling as an expendable-ammo-type-weapon would be nice, would make the people more cautious, spray-and-pray would be reduced. the gatling would neet greater accuracy, otherwise it's no good, if you waste 50% on the void in space simply due to the fact that the cannon is too inaccurate.
speaking of gatling cannons, the M61A1 vulcan cannon employed by most aircraft designers has a rate of fire of 6600 shots per mnute and a repeat rate of .009091. the sound of the cannon is somewhat strange, sounds like a siren (from afar). it has a magazine capacity of 515 shots, which makes for approximately 4.7 seconds of continuous firing.
i don't know if you made the 100 rounds up celebrim, but it was quite close to reality:
the gatling cannon has a repeat of 0.075 if i'm not mistaken, thus 13 1/3 shots per second, 800 shots per minute, 100 shots = 7.5 seconds of continuous firing.
speaking of gatling cannons, the M61A1 vulcan cannon employed by most aircraft designers has a rate of fire of 6600 shots per mnute and a repeat rate of .009091. the sound of the cannon is somewhat strange, sounds like a siren (from afar). it has a magazine capacity of 515 shots, which makes for approximately 4.7 seconds of continuous firing.
i don't know if you made the 100 rounds up celebrim, but it was quite close to reality:
the gatling cannon has a repeat of 0.075 if i'm not mistaken, thus 13 1/3 shots per second, 800 shots per minute, 100 shots = 7.5 seconds of continuous firing.
"i don't know if you made the 100 rounds up celebrim"
I think you've got the wrong man.
Back on topic...
The problem with rapid cycling ammunition consuming weapons is not a bug, nor is it I suspect easily removable from the engine (without raising other problems?). Each time an ammunition consuming weapon fires, it has to update the server with not only the location and vector of the new munition, but it has to inform the server to decrement the record of the ammount of ammunition stored in the ship ((??) otherwise you risk infinite ammo hacks(?)). It's that need to update the record of the ammo storage that creates the problem, because for high rates of fire it creates excessive lag. For now I think we should just assume that a ammunition consuming cycling weapon is impossible.
I would assume that this is the reason the devs have steered away from ammunition based weapons. Some suggestions have been made for ammunition based weapons, including a few with kludgy mechanics designed to 'fix' the problem (such as the flak cannon), but even those raise the spectre of creating a new problem (the need to send the server several new object creation strings virtually simultaneously). Which just goes to show why designing for a game like this is harder than it might at first seem.
I think you've got the wrong man.
Back on topic...
The problem with rapid cycling ammunition consuming weapons is not a bug, nor is it I suspect easily removable from the engine (without raising other problems?). Each time an ammunition consuming weapon fires, it has to update the server with not only the location and vector of the new munition, but it has to inform the server to decrement the record of the ammount of ammunition stored in the ship ((??) otherwise you risk infinite ammo hacks(?)). It's that need to update the record of the ammo storage that creates the problem, because for high rates of fire it creates excessive lag. For now I think we should just assume that a ammunition consuming cycling weapon is impossible.
I would assume that this is the reason the devs have steered away from ammunition based weapons. Some suggestions have been made for ammunition based weapons, including a few with kludgy mechanics designed to 'fix' the problem (such as the flak cannon), but even those raise the spectre of creating a new problem (the need to send the server several new object creation strings virtually simultaneously). Which just goes to show why designing for a game like this is harder than it might at first seem.
I feel Celebrim's response is perhaps overly negative. If this is a serious problem, it has probably already been solved many times in all the other ammunition-based weapon online games out there. I can't imagine that there isn't some easy workaround.
Buffering the record updates and doing consistency checks only periodically rather than on every firing could cut the bandwidth usage back by a lot.
Updating the database only so often (say, requiring an update request/consistency check every certain number of shots and also at a given time interval) and letting the client take care of the detailed ammo count would probably be fine. Ammo that had hit a target or expired, but had not been consistency checked yet would be marked as such, but not removed from the database until cleared by a consistency check. Anyway, I don't know how the system is programmed, so this is pretty speculative. The point is, there are ways to deal with desired actions that would normally spam the server.
Hacked clients could get at most another few shots out of it before the server noticed that they used more ammo than they had. A swift disconnect and 5 minute ban would probably do enough to discourage this, as it would only provide such a tiny temporary advantage that it's hardly worth doing in the first place.
Buffering the record updates and doing consistency checks only periodically rather than on every firing could cut the bandwidth usage back by a lot.
Updating the database only so often (say, requiring an update request/consistency check every certain number of shots and also at a given time interval) and letting the client take care of the detailed ammo count would probably be fine. Ammo that had hit a target or expired, but had not been consistency checked yet would be marked as such, but not removed from the database until cleared by a consistency check. Anyway, I don't know how the system is programmed, so this is pretty speculative. The point is, there are ways to deal with desired actions that would normally spam the server.
Hacked clients could get at most another few shots out of it before the server noticed that they used more ammo than they had. A swift disconnect and 5 minute ban would probably do enough to discourage this, as it would only provide such a tiny temporary advantage that it's hardly worth doing in the first place.
Forgive me if this is a foolish question, but if the server/vendetta app can accurately keep track of how much energy remains aboard the ship, why couldn't it keep track of how much ammo was aboard the ship? The only change I am suggesting is to have the basic gatling consume ammo rather than energy. It's not as though it would be firing rockets, just the same old "energy bolts" like it always has.
Devs?
Devs?
Phaserlight:
The devs said that quickly firing ammo consuming weapons lag the hell out of the server "because they must send a packet for ever shot." I don't understand why this would be drastically different than energy weapons but in the current program it is. I don't know if this is something that the devs have decided is significant to fix at some point. I would suggest that you ask them next time you see them online, because they're not likely to see your question here.
The devs said that quickly firing ammo consuming weapons lag the hell out of the server "because they must send a packet for ever shot." I don't understand why this would be drastically different than energy weapons but in the current program it is. I don't know if this is something that the devs have decided is significant to fix at some point. I would suggest that you ask them next time you see them online, because they're not likely to see your question here.
If it's client side wouldn't that make it even easier to hack?