Forum
FoV Client Plugin Changer
Created 21st December 2011 @ 00:44
Add A Reply Pages: « Previous 1 ... 7 8 9 ... 12 Next »
Quoted from skeej
[…]
To go even further, the “unfairness” always existed by default, regardless of any eyefinity or windowed widescreen solutions. 5:4 monitors have a disadvantage over 4:3 monitors, those in turn have a disadvantage over 16:10 monitors, and 16:9 monitors have even wider fov.
MInd speaks the truth here, a wider fov is not an automatic absolute advantage. Btw I think I said something wrong in my first post in this topic. I said that fov_desired dictates vertical fov. After some quick research though, it seems that it dictates horizontal fov at an aspect ratio of 4:3, which means we all played with a vertical fov of 73.74 degrees (thanks Jaeger). So this is also a general warning, don’t just carry over your fov settings from QL as the fov setting might be applied differently in that game.
Longas, even without this plugin you can change fov_desired on the fly as far as I know. So I don’t see a problem here. You’d be fine with Valve unlocking fov officially, even though effectively there would be no difference between these implementations? (unless of course you meant: Valve should allow higher fovs and disable changing fov_desired on the fly)
lwf: It is not incompatible with VAC. VAC works on a blacklist-type basis, so VAC will only kick in if Valve decides that this plugin is a hack. The question is, IF Valve decides this, will the VAC measures also work retroactively? (anyone who used this plugin in the past is fucked?). The odds that Valve will do this are small though. First of all it would be hypocritical (because they’re know that wider AR = wider FOV) and second of all, apparently there are loads of unsigned plugins out there (with actual absolute unfair advantages) that never got banned.
I’m ok with being able to change the fov_desired on the fly if the values are “locked” (e.g. 70 min, 120 max), with this plugin you can change to 145 to see through walls when you need it (sticky trap).
Last edited by longas,
Discussion ensued.
I still don’t see much wrong with this statement:
Any percentage of more protection, even though it is infinitely small, is better than no other measure at all, provided that this protection does not bring any disadvantageous externalities.
DBlocker provides this protection (at least it fixes the easier methods of wallhack, including the high fov one), at no apparent cost, in my opinion.
Arguments against?
octochris: it sends private data of it’s own will
octochris: that’s enough for me not to want to use it
That seems to be the only “fuss” up to this point?
Last edited by skeej,
Quoted from skeej
Discussion ensued.
I still don’t see much wrong with this statement:
Any percentage of more protection, even though it is infinitely small, is better than no other measure at all, provided that this protection does not bring any disadvantageous externalities.
DBlocker provides this protection (at least it fixes the easier methods of wallhack, including the high fov one), at no apparent cost, in my opinion.
Arguments against?
[…]
That seems to be the only “fuss” up to this point?
The data it sends is exactly the same as the one in DBlocker.log, not more, not less. This data is used for debugging purposes, and has been useful quite a lot in the past in case there was a bug with one of the detections.
I disagree, the area you’re in now operates using what’s closer to a whitelist than a blacklist. VAC as it’s used in TF2 is designed to be incompatible with this very plugin. I will explain.
Once upon a time all plugins were (technically) allowed and would always load. They were meant for servers but worked on clients as well. This allowed for easy abuse, for example by loading SourceMod on the client (which is a perfectly legit tool meant for servers), and then overriding values that were clamped for any reason or restricted by other settings such as sv_cheats.
September 8, 2010 this was put to a stop with the patch note “Disabled clients loading server plug-ins unless the plug-ins are signed by Steam or the client is running in insecure mode.”. The author describes this FOV plugin as “a client side plugin, just like PREC”. It’s nothing like PREC. See, PREC actually got a code signature by Valve. This hack obviously didn’t, which is why it requires the use of the -insecure argument.
But why would Valve disable all plugin functionality on clients (with very specific exceptions) if they would simply let you disable the check? Sounds a bit odd, doesn’t it? Well, the insecure argument wasn’t introduced in the 2010 patch. It existed before that and already had a function, same on both the server and client; it disables VAC. Therefore with the use of this argument, unauthorized plugins will load on the client but the client is not allowed on VAC secured servers because they won’t allow your client to join unless it too has VAC enabled. Incompatible by design.
This calls for an experiment. Don’t use the plugin. If you have, remove it. Start TF2 using the -insecure argument and join a server. Did you get the error “You are in insecure mode. You must restart before you can connect to secure servers.”? Good. This is the expected behavior.
Now install the hack (ON YOUR OWN RISK, I DO NOT RECOMMEND IT). Can you join now? Oh, you can! Good job!
Now remove the -insecure argument. Did you get the error “No valid signature found for c:\program files (x86)\steam\steamapps\throwawaytest114124\team fortress 2\tf\addons\fov.dll” in the console? Did it load? It didn’t?
There’s only one possible explanation for this; the hack bypasses the plugin check. It may even bypass VAC, I can’t say, but at the very least it does bypass the anti-cheating measures Valve has in place. You’re on very thin ice in an extremely gray area with a closed source program, and I think we found the reason for why it is, that’s it by every definition a hack. I’m astounded there wasn’t a more critical response to this.
http://wiki.teamfortress.com/wiki/September_8,_2010_Patch
https://developer.valvesoftware.com/wiki/Client_plugins
https://developer.valvesoftware.com/wiki/Command_Line_Options#Command-line_parameters_4
Quoted from lwf
-snip-
About plugins:
Blocking plugins from loading has always been a HORRIBLE desicion. It never stopped cheating, it never will; it only harmed people who wished to create legitmate plugins for their favourite games. Keep this in mind: if the plugin block was here before P-REC we probably would have never gotten P-REC in the first place!
The signature thing is a complete joke. I tried to get multiple plugins signed and I NEVER got a response. What do you expect us to do? In my eyes all it served for was to ban clientside plugins while still enabling P-REC (which would otherwise lead to an internet backdraft).
Here’s what should have happened:
1. Update VAC so it can kick people instead of marking them to be banned after a random period of time.
2. Creators of sourcemod fix this exploit in their software.
3. Running sourcemod while connected to a VAC secured server should lead to a kick
4. Anyone found recompiling sourcemod binaries to avoid the signature should be treated for what they are, hacks designed specifically to circumvent the system. Just backlist their signatures.
5. Post an announcement about all this
But we know how well Valve handles such situations (hello halocaust)
About -insecure and VAC:
It does NOT disable VAC in ANY WAY. Here’s what happens if you prevent VAC from loading completely: You get kicked for ‘client timed out’ (although I think they changed the msg to something like ‘no connection to vac servers’ or something). All this plugin does is:
1. Remove -insecure from the startup params (edit: scrap that, the plugin doesn’t do this)
2. Flip a global boolean value indicating whether the client should be allowed to join VAC secured servers
Will VAC catch these methods to bypass the plugin check? No.
Can VAC in theory catch this specific plugin by dll signature? Yes.
Looking at this thread & the spuf thread, people generally WANT a higher fov cap. Based on this Valve can now make a proper decision and increase the cap (and fix aspect ratio related exploits from bypassing it).
About this fov plugin:
Yes it should have been open source but so far I couldn’t convince my friend (who wished to remain anonymous, he’s amazing btw) to do so.
Last edited by Casual,
This discussion isn’t really about FOV anymore. Nobody would complain about people using 120 fov if it was allowed by Valve. So yes, people want to use this, that doesn’t mean that circumventing VAC restrictions is something people should be so blasé about.
Personally I won’t use this until it gets signed (which won’t happen because Valve doesn’t want higher FOVs), and it’s probably only a matter of time before Valve takes action against it.
My 2c.
All I’m getting out of this is that Valve are bad coders. Which we knew already.
That isn’t making it any more or less detectable as it was before though. It would be quite stupid for Valve to do anything considering the amount of people that used it, the amount of people that want a higher FoV, and the ability to do it by changing the aspect ratio. I hope they’ll add that to the game options.
Last edited by AnAkkk,
Bad coders who have been known to overreact. Remember the idling fiasco?
On a side note, this can probably also be used to change the fov while playing back demos so you don’t need arcane methods of changing the fov for special effects.
Quoted from Casual
On a side note, this can probably also be used to change the fov while playing back demos so you don’t need arcane methods of changing the fov for special effects.
There’s an FOV override cvar for demos now, I think.
Quoted from octochris
[…]
There’s an FOV override cvar for demos now, I think.
Isn’t the max 90, though?
Quoted from octochris
[…]
There’s an FOV override cvar for demos now, I think.
Oh you’re right:
] demo_fov_override
“demo_fov_override” = “0”
client
– If nonzero, this value will be used to override FOV during demo playback.
Last edited by Casual,
Fuck this shit, I’ll just roll back to using fov 75.
Add A Reply Pages: « Previous 1 ... 7 8 9 ... 12 Next »
content rss