Print

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

[feelotraveller]

Hi Patrik,

Perhaps you could take a look at this 43.05 embark?  I think (...) showbiomes is misreporting.

Spoiler (click to show/hide)

[WORLD_GEN]
   [TITLE: DUVET-check]
   [SEED:sWYO8AOAmQOc6YaYy6I8]
   [HISTORY_SEED:YS0C8U0gsE4WaOgMOuIo]
   [NAME_SEED:6SCyqcEWQIQkWCiUWUoA]
   [CREATURE_SEED:YiSqsyyue6YWOWC4qCM2]
   [DIM:65:65]
   [EMBARK_POINTS:1504]
   [END_YEAR:2]
   [BEAST_END_YEAR:1000:-1]
   [REVEAL_ALL_HISTORY:1]
   [CULL_HISTORICAL_FIGURES:0]
   [ELEVATION:75:400:3200:3200]
   [RAINFALL:0:100:3200:3200]
   [TEMPERATURE:20:70:3200:3200]
   [DRAINAGE:0:100:3200:3200]
   [VOLCANISM:0:0:0:0]
   [SAVAGERY:0:100:3200:3200]
   [ELEVATION_FREQUENCY:1:1:1:1:1:1]
   [RAIN_FREQUENCY:4:6:0:0:0:10]
   [DRAINAGE_FREQUENCY:1:1:1:1:1:1]
   [TEMPERATURE_FREQUENCY:1:1:1:1:1:1]
   [SAVAGERY_FREQUENCY:4:0:0:0:0:100]
   [VOLCANISM_FREQUENCY:1:1:1:1:1:1]
   [POLE:NORTH_AND_SOUTH]
   [MINERAL_SCARCITY:100]
   [MEGABEAST_CAP:80]
   [SEMIMEGABEAST_CAP:80]
   [TITAN_NUMBER:80]
   [TITAN_ATTACK_TRIGGER:80:0:0]
   [DEMON_NUMBER:11]
   [NIGHT_TROLL_NUMBER:11]
   [BOGEYMAN_NUMBER:11]
   [VAMPIRE_NUMBER:11]
   [WEREBEAST_NUMBER:11]
   [SECRET_NUMBER:11]
   [REGIONAL_INTERACTION_NUMBER:11]
   [DISTURBANCE_INTERACTION_NUMBER:11]
   [EVIL_CLOUD_NUMBER:11]
   [EVIL_RAIN_NUMBER:11]
   [GENERATE_DIVINE_MATERIALS:1]
   [GOOD_SQ_COUNTS:1023:0:0]
   [EVIL_SQ_COUNTS:255:0:0]
   [PEAK_NUMBER_MIN:0]
   [PARTIAL_OCEAN_EDGE_MIN:0]
   [COMPLETE_OCEAN_EDGE_MIN:0]
   [VOLCANO_MIN:0]
   [REGION_COUNTS:SWAMP:0:0:0]
   [REGION_COUNTS:DESERT:0:0:0]
   [REGION_COUNTS:FOREST:0:0:0]
   [REGION_COUNTS:MOUNTAINS:0:0:0]
   [REGION_COUNTS:OCEAN:0:0:0]
   [REGION_COUNTS:GLACIER:0:0:0]
   [REGION_COUNTS:TUNDRA:0:0:0]
   [REGION_COUNTS:GRASSLAND:0:0:0]
   [REGION_COUNTS:HILLS:0:0:0]
   [EROSION_CYCLE_COUNT:300]
   [RIVER_MINS:0:0]
   [PERIODICALLY_ERODE_EXTREMES:1]
   [OROGRAPHIC_PRECIPITATION:1]
   [SUBREGION_MAX:5000]
   [CAVERN_LAYER_COUNT:3]
   [CAVERN_LAYER_OPENNESS_MIN:0]
   [CAVERN_LAYER_OPENNESS_MAX:100]
   [CAVERN_LAYER_PASSAGE_DENSITY_MIN:0]
   [CAVERN_LAYER_PASSAGE_DENSITY_MAX:100]
   [CAVERN_LAYER_WATER_MIN:0]
   [CAVERN_LAYER_WATER_MAX:100]
   [HAVE_BOTTOM_LAYER_1:1]
   [HAVE_BOTTOM_LAYER_2:1]
   [LEVELS_ABOVE_GROUND:10]
   [LEVELS_ABOVE_LAYER_1:25]
   [LEVELS_ABOVE_LAYER_2:5]
   [LEVELS_ABOVE_LAYER_3:5]
   [LEVELS_ABOVE_LAYER_4:5]
   [LEVELS_ABOVE_LAYER_5:2]
   [LEVELS_AT_BOTTOM:1]
   [CAVE_MIN_SIZE:5]
   [CAVE_MAX_SIZE:25]
   [MOUNTAIN_CAVE_MIN:6]
   [NON_MOUNTAIN_CAVE_MIN:12]
   [ALL_CAVES_VISIBLE:0]
   [SHOW_EMBARK_TUNNEL:2]
   [TOTAL_CIV_NUMBER:10]
   [TOTAL_CIV_POPULATION:15000]
   [SITE_CAP:264]
   [PLAYABLE_CIVILIZATION_REQUIRED:1]
   [ELEVATION_RANGES:0:0:0]
   [RAIN_RANGES:0:0:0]
   [DRAINAGE_RANGES:0:0:0]
   [SAVAGERY_RANGES:0:0:0]
   [VOLCANISM_RANGES:0:0:0]

It is the Temperate Conifer Forest inclusion towards the bottown right that is in question.  In my embarkation it contains both Pineapples and Urad Beans as well as trees that I think are tropical only.  Showbiomes reports it as one of 10 (!) potential/present biomes and all variables graphically accessible with the script return values identical to the Tropical Broadleaf Forest that I believe it should be displayed as.

[PatrikLundell]

I tried, but unfortunately the parameters don't generate the same world for me (0.43.05 Windows 32), so could you please provide a save instead?

[feelotraveller]

Uploaded the region folder here http://dffd.bay12games.com/file.php?id=12717 starting save/play now.

Is that all you need?  (For reference it was created with linux 64bit and uses latest CLA graphics/Myne tileset; showbiomes 2.5(?) and DFHack 43.05beta1.)

p.s. Dropbox have become asshats.  I wave rudely in their general direction. 

[PatrikLundell]

Thanks.
I think I understand what the problem is: You're embarking at the edge of the 16*16 region, and the biome displayed incorrectly refers to the biome in the west-most region tile of the next world map tile, and the code currently truncates over/underflows rather than wrapping them over. It will likely require some thinking to handle that correctly. The current operation handling this adjustment doesn't know about other world tiles, and the code also needs to handle the case where you're right at the edge of the world, to ensure there aren't references out into the void.
I'll be back with an update once I've figured out how to handle it.

Edit:
OK. I think I've solved the problem, but I'm guessing a bit. The region structure used in 17*17 rather than 16*16, so I tried letting it use the 17*th element, which gives the correct result in this case, at least. This is based on the assumption/guess that the extra stuff is there to handle this kind of overflow, but it curiously means it cannot be allowed to underflow.

Another interesting lesson is that you'd end up with temperate coniferous forests rather than broadleaf if the temperature for a temperate forest is less than 65, regardless of if the rainfall falls into the broadleaf range (the biome wiki page doesn't cover that).

Anyway, I've uploaded version 2.6. In addition to addressing this issue, I also added X/Y coordinates for the DF cursor on the help page.

[PatrikLundell]

Double post, as this is a different, somewhat related, issue. I believe I can "cure" shears. I've created two versions of the script. The first one, shearvanilla.lua, replaces all air biome references with 0, which means the biome of the world tile to the NW. This is the way DF does it when no shears are generated, so all the air gets converted.
The second script, shearcenter.lua changes the biome reference to 4, which is what I believe Toady really intended, as this causes the air to take on the biome of the world map tile the embark is in.

The scripts have been tested by building farms on a shear and first changing it around "manually" and then using the scripts. You don't even have to unpause for DF to present a different set of plants for the plot on selection.
I also tried to give different references for different adjacent farm plots within the same tile, but they all got the same one, so I either bungled it or it only works on the tile level.

shearvanilla.lua:

Spoiler (click to show/hide)

function shearvanilla ()
  if not dfhack.isMapLoaded() then
   dfhack.color (COLOR_RED)
    dfhack.print("Error: This script requires a Fortress Mode embark to be loaded.")
   dfhack.color(COLOR_RESET)
   dfhack.println()
   return
  end
 
  local max_x, max_y, max_z = dfhack.maps.getTileSize()
   
  function Is_Air_Tile (x, y, z)
    local tile_type
    local block = dfhack.maps.getBlock (math.floor (x / 16), math.floor (y / 16), z)
   local region_offset = block.region_offset [block.designation

• [0].biome]

   local result = true

   for i = 0, 15 do
     for k = 0, 15 do
        if dfhack.maps.getTileBiomeRgn (x, y, max_z - 1 - z) ~= nil then   
          tile_type = dfhack.maps.getTileType (x + k, y + i, z)
          if tile_type > df.tiletype.Void and
             tile_type ~= df.tiletype.OpenSpace and
             (tile_type < df.tiletype.BurningTreeTrunk or
              tile_type > df.tiletype.BurningTreeCapFloor) and
             (tile_type < df.tiletype.TreeRootSloping or
              tile_type > df.tiletype.TreeDeadTrunkInterior) and
             (tile_type < df.tiletype.ConstructedFloor or
              tile_type > df.tiletype.ConstructedRamp) and
             (tile_type < df.tiletype.ConstructedFloorTrackN or
              tile_type > df.tiletype.ConstructedFloorTrackNSEW) and
             (tile_type < df.tiletype.ConstructedRampTrackN or
              tile_type > df.tiletype.ConstructedRampTrackNSEW) then
           result = false
              break
        end
      end
      
      if region_offset ~= block.region_offset [block.designation [k].biome] then  --  Air tiles have uniform offsets (even when they are shears)
        result = false
        break
      end      
     end
    
     if not result then
       break
     end
   end
   
   if result and region_offset ~= 0 then
     dfhack.println ("Shear at " .. tostring (x) .. ", " .. tostring (y) .. ", " .. tostring (z))
   end
   
   return result
  end
 
  local block
 
  for i = 0, math.floor ((max_y - 1) / 16) do
   for k = 0, math.floor (max_x - 1) / 16 do
      for l = 0, max_z - 1 do
       if i==0 and k==0 then
      end
       if not Is_Air_Tile (k * 16, i * 16, max_z - 1 - l) then      
        break
      end
      
        block = dfhack.maps.getBlock (k, i, max_z - 1 - l)
      
      for m = 0, 15 do
         for n = 0, 15 do
          block.region_offset [block.designation [n][m].biome] = 0
        end
      end
     end
   end
  end
end

shearvanilla ()

shearcenter.lua:

Spoiler (click to show/hide)

function shearcenter ()
  if not dfhack.isMapLoaded() then
   dfhack.color (COLOR_RED)
    dfhack.print("Error: This script requires a Fortress Mode embark to be loaded.")
   dfhack.color(COLOR_RESET)
   dfhack.println()
   return
  end
 
  local max_x, max_y, max_z = dfhack.maps.getTileSize()
   
  function Is_Air_Tile (x, y, z)
    local tile_type
    local block = dfhack.maps.getBlock (math.floor (x / 16), math.floor (y / 16), z)
   local region_offset = block.region_offset [block.designation

• [0].biome]

   local result = true

   for i = 0, 15 do
     for k = 0, 15 do
        if dfhack.maps.getTileBiomeRgn (x, y, max_z - 1 - z) ~= nil then   
          tile_type = dfhack.maps.getTileType (x + k, y + i, z)
          if tile_type > df.tiletype.Void and
             tile_type ~= df.tiletype.OpenSpace and
             (tile_type < df.tiletype.BurningTreeTrunk or
              tile_type > df.tiletype.BurningTreeCapFloor) and
             (tile_type < df.tiletype.TreeRootSloping or
              tile_type > df.tiletype.TreeDeadTrunkInterior) and
             (tile_type < df.tiletype.ConstructedFloor or
              tile_type > df.tiletype.ConstructedRamp) and
             (tile_type < df.tiletype.ConstructedFloorTrackN or
              tile_type > df.tiletype.ConstructedFloorTrackNSEW) and
             (tile_type < df.tiletype.ConstructedRampTrackN or
              tile_type > df.tiletype.ConstructedRampTrackNSEW) then
           result = false
              break
        end
      end
      
      if region_offset ~= block.region_offset [block.designation [k].biome] then  --  Air tiles have uniform offsets (even when they are shears)
        result = false
        break
      end      
     end
    
     if not result then
       break
     end
   end
   
   if result and region_offset ~= 0 then
     dfhack.println ("Shear at " .. tostring (x) .. ", " .. tostring (y) .. ", " .. tostring (z))
   end
   
   return result
  end
 
  local block
 
  for i = 0, math.floor ((max_y - 1) / 16) do
   for k = 0, math.floor (max_x - 1) / 16 do
      for l = 0, max_z - 1 do
       if i==0 and k==0 then
      end
       if not Is_Air_Tile (k * 16, i * 16, max_z - 1 - l) then      
        break
      end
      
        block = dfhack.maps.getBlock (k, i, max_z - 1 - l)
      
      for m = 0, 15 do
         for n = 0, 15 do
          block.region_offset [block.designation [n][m].biome] = 4
        end
      end
     end
   end
  end
end

shearcenter ()

The scripts are identical for the names and a single digit.
It wouldn't be hard to make an air biome editing script that let you select the biome for an air tile from among the up to 9 available ones, but I don't know if there's much demand for one.

[Fleeting Frames]

Not hard, indeed. Mentioned it few days ago in passing, but

Spoiler: setair.lua (click to show/hide)

Code: [Select]

local args = {...}

function setair (values)
  if not dfhack.isMapLoaded() then
dfhack.color (COLOR_RED)
    dfhack.print("Error: This script requires a Fortress Mode embark to be loaded.")
dfhack.color(COLOR_RESET)
dfhack.println()
return
  end
 
  local max_x, max_y, max_z = dfhack.maps.getTileSize()
  local lastvalueindex = 0
  function lenTable (subject)
    local len = 0
    for iter in pairs(subject) do
      len = len + 1
    end
    return len
  end
 
  local lengthofArgs = lenTable(values)
  function getNextValue ()
    lastvalueindex  = lastvalueindex + 1
    return tonumber(values[1+(lastvalueindex % lengthofArgs)])
  end
   
  function Is_Air_Tile (x, y, z)
    local tile_type
    local block = dfhack.maps.getBlock (math.floor (x / 16), math.floor (y / 16), z)
local region_offset = block.region_offset [block.designation [0][0].biome]
local result = true

for i = 0, 15 do
  for k = 0, 15 do
        if dfhack.maps.getTileBiomeRgn (x, y, max_z - 1 - z) ~= nil then
          tile_type = dfhack.maps.getTileType (x + k, y + i, z)
          if tile_type > df.tiletype.Void and
             tile_type ~= df.tiletype.OpenSpace and
             (tile_type < df.tiletype.BurningTreeTrunk or
              tile_type > df.tiletype.BurningTreeCapFloor) and
             (tile_type < df.tiletype.TreeRootSloping or
              tile_type > df.tiletype.TreeDeadTrunkInterior) and
             (tile_type < df.tiletype.ConstructedFloor or
              tile_type > df.tiletype.ConstructedRamp) and
             (tile_type < df.tiletype.ConstructedFloorTrackN or
              tile_type > df.tiletype.ConstructedFloorTrackNSEW) and
             (tile_type < df.tiletype.ConstructedRampTrackN or
              tile_type > df.tiletype.ConstructedRampTrackNSEW) then
  result = false
              break
  end
end

if region_offset ~= block.region_offset [block.designation [k][i].biome] then  --  Air tiles have uniform offsets (even when they are shears)
  result = false
  break
end
  end
 
  if not result then
    break
  end
end

if result and region_offset ~= 0 then
  dfhack.println ("Shear at " .. tostring (x) .. ", " .. tostring (y) .. ", " .. tostring (z))
end

return result
  end
 
  local block
  local offsetbiome = 0
  for l = 0, max_z - 1 do
for k = 0, math.floor (max_x - 1) / 16 do
      for i = 0, math.floor ((max_y - 1) / 16) do
    if i==0 and k==0 then
end
    if not Is_Air_Tile (k * 16, i * 16, max_z - 1 - l) then
  break
end

        block = dfhack.maps.getBlock (k, i, max_z - 1 - l)
    offsetbiome = getNextValue()
--     dfhack.println("offsetbiome is " .. tostring(offsetbiome))
for m = 0, 15 do
      for n = 0, 15 do
    block.region_offset [block.designation [n][m].biome] = offsetbiome
  end
end
  end
end
  end
end

setair (args)


Usage: setair 4 1 3 8 0 8 2 4 1
I.e. setair <any amount of numbers between 0 and 8...I presume an error or loop with higher ones>

I initially thought of making it set it 1 biome for z-level (hence why loop orders were changed), but then changed my mind: it's more interesting this way, with the number constantly changing (and you can't fit 6 air biomes into 5 z-levels anyway).

Mildly curious that using this removes @s in air from showbiomes.

[lethosor]

Code: [Select]

dfhack.color (COLOR_RED)
    dfhack.print("Error: This script requires a Fortress Mode embark to be loaded.")
dfhack.color(COLOR_RESET)
dfhack.println()
Why do I keep seeing this everywhere? Is there some common script I'm not aware of that does this? (Nothing against your code specifically - I've seen it in a lot of places, and I'm not sure why.)
There are two ways to do this that are much simpler:
* qerror(message) for things that are errors (and should stop the script)
* dfhack.printerr(message) for things that aren't strictly errors but should be displayed like errors
These have the advantages of not requiring you to reset the color or call println(), and they won't leave the console in red if the error message breaks somehow. They're also documented in the Lua API docs, even above dfhack.color() in the case of dfhack.printerr().

(Also, PTW - this script looks cool)

[Fleeting Frames]

On the off-chance you're asking me, I wasn't aware of those docs - 99% of my lua knowledge comes from looking at dfhack scripts, and I follow a principle of "if it works for PL why mess with it".

[PatrikLundell]

@lethosor:
"Lots of places" is at least partially me using what I've found works. Copy/paste (not the least by me) then spreads it...
I'm using the Lua documentation (and switched to the version you linked in a github issue comment from the github one I've used previously), but there's a lot of stuff in there, and it's not always I look for things I don't expect to find (I wouldn't have found penarray because the name indicates a palette of "pens", i.e. HOW to write something, not WHAT to write, to me). A better memory would certainly help as well...

Also, my experience is that the built in dfhack error operations are sloppy: I've found they don't reset the color, so everything printed after them is bled over in light red (including the DFHack console prompt for the next entry, and that entry itself). I've started using the stack trace one where appropriate despite this, as the stack trace is useful, but a bleeding error message with the side effect of writing to the error log (which I don't really care about either way, but there's not much reason to write reports of user input/usage errors into an error log) isn't useful to me.
I've meant to examine it in more detail and write an issue for it, but haven't gotten around to it yet.
It's certainly the case that every time I screw up my scripts and get red stack traces the DFHack console prompt gets colored as well (making it harder to see where one failed run is replaced by the next one).

Edit:
To clarify, I appreciate lethosor's efforts to get me (and others) to produce higher quality scripts.

I've now made a quick test of "dfhack.printerr", "error", and the built in stack trace (local x = 3 / <undefined variable>), and neither of them bleed. So why do I get bleeding when my more complex scripts fail? I would guess it has to do with the multiple threads involved when dfhack.gui is used, somehow. It looks like more investigation is needed, which is the next step...

Edit 2:
Hm, it's more complicated. Somehow the DFHack terminal (or DF) "gets tired". I tried to make an MFP (Minimal Faulty Program) with a UI, but it worked correctly regardless of thread. I then created an error in the rendering of biomemanipulator, and I'm fairly sure it looked OK initially. After exiting I modified the code to just fail 5 times, but I still got a red DFHack prompt. I went back to my MFP, and it now produces a red prompt where it didn't before (and the script hasn't been changed in the mean time).
Further experiments where I generated 10 error messages on rendering each time the script was run. I then exited the script and ran it again. In one sequence the prompt turned red after the 7:th run. I then killed DF and started it afresh, ran the test again, and this time the prompt turned red after the 6:th run. Tried it again, and failure on the 7:th. Modified the script to fail 60 times, and it worked fine the first time and bled the second (starting DF from scratch for each run). The variable failure point leads me to think there's a race condition over an unsafe region in DFHack where the script's output is interleaved/replaced with the DFHack prompt causing the output color designation to occasionally write into DFHack's prompt color state.
More experimenting: It seems the DFHack color prompt state gets entangled with the script output color state:
Two scripts:

Code: [Select]

function y ()
  for i = 1, 1000 do
  dfhack.printerr ("Do I bleed?")
  end
  dfhack.println ("What?")
--  error ("Not really...")
--  dfhack.println ("What?")
--  dfhack.println ("What?")
end

y ()and

Code: [Select]

function z ()
  dfhack.color (COLOR_BLUE)
  dfhack.println ("What color is this?")
end

z ()If I run z on a fresh DFHack, it provides a blue output followed by a standard DFHack prompt.
However, if I run y followed by z I get the correct output from y, followed by a red prompt, followed by the correct z output, followed by a blue prompt, with the next DFHack prompt after that being red. Run z (nothing strange happens) followed by y, and I get the standard color output at the end of y in blue followed by a blue prompt!
I've created issue #1123 on github, and will try to use dfhack.printerr where appropriate from now on (there will probably cut&past exceptions, though...).

[lethosor]

