A：为什么BORDER_COMPLETE_LFB宏要存在两个BORDER_RESTRICTED_RANDOM_LFB宏？
Q：BORDER_COMPLETE_LFB是内部宏，常见调用它的外部宏是TRANSITION_COMPLETE_LFB。
BORDER_RESTRICTED_RANDOM_LFB宏会增加6条构造规则。而且它只一条过渡边，它相关图像一般都存在；terrain_graphics.cfg存在很多TRANSITION_COMPLETE_LFB宏。实际测下来少这么一个宏总的构造规则就少400来条。总供3000条构造规则。
一、地图编辑器
不论是地形系统还是地图编辑器，都尽量和韦诺保持一致，但由于编辑器更加嵌入主程序，至少像编辑器界面已不可能和韦诺一样了。
1.1 地形组图标
按钮类型全由TYPE_CHECK改成TYPE_PRESS，因而只要一个常态的就够了。存放在“<kingdom-res>/images/buttons”目录。
1.2 画刷图标
按钮类型全由TYPE_CHECK改成TYPE_PRESS，因而只要一个常态的就够了。存放在“<kingdom-res>/images/icons/action”目录。
1.3 只让支持单窗口
只支持单窗口是为简化使用。一旦加载新地图后则一定拆除旧的。为只让支持单窗口，程序做两处修改，1）use_mdi()一定返回false；2）编辑器设置隐藏可设置mdi的控件。
1.4 <kingdom-res>/data/core/editor/_main.cfg
此文件删除“EDITOR”宏开关部分。editor已并入data.bin，不须要单独分开了。
去掉“{multiplayer/}”。
#ifndef MULTIPLAYER
{multiplayer/}
#endifcore、multiplay、editor已被整合到一个data.bin，<kingdom-res>/data/_main.cfg已包含过“{multiplayer/}”，此处再包含会出重复。
新增map.cfg，它定义了编辑各样地图时限制，像城市地图。
1.5 <kingdom-res>/data/core/terrain-graphics/editor.cfg
此文件删除“EDITOR”宏开关部分。editor已并入data.bin，不须要单独分开了。
1.6 <kingdom-res>/data/core/terrain.cfg
此文件注释掉两种地形：^Tshy、^Tbny
这两地形是韦诺后加的，一来我还不清楚这两地地用途，二来为支持这两地形还得加构造规则。为减少工作量先注释掉。
二、何时形成地形动画中的start_tick_？
terrain_builder::load_images，它对每个动画调用“res.start_animation(0, true)”，cycles参数用了“true”，所以地形动画都是周期动画。
start_tick_不是“即时”的
要注意，为提高效率，只有在确时需要加载图像时才会调用terrain_builder::load_images。一旦已经加载过是不会再调用load_images。由于各种地形动画只会被加载一次，后面的加载是不调用load_images，这会导致一种结果，各地形动画的start_tick_是第一次加载时的值，程序运行时间越长，这个start_ticks_距现现在时间就越远。
void animated<T,T_void_value>::update_last_draw_time(double acceleration)中有用当前时间减去start_tick_，即使每个都是100毫秒加，也可以会耗上数十毫秒。一旦地形多了个，这个时间就会到秒级，倒致出严重问题。
系统缓存的start_ticks_是执行load_images时时刻。后面terrain_builder::tile::rebuild_cache拿走的是它的副本，之后在副本上修改不会影响系统缓存中的start_ticks_。
解决办法
terrain_builder::tile::rebuild_cache在生成副本时，立即把start_ticks_改到最新时间。
void terrain_builder::tile::rebuild_cache(const std::string& tod, logs* log)
{
......
img_list.push_back(anim); // 形成副本
img_list.back().reset_start_tick(); // 把start_ticks_改到最新时间
......
}
三、tb.dat
为什么要存在tb.dat？
tb.dat主要作用是减少游戏启动时加载构造规则时间。把[terrain_graphics]解析成程序能直接认识的building_rule，从tb.dat文件读取形成building_rule，这两者比较起来tb.dat的要快。
用tb.dat后编程要注意的，以及它会带来副作用。
3.1 tb.dat不存储那些图像文件不存在的规则
tb.dat不存储是因为一条规则内判断文件是否存在也是要点时间的。而多存在一条无效规则就会使得terrain_builder::build_terrains()花费多余时间。
判断文件是否存在要使用terrain_builder::load_images函数，因而在把规则加入规则集前一定要调用load_images，只有该函数返回true才能加入规则集。当然load_images除了判断文件是否存在，还会把这存在文件形成图面，这个过程对于形成tb.dat是多余的，但考虑形成tb.dat是在作安装包前执行，不影响玩家玩游戏时的启动时间。
3.2 一旦制作本来不存在图像后，需要重新形成tb.dat
没有的图像文件存在后，图像归属规则可能就从无效变成有效，而旧的tb.dat可能就没收录这条规则，要生效则必须重新形成tb.dat。
3.3 全局构造规则和本地构造规则
全局构造规则指的是主config下的[terrain_griphics]块形成的构造规则。（全局构造规则适用于所有战役）
本地构造规则指的是特定场景下的[terrain_griphics]块形成的构造规则，像[scenerio]。（本地构造规则适用于特定战役）
在程序中，building_rule中的local字段指示该规则是全局的还是本地的。
用了tb.dat后只支持全局构造规则。——这并不是说用tb.dat后就不能支持局部构造规则，是要支持的话就必须对本地构造规则也和全局一样形成一个类似tb.dat文件，要形成这个dat有点难，又考虑到至少现阶段是几乎不用写本地构造规则，暂不作支持。
至此tb.dat中存的都是全局构造规则，像terrain_builder::flush_local_rules函数就不会产生什么影响。
3.4 如何形成tb.dat
tb.dat是kingdom.exe形成，editor.exe只能察看tb.dat内容。