High Velocity Rates of Fire...

[Canalien 0]

Hi there,

something that's always bugged me about ArmA (I think this was also an issue back OFP as far as I remember) is the way that high velocity rates of fire are 'simulated' or more appropriately... cheated.

Take the Vulcan on on the VADS for instance: when firing the smallest possible amount at once (1 projectile) the ammo count drops 6 at a time. I believe this may have been a leftover from BIS' original 'laser' tracers which lit up every round... by dropping the count 6 times and only seeing 1 tracer (because, really, only 1 round is being fire) an intermittent tracer load is somewhat simulated. The same goes with the Shilka; ammo count drop on the smalelst burst possible is much higher than the amount of projectiles that actually leave the barrel.

Now that we have wonderful toys like SIX tracers which actually can fire intermittently, this original 'cheat' is really obvious visually and the fact that, for example, the Vulcan on the VADS really only has 350 rounds in it for the supposed 2100 is atrocious. It seems to be the case across all high velocity guns in the game; the majority of the rounds supposedly being fired are disappearing into thin air.

Any thoughts on ways of rectifying this?

[max power 21]

The reason is for that behaviour is so the engine doesn't have to simulate so many bullets. Instead of simulating 3000 bullets every minute, they will simulate 500, and multiply each bullet's damage 6x, and take away 6 bullets every time you fire.

[Col. Faulkner 0]

If you really have to change it it can most easily be done

by editing the configuration for the "M163" object in

"weapons.pbo"; remove "multiplier = 6" and add a "burst = 1"

attribute.

[Canalien 0]

thanks

[Canalien 0]

i really don't know much about scripting, but is it possible to make up a little config.cpp (?) that would alter the appropriate lines in weapons.pbo insteaod trying to mess with it itself?

[Serclaes 0]

Your ROF is decided by your framerate. You can't fire more bullets than frames in a second. Hence the necessity of a multiplier and the lower ROF

[Canalien 0]

that doesn't sound right to me... by that logic the maximum rate of fire in the game is 60 bullets per second. even rifles fire faster than that and they don't use multipliers.

[PuH 0]

uhm, 60 rounds per second means it fires at 3600 rpm, i'd love to see that rifle. but its in the range where it might cuse problems for a weapon that fires 2-4000 rpm and thats with 60 fps constant, now imagine a few drops in fps and you see why they cut down on the number of rounds.

[Col. Faulkner 0]

To answer "Canalien"; yes, you could make your own subclass

of the VADS unit with a custom config.cpp. I suggest you

post an enquiry in the configs and scripting part of this forum

for assistance with that.

In any case, at 3,000 rpm the shortest burst you can fire

with the real VADS system is 10 rounds. VADS also supports

a continuous fire mode of 1,000 rpm. It'd be easy enough to

support both of those modes in the game (no idea how the

stupid AI would handle it though).

[Canalien 0]

uhm, 60 rounds per second means it fires at 3600 rpm, i'd love to see that rifle. but its in the range where it might cuse problems for a weapon that fires 2-4000 rpm and thats with 60 fps constant, now imagine a few drops in fps and you see why they cut down on the number of rounds.

yeah typo... should have read 60 rounds per minute

[Canalien 0]

to be honest i'm not really concerned about fps drops.

i just want to have the option of having the weapons set up realistically.

[dm 9]

to be honest i'm not really concerned about fps drops.

The point is, without those fps you WONT get the rate of fire.

Like Serclaes said, rate of fire is directly tied to frames per second.

Rifles, machineguns and so on will be fine, but miniguns and gatling guns (in the 2-6000 rpm range) will have issues.

[max power 21]

uhm, 60 rounds per second means it fires at 3600 rpm, i'd love to see that rifle. but its in the range where it might cuse problems for a weapon that fires 2-4000 rpm and thats with 60 fps constant, now imagine a few drops in fps and you see why they cut down on the number of rounds.

yeah typo... should have read 60 rounds per minute

