your also forgetting that having a higher FOV also gives you a disadvantage as the middle of your screen gets 'smaller'. Usually near 120 is the highest i would go and even then sometimes (depends on the game) that is too high, your then at a disadvantage.
With this issue to contemplate i dont think its that big of a deal. So far i see that increasing FOV gives you an advantage, why dont you increase your FOV to 300 or 900 to see how much of an advantage you will have...lol
I do agree with Elodeas point that NS2's FOV is fine at the values that have been set. The general mindset is people want to increase their FOV because of the high amount of consoles ports with 60 POV. Its became almost a fasion to demand higher FOV only because of these ports. NS2 is not a port and the FOV is fine imo. Though i play at 1080p i dont know if the FOV is different for other aspect ratios.
This is an interesting discussion about FOV. I would like to add that I think its partially a mistake to assume that just because someone has an increased FOV that they are at an actual advantage rather than a potential advantage.
For example, some people are so bad at aiming that even with 180 fov and a pink skulk they still couldnt hit it at any range especially up close
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=1984097:date=Sep 28 2012, 01:17 AM:name=elodea)--><div class='quotetop'>QUOTE (elodea @ Sep 28 2012, 01:17 AM) <a href="index.php?act=findpost&pid=1984097"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->And i'd quote it right back at you to show that you <b>don't</b> necessarily need modifiable FOV at all. <a href="https://www.youtube.com/watch?v=blZUao2jTGA&t=8m17s" target="_blank">https://www.youtube.com/watch?v=blZUao2jTGA&t=8m17s</a> Reasonable FOV for pc is 90-95, which is exactly what NS2 runs default (with skulk up to 105). Competitive cs ran locked at 90 FOV.<!--QuoteEnd--></div><!--QuoteEEnd--> He was clearly generalizing (his example used a 30in monitor 2ft away). The point is that comfortable FoV is a function of monitor size and distance away from the players eyes, neither of which UWE can control. Sure, people who don't get motion sick/headaches from improper FoV and decide to crank up their FoV will have a slight advantage, but the same can be said for people with a good mouse or faster hand-eye coordination. We don't lock mouse sensitivity or framerate to ensure these people don't have an advantage and we shouldn't with FoV either.
FOV sliders are good for customization, but need to be limited as to not allow extremely high or low FOVs. I think 120 FOV is far too high. 80-100ish is fairly reasonable, though.
The consistency checks are very good and welcome, but there will be a lot of problems that need to be ironed out. I wish UWE would take it upon themselves to open the default consistency check to the crosshair.dds and crosshair-hit.dds files. These should be changeable by default, after all the crosshair is designed to assist you.
I think this could be a step in the right direction. Imagine if a server could "accept" mods just by subscribing for them on steam workshop. That way the mod will allways be up to date. And it would allow for everybody to be able to use mods a lot more easy, while at the same time giving all players similar circumstances. And, if you have mods loaded that the server disallows the server will simply disable them to fit the rules on the server.
I think this could be the start of something awesome.
DghelneshiAims to surpass Fana in post edits.Join Date: 2011-11-01Member: 130634Members, Squad Five Blue, Reinforced - Shadow
edited September 2012
<!--quoteo(post=1984255:date=Sep 28 2012, 10:17 PM:name=GORGEous)--><div class='quotetop'>QUOTE (GORGEous @ Sep 28 2012, 10:17 PM) <a href="index.php?act=findpost&pid=1984255"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->FOV sliders are good for customization, but need to be limited as to not allow extremely high or low FOVs. I think 120 FOV is far too high. 80-100ish is fairly reasonable, though.<!--QuoteEnd--></div><!--QuoteEEnd--> 16:9 screen users already have FoVs <b>way </b>above 110°, especially as skulk. I somehow can't get the calculation done right so I can't tell exactly how much.
<!--quoteo(post=1984305:date=Sep 28 2012, 07:50 PM:name=Dghelneshi)--><div class='quotetop'>QUOTE (Dghelneshi @ Sep 28 2012, 07:50 PM) <a href="index.php?act=findpost&pid=1984305"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->16:9 screen users already have FoVs <b>way </b>above 110°, especially as skulk. I somehow can't get the calculation done right so I can't tell exactly how much.<!--QuoteEnd--></div><!--QuoteEEnd-->
Why is that? Genuinely curious as I play at 1600x900 resolution and have the default FOVs in my BalanceMisc.lua. Nothing is higher than 105 (skulk).
Default FOV is 90, though. I assume that this is what would be capped where as the extra FOV the skulk enjoys could scale beyond any cap. I'm curious what the 90 default FOV translates to in 16:9.
You can use this to calculate the FOV difference: <a href="http://www.emsai.net/projects/widescreen/fovcalc/" target="_blank">http://www.emsai.net/projects/widescreen/fovcalc/</a>
DghelneshiAims to surpass Fana in post edits.Join Date: 2011-11-01Member: 130634Members, Squad Five Blue, Reinforced - Shadow
edited September 2012
The new slider in b221 is implemented in a weird way. It actually does not set FoV, but rather adds a value to the base FoV (up to 20°).
New maximum values for 16:9: <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Default = 125° Skulk = 137° Gorge/Exo = 129° Lerk = 133°<!--c2--></div><!--ec2--> Maximum values for 5:4: <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Default = 106° Skulk = 122° Gorge/Exo = 112° Lerk = 117°<!--c2--></div><!--ec2--> That was pretty much what I was playing at the whole time, so I'm fine with this.
How does the system deal with files that are on the server and not the client?
I was hoping a server-side plug-in metamod system could be a good way to allow server ops to customize their servers without requiring the clients to have all the same files (as the code in the mod files would never run on a client).
So, a client connects and the server has a bunch of .lua files that the client doesn't have. What happens?
SecurityJoin Date: 2005-01-07Member: 33133Members, Constellation, Squad Five Blue
<!--quoteo(post=1984402:date=Sep 29 2012, 06:18 AM:name=eh?)--><div class='quotetop'>QUOTE (eh? @ Sep 29 2012, 06:18 AM) <a href="index.php?act=findpost&pid=1984402"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It drops the client because they don't match.
Sucks.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yep. -> <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=121483&st=0" target="_blank">http://www.unknownworlds.com/ns2/forums/in...121483&st=0</a> What the hell?
Also, why are people even beeing kicked?
On sv_pure TF2 servers, non-vanilla content just won't work for users who have it installed. Noone is kicked for it.
<!--quoteo(post=1984402:date=Sep 29 2012, 12:18 AM:name=eh?)--><div class='quotetop'>QUOTE (eh? @ Sep 29 2012, 12:18 AM) <a href="index.php?act=findpost&pid=1984402"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It drops the client because they don't match.
Sucks.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is bad.
At least a forced download would be better (though it makes no sense to enforce client consistency on server-only code)
Lets assume a plug-in system gets built in to the official code or a mod, letting you do stuff like reserved slots and stats using server-side plugins. Then surely if you whitelist the plugin files (but not the main files that dispatch calls to plugins), it won't care if the client has them or not?
And the whitelisted files can't be modified client side and used to cheat if the code that calls into those files has "if Server" checks, and is consistency checked.
So sounds like the metamod would be really useful.
EDIT: Max points out <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=121483&view=findpost&p=1984609" target="_blank">here</a> that if the server mod is published to the workshop it will autodownload (and should be tiny).
This has been done for so many games, if you want to make it fair just make it default or at least what you want to be default. Makes me think of <a href="http://www.youtube.com/watch?v=GcHv-VNFypA" target="_blank">http://www.youtube.com/watch?v=GcHv-VNFypA</a> dunno why
SecurityJoin Date: 2005-01-07Member: 33133Members, Constellation, Squad Five Blue
I'd suggest just including an extra folder with vanilla files with the server, which the consistency check then uses to check against the connecting clients files, rather than the possibly modified server files.
That would solve the current problems with serverside mods & consistency checking right away.
Comments
With this issue to contemplate i dont think its that big of a deal. So far i see that increasing FOV gives you an advantage, why dont you increase your FOV to 300 or 900 to see how much of an advantage you will have...lol
I do agree with Elodeas point that NS2's FOV is fine at the values that have been set. The general mindset is people want to increase their FOV because of the high amount of consoles ports with 60 POV. Its became almost a fasion to demand higher FOV only because of these ports. NS2 is not a port and the FOV is fine imo. Though i play at 1080p i dont know if the FOV is different for other aspect ratios.
For example, some people are so bad at aiming that even with 180 fov and a pink skulk they still couldnt hit it at any range especially up close
Reasonable FOV for pc is 90-95, which is exactly what NS2 runs default (with skulk up to 105). Competitive cs ran locked at 90 FOV.<!--QuoteEnd--></div><!--QuoteEEnd-->
He was clearly generalizing (his example used a 30in monitor 2ft away). The point is that comfortable FoV is a function of monitor size and distance away from the players eyes, neither of which UWE can control. Sure, people who don't get motion sick/headaches from improper FoV and decide to crank up their FoV will have a slight advantage, but the same can be said for people with a good mouse or faster hand-eye coordination. We don't lock mouse sensitivity or framerate to ensure these people don't have an advantage and we shouldn't with FoV either.
But yea fov slider is meh, as long as the limit is reasonable idc in the end.
The consistency checks are very good and welcome, but there will be a lot of problems that need to be ironed out. I wish UWE would take it upon themselves to open the default consistency check to the crosshair.dds and crosshair-hit.dds files. These should be changeable by default, after all the crosshair is designed to assist you.
<img src="http://i.imgur.com/4MnRx.jpg" border="0" class="linked-image" />
I think this could be the start of something awesome.
16:9 screen users already have FoVs <b>way </b>above 110°, especially as skulk. I somehow can't get the calculation done right so I can't tell exactly how much.
Why is that? Genuinely curious as I play at 1600x900 resolution and have the default FOVs in my BalanceMisc.lua. Nothing is higher than 105 (skulk).
Default FOV is 90, though. I assume that this is what would be capped where as the extra FOV the skulk enjoys could scale beyond any cap. I'm curious what the 90 default FOV translates to in 16:9.
*edit, images in my post below*
FoV values for <b>4:3</b>:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Default = 90°
Skulk = 105°
Gorge/Exo = 95°
Lerk = 100°<!--c2--></div><!--ec2-->
FoV values for <b>16:9</b>:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Default = 106°
Skulk = 120°
Gorge/Exo = 111°
Lerk = 116°<!--c2--></div><!--ec2-->
FoV values for <b>16:10</b>:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Default = 100°
Skulk = 115°
Gorge/Exo = 105°
Lerk = 110°<!--c2--></div><!--ec2-->
FoV values for <b>5:4</b>:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Default = 86°
Skulk = 101°
Gorge/Exo = 91°
Lerk = 96°<!--c2--></div><!--ec2-->
Edit: @Koruyo: The box for 5:4 is wrong. I measured it and it is closer to 3:2. 5:4 is even smaller than 4:3.
<img src="http://i.imgur.com/nn4kO.jpg" border="0" class="linked-image" />
<img src="http://i.imgur.com/vZJIl.jpg" border="0" class="linked-image" />
New maximum values for 16:9:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Default = 125°
Skulk = 137°
Gorge/Exo = 129°
Lerk = 133°<!--c2--></div><!--ec2-->
Maximum values for 5:4:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Default = 106°
Skulk = 122°
Gorge/Exo = 112°
Lerk = 117°<!--c2--></div><!--ec2-->
That was pretty much what I was playing at the whole time, so I'm fine with this.
How does the system deal with files that are on the server and not the client?
I was hoping a server-side plug-in metamod system could be a good way to allow server ops to customize their servers without requiring the clients to have all the same files (as the code in the mod files would never run on a client).
So, a client connects and the server has a bunch of .lua files that the client doesn't have. What happens?
Sucks.
Sucks.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yep. -> <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=121483&st=0" target="_blank">http://www.unknownworlds.com/ns2/forums/in...121483&st=0</a>
What the hell?
Also, why are people even beeing kicked?
On sv_pure TF2 servers, non-vanilla content just won't work for users who have it installed. Noone is kicked for it.
Sucks.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is bad.
At least a forced download would be better (though it makes no sense to enforce client consistency on server-only code)
Lets assume a plug-in system gets built in to the official code or a mod, letting you do stuff like reserved slots and stats using server-side plugins. Then surely if you whitelist the plugin files (but not the main files that dispatch calls to plugins), it won't care if the client has them or not?
And the whitelisted files can't be modified client side and used to cheat if the code that calls into those files has "if Server" checks, and is consistency checked.
So sounds like the metamod would be really useful.
EDIT: Max points out <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=121483&view=findpost&p=1984609" target="_blank">here</a> that if the server mod is published to the workshop it will autodownload (and should be tiny).
That would solve the current problems with serverside mods & consistency checking right away.