Semiclip plugins hide players' names when aim

[RauliTop]

Solved by using the new hook added at ReHLDS: rehlds/ReHLDS#951

---

Yes, when you are using whatever semiclip plugin/module, and you are aiming at enemy or teammate that is not solid, you can't be able to read his name and hooking StatusValue won't work at plugins.

That is caused because of these lines checking traceline:
https://github.com/s1lentq/ReGameDLL_CS/blob/c002edd5b18a8408e299bc6cccfec2c7de56ba3d/regamedll/dlls/player.cpp#L7761-L7763

Well, possible solution?
I think about set solid all players before this check saving his solidtype in a var
and then, after the traceline check, set back his solidtype again

It will work and can create a cvar for enable this, for example: mp_fix_semiclip_statusvalue

[StevenKal]

That happens with basic semiclips, not with some enhanced ones. Use a "better" semiclip module/plugin can solve this (as one dealing with PM_* functions). But it might also depends on the settings you use on your semiclip.

[Vaqtincha]

https://github.com/rehlds/resemiclip
Works perfectly.

[RauliTop]

https://github.com/rehlds/resemiclip Works perfectly.

That module only has 4 semiclip options and can't be customized.

On plugins, you can customize your semiclip by adding other options rather than team.
That's when my request should be used.

[Vaqtincha]

@RauliTop You can customize resemiclip (opensource project)

[RauliTop]

@RauliTop You can customize resemiclip (opensource project)

a plugin is easier than a module.

[StevenKal]

A module is more efficient & allow much more possibilities, as it relies with C++ code which is way more powerful than pawn.
But pawn gives the advantage of the simplicity, so for people not knowing much about C++, compiling modules, etc., for sure a plugin is easier to modify yourself (or by others), or "get your modification requests done by people", as more people know Pawn than C++, and more active Pawn coders than C++ ones, on HL1 games.

Seems you use schmurgel1983's semiclip plugin huh?
Despite it has less functionnalities than the Team Semiclip one, method used in s1lentq's module is much better/reliable than his.

[RauliTop]

Seems you use schmurgel1983's semiclip plugin huh? Despite it has less functionnalities than the Team Semiclip one, method used in s1lentq's module is much better/reliable than his.

No, I'm using my own semiclip plugin.
I need A PLUGIN because I'm using NATIVES from other PLUGIN to communicating with it.

Is so many difficult to understand not all people can use a module?
For sure, I'm not the only person having this problem, but nobody notice it or they let it go.

[StevenKal]

