Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 11 12 [13]

Author Topic: DFHack plugin embark-assistant  (Read 25905 times)

clinodev

  • Bay Watcher
  • Embark Profile Enthusiast
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #180 on: January 19, 2020, 04:43:24 am »

Thank you for all your work on this project!
Logged

RedDwarfStepper

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #181 on: January 19, 2020, 05:20:51 pm »

A new DFHack version has been released. This also means all changes made to this plugin since the last release are released as well.
I'll try to remember what has been done over this period...
Splendid!

Being nitpicky I know, but there was also the bug triggered by pocket worlds:
Thanks for the crash report.

It took a bit of time to find out what was wrong, but it is indeed a bug.
The line should be
Code: [Select]
            tile->region_type[i][k] = world_data->regions[tile->biome_index[mlt->at(i).at(k).biome_offset]]->type;
i.e. "biome" -> "biome_index".
The reason it crashes only on pocket worlds is that the number of regions in those worlds tend to be fewer than the number of biome types, i.e. the index passed in was the biome type, but was interpreted as the index of the region.
The bug should screw up the reasonably (I think) uncommon searches for region types when it doesn't cause a crash.

Also thank you for your fast answer concerning incursions.
I'll have to do some more code reading and stepping through the code during survey and matching phase in a small world to get a better grasp of the details.
What I can say is this: The index structure actually would allow for storing data of an incursion from a neighbor before the receiving MLT was being surveyed, all that is needed is the correct key, that can be calculated - thanks to you - but it might be rather complicated to get rid of those if they are an ocean/mountain and the receiving MLT is e.g. a desert.
This also results in a question: Does the following sentence only mean that the biome won't be transferred or does it also include all other features (aquifer...).
Quote
There are also certain rules forcing ocean/lake biomes to lose edges to mountains, and both of them to anything else, no matter what the original array value is.
If this includes the biome and all the features I would have to retain all this info for later, so it could be undone.
If this only refers to the biome it just could be removed if the receiving MLT has a "stronger" biome type.

Quote
Also, you can't just merge things together as you go, as that would cause incursion info into a tile to be propagated into further tiles as part of the "real" data for that tile.
Currently my design keeps the real source data (MLTs) separate from the index data (pure sink) during the survey phase - so any further propagation should not happen, but I'm wondering, how could further propagation happen if always 2 tiles (with the exception of corners) are being linked as you said here
Quote
every "receiver" is matched by a "giver" in the corresponding neighboring tile (corners has one "giver" and 3 "receivers"), and there is no "neutral" choice: there is an intrusion in one direction or the other.
Sorry if I should have understood/interpreted that wrong, which is quite likely. That would be just more evidence I need to see those rules and the data in the context of program execution.
Ah - I think I'm starting to understand: There are up to 8 incursion giver candidates (the neighbors of the MLT as corners and edges) for every MLT (exceptions world-corners and -edges...) but only 1 of them actually will be a giver, but the other 7 could be the giver to another MLT, which includes the winning candidate, which would lead to further propagation. Yes?

Again thanks for your patience!
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #182 on: January 20, 2020, 05:24:38 am »

Yes, the bug you reported was fixed as well, although I missed reporting it.

Incursions are packet deals, to the mountain etc. incursion inversion applies to everything. Instead of a mountain incursion into a steppe, we'd get a steppe incursion into the mountain, with all the associated data.

Hypothetical incursion contamination process:
- Survey World Tile A, and apply incursion information to border World Tile B MLTs that haven't been surveyed yet. As a result, some of these border MLTs may have info about containing biome A, B, and C (because it happened to receiving incursions both from the corners and the edge).
- Process World Tile B, where the edge tile above is identified to have a native biome D, so its biome set is now (A, B, C, D).
- Process incursions in World  Tile B, at which time we note that the problem MLT above makes incursions into two neighboring tiles, resulting in those tiles getting tagged with biome A, B, C, and D in addition to whatever biome it has natively, but the incursion actually contains only D.
The above also goes for other properties, such as e.g. aquifers.

You can't keep all the data from all MLTs in the world throughout the survey process, or you'd use up too much memory: you have to discard the data when the processing of it is done as you go. I've retained the border MLT info for incursion processing but discard the interior data when the processing of that world tile is finished. You'd have to do something similar, but can be more intelligent about it and discard the border data as it has been used for all relevant incursions.

It seems like you misunderstand the giver-receiver relationships. For a given (interior) MLT there are 4 edge incursions either going inwards or outwards so the tile can receive 0-4 incursions and perform 0-4 incursions, with the sum being exactly 4.
For each corner there is exactly one incursion provider and exactly 3 incursion receivers (all receiving from the same provider).
Thus, if you know the situation for one side of the arrangement, you also know the situation for all the other sides of that arrangement, which is why DF stores the info in a single place for each of these interface points. If the East side of an MLT received, that also means the West side of the MLT to the East gave.
There is no relation between different interface points (i.e. edges or corners) of an MLT. Each one of them is related only to the counterpart(s) for that interface point (which reside(s) in (a) different MLT(s)). Having an incursion in one place says absolutely nothing about the state of other edges/corners of the same MLT.
Logged

RedDwarfStepper

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #183 on: Today at 05:14:42 pm »

Thank you for those explanations!

I did some more reading and are currently in the process of stepping through the code that handles the incursions - as part of that I created the following annotated call tree:
Code: [Select]
# matcher::embark_match
// tldr; does the actually matching for the current MLT and delegates the incursion processing for the outer edges of the embark rectangle as there is no need to process the inner part of the embark rectangle
// starting ~ line 773 the both north corners (NW+NE) and the north edge of every northern embark MLT of the embark area, then the south corners (SW+SE) and the south edge of every southern embark MLT are being processed
// starting ~ line 888 both west corners (NW+SW) and the west edge of every western embark MLT and then both east corners (NE+SE) and the east edge of every eastern embark MLT of the embark area are being processed
// the second loop respect all already processed corners, so no duplicate processing
    # survey::translate_corner/survey::translate_ns_edge/survey::translate_ew_edge
    // those 3 methods apply the rules described in world_region_details for edges.biome_corner/edges.biome_x/edges.biome_y to find the origin direction of the incursion to the current MLT corner/edge
    # matcher::process_embark_incursion_mid_level_tile
    // locates the correct incursion origin MLT + related RTD/world tile with the passed origin direction for further processing       
        # matcher::process_embark_incursion
        // actually processes the matching with the incursion data with the correct MLT and RTD/world tile

Is that basically correct?

And I'm wondering: Could it be, that in embark_assist::survey::translate_ew_edge instead of
Code: [Select]
biome_x
Code: [Select]
biome_y should be used at the following lines:
https://github.com/DFHack/dfhack/blob/82f082d7cbd6b823ab4c54d0dfbbf578f7fb1c4a/plugins/embark-assistant/survey.cpp#L1912
https://github.com/DFHack/dfhack/blob/82f082d7cbd6b823ab4c54d0dfbbf578f7fb1c4a/plugins/embark-assistant/survey.cpp#L1917
as the edges between east/west tiles run vertically/in y-direction?
Or am I getting something wrong here again?
Logged
Pages: 1 ... 11 12 [13]