Stats data format I wish to have.

[Emdek]

iap, decided when and to which?

[iap]

It seems that things are allready being developed to use ini, if I'm not mistaking...

[vexed]

It seems that things are allready being developed to use ini, if I'm not mistaking...

Your mistaken.

Well, kinda, while some things might be ini now, it is just as easy to revert those changes, and use something else.

I am still waiting to hear of a good library that we could use for whatever format you guys want to use instead of ini (or csv).

[iap]

Well I'm not a c++ programmer, but I can Google.
This looks like a good parser, and it open sourse: http://sourceforge.net/projects/tinyxml/
I've read good stuff about it. In the description it says that it creates an object representation of the xml. Very convenient.

[Emdek]

I am still waiting to hear of a good library that we could use for whatever format you guys want to use instead of ini (or csv).

For both SQLite and XML (one of possibilities - it wouldn't add dependency on additional module) you can use Qt modules...

[Duha]

Well I'm not a c++ programmer, but I can Google.
This looks like a good parser, and it open sourse: http://sourceforge.net/projects/tinyxml/
I've read good stuff about it. In the description it says that it creates an object representation of the xml. Very convenient.

Doe`s it has validation like http://labs.qt.nokia.com/2009/02/03/w3c ... n-with-qt/

[vexed]

I am still waiting to hear of a good library that we could use for whatever format you guys want to use instead of ini (or csv).

For both SQLite and XML (one of possibilities - it wouldn't add dependency on additional module) you can use Qt modules...

Qt isn't very good, as I have pointed out before in this thread.

[vexed]

Since I was pinged about this for clarification, let me rephrase what I meant.

Using a sql database to store all the stats in, would be better than what we have now (or what we are moving to), it would save us lots of time as well.
No need to make any new editors or anything else, sql editors are available for every known platform known to man.
Using SQLite in the codebase wouldn't be that much more work than working with Qsettings.
(Note, there was also an idea to have the savegames using a SQL database as well...)

We just need someone to actually do that, and since nobody has time that wants to do this, then that leaves whomever free to do what they think is better, and that is turning csv into ini.

Hope that clears things up.

[Lord Apocalypse]

Quick question. How far out of date is the original pumpkin access database as far as the data formatting? Don't care about the actual stats, just the various tables, etc. If no new additions have been made to the basic stats format it would not be difficult to use the access db as a template for creating the sql schema for new tools, internals, etc. I know there are free access viewers for windows.. think there might be one for linux but am not sure.

[Duha]

Quick question. How far out of date is the original pumpkin access database as far as the data formatting? Don't care about the actual stats, just the various tables, etc. If no new additions have been made to the basic stats format it would not be difficult to use the access db as a template for creating the sql schema for new tools, internals, etc. I know there are free access viewers for windows.. think there might be one for linux but am not sure.

It is not far away as I see. It still looks like sql base dumped to csv.

access is not good. sqlite is better "file base" (crossplatform, has api for many programming languages, well documented).

[Lord Apocalypse]

It is not far away as I see. It still looks like sql base dumped to csv.

The retail release data format was an sql dump, hence the access db. It was created to make editing all the game stats easier and if the tables (formatting) has not changed much as far as adding new columns/rows whatever then the access database can be used to create the sql file wzdata.sql with out the need to figure out how it should be built as a new db object for postgree, mysql, sqlite, etc.

access is not good. sqlite is better "file base" (crossplatform, has api for many programming languages, well documented).

Don't see how this applies unless I had specifically stated to reuse it as is. The database is only a means to create something better and more compatible with the cross-platform nature of WZ. Even switching it over to OpenOffice.org base would be an improvement provided all the functionality of the original acess db remained intact.

[Per]

I'd be happy with SQL as data format, but I think it is more work, and probably harder to do piecemeal, and I'm not doing that work.

[Duha]

It is not far away as I see. It still looks like sql base dumped to csv.

The retail release data format was an sql dump, hence the access db. It was created to make editing all the game stats easier and if the tables (formatting) has not changed much as far as adding new columns/rows whatever then the access database can be used to create the sql file wzdata.sql with out the need to figure out how it should be built as a new db object for postgree, mysql, sqlite, etc.

access is not good. sqlite is better "file base" (crossplatform, has api for many programming languages, well documented).

Don't see how this applies unless I had specifically stated to reuse it as is. The database is only a means to create something better and more compatible with the cross-platform nature of WZ. Even switching it over to OpenOffice.org base would be an improvement provided all the functionality of the original acess db remained intact.

Many games and progs used sqlite as inner database.

Modding on Civ5 made in that way:
On load game reads xml/sql files and loads its to sqlite table.
After it game works only with sqlite.

Wz design as I see it:
From various formats (csv, ini) data loaded into inner game 'database'.

IMHO csv is easy edited by notepad. But there is many viewers editors for sql databases. (There is firefox plugin for managing sqlite)

I'd be happy with SQL as data format, but I think it is more work, and probably harder to do piecemeal, and I'm not doing that work.

IMHO using sqlite and C++ ORM will be more clear but you right, no one will rewrite it.

[Lord Apocalypse]

I'd be happy with SQL as data format, but I think it is more work, and probably harder to do piecemeal, and I'm not doing that work.

I don't see how you could really do this piecemeal w/o seriously breaking things. If this were to be done first thing that needs to be sorted is what, when, and how everything should be loaded. So what order would you want things loaded. Do you preload all the stats or wait to see what kind of mod is running or load the mod data after loading the normal game data since the mod will overwrite everything. Or do you keep an extra copy of all data loaded (with each copy holding each useable mod). One thing WZ needs is an internal mod selector.

With an internal mod selector it becomes easy to know what to do upon load. As most mods do not replace or change the cam data two stats tables may be needed though unless you want to discard mod data when a player chooses a campaign option. The problem with this though is the extra load time when tossing out the mods data in favor of the cam data. That or adding to the load times for ski and mp games.

If using sqlite as a new internal data format is on the table this should probably be moved to a new thread for a more thorough discussion with all the rest of the devs to gather information on how and where to stick the new code and how best to integrate the data into the game. Would make adding new items to the db much easier as well I think.

[Per]

Just to toss that out there -- another alternative stats format is ... javascript. If all the stats rules are exposed to the javascript API, then instead of loading any predefined format, we run a script to set the rules, possibly holding the majority of the rules in JSON notation (but not necessarily). This could greatly simplify very complex stats data such as upgrades and research, or at least move the complexity out of the C++ code, since the engine would just call javascript functions on upgrades/research and ask what should be done. It would also be just as future proof in regards to engine changes as the INI format (and more so than SQL, I think).