But due to the problem you have, your own semiclip plugin might likely use similar method schmurgel is using, with solidity alteration, which is not much good in my opinion.
I personnaly totaly understand why people prefer plugins and I am also in favor of plugins for simplicity of coding & compiling.
After all, probably more than 90% of the addons users (servers's owners/admins) do not know C++, so module coding, and some do not even know "how to compile .sma files"!
But by modifying the module, you could also add natives to it.

But for your problem, if working on a module code is not possible for you for "your reasons", and, if you can not just use the other semiclip modules/plugins existing (or readapt them), I see at least two solutions:
1: Try reworking your semiclip method in your plugin, it might be good to deal with PM_Move & physent, but AMXX's ReAPI module does not handle all the structures (& sub ones) of the "playermove" structure (like "physent"), so you might need to use a memhack module for such purpose.
2: If you want to try your suggesttion in your first post (about setting & storing solidity before UTIL_TraceLine call), you can on your fork of the ReGameDLL_CS project to your GitHub, here, create a new branch like "semiclip-fix-test" (from master as base), then modify the related part on your branch. Once done, make a PR in your repo, from your master (not s1lentq's one), to your "semiclip-fix-test", then go into your Actions & it should compile you a new ReGameDLL with your changes. Also, for Windows compiling, set "windows-2019" in "github/workflows/build.yml" since GitHub has moved to VS 2022 this might refuse compiling without that or without other kind of changes in the workflows. But that single line (like I did here) is the simplest method for compiling it again with success.

EDIT:
Here (the *-semiclip-fix) you go! This does the job & so, fix your issue.
But you can still do that I said, create a new branch on your repo, edit on yours, the files I have changed on mine, then make a PR on yours, then push it or not to your "master" after that, (or you can let your "semiclip-fix" branch & push the master changes to yours). And when official s1lentq's ReGameDLL_CS is updated, just merge the new changes to yours, so your master should always have the official content, but + your semiclip fix always integrated.

[RauliTop]

Really thanks about that!

It could be better is you post a pull request here adding a cvar to enable that feature.

[StevenKal]

It could be better is you post a pull request here adding a cvar to enable that feature.

Certainly, but you can do it yourself at worst (if "emergency"), you have the files I modified here, I explained above how to do it and, if you want a CVar, just edit "game.<cpp|h>" files & add it around the fixed code in "player.cpp".
But for me this does not worth to add a CVar for this (imagine if we add a CVar for each "fix"!), might be better to permanently fix it in force like I did (or, if CVar, enable it by default in order to have the fix always applicable, when users do not paid attention to that CVar or forgot to enable it), except if the set/reset solidity can generate conflits with other things but I doubt, this just makes the function "pfnTraceLine" be able to detect the player on its trace, and, on a specific moment not dealing with two frames where other things can change.
I also did not PR because I wished to test it first, see if there is no possible conflict with X or Y thing or third-party stuff (but should not be the case).

Besides, if we PR, it is gonna be dormant for months as usual, & maybe even emits some annoying snore sounds! Hehehehehe! While you apparently wanted the fix "for yourself" at T instant.
But yeah this does not cost anything to submit it for sure!
I am just gonna put my personnal RGCS with it on my servers to test it on a specific duration first.

[RauliTop]

I'm talking about a cvar because not all people need this fix. So, it's irrelevant to have regame doing things not needed.

Only enable when needed.

Something like sv_rehlds_attachedentities_playeranimationspeed_fix cvar at rehlds

[StevenKal]

Yeah, knowing this is likely "only for such semiclip plugins", this might worth after all. So set it to "0" by default in such case.
But it is also good to "automatise" things intelligently when possible, because I learned that people usually do not read much various docs or config files, unfortunately, even if they are supposed to do it..., so at the end, some people like you (using similar semiclip plugin), may miss the "fix CVar" while it will be present...
And since this is done internally in C++, this does not hurt much to let the code alter this even if we do not use the feature.

I still think the CVar addition for this remains discutable, all depends on how many people use those kind of semiclip plugins. But from that I saw, most of them are not using such, but more the s1lentq's one or its Re* version linked by Vaqtincha.

EDIT: If you want, I pushed on your version the "distance fix" (status bar not working when aimed on a player/hostage beyond 2048 units). So download the "v5.21.0.563-semiclip-fix" (or above), or, my own version I use on my servers (*-personnal_v1) with a few more fixes.

[RauliTop]

Will be fine to have all this here as a pull request @StevenKal

[StevenKal]

Will be fine to have all this here as a pull request @StevenKal

& let it emitting some "loud snore sounds"...! Hehehe!

Besides, no offense, but I saw you before "take the side" of the other vaqDumb guy for this (here), while my PR was more intelligent about some fixes, so, forgive me if I do not feel to PR it, neither any other kind of PR here anymore...
But if you want I push latest official changes on my semiclip version, just ask, I will do it free.
But this is better for you to take my "personal version", which includes some fixes & changes additionaly to your semiclip workaround/fix. I could just add the latest 4 commits of the official version, that's all.

Also, I started at the begining of the year to work on my own enhanced ReGameDLL_CS, I did not work from some months on it, but I already did a good amount of things, & still have plans to continue to add the things I have in mind, which also includes this feature, so I will probably only focus on my own, not on this official one where PRs are too long to be merged, additionally to the fact approvers may not be in agreement with submitters's ideas & work, unfortunately.

[RauliTop]

& let it emitting some "loud snore sounds"...! Hehehe!

Besides, no offense, but I saw you before "take the side" of the other vaqDumb guy for this (here), while my PR was more intelligent about some fixes, so, forgive me if I do not feel to PR it, neither any other kind of PR here anymore... But if you want I push latest official changes on my semiclip version, just ask, I will do it free. But this is better for you to take my "personal version", which includes some fixes & changes additionaly to your semiclip workaround/fix. I could just add the latest 4 commits of the official version, that's all.

You said no offense but you are currently offended. LOL
I read about a problem, and I linked a pull that solves it.
I don't know what pull is better, only linked that because it's on the official github.

But, it doesn't mind...

I'm only asking you to have the pull request here.
It's not about get your pull updated with lastest version here, because I'm not using it yet.
I can get your pull and publish here if you don't want to do it... also adding the cvar I said you.

[StevenKal]

O.K.!

I personnaly use it in force without CVar, on my servers, I did not see any problem, but if you really care about a new CVar to control this (& make it off by default probably), and, know how to make PR, code to grab is there, just add a new CVar to control it (in "game.<cpp|h>" files for registration, then around the "UTIL_ManageClientsSolidity" functions used in "player.cpp").
And all will be done!

[RauliTop]

O.K.!

I personnaly use it in force without CVar, on my servers, I did not see any problem, but if you really care about a new CVar to control this (& make it off by default probably), and, know how to make PR, code to grab is there, just add a new CVar to control it (in "game.<cpp|h>" files for registration, then around the "UTIL_ManageClientsSolidity" functions used in "player.cpp"). And all will be done!

Why are you getting the value from sv_zmax?
Is another little fix? Is GameDLL showing the name of player whatever distance are you from him?

[StevenKal]

Because "sv_zmax" is maximum visible distance, set it to 100 on your server & you will see that happens!
You can put instead, on the code, a very high hardcoded number (like 50 000) if you want, to try bypassing "sv_zmax", but it makes senses on my opinion to deal with this CVar, as players will not see other people on screen.
With hardcoded like 50k, if you have a limited zmax value of like 2000, & player being at 3000 units, you will see his infos while aiming on him, but you will not see him on your screen, can be useful but well, I think better to rely on zmax to make the limits match.

And yes, this fixes this, at the same time. I do not think we need a CVar for such, no need to add a tons of CVars for "tiny" things that should just behave more logically naturally.

[RauliTop]

Because "sv_zmax" is maximum visible distance, set it to 100 on your server & you will see that happens!

Yes, I know it.

Reviewing code again. Now I get it.
GameDLL uses hardcoded MAX_ID_RANGE = 2048, so is limiting to that units. Doesn't care about sv_zmax value.

Your pull is always using the units of sv_zmax.
I don't think is a good idea. The game wants to show you the map but doesn't want to show you the name of far enemies.

[StevenKal]

For me it makes sense to use zmax with this, because however, if you have like zmax 1500 & a player at 2500 units, you might see a name but not him visually, I am not really saying my method via zmax is better, just more logic, while a very high hardcoded limit can bypass this restriction for sure, but you might not see it, & feel it a bit weird to have players infos "of a player you can not see", like "what the fuck are those infos of a player I can not see? It this a bug?".
Feel free to do like I do or use a high number like 50 000, or ask other people opinion.

[RauliTop]

OK, so. The correct way will be:
If sv_zmax < MAX_ID_RANGE or MAX_SPEC_ID_RANGE, just use sv_zmax value.

Only on that situation.

Other situations are wrong, because as I said before:
The game wants to show you the map but doesn't want to show you the name of far enemies.

[StevenKal]

Default values (hardcoded ones) for *_ID_RANGE are already large, I do not see much the problem to rely on CVar "sv_zmax", being even higher, this just ensure anyone can see names until map end visibility, this is logic.
But as I said, do as you wish or ask other people opinion.
You can submit the PR as it is then ask below about possible other way you prefer yourself, and if approver(s) agree with you, PRs can be edited to match your preferences, no problem.

[RauliTop]

You are mixing ideas.

The issue I'm talking here it's about only names because of semiclip plugins using solidtype.
The other issue we are talking is about distance when you aim a player.

Can be done on different PR, because they aren't the same problem.

[StevenKal]

This is because your "semiclip fix" touched the same part of code that affects aiming distance on player, so I took this opportunity to adjust this at the same time when I did the PR on my repository, for you.
Just drop "sv_zmax" related code on your PR if you do not want to put this too in the PR, you can easily see modified part here, before & after, with colors (red/green).

[SergeyShorokhov]

Is so many difficult to understand not all people can use a module?
For sure, I'm not the only person having this problem, but nobody notice it or they let it go.

If you are breaking the behavior of gamedll with the plugin, it would be logical to fix it there, in the plugin. Specifically in this case.