Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MLT Rivers, tentative investigation result #330

Open
PatrikLundell opened this issue Nov 27, 2019 · 0 comments
Open

MLT Rivers, tentative investigation result #330

PatrikLundell opened this issue Nov 27, 2019 · 0 comments
Labels

Comments

@PatrikLundell
Copy link
Contributor

PatrikLundell commented Nov 27, 2019

I've had reason to look into the weird way DF handles rivers at the Mid Level Tile (MLT) level. I don't think the results are good enough to be considered proven, but think it would be useful to document them somewhere anyway.

The DF structure involved is df.global.world.world_data.region_details [] and the elements involved are rivers_vertical and rivers_horizontal.

  • x_min/x_max and y_min/y_max describe exactly where a river segment leaves/exits an MLT. If a river entrance and exit are both horizontal or both vertical you have to look at the interfacing tiles to find the other entry/exit point. I consider this established and provide it here for reference only.
  • Observation, strengthened by a recent speech by Toady indicates rivers don't meander, but always moves toward the other entrance/exit. That is, if the entry is at X = 3 and the exit is at X = 10, the river will always have the next point at an X value higher than or equal to that of the previous one, until reaching 10, and the same goes in the Y direction. Thus rivers are always slanted diagonally (with exactly vertical and exactly horizontal as special cases). It seems similar logic applies between the MLTs as well, i.e. within the world tile. This is a tentative result.
  • The "active" field can take a value of -1, 0, or 1, with 0 being not active, and -1/1 indicating direction in some fashion. I'm not sure how to determine the "some fashion" part, though (the interpretation I've made in my regionmanipulator script is likely incorrect).
  • For some reason DF doesn't provide any information for some of the tiles the river flows through, but this has to be deduced by processing neighboring tiles. I have no idea why Toady has decided to use this rather cumbersome and lopsided logic, but there's presumably some reason.
  • Rivers flowing to the NW and the SE seem to be well behaved, i.e. each of the river tiles is present (source/sink/edge can be an exception) and the "active" field consistently use the same values for the tiles interfacing to the N and W for the NW case and S and E for the SE case. Tentative result.
  • Rivers along the other diagonal are weird. Instead of just having a sequence of tiles, the bends between W and N have the "active" fields set for both the vertical and the horizontal element, while the bends between S and E are omitted, and have to be deduced from the presence of connecting river tiles. The "active" fields for the bends present have one pair of values for rivers going SW -> NE and the opposite one for NE -> SW, while the tiles that have only a vertical or horizontal extent use the same values as those in the well behaved diagonal. Tentative result.
  • Rivers sources (and, presumed but not investigated, sinks) are similarly subject to different rules depending on the directions of their connecting rivers. When the river is to the N or E of the source/sink, the source/sink is explicitly marked as a river, but when it is to the S or W the source/sink has to be deduced. Tentative result.
  • The same logic applies to MLT entry/exit, i.e. the river tile is explicit only if their connections are to the N or E. Tentative result.
  • The river elevation of implicit river segments appear to be the lower of the two connecting segments. Deduced by hacking rivers going in both direction and embarking, but no check against natural cases of differing river elevations have been made. Tentative result.

To clarify, the results indicates the diagonal orientation is the guiding factor when determining whether features are explicit or implicit, not the flow direction. Tentative result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants