Closed Hpmason closed 1 year ago
Yeah, the name does make sense as unity refer to the executable as "the player exe", and in older unity versions there is no separate UnityPlayer dll, it's all inside the exe. But yes, due to the bug you mentioned with certain versions of unity 2021.2 mislabelling themselves as 2022.1, I did have the intention of using the version of UnityPlayer first, if it exists, then falling back to the exe. But it's not high priority because you can use the --force- options to override the detected unity version anyway.
Ah, I see. So is the version in UnityPlayer.dll and globalgamemanager the accurate version in this case?
Yes
This has been addressed actually, in https://github.com/SamboyCoding/Cpp2IL/commit/43dd2529d564e2fb0d1d682225984c0b9db010e5
I've been looking through some of the code to see how this works and noticed something that seemed incorrect (or at least misleading). When trying to determine the unity version it checked the version of the game it checks the game .exe, but it's referred to as
unityPlayerPath
. I know Unity games have aUnityPlayer.dll
lib file in the same directory, so is it meant to check that file instead? At least for Slime Rancher 2, I found that while the file version ofUnityPlayer.dll
matches with the version seen inglobalgamemanagers
, theSlimeRancher2.exe
is different.Here's the piece of code I'm referencing: https://github.com/SamboyCoding/Cpp2IL/blob/844e286b3858b31966af0e01bd0a5e22c864140f/Cpp2IL/Program.cs#L61-L72