View Angles Violation ban

[Listing]

I noticed there are servers which run this kind of plugin, that gets you banned when using nospread :mad2:

I looked around and could find the source here (http://hg.nicholashastings.com/smac/files/0c33a97b53033b24d9c5e5467e98be72e6ba1be3/scripting/smac/eyetest.sp). The interesting part is:


Eyetest_OnPlayerRunCmd(client, Float:angles[3])
{
...
// +/- normal limit * 1.5 as a buffer zone.
if ( (angles[0] > 135.0 || angles[0] < -135.0 || angles[1] > 270.0 || angles[1] < -270.0)
&& IsPlayerAlive(client) && !(GetEntityFlags(client) & FL_ATCONTROLS) )
Eyetest_Detected(client, angles);
}

Basically it checks the view-angles of the player for possible values.
Therefore I tried to put this at the end of my CreateMove function:



cCmd->viewangles[0] = max(-134.0f,cCmd->viewangles[0]);
cCmd->viewangles[0] = min(+134.0f,cCmd->viewangles[0]);
cCmd->viewangles[1] = max(-269.0f,cCmd->viewangles[1]);
cCmd->viewangles[1] = min(+269.0f,cCmd->viewangles[1]);

but it seems to break the movement when strafing & attacking somehow :rolleyes2:, could someone give me a hint in the right direction?

Cheers
Listing

[how02]

...

[Listing]

Thank you for the fast answer!

I think what you do will not be enough to avoid a ban, if you look at


if ( (angles[0] > 135.0 || angles[0] < -135.0 || angles[1] > 270.0 || angles[1] < -270.0)

You see that it doesn't only verify that the angles are in (-360.0f, 360.0f) but in a smaller possible region. This is due to impossible view-angles like when anti-aim is used, those lead to a direct ban, however if I use those smaller angles in my application I am getting problems with the movement :rolleyes2:.

Also

memcpy(&pLocal + offset_EyeAnglesX, &tmp1.x, sizeof(QAngle));
What is the purpose of this bit of code? Note that tmp1.x is a float, hence its size is 4 bytes however sizeof(QAngle) is 3*4=12 bytes therefore you write too much into that structure (I guess pLocal is the local player entity).

[tang77]

zBlock was doing something like this and the fix was :



*(float*)((DWORD)pBaseEntity + 0x13F8) = qRealView.x; //m_angEyeAngles[0]
*(float*)((DWORD)pBaseEntity + 0x13FC) = qRealView.y; //m_angEyeAngles[1]

pLocalEntity->OnDataChanged( DATA_UPDATE_DATATABLE_CHANGED );


Where qRealView is unmodified viewangles.

[Listing]

Thank you, I got it now. You have to change the angles that are stored in the base entity struct not those in the cmd struct.

[tang77]

Hope that help ;)

[how02]

Yes it's float, not QAngle, didn't noticed my mistake before. Also, you can fix your movements by using this: http://www.gamedeception.net/threads/18764-Movement-fix

[tzoz]

Yes it's float, not QAngle, didn't noticed my mistake before. Also, you can fix your movements by using this: http://www.gamedeception.net/threads/18764-Movement-fix

No, it's not a float. It's a QAngle. Check again what m_angEyeAngles returns. It's even in the name for fuck's sake.

[syntroniks]

Hey folks, I have a feeling floats and QAngles are more similar than you may think :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/

[!Slrig]

Hey folks, I have a feeling floats and QAngles are more similar than you may think :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/
Mind = Blown.

Not really, since QAngles are just an array of floats, lawl.

[darkcat]

Mind = Blown.

Not really, since QAngles are just an array of floats, lawl.

In the end they all follow the 4byte alignment, vectors, ints, floats, qangles, pointers whatever.

[Sploosh]

Hey folks, I have a feeling floats and QAngles are more similar than you may think

Seriously, this thread.

[!Slrig]

I are teh leeb googler.

http://developer.valvesoftware.com/wiki/QAngle

Says it contains three vec_ts, which are...

http://developer.valvesoftware.com/wiki/Vec_t

A redefined float that "has no special properties."

Translation: "It's a float that's not a float because it has a new name. See: Machintosh" {For those of you who don't get it: It's FreeBSD but it's not because it says Machintosh OS on it.}

[Sploosh]

Vec_t is a valve's vector class, they're floats that aren't floats because they have operators written to make your life easier.

[battiboy]

zBlock was doing something like this and the fix was :



*(float*)((DWORD)pBaseEntity + 0x13F8) = qRealView.x; //m_angEyeAngles[0]
*(float*)((DWORD)pBaseEntity + 0x13FC) = qRealView.y; //m_angEyeAngles[1]

pLocalEntity->OnDataChanged( DATA_UPDATE_DATATABLE_CHANGED );


Where qRealView is unmodified viewangles.

Do you do this in CreateMove?

void CreateMove()
{
// do my stuff
CUserCmd originalCmd;
memcpy(&originalCmd, userCmd, sizeof(CUserCmd));

doAim(userCmd);
noSpread(userCmd);

QAngle* eyeAngles = NetVar::angEyeAngles0(local);
eyeAngles->x = originalUserCmd->viewangles.x;
eyeAngles->y = originalUserCmd->viewangles.y;
local->OnDataChanged(DATA_UPDATE_DATATABLE_CHANGED);
}

[tang77]

Do you do this in CreateMove?

void CreateMove()
{
// do my stuff
CUserCmd originalCmd;
memcpy(&originalCmd, userCmd, sizeof(CUserCmd));

doAim(userCmd);
noSpread(userCmd);

QAngle* eyeAngles = NetVar::angEyeAngles0(local);
eyeAngles->x = originalUserCmd->viewangles.x;
eyeAngles->y = originalUserCmd->viewangles.y;
local->OnDataChanged(DATA_UPDATE_DATATABLE_CHANGED);
}

lol ofc

[v3n0m4]

I are teh leeb googler.

http://developer.valvesoftware.com/wiki/QAngle

Says it contains three vec_ts, which are...

http://developer.valvesoftware.com/wiki/Vec_t

A redefined float that "has no special properties."

Translation: "It's a float that's not a float because it has a new name. See: Machintosh" {For those of you who don't get it: It's FreeBSD but it's not because it says Machintosh OS on it.}

this extrapolation can be pushed forward and then would be explaining all the 'ctrl c/v' of the worlds

[KN0WF34R]

this extrapolation can be pushed forward and then would be explaining all the 'ctrl c/v' of the worlds

C/P children of the world use context menus, not keyboard shortcuts. ;)

[battiboy]

Cant you just do this:

*(float*)((DWORD)pBaseEntity + 0x13F8) = 0; //m_angEyeAngles[0]
*(float*)((DWORD)pBaseEntity + 0x13FC) = 0; //m_angEyeAngles[1]
pLocalEntity->OnDataChanged( DATA_UPDATE_DATATABLE_CHANGED );

Because zblock only checks if the eyeangles are within certain bounds.

[semen]

you are all wrong.

[JouHn]

you are all wrong.

yeaahh they are lol

You just have to make your angles not going "too far". This is just a question of angles ... for example, an angle of 360 shows the same position as an angle of 180, but it's not the same value. If you can't understand that ...

For Pitch angle, in CS:S, limits are -89.0, +89.0 (cl_pitchup and cl_pitchdown). So :

if(fabs(m_angEyeAngles[0]) > 89.0f) ban(you);

Same for Yaw angle but it's more complicated for anti cheat coders to handle this angle since it is also modified when spawning / teleporting (-> false detection).

But :

if(fabs(m_angEyeAngles[1]) > 180.0f) ban(you);

So now how to fix this ?
Haven't you tried something like :
angle.x %= 89;
angle.y %= 180;

This is just an exemple but the idea is here MY FIX IS FALSE, another topic talks about that here and gives you the real value ... juste use the search button.

[wav]

yeaahh they are lol

You just have to make your angles not going "too far". This is just a question of angles ... for example, an angle of 360 shows the same position as an angle of 180, but it's not the same value. If you can't understand that ...

For Pitch angle, in CS:S, limits are -89.0, +89.0 (cl_pitchup and cl_pitchdown). So :

if(fabs(m_angEyeAngles[0]) > 89.0f) ban(you);

Same for Yaw angle but it's more complicated for anti cheat coders to handle this angle since it is also modified when spawning / teleporting (-> false detection).

But :

if(fabs(m_angEyeAngles[1]) > 180.0f) ban(you);

So now how to fix this ?
Haven't you tried something like :
angle.x %= 89;
angle.y %= 180;

This is just an exemple but the idea is here MY FIX IS FALSE, another topic talks about that here and gives you the real value ... juste use the search button.

An angle of 360 generates the same rotation matrix as an angle of 180. That's the better way to word it. Knowing that some angle rotations generate the matrix you need means even if your bounds are limited if you work the algorithim right you can still perform a good aimbot without tripping the detection.

[semen]

what I was talking about is that overwriting your local netvars won't bypass any serversided checks (zblock/smac anti aimbot etc.).

it just doesn't work like that.



yeaahh they are lol

You just have to make your angles not going "too far". This is just a question of angles ... for example, an angle of 360 shows the same position as an angle of 180, but it's not the same value. If you can't understand that ...

For Pitch angle, in CS:S, limits are -89.0, +89.0 (cl_pitchup and cl_pitchdown). So :

if(fabs(m_angEyeAngles[0]) > 89.0f) ban(you);

Same for Yaw angle but it's more complicated for anti cheat coders to handle this angle since it is also modified when spawning / teleporting (-> false detection).

But :

if(fabs(m_angEyeAngles[1]) > 180.0f) ban(you);

So now how to fix this ?
Haven't you tried something like :
angle.x %= 89;
angle.y %= 180;

This is just an exemple but the idea is here MY FIX IS FALSE, another topic talks about that here and gives you the real value ... juste use the search button.

I think what you want to do here is something like the following:



if ( angle.y > 180.f )
{
angle.y -= 360.f;
}

if ( angle.y < -180.f )
{
angle.y += 360.f;
}

[JouHn]

I think what you want to do here is something like the following:

if ( angle.y > 180.f )
{
angle.y -= 360.f;
}

if ( angle.y < -180.f )
{
angle.y += 360.f;
}

Not exatly, or yes if you do it in a loop like :

while ( angle.y > 180.f )
{
angle.y -= 360.f;
}

while ( angle.y < -180.f )
{
angle.y += 360.f;
}
I've already seen Eye Angles going over the value of 1000, this is possible too ...
So the better way would be to use % like :
angle.y %= 360;

But this is only my opinion. ;)

[semen]

I don't get your point though... are you doing valves job of fixing some bugs or what are you doing?

Same for Yaw angle but it's more complicated for anti cheat coders to handle this angle since it is also modified when spawning / teleporting (-> false detection).

[battiboy]

Sorry to keep bringing this up but I still get kicked, even after I fix the eye angles. Am I supposed to modify the eyeangles in CreateMove?

[largephallus]

Sorry to keep bringing this up but I still get kicked, even after I fix the eye angles. Am I supposed to modify the eyeangles in CreateMove?

This is what I have so far:



dear god what are you doing


overwriting your local netvars won't bypass any serversided checks (zblock/smac anti aimbot etc.).

[b4ckd0or]

Sorry to keep bringing this up but I still get kicked, even after I fix the eye angles. Am I supposed to modify the eyeangles in CreateMove?

Since this is where the data is sent to the Server it wouldn't be so bad.


QAngle* eyeAngles = ((DWORD)LOCALPLAYER + 0x1420); // angEyeAngles0

got it?

[battiboy]

Since this is where the data is sent to the Server it wouldn't be so bad.


QAngle* eyeAngles = ((DWORD)LOCALPLAYER + 0x1420); // angEyeAngles0

got it?

Thats what I am doing.

[b4ckd0or]

Thats what I am doing.

Aaalright:


what I was talking about is that overwriting your local netvars won't bypass any serversided checks (zblock/smac anti aimbot etc.).


QAngle* eyeAngles = ((DWORD)LOCALPLAYER + 0x1420); // angEyeAngles0

This is the place in your code where you do exactly do what logically will NOT bypass their aimbot detection, because of the reason you do set the viewangle only client sided. What you wanna do is modifying the viewangles which are sent to the server NOT the local.

As we all know the UserCmd is what is sent to the server you'll obviously have to modify something there.

In short:

userCmd->viewangles is what you need to modify.