Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[RedDwarfStepper]

@PatrikLundell:
I think I'm done with the incursion processing.
Unless I'm still missing something (staring at survey::translate_corner and especially at #L1690 and at #L1693), so just to be sure as it got lost in the details of the bug discussion:

...
Long question short:
Is it possible to process corner incursion at the edge of the world with only two candidates and if so for which world-edges is it possible?

I know it works for the northern and the western world edge.
But is there any way to process the corner incursions of the eastern

Code: [Select]

x == world_width - 1 && i == 15 && corner_location == 8
and southern world edge

Code: [Select]

y == world_height - 1 && y == 15 && corner_location == 8
with only the two eastern

Code: [Select]

i == 15 && k = [0-14] and k + 1
or southern

Code: [Select]

i = [0-14] and i + 1 && k == 15
corners that are available?
Or is there just no data (=> edges.biome_corner/region_tile_datum.north_corner_selection/region_tile_datum.west_corner_selection) to resolve those?

[PatrikLundell]

I'm trying to understand the question, but may still get it wrong....

x = world_width -1 and i = 15 with a corner location of 8 ought to result in an effective_x = world_width (and effective_i = 0) after having been processed by adjust_coordinates at line 1662, and thus be handled by the processing at line 1664, and similar for the southern edge (line 1677).
The reason for that overriding section is precisely that there is no data to read, and fallback values have to be used (and the fallbacks are what I've seen DF produce when I've looked at these edges).

[RedDwarfStepper]

I think you got it perfectly right.
I'll lay out an example, so there is less room for misinterpretation on my side.
So, lets look at the south-east corner case on the southern edge of the world.
I'm debugging this in a pocket world, 17x17, let

Code: [Select]

x == 14
y == 16
start_y + finder->y_dim - 1 == 15the last one translates to k == 15
so my breakpoint condition for this line is as follows

Code: [Select]

x < 16 && y == 16 && start_y + finder->y_dim - 1 == 15
I just stepped from
matcher::embark_match, the "SE corner south row" case
to
survey::translate_corner
which only happens for the southern edge of the world (effective_y == world_data->world_height), when looking at the south-east corner (corner_location == 8 ).
translate_corner returns 3.
Taking this value to
survey::process_embark_incursion_mid_level_tile
which means we get the data for the south-east corner incursion from the western neighbour (i - 1) of the currently processed tile, correct?

Is that the logic to produce the fallback values you mentioned

The reason for that overriding section is precisely that there is no data to read, and fallback values have to be used (and the fallbacks are what I've seen DF produce when I've looked at these edges).

