Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 17 18 [19] 20 21 ... 24

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

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #270 on: December 04, 2020, 04:48:59 am »

If you stop digging up bugs I'll stop trying to fix them ;)

It's great that you're able to find so many bugs (although I'd wish there wouldn't be that many to find in the first place).
Logged

RedDwarfStepper

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #271 on: December 15, 2020, 03:40:58 pm »

Ups I think I did it again :D - there were some results related to incursions at world tile borders I couldn't wrap my head around and after adding more and more logging output I finally did some debugging, which lead to a realization almost instantly:
There is copy-paste-wrong-index issue here and here
Every time i or k is used instead of fetch_i or fetch_k in one of the following terms in the big if-else-block
Code: [Select]
&survey_results->at(fetch_x).at(fetch_y).*_row[i]
&survey_results->at(fetch_x).at(fetch_y).*_column[k]
it potentially uses the wrong mlt to check for incursions.
This also means that fetch_i and fetch_k must be readjusted in the blocks where fetch_x and fetch_y are adjusted here and here
similar to how it is done in survey::adjust_coordinates


Actually using adjust_coordinates might be the good solution.
Nevermind: values < 0 and > 15 are properly handled for fetch_i and fetch_k...  ::)
What do you think?

PS: survey::adjust_coordinates is not available in the context of matcher...
« Last Edit: December 15, 2020, 03:56:21 pm by RedDwarfStepper »
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #272 on: December 16, 2020, 05:01:35 am »

Yes, it looks like you're right. It can also be noted that the very last clause actually uses fetch_i and fetch_k.
Logged

RedDwarfStepper

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #273 on: December 16, 2020, 07:04:48 pm »

