q: how can i respawn at a random location within a min/max radius of my death location?

[meoso]

idea blatantly taken from "Ghosts" plugin. I'd like to be able to respawn at a random location say between 40 and 100 blocks from my point of death (where 40 and 100 are variables i can set).

[andune]

Interesting feature request. HSP 2.0 tracks death location so this would actually be really easy to implement. I'll take a look at it.

[andune]

This is available as of HSP 2.0 build #560 (on andune.com/jenkins).

Here is the documentation in the strategy source for how to take advantage of it:

https://github.com/andune/HomeSpawnPlus/blob/master/core/src/main/java/com/andune/minecraft/hsp/strategies/LastDeathRandomRadius.java#L36

[meoso]

praise.

[soopageek]

The builds are way past build #560 at this point, obvs... has this been implemented in 2.0 or no? There's yet to be any documentation. I've tried adding it as an event strategy, but I'm not having any luck with it. Just thought I'd bump this to see what the status is. This would be a fantastic strategy to have.

[andune]

This code is in the latest 2.0 builds, though I haven't tested it since it was written. Nothing has changed with the strategy since it was written and tested, so I'd expect it's still in good working condition. Certainly happy to take a bug report otherwise and look into it.

Documentation is sorely lacking for HSP at this point, which is unfortunate. And unless someone volunteers to start writing docs, it's unlikely to be resolved anytime soon. The docs for this feature, as linked above, are contained within the comments, so the usage is as so:

lastDeathRandomRadius:radius;yVariance

such as:

events:
  onDeath:
    lastDeathRandomRadius:100

This would spawn someone within 100 blocks of their death location. If that's not working, please turn on verboseStrategyLogging and pastebin the logs from your attempts here. That might make the error obvious to your or me from the logs, or if not, might give you the necessary information to file a bug report.

[meoso]

what if using multiverse, and want this only for one specific world? also what about a minimum so not to re-spawn too close. p.s. thank you, the existing function does work as coded.

[andune]

Then usual HSP per-world configs apply. Something like:

events:
  world:
    myworld:
      lastDeathRandomRadius:100

[andune]

The new format (latest build) for this strategy is:

lastDeathRandomRadius:maxRadius;minRadius;yVariance

For example, if you wanted players to spawn at least 50 blocks away but not more than 200, and you want them to spawn within 10 blocks of the vertical range they died in (instead of up to 200), you could use:

lastDeathRandomRadius:200;50;10

[meoso]

That's fricken awesome @andune; totally works! Using this in conjunction with PlayerDeathLocation and Cenotaph

  # strategies to use when player is respawning after a death
  world:
    my_adventure_world:
      onDeath:
      - lastDeathRandomRadius:330;80;10

  onDeath:
    - homeMultiWorld
    - spawnLocalWorld

[soopageek]

Turns out I was putting a space between the colon and the radius value... works just fine for me, now. Thanks!

[andune]

Glad it's working well for you both. Enjoy!

[soopageek]

I encountered a problem with DeathRandomRadius, but I'm not sure if it's a configuration problem or a bug. I'll tell you what happened and my config... and if you need me to open a separate ticket to document it, just let me know.

Here is my config section for onDeath in the Nether:

world_nether:
  onDeath:
    - modeYBounds:5;120
    - lastDeathRandomRadius:100;50
    - spawnLocalWorld
    - default

I died the other day in the nether and re-spawned on top of the bedrock roof (y128). HSP probably shouldn't allow that by default (personal opinion) but shouldn't my modeYBounds config have prevented that anyway?

[andune]

Yes. HSP tries really hard to obey the restrictions given for random teleports: it does so by picking a random location, then searching in concentric squares around that point for a safe spot that obeys the rules (don't suffocate them, don't port them over lava, you can restrict water, trees, snow, etc). It gets exponentially more expensive each "ring" processed, so it will check some amount (I think 10?) of rings before it gives up and tries a new random location.

It will continue in this fashion for up to 15 times and then it just gives up and teleports them at whatever the last random location was. This is to avoid it lagging the server by infinitely looking for a random spot that it might never find. In all of my local testing with hundreds of teleports, once or twice I managed to tap out the the restrictions: this was more likely the more severe the restrictions and the less likely the terrain I was in was to meet those restrictions.

In your case, you're in the nether, a place that isn't uncommon to have lots of solid block (suffocate) and lots of lava (burn), you've restricted it to a 50-block area around the death (block range 50-100) and Y 5-120. It seems entirely likely that you could die in an area that after 10-15 random tries, HSP can't find a safe location that meets the criteria and so you will end up somewhere random that might kill you (suffocate or lava) at which point HSP's safeTeleport algorithm will kick and teleport you to the nearest safe location, which might violate your original bounds restrictions.

The only way to know for sure is to try to repeat the scenario with debugging turned on, at which point HSP will be very verbose and descriptive about it's attempts, and it's likely you'll see it testing hundreds or thousands of blocks for a safe location before finally teleporting you wherever you end up.

I thought about having some sort of "fail safe" strategy for these failed random attempts, but ultimately just figured it was rare enough that it would happen that I didn't worry about and want to add a bunch of extra code for an edge condition. In several years of HSP having various random teleport strategies, you're the first person besides myself to notice one of these failed teleport events, so it wasn't a bad strategy. :)

[andune]

BTW, if you want to confirm my theory about what happened, this is the log message you can search for in your logs that is printed out when it happens for that strategy:

            log.info(getStrategyConfigName()+" unable to find random location that met configured range after MAX_TRIES({}) loops. Returning null result.", MAX_TRIES);

[soopageek]

I guess my assumption was that, in the rare event that DeathRandomRadius exhausted its internal limit for a safe teleport, that it would move on to the next strategy in the config (in my my case, spawnLocalWorld) but I guess it's not setup that way.