Print

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

[PatrikLundell]

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).

[RedDwarfStepper]

Ups I think I did it again - 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...

[PatrikLundell]

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

[RedDwarfStepper]

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...

[PatrikLundell]

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

[RedDwarfStepper]

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 257² 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 (129²  + 257²) worlds if they have only one pole?

[PatrikLundell]

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.

[Iä! RIAKTOR!]

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

[RedDwarfStepper]

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 257². 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. 17², 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. 33², 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. 257², 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. 257², 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. 257², 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

[lethosor]

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)

[Iä! RIAKTOR!]

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.

[PatrikLundell]

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.

[RedDwarfStepper]

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. 257², 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.

[PatrikLundell]

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...

[RedDwarfStepper]

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