Make it sense to put the yellow and blue flag also into the laps tag? I know that Insim does not send the lap number, but in my stats tool I put the flags into the current lap when the IS_FLG event is received.
I also suggest that we make mendatory infos and optional infos. For example the result or lap time is mendatory, but the speed should be optional.
I put a lap number into penaltie, pit and take over and no I don´t think it would be good to put it into lap because we have to put an empty element in every lap where you don´t need it.
Thats much better structured and you get a better and faster overview.
And why do you want the flags into the lap?
Thats only a counter of flags the player got.
Maybe you can make also a list of it. But I decided that it would be too much and isn´t needed.
The splits ad laps and penaties tags. I don´t know if you do this if you could have more entries. This should someone say how know more over XML. filur?
EDIT: I don´t formated the speed because you maybe will lost the exact number and its better to work with. It was in fact bad to do it with the time. But you can export it in hundreds of seconds with an option in my program (readflag 1 ist set in this case)
I have a driver detail page where every lap of a the race is display and I want to add a flags column that shows when a racer has received a blue or caused a yellow flag.
Here is an example of the current version of a drivers detail page: http://liveforspeed.at/?q=league/driver/detail/310
If the pit and penalty infos are childs of the lap element, it is also very easy with XPATH to get only a list of all pits of penalty tags.
Yes you can have more entries, and you can get the correct tags with XPATH.
Mhm you brought a new point in with your first idea. For some things it would be better to do it this way. BUT you have much overhead with ever the player name. Also it is harder to read (if you should read the xml file).
I prefer the second one (wich is similar to mine).
Also I think the first format would be harder to write.
You did everything as attributes. Also the users data (and why user and not player?).
There are many more tags to save, so that its too much to do it with attributes (my opinion)
I also happen to like my second more then my first. This is mainly due to the fact that it's more akin to the .lsf stats format that I had originally envisioned. In my view, I don't think that the end user will be reading the file raw. They will be using like SimpleXML to do that, or some other xml functions in their language.
Why did I use user rather then player? Well, user is shorter then player or driver, and second, what if this also supports spectators at some point, they are not players or drivers as they have no effect on the result.
The size of the file is really a non issue, seeing as they are so small in the grand scheme of things. We are using after all, XML, that pretty much the most pigged setup for any format, ever. So much mark up, for so little information, flat text files with expectations on what should go where would of been best if we really were worrying about the file size. But that is besides the point.
One thing that might be of rellevence to this discussion, i'm making a viewer application that allows watching of LFS races on a 2D overhead map and allows for replay rewinding, stats application authors may wish to support this file format although i've designed it for server side use and therefore it's main role is to provide for tiny files in order to keep an archive. The intended aim for it is to be used in stewarding, if it's good enough - which is yet to be finalised.
I've not finalised the format yet, but i'll post what i've got so far so that you can keep it in mind.
//SSR Specification var line A variable length string terminated with an EOL var short An unsigned two byte value with Intel Endian var int A signed four byte value with Intel Endian
line SSR //denotes file is of type SSR short 0 //denotes version number line Track short code short laps byte weather short time interval
Then onto packet data, packet data is prefaced by a single byte identifyer
0 End of this time interval 1 New player 2 Existing player 3 Lap completed
//New Player struct short unique ID of this player in replay file // use of LFS uniqueID is not recommended as during the course of a single replay two players may occupy the same uniqueID line LFSW name line player name line car name + skin name (no _ seperation) <followed by existing player struct without uniqueID>
//Existing Player struct short uniqueID int x position int z position short heading short facing short angVel short speed
//Lap Completed short uniqueID byte sectors { msht split sector time } msht lap time short current lap number
Final specification details will be available on program release which I hope to get done very soon.
1. it looks like it want to look "professionell" in my eyes the "lfs:" is totally needless.
2. Why is there a live section. I see your idea but if you send this live you won´t send all the other data or am I wrong?
[Second Look]Ah I see it has another tag, not "lsf" is that a sort of case of? Will read something about it. But Iam confused because you have both in one file[/Second Look]
3. I don´t understand the finish section. I know that you get the data in the IS_FIN package, but I don´t see a reason why copying InSim in such an equal style, that we create a "readable package image"
4. You did it the other way then me and put flag to the lap times that also don´t get my vote because I think it will be harder to read the content if I think for example for creating a website out of it.
Ok you can do it with the flags maybe, but if I see this I think you want to do it with pit and penalties too.
Also I don´t think too many are interested in the detailed flags.
5. Thats my last point. You wrote sp1="" ... Thats ok but I would prefer a list of splits because you ever have to write 3 tags also if you only have 1. Thats not such a bad situation. But it isn´t save for future changes in LFS where you maybe get more then 3 split times. And I´m a ever for lists more then for this way like you saw before :P
Sorry that I´m so critical with this. I could have a go with it, but we are here to discuss over a format so everyone should say what he prefer
They are namespaces. For example, it's very simple to discard unknown namespaces, thus letting authors embed any kind of data without causing any trouble for a parser (since the parser never even sees data outside of known namespaces).
Namespaces only make sense if other kind of data is also included in the XML file, and that is not the cause with the stats file format. If you want a valid XML file so that the parser has no problems, than a XML-Schema is the right way.
So we need no namespaces here, it only make things complicated.
As I wrote earlier in this thread I don't like abbreviations. You sometimes use full names in your example, and sometimes use abbreviations.
So always use full names like username instead of uname, or position instead of p.
Also the time should not be formated. XML is mostly read by programs so a unnecessary parsing could be avoided.
If the flag tags have lap numbers, than put them directly into the lap tag. Also the split times. e.g.:
As i see it, namespaces do not complicate things, they create an extensible format where you can put other kinds of data in the file. Since i want to be able to add extra data for rendering live progress, using namespaces makes alot of sense.
Surely it is possible to validate an extracted node / namespace instead of the entire file.
I agree.
The time is actually not formatted, i've dumped it straight from LFS as m.s.h.t
Is this format meant to be human readily human readable?
I really don't think it's that important myself, however ... I would no go about using things that no one has ever heard of in places that people should know. I would use uname, and pname, as they are well defined (In my view). I think that the format should read like an XML file that takes ques from insim packets. One readme.txt file to rule them all! I also think that namespacing the stats is a MUST. It should be eXtendable as we are doing it in a Markup Language. So some parsers can't read that ... well then, don't use them. We are here to make an XML file that validates to it's own format, and that format just so happens to be about Live For Speed stats, weather or not it's live or from a replay. You kill so many different birds with one stone like this.
Hmm, first I also thought that is should be analog to insim, but now I don't know if it is the right direction. The goal of the common stats format is that different tools can use the same input format. Why not different racing sims. I mean that the naming or values like penalty should not be lfs specific. e.g.:
You know what, I'm not sure what I think about that right now. I see where you are coming from, and I'm pretty much coming from the same place as SimFIA runs things for LFS and soon rFactor. It would be nice to have a universal format, but thats out of the scope of this I would have to say. I do know where your going tho, and I do like it. The whole name space thing works well in a situation like this.
lsf - Live For Speed Stats Format.
rsf - rFactor Stats Format.
I´m not for most of the last examples because they all have so many useless data. For example the penalty type in every lap entry. How do you get a penalty that such thing is needed.
Also you have pit, flag, take over... Where do you want to go with this.
Every example has only parts of all availible information in it and I think most times you don´t think enough forward.
Maybe in a common format there is no space for speed because its also not the easiest thing to implement. But you can´t take out pit, tyres, flag and so on...
So why do we don´t use my way to use a list of all those infos? In my opinion thats the best way. Easy to implement and the easiest way to parse. I don´t understand why you try hard to get something else.
What useless data? We do not put a penalty tag into the lap tag when no penalty event happen. Only when a penalty, takeover, flag occurs, than a tag is added to the proper lap when the event occurs.
As I suggested earlier in the thread, we should put mendatory info in the format, but the speed should be optional. But we should only put infos in the file that are useful. I only think that the top speed is one useful information. As I remember there were more things in filurs example is not available anymore, so I cannot give an example whats useless.
I mean an example of Dygear, he put the penalty tag in every lap "<lap ... penalty="0">"
Putting a tag <pit> behind <lap> if its in the right lap is this really a valid xml structure?
One thing I see as valid would be
Don´t lay words in my fingers I never wrote.
I wrote to use the idea of those lists instead of put every event into the lap list wich comes strange to me.
Also you can easy write "attacking words" but I discuss what I like and I argument what I don´t like on other formats.
You could come with arguments but thats no way.
Yes that at least is also for me the best from all ideas.
I think we need a flag in the lsf tag wich shows if speed is in it and if there are pit information.
The best idea is to split the new packet information in two bits. One bit for the new information and one additional for pit and take over... because on an old replay you get flag and so on, but no pit events.
Also the time should be changeble to hundreds of seconds. That was a request on my file and I implemented it.
Thats a nice basic think,but there are no new packet information in and we have continue working on bring it together to a result.
For me it would be nice to have the speed for spilts too, but if I´m the only one who do this it´s not good for you I know.
But on the other hand I couldn´t be compatible with my main output.
So splits times would be SPX and split speed for that split would be what SDX? I would have to say then when the cross the start finish straight that it would be SDL, and for the fastest speed overall on that lap SED (If we should include it).
Also, I do think that leaving the time in the MHTS format would be the best for us all. 3000 for 30.00 or 0:30.00 or 00:30.00 or 0:00:30.00 (Ya see my point).