Project Reality Forums

If you look in the Simrad's .tweak you'll see the altguiindex (ie the graphical user interface for the zoomed view) is set to "1". There is a line in that laserpainter file which applies the code to weapons with that GUI index (hudBuilder.setNodeLogicShowVariable EQUAL GuiIndex 1). If I am not mistaken, the TargetDistanceString variable is the rangefinder value. I had a look for that variable in other files and lo and behold the tank drivers have it for their rangefinders.

menu_server.zip\HUD\HudSetup\VehiclesHudElementsM1A2Driver.con:

Ahh yes, then how do delay the appearance of the range finder values?

No idea.

I guess this is the best place to ask this question...

Could you...(without creating detriment to the gameplay)
(a) Increase the speed at which players can pace while the weapon is at eye level. I wouldnt suggest this for scoped rifles, only for iron sights.
(b) Increase the speed of prone movement just a tad. as when a player is prone and being fired at it is difficult to scramble backwards to cover. (I know that if i was being shot at scrambling wouldnt be a problem lol )

Psykogundam wrote:I guess this is the best place to ask this question...

Could you...(without creating detriment to the gameplay)
(a) Increase the speed at which players can pace while the weapon is at eye level. I wouldnt suggest this for scoped rifles, only for iron sights.
(b) Increase the speed of prone movement just a tad. as when a player is prone and being fired at it is difficult to scramble backwards to cover. (I know that if i was being shot at scrambling wouldnt be a problem lol )

(a) Yes, with ObjectTemplate.zoom.zoomDelay X, where X is the time in seconds. If you set it too long, funny things happen. The default value for the M16A4 is 0.08 seconds. By the way, 0.08 seconds is a very short time. Having it a little shorter won't make much of a difference. Increasing the time for scoped weapons and making the animations work however would, I'd imagine...

(b) Apparently yes. Through the use of: Vars.Set phy-soldier-crawl-speed Y, where Y is the speed.

I think he means the pace at which the soldier can move at with the weapon in ironsights, not the time it takes to bring up to eye level. Apologies if I'm wrong...

Psykogundam wrote:(a) Increase the speed at which players can pace while the weapon is at eye level. I wouldnt suggest this for scoped rifles, only for iron sights.

That might be a good idea. CQB could be enhanced if iron-sighed soldiers could move slightly faster with their weapons drawn. Will look into this and if possible, see how it affects gameplay.

Psykogundam wrote:(b) Increase the speed of prone movement just a tad. as when a player is prone and being fired at it is difficult to scramble backwards to cover. (I know that if i was being shot at scrambling wouldnt be a problem lol )

Not sure if it's possible to regulate the speed of difference stances such as prone. Even if it were, I personally think the speed of prone is fine. If you're getting shot at, you may want to re-think your approach to the enemy.

a) We didn't find a way to do this, but we want to.

b) It's possible, but I don't think it needs any change.

Wolfe, how is the deviation thing going? Did you guys made any progress?

[R-DEV]dbzao wrote:Wolfe, how is the deviation thing going? Did you guys made any progress?

It's just me doing the progress and it's been more work than anticipated. There are also a few issues to be resolved; there needs to be some kind graphic that shows your cone of fire... something that looks natural and realistic. I've had a few ideas but don't know how to code them.

Beyond that, I'm still working on the basic deviation model for the assault rifle; this is the most difficult gun because it is used in the most variety of ways (full auto, single shot, short/medium/long range, slow movement, fast movement) and getting all of those to work effectively without run'n gun is a delicate balance. The other weapons (sniper, support, rockets) are easy because they're niche weapons designed for 1 or 2 purposes only and I don't have to worry about movement deviation since those weapons should remain stationary when fired.

I'm in the ballpark but now trying to fine-tune it all. Hopefully I'll get that done this week or next. Once complete, I'll set up a series of test fights (squad vs squad) and see how well I've balanced the paper, scissors, rock effects.

