New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The animation "setAnimSpeedCoef 2" can increase players movementspeed/aka speedhack #406

Open
wiking-at opened this Issue Jun 9, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@wiking-at
Contributor

wiking-at commented Jun 9, 2016

In the last days I had more and more messages from users running with a "speedhack". I think i could track this back to the changes in
\client\functions\fn_inGameUIActionEvent.sqf

the bug can be reproduced if both people want to become driver of a vehicle of the same time. then one player gets ejected without the animation speed reset. and this player then runs with double speed.

it seems the that the event handlers for \client\clientEvents\getInVehicle.sqf and \client\clientEvents\getOutVehicle.sqf don't get triggered in this (and maybe other) occasions.

@wiking-at wiking-at changed the title from The animation "setAnimSpeedCoef 2" can increase players movespeed to The animation "setAnimSpeedCoef 2" can increase players movementspeed/aka speedhack Jun 9, 2016

@AgentRev

This comment has been minimized.

Member

AgentRev commented Jun 9, 2016

gosh darnit I knew this was a bad idea... I'm gonna add a new thread to track the player and reset speed as needed

@Gigatek1

This comment has been minimized.

Contributor

Gigatek1 commented Jun 10, 2016

Maybe add these 2 to the thread as well.

hideObjectGlobal false;
allowDamage true;

I still get complainants about invisible or god mode players. This way we could make sure its not a playerSpawn.sqf bug and its a script kiddie and maybe we can implement better spawn island protection with this on. We still have admins wasting time on this issue (spawn island killing) ALL the time. We used this for awhile and it worked but I turned it off because of reports of players being bugged with invisible/god mode.

https://github.com/A3Armory/A3A_A3Wasteland_Sock.Altis/blob/dev/addons/spawn/functions.sqf

@AgentRev

This comment has been minimized.

Member

AgentRev commented Jun 10, 2016

I didn't know spawn protection was still a problem, but I have found the ultimate solution while working on Tanoa: ProtectionZone_Invisible_F, a giant invisible vertical 50m-wide cylinder made by BIS that protects everything inside it, like a bullet sponge if you will. You can shoot at players while inside, but it doesn't do anything.

@AgentRev

This comment has been minimized.

Member

AgentRev commented Jun 10, 2016

Also I think the issue you are referencing applies specifically to sock edits, I have not received any such reports from other server owners.

@Gigatek1

This comment has been minimized.

Contributor

Gigatek1 commented Jun 10, 2016

I'll test it on extdb and make a new issue. Thanks Agent. I still think those commands should be checked as well though.

@AgentRev

This comment has been minimized.

Member

AgentRev commented Jun 10, 2016

I just looked at that code you pointed out. Seriously just throw it out the window, this is garbage. If the scheduler is slowed down and the player manages to choose a spawn before the script had time to run, he will be made invisible after teleporting to the final location, and the script will keep waiting indefinitely.

@Gigatek1

This comment has been minimized.

Contributor

Gigatek1 commented Jun 10, 2016

Yeah that's why I commented it out. It's not active right now.
On Jun 10, 2016 12:34 PM, "Agent Revolution" notifications@github.com
wrote:

I just looked at that code you pointed out. Seriously just throw it out
the window, this is garbage. If the scheduler is slowed down and the player
manages to choose a spawn before the script had time to run, he will be
made invisible after teleporting to the final location.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#406 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AI6sJtUw71SV49kIZoJHIjxX8zUioyZFks5qKbwjgaJpZM4IyIEy
.

@AgentRev

This comment has been minimized.

Member

AgentRev commented Jun 10, 2016

In my code, allowDamage true is called immediately before the black screen "fade-in", so it would mean that the spawning procedure completely failed if they are stuck like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment