eu2 files are interconnected, but after separating them into more logical (but less space efficient) editor's own file format(s) the editor can be built separately from the compiler
thus the editor doesn't have to know much about eu2 complicated file formats
so all the heavy linking together will happen when compiling simple (possibly large) data into those various tbl files...
the possibilities of modifying only relatively small parts of the map (something like 32x24 blocks of 32x32px at a time for example):
boundbox.tbl can be modified province by province so this is not a problem when modifying only part of the map; id.tbl can be loaded in (separated into scanlines and individual spans) and only the affected scanlines need to be modified; idgrid.tbl can be compiled using lightmap.tbl or id.tbl to get the original data if the modified part doesn't match an region exaclty; adjacent.tbl should not be a problem since there already is a program for modifying it and it isn't linked to other tbl files; incgrid.tbl blocks match lightmap.tbl blocks so the (only?) problem here is that we don't know the exact format of incgrid.tbl?;
and then there's this lightmap.tbl which again doesn't need to be modified all at once - the indexes need to be recalculated (loaded into memory, modified part is compiled into quadtrees and id lists and then saved)
the blocks that are only partially modified in zoomed out lightmaps can be decompiled, modified and compiled
the problem might be that we are using rasterised map image so zoomed out lightmaps might need some special attention (for image quality and determining which pixel belongs to which province, the answer to the latter might be comparing original(paradox) lightmap's ownership data to original id.tbl)
the problems are the things we don't understand (incgrid.tbl and rivers in lightmap.tbl)
those could ruin the plan to unpack, modify and compile only a part of the map at a time
thus the editor doesn't have to know much about eu2 complicated file formats
so all the heavy linking together will happen when compiling simple (possibly large) data into those various tbl files...
the possibilities of modifying only relatively small parts of the map (something like 32x24 blocks of 32x32px at a time for example):
boundbox.tbl can be modified province by province so this is not a problem when modifying only part of the map; id.tbl can be loaded in (separated into scanlines and individual spans) and only the affected scanlines need to be modified; idgrid.tbl can be compiled using lightmap.tbl or id.tbl to get the original data if the modified part doesn't match an region exaclty; adjacent.tbl should not be a problem since there already is a program for modifying it and it isn't linked to other tbl files; incgrid.tbl blocks match lightmap.tbl blocks so the (only?) problem here is that we don't know the exact format of incgrid.tbl?;
and then there's this lightmap.tbl which again doesn't need to be modified all at once - the indexes need to be recalculated (loaded into memory, modified part is compiled into quadtrees and id lists and then saved)
the blocks that are only partially modified in zoomed out lightmaps can be decompiled, modified and compiled
the problem might be that we are using rasterised map image so zoomed out lightmaps might need some special attention (for image quality and determining which pixel belongs to which province, the answer to the latter might be comparing original(paradox) lightmap's ownership data to original id.tbl)
the problems are the things we don't understand (incgrid.tbl and rivers in lightmap.tbl)
those could ruin the plan to unpack, modify and compile only a part of the map at a time
