daniu

The mention of AbcaCodec in the stackdump isn't encouraging; it sounds like they've created another ESF format (since AB CF is the latest we have, and I think AB CA is just the fallback if no suitable one is found). To verify, check the first two bytes in the save file in a hex editor; if it's not AB CA, AB CE or AB CF, we don't have a codec for it. In this case, it might be enough to just copy one of the existing ones (like AbcfCodec), call it after the first bytes in the file (eg AB DA -> AbdaCodec...

You may want to look into https://sourceforge.net/p/packfilemanager/code/HEAD/tree/branches/table-decoder/DbDecoding/ where I started something similar. The issue is that there is no one to one mapping between tables in the official editor files and the ones in the pack files - there are fields that don't go into the corresponding pack db files, and there are columns in the pack db files without corresponding sources in the editor files. I assume those fields are filled from other tables during pack...

Note that I intentionally did not allow RECORD entries to be edited to protect users from themselves. In all instances I can think of, the game expects the RECORD type field to have the exact format it currently has in the file; if you change it (add or remove a field, or change the type of an existing one), the game will crash. In other instances, you can edit the RECORD, but only if you edit other places referencing it (eg add a starting army to a faction, but also need to define the army itself...

Note that this might also affect EditSF, ie the new type might need to be added there as well.

It is possible that they check the Pack file header number (PFH<x>) to be the latest the game is able to digest. PFM does not currently have a way to edit this number directly (I never got around to doing that and it never seemed that necessary). However, if you create a new pack file for a game, it will create it with the highest header number it knows the game can handle IIRC.</x>

FYI, there were two reasons I never upgraded to a newer .NET version. 1. to retain backwards compatability for the users - ie not force them to update to keep PFM running. This might be an issue for Mac users especially, I don't think there are a lot of Linux users out there. 2. to be able to do PFM development at the place I worked at the time I was active. There, we had a Linux environment and I could only get Mono running in an older version, ie up to .NET 4.0. Since that is out of the picture,...

adding tables for schema_102

Warhammer 2 support