you were right the first time. 60 frames per minute would be 1 frame per second. That would be aaaagonnnyyy to play. 60 hz, being the basic refresh rate of most monitors at high res, is 60 frames per second. The maximum ROF at that refresh rate, given vsync, would be 3,600 rpm.

[Uziyahu--IDF 0]

The reason this was done in OFP was because firing an MG42, for example, LAGGED the game.

Also, there was a bug (it was supposed to have been fixed in ArmA...was it not?) in OFP that tied your weapon's cyclic rate to your frame rate or CPU cycles or some such. You could actually see your weapon's cyclic rate slow down as you swung your view to more complex scenes on the compass, whereas in a game like Rogue Spear, your cyclic rate was independent of frame rate.

What I believe B.I. tried to do was to provide a round that had the destructive power of that round and all of the rounds that should have been fired. That's why the Cobra's minigun in OFP fires explosive rounds (when a round is given a high enough damage value in OFP, it turns explosive, from what I understand, as was the case with one fellow's Barrett .50 addon, even when it wasn't firing the special explosive ammo).

[dm 9]

Also, there was a bug (it was supposed to have been fixed in ArmA...was it not?) in OFP that tied your weapon's cyclic rate to your frame rate or CPU cycles or some such.

Not a bug, but the way the simulation (i.e. the engine) works. Some simulations tie into the fps (like OFP, ArmA and so on), some tie into the CPU cycle, and others run to a fixed frequency (usually between 20 and 60 Hz)

when a round is given a high enough damage value in OFP, it turns explosive, from what I understand, as was the case with one fellow's Barrett .50 addon, even when it wasn't firing the special explosive ammo

Also not true. There is an independant config value which causes ammo to be explosive or not.

[Uziyahu--IDF 0]

Not a bug, but the way the simulation (i.e. the engine) works.

Sorry, but Ondrej fixed it, thus it was a bug. I really can't say more, IF YOU KNOW WHAT I MEAN.

How you could call a variable weapon cyclic rate proportional to frame rate (thus, on-screen poly-count) anything other than a BUG, you'll never be able to explain to me, given that the goal was to create a realistic infantry simulation. The simulation DID NOT work. It failed to simulate, thus it was a BUG. Please list for me what other half-decent tac-shooters did this, because I can't think of a single one.

As for the explosive rounds, that was the way it was explained to me by the kid who made the Barrett Light .50 with explosive rounds. I'm relying on an oral tradition. Thanks for the correction.

Bottom line is that B.I. made up for the poor cyclic rate on the mini-gun by making the rounds more powerful.

[dm 9]

Not a bug, but the way the simulation (i.e. the engine) works.

Sorry, but Ondrej fixed it, thus it was a bug. I really can't say more, IF YOU KNOW WHAT I MEAN.

How you could call a variable weapon cyclic rate proportional to frame rate (thus, on-screen poly-count) anything other than a BUG, you'll never be able to explain to me, given that the goal was to create a realistic infantry simulation. The simulation DID NOT work. It failed to simulate, thus it was a BUG. Please list for me what other half-decent tac-shooters did this, because I can't think of a single one.

Well, since I cant find any reference to this "fix" in the changelogs, and the rate of fire is still FPS-DEPENDANT I'd say it was still a "feature."

And no, its not a bug, just because you want to call it a bug, doesnt mean it is one.