Could the representation of a player's cone of fire be done via a very subtle shader effect; a little like focusing a manual-focus SLR camera? As in, when you're scoped the area in which your fire will go is crystal sharp, and everything outside it is very slightly blurred; the area of perfect sharpness would shrink down to a small area at lowest deviation.

Not realistic in the sense that your eye would remain focused on everything in a optical gunsight but if the effect was subtle it'd be a small indicator than just requiring players to wait and guess.

Yes, that's the kind of idea I'm learning towards; something natural that could be applied to any weapon universally. Unfortunately I don't know how to tie shaders to crosshairs but would like to learn and experiment with different ideas.

Need help:
Someone who is an expert in manipulating crosshair effects. I was hoping this wouldn't be necessary but it seems that without it the user has to "guess" where he is aiming and this is unacceptable with the increased cone of fire and increased settle times. The crosshair effect must be seamless, look natural, and be a direct representation of the weapon's cone of fire.

At this point, I cannot continue testing/coding until this is done.
______________________________

Below is the latest deviation code. It is the basis for all other assault weapons, but still needs to be tested in combat and tweaked as necessary. It uses the the following principals:

Fire Devation:
1 shot = ~20deg deviation. 2 second settle time.

Mouse Movement:
90deg turn requires 5 second rate to maintain accuracy (prefect for tracking targets, but severely hinders run'n gun)(similar tracking rate to the HAT, but max dev not as high). Max dev = ~20deg, 2 second settle time.

Forward Movement (walk forward/reverse):
No deviation. Allows user to walk towards target while scoped. Required for CQB.

Side Movement (strafe left/right):
Instant ~20 deviation, 4 second recovery time.

rem ---BeginComp:SoldierBasedRecoilComp ---
rem 556 Standard Recoil Assault Rifle
ObjectTemplate.createComponent SoldierBasedRecoilComp
ObjectTemplate.recoil.hasRecoilForce 1
ObjectTemplate.recoil.recoilForceUp CRD_UNIFORM/1.6/1.9/0
ObjectTemplate.recoil.recoilForceLeftRight CRD_UNIFORM/-0.2/-0.5/0
ObjectTemplate.recoil.zoomModifier 0.6
ObjectTemplate.recoil.goBackOnRecoil 0
rem ---EndComp ---

rem ---BeginComp:SoldierDeviationComp ---
rem 556 Optical Sight Standard Accuracy Assault Rifle
ObjectTemplate.createComponent SoldierDeviationComp
ObjectTemplate.deviation.minDev 0.33
ObjectTemplate.deviation.setFireDev 3.0 2.5 0.06
ObjectTemplate.deviation.setTurnDev 2.2 0.2 0.2 0.05
ObjectTemplate.deviation.setSpeedDev 3.0 0.0001 3.0 .03
ObjectTemplate.deviation.setMiscDev 5 5 .1
ObjectTemplate.deviation.devModStand 1.5
ObjectTemplate.deviation.devModCrouch 1.4
ObjectTemplate.deviation.devModLie 1.3
ObjectTemplate.deviation.devModZoom .3
rem ---EndComp ---

Note:
Although the MinDev is listed as .33, remember to calculate in the devModZoom factor of .3 to create a .099 minimum deviation (.3 x .33 = 0.099). PRv.75 uses a minimum deviation of .1. The difference between .099 and .1 is 1/1000 of a point. In other words, the minimum deviation has not been changed.

Why do you have a huge fire deviation? What are you trying to acomplish with it?

The general level of deviation is too big imo, it feels a little like vBf2.

Also, did you reduce the recoil?

[R-DEV]Mosquill wrote:Why do you have a huge fire deviation? What are you trying to acomplish with it?

It's to force people to take their time to line up their next shot. Currently you can often spam rounds at the target more effectively then doing it in a controlled fashion.

[R-DEV]Mosquill wrote: Also, did you reduce the recoil?

The upwards "recoil", on average, is the same as 5.56x45mm rifles. Instead of being a single value (1. is has a range of 1.7 to 1.9. This will make it harder for a player to account for the muzzle climb by pulling the mouse down at a set rate (since the climb varies between shots). The "recoil" to the side is far less that the original range (-1 to 1), is within the range of -0.2 to -0.5 and is consequently only to the right. The gobackonrecoil value is set on "0" which means the weapons won't return to the original position which I imagine will help solve the spam problem.

As Wolfe said, it still needs to be tweaked.

EDIT: Another major difference that this model has is that there is less difference in the modifiers for stance (1.5, 1.4, 1.3 vs 1.5, 1.2, 1.0). This means that all the other movement, firing, jumping modifiers have a more consistent effect between stances.

EDIT #2: A huge difference is the zoom modifier. Currently you are just as accurate looking down your scope as firing from the hip. With this model you have 30% less random deviation while looking down the sights compared to firing from the hip.

Well, I wrote a huge response but Ned said it better lol. Thanks Ned, spot on.

Wolfe wrote:Are you basing your opinion on actual testing of the values or just eyeballing them?

I played and tested it.

Wolfe wrote:If the fire dev is too small (like v.75), players are allowed to rapidly fire single shots at a target without waiting to aim between shots.

The recoil is there for a reason. It makes people aim after every shot.

Wolfe wrote:This is particularly frustrating and unrealistic at range. Sighting in and pulling the trigger should require patience and skill, not stupid luck.

It was never frustrating for me. Sighting in and pulling the trigger will not requre any skill if you add crazy fire deviation like that, it would require timing... and luck. And it definately won't be more realistic.

[R-DEV]Mosquill wrote:It was never frustrating for me. Sighting in and pulling the trigger will not requre any skill if you add crazy fire deviation like that, it would require timing... and luck. And it definately won't be more realistic.

Hence the need for some visual indicator, as stated by Wolfe.

Someone who is an expert in manipulating crosshair effects. I was hoping this wouldn't be necessary but it seems that without it the user has to "guess" where he is aiming and this is unacceptable with the increased cone of fire and increased settle times. The crosshair effect must be seamless, look natural, and be a direct representation of the weapon's cone of fire.

EDIT #1: The gobackonrecoil modifier which is currently set at "1" negates peoples need to aim after each shot Mosquill. Increasing the recoil just means it takes a little longer for the crosshair to fall back on target.

EDIT #2: On second thoughts the amount of deviation added after each shot looks rather large. If I am not mistaken that is 2.5 degrees added deviation.

[R-CON]nedlands1 wrote:EDIT #1: The gobackonrecoil modifier which is currently set at "1" negates peoples need to aim after each shot Mosquill. Increasing the recoil just means it takes a little longer for the crosshair to fall back on target.

No, I don't think gobackonrecoil works the way you described. It doesn't just go back where it was, its much more comlicated then that.

[R-DEV]Mosquill wrote:No, I don't think gobackonrecoil works the way you described. It doesn't just go back where it was, its much more comlicated then that.

True that. I should test before I make such statements or at least state that I think it does.

From my testing, it seems that the time for the sights to stabilise after shooting is ~0.3 seconds and they fall back down ~75% of the distance that they climb, after a single shot. This means that there is more mouse pulling with weapons with large recoil and that the sights move a lot faster, up and down, the more recoil you have. The values I tried were 1.08 (due to the zoom modifier being 0.6) and 15.

I'm pretty sure Jonny is on the money. The gobackonrecoil appears to only work on the last round fired.

Perhaps the gobackonrecoil modifier isn't a boolean. I'll have a looksie.

EDIT: It looks like a boolean with a default value of "1". That means if you don't include the gobackonrecoil line or you put an erroneous value in it will act as though gobackonrecoil is set as "1".