That's weird. The prompt isn't supposed to ever be colored, as far as I know (at least that's how it is on Linux/OS X). Thanks for the report, anyway.

[gchristopher]

This still works great with 44.12 to visualize shears! Kind of a naive observation, but using this to look at a 4x4 embark, it seems that the shears occur across an entire 48x48 map tile at the same z-level.

Is there any reason you couldn't fix shears on a map-tile-by-map-tile basis in the embark by finding where the entire tile turns to 0s and setting each individual air tile from the shear z-level up to the biome immediately below the shear z-level for that (x/y) tile? i.e. just take the correct biomes and extend them up to the highest fully-allocated z-level? (Or even partially allocated sky z-levels, but I think that might complicate fixing future air shears once that part of the sky gets allocated.)

I'm assuming what I'm seeing when the biome offset isn't a number is portions of the sky that haven't been allocated yet.

[PatrikLundell]

Shears appear on the 16*16 tile (3 * 3 of those per Mid Level Tile) level if I recall correctly. However, if your embark is of varying elevation, the sky starts at different elevations on a whole Mid Level Tile basis, which is not the shears, but the sky.

I've made a couple of scripts to remove shears, one so all sky tiles adopt the biome of the world tile to the NW (i.e. that of the non shear sky tiles), and another one that "corrects" DF and sets the whole sky to the biome of the own world tile instead.

It shouldn't be too hard for someone to make a script that extended the biomes present on the ground up into the sky. I'd expect "infinite sky" (or whatever the script is called) would not respect this when adding more sky levels, though, so the script would have to be run again.

The no number parts are the shears, where the numbers are out of bounds, and so are bugged. I haven't been able to determine how those bugged numbers translate into biome offsets, but testing them (by muddying floors and building farm plots on those to see what plants you could grow there) shows they are of one of the up to 9 possible biomes, as dictated by the normal biome rules.

[gchristopher]

Sorry if I'm missing something everybody already knows; typing while traveling and short on sleep. I don't think the all zeros air is intentional at all. I think it's one of a few bugs with the generation of air tiles.

I see how you're getting the biome offsets from block.designation.x.y (from the tile block for that 16x16xz location), but I think that the region_offset is also broken, which is why you get confusing results even when fixing the designation.x.y to be the same as the tiles below. (Assuming you want surface biomes to continue to sky height, which I think is the correct behavior.)

Here's looking at the region_offset immediately below one of the "turns into an evil biome" z-level transitions. (Not a "shear" by your definition, but definitely a place where the biome unexpectedly changes)

Code: [Select]

[lua]# tileblock = dfhack.maps.getTileBlock(cursor.x, cursor.y, cursor.z)
[lua]# printall(tileblock.region_offset)
0                        = 1
1                        = 1
2                        = 1
3                        = 1
4                        = 4
5                        = 4
6                        = 1
7                        = 4
8                        = 4
[lua]# tileblock = dfhack.maps.getTileBlock(cursor.x, cursor.y, cursor.z+1)
[lua]# printall(tileblock.region_offset)
0                        = 0
1                        = 0
2                        = 0
3                        = 0
4                        = 0
5                        = 0
6                        = 0
7                        = 0
8                        = 0
I think (from your code), this is how the fine-grained noise pattern in block.designation turns into the top-level map biome associations? (with 0 representing the NW one?)

With all of the region_offsets set to 0, it won't matter what's in the block designations array, because they all map to 0.  I will experiment, but I think you might be able to fix the evil biome air transitions by both copying the region_offsets from the z-level below, and also copy up the block.designation 2d array.

[PatrikLundell]

It's reasonably clear it's a bug to have the air biome refer to the world tile to the NW rather than the own world tile, thus, the zeroes most likely should have been fours (i.e. "this world tile").

I have no idea why Toady decided to have an air biome at all, rather than just extend the biome references upwards as well as downwards (the cavern biomes are different from the surface ones, but the boundaries are the same).

Extending the surface (and below) references upwards should be reasonably easy to do. Note, though, that I don't know how DF handles that when it comes to flying critters entering the map. Also, it's possible it may cause evil weather to move upwards (it currently seems that blood rain happens at the top level of the "real" biome, and building a floor on air levels above it blocks the rain from happening, rather than ending up on top of it, as I had intended).
Blood rain in an evil air biome does not reach the ground, but may end up on top of built structures.

[gchristopher]

Sorry, what I meant was, I was asking for code advice. Do you think those two fields are likely to be enough, or is there somewhere else you know offhand that there's relevant data to change?