Forums » Suggestions
Dont know how many there are (looking at the weapons page at vendetta gate). From what i've seen on the list, there arent many projectile weapons... Im sure this has been brought up a million times before, but i couldnt resist ; )
Put in a few more machine guns, cannons, miniguns (drool). Nothing like the smell of gunpowder, a hot smoking barrel, and the crack of a weapon that says "no BS!".
Ofcourse, these types of weapons have obvious limitations. Ammunition for one. Perhaps they could be harder hitting but have a slower muzzle velocity than their energy based counterparts. (making them fairly hard to aim - greater deflection needed). However, they might have less energy requirements to fire. No lazer battery has to be powered with these babies - just old fashioned projectiles here..
Ehh.. for those of you who want to say "but its the future.. only lazers work in space " ect ect... the writers in VO can spin some story about new technologies in projectiles.. being magnetically accelerated and partical charged and compensating dampeners or some futuristic BS. you know what i mean...
Oh yeah. Add choice for ammunition types. Giving the pilot more choices for loadouts. Perhaps variants on missile types. Giving more damage while sacrificing speed/nimbleness. Maybe some missiles are those EMP types which can disable a ship if it has low armor. Maybe a more exotic (but understandably improbable) type which disables an enemy's ability to jump for 10 seconds after a successful hit (scrambles the jump computer, creates a spatial disruption.. ect ect.) WIth ammo, you could have types which have leathality at close range.. Some with damage over time (like burning or radiation).. Some with high explosive (detonation promixity fuse like Flak) which have damage over area. Or maybe EM rounds which give unpredictable results. For lazers, having lense mods. Little pieces of glass over the focus beam which augments its properties. Perhaps one range of the spectrum gives more damage but less range. And vice versa. Okay, that idea was influenced by eve online.. Anyway you get the idea. This, again, opens up more variety for the pilot. The stock standard ammo will be good all round damage givers, but there is also a choice for the thinking pilot who wants to get a particular effect from his weapons
Put in a few more machine guns, cannons, miniguns (drool). Nothing like the smell of gunpowder, a hot smoking barrel, and the crack of a weapon that says "no BS!".
Ofcourse, these types of weapons have obvious limitations. Ammunition for one. Perhaps they could be harder hitting but have a slower muzzle velocity than their energy based counterparts. (making them fairly hard to aim - greater deflection needed). However, they might have less energy requirements to fire. No lazer battery has to be powered with these babies - just old fashioned projectiles here..
Ehh.. for those of you who want to say "but its the future.. only lazers work in space " ect ect... the writers in VO can spin some story about new technologies in projectiles.. being magnetically accelerated and partical charged and compensating dampeners or some futuristic BS. you know what i mean...
Oh yeah. Add choice for ammunition types. Giving the pilot more choices for loadouts. Perhaps variants on missile types. Giving more damage while sacrificing speed/nimbleness. Maybe some missiles are those EMP types which can disable a ship if it has low armor. Maybe a more exotic (but understandably improbable) type which disables an enemy's ability to jump for 10 seconds after a successful hit (scrambles the jump computer, creates a spatial disruption.. ect ect.) WIth ammo, you could have types which have leathality at close range.. Some with damage over time (like burning or radiation).. Some with high explosive (detonation promixity fuse like Flak) which have damage over area. Or maybe EM rounds which give unpredictable results. For lazers, having lense mods. Little pieces of glass over the focus beam which augments its properties. Perhaps one range of the spectrum gives more damage but less range. And vice versa. Okay, that idea was influenced by eve online.. Anyway you get the idea. This, again, opens up more variety for the pilot. The stock standard ammo will be good all round damage givers, but there is also a choice for the thinking pilot who wants to get a particular effect from his weapons
Because ammo weapons generate an additional packet of information every time they are fired compared to non-ammo weapons, the number of ammo based weapons in the game have been reduced to those cases in which the ammunition limitation is actually important.
... gah?
Basically (this is probably a little inaccurate for the sake of simplicity), for people with slower connections, ammo weapons will cause them to lag more than non-ammo weapons because of the additional information that ammo weapons carry (and thus, takes more bandwidth to get that information out quickly).
Yeah. It was real bad when the gatling cannon had ammo.
i imagine it would wreck havok on VO's servers. the bots AI, players syncing with a sector, sending information on player/bot positions, and much more. add ammo to that and.. ouch =x
I don't get it. How can an ammo weapon require a significant increase in bandwidth? Every shot requires something be sent, obviously, but an ammo weapon only has to send an additional integer (shot count or ammo left), right? What else is there that has to be sent that a non-ammo weapon doesn't?
And for that matter, why does anything special have to be sent for ammo weapons? The server knows your weapon load-out and ammo amounts, so why can't it just decrement your ammo when you say that you fired a shot? If a shot gets dropped due to lag, then the server keeps the official account, same as it would if the additional info is sent by a player.
I'm obviously missing something here. Someone enlighten me. =P
And for that matter, why does anything special have to be sent for ammo weapons? The server knows your weapon load-out and ammo amounts, so why can't it just decrement your ammo when you say that you fired a shot? If a shot gets dropped due to lag, then the server keeps the official account, same as it would if the additional info is sent by a player.
I'm obviously missing something here. Someone enlighten me. =P
Ammo based weapons with low repeats dont cause a problem. Something like the following COULD be added
Gun
S-port
Damage 300
Speed 200
Repeat .4 seconds
Ammo 100
Its when you get into weapons like a minigun, machine guns etc that the game has problems. Each "shot" is tracked seperately, so a gun that fires 50 shots per second causes a lot more lag than a gun that fires 2 shots per second. Additionally keeping track of how many rounds a gun has fired takes an additional calculation per shot. Once again, causing slowdown.
Gun
S-port
Damage 300
Speed 200
Repeat .4 seconds
Ammo 100
Its when you get into weapons like a minigun, machine guns etc that the game has problems. Each "shot" is tracked seperately, so a gun that fires 50 shots per second causes a lot more lag than a gun that fires 2 shots per second. Additionally keeping track of how many rounds a gun has fired takes an additional calculation per shot. Once again, causing slowdown.
okay a little confused on that point. 50 rounds per second is fairly extreme. I could see that being a slight problem. But nothing insurmountable with the crew of talented programmers we have ; )
A more conservative figure would be an alternative. Like, have the gun fire at 10-12 times per second so that its info is still acceptable (a little more than the fastest energy weapon). The texture model for the "bullet" would look like a streak of 10 bullets, and with a rapid firing noises.... could be pulled off without being too insulting to bandwidth. It would still retain its rapid firing properties (and appearance) without actually sending 50 objects per second out in to the universe.
Heck, am i the only one who think gattling guns and cannons are cool? : )
A more conservative figure would be an alternative. Like, have the gun fire at 10-12 times per second so that its info is still acceptable (a little more than the fastest energy weapon). The texture model for the "bullet" would look like a streak of 10 bullets, and with a rapid firing noises.... could be pulled off without being too insulting to bandwidth. It would still retain its rapid firing properties (and appearance) without actually sending 50 objects per second out in to the universe.
Heck, am i the only one who think gattling guns and cannons are cool? : )
Ok, its fairly obvious that every time a weapon is fired it has to send a packet announcing the creation of a particular munition type with a certain vector.
Testing has shown that weapons which fire more than 15 times per second cause significant lag. To ensure good performance, the devs seem to prefer to keep fire rates down to between 6-10 times per second for most weapons.
When ammunition weapons are fired, it has to send an additional packet announcing that ammunition for a particular player on a particular ship has been decremented.
My guess is that an ammuntion based weapon probably can't cycle more than about 3 times per second without causing significant lag. One 'solution' I proposed a while back was the idea of 'bursts' where each ammo corresponded to multiple shots. However, that has the problem of generating large numbers of new objects. Since the original proposal for 'bursts' was tied to the original proposal for what is now the flechette cannon, and the flechette cannon was introduced without either ammo or bursts, I think its safe to say that devs did not find the proposed solution workable.
Testing has shown that weapons which fire more than 15 times per second cause significant lag. To ensure good performance, the devs seem to prefer to keep fire rates down to between 6-10 times per second for most weapons.
When ammunition weapons are fired, it has to send an additional packet announcing that ammunition for a particular player on a particular ship has been decremented.
My guess is that an ammuntion based weapon probably can't cycle more than about 3 times per second without causing significant lag. One 'solution' I proposed a while back was the idea of 'bursts' where each ammo corresponded to multiple shots. However, that has the problem of generating large numbers of new objects. Since the original proposal for 'bursts' was tied to the original proposal for what is now the flechette cannon, and the flechette cannon was introduced without either ammo or bursts, I think its safe to say that devs did not find the proposed solution workable.
Damn. I was in the process of coming up with the exact same idea, Celebrim, and then I read your post. Too bad it won't work, ey?
What about a slower multishot ammo, though?
Something that, say, fires 3 shots at .3 second intervals per round?
This way you could make the ammo relatively sparse, but still have a weapon that would be very powerful if one could keep one's crosshairs in the sweet spot for that period of time.
It would allow the gun to have some statistical advantages(better damage/speed, lower weight, more overall shots), but make using it effectively extremely difficult.
What about a slower multishot ammo, though?
Something that, say, fires 3 shots at .3 second intervals per round?
This way you could make the ammo relatively sparse, but still have a weapon that would be very powerful if one could keep one's crosshairs in the sweet spot for that period of time.
It would allow the gun to have some statistical advantages(better damage/speed, lower weight, more overall shots), but make using it effectively extremely difficult.
Again, I ask why the client needs to announce its ammo count.. Doesn't the server have the weapon information for every ship? How hard is it to decrement an integer? Not trying to be sarcastic really, but I just don't get why there's any difference between ammo weapons and non-ammo weapons. Even if they do send ammo-related packets (you sound like it's definite, Celebrim, and I believe you), is it really necessary?
I understand why high-rate weapons aren't feasible, but not why ammo-based weapons are any less practical.
I understand why high-rate weapons aren't feasible, but not why ammo-based weapons are any less practical.
why ammo based weapons arent practical, well for starters theres the deep space recoil problem. Imparting enough force to propel a projectile in a specific direction results in a "kick" in the opposite direction.
Ok, on second though, who gives a flying fart about that.
The main reason that an ammo based weapon isnt overly feasable is because even if it fired at the same rate as the gauss cannon and did half the damage, you would need to carry several hundred rounds of ammo to make it a practical weapon, ammo which would logically take up more space than a weapons port IMO has.
Any less ammo than that and you run a very significant risk of running out of ammo in the fight. Whats the use of carrying a gun that does half the damage and can run out of ammo in a standup fight when you can take a comparable energy weapon and never have to worry about ammo.
Projectile weapons would HAVE to do either less damage or travel less swiftly in order to be balanced, otherwise the ability to turbo while firing them would make them far too dangerous.
Ok, on second though, who gives a flying fart about that.
The main reason that an ammo based weapon isnt overly feasable is because even if it fired at the same rate as the gauss cannon and did half the damage, you would need to carry several hundred rounds of ammo to make it a practical weapon, ammo which would logically take up more space than a weapons port IMO has.
Any less ammo than that and you run a very significant risk of running out of ammo in the fight. Whats the use of carrying a gun that does half the damage and can run out of ammo in a standup fight when you can take a comparable energy weapon and never have to worry about ammo.
Projectile weapons would HAVE to do either less damage or travel less swiftly in order to be balanced, otherwise the ability to turbo while firing them would make them far too dangerous.
no no, why are they impractical from a network/server perspective. I know it's explainable with pseudo-science - everything is. And I know there are gameplay implications, but why is it claimed to be not as bandwidth-efficient?
Celebrim posted the reason why
"When ammunition weapons are fired, it has to send an additional packet announcing that ammunition for a particular player on a particular ship has been decremented."
As to why the server and the client both need to keep track of how much ammo is there, its an error checking /anti-cheating thing. Basically for every shot you fire with an ammo based weapon, you are sending twice the data to and from the server, which makes it less bandwidth efficient.
"When ammunition weapons are fired, it has to send an additional packet announcing that ammunition for a particular player on a particular ship has been decremented."
As to why the server and the client both need to keep track of how much ammo is there, its an error checking /anti-cheating thing. Basically for every shot you fire with an ammo based weapon, you are sending twice the data to and from the server, which makes it less bandwidth efficient.
Simple: cheating.
the server -and- clients need to be in sync with the ammo count.
The client sends a "shoot" request. the server counters with a "you have ammo, shoot" response. This has to be done fairly regular, or you'll have a state of desynch between server and client (remember, its a stateless protocol and packets can be lost) Where the client sends more "shoot" requests than the server knows that ship had.
Add this up on three hornets in a sector, and you suddenly have 12 items going around and causing counters to increment and decrement in a fast way.
Now make sure that all players within range get sent a notice for every of theese shots, so they can draw them and make the effects.
This counts for a LOT of bandwidth to be generated by the server and clients, and will more or less hog down slower connections, cause latency and glitches.
This is probably not the exact description, but ought to be a fairly accurate one of how counters work ;)
the server -and- clients need to be in sync with the ammo count.
The client sends a "shoot" request. the server counters with a "you have ammo, shoot" response. This has to be done fairly regular, or you'll have a state of desynch between server and client (remember, its a stateless protocol and packets can be lost) Where the client sends more "shoot" requests than the server knows that ship had.
Add this up on three hornets in a sector, and you suddenly have 12 items going around and causing counters to increment and decrement in a fast way.
Now make sure that all players within range get sent a notice for every of theese shots, so they can draw them and make the effects.
This counts for a LOT of bandwidth to be generated by the server and clients, and will more or less hog down slower connections, cause latency and glitches.
This is probably not the exact description, but ought to be a fairly accurate one of how counters work ;)
And, once again, I ask why this is necessary. A cheating client sends a fraudulent shoot notice, and the server just chooses not to acknowledge it. So if anything happens because of that shot, the server never tells anyone about it, so it basically never happens. No other clients render the shot, and no damage occurs because of it.
If you cut out the query/response cycles, and just let the client "ask" to shoot, the server can decide if it's valid or not, and any cheating clients will be ignored (or kicked if repeat offenses are detected). Then, the only time it takes to shoot is the time it takes your "shoot request" to get to the server and back to other clients. So with a third of the traffic going across the pipe, 3x more shots can be fired without lag.
Am I still missing something?
If you cut out the query/response cycles, and just let the client "ask" to shoot, the server can decide if it's valid or not, and any cheating clients will be ignored (or kicked if repeat offenses are detected). Then, the only time it takes to shoot is the time it takes your "shoot request" to get to the server and back to other clients. So with a third of the traffic going across the pipe, 3x more shots can be fired without lag.
Am I still missing something?
yes, and the funny part is you mention it in your own post.
"And, once again, I ask why this is necessary. A cheating client sends a fraudulent shoot notice, and the server just chooses not to acknowledge it. "
How does the server know the client is out of ammo unless the client has sent a "shots fired, ammo used" packet for each round. Thats 2 pieces of information, as opposed to a "shots fired" packet for energy weapons.
Even if the server were to process the ammo count based on how many "shots fired" packets that it recieves to lower your ammo count, thats still another process the sector daemon has to do, so its still using double the server resources for each shot.
"And, once again, I ask why this is necessary. A cheating client sends a fraudulent shoot notice, and the server just chooses not to acknowledge it. "
How does the server know the client is out of ammo unless the client has sent a "shots fired, ammo used" packet for each round. Thats 2 pieces of information, as opposed to a "shots fired" packet for energy weapons.
Even if the server were to process the ammo count based on how many "shots fired" packets that it recieves to lower your ammo count, thats still another process the sector daemon has to do, so its still using double the server resources for each shot.
Because the server knows how much ammo you have!!!
Is this seriously that hard to understand? The server knows what guns you have, and how many times you've shot, so why the heck can't all the ammo info be stored server side??
I've tried to be patient, but this is just silly now. What would be so bad about having the server keep track of peoples' ammo and verifying each shot request? Certainly it's not storage - that's like 2-3 integers per client. It's not complexity - just a few lookups and decrements. It doesn't nearly double the sector daemon's tasks per shot. This is nothing compared to trajectory plotting and collision detection. This is lookup and subtraction.
Am I losing my mind?
Edit: And it seems equally funny to me. If we've established that a client is cheating, what's to stop them from forging the ammo-left packet? It seems to me that server-side is the only way to ensure that nobody is cheating or exploiting lag.
Is this seriously that hard to understand? The server knows what guns you have, and how many times you've shot, so why the heck can't all the ammo info be stored server side??
I've tried to be patient, but this is just silly now. What would be so bad about having the server keep track of peoples' ammo and verifying each shot request? Certainly it's not storage - that's like 2-3 integers per client. It's not complexity - just a few lookups and decrements. It doesn't nearly double the sector daemon's tasks per shot. This is nothing compared to trajectory plotting and collision detection. This is lookup and subtraction.
Am I losing my mind?
Edit: And it seems equally funny to me. If we've established that a client is cheating, what's to stop them from forging the ammo-left packet? It seems to me that server-side is the only way to ensure that nobody is cheating or exploiting lag.
Unless the server and the client track ammo expenditure completely seperately, which could lead to different counts due to packet loss, EACH TIME THE AMMO COUNT CHANGES, THE SERVER HAS TO CHECK WITH THE CLIENT TO MAKE SURE THE COUNTS ARE THE SAME. It doesnt matter where the tracking is done. To make sure that the server and the client agree on how much ammo your ship has, an extra packet has to be exchanged.
If its tracked clientside, the client tells the server "I fired a shot" "I used an ammo", the server replys, "draw this shot GFX"
Even if everything is tracked serverside. I tell the server "i fired a shot", it knows what i have on my ship so it calculates the ammo loss and returns a "draw this shot GFX" and a "decrease ammo count on client screen" message, its still 2 packets.
If its tracked clientside, the client tells the server "I fired a shot" "I used an ammo", the server replys, "draw this shot GFX"
Even if everything is tracked serverside. I tell the server "i fired a shot", it knows what i have on my ship so it calculates the ammo loss and returns a "draw this shot GFX" and a "decrease ammo count on client screen" message, its still 2 packets.