I am trying to add a custom block in an AWD file without losing its compatibility.

So, following the 2.1 format documentation (pdf), I have defined my namespace id using a “blocktype=254”, and then defined the same namespace id to my custom block headers.

I understood from the doc that its allowed to reuse any typeid for a custom blocks have it defined a namespace id !=0. So it would be beautifully ignored by the parser.

Well, not exactly true. I still have to use an “unused” blocktype, or I get an error.

Looks like the current AWD2Parser (4.1.5 master) completely ignores any block namespace definition and throws an exception if I try to use a typeid reserved to the internal types.

Could someone confirm if this is a bug or maybe a faulty documentation?

I just looked quickly into the parser and saw(comfirm) the problem. Some changes were made for 2.1 features but there is no default into the switch statement for custom 2.1 blocks and the v1 part skips it by the block bytes length.
In short: no way to parse a valid awd file with custom block ids without altering the parser. I’m gonna pass the info to Robin who is I beleive the one behind the last updates…

Well, once spotted its not a big deal, it is possible to embed a custom block in a awd file as long as I define it with a blocktype other than those predefined.

I confirmed it opens fine in AB and from Away.

Thanks for your support, Fabrice.

Yes, tho if you have lots of blocks, instead of altering the parser too much or you awd generator, I would add a simple block like “AWD_CUSTOM_BINARY”=someid. you would then store inside a custom binary info, that you could parse outside the parser with no need to bloat it with many custom methods. same for your exporter, it would simply inject the custom stream into the custom awd block.