Add getSystemInfo function#2267
Conversation
This comment has been minimized.
This comment has been minimized.
|
Nice, this will allow scripters to make scripts smarter (estimate how high-end player's PC is, and decide if they will load heavy mods and scripts or limited / more optimized lightweight versions) Also, in my eyes this function is fine to return basic GPU specs (model name & video mem), with a note on its wiki page saying |
|
Why exactly is this needed and how would that be used to "optimize" scripts? |
|
I think it's main use would be to compute some kind of "performance score" for the client PC, and deciding things like what models to load or what code to run based on that score, as @Dutchman101 said. Obviously, you can't trust things like clock speed or available memory alone (fun fact: I have an old single-core Pentium D from around 2005 lying around that goes up to 3.4 GHz, and obviously nobody would claim that is a good CPU nowadays, despite its high clocks), but if you mix them using some kind of model (i.e. "if this CPU has more than 4 cores, is an Intel Core or Ryzen and has at least 3 GHz of base clock speed then it should be good") you could get pretty interesting conclusions. The alternatives I can see that are possible right now are:
All in all, while I concede that this function is not exactly the most privacy-friendly and easy to use thing in the world (I'm scared that some scripters may hardcode a list of hardware names and, in general, use it in a sloppy way and call it a day), I can definitely see some interesting use cases for it. Although maybe MTA can already provide scripters with a "performance score", similarly to what the Linux kernel does when computing the "bogoMIPS" (but hopefully better)? |
|
This function is a paramount for heavily modified servers. Knowing basic information about player's hardware will allow to greatly improve user experience and possibly even reduce amount of crashes. Currently I use relatively ugly approaches to handle low-end PCs. The main one would be to wait for "memory overflow" error (if lucky player wasn't crashed before it showed) and then unload models, switch to low-performance mode (optimized for low end PCs) and load again. Knowing information about player's CPU and physical memory will allow to select best suitable loading mode in advance which is way better. It would also allow to create different loading profiles for different category PCs (so not only generalized "low end" / "good enough specs" but more categorized). Other approaches were tried over the years too. Like selecting "graphics settings" before loading. This one is nearly useless because most players don't tend to read detailed information or benefits of different modes (or even understand what mode will be the best suitable for them) and just click "high" or something similar. And then in some cases it lead to crashes (either due low amount of memory or something else). Fast benchmarking approach was tried too but in some weird cases it froze the client so it was removed basically after a week of public testing. Also benchmark results were not really reliable. I still keep manual override options for advanced players tho (so they could override server selected models and textures loading options). Another benefits that I see here (besides creating different models loading profiles):
I think it also makes sense to add information about currently available amount of physical memory or / and current memory usage of gta_sa.exe process. It might slow down this function tho (I'm not sure). But it could be useful to know for sure in advance how many models can be replaced without crashing the client or producing overflow errors. I don't really see any downside here. I wouldn't be too worried about some scripters using it for lazy scripting techniques. There are many ways to create sloppy things right now and this function wouldn't make a difference in this regard IMO. Anyway, my apologies for this long comment but it's quite an interesting topic and really useful function. It would be nice to see it reviewed, tested and merged soon since it could provide many benefits right now even before IMG related features are integrated. |
patrikjuvonen
left a comment
There was a problem hiding this comment.
I stand against this feature until it can provide a way to disable sharing the information to scripts via settings menu.
| { "RAM", (lua_Number)gpu.memoryKB}, | ||
| { "Name", gpu.name }, |
There was a problem hiding this comment.
Inconsistent use of whitespace.
| { "RAM", (lua_Number)gpu.memoryKB}, | |
| { "Name", gpu.name }, | |
| {"RAM", (lua_Number)gpu.memoryKB}, | |
| {"Name", gpu.name}, |
| uint32_t MaxClockSpeed = 0; | ||
| std::string Name = {}; | ||
| uint32_t NumberOfCores = 0; | ||
| uint32_t NumberOfLogicalProcessors = 0; |
There was a problem hiding this comment.
Indentation is inconsistent.
| uint32_t MaxClockSpeed = 0; | |
| std::string Name = {}; | |
| uint32_t NumberOfCores = 0; | |
| uint32_t NumberOfLogicalProcessors = 0; | |
| uint32_t MaxClockSpeed = 0; | |
| std::string Name = {}; | |
| uint32_t NumberOfCores = 0; | |
| uint32_t NumberOfLogicalProcessors = 0; |
| WMIProcessorInfo CPU = {}; | ||
| uint64_t TotalPhysicalMemory = 0; // In KiB |
There was a problem hiding this comment.
Indentation is inconsistent.
| WMIProcessorInfo CPU = {}; | |
| uint64_t TotalPhysicalMemory = 0; // In KiB | |
| WMIProcessorInfo CPU = {}; | |
| uint64_t TotalPhysicalMemory = 0; // In KiB |
| SString GetWMIOSVersion(); | ||
| unsigned int GetWMIVideoAdapterMemorySize(const unsigned long ulVen, const unsigned long ulDev); | ||
| long long GetWMITotalPhysicalMemory(); | ||
| WMISystemInfo GetWMISystemInfo(); |
There was a problem hiding this comment.
Indentation is inconsistent.
| {"tocolor", tocolor}, | ||
|
|
||
| #ifdef MTA_CLIENT | ||
| {"getSystemInfo", ArgumentParser<mta::GetSystemInfo>} |
There was a problem hiding this comment.
Missing trailing comma.
| {"getSystemInfo", ArgumentParser<mta::GetSystemInfo>} | |
| {"getSystemInfo", ArgumentParser<mta::GetSystemInfo>}, |
Just for the record, in case I didn't state my thoughts clearly on my previous comment, judging by the downvotes and the overall "I would love to see this added and here's why" tone of this comment: I think that this function can be a good addition to MTA. I was just pointing out some considerations that I think are worth thinking about before this is merged in a final release. |
I probably never gonna understand why some game developers so against basic and necessary functionality for a game.. Specially when we already had GPU information for years. Just wanna point out something. Disabling this kind of necessary functionality in the settings would create additional issues and potentially not user friendly behavior. In my case i would probably need to drastically change models loading flow in order to ask the user to share hardware information prior loading. Or simply kick a player (which is a really really bad thing but many servers that will require hardware information will probably do it this way). Similar to how some servers handle "Allow screen upload" checkbox right now.. I remember in the beginning it wasn't a problem with "screen upload". Just removing some functionality from users with disabled option was enough. But later "render targets" became a part of necessary functionality and i had to force all users to enable this option so they wouldn't lose gameplay features. In this case of course it's not hard to do it without kicks using banner (unlike hardware information which is mostly required prior regular models loading flow). It's surprising why one of the greatest multiplayers created lacks necessary scripting functionality. Starting from detailed hardware information and ending with client settings (like for example "Audio" volumes). Something is holding us back :( |
Privacy. |
I understand this point. Thank you. Personally I hardly see any privacy issues with knowing client's hardware. After all, it's a game (multiplayer). And the game is hardware dependent. |
While it can be argued that the device information this function provides is pretty basic, device fingerprinting is an actual concern that has already seen some bad uses. Wikipedia has a good article about the subject. I definitely wouldn't want to introduce a function that may help such activities without even thinking about it. Besides, making it an option means that you can handle the setting being disabled, as you discussed previously, as you seem fit for your server. It's possible to do the check in a separate resource that loads before the bulk of your resources, so you can take the corresponding action before any model gets loaded, and handle any synchronization via events. Personally, I wouldn't mind such an option being enabled by default, much like CEF is not entirely disabled by default, so I don't think that user-friendliness should be impacted that much for those who seek that "plug and play" experience. |
Of course it can be handled. But like I mentioned, it will lead to unnecessary steps and complications. Typically users don't like complications (proven in many areas of life and specially in online games). Besides, making it optional will not solve device fingerprinting in any way. And for advanced users hardware information spoofing isn't something too complicated. So arguably speaking making it an option is counter productive (if we are talking about potential bad usage). |
Trivially, if a script can't get fingerprintable information at all, every device fingerprinting concern is solved, because device fingerprinting can't happen in the first place. While I agree that spoofing this information solves most concerns related with fingerprinting, I don't think we should make advanced users lives harder just because they are already advanced, the same way we should not make not-so-advanced or privacy-conscious users lives harder by having to explicitly enable such an option.
This is a fair point. I usually advocate for using each new feature as an opportunity to apply experience or new knowledge that would arguably result in a better software design overall, though, because I fear technical debt creeping up my back quite a bit. |
You are right. Though I was talking about developers not letting users in unless hardware information is shared. So if some server decides to use hardware information with the sole purpose of device fingerprinting then it would be a way to go. This is why I mentioned that option is "counter productive" and I believe there is no perfect solution for this particular problem (if we even consider this as a problem). For example I don't consider this as a problem in 2021 because it's already possible to use different forms of device or in-game behavior fingerprinting without this function (and it can be quite effective). |
Unless we can know the amount of ram the game process is using, forget about preventing people from "out of memory" crashes. |
Servers can see your IP address and you're worried about them seeing the name of your CPU..? |
|
to make one thing clear: |
|
Isn't the |
|
I don't want my GPU information to be read by scripts. |
|
That's already done by |
|
I find this entire privacy concern heavily exaggerated Your main concern would be device fingerprinting right? Well, the best way for server owners to fingerprint a player is already built into MTA: serials. It can't get worse than that, so having a scripting function that returns CPU and GPU name doesn't do much after that point. Of course, we can add a client option similar to others (e.g "Allow external sounds" and "Allow screenshots"), but that would be wasted developer effort on this PR as it brings no additional privacy value, and may only complicate a server scripter's job of educating players that they need to allow getting PC specs (either to let the game run properly, or as some servers would do - barr the player unless they allow it, and make a tooltip or something instructing them to enable it. It's all wasted effort, as players like to fiddle with random options without a particular purpose of allowing/disallowing something) |
|
Anyone that wants to, feel free to adopt this PR |
|
This draft pull request is stale because it has been open for at least 90 days with no activity. Please continue on your draft pull request or it will be closed in 30 days automatically. |
|
I will create a new PR soon. 😄 |
|
This draft pull request is stale because it has been open for at least 90 days with no activity. Please continue on your draft pull request or it will be closed in 30 days automatically. |
@Nico8340 |
Yes |
|
Bump? |
|
PR abandoned ? |
|
I just saw that there is such a PR with some funny comments on it. I don't get it why some people dragged here the privacy concerns. For me, privacy concers came into my mind, when a software does much more than these. When it logs my activities/actions OUTSIDE of the software. When it logs my browsing history for e.g. When it logs my file architecture alongside its content. When it listens to microphone/webcam, etc. Note: There are known aggressive kernel ACs like Vanguard which even collects some of these mentioned sensitive data and there are huge concerns about this process. If I connect to a server, I know that everyting I do on it, will be logged. YES, even private messages. Server owners, server administrators must have the full power to fight against their malicious users. If you don't want your server owners to read your pms, then use other software for communitacion. But again, if you use discord for example, or messenger, then Facebook and Discord will read your messages. There is no such things like 'no one reads it only me and my partner'. In my opinion this PR is okay, but lacks of more detailed data. Keep in mind that even this: https://wiki.multitheftauto.com/wiki/Fingerprint MTA serial system can no longer be trusted. Serials can easily be spoofed into anything. What can we do to prevent cheaters from coming back? Ban by nick? They choose another. Ban by serial? They spoof it. Ban by IP? They use VPN. Implement VPN-Detect API usage? There are VPN IPs which won't be detected by any of the apis on the internet even if you pay for one. Topic about map/mod optimisaiton: This PR would sufficient their needs as well, however I maybe read something which I misundrstood, but you can't avoid some players to not to download some files if their PC is lowend. On connect every running resource will be automatically downloaded. You can disable certain things to be loaded for e.g textures which would be the benefit of this PR. (maybe I misread something there are huge ammount of comments anyway) I just would like to read the answers and reason why knowing such hw infos of a user would break user privacy. |
|
Not everyone shares your opinion. That being said it all depends what will we introduce to mta. Collecting machine info only? Okay, fair. |
I understand that there are different opinions, thats not the problem. What I don't understand is having a CPU name how can be malicious to a user if a server knows what CPU the player uses? I comepletely agree with all these you wrote (in quoted) This is what I wrote as well in more detail. |
|
I still don't really see a convincing reason why a script/server/client needs this sort of information. For process memory there is |
There are ways to make it harder for client to fake this information. Implement getSystemInfo on server side. Send packet with client specs to the server on connection as part of other client data. Sure, it will not stop last gen cheats from sending fake packet. But it's usually harder to do than hooking and spoofing Lua data on client side. And it is better than relying on client side function. The truth is this. The current state of MTA AC leaves servers no choice but to fingerprint cheaters and try to make ban evasion as hard as possible. Accounts system with 2FA don't stop the abuse and don't even slow down cheaters anymore. Getting hardware information is also important to make better security for normal accounts (users) and prevent potential abuse.
So instead of good performance profiling you suggest to add new setting that could be abused by any user (in a lot of cases servers use more optimized but less accurate approach for different things on low end computers and it's ok as long as the number of low end computers isn't too high but if any user with good specs can fool the server by using this simple setting then it will potentially create more competitive advantage issues than any current solution that is based on client specs). |
I think that adding a server graphics option in the configuration could be quite useful, but yeah the profiling would be good to catch cheaters and ban evasors (serials are simply too easy to spoof, when serial2) |
Since the code here is going to be public, it will only be a matter of minutes/days until cheaters will submit fake data.
Have you tried blocking IP ranges and access from non-domestic IP ranges?
What do you mean fool the server? If the user is dumb enough to request higher fidelity graphics and their game runs at 5 FPS, then it's a user problem. And if we're talking about actually good players, then they will want to play on the lowest setting anyway, to increase average FPS, smoothness and distractions by details. You're doing something wrong if players gain a clear advantage on lowest settings. |
You are in the position to make it harder to bypass. It would be more beneficial for everyone if things like this would be handled by netc (so creating interface with hardware information).
Of course. It helps to keep amateur cheaters away. But we have to deal with targeted attacks from time to time. These developers usually use compromised domestic routers for proxy. And you'd be surprised but in a lot of cases they don't bother properly spoofing hardware data to evade restrictions. So better profiting in this case would definitely help. Also there are legitimate use cases for VPN. Blocking it completely reduces the number of potential players. Every day more countries add more restrictions for its citizens (we are slowly moving into the dark ages of the internet worldwide). So the use of VPN is becoming new norm for good players.
I was just talking about uselessness of any "preferred quality" setting. Because it wouldn't reflect what user hardware is actually capable of. |
Really useful, I don't understand the argument being made here, they are just graphical settings dude I would be pissed off if the developer chose my graphical settings for me. I want to be able to set my own graphical settings, some players prefer more FPS, some players prefer more visual fidelity (not that much to get from renderwave in 2025 but you get the point). In my case as a server developer, I have a big ass config panel in which you can change most things, from controls to graphical settings. It would be pretty nice to set the default values depending on their preferred style of gameplay rather than hardware information (this can be already be done, but a global solution would just up the QOL for every user... eventually server owners will take this into account, hopefully. still a really easy thing to integrate), then again with either approach the user should be able to choose what things should be ON or OFF. If something should be always ON, then dont make it togglable, simple as |
Then I'd suggest to create new issue specifically for this feature. It's not related to this PR anyway. I'm not arguing that it could be useful for someone. The thing is... This "graphics" setting already exists (fx quality, draw distance, etc.). I set my custom gamemode settings to low, medium or high by default based on user selected setting from the game. "Preferred quality" setting doesn't solve the need for hardware profiling (to know the exact capabilities of user hardware). There are other use cases for this besides fingerprinting. It was already discussed earlier in this topic. If someone here is worried so bad about function that would return not personally identifiable hardware information then just add new checkbox to disable it (enabled by default). MTA already uses this approach for "screen upload" functionality. This is the most optimal solution that would satisfy everyone in my opinion. |
Totally agree, I also agree that this should be handled in a way that scriptkiddies have a hard time circumventing (in netc for example) |
|
Well as I see there are two types of opinion for this PR, one for the performance part and the other one for a new fingerprinting opportunity. -- They started to use vpn, we started to use a detector api for that but now they found vpn services which won't get detected by any of the best vpn detector apis. We also faced a problem which occured among good vpn users. They used vpn to connect to our server because the vpn service gave them better routing so they had -60ms. Now they can't use that. They can spoof their serial into anything, not only generating new ones but setting it to other player's serial or set it to an insult word (recently a PR changed this so they have to spoof their serial into a real looking one) So from our viewpoint a new fingerprinting system would be highly appreciated. |
|
@derxgbb The solution to this would be to update the serial system, from my point of view. |
If that's possible to update that system in a way where malicious users will not be able to spoof/fake their serials then its okay. |
This function returns basic information about the client's system in a table.
Example:
{ CPU = { MaxClockSpeed = 3200, NaNumberOfCores = 6, Name = "AMD Ryzen 5 1600 Six-Core Processor", NumberOfLogicalProcessors = 12 }, GPU = { Name = "Radeon RX 570 Series", RAM = 419328 }, TotalPhysicalMemory = 16727152 -- in bytes. I actually think it should be in MB (as the VRAM size) }Note: First call to this function is veeeeeery slow, as it has to query WMI.
Subsequent calls are fast, as static variables are used to cache the data.
To clarify, this PR adds:
TotalPhysicalMemory