Would it be possible to add support for Advent of Ascension / Nevermine's death mechanic (with the Augury skill)?

Basically their mod "takes over" the normal death mechanic of MC by making you spill your items on the world again (just like vanilla) unless you have some levels in the Augury skill, in which case you get to keep some armor and weapons (but still leave other items on the ground). This overrides the OpenBlocks grave system completely (graves don't even spawn from that mod) but I see that with your mod actually still spawn the grave, but the items don't go in it. Which gives me hope, because maybe you can get a grave system working again with AoA, by doing something like adding "vacuum hopper" behavior to the grave as it spawns?

Anyway, just an idea ...

This would be nice to have in 1.7.10.

I can confirm that graves do now spawn with items in them with AoA installed.

I would truly 100% love this! No grave mod is as awesome as your mod but aoa is a decent mod too!

same as AoA + grave = grave problem.
mod version: 2.16.0-1.7.10, grave create and inventory no put in grave:

P.S. /gamerule keepInventory false /gamerule keepAllInventory false /gamerule keepNoInventory false

@Bogdan-G The creator of AoA was told to add hooks back in the day but refused to comply stating "I will make my mod my way I don't care about compatibility."
The creator basically does not give a damn so move on.

@P3rf3ctXZer0 author AoA no add config option in AoA? ehh..

I can't say I would entirely blame them. (not pretending to understand their motives) Compatibility is a major pain, and IMO, these hundred+ mod packs are INSANE, and using software in this manner generally speaking, is asking for a plethora of problems. I can say that if I were going to make a mod, even if I did use Forge's features to make it compatible, I REALLY do not want to deal with the potentially thousands of compatibility bug reports I would get, and I even LESS desire to bother with fixing them, when that time could be used to solve problems with the mod by itself, or to add new features.

As for me - the main reason of such problems is reluctance of some moders in any type of cooperation. It is not realy hard to create an API for most common features of the mod. But even without it creation there are few ways to make mods compatible. I used reflection for some mods, which havn't got an API, such as "Backpack", "Rpg Inventory", "Witchery", or even more simple hacks like was done for "arsmagica2", "EnderIO", "Battlegear2". But it can't be done without help of creators of those mods, without explanation of how those mods works - otherwise it should takes too much time.
As for AoA - I didn't get any reply on my requests.

@Brian151 and @NightKosh take the human approach and do one mod issue at a time and only if it had been properly documented. Telling people and modders to fuck off directly which "AoA" dev had told me in a pm; is the wrong way to be in a modding community. That is the type of modder who should only doing private releases to themselves and friends. If you place a mod public expect requests; its that simple. Insult people about their requests and expect backlash.

It wouldn't matter if I took one issue at a time, or all of them at once. In the end, I have to fix the problem(s). it's easier said than done. One mod has energy conversion issues, I fix that, but now I've broken something in my own. I fix that, now other previously compatible mods don't work. Let's also add the stress of keeping-up with MC versions and/or forge.

I can think of one such modder who has (not with the exact wording) essentially told everyone to "F off". (in addition to basically committing fraud) I agree that is entirely uncalled for, and I don't respect people who do such things, either. Be that as it may, most modders are hobbyists, and do not necessarily have the time or money to work on those mods full-time. Even if they do, they have a life, too.

The way I see it, the public needs to respect the modders just as much as the modders need to respect them. That includes not basically demanding everything get fixed. It truly amazes me how these mods can be remotely compatible as-is. I'm not sure I want to know every detail of this, either. The only way I envision as being able to make mods not conflict as much as they do involves TONS of configuration files for EVERYTHING, and breaking them all into...SEVERAL smaller modules, besides QUIT RE-INVENTING THE WHEEL... more common APIs. Honestly, it'd be a nightmare to maintain that, too. I don't usually play these huge modpacks both because of massive system resource use, and the steep learning curve to use any two technical mods at the same time. besides that, I've heard enough of what nightmares go into making those mods not fight each other constantly. No thanks...

As another point, open source software can be contributed to in other ways than just asking for stuff to be resolved. Back to my point on how difficult or time-consuming handling these issues can be, stuff that's generally outside the primary scope of the project (like compatibility with ) could also be done by the users, themselves.

I haven't tried making a mod in a while, but my main focus if ever I do will be on making the mod work, and I might generally ignore compatibility, unless it can be resolved without turning my code into spaghetti, and in a short amount of time. In any case, it'd be open-source, and I'd hope if people seriously want compatibility with another mod, that they would also try figuring that out, themselves.