2D Coordinate Type

[dxrcy]

Introduces a new '2D coordinate' struct which mirrors the existing Coordinate struct, but does not contain a y value.
Adds constructors to (often implicitly) convert between Coordinate and Coordinate2D.

Replaces some parameters and return values with Coordinate2D in relevant functions (getHeight and getHeights in MinecraftConnection, get_worldspace and base_pt in `HeightMap).

Possible changes:

• Rename to Coordinate2 (mirrors naming style for other libraries, eg. Vec2, float3). Likely not ideal since Coordinate keeps the same name regardless.
• Update documentation for description of Coordinate2.

Note that overloading function parameters such as MinecraftConnection::getHeight to accept a Coordinate is unnecessary, since a Coordinate will be implicitly cast to a Coordinate2 in such a context.

[rozukke]

Also, something like a filled() or with_height() method would be nice for Coordinate2D as a quick shorthand to get areas of non air blocks - for example:

auto c1 = Coordinate2D(0, 0);
auto c2 = Coordinate2D(100, 100);
auto chunk = mc.getBlocks(c1.filled(), c2.filled());

where each filled() call does a getHeight() under the hood.

[dxrcy]

where each filled() call does a getHeight() under the hood.

How could it do this without accessing the MinecraftConnection?

I suppose Coordinate2D::filled could return a new type which getBlocks has an overload for, but this seems unintuative.

Perhaps withHeight could be a method of MinecraftConnection, to convert a Coordinate2D to a Coordinate:

Coordinate2D c1{0, 0};
Coordinate2D c2{100, 100};
Chunk chunk = mc.getBlocks(
    mc.withHeight(c1),
    mc.withHeight(c2)
);

Although this doesn't read as nice (grammatically), so withHeight could have a different name.

Note that getHeight and withHeight would be essentially the same, but withHeight would return the entire coordinate. This would not be possible as an overload of getHeight, unless some flag parameter is passed.

Alternatively, getBlocks could accept Coordinate2D arguments, but I think this would lead to more confusion.

[dxrcy]

I think mc.fillHeight would be a good name instead.

[rozukke]

Ah, my bad. Didn't think through that dependency properly. Your suggestion sounds good (with snake case though).

[rozukke]

Looks good! Hopefully this is a step towards reducing ambiguity in the existing api

[dxrcy]

TODO: HeightMap::fillHeight to match mcpp::fillHeight
HeightMap::fill_coord should cover this.