I think with all of the tools that are coming out, we as the developers of the addons, should decide on a format that can be used by all of the stats tools. LFS Stats right now uses CSV files, luaLFS has no stats program (as far as I know) so it would need one at some point, and lurLFSd uses a sterilized array (Via a plugin I've made). I think it would be better if we setup our own format that could be used across all of the addons. It should only be ONE file per session (Race.lsf, Qual.lsf) and that file should have all of the information needed to make graphs and the like. I would hope that this format would be sanctioned by the Live For Speed devs.

So, what can you come up with? I've make my proposal very soon.

First question would be, what exactly do you want the stats to contain. Personally I could reel off a lot of things I'd like to see, at which point I might as well just parse the mpr/spr files

I also fear, from experience, that design by commity never works unless you already have a semi-clear idea of what you want

How much of a need is there for a common file format? Is movement between various race management applications that common?

Race.lsf

That should turn out something that looks like this :

You could also use the same setup for the Qual.lsf.

There are so many racing leagues out there that are using their own format (I put my hand up as the founder of SimFIA.) It think it would be bennifial in the long run to have a format that could be used by all of the users and admins of LFS.

I though of a common stats format myself some time ago, because I have written my own stats tool to manage the austrian championship.
So I think it is a good idea to have a common format.

The format of my tool is similar to CVS and here is an example:
http://dev.guglhupf.net/gstats ... O5_race_0608271626.gstats

I have also already implemented the new InSim features since patch 0.5V3 that pitstop, flag and takeover are stored in the gstats file, but I have no example at hand.

Compared to your Race.lsf proposal my stats file contains much more informations, and I need all these infos for my league tool. I also to not like abbreviations like UName1, because UserName1 reads much better.

XML would also be a good choice, because with a proper XSLT file, the stats could be rendered in the browser without any additional tools involved.

Every stats tool uses or calculates other values and was developed for various reasons so:

1. you couldn´t really do a common format
2. if you have a common format why should there exists more then one program?

Quote from CLRS530 :

Every stats tool uses or calculates other values and was developed for various reasons so:

1. you couldn´t really do a common format

I don't think so, because stats tool does only collect the data from insim and stores it in a csv like text file.
So nothing is calculated, except unfinished racers, that do not cross the start finish line.

Quote from CLRS530 :

2. if you have a common format why should there exists more then one program?

Good point. I already thought of using your liveforstats tool , but I run my lfs-server with linux/wine and I have no GUI, and afaik your tool runs only under windows and needs a GUI.
My tool is written in java and runs on every OS that has a java runtime.

Thanks, I´m a bit dissapointed that it seems no one uses it
I know your point and in the future there will be a console version maybe also for linux.

But my first point was in fact not written without thinking I can only write for me here, but I "calculate" the speed on lap or split lines and also the positions are not sooo easy but surely implemeted from everyone.
For the new pit, penalty... I also ever use the position.

I don´t want to say with this my tool is the best. I only want to say that not every tool uses the same values.

CLRS530:
If you have a common format why should there exists more then one program?

Some programs are targeted at some people. It might be that one program is to much of a hog for one system, but allows for much more. While there is a lighter version that some one else made. In programming, there is no end all be all solution to everyones problem. It could be the case of lua programmers want to programm in lua. It could be that C programmers what to use your tool. It could be that PHP programmers what to use lurLFSd. To each his own.

Brilwing:
That you, I will look into your format, and see what I like and don't.
(There is one thing, I would like to say about yours, and that's that fact that it's kinda offensive to the eye in flat file format. Not a big deal with the amout of information that it gives out, but still ...)

You can open the file in a spreedsheet application (Excel, OpenOffice), than it should be easier too read.
I wanted to keep the file format simple, because my league tool is written in PHP and I upload the file with a webform. The file is than parsed with php, and the data are stored in a mysql database. Stats, standings etc. are than calulated dynamically using the data from the database.

It is not difficult to change my stats tool to store the data in a different format. So if anything comes out of this discussion, it is very likly that I will support the new file format.

If indeed, any one cares besides you and me.

Namespaced XML, extensible.

I think we've just had all of the major mod writers chime in, that's good.

XML, vs My Implementation, vs Brilwing's, vs CLRS530 CSV files.

I would have to say for a stats format, all of the information should be placed in ONE file. XML would allow for this, as would my file and Brilwing's. I would like it to be light weight on the file size, but that's really not a MUST, seeing as it could stifle innervation at a later point.

My format could be extended if need be, one of the reasons why I added version numbers to it. Also, I never said it had to follow that form. If people wanted to add proprietary information into the format, I don't have issues with that, in fact that file layout allows for, and encourages it to a certain extent.

Overall, I would have to say the XML implementation would be best all around, minus the file size. But as PHP, and many other language's already have a built in XML parser, it would be easier over all to maintain.

I also, like Brilwing's format, as it allows for so much information, but it's down fall it that's it quite bad looking in the flat file point of view.

While CSV files are simple, CLRS530's only puts certain information in certain files. That at the end of the day, litters the file system.

Any more ideas on the subject?

XML is fine.

I think we should start with a xml-schema file that discribes the format.

We should also find a good compromise between using tag elements and attributes, because attributes makes the XML easier to read (by humans).

I also want that the times in the XML are not formated, because the main goal for the stats file format should be that it is processed by programs.

I hope I have some time in the next view days for a small proposal.

Alright. CLRS530, Filur, and the_angry_angel do you plan on supporting this?

Sure.

One more vote for XML too.

Don´t know yet, it depends on how the format looks like. If I can use it. I´m ever for a standart

I'll give it a go Other than the fact that xml is a bitch under C, and the luaXML package is a little iffy, I can't see why I shouldn't beable to support it.

Cool . Alright. What do we want to see in it? What name space should it take?

Hi, as you know I made such a format so the best for me would be to use that. I´m sure everybody wants something else, but you could use it as a base for your own ideas.
Many things like the lap and split structure you cannot do better (in my mind) in a xml file. Because you ever have to think how you can process it the best way and can get specific information you want on the fastes way

Here is the link to the documentation of my format
http://liveforstats.sourceforg ... cumentation.htm#xmlformat

Quote from Dygear :

Alright. What do we want to see in it? What name space should it take?

I'd like to see a format with profiles, a "light" profile could be the equivalent of the CSV output from LFS Stats!, and a "full" profile could contain more details such as lap by lap data. I'd want everything to be namespaced and i'd like parsers to properly discard unknown namespaces, expecting unknown data to be present. I'd also like the format to be fairly suitable for rendering live race progress.

Quote from Brilwing :

I think we should start with a xml-schema file that discribes the format.

+1

Quote from Brilwing :

attributes makes the XML easier to read (by humans).
[...]
the main goal for the stats file format should be that it is processed by programs.

I'd like a consistent design pattern.

Quote from CLRS530 :

I made such a format so the best for me would be to use that

Your format has a few problems (imho), it doesn't stick to field names from the InSim documentation and it under-uses attributes, ie.

Quote from filur :

Your format has a few problems (imho), it doesn't stick to field names from the InSim documentation and it under-uses attributes, ie.

<penalty>
<penlapnumber>5</penlapnumber>
<penvalue>123</penvalue>
</penalty>

.. vs

<penalty lap="5" value="123" />

And you mean thats better?
I don´t think so

Also it was in fact my plan not to stick to InSim. I don´t wanted same attribute names. Maybe now I´m also better with the idea to use everytime lap, instead of penlapnumber, tolapnumber...
I did that because if you don´t really parse it and search in the text with normal methods.

I'm going to be doing server-side stats on STCC Servers soon, acessable via the web for every public race, hopefully alongside a rewindable RaceWatcer Replay (as LFS' own rewinding seems to be 'coming' still ).

I'll be exporting the contents of an HTML table, and including that table in a web page where the <table> tags and CSS will reside, I dont see the need for anything more complicated than that to do the job at hand.

I think a 'stats file format' implies that there is a distinction between stats viewing and stats generation. I dont think that is the case, programs which let you view the stats also let you generate them - if they give the ability to export/import that is all well and good, but what is the advantage to formatting that file in a common way?

I dont mind providing a stats file download if that's the way this idea shifts, and comforming to the format - but the primary multi-platform delivery medium is the web - so why does it need to be any more complicated than the contents of a table that can be styled by the page that includes it?

Quote from CLRS530 :

And you mean thats better?
I don´t think so

It makes XPath'ing the document easier / more sensible, for example.