Agree that these can be nuked.
The screen resolution is more relevant than the window size before the application even initialized.
It gives me 1024*768, but that's not the real window size.
Since we have the screen resolution below, ok.

Arugably removable (even though it gives a possibly valuable indication even if only measured at gamestart)

Not sure about this one, it gives me

"cpu_frequency": -1,
"x86_frequency": 3392695955.358982,

So it gives an indication on the performance of the users CPU, even if inaccurate, no?

should be moved to the top of the file, a const, like #define PS_PROTOCOL_VERSION 0x01010015 // Arbitrary protocol

But it's still active and it's not about hwdetect. My understanding of hwdetect, that the report data should change if and only if hardwares or drivers for hardwares were changed.

It's not a static value, we measure it at runtime, so we have a visible error here.

Why on top? I placed it here, because you may see it after making all changes, but on top it's easier to forget, no?

I'd prefer static cost int for on top to fix the type.

(or OS or build or those becoming separate reports too)

So we have a somewhat inaccurate number instead of no number. Or can we deduce the frequency from the other data? (I doubt)

I guess it's ok to keep it inside this function as long as this function is the only one relevant to the hwreport and the version only refering to the format of the hwreport part of the UserReport.
The comment itself above the number could be sufficient when keeping the number so close to the call IMO.
Or you could move the version to the top of the function. So every reader that starts reading at the top of the function notices the comment.
(Perhaps or perhaps not even something like { "hwreport", 11 }.)

OS = different drivers, build = possibly a different version, a different set of keys.

We can deduce it from the CPU model or round it to few decimal places.

deduce it from the CPU model

Which source are you going to use for that, is it worth the hassle?

Which source are you going to use for that, is it worth the hassle?

Vendor technical reports.

The current value is useless for us, because it can be any, it depends on a current machine loading. So I suggest to remove this value, until we have a better one.

Won't the user report be false if the person overclocked his CPU ? If we have both values we can compare.

I'd say semi-false, because we'll know a value less than the actual value. The current value is pretty dynamic and has noticeable error (we should round it at least). Also we calculate it in the pregame, so the value will be less than possible.

What about people that play in windowed mode ? Don't we want know in what resolution they play ?

Agree that it is irrelevant especially since we are still a 32bit process and knowing that 16GB are free on 20 doesn't seem like a really useful information.

Not sure about removing it but the points seem good enough to remove it.

Wouldn't it be nicer to have it in the default.cfg file ? to update it at each release ? This way if someone forgets you don't have to rebuild the whole game.

At least not here, because this is the hardware report, not all user statistics.

The version is independent of the release cycles. Also default.cfg isn't in mods, so how to modify it without rebuilding?

Well you have mod.cfg, local.cfg, and user.cfg that should do the trick :)

→ The version is independent of the release cycles.

True. However you might want to separate the hardware by the version people play, so you can make stats per version. Like it's more useful to know the hardware used in the last 4 versions than in the last 20.

But config settings are used to change the program flow, this is a piece of information that if changed by a user, would indicate something incorrect, no? So more comparable to the protocol version magic of the netclient, or the pyrogenesis engine version constant. The user can't change anything in JS or the GUI that would influence the version.

Fair point. I just imagined a random case where someone changed the feedback link for his server and wanted to start at 0 for his own mod.

He then either does not change this protocol and thus has no reason to use a different protocol version number,
or he does change the protocol, then he can also change the protocol number.