Like I said, some simulations run accoding to CPU speed (see old DOS games that run at lightspeed when played on a modern CPU), some simulations run according to a fixed frequency (between 20-60Hz) and others run according to the refresh rate (i.e. fps) achievable (why simulate things you're not going to see). OFP and ArmA are of the latter group, as are a lot of games.

Bottom line is that B.I. made up for the poor cyclic rate on the mini-gun by making the rounds more powerful.

Yup, not denying that.

[Uziyahu--IDF 0]

Then it didn't get fixed, after all, which was my original question.

As for the changelog, there ARE numbers less than 1.00, and "that's all I'm going to say about that".

What are these "lot of games"? Like I said, I can't remember a single half-decent tactical-FPS other than OFP/ArmA that used this unrealistic method. If you close your eyes in real-life, does your weapon stop shooting? A weapon's cyclic rate isn't dependent on what a person sees, so it should never be coded that way.

Why in the world would you have a weapon's cyclic rate, something IDEALLY dependent on physics calculations, waiting on a freaking VIDEO CARD?

Do you realize that the rounds aren't being fired? Look at the ammo count. It's not just that they aren't being "seen". Furthermore, because the gunshot sound effect is tied to real-time cyclic rate, you can actually HEAR the weapon slow down.

It's no "feature". It's a deficiency in the simulation. For the monosyllabic, that = "BUG".

This "feature" is so lacking from the tactical-FPS genre that when I saw it in OFP:CWC it GLARED at me. I've been preaching against it ever since.

"Excuse me, Mr. Graphics-Intensive Level Boss, while my weapon pauses for you to display your awesomeness!"

Don't misinterpret what I'm saying. The Spanel Brothers are geniuses, but this bug has been bugging me since I noticed it.

[dm 9]

What are these "lot of games"? Like I said, I can't remember a single half-decent tactical-FPS other than OFP/ArmA that used this unrealistic method.

Sadly, there isnt a handy-dandy list (that I can find) which lists the simulation type of each and every game out there.

If you close your eyes in real-life, does your weapon stop shooting? A weapon's cyclic rate isn't dependent on what a person sees, so it should never be coded that way.

No, you dont, but unfortunately PC's dont work that way.

Why in the world would you have a weapon's cyclic rate, something IDEALLY dependent on physics calculations, waiting on a freaking VIDEO CARD?

Because it was the best and most reliable way to do it at the time? Because it was the easiest way to do it at the time? Because it was the most cost effective way to do it at the time? Because it was the most effective way of using the hardware at the time? Because the Spanels didnt know any other way at the time? Because the Spanels didnt know any better at the time? Take your pick... The real answer might not even be in there...

Do you realize that the rounds aren't being fired? Look at the ammo count. It's not just that they aren't being "seen". Furthermore, because the gunshot sound effect is tied to real-time cyclic rate, you can actually HEAR the weapon slow down.

Yes, and I'm pretty sure I know a lot more about what is going on "behind the scenes" when this occurs. I'm not saying its the best way to do it, I am saying its the way its done tho.

It's no "feature". It's a deficiency in the simulation. For the monosyllabic, that = "BUG".

Like I said last time, just because you want to call it a bug, does NOT make it a bug. It is a feature of the way the simulation is coded. Once again, NOT A BUG.

This "feature" is so lacking from the tactical-FPS genre that when I saw it in OFP:CWC it GLARED at me. I've been preaching against it ever since...

...Don't misinterpret what I'm saying. The Spanel Brothers are geniuses, but this bug has been bugging me since I noticed it.

Thats good for you. There is a ton of other (some might say more important) stuff that would benefit from a change of simulation timing to a fixed frequency, rather than fps dependant. But that would not only require a re-coding of almost the entire engine (since ALL calculations are handled in this way), it would also require a massive rework of the configuration files to re-balance everything. Its not a simple fix.

[max power 21]

The frame rate of the simulation is not only dependent on the video card.  The cpu also calculates the simulation in frames, etc, and all of these systems have to be coordinated.  Just assume that there is nothing happening between frames.  I think this is more often than not true.  It's not the graphical frame rate that the rate of fire is dependent on, I don't think, it's the frame rate of the simulation.  I think that the frame rate of the simulation is dependent on a lot of different factors, and that the graphical frame rate and the frame rate of the simulation is highly corelated. I think that the only time there is something happening between frames is during server-client desync.

[chammy 7]

Not sure if its been mentioned but even the 35mm cannon off the BMP has the same problem.