?
Or am I not seeing something here?
(It's getting late and I might be a little confused )

[PatrikLundell]

That's clearly wrong, as you point out.

I'm having trouble remembering what the behavior was, but assuming the overall logic is correct, the "3" should be "5", i.e. the eastern tile, not the definitely incorrect western one. If that eastern tile doesn't exist effective_x would be world_width, and so caught in the first section, so that tile should always exist.

[RedDwarfStepper]

That's clearly wrong, as you point out.

You give me too much credit for this one.
I wasn't even assuming that it might be wrong - I just wanted to understand the logic/process.

If line 1682 always returns 5 (eastern neighbour is incursion source) for every south-east corner incursion at the southern edge of the world without regard for the region type, than that also means that every tile (but the last) has an incursion from its eastern neighbor, doesn't it?

[PatrikLundell]

Well, you did flag "western" as suspicious, and rightly so, as the only legal alternatives for those corners are self, E, S, and SE.

Not quite, as line 1679 returns "self", so the alternatives are "self" and E for those tiles.

However, it seems that the code should have compared the region types and swapped the results around where appropriate, so a straight "return X" seems to be hasty.

[RedDwarfStepper]

Haha, yes, suspicious fits quite well.

Ok, so instead of returning 3/5 directly in L1682 the flow would need to continue along the function, while skipping L1686 till L1694, as neither biome_corner nor *_corner_selection are available/contain valid data for this case.
This makes setting a proper/correct value for effective_corner in the else-branch necessary, one that will lead to a correct return value of the function - I'll look into it.
embark_assist::survey::region_type_of actually handles none existing tiles pretty well (returning Lake), so no need to change anything there.
That also means that the non-existing corners/tiles will receive a low *_region_type_level which should sort them out automatically.
I'll have to run some tests...

Thanks for your ongoing support, I really appreciate you taking the time to answer my never ending questions!

[PatrikLundell]

I'm impressed that you're putting all that effort into updating the code, and you've proven that the code needed a code review as well. Thanks for that.

[RedDwarfStepper]

Well thank you
Once we had our initial exchange I just couldn't let go of it and up until now there wasn't any total road block that prevented me from carrying on.
Also embark-assistant is quite different from my day job which intrigues me and yet it is similar enough that my skills, experience and intuition are helpful.
It's like a very time consuming riddle - soon it will be a year.

Having said that, I was thinking: Isn't what we have concluded in our previous posts true for the south-east corner at the eastern edge of the world as well - always returning 4 in survey::translate_corner if 7 could by a valid value too seems strange ...

[PatrikLundell]

The logic for the south edge corner is reflected for the eastern edge, but rotated 90 degrees in the form of "5". The valid value of 7 results in an effective_x of world_width -1, and thus would be handled by the regular code further down.

Remember that each corner has 4 different possible outcomes, and the special handing applies only to the two of them that would refer to tiles outside of the map (and the extra special case of the very SE corner of the world is handled just above, always returning "4").

[RedDwarfStepper]

I think I get what you are saying.
But what I mean is this: Being at the eastern edge of the world, (effective_x == world_data->world_width && i == 15) and looking for incursions on the south-east corner here, there are two valid return values at this point, 4 and 7, the current tile (4) and the tile south of the current tile (7).
But translate_corner always returns 4 for this case - shouldn't the region_type factor into the return value here as well - in fact for all special "edge" cases except the first

However, it seems that the code should have compared the region types and swapped the results around where appropriate, so a straight "return X" seems to be hasty.

[PatrikLundell]

Ah, that's what you meant!
Yes, it should perform that evaluation, but I thought we'd already drawn this conclusion (for the southern edge, which should apply to this one as well), which is why I took your comment literally, rather than involving the larger context.

[RedDwarfStepper]

Ok, I'm doing some embark science via sampling edge cases (neighbor with aquifer incurs into neighbor without aquifer ...)
And I'm wondering: How far does an incursion reach into the receiving embark tile?
I've seen something about 12,13 (small) tiles?
Or is this coincidence with my samples and there is no rule for the "depth" of an incursion?
Asked differently: Does an incursion via a corner into 3 other embark tiles concentrate in the complementary corners of the receiving embark tiles?
Or is incursion more defined along the line of: receiving embark tile has now sand not only along its edge or the incurred corner but spread everywhere in its 48 x 48 area.

[PatrikLundell]

I'm not sure about the exact logic for incursions, but I believe the edge information about where the division of the edges into sections result in four points in the tile acting as starting points for the divisions, and random generation then generates boundaries from those points out to the edges. If the incursion goes into the neighboring tile instead, the point doesn't have any effect for that incursion on the current tile, but instead affects the neighboring tile (where the division point in the other dimension doesn't have to have the same value).


*  10 40  *
11        13
38        41
*  12 36  *

would result in the points (10, 11), (40, 13), (12, 38), and (36, 41). The divisions along the edges are shared with the neighboring tile on the other side, so the top eastern corner of the tile to the west of the one above would  be (x, 11), where x is given by the value on its norther border.

It should be noted that it's how I think it works, but I haven't confirmed it. I've confirmed that the coordinates along the borders do not match where the borders are divided themselves (i.e. in the above example, the division between the NW incursion and the N one [or the native one, if the N incursion goes outwards] doesn't appear at X = 10, but typically further away).

I'm not sure the confused rambling above makes sense, though...

[RedDwarfStepper]

Hehe, it might be confused rambling for you, but I can relate.

*  10 40  *
11        13
38        41
*  12 36  *

Let me paraphrase one key takeaway: The offset/division of the dimension/edge (horizonal - x/vertical - y) that is shared with the neighboring tile is used in both cases either if the incursion is incoming or if the incursion is outgoing to the neighboring tile.

Is the above by any chance another way of representing this schematic?
That would mean I could try and use the data from split_x and split_y to verify my assumptions?
And if I understand correctly the split/division data should be the same for the edge that two neighbors share?