[COMPLETED 0.78.0] Weapons Innacuracy

[ZenBudha]

Ok not to harp or anything but this is a major feature lacking that to me seems like one of the easier features to be implemented. I could be wrong as I am no programmer but I would think it would basically involve giving the gun firing code a random rotation variable. Or even better a progressive random rotation variable. That is able to be called from the Weapon.ini

I think I've also realized that programmers don't like vague ideas on things. Like "I want X!" So here is what I believe we need to have a truly fully functional weapons system in RF.

We need something like 3 new values in the weapon.ini
Something along the lines of...
Saccuracy = X
Eaccurcy = Y
ProjNumber = Z

The first one stands for starting accuracy. Which for example set to "0.0" would be a laer gun like we have now. The second one is the ending accuracy or the maximum amount of innacuracy. The third is to tell it how many projectiles to fire each shot.

I'm not sure what the weapons code looks like but basically it needs to generate a random angle offset progessively starting with the Saccuracy and progressing to the Eaccuracy.

Perhaps a fourth variable is need to tell it the size of the progression. So lets say it looks like this...

Saccuracy = 0.0
Eaccuracy = 2.4
Progression = 0.4
ProjNumber = 1

So the code will start with an offset of "0.0" and then on the next loop it will be 0.0 + 0.4 + random rotation. So it will angle the projectile 0.4 degree's and then apply a random rotation out of 360 degree's. Sort of like offsetting the firebone at and angle along the Y plane and then applying a random amount of rotation along the Z plane. I hope that makes sense.

So basically as long as the trigger is being held down. Each loop will be the previous Saccuracy + Progression. Untill that is equal to or greater than the Eaccuracy. At which point the angle offset will stay 2.4 with a random rotation of the firebone along the Z plane. Relative to the bone of course.

So for a shotgun it may be...

Saccuracy = 2.4
Eaccuracy = 2.4
Progression = 0.0
ProjNumber = 8

Which should tell it to fire 8 projectiles with an angle offset of 2.4 degree's and a random Z rotation of the firebone for each projectile.

Or perhaps the shotgun needs it's own segment of code since having more than 1 projectile could complicate things too much.

This will be far from Rainbow 6 innacauracy. However it will still allow for decent and simple weapon innacuracy setup.
Which plays a huge role in game balance. Which is the player needing to decide to use the right weapons in the right situation.
He should not be sniping people with a chaingun, or an uzi for that matter.

I don't know if this helps any or not. And I know the programmers are always and already busy with other tasks. However to me a fundamental element should take at least some priority.

This is not just for me either as it will benefit anyone creating a game in RF that does not involve swinging a sword or throwing spells. Heck RF guns are more accurate than laser guns in other games. Fact is if it's a gun and it shoots. Whether your working on a Rainbow Siz type of shooter or a Quake type of shooter. It's just a necessary feature.

I'm not trying to tell anyone to drop what they're doing. Just consider it for your next task when your done with what you are currently working on.

[MakerOfGames]

This is very possible if you choose to use a scripted player and a multi-object player. The arms and guns are separte from the main actor. The gun attaches itself to the hand of the arm. Then the arm is told to rotate in a certain pattern or randomly when the fire button is pressed. Since the gun can be made to always be rotated the same way as the arm it will create inaccurate shots. The distance the arm rotates in all directions would change the inaccuracy. The larger the distance to rotate, the more inaccurate the shots.

THIS IS ALL IN THEORY. I have not tested it, but I think that would work. But if you are not the programming type, RF should have a feature built in for this kind of thing. But if you are using a solid actor or the animated floating arms trick, I am not sure how you would do this.

Basicly, you can do this in RF now, but it requires alot of extra effort.

[ZenBudha]

Well I spent a lot of time attempting to use a pawn for scripted weapons. However due to alignment and rotation problems this never worked out.

It worked so long as you didn't look up or down. Ideally it would be as simple as attaching the arm, and gun to the camera. However like I said you run in to vertical rotation problems with it just like you do with the flashlight.

Last I heard it required two pawns to get one of them rotating correctly with the camera. Which sounds 1000 times easier than it is.

With the varible method I showed above would allow anyone to modify the weapon.ini for whatever weapon they were using. So no need to write scripts for 10 different weapon pawns or 20 if you are using the two pawn method.

Also programmers dont have to write code for 10 different types of weapons. They all the same except the damage, accuracy, ammo, etc. Are all adjusted by the weapons.ini

Aside from the problems that might arise with shotguns that may require a different piece of code altogether.

[federico]

In my S:I:M:O:N demo, never made public, I used a script that "switch" between weapon mode. Normal, Auto-target, Aim. My idea was to use the auto target mode and regulate the fire accurancy with the self.ThinkTime command. Another idea, still unmade, was to replicate the breathe/aim/panzemina system of Metal Gear. Pratically force the camera to tilt-changeyaw randomly within a fixed range and use a keep-breathe key to reduce that interference to have a accurate aim (naturally the oxigen could finish and again increment)...
I hope this can help

[ZenBudha]

I have one PITA method I have thought up to get it to work right.

I'm not even talking about innaccuracy that I know can be scripted. I'm talking about just getting a pawn/weapon to maintain proper alignment with the camera.

Which to my knowledge has never ever been done. The flashlight doesn't work because of this axis problem it just shines one direction. In the old version it just looked left and right whenever you looked up or down.

If it wasn't for that a scripted weapon would be feasable. However because of it a scripted weapon in first person view is not feasable.

So the task is to clarify and I invite anyone who wants to try to figure out this as well...

How to make a scripted pawn weapon maintain proper alignment with the camera in a first person perspective.

Truth is this is a ton of hassle for a feature that has been present in every FPS game since before FPS went true 3D.

I remember reading a tutorial for weapons innacuracy somewhere a long while back when I was first looking at engines. If I recall it was about 15 lines of code total.

[ZenBudha]

Progress so far...

I cannot get the pawn to attach itself to the player. According to the script manual I am using the right command with

PlayerToPosition(0, 0, 0, true, true)

Which should position the pawn to the players location with no offset and match at a minimum the players rotation.

Strange enough though I had also attach a dynamic spotlight to the pawn.

Which acted as if though attached to the player. Although it only pointed in one direction.
Meanwhile the pawns body wasn't moving an inch and just sitting there off to the side where it spawned.

Also tried attaching a dynamic spotlight directly to the player and setting it's rotation to True. This seemed to attach the spotlight to the player however the ony rotation it matched was the players initial starting facing direction.

So a couple of hours of fiddling with no luck. Also the dynami spotlight had a weird flickering effect. Checked it's values and there was nothing there to cause it. It's not really an issue. Probably just a result of being attached to a moving object or something.

[AndyCR]

try my scripted flashlight code posted in the scripting forum, i dont recall if it worked with all angles, i believe it actually did, and if yiu remove the code to attach itself to the wall infront of the player and the code to make it invisible, it should work for you.

[ZenBudha]

Ok gave it a go but it doesn't match all angles.

Would work for like a shoulder mounted flashlight in a game. But when the player looks up or down it just stays straight ahead.

Much better than the old one that swings left and right when you look up and down though.

I will try to build off it to solve the look up and down problem. However I can't find any script that reads the camera angle. Therefor I have no clue how to tell it to match that angle since the player does not actually rotate up or down.

[GD1]

honestly, I dont think you can do this in first person. I tried for a long time, and it never worked.

BUT, in Pickle's OGRE demo, he used a similar system, and it worked. But it was in third person. If you could position the camera correctly and set playerrender(false); you might be able to get the rotation working in third person and fake that the perspective was first person. The only sacrifice would be weapon reloading, since that doesn't work in third person, but you could probably script that as well, along with the innacuracy.

[Guest]

The easy solution is to just attach a invisible pawn to the Firebone01 of the players first person weapon. Let the first person weapon do it's thing but just no damage, and no visible projectile, or decals.

Then have the pawn detect when the LMB is pressed and go from there.

[GD1]

the guest (probably pickles?) may actually be right. I forgot that when he made Cell Division he included a command to attach to a first-person weapon's bone structure, something you couldn't do before. This could also solve the flashlight problem.

I forgot the name of the command, but if you dig through the source code a little I'm sure you can find it.

[QuestOfDreams]

Projectile weapons now (RF 0.78.0.0) have a maxdeviationangle option to specify the accuracy of the weapon.