2.5% from basic enemies (White/Yellow).
5% from heroes.
10% from bosses.
Edit: I can look to add the drop ratios to the spoiler-cheatsheet for next release.
2.5% from basic enemies (White/Yellow).
5% from heroes.
10% from bosses.
Edit: I can look to add the drop ratios to the spoiler-cheatsheet for next release.
Up to you, I’m just being my overly busy body self. I also have notoriously atrocious luck and after getting to the higher levels haven’t seen the gemling in a while vs getting it a lot in the leveling up to that point. (I completed the gemling card set 3 or 4 times while leveling through normal/elite and then haven’t found a single gemling again despite killing many of the dropping enemies (I think). So like I said before either the loot percentage dropping has normalized to where it should be since I’m leveled or I just have my consistent bad luck. (Or there’s a small chance I installed something incorrectly as well but have no idea what or how.))
Thank you!
Grim Armory’s largest update ever has now been released! See below for the major new features, or see the first post in the thread for updated download links and more information on bugfixes/changes to the mod.
At long last, a simple, modular, and elegant way to purge the green fart clouds from my glorious ice storms
A non-critical update to Grim Armory has been released. This update adds no new features and changes no gameplay/balance of the mod. It therefore does not need to be downloaded for individuals/modpacks on the previous version of the mod.
In addition, download links for GrimArmory have updated from dropbox downloads to mediafire downloads.
A significant bugfix to GrimArmory has been released, along with two new Augury cards:
I have few mods merged (Grim Armory and Shattered affixes merged together, and New_Caravan & Inventory as baseline mod since i don’t have mod sources). That was 1st time i was merging mods and launching 3 mods at once, but since they all do different things, there were no conflicts. Even GDStash has no issues with this modded game (only some warnings about duplicate items, but everything is fine, it works with all modded items and has bigger stash size). And still, i had to replace warden01.dbr (from this mod) with original game .dbr file, cause something (may be related to DeathHooks?) made boss unable to revive for 2nd phase. As i noticed, modded .dbr had 1st row with template name skipped and missing quite a lot of attributes (most or all of them are 0.0 tho). Could DeathHooks cause issue and is it possible there will be more issues with DeathHooks later?
@ASYLUM101 - FYI for grimarillion, GrimArmory has a progression blocker. Working on addressing. Fixed. Please redownload above.
@faraddox Good catch!
This is not caused by DeathHooks. It took me some doing to identify the culprit, but it comes from a process I run to minimize source file size through my GrimDawn Modding Suite (GDMS).
As you saw, this process removes most ‘0’ values from all files in a mod. Most of the time, these values are not necessary. However, in this particular case, it seems that the zero that corresponds to whether an entity ragdolls on death was required here:
Essentially, the Warden is supposed to play his respawn animation on death, but if he ragdolls, he cannot do so and just dies (which is actually kinda funny). If one reinserts a 0 into this field to set his ragdollPhysics to False, this issue should be resolved without changes to DeathHooks.
This is a little strange to me, as most things default to False when empty, but it makes some sense in this case as most enemies in the game ragdoll on death so it seems appropriate for Crate to make that be the default.
I suspect this issue will be present with other entities throughout the game - virtually anything that has multiple phases. I’ll work on a hotfix for this in the coming days, in both GrimArmory itself and in GDMS so that my tool does not cause this issue for others in the future.
Thanks for your help in identifying this issue!
It took quite some time to find out it is caused by changes in warden01.dbr since i never look inside Grim Dawn’s mods before, so that was quite fun day (except time spent for building mod again and again)
And yeah, the issue spread to all enemies that have phases. Swarm Queen Ravna died after 1st phase too, unable to start 2nd phase. Does it even worth to save on attributes in .dbr files? Who knows what else might break by removing attribute completely, even if it’s 0.0 or False.
The process cuts down on filesize quite significantly. Overall, the source data for GrimArmory would be about 70-80MB without this process, as opposed to its current 18.2MB. It also makes editing a bit cleaner/faster if opening files in Notepad++, as they would be without extraneous info.
A quick fix would be to remove any non-final phases of enemies involved. Korvaak may still bug out in that case (as I believe his third phase has an on-death animation even still) but the reason this issue hasn’t appeared sooner is because only recently did DeathHooks add earlier phases of enemies to the mod. This suggests that the pruning process does not typically create too many issues on its own.
A critical update to Grim Armory has been released:
@faraddox Please redownload above and let me know if you encounter any issues. I was able to see the Warden phase transition successfully with the above hotfix and believe I have fixed this issue for most enemies it affected.
Yeah, downloading it already (very slow, have to use vpn to even access mediafire), will check Ravna again as soon as i’ll rebuild database with all enemies from this hotfix (takes some time too, thanks to huge amount of .dbr’s in Shattered Affixes :D). Doubt i’ll be able to test that much since i’m just playing normally, just killing time before tomorrow’s 2nd Cycle in Last Epoch.
For future patches, would dropbox be any faster for you? I moved to mediafire recently because another user encountered the opposite problem (needing to vpn to dropbox but being able to access mediafire normally), but I’m not opposed to hosting a mirror on both sites in the future.
Thanks, but don’t bother, my ISP is absolutely unpredictable. Few days ago i didn’t have to use vpn for mediafire and downloaded mod almost instantly
Ravna is fine now, Karroz transitioned to 2nd phase too, so no more problems, i hope.
This I’d chalk up as a DeathHooks bug as DeathHooks was never intended to be attached to traps. For regular enemies, GDMS’s data trimming behaves otherwise normally.
I’ve corrected this in DeathHooks’s generative code and removed the traps from it and GrimArmory, but do not intend to release a Hotfix solely for this issue as it’s fairly non-invasive (and doesn’t even occur for those that do not have enemy healthbars always enabled, which was the case for me).
This will be resolved whenever GA’s next release occurs.
You won’t break your game, but you will remove the main reason to be running GrimArmory.
I’ve confirmed the presence of this issue. Working on identifying why it occurred - to see if anything else might be affected.
For now, if you’d like to ‘patch’ this yourself, adding the following to the end of the DeathHooks script file (and rebuilding your mod) should resolve this issue:
function gd.DeathHooks.chthonianrylok_ekketzul(objectID)
gd.quests.areaEQuestVoid.ulgrimBossKilled(objectID)
end