Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to not overwrite Graves #35

Open
Mcklp opened this issue Apr 22, 2024 · 12 comments
Open

Add option to not overwrite Graves #35

Mcklp opened this issue Apr 22, 2024 · 12 comments

Comments

@Mcklp
Copy link

Mcklp commented Apr 22, 2024

Hi, i wanted to use grave plugin and CreeperHeal2. In rare cases its overwriting the grave (after dying in alredy blown area). Quick fix that i can think of is to add whitelist of block to be overplaced while repairing (like chest or more likely with grave plugin player heads).

@pmdevita
Copy link
Owner

If you're talking about this plugin https://www.spigotmc.org/resources/graves.74208/ then it's due to a bug with how they're handling explosions. I messaged the developer a few months ago but I haven't heard anything back. I'll try to ping them again.

@pmdevita
Copy link
Owner

@Legoman99573
Copy link

This is the Maintainer of the fork GravesX, which works on the same codebase. If there is an event or a way we could listen to and exclude specific block locations, I am willing to hook into the plugin and handle it that way. Would be helpful for other plugins as well that want to hook into your plugin 🫡

@pmdevita
Copy link
Owner

pmdevita commented Nov 7, 2024

Hey! You should just have to adjust your listener priority. Here's what I wrote to the Graves maintainer originally.

Hey, I'm the author of the CreeperHeal2 plugin. It looks like your BlockExplodeEvent listener is set to HIGHEST priority but that's causing it to run after all other plugins. This means it is unable to exclude the grave block from any other plugins that are getting involved with the explosion and causing some compatibility issues with CreeperHeal2.
Since you probably don't want anything else touching the grave block, I'd recommend you set this event to LOW or maybe NORMAL priority. CreeperHeal2 is set to use HIGH priority to try and let other plugins edit the explosion first before it gets involved, so anything below that will fix it.

As far as I can tell, you should have that listener on NORMAL or LOW priority, setting it to HIGHEST is making it run after every other plugin which seems at odds with what the plugin wants to do.

@Legoman99573
Copy link

Hey! You should just have to adjust your listener priority. Here's what I wrote to the Graves maintainer originally.

Hey, I'm the author of the CreeperHeal2 plugin. It looks like your BlockExplodeEvent listener is set to HIGHEST priority but that's causing it to run after all other plugins. This means it is unable to exclude the grave block from any other plugins that are getting involved with the explosion and causing some compatibility issues with CreeperHeal2.
Since you probably don't want anything else touching the grave block, I'd recommend you set this event to LOW or maybe NORMAL priority. CreeperHeal2 is set to use HIGH priority to try and let other plugins edit the explosion first before it gets involved, so anything below that will fix it.

As far as I can tell, you should have that listener on NORMAL or LOW priority, setting it to HIGHEST is making it run after every other plugin which seems at odds with what the plugin wants to do.

At the time, there was no protection logic behind it, which now requires a higher priority as heads would just pop out if lowered. If there was an event to listen to blocks regenerating, this can allow me to either ignore that block or destroy the grave entirely. There is a previous event, but that only checks when an explosion occurs.

@pmdevita
Copy link
Owner

pmdevita commented Nov 7, 2024

Hmm, could you explain what you mean by protection logic? How does it cause a problem with heads popping out? There is an event you can listen to, I can help you set that up, but I'd imagine you'll have problems with a lot of other plugins that also listen to explosions like this (also if fixing the priority works that's definitely easier). I haven't used Graves at all but it just seems from my basic lookthrough that you'd want to get in quick and make sure no other plugin touches the grave block in an explosion event

@Legoman99573
Copy link

Legoman99573 commented Nov 7, 2024

Hmm, could you explain what you mean by protection logic? How does it cause a problem with heads popping out? There is an event you can listen to, I can help you set that up, but I'd imagine you'll have problems with a lot of other plugins that also listen to explosions like this (also if fixing the priority works that's definitely easier). I haven't used Graves at all but it just seems from my basic lookthrough that you'd want to get in quick and make sure no other plugin touches the grave block in an explosion event

If an explosion occurs, it works as expected to keep the grave around. The solution I am looking for is regenerating blocks that were exploded as it pops the head. I am looking to capture the block and update the replace material state so that when the grave does get looted, it will place he block back instead of leaving holes in the ground as they are determined as air, like if the grave is generated in the exploded hole in the ground.

@pmdevita
Copy link
Owner

pmdevita commented Nov 7, 2024

Ah I see, CreeperHeal is removing the head block of a grave and replacing it with the original block that was there prior to the explosion? I think the trickiest part of handling this is to figure out what to do with the block that was originally there. How do you handle situations where the player dies due to suffocation? If there isn't any air, where do you place the head block?

@Legoman99573
Copy link

Legoman99573 commented Nov 8, 2024

Ah I see, CreeperHeal is removing the head block of a grave and replacing it with the original block that was there prior to the explosion? I think the trickiest part of handling this is to figure out what to do with the block that was originally there. How do you handle situations where the player dies due to suffocation? If there isn't any air, where do you place the head block?

likely situation is that there is pvp going on in the hole and the blocks regenerate during that time while the grave is in the hole where the explosion happened. I could move the graves up, but with the current code base, its not possible to do so without re-writing the whole plugin and doing consistent checks every tick may not be ideal as it may cause performance issues.

@pmdevita
Copy link
Owner

pmdevita commented Nov 8, 2024

Sorry but just to clarify, putting CreeperHeal aside for the moment, how does Graves currently handle death by suffocation? Where does it put the grave?

@Legoman99573
Copy link

Legoman99573 commented Nov 8, 2024

It places the grave above or below ground depending on which is closest unless using the API, which the API can override the location if set.

@pmdevita
Copy link
Owner

pmdevita commented Nov 8, 2024

OK I think that gives us two options. On a death, prior to grave placement, you can check if CreeperHeal is currently planning to place a block over the grave. Then,

  • You can then use that info with the suffocation grave moving code and move it up or down to the proper place. This one gets to place the grave immediately, but it could maybe cause some issues i.e. the best place for the grave is currently in midair.

  • You can wait for CreeperHeal to finish repairing the explosion, and then it can return a callback once repairing is complete and its safe to place the grave. Then you can just resume the grave placement code and it can solve the potential suffocation issue without any changes.

I do think 2 is probably our best bet, what are your thoughts? We could also maybe do a hybrid of the two, we do 1 if it doesn't end up in midair and then 2 as a last but safe resort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants