Little-Anti-Cheat Discussions

[J-Tanzanite]

Discussions 🗣️ 💬

So Apparently this is a new feature on github, which is nice.
I think this is a perfect place for people to:

• Ask questions
• Talk about Lilac
• Leave suggestions

And I can leave general updates about the project and the current situation.

If you have an issue, I still recommend you use the "issues" page.

[tappeh]

Is it possible to make the cheat detection logs go to like a mysql or somthing like that?

[azalty]

I don't know a thing about file splitting, but I don't see how you're going to pass all needed arguments efficiently through natives.

SQL queries will be asynchronous as well to prevent server freeze, so forwards are needed for callbacks, and again, it's dumb, because everything will be done on LilAC side, so no point on doing all that

Edit: since this is only about logging, either LilAC could call a native from the logging plugin and passing the message, steamid/client index or lilac could expose forwards that the logging plugin will get and log when they are called (idk if it's the case yet). No callbacks should be needed for that.

[J-Tanzanite]

My English isn't perfect, and I couldn't quite make sense of your message.

I assume your initial paragraph is referring to the string splitting and how Lilac would pass all those strings to the native.
It wouldn't work like that, although the strings are split, they would all get concatenated when doing file logging into a single long string. It would from there pass the entire string to the native.
Which is how it would work for the Discord plugin as well.
It seems like a weird thing to do, but it makes sense to do it like this when you consider in-game chat detections for admins.

The reason for this is pretty simple, logging the entire detection in-game chat for admins would be too long, so it has to be shortened; hence the splitting.

---

Although, there is another way to go about the in-game chat detection messages for admins which I haven't thought about until now... Which... Would make the string splitting useless...

Anyway, I made the suggestion of SQL logging being it's own plugin in case other plugins wanna do logging through SQL as well. But if you don't think that's needed, then ok. ¯\_(ツ)_/¯
I don't know SQL so don't know what's best in terms of going about it.

[azalty]

Why would other plugins do SQL through LilAC's DB plugin?

Spoil: I'm not very good at English too

[J-Tanzanite]

"Lilac's DB"...
Wait, you're talking about SQL having a dedicated DB for lilac detections only?
...
Oh... Yeah now it makes more sense xD
I'm stupid :P

[azalty]

SQL Structure

-> Database
--> Table(s)
---> Data (rows)

We can use the default SQLite "sourcemod-local" database or create our own, we probably only need one table (a custom MySQL db is required in case you want to use MySQL, but again, if it's not going to be used by multiple servers at the same time it's not needed)

I don't see why any other plugin would want to call LilAC's natives

1. Plugins use their own SQL functions
2. No one needs to write/get data to/from LilAC's table, and if for some reason they need to, they can just write their own SQL functions