lesserhydra / secondchance Goto Github PK

Although it's terribly unlikely that a hitbox armorstand will get left behind in the world during normal use, there are cases that need to be handled. Could use attributes, thanks to 1.9.

Description:

When the plugin/server is reloaded, the online players are not given a safe location in the metadata. This causes deathpoints to fail to create if the players in question don't move through a "safe" position.

Note that this should never occur during normal server operation.

Reproduction:

/gamemode 1
Jump in lava
/reload
/gamemode 0

Expected:

A deathpoint should be created.

Actual:

A NPE occurs, and the items die in a fire.

Description

When a player sneaks on the edge of a block, the location over the edge is marked safe.

Reproduction

Tower a couple blocks into the air
Sneak on the very edge of the block
/kill

Expected

Deathpoint should be over the top block

Actual

Deathpoint is off to the side, over air

Sounds could help give deathpoints that "finished" feel that they're currently missing. Everything would be configurable, of course.

Some ideas:

• Created (Direct?)
• Forgotten (Direct?)
• Interaction
• Closing

It seems something's changed in 1.10 that's causing armorstands to get left behind on world save again. What's odd is that it's happening in what should be unloaded chunks. Seems to be happening when attempting to respawn hitboxes in loaded chunks.

After further testing, it seems the Chunk.isLoaded() method is bugged in the current Bukkit(Spigot?) version.

The hitbox system needs to be improved. Ideally, hitboxes will be client-side only, so that the plugin doesn't have to worry about removing them before unloads, reloads, shut-downs, and crashes. This will also allow deathpoints to be shown on a per-player basis.

Now that I've messed with unit tests a bit, I should be able to do things much more elegantly.

• List all deathpoints
• Open deathpoint (Without breaking on close!)
• Break deathpoint

As far as I can tell this doesn't happen though vanilla means. In this case another plugin is sending a custom damage event in the aftermath of a spell from that plugin.

I originally planned on supporting Bukkit 1.8, but I've since realized how difficult this is in execution. 1.9 introduced the particle api (obviously used for particle effects) and the attribute api (used to mark armorstands for deletion in case they get saved to the world file), as well as the ability to play a sound via Strings (instead of the Sound enumeration).

While it is certainly possible to get the plugin working in 1.8, the difficulty lies in making it work elegantly and without adversely effecting the post-1.9 version. It seems my choices are as follows:

1. Make the plugin dependent on the version of Bukkit
2. Use interfaces to have a single plugin version decide whether to use 1.8 compatibility
3. Make a separate version for 1.8

The first option is certainly out; SecondChance is designed to work with any version post-1.9, and there's no way I'm going to start using unchecked reflection. The second option could be viable, but it'd add unnecessary bulk to the post-1.9 version. Separate versions seem to be the best way to go, but that begs the question: how do I build multiple versions from a single codebase?

This requires more research.

Currently, there is an option that maxes out the number of deathpoints a player can have at once. It would be more useful if it instead instated a sort of countdown that destroyed the deathpoint after a certain number of deaths.

Should allow an op to see the contents of a deathpoint without breaking it.

Add a message that shows on death and when a deathpoint is forgotten. These need to be configurable (using special tags) and optional.

Title is fairly self-explanatory.

Description:

Experience points still get stored in a deathpoint when the gamerule keepInventory is set to true.

Reproduction:

/gamerule keepInventory true
/xp 10L
/kill

Expected:

No deathpoint should be created.

Actual:

A deathpoint with 10 levels worth of experience is created, and the player looses nothing.

It seems that the armorstand hitboxes might be getting saved to the world right before the plugin is unloaded. This might be fixable by despawning hitboxes on world unload, instead of waiting for the plugin to unload. Perhaps the hitboxes should also be despawned before every save as well?

Thankfully, the safety net implemented in 0.6 can handle the leftovers in the meantime.

Whoops.

Need a way of blacklisting worlds.

Description

A player's location in not considered "safe" when riding a horse, or anything else for that matter.

Reproduction

Stand on an obvious block
Mount a horse without moving from the block
Ride a ways away, and stop in the open
/kill

Expected

Deathpoint should show up where the player was on death

Actual

Deathpoint is created over the original block

In order to make changes to the configuration, I need a light system for updating old configs without any effort on the part of the user.

ArmorStand.setInvulnerable() was not implemented until 1.9.2.

Description:

The stored experience points are sometimes off ever so slightly when dealing with high levels.

Reproduction:

/xp 100L
/kill
Open deathpoint and collect exp

Expected:

You should get 100 levels back exactly.

Actual:

You get 99 levels and the experience bar is barely short of full. Typically, "/xp 1" (For 1 exp, not level) will finish it off.

Some ideas:

• Working with disabled worlds
• Task canceling on disable
• Permissions
• Hitbox fallback attribute
• Deathpoint invalidation/removal
• Configuration keys? (make sure default config keys match lookup keys; possible?)
• Hitboxes de/respawned on world save
• Save on world save and deinit
• Config options (all the things)