Adding playername to logging

[ghost]

Hi,

For troubleshooting and debugging of issues, it would make life more straightforward if the player name could be added to the entry that is logged to server_log.txt:

For example: [Nex-AC] ID 26 appears suspicious. Reason code: 047 (2)
Could become: [Nex-AC] ID 26 (playername) appears suspicious. Reason code: 047 (2)

That way, inside of parsing the logs with "grep 26 server_log.txt" which would return all sorts of irrelevant results, one could simply "grep playername server_log.txt".

Is it possible to do this without too much trouble?

Many thanks

[NexiusTailer]

I thought about it and most likely you are right. Despite the fact that in most cases you can search by nickname and you will find the desired player by disconnect message (which will be exactly after the anticheat kick message), there are also several cases when anticheat might not kick or ban a player and just log about it. So then it becomes really difficult to find him only by his ID.

But even if I try to add player's name to the log messages right now, there are several difficulties associated with the backward compatibility of localization versions, which has actually never changed since the release and doesn't have even a definition of the version by which it would be able to check its relevance to avoid conflicts.

[ghost]

That's understandable, thanks.

I've had some reports of suspected false-kicks by Nex-AC from my players. To investigate them, what I'd love to be able to do is simply "grep playername server_log.txt" so that I can see what commands they used leading up to the kick (i.e. did they open a dialog, join a minigame, etc).

But right now I would have to find the player name in the logs, then get their ID, and then search the logs for everything under that ID, which is a bit of a pain.

I don't suppose you have any suggestions to make this easier?

[NexiusTailer]

I don't suppose you have any suggestions to make this easier?

The only intention that I have now is to make it easier in the second (v2.0) version of the anticheat that I am currently developing. It won't have backward compatibility with existing version and much things including this one will be completely rewritten.

[alextwothousand]

I'm working on a fork of Nex-AC, versioned 2.0.0. I will add this.

[NexiusTailer]

@alextwothousand Original v2 is still in development so you can just PR anything you consider important here if it will not break any compatibilities like:

• Adding/swaping/deleting numerical anti-cheat codes (although it is not a problem to add new checks to the existing ac codes)
• Changing basic API from v1.0 (OnCheatDetected and its arguments in particular)
• Changing .lang files in any form as they don't have versioning

Thus, these are the simple principles that I'm personally guided by even now and this can be bypassed in my new 2nd version. But currently it makes little sense for someone else to fork, calling it a "successor" through "v2.*" in the version. This way you will just create confusion when the real v2 comes out.

UPD: Even if you're really want to make your own fork with some radical changes which may also contradict my "compatibility conditions" above and thus cannot be merged here, you can look at this example, where a person develops his fork under a different name, where it's quite easy to implement everything he needs (even including my help sometimes as it's also interesting to me). This way it clearly stated as a side project and there is no confusion when somebody search for "nex-ac" or its "rakcheat" fork.

[alextwothousand]

It isn't going to be a separate fork, I would genuinely like to make PR's and improve nex-ac.

Here's what I plan on doing:

• Utilising YSI@5.x for hooks.
• Utilising YSI@5.x for loading language files (ini instead of pwn/lang files)
• Cleaning up the code, improving readability and modulating it.

Here's what I don't plan on doing:

• Moving away from OnCheatDetected (other than const correcting it)
• Modifing / rearranging the current numerical anti-cheat codes.

Update: In essence, it is literally a partial overhaul of nex-ac, enough to improve it in someway.

[NexiusTailer]

Any YSI library can be used only as optional dependency like it is now with YSF, SKY, weapon-config, Streamer Plugin, foreach, sscanf and Pawn.RakNet. I am against "required" dependencies, because any problem with them entails problems in my module. Moreover, starting from the first version to this day, anticheat does well without the obligatory presence of any of the things above, while being able to work correctly with their connection.

As for that:

Cleaning up the code, improving readability and modulating it.

Would be interesting to see your suggestions.

[alextwothousand]

OK.

Instead, I will stick to the current code base, and just const correct it to support the 3.10.10 compiler.
Following that, I will potentially implement the ini loading. Would you prefer if I parsed it myself manually, or used a lightweight ini parser, like Southclaws/samp-ini?

[NexiusTailer]

Any const-correctness must be implemented without breaking compatibility with default pawn compiler. Just adding "const" everywhere you only make it impossible to use the include with the default samp includes & compiler which don't have "const" definitions in their natives so that ac will call it with argument mismatch errors. I described this problem in more detail here and here.

Following that, I will potentially implement the ini loading. Would you prefer if I parsed it myself manually, or used a lightweight ini parser, like Southclaws/samp-ini?

Optional dependency consider there is always manual way of doing something you do with this dependency, so yes, you can use anything you want, but there should be another built-it variant (ini-reader/writer for this case)

[alextwothousand]

Any const-correctness must be implemented without breaking compatibility with default pawn compiler. Just adding "const" everywhere you only make it impossible to use the include with the default samp includes & compiler which don't have "const" definitions in their natives so that ac will call it with argument mismatch errors. I described this problem in more detail here and here.

Following that, I will potentially implement the ini loading. Would you prefer if I parsed it myself manually, or used a lightweight ini parser, like Southclaws/samp-ini?

Optional dependency consider there is always manual way of doing something you do with this dependency, so yes, you can use anything you want, but there should be another built-it variant (ini-reader/writer for this case)

If I'm being honest, anyone who still uses the old compiler needs to move on from it. The new compiler is miles better, and besides, they can always revert to, say, 1.9.55, if they need that compatibility.

The lack of const-correctness is reminiscent of the past at this point.

[NexiusTailer]

To be honest from my part, I find it simply the stupidest and absolutely irresponsible decision to introduce such radical warnings by the pawn-lang team, which forces users to choose between two compilers, introducing such incompatibilities out of nowhere. On their part, it was possible to disable it by default or at least disable it in compatibility mode (-z flag). The very fact of such an uncompromising decision about the functioning of these warnings just by default resented me from the very beginning. Perhaps this is one of the reasons why this include still does not have any support at all.

UPD: There is still sa-mp.com/download.php section which share default pawn compiler and that is the main problem. This is still considered the official SA-MP compiler in the official SA-MP server package.

[alextwothousand]

Fine. Have it your way.