s1lentq / ReGameDLL_CS

:hammer: Reverse-engineered gamedll (CS 1.6 / CZero)
GNU General Public License v3.0
579 stars 198 forks source link

Observer bug in First Person #865

Open axl303 opened 1 year ago

axl303 commented 1 year ago

I'm just gonna paste @francoromaniello's message,

The game have a bug when you are specting in first person, quickly changing players it is possible to "bug" the game and see through walls for a fraction of a second. This hook is needed to try to fix this bug.

https://github.com/s1lentq/ReGameDLL_CS/pull/667

Can this be fixed or is a 3rd party plugin available somewhere?

dystopm commented 1 year ago

First, if you want to discard any 3rd party plugin bug trigger, test in a pure environment (with regamedll), and then provide some kind of record to demonstrate the issue. But I'm certainly sure it's a client-side rendering issue

axl303 commented 1 year ago

Currently running a clean server (pure environment): Rehlds (latest) - 3.13.0.788 RegameDLL (latest) - 5.22.0.593 Metamod-R (latest) - 1.3.0.131 AMXX is not used or any other plugin loaded by metamod.

The bug is old and still exists. Tried with some (UTIL_VecToAngles) to make a fix or adjustment, but don't have coding skills or event I don't know If this is the way to do it.

But I'm certainly sure it's a client-side rendering issue

I myself think the same, but not fully sure and I think it can be adjusted/fixed from server side.

dystopm commented 1 year ago

Currently running a clean server (pure environment): Rehlds (latest) - 3.13.0.788 RegameDLL (latest) - 5.22.0.593 Metamod-R (latest) - 1.3.0.131 AMXX is not used or any other plugin loaded by metamod.

The bug is old and still exists. Tried with some (UTIL_VecToAngles) to make a fix or adjustment, but don't have coding skills or event I don't know If this is the way to do it.

But I'm certainly sure it's a client-side rendering issue

I myself think the same, but not fully sure and I think it can be adjusted/fixed from server side.

Thanks for providing that information. Any possibilites to attach some kind of video? I'll have my pc far away these days (rn in my office)

axl303 commented 1 year ago

Sorry for the external video link, but Github has 10MB limit on files and the video is 20mb. Here it is: https://streamable.com/lwm8jy (Expires in 2 days, will renew it if needed)

From the video you can see the camera glitching walls etc, also if you can review the video multiple times (replay) you can also see the players through walls when quickly or sometimes not. Just like the person franco (quoted him) said.

If some more familiar with this bug can comment will be cool, maybe wopox from Fastcup or some 5v5/competitive server owner/player which knows the bug.

dystopm commented 1 year ago

Thanks for the video, nothing too far from what I experienced also in the past. Just wanted to refresh my memory about it. @s1lentq this has something related with interpolation? Using EF_NOINTERP or something related would cause no effect?

axl303 commented 1 year ago

Just tried to set it with the following code in FindNextPlayer m_hObserverTarget->pev->effects = EF_NOINTERP and it doesn't work, not sure if this is the correct method. Just wanted to help or try to save you some time.

Used it below line 193 https://github.com/s1lentq/ReGameDLL_CS/blob/master/regamedll/dlls/observer.cpp#L193

justgo97 commented 1 year ago

I think a possible workaround for this bug is to make all players invisible to the spectator before starting the transition and then reset the visibility back to normal once spectating the new target.

axl303 commented 1 year ago

I think a possible workaround for this bug is to make all players invisible to the spectator before starting the transition and then reset the visibility back to normal once spectating the new target.

Or just the players from opposite team (depends from the force camera cvars), also not fully sure how they will appear when player (the spectator) just switch between teammate's cameras and suddenly a enemy appears magically on his screen + the demos. But I think it is a possible workaround if nothing can't be done from server side.

dystopm commented 1 year ago

@axl303 it does not work that way. First of all, you have to be sure of what are we discussing here, and by just looking at the video, problem isn't the fact "you can see the enemies while changing spec target", it is the fact origin has some grade of interpolation between every point you are changing. In this particular scenario, position changing while spectating must be immediate without any interpolation (smoothness) between every change. That's why I mentioned that FLAG, which you were setting (wrongly) on your current spec target, which has nothing to do with the issue, because it is the complete environment. It may have a fix on client-side directly, but server-side speaking I cannot figure something. @s1lentq has more knowledge on client-side, which may have an approach or idea as to why this smoothness occurs.

axl303 commented 1 year ago

I found it cl_smoothtime 0 will fix the problem. Tested and it works! From: https://github.com/ValveSoftware/halflife/issues/258 Since it is a client command should be related to the client right? And I don't want to force any commands (slowhacking like) to the client, so is there a way from the sever side to adjust/fix or to make a correction? @dystopm Thanks for the good explaination, you the best :)

dystopm commented 1 year ago

I found it cl_smoothtime 0 will fix the problem. Tested and it works! From: ValveSoftware/halflife#258 Since it is a client command should be related to the client right? And I don't want to force any commands (slowhacking like) to the client, so is there a way from the sever side to adjust/fix or to make a correction? @dystopm Thanks for the good explaination, you the best :)

So it was about a certain smoothness applied in the client-side.

Nothing can be done from server-side, more than getting client's cvar value with pfnCvarValue function and prompting that information to the client (like, "please change it").

There is not some kind of correction that can be done, client program is the one who is interpolating the origin changing, server knows client is on position A and then on B while changing target on spectator mode, and nothing else, you can't force from server-side to "hasten" the smoothness process.

axl303 commented 1 year ago

That's everything I wanted to know. Well I hope this issue (the comments) to help to others like me searching for some information about this bug.

Hoping one day mikela from valve or other valve employee to fix the things up. Some sunny suday maybe (2040 year). Or some user here in Regamedll repo.

Thank you for the comments @dystopm @justgo97 I really appreciate them. Also thank you for the work and PR's you do. Also big thanks for s1lent and all contributors. Keeping it alive as much as they can. ❤️

abecee commented 12 months ago

I found it cl_smoothtime 0 will fix the problem. Tested and it works! From: ValveSoftware/halflife#258 Since it is a client command should be related to the client right? And I don't want to force any commands (slowhacking like) to the client, so is there a way from the sever side to adjust/fix or to make a correction? @dystopm Thanks for the good explaination, you the best :)

Hi. It doesn't work for me... I mean if i have cl_filterstuffcmd 1 the plugin doesn't work anymore and if they still have filterstuffcmd but they have cl_smoothtime 0, it doesn't seems to work out ( tested right now with bots... ) or maybe it's because of bots?!

dystopm commented 12 months ago

I found it cl_smoothtime 0 will fix the problem. Tested and it works! From: ValveSoftware/halflife#258 Since it is a client command should be related to the client right? And I don't want to force any commands (slowhacking like) to the client, so is there a way from the sever side to adjust/fix or to make a correction? @dystopm Thanks for the good explaination, you the best :)

Hi. It doesn't work for me... I mean if i have cl_filterstuffcmd 1 the plugin doesn't work anymore and if they still have filterstuffcmd but they have cl_smoothtime 0, it doesn't seems to work out ( tested right now with bots... ) or maybe it's because of bots?!

I didn't get if you wrote that command in console by yourself

abecee commented 12 months ago

I found it cl_smoothtime 0 will fix the problem. Tested and it works! From: ValveSoftware/halflife#258 Since it is a client command should be related to the client right? And I don't want to force any commands (slowhacking like) to the client, so is there a way from the sever side to adjust/fix or to make a correction? @dystopm Thanks for the good explaination, you the best :)

Hi. It doesn't work for me... I mean if i have cl_filterstuffcmd 1 the plugin doesn't work anymore and if they still have filterstuffcmd but they have cl_smoothtime 0, it doesn't seems to work out ( tested right now with bots... ) or maybe it's because of bots?!

I didn't get if you wrote that command in console by yourself

So the plugin has to do it?

abecee commented 12 months ago

I think a possible workaround for this bug is to make all players invisible to the spectator before starting the transition and then reset the visibility back to normal once spectating the new target.

I searched on the internet to see if I could find such a plugin, but found nothing. Any ideas?

axl303 commented 12 months ago

@abecee

Hi. It doesn't work for me... I mean if i have cl_filterstuffcmd 1 the plugin doesn't work anymore and if they still have filterstuffcmd but they have cl_smoothtime 0, it doesn't seems to work out ( tested right now with bots... ) or maybe it's because of bots?!

Please read what dystopm said in his comments (all of them).

The problem is in the client, there is no plugin to force the command or whatsoever. This means you have to find another alternative maybe what @justgo97 said to make invisible or just dark screen until respawn (fadetoblack). I've searched the AMXX forums and found only one by perforator which forces (trying to) cl_smoothtime 0 by MSG - Doesn't work anymore with cl_filterstuffcmd 1

You can't solve it by force a command to the client and it's not good to force command on the client (I know some players are playing with bad rates/command, for example: cl_lw/lc 0 or some other commands/things which may lead to bad things or whatsoever, but forcing is not the way to do it!) cl_filterstuffcmd 1 a good addition/command.

@wopox1337 - Sorry for the tag, if you can tell more about this topic? Is fastcup forcing that command through AC (Anticheat) or something else? Or some other 5v5/competitive owner or enthusiast loving to find/fix/correct bugs?

Personally I think the fix should be to the client/observer camera OBS_IN_EYE only and not even with this command?

dystopm commented 12 months ago

I found it cl_smoothtime 0 will fix the problem. Tested and it works! From: ValveSoftware/halflife#258 Since it is a client command should be related to the client right? And I don't want to force any commands (slowhacking like) to the client, so is there a way from the sever side to adjust/fix or to make a correction? @dystopm Thanks for the good explaination, you the best :)

Hi. It doesn't work for me... I mean if i have cl_filterstuffcmd 1 the plugin doesn't work anymore and if they still have filterstuffcmd but they have cl_smoothtime 0, it doesn't seems to work out ( tested right now with bots... ) or maybe it's because of bots?!

I didn't get if you wrote that command in console by yourself

So the plugin has to do it?

I mean, you tested it by writing the command yourself in console? That is what we were arguing here