Quote:
Originally Posted by pedrotski
CornerCulling engine has audio-related bugs. This is something Valve related apparently.
Sauray needs a ray tracing GPU as far as I'm aware.
I'll check out that other you posted but would prefer something private.
|
Hey everyone, Baktash here from TooMuchVoltage Software.
Firstly, thank you for the mention raj! Just wanted to let everyone know that SauRay's plugins can be now found at:
https://github.com/toomuchvoltage/SauRay. Now it's just part of TooMuchVoltage's portfolio. (Updates will be on the new website
http://sauray.tech, new Twitter account (@antiwallhack) etc. etc.)
Additionally, yes! SauRay needs a ray-tracing GPU. Because, it also accounts for shadows, guns, the frustum under normal -- i.e. low latency -- circumstances and myriad other things.
Regarding CornerCulling's audio issues: even though we use a slightly different method to obfuscate audio origin, we by and large suffer from the same audio issues: reload sound emanating from the last known enemy/entity position (who may be long out of sight). Full list is in:
https://github.com/toomuchvoltage/Sa...ee/master/CSGO. Everyone else will as well. The reason has to do with CSGO's netcode as hinted.
See, when we were integrating Quake II we had access to low-level netcode. We could actually modify underlying server netcode to force sending audio positions instead of telling the client to play the audio at entity location. See:
https://github.com/toomuchvoltage/Sa...aster/vkQuake2.
With respect to CSGO, it involves changes that may neither be easy to make via the VSP/MetaMod:Source/SourceMod interface... nor easily consumed by CSGO client binaries. This is not the only issue at hand either. For example, we obfuscate radar position laterally which is not ideal. Why? Because they're broadcasted as a full position via a protobuf envelope to everyone the same. From a design standpoint, they should've just sent the 2D location rather than the full 3D one coupled with an above/below/level flag (for the 'T' marker on radars) crafted for each recipient. They didn't do that and now we're just stuck with randomizing it laterally. Full list here:
https://github.com/toomuchvoltage/Sa...ee/master/CSGO.
This doesn't just affect CSGO. In TF2, by default they transmit the heavy class everywhere. Even outside of visibility leaves. Why? Because when they want to signal clients to display the heavy's machine-gun muzzle-flash they simply tell clients to display it
at the entity. When we disable this behavior with SauRay, you sometimes see heavy muzzle-flashes mid-air. This is because that's where you last saw (or 'received' the location of) that heavy and now they're somewhere else blasting the whole world. Same thing with the medic beam: you last saw them there... and now they're somewhere else healing somebody. Again, full list here:
https://github.com/toomuchvoltage/Sa...ree/master/TF2.
Now the truth is Source is upgraded GoldSrc, and GoldSrc is upgraded Quake II engine (idTech 2). Why is it that a large part of the netcode is very server authoritative and thin-client while some corners are seemingly cut design-wise? Well my take is: they never saw anti-wallhacks becoming a real usable alternative to visibility leaf filtering (or other crude means). Or at least not this soon. Hopefully, they will take notice of possibilities like SauRay and change some of that netcode. At the very least, in low-latency competitive scenarios middleware like SauRay make anti-wallhacks (minus some room left for garbage like 'Chams') actually feasible. And this shouldn't be written off by netcode designers/programmers by and large.
Linear Mode
