https://grimdawn.evilsoft.net/seed/index.html
For those needing to find specific seeds and using GD Stash.
This is a proof of concept. You can find the SDK at GitHub - marius00/GrimDawnItemStats: Stat calculation algorithm for Grim Dawn items · GitHub
The SDK is meant to be used for other third party tools to be able to derive stats using records + seed.
This does not seem to take pet bonuses into account for seeds 
Is there logic to do the reverse? I am trying to build a tool that needs to calculate the correct stats of items using the seed of the item obtained from the player.gdc save file.
So far I have managed to get the item, suffix, prefix and seed for each slot of equipped item, I’m trying to find a way to generate the accurate item stats from these obtained values.
Hi @slipperypete ,
Since you posted the link to your seed finder utility here for GD Stash users and since this is seed related which GD Stash heavily utilizes, I figured this would be the best thread to share some feedback. If there is a more dedicated discussion thread for the tool, please feel free to move this post!
I’ve been running a search for a specific item combo over the last ~3 days (screenshot attached below), and it got me thinking about the underlying mathematics of the search. I wanted to ask a couple of questions and propose an idea, though please forgive me if I am missing something obvious about the game’s engine or your implementation!
I noticed my search reached 23.5 Trillion seeds tried at a blazing fast 73.7M/sec. Since a 32-bit hex seed pool maxes out at exactly 4,294,967,296 unique possibilities (16⁸ or max unsigned integer), is it true to assume that the tool is running a non-deterministic or pseudo-random check? Which by definition would naturally allow overlapping and re-testing seeds across the worker threads (assuming you are using worker threads) over time?
Because the tool shows a “1 in 2.7B seeds match” probability, I initially expected it to hit a result quickly. But seeing it loop through the equivalent of the entire seed pool thousands of times over makes me wonder if the specific stat combination I am hunting for is simply mathematically impossible due to how Grim Dawn’s internal logic handles stat calculations (which results in some stat distributions reoccurring and being more common than others whereas others are simply left out due to the hard cap of seed counts?).
If certain perfect combinations don’t exist, the random loop unfortunately turns into an infinite processing loop for the user. So I was wondering if it might be feasible to change the search strategy to a deterministic, linear sweep instead?
If the total 4.29 Billion search space were cleanly split into equal, non-overlapping blocks based on the user’s available CPU threads (e.g., Thread 1 checks 0 to 536M, Thread 2 checks 536M to 1.07B, etc.), a sequential sweep could exhaustively check every single existing seed in the entire game in under 60 seconds. This way, if the threads complete their assigned slices and find zero matches, the tool could definitively tell the user something like - “Search complete. A combination for this stat range does not exist. Please modify your search and try again.” clearly communicating to the user that no further searching can be made and that the combination simply does not exist.
This also means that combinations that are assessed to be something like 1 in 29.5B are likely to not even exist in the first place, which could be worth mentioning (which is something I’ve originally never taken into consideration before taking a look into what seeds actually are).
I might completely be misunderstanding how the tool interacts with the browser, how Grim Dawn handles stat distributions altogether or why a sequential brute-force isn’t ideal here, so please take this with a grain of salt! I just wanted to share the observation in case it helps optimize an already awesome tool.
Thank you for all your hard work on this!
My guess is that your stat distribution is not satisfiable. I’m not sure whether the website implements the game stat distribution algorithm exactly, but you can dig into the site source code and check for yourself.
edit: I actually checked the source and found this repo: GrimDawnItemStats
In short, the stat distribution algorithm implemented by the website is fully deterministic. Again I think you’re hitting an edge case and your desired stat distribution is simply not possible.
I think we might be talking about two different parts of the code. I am actually not talking about the item stat distribution calculation itself (the MINSTD formula), but rather about the seed search/generation algorithm used by the website.
You are 100% correct that the stat calculation is likely fully deterministic (I haven’t tested this personally but I’m sure this works as intended as I’ve generated items with varying stats and those were the values in the game). Inputting seed X into the formula will always give item stats Y.
However, the search method picking which seed to test next appears to be the part that is non-deterministic (pseudo-random). If the tool were running a sequential, deterministic sweep through the 4.29 billion unsigned integer pool (0 to 4294967295), it would check the entire universe of seeds exactly once and stop.
Instead, if the seeds are generated without a shared state or history tracker to log checked values, they will inevitably re-evaluate identical seeds over a long enough timeline. This structural overlap is why a search can hit 22+ Trillion checks on a 4.29 Billion pool without ever completing or terminating.
So while this might be an edge case, I wouldn’t say this is all too uncommon. It’s very possible to hit impossible stat distributions with normal use, and the issue is that the tool does not communicate this to the user. Sometimes there even MUST be impossible stat distributions because some items can have well over 4.29B possible stat distributions and that would simply mean that it’s impossible to accommodate them all with seeds as the driving factor as those would require the seed representation to be larger than 32 bits (or 8 hexa digits).
Hey slipperypete,
I’m glad to see the fix implemented so quickly! This is going to make searching a much smoother experience! Thanks for being so receptive to the feedback.
Since a lot of us using this tool are likely coming from GD Stash, I wanted to pass along a couple of UX/UI suggestions that could make selecting the right affixes a little smoother.
Currently, the dropdown lists multiple versions of the exact same affix for a given level. For example, in the attached image below:
“of the Cabal” shows up several times with different bonuses. It can be tough to figure out which one is actually valid for the specific base item type you are trying to roll.
There is a slight readability issue where longer affix descriptions are getting cut off by the fixed container width as can be seen in the image below (of attack filters to a lot of different affix names and you can’t tell which affix is shown here):
(Some suggestions, though options here are endless):
(~3 days going so far, I’m too invested to stop it).
vw) would let those of us on larger screens utilize the extra space and read the full text.Thanks again for the rapid update! Hopefully these suggestions give you some good ideas for the next iteration.
Edit: The “Impervious” Prefix options are also a good example of selections which you can’t tell apart from the dropdown:
Don’t know if I missed it, but I can’t seem to find any Relic items in the dropdown.
Might want to add a Completion Bonus selection alongside it?
If you can get me a .gds file with say… 100+ relics, I can look into it.
Will need a substantial dataset. I got none in my own dataset.
Hello,
First time using this feature of GDStash so I hope this is the correct file:
Should contain ~180 Relics (Made with the Blacksmith ingame; 1 of each Transcendent and Mythical I had the Bluenprint for and could easily edit in the mats in with GDstash; and a few multiples of Empowered Relics)
Thanks!
My most hopeful estimate is that I’ll have something in 3-5 weeks.
It first requires me to add support for this in item assistant, so that I can establish what the expected values are. Then knowing the real values from record+seeds this can largely be brute forced.
Relics are treated a bit differently than most items, and has up until now been disabled in item assistant to prevent crashing the game when parsing stats for them.
I see, fingers crossed then!