Yes, purely technically it is fine. But I was wondering if it was fine by design. I think we can leave it like this though. If somebody uses one method, they don't have to necessarily use the other as well.
EDIT: Shit, I broke it all. :/ I'll have to go fix all of this stuff. Writing never really worked in C++ actually (I never tested it) and the redesign leaves me with weird data. Now I'm not sure whether the data has been corrupted during conversion from RMXP to ARC or whether it is not being loaded properly in C++. :/ I'll take a look at this tomorrow, it's late.
EDIT: Lol, I didn't break it after all. The problem was in April, not in our libs. But the C++ version of dumping doesn't work after all.
Ryex, I have updated the Ruby code as well as the Python code for ARC Data. I have also changed the usage of the "is" operator in Python as it compares identity, not equality. This could have caused many unforeseen problems. I will commit everything soon. If can fix the broken C++ dump code, then I will commit it as well.
EDIT: Alright, I got the dumper to work, but for some reason it's not creating files that are like the original. I have to investigate this further. It's probably just some additional junk data that's being stored that has been rendered obsolete with the final definition of ARC Data v1.0.
EDIT: I will add sorting of instance variables names. This will make files more consistent and changes won't be caused just by two variables switching places.
EDIT: I found something in RMXP that is pretty fucked up. In Animations.rxdata there are Tables that have one of the sizes set to 0 (xsize in the particular example I found). :/ I have implemented in ARC that xsize, ysize and zsize are always at least 1. When we convert data from RMXP, we're not handling that case so the converted files can have xsize, ysize and/or zsize set to 0 without us noticing. Obviously this means no data will be saved at all. If the file is loaded in the engine, the sizes are corrected to at least 1 and when they are saved again, these changes are reflected in the new file.
You can look it up easily. This hex code basically designates the Table entry in Animations.rxdata: "75 3b 0c 19". The easiest way to find it is to search for "02 00 00 00 00 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00" which basically means 2 dimensions, 0 xsize, 8 ysize, 1 zsize, 0 elements.
I will implement an identical behavior in ARC. If one of the sizes is specified as 0 or less than 0, it will be clamped to 0. Obviously all data access will return nil and technically the Table is useless. But if Enterbrain implemented it that way, so will we.