Thats strange because I specifically downloaded the 64 bit version. Nonetheless I now downloaded the 64 bit offline version on this site that installed itself into program files and I edited the batch accordingly (only thing that that changed is the removal of the “(x86)” bit) but I’m still getting the same errors.
Right now I worked on bringing the heap size down. Unfortunately not enough for a 32bit JVM it seems - even though I have no idea why the JVM has issues to begin with, I certainly stay well within the limits of a 32bit VM.
It seems the Oracle 32 bit VM simply has problems allocating large chunks of memory at once (and by large I mean maybe 200-300 MB…), in theory that could be fixed in the future or not be an issue on another 32 bit VM (IBM, Apple).
I did not add that check as there was more important stuff to do and because to me it is a minor issue. In a way you have that warning already, it just manifests itself with a somewhat different text 
Finally, there does not appear to be a good way to actually check this (read, one that is not JVM specific) and since the compiled executable shares the exact same code, I will also have to take that into consideration and make sure it passes the check despite being theortically on a 32bit JVM.
I will look into this a bit, now that the higher priority stuff is close to completion. Will see what I find.
Trickier if you want GDStash to work on all platforms, but I’ve seen examples for most platforms.
os.arch is the OS, not the JVM
The approach is similar though, it’s just that there is no universal system property for it, only a JVM specific one.
As pretty much everyone is using Oracle’s JVM I probably will check its property and just ignore other JVMs. The issue is probably specific to it anyway, so there is no real need to prevent ‘unknown’ 32bit JVMs from running the tool.
It’s not like I need more RAM than a 32bit JVM can handle, it’s just that this JVM seems to have trouble allocating 100MB of RAM or more at once.
Will see if I can bring that down more, but I do not want to sacrifice performance too much for this either, so looking for some compromise there.
Switched to memory mapped file handling as their buffer presumably is not on the heap, but that accomplished nothing wrt the 32bit JVM and the memory allocation issue.
But OS arch is the “tricky” one.
JVM one is easy.
How so ? os.arch is easy, JVM to me is slightly harder as there is no standard property for it, i.e. no os.arch but for the jvm
Increase the maximum heap size then (the -Xmx1024m part) to e.g. 1600m
Alternatively, the next version has a reworked loading logic to reduce the memory usage, try that one
Version 1.0.1 released
Reworked the database import to use less memory. Also a few bugfixes around Spear and Staff support.
Still not good enough for the Oracle 32bit JVM, but that definitely is a bug in the JVM (when I allocate 190MB and up in one block, the Oracle 32bit JVM chokes on it). I decided to take closer look at this and the IBM 32 bit JVM does not have this issue.
Will decide whether I should work around this, will require some more reworking if I want to.
Thanks for the update! 
@Batch file
I found a easier way, I think.
- klick right on the “GDStash.jar” file an make a Link!
- klick right and on properties.
- edit target to: “java.exe -Xms1024m -Xmx1024m -jar GDStash.jar” and save it!
- Thats it!
Start GDStash over the link …
Hi mamba! I’m currently testing the upcoming version of the cornucopia mod by ceno and doom. This version will change a lot of items, especially epics. it will also intoduce new completion bonuses for relics and allow more components on jewelery.
So my question is: If i set the savefolder to cornucopia 3 and import the cornucopia3.arz, will your awesome tool still work with that mod?
Ty in advance!
Leave the save folder untouched, ie Grim Dawn\save, in the tool you can select shared stashes and chars from the mod subdirectories already, do that instead.
As to mod support, go to the Config page, select the mod and import it. This should create a second database for that mod.
When editing stashes /chars of the mod, make sure you have the mod selected in the Config page so the items reflect the Cornucopia values rather than the vanilla stats. Hope all of that works flawlessly, mod support is pretty new
With Cornucopia you probably could also use the vanilla database as there are no new items (I believe), but you would not see the changed stats or have the new completion bonuses etc. so importing the mod is the better solution.
Thx a lot, sounds great.
Edit says it’s working.
String arch = System.getenv(“PROCESSOR_ARCHITECTURE”);
String wow64Arch = System.getenv(“PROCESSOR_ARCHITEW6432”);
boolean warnUser = “x86”.equals(arch) && “AMD64”.equals(wow64Arch);
System.out.println("Needs 64-bit warning: " + warnUser);
Should do just fine as well, as long as you don’t intend to run it on non-windows. (in which case it defaults to false)
I might just use the JVM specific property, after all by now I established that it is a bug in Oracle’s JVM, IBM’s works flawlessly…
will have to check that, thanks
Unfortunately same with cornucopia 003. I was a bit too hasty saying it would work. I didn’t realize that it didn’t import the database correctly. (I get the same errormassage as Mr. Strigvir, "java.lang.NullPointerException).
Version 1.0.1a fixes this
What mod is this ?