sea_grids.esf

[taw]

Here's the output of one-way converter for sea_grids.esf

poi.esf uses very similar technique for encoding data,
so I should be able to convert both.

How data is organized is reasonably certain.
On the other hand labels are pure guesswork, I have only very faint idea of what they mean.

Structure is:

• Count of grids, each being:
  
  • Name (string)
  • min x, min y (v2)
  • max x, max y (v2) - bounding box is a good guess
  • x size (uint32)
  • y size (uint32) - all data following is a X*Y cells
  • x*y bounding boxes, each being (outer iteration by y, inner by x):
    
    • x index from 0 to x-1 (uint32)
    • y index from 0 to y-1 (uint32)
    • min x, min y (v2)
    • max x, max y (v2) - seems like bounding box as well
    
    
  • x*y areas each being:
    
    • consecutive id (uint32)
    • uint32 count of land region names
      
      • that many land region names, each being a string
      
      
    • uint32 count of sea names
      
      • that many sea names, each being a string
      
      
    • uint32 count of port names
      
      • that many port names, each being a string
      
      
    • uint32 count of some numbers
      
      • that many numbers, each uint32 - no idea what they mean
      
      
    
    
  • uint32 number of connections (???), each being:
    
    • id of one of area from current grid (uint32)
    • id of another area from current grid (uint32)
    • float with entirely unknown meaning (probably not distance, these are identically spaced cells)
    
    
  
  

Does anybody has any clue what these things mean?

I want to integrate this (and upcoming poi.esf converter) with esfxml,
but I'd like to avoid a bunch of <unknown> tags.

Also, is this or poi.esf useful to anyone? I mostly did this because I had sea_grids.esf in my
test set, and found blatant undecoded structure too annoying.

[The Hedge Knight]

Possible entries for trade routes to allow ai responses based around those?

[taw]

Here's a better xml.

I'd sort of prefer to move connections together with areas, but
there's no guarantee they're in the same order, and I prefer byte-perfect round trip.
So I probably won't do this.

One-way converter is now included in esfxml sources,
just disabled by default.

If you want to enable it to play with it now, edit esf_semantic_converter.rb
and change (currently line 360):

def disabled_convert_rec_CAI_SEA_GRID_ROOT

to:

def convert_rec_CAI_SEA_GRID_ROOT

[uanime5]

The sea_grids.esf tells ETW which seas are connected to which regions, seas, ports, areas. It's possible that the sea_grids.esf is similar to the pathfinding.esf in that it tells ships where they can sail.

I'm unsure what the purpose of the poi.esf is because in NTW I was able to replace the poi.esf from one campaign with the poi.esf for another campaign with suffering a crash. Though I didn't evaluate how this effected the AI.

[taw]

Fully functional bidirectional converter for sea_grids.esf is now included in esfxml in etwng repository. Enjoy.