Yarn: NORTH/S/W/E/U/D -> ZN/ZP/...

Sorry, but I disagree.

• If you don't have a very good skillset in maths, these names are more confusing and much less readable in code.
• "Code is usually being written with the axis+direction or xyz coordinates in mind, not a cardinal direction ("5 blocks west + 1 south")." - That code usually simply modifies the x/y/z coordinates directly, not uses the enum.
• Everyone I know, even non-modders, coordinate with this cardinal direction mapping in mind, simply by using them to refer to their relative distances, say.

I think this is being overly strict.

Aside of up/down, I've never had to explicitly reference any of the other directions, so I would consider it a non-issue. It's rare to see something that works differently on different horizontal direction, with that direction being hardcoded. Maybe except some switch...case on all the existing directions, but in either case you still don't need to know how those directions map to coordinates, because there are more than enough useful methods there.

And it's also an enum, where it's probably not a good idea to rename the entries. String names in bytecode directly correspond to what the field names should be, there is a good chance it's going to confuse decompilers and maybe even IDEs.

Yes, that's also an important factor. valueOf() for Direction returns the cardinals, so Mojang does actually refer to them like so internally.

There are generally 4 contexts/uses for the horizontal facings:

• iterating all
• opposites (neighbor interaction, worldgen)
• coordinate deltas (e.g. entity movement code)
• axis (see uses of the axis nested class)

Opposites are slightly more clear with the axis notation due to same prefix. Coordinate deltas strongly favor the axis notation, a.getX() - b.getX() relates obviously to XN/XP, but not so much to west/east. Axis are also X/Y/Z, not north-south/west-east/up-down.

" very good skillset in maths" -> they are basic coordinate offsets/directed axis, this is not hard or unreadable. Contrary, "west" is unreadable if the code around it works with coordinates and you have to look its coordinate relationship up first.

"That code usually simply modifies the x/y/z coordinates directly" -> the offset/move methods in BlockPos disagree. You actually do those direct modifications because of how unclear the relationship is with the current names

Renaming the enum fields is a no technical issue, they are called a-f in mojang names. I think they are bad enough where it matters to not cater to Mojang's naming choices either.

I simply fail to find a single case where north/south/west/east make sense other than looking slighly less mathy.

Renaming the enum fields is a no technical issue, they are called a-f in mojang names.

Incorrect. The enum name is preserved despite obfuscation to make valueOf calls work, even by Mojang's Proguard configuration. Those are names we know.

The fields as shipped are called a-f, just like we are renaming the fields. Since the renaming works for Mojang, it'd work for us as well.

Big no from me.

I also disagree, I feel this would cause more confusion than its worth

If anything, I'd say NORTH_XP, SOUTH_XN, etc.

However I really don't see the need for this. I'd just stick with the current ones

NORTH_XP

It's NORTH_ZN.

I think you have just proven Player's point.

But I agree with modmuss and kashike, even though I can see your point somewhat more clearly now and I think it's somewhat valid.

I dont agree with and this would cause a lot of confusion