Set thread names for game threads

[p0358]

Adds nice thread names that can be visible in crash dumps, non-attachable debuggers and generally in all places where old method of throwing exceptions to attached debugger on game start wouldn't work:

Can't believe it wasn't already there lol, makes debugging pain without.

Also the method to convert charsets is bad, but that's not my fault, seems Northstar doesn't have any util func for that apparently either, and this "method" was used in some other places in the codebase where it didn't belong. As thread names are generally static it should be fine in this place, but still.

Tested to work as you can see on the screenshot.

[GeckoEidechse]

Uh, where can I see the thread names? ^^"

[p0358]

Many tools, like x64dbg, Very Sleepy debugger, probably in various "process explorer" kind of programs too.

Also worth noting for future reference from RoyalBlue:

if you want names for miles threads as well you need to hook a func there as well because miles only names threads when a debugger is present on thread start
its mileswin64 + 0x3EBD0 a1 is thread handle a2 is the name

https://discord.com/channels/920776187884732556/950322078945538058/1206634307976699905

tested some more and Bink IO is set with just your change already so only the miles hook needs to be done

The above and possibly bink could also be added, but unfortunately for now I cannot be arsed to do that. They might be done in a separate PR though, so I leave that for future reference here. This PR alone makes the situation much nicer already by naming game threads...

[p0358]

Oh also one more thing, this doesn't set the name of MainThread as the hook is done too late. The thread that does the hooking is 99% the main thread, but that should be tested and then when the hook is performed it should set the name of its own thread to "MainThread" then.

[r3muxd]

the real fix for this is to use tier0 to make threads so your TLS gets set up correctly
https://www.unknowncheats.me/forum/counterstrike-global-offensive/335391-fixing-tls-multithreaded-engine-calls.html
for more info as to why this is important read here
particularly you will get weird problems with CMaterialSystem as it uses a CTHREADLOCALPTR for the render context

[GeckoEidechse]

I was told the comment above is not really relevant to the PR...

[GeckoEidechse]

Fails to build after updating with main. Any ideas @p0358 ^^

[p0358]

I guess the CModule class was refactored in master

[GeckoEidechse]

Any chance you could update the PR so that we can merge 👉👈

[GeckoEidechse]

CI still failing btw @p0358

[p0358]

This works now too. There's also MilesMixer thread, but it seems it's not being created, thus it's not on the list? idk why but welp

[p0358]

Merge with rebase maybe, I rebased it to two distinct commits on top of main

[GeckoEidechse]

Will consider, thanks <3

[GeckoEidechse]

Verified that it still runs fine on Linux. This is more of a breakage check than a functionality check though tbh...

[ASpoonPlaysGames]

Would appreciate if someone could give this code review, since I have switched the hooks over to be manually hooked instead of using autohook.

[ASpoonPlaysGames]

Works on my machine:

[ASpoonPlaysGames]

Code looks good (although I am a bit biased since I converted the hooks to manually hooking) other than the stuff indicated by the comments. Fixing that would be beyond the scope of the PR though so it shouldn't block anything

[ASpoonPlaysGames]

@F1F7Y Any chance you could sanity check the stuff that I wrote? Would prefer to not be reviewing my own code in a PR if possible

[p0358]

Hehe I can't physically do an approving review on my own PR lol. But yeah it does seem to look okay...