mtasa-blue
mtasa-blue copied to clipboard
multitheftauto
Add getSystemInfo function
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:
- CPU info (table under CPU key)
TotalPhysicalMemory- GPU info is just here for convenience (already available from dxGetStatus)
The LuaUtils code is a little bit ugly, but the compiler didnt let me use const auto&.
Edit: Fixed. The code is cleaner now.
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 For more than just basic GPU information, use dxGetStatus. Because people would expect a function called getSystemInfo returns info about the most important hardware. So i wouln't consider it as much of a duplicate functionality.
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:
- Benchmark the client PC on the first connection, which provides accurate data, but this information may become stale if the hardware is changed. Also, the benchmark can't be too hard, because lower end PCs may crash when running it due to lack of memory, for example, so it may have trouble telling apart really high end PCs from those in lower ranges. Not to mention that executing a benchmark is not necessarily so quick and energy efficient.
- Introduce settings that, while configured by default to target low end PCs, allow players with beefier PCs to enjoy enhanced visuals and things like that. While this is a nice concept, some players can't really be bothered to understand and tweak the settings, and it can be argued that the first impression a server gives, in terms of the visual quality it offers by default, can make some difference.
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):
- Smart scripts. Different optimization strategies could be used based on information about hardware. It might be related to complex computations as well as simple things like reducing amount of repeated heavy calls (so lower amount for low-end PC, higher for better PC).
- Providing suggestions based on hardware (CPU / OS tweaks). Currently I use similar approach based on the name of GPU and GPU memory (suggesting optimal or best settings for NVIDIA / AMD user). This is mostly for advanced users but it's proven to be quite useful in providing good user experience. Specially for cases with outdated drivers (there are users with dedicated GPU that is not used by MTA:SA in some cases and re-installing or updating drivers usually fixes it, sometimes GPU settings tweaks are required).
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.
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.
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 stand against this feature until it can provide a way to disable sharing the information to scripts via settings menu.
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 :(
I stand against this feature until it can provide a way to disable sharing the information to scripts via settings menu.
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.
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. Well, I hope that we will get this kind of functionally at least in some way. But in my opinion it would be better without option to disable it (for reasons I mentioned in my previous comment).
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.
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.
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). Also I have seen many projects that decide to kick player instead of explaining at least in some good form what is required from the user. Obviously it's a fault of server developer that such not user friendly way was chosen. But it's avoidable (if there is no option).
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). We already have many things in this game that can be used in a bad manner. I think we should consider amount of benefits in relation to amount of potential bad practices (or something like this). And in this case I believe benefits outweighs.
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.
We already have many things in this game that can be used in a bad manner. I think we should consider amount of benefits in relation to amount of potential bad practices (or something like this). And in this case I believe benefits outweighs.
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.
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.
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).
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.
Unless we can know the amount of ram the game process is using, forget about preventing people from "out of memory" crashes.
I stand against this feature until it can provide a way to disable sharing the information to scripts via settings menu.
Servers can see your IP address and you're worried about them seeing the name of your CPU..?
Isn't the serial the perfect candidate for device fingerprinting?
This won't change the situation at all. Devices can be fingerprinted by their serial already.
This basic sysinfo won't make it any worse.
And you can't even spook it (unlike this one, which probably is fairly easy).
That's already done by dxGetStatus. It isn't a new feature.
This PR just adds CPU info + RAM size.
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)
That's already done by
dxGetStatus. It isn't a new feature.
Yes, well that doesn't change my stance on the issue itself. I also don't want my other system information such as CPU information to be read by scripts. I think these privacy improvements should be made to other functions such as dxGetStatus as well.
Serials are a MTA thing, not a global thing.
My main concern was never device fingerprinting (that was someone else's concern). My concern is letting malicious actors have access to data which devices I am using and what are the capabilities that can be exploited in another context.
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 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)
An option to toggle this feature literally adds privacy value. This option does not take a lot of effort for a developer to add.
Whenever you are exposing data of a client you are giving up privacy, which I think is wrong and should be up to the client to decide.
well, i guess probably the gtaonline also does collect these information too. I think if the data doesn't contain anything other than hardware itself, should be fine.
At this point if privacy is a concern when entering a server you might as well nuke MTA from your PC.
If we're going to start taking a heavy stance on privacy in MTA it needs to be a concerted, consistent effort across the board - otherwise your call for the buck to stop here is just irrelevant. For example, do you think so many people would run MTADiag if they knew what data was shared? Are there even terms and conditions to accept before you run that thing?
I do see valid points on both sides though - why would there be any harm in at least letting the client choose what information he allows the server to see? I see no problem with a checkbox setting "Share my device data" - but again, we need to make that's consistent with all other related hardware-data pulling functions, otherwise it's pointless just changing it here.
My main concern was never device fingerprinting (that was someone else's concern). My concern is letting malicious actors have access to data which devices I am using and what are the capabilities that can be exploited in another context.
I already had some scenario's in mind before you said this, but they have in common that they are extremely far-sought. So i stand with my opinion of heavy exaggeration of the risks.
The ball is probably back at @Pirulax, to see if he wants to include a main menu setting for it. Or else, as per @Lpsd's comment directly above, if it would be inappropiate to make this PR the 'victim' of a change that needs to happen in general.
How far down the rabbit hole are we expected to go, though? Do we allow users to mask their IP down the line due to fear of geo-location and tracking?
We should probably create a separate issue if we want to discuss this in a general sense. Then if needed we can make that issue a blocker for merging this PR.
How far down the rabbit hole are we expected to go, though? Do we allow users to mask their IP down the line due to fear of geo-location and tracking?
For people mindful of their privacy tend to use third-party services such as proxies/VPNs which are allowed in MTA. Hardware spoofing however requires more tooling and I think some of these tools may be banned by MTA in effort to prevent malicious activity (someone with access to the AC can correct me on this specifically).