I would like to alter the y height of the border, preferable per world.

Currently it looks as if the y height is hard coded to show up on the dynmap on a height of 64.
Custom worlds may have a different height.
This leads to a wrong perspective on dynmap if the perspective is isometric.

Worldborder 1.9.9-beta
Paper 1.13.2 build 630
Dynmap-3.0-beta-4

Borders have no Y component, they effectively have infinite height.

I'm not sure about them being displayed in DynMap with a height to them in the isometric view, offhand. Pretty busy lately, but I can probably try looking into to eventually.

I'm not sure where this height comes from. I thought it was hard coded in WorldBorder because I found some code here with y = 64.

Anyway; I "solved" it for now by making a custom dynmap marker. So no hurry ;-)

Attempted fix.
0d45093

Try it out, please. If you can't build it yourself, I can provide a test build.

EDIT:
Mistakenly pointed to wrong code earlier. It does appear to specify 64 for some reason:
https://github.com/Brettflan/WorldBorder/blob/master/src/main/java/com/wimbli/WorldBorder/DynMapFeatures.java#L184

Not sure why, that could probably be switched to reference World.getMaxHeight() instead. Or at the very least 256 should be a safe enough bet now. I can try that out when I have time to investigate further. If someone else can test it, that would be great.

Tried it, but I don't see any change.
I have tried the following config:

  world:
    x: 0.5
    y: 200
    z: 0.5
    radiusX: 2500
    radiusZ: 2500
    wrapping: false

I guessed the Y value so maybe it's my own misinterpretation...

I think the border is normally shown at Y = 64 because that is sea level, so if you're drawing the border in a projection where the Y component is relevant (i.e. not a top-down view) it'll generally be in roughly the correct location. I assume that @x1p has a world where the sea level isn't 64, or it's all land and the average altitude isn't 64?

If my understanding is correct, then setting Y = World.getMaxHeight() is probably going to look worse, and the original request of allowing this value to be customised per-world is probably the only sensible way to deal with these cases.