Ok, I think I've got one more...
All calls to
Code: [Select]
embark_assist::survey::region_type_ofin survey::translate_corner here and probably here and here as well should be using effective_x and effective_y like this
Code: [Select]
embark_assist::survey::region_type_of(survey_results, effective_x, effective_y, ...
I'm pretty sure about the first location with the 4 calls in a row, not so much about the other two locations, as my version of the translate_corner is older.
The error only manifests while going across world tile borders and if the corner_location is not embark_assist::defs::directions::Center but for example embark_assist::defs::directions::Southeast and the home_tile lies in the world tile east (south + south-east?) of the current one. So it should break for embark_assist::defs::directions::East and embark_assist::defs::directions::South as well.

I stumbled upon it as I mostly only use embark_assist::defs::directions::Southeast (or 8 in the old version) for corners and it did not behave symmetrically with embark_assist::defs::directions::Center (4) which resulted in incursions that only happened when looking from the receiving side in the south east...
« Last Edit: December 17, 2020, 02:38:27 am by RedDwarfStepper »
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #274 on: December 17, 2020, 05:47:51 am »

Yes, you're correct again. It doesn't make sense to adjusted coordinates with unadjusted ones.
Logged

RedDwarfStepper

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #275 on: December 24, 2020, 06:42:48 pm »

Merry Christmas to everybody lurking around here!

So everybody is asleep and I'm trying to get this done before the year is over - 3 more criteria (freezing, syndrome rain + reanimation) then at least the search itself will be (mostly) done.
And I stumbled upon something strange - while surveying a 257x257 world I noticed that the temperature values in region_tile_datum seem to be mostly identical within a region_tile_datum (min_temperature[n] == max_temperature[n] => true for n = 0 - 9) for the whole world - I checked another 2572 world and it behaved the same, smaller worlds behaved different/correct(?) though, with a lot more distribution/differences between min and max temperature.
So I did some digging: The problem seems to be located around here in the function min_temperature.
It's my test world with only one (south) pole => steps = 128; lat = 1 or lat = 0 which results in divisor 0.5 or 0.
As divisor is defined as uint16_t all values below 1 get truncated to 0 directly which results in max_temperatur - 0 here.
Should divisor perhaps be a floating point value?
Or is there something else off with the formula for large (1292  + 2572) worlds if they have only one pole?

« Last Edit: December 25, 2020, 03:58:16 am by RedDwarfStepper »
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #276 on: December 25, 2020, 04:57:37 am »

To start with: my brain is a bit sluggish today, and I have some difficulty understanding the problem. Thus, I may well bark up the completely wrong tree...

To start with the "easy" bit, i.e. how I believe DF's temperature variation works:
- On the coarse scale, DF's temperature variation changes linearly between the mid latitude and the pole as well as between the mid latitude and the equator, with the maximum variation happening at the mid latitude and zero variation at both the equator and the pole. This logic is the same regardless of whether you have a single or double pole world, but the single pole one has twice as many tiles to distribute that variation over.
- On the fine scale, there are steps caused by integer math, plus some weird cycle within same size segments of latitudes, and I don't know what the purpose of that lower level cycle is, just that it is present.
- For large worlds, this means there is no temperature variation at all for several world tiles near the poles and around the equator.

For your 128 step single pole test world, this means there should not be any temperature variation for the first two latitudes (and the two last ones), with a single degree variation happening for the next two latitudes. It's simply a case of an illogical choice of temperature variation logic and too many latitudes to smear out too small a variation over, so every variation value has to be shared over several latitudes. So, unless I've misunderstood the issue (which is entirely possible), I don't see any problem here.
Logged

Iä! RIAKTOR!

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #277 on: December 25, 2020, 04:51:20 pm »

Why embark assistant don't differentiating of lairs? Mound and burrow are different in game code.
Logged

RedDwarfStepper

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #278 on: December 25, 2020, 04:53:34 pm »

Okay, I could be as well me imagining something, but lets look at the numbers of some examples.
The first 4 examples are the results with an unchanged function min_temperature, for the fifth example the type of divisor was changed to float, as well as the expression
Code: [Select]
divisor = (64 / steps * lat);to
Code: [Select]
divisor = (64.0f / steps * lat);
What you see below is the distribution of min-max temperatures below-equal to zero/above zero for all embark tiles. Adding the number of entries for both min and both max row results in roughly the number of total embark tiles (=> 3. column). The delta between the sum and the actual number of embark tiles is caused by incursions.

Now see how "random" the distribution is for the first (pocket) and the second (small) example.
And now compare that to the distribution of the third and fourth example, both 2572. Both "min <= 0" and "max <= 0" have the same number of entries, as have "min > 0" and "max > 0". That seems odd, doesn't it?
For the fifth example (changed function min_temperature) the distribution looks much more like for the first and the second.
The reason is, that values between 0 and 1 are possible for divisor, which results in a larger variation.
This looks "right" for me - of course I have no clue if it really is correct.
What do you think?

1. 172, pocket - # embark tiles 73.984
range# ∑ # min/max
min <= 0 27908
min  >  0 48355 76.263
max<= 0 10583
max >  0 64243 74.826

2. 332, small - # embark tiles 278.784
range# ∑ # min/max
min <= 0 97967
min  >  0 188173 286.140
max<= 0 32768
max >  0 248539 281.370

3. 2572, large 1 - # embark tiles 16.908.544
range# ∑ # min/max
min <= 0 2243169
min  >  0 14758891 17.002.060
max<= 0 2243169
max >  0 14758891 17.002.060

4. 2572, large 2 - # embark tiles 16.908.544
range# ∑ # min/max
min <= 0 1980576
min  >  0 15013574 16.994.150
max<= 0 1980576
max >  0 15013574 16.994.150

5. 2572, large 1 - float divisor - # embark tiles 16.908.544
range# ∑ # min/max
min <= 0 7843764
min  >  0 9387251 17.231.015
max<= 0 2243169
max >  0 14758891 17.002.060
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #279 on: December 25, 2020, 05:03:31 pm »

Why embark assistant don't differentiating of lairs? Mound and burrow are different in game code.
Are you talking about on the local map when embarking? What DFHack version are you using? 0.47.04-r4 (released yesterday) adds support for this (PR, changelog)
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

Iä! RIAKTOR!

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #280 on: December 25, 2020, 05:53:11 pm »

Why embark assistant don't differentiating of lairs? Mound and burrow are different in game code.
Are you talking about on the local map when embarking? What DFHack version are you using? 0.47.04-r4 (released yesterday) adds support for this (PR, changelog)
Thanks! I'll update my dfhack soon.
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #281 on: December 25, 2020, 06:16:38 pm »

The reason the lairs weren't differentiated originally was that the DFHack values weren't enumerated and organized as integer values associated with vague and, I think, not entirely certain descriptions, so it wasn't clear how many types of lairs there were or in which way they differed.

On to temperature:
The formulae for determining the temperature variation were matched to measured temperatures over the year at various latitudes in variously sized worlds and eventually managed to correctly predict which day and tick the temperature would change (as reported by DF's data structures). All those temperatures are integer numbers. The presence of a fudge factor in some of the formulae is an indication that those formulae (at least) aren't entirely correct.
However, it may be that the code should reshuffle the factors to ensure the correct result, i.e. "divisor = ((lat * 64) / steps)". In pure math the order of the division and multiplication terms doesn't matter, but it does with the imperfect emulation of math performed by computers.

Max temperature is the "official" temperature of the world tile (i.e. the value in the world tile data), while the min temperature is the max temperature - the maximum variation (which lasts for a single tick in some cases), so the max temperature variation is completely dependent on the official world tile temperature, which, in its turn, is dependent on latitude, elevation, and the temperature parameters for world gen.
Logged

RedDwarfStepper

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #282 on: December 26, 2020, 05:41:14 pm »

Max temperature is the "official" temperature of the world tile (i.e. the value in the world tile data), while the min temperature is the max temperature - the maximum variation (which lasts for a single tick in some cases), so the max temperature variation is completely dependent on the official world tile temperature, which, in its turn, is dependent on latitude, elevation, and the temperature parameters for world gen.
Yes, I saw how min temperature was derived from max temperature and that in turn was taken from region_map_entry and transformed.

Reordering the expression to divisor = ((lat * 64) / steps) as suggested results in the below distribution of min temperatures - which also looks much more random / natural and similar to the results of the fifth example.
I'm currently pushing to get the search criteria done (2 remaining, just finished "freezing"), otherwise I would be happy to do some science to evaluate the fitness of the changed divisor expression. If I can wait a little longer I can take care of it then.

6. 2572, large 1 - divisor = ((lat * 64) / steps) - # embark tiles 16.908.544
range# ∑ # min/max
min <= 0 7506116
min  >  0 9729380 17.235.496
max<= 0 2243169
max >  0 14758891 17.002.060

PS:
Also I have an idea on how to proceed (as we have discussed some time ago) that I would like to run by you but first I want to get the criteria done and fix two more hopefully little issues.
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #283 on: December 27, 2020, 05:19:00 am »

Correcting the order of the terms should give a result very close to that of forcing the calculations to be performed using floating point math and then truncating the result to an integer one, and it may be that the results are identical for this value space, but you can't trust it would be without a careful analysis (where "careful analysis" can be an exhaustive comparison of all possible results). I assume you've seen floating point values of the type 1.99998 when the mathematically correct value was 2, but truncating it to integer would nevertheless result in 1...
Logged

RedDwarfStepper

  • Bay Watcher
    • View Profile
Re: DFHack plugin embark-assistant
« Reply #284 on: January 03, 2021, 04:43:29 pm »

Happy new year everyone!

First things first:
I assume you've seen floating point values of the type 1.99998 when the mathematically correct value was 2, but truncating it to integer would nevertheless result in 1...
Actually I saw a natural value of 0.5 for divisor which was rounded up (ceil) to a 1 after being multiplied with 0.75 here resulting in
Code: [Select]
max_temperatur - 1
And now: Good news everyone!
I finally finished the last query (in the old version) which was reanimation.
While comparing the results of the matcher with the results of the index for the "Reanimation or Thralling" option I found something curious:
At first I implemented this as strict OR/XOR as in "either Reanimation or Thralling" but that seemed to return not enough results, after changing the implementation to the broader AND/OR as in "Reanimation and/or Thralling" (=> ||)  the results matched perfectly.
So my question is: Is the implementation for embark_assist::defs::reanimation_ranges::Any by intention broad and the wording of the option in the UI could be made clearer if changed to "Reanimation and/or Thralling" as it also contains all matches that have both reanimation and thralling or should the implementation be more strict and thus represent an exclusive OR/XOR as in "either Reanimation or Thralling" which would require the logic to change?
The condition here and here and here as well as
Code: [Select]
!tile->reanimating_possible && !tile->thralling_possiblewould need to be changed to
Code: [Select]
!tile->reanimating_possible != !tile->thralling_possibleor easier to read
Code: [Select]
tile->reanimating_possible != tile->thralling_possible
Logged
Pages: 1 ... 17 18 [19] 20 21 ... 24