It’s been a long time since I’ve worked on this. Pre-Ashes of Malmouth, in fact. I did some digging into my own code and yes, the tool does make the assumption that you are working directly in /mods.
In theory, putting in your full working directory (provided it’s a subdirectory of /mods) should (err…could) work.
As to the modchecker and, consequently, the modpruner, these were not updated to correctly account for gdx1/gdx2 information and so a lot of “default” records are marked as erroneous. A (tedious and not recommended) workaround is to merge gdx1/gdx2 dbr files into the vanilla database directory.
It’s been on my mind recently, as I’m getting back into modding GD again as well, to update this toolset. But I likely won’t be working on it at all until this weekend, and it’ll take further time from there to develop to completion.
Most of what I’ve used the suite for in recent years is as a quick means to launch the game’s various innate developer tools. At least that still works!
Shoutout to @mamba for remembering that this tool even exists!
I’ll give the copy a spin. Since I’m not using game file extracts in that location, putting a copy there and then merging in gdx1/gdx2 and creating a ganked up directory would be harmless here, I think.
Yeah, if I’m not mistaken when gdx1 (Ashes) first released there was something jank about how the files did/didn’t get extracted/viewed correctly in the Asset Manager so the workaround was to dump them into the vanilla /database/records directory and work from there. I think I did a bit of development of this tool on that pretense rather than on the assumption that gdx1 would one day extract data properly.
Oops!
Still, no guarantee that this tool will work appropriately even with jank workarounds. Sorry about that.
Tell you what, though - thanks to you my head is a bit in the clouds today thinking about which language to use to re-develop this tool. (I genuinely believe it’d be faster to rewrite from scratch than attempt to relearn my code and pick up where I left off.) The version above is written in Java, but now I’m debating between Python (which would be faster to code but slower to run (and the tool was already a little slow)) and Fortran95 (which would be slower to code but in theory would be fast as all hell, and it’d have massive native Windows support…).
Or maybe I could take the opportunity to finally learn C#/++…
Python is only slow when… running python. A great deal of python is actually C. So, for example, loading a file using python is about the same speed as C. And python math modules often perform faster than C, do to the array handling semantics (they use adjacent memory, which is cache friendly, as opposed to multidimensional C arrays which are fragmented). Conversely, of course, basic for loops and functional call dispatch is quite expensive in python. So intricate, interwoven python code is pretty slow.
BTW, it does, in fact work by creating a merged copy of the database and templates in the working directory with gdx1 and gdx2 copied in.
Also, you’d think the Crate team might use your tool. There are broken references in endlessdungeon that are legitimately broken in the gdx2 delivery. e.g., dungeonset14.db points to yugul_tentacle01.dbr, but the correct file is yugoltentacle02.dbr. There’s a few like that.
BTW, the tool doesn’t seem to know about my custom text_en tags, which are properly compiled and work in game. Is there something special I need to do to get those recognized?
Are you referring to GDSearch or GDModChecker? (I really need better names.)
IIRC (though I’d need to delve into the code to be sure), GDSearch only searches for strings in Grim Dawn files and isn’t concerned with mod text. As for GDModChecker, I don’t think it checks tags at all (which seems like an oversight so I’m hoping I’m wrong and it’s some other problem).
Just for those using it (it’s super useful!), if you want to get the current tool to shut up on broken text tags, the tool does not understand tags that begin with something other than “tag”. The game does, though. So, for example, I begin my mod tags with “jktag”. The mod checker ignores those, allowing you to focus on the other very valid things that are broken in your mod.
I have not figured out how to get it to silence on textures though.
Very HELPFUL tool this is, still! Finally got my hands on it and guess what, found over 4k errors in my mod… xD well, i bet a “#” infront of a tag to deactivate that one, is no issue at all, just can not be seen as a working tag by the “checker”, if i DO get this right now fixing all other errors step by step! Thanks for this genius tool, which is indeed still working. Cheers!
edit1:
3093 total errors:
710 broken references. 22.955059812479792%
2344 invalid tags. 75.78402845134174%
39 changes to base player speeds. 1.2609117361784674%
…xD
→ about the changes to base player speeds, it is reported even on “just” removing a “.0” from the “1.0” values, this should be no problem aswell i hope, maybe someone can clarify this for me
After more than six years of stagnation, the Grim Dawn Modding Suite has been completely rebuilt from scratch to gain compatibility with current and future Grim Dawn content!
Please see the first post for more information and download links to the latest version of GDMS.
Fixed issue in which GDModChecker’s line reports were off by 1.
Fixed issue in which some errors were reported that were not actually errors (e.g., level calculations, .lvl map references).
Additions:
GDModChecker can now check references within .lua, .cnv, and .qst resource files and report any related errors thereof. .cnv and .qst resource files do not come with line reporting. (Because they are bytecode and do not have strict line separators)
GDMS download link formatting changed so that when I upload new versions of this utility, the damn download counter doesn’t reset. (from now on)
Bugfixes:
GDModPruner can now actually delete files if told to, where previously it was unable to do so. It was always capable of trimming DBRs, though.
Additions:
GDModPruner can now compare resource files of a mod’s resources against those of Crate Entertainment files. This is done by comparing their SHA-256 hashes. Resource files which are deemed to be unchanged from their vanilla counterparts will be staged for deletion as with DBR files.
Added proper version updating to the tool’s UI, such that GDMS properly reports which version of the utility a user is on. This is processed and reflected in updating its configuration files as well.
Fixed fresh installs of GDMS not properly loading newly-initialized config files and displaying erroneous info in the application header. This was purely a visual bug that only occurred on first-time-use, and had no impact on performance or stability.
Fixed issue where GDModPruner would not trim DBR content in mod-original DBRs, only those that overlapped Crate-content. As most mods provide lots of original content, this will enable GDModPruner to drastically compress mod size even more than it was before.
Also corrected an issue in which GDModPruner was not looking for the right decimal places of “0.000000” entries in DBRs. It will now trim those correctly as well.
GDMS now has support for utilizing custom Working Directories as defined in the Asset Manager, e.g.,
Note that at this time custom Build Directories are still not supported; GDMS will assume that one’s Build Directory = their Install Directory.
To configure a custom Working Directory, refer to the Mod Suite Setup buttons on the home menu before pressing the ‘Initialize Mod Suite Config’ button:
GDSearch now has an optional checkbox to perform searches only on the first entry of a field in DBRs. There is an explanation of this feature built in to an adjoined button:
Fixed an issue in which GDModPruner’s DBR Trimming functionality could break the UI display of mods with mastery data, leading to corruption of player characters in mods that had used it.
now fixing all other errors step by step! Thanks for this genius tool, which is indeed still working. Cheers!
