Nice idea, better than using binaries, ini is easy to modify.
How you will manage the case of SkillJpResource in database ? sql generated files will be compatible with rappelz database out of the box ?
There is also the case of SkillTree rdb which has not the same layout as others (don't remember if it's this file, but there is at least a file with it's line count equal to group of line instead of just one line), how it's case will be managed ?
The way I managed these case is to add a special field indicating how this file should be converted. Using a better solution was too much coding for just 2 files for me, but it's a bit ugly.
I see the init will have:
Code:
[1LOOP]
ID=INT64
TEXT=STR[258]
The way the data will be proceed will be like that ? :
for each field in 1LOOP which is a structure do
for each field in 2LOOP which is a structure do
for each field in 3LOOP which is a structure do
....
?
I would have managed this way the special case:
Code:
[root]
sbustruct=STRUCT(aname)
[aname]
field1=INT64
field2=...
...
having root as a STRUCT and each structure containing these fields:
Code:
elements_count_in_struct=INT32
contents as described in [aname]
and the full rdb file would be:
Code:
timestamp=CHAR[128]
content=STRUCTURE(root)
A good idea would be the possibility to add modifiers, for example to indicate that a field should not be in the database, or is a bit that is concatened in a group of 8 bits.
The advantage of doing this (the use of a text file as a rdb describer file and not using hard coded things) is the fact that you don't have to recompile the binary after each change in rdb structures, and you don't need to add a bunch of code when gala create a new rdb file. just enough to describe the new file.
Also Gr4ph0s, i saw that you separated the version string with 0s after this string, but I think it's not needed, it can be seen as a whole string of 128 bytes which is zero-terminated (many zeroes, but it does not matter

)