-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Evochron Mercenary, false positive for Godot #30
Comments
Worth noting: Original release date might not be a 100% accurate factor either as some games might have had a Godot port in a later update (that seems to be the case for e.g. https://steamdb.info/app/579230/ which has a Windows version using Godot and macOS/Linux versions still using Unity, i.e. not updated). |
This is a good catch and will be a false positive after the Godot PR goes through.
I think release date checking is out of scope for SteamDB. You also rightly note that release dates are hard to rely on because of stealth updates.
I think this is the better way to go. Look at all the Godot false positives for this pattern and throw in some easy rule-out evidence patterns we can check. |
So I've been thinking about how to exclude this false positive (which is a bit annoying as it's the most "followed" "Godot" game so far on https://steamdb.info/tech/Engine/Godot/ :)). We could exclude based on stuff like DirectX installers (e.g. So... this might be worth a try. At the same time, this is so specific that it might be just as well if we could have an exclusion list where we can specify that app ID 71000 should not match Godot. Would that be an option? |
Just found a Godot game with a DirectX install depot for some obscure reason: https://steamdb.info/app/1189230/depots/ |
What about these files? msvcp71.dll |
In general we are willing to accept false negatives if it avoids false positives. So I'm willing to trade a lost ID for not making a bad one, so let me know if you find any of the msv files, otherwise I'll go off of DXSETUP.exe |
I think it's the same for DXSETUP.exe or msvc*.dll, if the game was ported from another engine but old files have been left lying around, both are likely to be there. msvc*.dll might be a valid scenario for a Godot game using a GDNative plugin that was compiled and linked statically against MSVC's DLLs though, so I'd go with DXSETUP.exe instead. Or |
I've just went through all Godot titles currently detected by SteamDB, and Evochron Mercenary is the only false positive I could fine. Is it really not an option to simply exclude Evochron Mercenary's ID from the Godot detection heuristics? |
SteamDB link to the game
https://steamdb.info/app/71000/
What is it being detected as and what should it be detected as? Any other information?
Detected as Godot, but it doesn't seem to be.
Don't know what's the actual engine, might be in house.
Additional information
Windows depot: https://steamdb.info/depot/71001/
It matches the Godot rules as it has
.exe
and.pck
with the same basename, which is indeed the main signature of Godot 3.0+ games:But Evochron Mercenary was released in 2012, so 2 years before Godot's first open source release, and most importantly 6 years before Godot 3.0 which uses the ".pck with same basename as .exe" logic (previous releases required a main .pck named
data.pck
).There's also a ton of other files which are not relevant for Godot, such as DirectX installer and MSVC redistributable DLLs. It's hard to say 100% that this could never match a Godot game as with a custom build and a custom-developed DirectX renderer one could get a distribution like this if one wanted to... but it's extremely unlikely.
If one can access the release date, the Godot rule could exclude games released before February 2014 (or possibly a few months later if needed - the first game released on Steam might be the Dog Mendonça demo: https://steamdb.info/app/330800/).
The text was updated successfully, but these errors were encountered: