This is probably only of interest to those wanting to edit/explore the dat files via a hex editor or writing custom programs to edit the files:
Editing the files is going to be a little harder than with EHM. The bytes in the dat files are un-swapped (I think this is called big endian - whereas EHM, like most things, is little endian). So any tools have to byte swap before doing anything with the data. It does however mean that the bytes are easier to read manually via a hex editor. For example, the capacity of the Bell Centre is 21,273. In hex this is 53 19. With the usual binary files (such as EHM's dat files), this would be written as 19 53 because the bytes are swapped. However, in FHM's data files this is written as 53 19. When loading the files using C++ code, the function that loads the data (std::fstream) would expect the bytes to be swapped and so it reads FHM's dat files incorrectly. So you have to manually swap the bytes using your own code (it seems a little odd that you have to swap un-swapped bytes to view them, but there you go!). Here's an example of how to swap an unsigned short, such as the Capacity field, in C++:
Code: Select all
void endian(unsigned short &x)
{
x = ((x << 8) & 0xFF00FF00 ) | ((x >> 8) & 0xFF00FF );
}Code: Select all
endian(arena_name);Additionally, text fields are of variable size. For those who have edited EHM, the text fields are of fixed sizes. In FHM, there is a short field (i.e. 2 bytes long) directly before the Arena Name field which states how long the Arena Name field is. I'm guessing this is going to be the case with other text fields in other dat files, but I haven't looked yet. Also, each character in a text string is stored as 2 bytes. For example, the letter 'A' is 41 in hex - but in FHM it is stored as 00 41.
I'm only a novice at programming, but I'm guessing there's more to this than how I've explained it. For example, the text fields may be 2 bytes because they're wide characters (UNICODE). And the big endianess may also have some logical reason/explanation. But at least this is a start for anybody wanting to write editors for FHM. I know I'd like to eventually try writing an FHM version of my EHM Updater so that we can collaboratively edit FHM.
Writing an updating tool is now a real possibility. Even though I don't know the full structure, I have enough to be able to edit attributes and other bits. Contracts might be a bit more complex, but I think I should at least be able to implement trade/transaction updates.
