Print

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

[PatrikLundell]

Hi ragundo:

I don't really think the problem I'm having is caused by the original code, but my failure to translate the disassembly converted back to high level assembly (a.k.a. C(++)) into LUA.
I want the code to match what you get on an embark. My current working assumption is that the world level code is used there as well, so currently I don't think there's a need to increase the resolution (which shouldn't be too hard, technically, if needed).

I've used your code to do the calculations, but the data I plug in is the set of parameters (salinity, etc) read for each tile on the embark, plus the coordinates of the embark (in world coordinates). The set of parameters is the same for all points of an embark level biome I've looked at, so recalculation is redundant, but not doing so would require caching the calculations and looking them up to see if a biome has already been calculated (would fall under future enhancements). However, there's little point in optimizing something that doesn't work.

I'll replace the convoluted non working translated code  with the simple calculation of
"is_tropical_area_by_latitude = v6 > 200"
on the grounds that a single North pole 259 height embark should have the tropics line at about 191, so the "maybe" zone would be 170-200, and the "definitely" zone would be 200 - 257, and that that might be what the code actually does (in its working form) and see what happens.

Edit: OK, I just found an embark that shows some basic assumptions do not hold:
The embark is divided into a temperate and a tropical grassland biome, but both of them are way below any conversion temperatures, and, in addition to this, the tropical one has a LOWER temperature than the temperate one,
38 vs 55 according to the parameters, and 10017 vs 10022 according to probe. The two biomes belong to the same region (20), which makes logical sense since they're of the same type, but have different biome numbers (7 vs 3).
Looking at the coordinates given for the two biomes within the region provides the coordinates (3, 44) for the temperate one and (5, 46) for the tropical one, while the embark itself is at (9, 45). Thus, it might be that the coordinates used for tropicality checks should be based on the biome origin, rather than the embark. That still wouldn't make the tropical biome tropical according to my simplified latitude check, though, and both are in the "maybe" range where they're rejected due to their low temperatures (and neither reaches the "real" tropical boundary).

[ragundo]

Hi
You get the biome type from a world coordinate, but at "embark" resolution, that is what you want, you would need to add some offset to the embark coordinate in order to match the world coordinate "up", "down", "left" or "right"  where your embark coordinate points to in order to get the correct biome data, because a biome can span over multiple world coordinates.
I think that's why you get incorrect data to feed to your script.

I'm usually in #DFHack channel in freenode. We can chat there more in detail if you want.

Greetings

[Fleeting Frames]

Just checking, when you're looking at the tropical grassland with temp lower than temp grassland, does the world have poles?

Because poles override tropical up till that's grassland is tundra or glacier. (Maybe it's a bug, but freezing tropicals do happen.)

with all of its weird things (using the longitude in the tropical/temperate determination logic, for instance).

Couldn't find any longitude with Ctrl+F, do you mean it using x and y? It seems to only compare y_pos, though. (though curiously seems to treat rainfall differently depending on latitude on line 422.

Hm, I've anecdotally noticed sometimes higher rainfall forests having higher temp in poles and lower in tropical. Could be worth investigating someday whether that was just random noise, though don't see the use now.

[PatrikLundell]

Yes, the world has both poles (it's your world, but generated on my machine, and thus it looks a bit different).

Actually, the longitude is me screwing up badly, as I've detected just now. It SHOULD actually be rainfall (Mea culpa, mea maxima culpa). And that also indicates that a shift of the calculation position from the embark to the biome "home" coordinates looks like it should make it tropical. There's a check of latitude vs rainfall and higher latitudes (in a North only pole world: everything is adjusted for a North only 259 size world, except the no pole case) compensates for more rainfall, and a sufficiently low end result pushes a "maybe" latitude biome into tropical. This check varies a bit between biomes, but, interestingly, grassland and savanna use the same check, and your investigations indicate the inherently lower rainfall grassland biome has a larger range than savanna.
Thus, it looks like my next move should be to re-engineer the code to make use of the "home" biome coordinates rather than the embark ones and see what happens.

[ragundo]

Hi again
Check this subroutine


std::pair<int,int> adjust_coordinates_to_region
(
   int x, // 0..15 in x direction ( a world coordinate has 16x16 embarks coordinates)
   int y, // 0..15 in y direction ( a world coordinate has 16x16 embarks coordinates)
   int delta,    // That's the trick.
                 // This is a value that you get from world_region_details().biome(x)(y) 2D array
                 // that tells you what WORLD coordinate you need to look for the correct data for the biome
                 // There are 9 possible combinations, N,W,NE,W, Center, E,SW,S or SW
   int pos_x, // in world coordinates
   int pos_y, // in world coordinates
   int world_width, // in world coordinates
   int world_height // in world coordinates
)
{
  if ((x < 0) || (y < 0) || (x > 16) || (y > 16))
    return std::pair<int,int>(-1,-1); // invalid coordinates

  int adjusted_x = pos_x;
  int adjusted_y = pos_y;

  switch (delta) // value of world_region_details.biome two dimmensional array
  {
      case 1: // SW
              --adjusted_x; ++adjusted_y; break;
      case 2: // S
                            ++adjusted_y; break;
      case 3: // SE
              ++adjusted_x; ++adjusted_y; break;
      case 4: // W
              --adjusted_x;               break;
      case 5: // Center
                                          break;
      case 6: // E
              ++adjusted_x;               break;
      case 7: // NW
              --adjusted_x; --adjusted_y; break;
      case 8: // N
                            --adjusted_y; break;
      case 9: // NE
              ++adjusted_x; --adjusted_y; break;
  }

  // Check if it's out ot bounds
  if (adjusted_x < 0)
    adjusted_x = 0;

  if (adjusted_x >= world_width)
    adjusted_x = world_width - 1;

  if (adjusted_y < 0)
    adjusted_y = 0;

  if (adjusted_y >= world_height)
    adjusted_y = world_height - 1;

  return std::pair<int,int>(adjusted_x,adjusted_y);
}


For a given world coordinate, where your embark screen cursor is, you need to
Locate the appropiate region_map_entry in world.world_data.world region details that thas pos.x and pos. y equal to the embark cursor
iterate 0..15 in the x direction
        iterate 0..15 in the y direction
             call that subroutine, using as delta the value of region_map_entry.biome(x)(y)
             You get a corrected WORLD coordinate as result. That's the world coordinate that has the data for the biome
             Call the sub that calculates the biome type using a world coordinate, but you feed the corrected world coordinate, not the one from the embark cursor


For a world position, you will get a 16x16 array of  biome types, that's the same data that you get when exporting the biome map in Legends mode
Greetings

[Fleeting Frames]

Probably.

And yeah, all 3 gen with 1 rejection (with dfhack, if that matters) :/ It still doesn't want to always place the dwarven civ, as you know, and those "lucky 3" that I got were all unlucky in that regard.

I think I need a crash course in how to identify biomes using farm plot growable plants.

Mountain, Glacier, Ocean: Nothing, glacier typically has snow on trees in area.
Tundra or Taiga: Blue/Bil/Cranberry, doesn't have Blackberry. Both can have snow.
Grassland (temperate): Artichokes.
Grassland (tropical): Teff and Cowpea (2nd not brewable)
Savanna (tropical): Fonio
Dry Broadleaf Forest: Buckwheat
Shrubland (tropical): Doesn't have the three above but has Bambara groundnut
Wetland (tropical): Papyrus sedge.
Wetland (temperate): Muck root, no Papyrus.
Desert: Caper, doesn't have either Artichokes or Cowpea/Teff


Generic Temperate: Bitter vetch (not brewable)
Generic Tropical: Blood amaranth

You'll note that you can't tell the difference between tundra and taiga or temperate savanna and shrubland, as well as between between moist broadleaf and conifer forest.

[feelotraveller]

On the farm plot test-

There are a bunch of seeds on the crops page of the wiki which ought to be able to distinguish tropical from temperate; I take it that's all that is needed?

I would suggest Rice.  It's tropical but has the advantage growing in both Wet and Dry tiles, so it avoids an additional test for being close to a water source.  Really only need the one since the test would be boolean - can plant/can't plant.  If it becomes an eventuality worth testing to make sure that there are no biome oddities associated with rice planting.

Quick [edited] thoughts on how it might work:
- save tile data (copy original)
- call tiletypes and change tile to soil type  (better for robustness/difficulties in finding a farmable tile)
- spawn farm plot
- set rice to grow [yes=tropical, no=temperate log outcome/job done!]
- remove plot
- restore original tile data

Not sure if/how it is possible to spawn building (=plot here).  But the modding community will know.

But worth making sure that current latitude (+temperature and whatever) based approach is not viable first.  Sorry my poor grasp of data/coding precludes from contributing to that effort. 

Best wishes for the project/your efforts.   

[PatrikLundell]

Thanks for the info, Fleeting Frames. That will be useful.

@feelotraveler: I've looked at assigning a plant to a farm plot (and yes, they should be possible to spawn), but that only sets it, without activating any tests for whether it's actually legal, and it's really the tests we'd want to find/use. I'm putting that approach on hold for the time being.

Thanks ragundo.
It's not quite what we want to achieve, since your code act on the region level, while we're working on the embark one (i.e. one step further down). However, what you say matches my current belief that the biome source world coordinate is the coordinate to feed into the biome calculation code.

[Fleeting Frames]

@feelotraveller: Dry and Wet doesn't matter for farm plot, only if you'll find the plants near bodies of water or away from them. You can grow Muck Roots and Bloated Tubers on same plot.

[feelotraveller]

@feelotraveller: Dry and Wet doesn't matter for farm plot, only if you'll find the plants near bodies of water or away from them. You can grow Muck Roots and Bloated Tubers on same plot.

Ah, okay, that makes sense.  Lots of options for distinguishing (some) biomes then. 

(@Patrik sorry I misunderstood what you were asking.  At the risk of misunderstanding again - it is easy enough to spawn a seed; and presumably calling the 'plant seed action' (whatever the technical term is) will show if the planting is legal?  By the by if the approach is not pursued. )

[PatrikLundell]

@feelotraveler: I tried bulding a plot (the conventional way, using dorfs) and then went into the farm plot building and set the plot to grow 53 (or whatever the number was), and nothing happened, which I think is due to the order bypassing the checks. If I would do this manually, I'd do what Fleeting Frames does, i.e. bring up the farm plot and look at what plants are available, but the data structure contains what's ordered, so it comes after the check (and crops that are inserted that way aren't show in the list and won't be planted since they're not legal). Note that you don't order seeds to be planted: that order is generated internally by DF as a result of the farm plot being ordered to grow a plant and the plot not being fully populated by growing crops yet.

Anyway, I've changed the code to use biomes (and fixed some bugs), and the result is a mess. For the embark I'm currently using, having tropical and temperate grassland only, I get a patchwork of different biome numbers within the same region, and the patchwork is cut off at embark tile boundaries, and those biomes have sets of parameters that are identical within either the temperate or tropical grassland group, so there are no seams visible in the parameter views. However, further examination shows there's actually some kind of method to the madness somewhere, as these subgroups line up with groups with different biome numbers on neighboring tiles. However, the biome numbers do not seem to really match entries in the regions' biome list. They may, however, have some relation to the delta numbers in ragundo's code. I guess that's the next thing to explore.

Edit: OK, it looks like we're at least approaching coming back on track. I've updated to 1.5, but there are oddities left.

I would have gotten nowhere without ragundo's input. Many thanks!

My current understanding, reflected by the code, regarding the biome is:
- The biome info shown by Probe on a tile isn't actually a biome index at all, but a delta as per ragundo's code, that shows which embark tile that has the biome data is its "main" data.
- The embark tile has a delta which shows which world tile its biome info has as its home. This is what ragundo's code handles.
- Thus, there seems to be a two step indirection to get to the world tile where the biome "belongs"

My guess why this is made that way is:
- On world generation, all there is is world tile data. This data then "bleeds" into surrounding tiles, which now is represented by embark tiles, resulting in areas of connected biomes on embark level, centered on world level tiles, so they should never spread beyond their neighbors.
- The process is then repeated where the embark tiles bleed into each other.
- Regions are then created by collecting all world tiles that have a biome type of one of the 10 high level ones. This would also mean the indices in the region structure do not mean anything; it's just an array listing all world map tiles that have been rounded up into that region.

Anyway, one thing I've seen in the latest version is a straight line (actually two, since it's broken) that cuts a biome along an embark tile boundary with different tropicality for the two of them. Somehow being on the wrong upper side has turned the northern parts into temperate, which they probably belong to the southern region tile, and thus their tropicality should be calculated from that.

Edit2: I forgot I've turned the vegetation view back on, but presents the biome delta number there.

Edit3: OK, it looks like ragundo wrote the code out of memory (thanks for the effort), since reversing all the signs (as well as reducing the numbers by one to account for C's starting at 0, not 1) provides a nice output and fits with the logic scheme when looking at the numbers and trying to fit their movement direction matches that.

Edit4: Well, this is weird. Trying another embark cause the script to spew out debug trace about deltas being out of range. Using ragundo's original code on the region level and my "corrected" one at embark level at least caused the errors to go away (using the same code in both places resulted in errors about 9 or 0, depending on which version was used. We'll see if the results make sense, though.

[feelotraveller]

Looks like I might be reporting back on an old version - 1.5 as shown in top post downloaded maybe 2 hours ago.  (But so as my bearded ones don't complain too much of the days delay....)

This is the drainage map posted to show what I expect to be the 4 biomes of my embark.  Other than the biomes view all variations mirror this (except for the water features on surface, of course).



The biome shot looks like this.  That's the above 4 biomes split into pairs with a tropical and temperate version of each, although sometimes a bit scattered.  Just to confirm that this was incorrect I tested (randomly) a farm plot from each of the pairs of biomes which add up to the four biomes above.  In all cases the plots confirm that there is no difference in growable crops and inferred from that no difference in biome (certainly at least not a temperate/tropical difference.



And the biome numbers map makes for some weird duck-rabbit visual distortion effects.  Was going to suggest the offsets might be off but looks like that has already been worked over.



The farm plots aren't as easy as I thought they might be when I first suggested it, had no idea that the check might be bypassed.  So I dunno about that.  Wild tangential idea; is it possible to spawn shrubs, and would they respect biome restrictions?  Just a thought in case current method runs into brick wall mind you.

[PatrikLundell]

Thanks feelotraveller.
This is actually the issue I'm grappling with at the moment, so I'm onto it.

When it comes to the biome numbers, they do make some twisted sense if you reverse ragundo's logic (and deduce 1), or possibly without reversing the logic... My current hypothesis is that his code is correct on the NEXT level, which is the one it actually describes, however, as investigations show this lower level to ranges from 0 - 8, while the higher one ranges from 1 - 9.
Take e.g. the region in the middle bottom of the top left embark tile. It matches up with the top middle region of the tile beneath. They use different numbers, but they match up visually, and that goes for the rest of them as well. There is a method to the madness, and the top region part's number should somehow refer to the same location as the lower half does, but presumably relative to their respective tiles.
On top of the logic issues, it's not exactly impossible that I've made mistakes as well, and the script language is good at hiding those by silently introducing new variables when you misspelled on, and I'm good at misspelling...

[feelotraveller]

Yes there is a definite pattern - the biome number decrements 1 as you go an embark tile to the right and 3 if you go an embark tile down. 

I presume the other variations (within a given biome and embark tile) match/mirror the various biome numbers (or is that region numbers?) that probe reports.  So one approach is to ask what (codewise) would be needed, or is lacking, to group them properly together.

Just rambling again.  Anyway, thought a 3x3 might help you unravel the logic.

[PatrikLundell]

The numbers are "biome" numbers, and they've matched every time I've compared them with Probe, so I'm fairly confident they're "real".
I'm trying various variations to get things to work out, but as soon as I get one of my 4 randomly selected embarks to line up another one ceases to do so (actually there are only two that are fighting).
Come to think of it, my latest variation shouldn't have screwed up the last one, because the thing I changed (handling of overflow) doesn't happen on that one, so I must have screwed up in some other way.

Edit: Looking at the number pattern, I get the following matrix:
0: NW 1:  N   2:  NE
3:  W  4:  C   5:   E
6: SW 7:  S:  8:  SE
which looks like ragundo's higher level matrix with N/S inverted and 1 subtracted.
Applying that for the lower level and ragundo's for the higher one ALMOST works. There's an error in one of the embarks, but at least that error has the shape of an underlying number.