A new series of weapons that are ammo based. Most likely has been suggested before, can’t imagine why it wouldn’t have been. Different small and large weapons that fire like neutrons or posi’s and take little or no energy. Only downfall is that ammo is limited. Maybe make a unique one for UIT like neutron III is for itani and serco. And… go!

...

Uh, the Devs originally wanted the Gatling Canon to be ammunition-based, but found that the server-client connection isn't fast enough to check fast-firing ammo weapons.

Also, the weapon you are describing sounds much like an existing one: The Railgun. True, it eats a great deal of power, instead of little to none, but it is an ammuntion-based weapon that behaves like a Neutron Canon or Positron Blaster (albiet, with a much longer range).

Curse you, server-client connections!

Now is the time we start peppering our scientists with suggestions to make faster internets!

In order to keep VO twitch and allow for high-speed, intense engagements, the game engine was designed to minimize packets sent in order to reduce latency and improve speed and precision. If rapid-fire ammunition-based weapons were introduced to the game, the server would have to check on the client after each shot is fired to insure that the client hasn't been hacked to cheat on ammo. Since this would create a large overhead (the client and server talking back and forth about ammo levels after every shot), it would slow down the network and create lag that would make it difficult to impossible to maintain a game model where fast firefights and intense action are the norm.

So the only reason is to check that the client hasn't been hacked? And if you can hack the number of ammo, can't you hack other stuff like firing rate? If so then doesn't that have the same lag associated complications?

Eh, that's checked I think.

If so then doesn't that have the same lag associated complications?

Right. That's why BS tends to lag more than other sectors. That's why sometimes your shots don't count even though they splashed across your target's windshield.

It does, but by adding ammo, you're effectively doubling the amount of checking done, and hence the lag.

It seems like the way to do this would be to have it rapidly fire, say 10 shots in a very short time, and then a cooldown of say a second. with an ammo load of, say 50 you've effectively got a rapid fire gun that has 500 bullets. Sort of.

Of course, that's already been mentioned here.

I don't see why this would double the checking time. It's not like you can reload out of a station.

* The server knows how many bullets you have onboard when you leave the station.
* Each bullet must be sent to the server anyway.

Just reduce the server side counter representing the players bullets. If it hits 0 and another bullet is received, well there be some hackin goin on.

Nothing extra needs to be sent as far as I can see. Rate of fire is a different issue.

The server would have to check how much ammo you have every time you fire. Each time you fired, it would have to then modify that amount. Try rapidly firing repair modules.

This having been discussed before, I think I remember that it would be possible to make the weapons have a finite ammunition count of the type int, but you would not have to have single projectiles, but instead make them behave like energy shots (I suppose that is what is being done with the rail gun already), sort of a 'ray' that is either on the target or not in the specific time window.

This only deals with the problem of the vectorial representation of the shots, however. The ammo count check would remain.

Proton: while this may be a useful temporary solution, it would limit the potential for future developments such as mid-flight rearming, etc, so it's really not a solution.

As for the whole multiple-fire volley count, it's been suggested LONG before that thread... heck, I was in on that when it came up, though I don't recall if the devs had anything to say about it.

How does a game like Quake/HL2 deal with this issue? Seeing as they are twitch based and also have rapid fire weapons.

They do not have centralised servers, I think, but distributed ones.

Umm, making ammo-based weapons isn't a problem. At least, that I know of. We don't have many examples of that, beyond the railgun and the repair-gun and so on. It might be a problem for high cyclic rate stuff. Honestly, I don't remember why we did or did not make the gatling turret use ammo.. that was like a hundred years ago. Maybe it was the ammo checking thing, that's possible, although that would have been kind of a dumb reason (but, we do lots of things for dumb reasons if the solution takes too much time to implement and isn't really important enough). The whole game has evolved so much, since then, that some reasons for why certain things were done.. no longer exist (equally, some still do, and my memory is often foggy). Anyway, as far as I can recall, there's no reason to not make ammo-based weapons, at least within the firing rate of most energy weapons.

Also, BS does not get slow and laggy because of ammo checks or anything like that. There are two problems: 1) Very large numbers of object-adds (lasers being shot) and object-updates (people, NPCs, and guided missiles flying around) can eventually become a load for people with reduced bandwidth capacity. 2) Simulating collision response and physics on the server currently kind of sucks.. this means, certain conditions where several capships are flying through an asteroid field, while getting shot with a gazillion lasers, can end up actually crunching that cluster machine a bit. We have a bunch of options for how to solve that, the simplest of which is just to reduce the complexity of the capship collision hulls (with minor gameplay repercussions). Plus, more complex options like using collision primitives.. but anyway, right now Andy & Co are busy on Kourier, so we'll have to wait until he's done with that project. It also doesn't help that the capships are all kind of idiots right now (and tend to run into things), and the Kourier work will hopefully make that area easier to improve.

For the record, Quake and games like it use totally centralized servers that check every single little thing when it happens. Back when quake..2? came out it was a really big deal that iD had a 64 player server, and in order to offer that they had to buy a 400mhz Alpha, which was about the fastest available computer at the time. This was because of the load of simulating 64 people playing the game at one, and checking everything they did. The whole "server simulates every little thing you do to make sure it's ok" is a viable architecture, as long as you don't expect your userload to scale very much.. although it can also suck if your latency is poor. We had to make something that would scale, so we went with "we'll let the client do whatever it wants, but then bounds-check it within certain sanity boundaries that are much easier and faster to check". Doing "ballpark" checks is a hell of a lot faster than actually simulating everything the person does. It doesn't outright prevent cheating, but it prevents cheating in any very useful ways, and lets us know who is cheating.

Hey there's an idea. Give the gat turret ammo and leave the gat cannon an energy weapon.

i like it... proms could run out of agt ammo... no more spray and pray?

If you have ammo for these guns it opens more doors... such as explosive rounds or high velocity rounds... ect.

Yes, actually, I now have a "Cannon" weapon type available to me. It's a relatively recent addition, and so far is only used for the capship turrets and the station defense turrets. But it allows me to put both splash damage and an area-effect "push" (a-la concussion mines) on impact. Pretty cool. I intend it to appear on lower-level weapons in due course, but I'll need to do some more experimentation.