I'd like to make things more clear: there is no point in distributing the source as it's ten times easier to write everything from a blank page than trying to modify existing stuff. Believe me or not, it is truth.
So, the answer is no. Sorry.

Hello.

I'd like to inform everyone interested that I'm ceasing the development. I strongly feel the thing requires complete rethink, redesign and therefore in fact rewrite from the scratch, as the main bone hasn't been changed from the very start. The worst is that I don't have enough spare time and interest to work on this project anymore.

Thanks for your support and feedback through this years, it really gave me a plenty of good time and helped to evolve towards the better self.

See ya.

The question seemed interesting enough for me to investigate, so I've added the MCI counter.
Using test replay with 16 players, I can confirm that the number of MCI packets sent to stats halves down with each replay speed increase.
The consequences are obvious

Speed values do vary a little bit between runs even at 1x speed.
It looks like LFS has some bandwidth/rate limit set on UDP MCI packets generation, what prevents recording the proper top speed values.
So logically you should get lower speeds recorded for high speed replayed mprs compared to 1x replays.
I've decreased the period of sockets polling just in case, but that won't do anything good in this case I suppose.

Quote from birder :

1) 3 racers stop in 0 time

That most likely is caused by an old lfs version they use

Quote from birder :

2) some of the reported items are wrong, the stats say minor yet the racers say their stop said minor, and major

There were some discrepancies in damage detection branch, and it should look better now.

Quote from birder :

Also just been told that their is another slight problem with the produced starts

I don't get this one, please explain.

Quote from birder :

In the settings section (First table) it produced "No obligatory pit-stop" when in fact the server is set to pitstop required

I've double checked the race info block and found no problems. I interpret the race information strictly according to insim documentation.

Anyways, there is another test build with quite a few fixes. Note that you must update your html_race.tpl, as pit-info words are made macro now.

Uhh, I just remembered I forgot to do the same work for penalty and flag tables... I'll leave it for the next time then.

birder, I 'm not able to find replays anywhere on conedodgers, can you please share the one with D1 stage?

Starblue, the bug is there indeed, and no one noticed it from the very introducing of WR compare
fixed.

birder, regarding pit and grid starts, I'll try to think about it, but I'd like to point out there is no way to determine a player time for any given moment.
About the template request, I don't really understand what prevents you from basing your web site page on the template file itself. You might want to change the template file extension to make dreamweaver recognise it as a hypertext, if that is a problem.
Anyways, introducing an additional template nesting level would create nothing but a mess in the program and its config file, I think.

flinty72, the problem does seem interesting enough. It seems that there are no PLA or PIT packets generated for Patto when he enters/exits pitlane and makes pit-stop. The only explanation I can think of is Paato running an older LFS. Host might check client version and avoid sending new insim packets in case of version dicrepancies.

Hello guys who care for! First of all, thanks for all of your replies, it is always very satisfying to know someone needs something you work at.

I believe nearly all the problems regarding new insim packets you mentioned are fixed now, so try it and point out the rest of the problems.

This is the first stage of improvements, I think I still have to do something about indicating penalties and pits on graphical representation of the race. But this is a work to do, that is

Hello.
Recently I began modifying stats to support new insim packets which Scawen generously agreed to add.

I'd like to ask for your help in testing the new version as I don't have any hold on crowded multiplayer replays, especially recorded with the latest lfs patch, W.

Also your feedback will be a good indicator should I still put efforts into the program's developing or it is nothing but a time waste.

flyby3d, replacing comma with dot in line 28 of graph.xml might help.

Quote from tomylee :

I get always wrong data out of it. Mostly for the last view drivers, it shows them as DNF but the did finisch.

I just can't stand qoting the faq:
A3:Shit happens...

Quote from tomylee :

Before it gave out a cvs file, now there is none. If I to change something in the xml file to get it?

Perhaps uncommenting csv OutputFileRace keyword might help in this case.

Hollywood, it seems that our views on educational process do vary a bit, but that doesn't change my intentions anyway.

duke_toaster, in case of racer swaps only latest one should be displayed. while it surely is possible to implement a proper swap log support, it can't be done due to inner structure limitations, which I'm not interested to be working at.

I hope someone someday finally comes with an uber solution of statistics generation developed while keeping in mind pros and contras of existing similar programs.

Quote from felplacerad :

May I request a customizable <OutputDir>?

My results/ folder gets messy in an instant!

May I ask you to be more specific? Customisable in what way?
You already can specify a different path for each generated file type...

Quote from banshee56 :

A couple of things I would like to see implemented/changed/whatever:

[....]

1) set the file name output for the HTML, the CSV, the TSV, and the TXT, have that information transfer to the lap file names, and the html lap callouts.

2) Add a custom title to the stats header and web page title

3) a place to add a link to an online hosted banner image

4) a place to add a link to an online hosted CSS file.

I might be completely wrong, but isn't most of this can be easily done by editing config and stock template files? have you got a look there?

Quote from banshee56 :

The last thing that I would love to see the stats page do is to be able to start LFS with the correct insim ports opened, and start the desginated replay, if that's possible.

To achieve this, all you need is to manually add a link to replay file somewhere in the results page (replay name cannot be retrieved via insim, so it's up to you to fill it) and make sure client computer which viewing this has mpr file association set to live for speed.

You also can auto-enable insim on lfs start by adding `insim nnnnn` line to /data/script/autoexec.lfs.

lyd, you are perfectly right.

Renku, I didn't change anything in wr-related stuff between these versions. I suggest you to try

Davo, whoa, 24h race, you're insane!
I don't allocate memory dynamically, and there IS a limit for laps which is set to 401. I'm not ready to answer where the problem crawls at the moment.

Btw, you actually can record stats for spr races or even hotlaps, all you need is disabling AtLeastOneFinishedCheck keyword in config.

Quote from Meanie :

Is it heavy at all, to run "on the fly"?
My specs are posted above.
What do you think?
If it's viable to run on the fly, i"ll do it.
It"ll be a lot better to have the results as soon as the events ends.

It doesn't consume any significant cpu time at all being run on the fly (the same goes to any replay speeds in case of offline analyzing), so you have nothing to be worried about, especially considering your cpu. just run!

Quote from Meanie :

If you wish i can send it to you later then, if you have any interest at all of having a "portuguese" version hehhe.

sure I'll include your work if if can be useful for anyone else

Quote from Meanie :

Ahhh, if you can, please take on the question i asked Renku too.
It would be nice to have your opinion on that.

Sorry, I don't really understand what you want to hear. I think you've been given pretty detailed explanation, as long as lfs runs ok, you'll get ok stats as well. top speed chart may be a bit off at higher replay speeds, but this is the only negative effect I'm aware of.

Meanie, use any speed which doesnt cause lfs to stuck up and stop reacting to your input. 8x and even 16x (in case of low players count) works for me. you might also want to switch to car wheels view prior to speeding up, what significantly reduces system load.

and yes, everything except braced words in templates can be changed.

lyd, people should learn from the best, not mediocre or just plain bad examples.

Davo, player name wont sneak to graphs from now on, so the problem is (temporarily) solved.

A.Fedorov & Renku, done & fixed.

Davo, I just installed hyeroglyph languages support and it didn't affect anything. To clear things a bit I tried to set default font from verdana to arial, can you test if this changes anything for you?

Gai-Luron, I wouldn't refuse to make the program open source if code quality was on sufficient level.
Since it doesn't meet my standards, I just prefer to keep it for myself

birder, I'm glad to hear it is useful for big projects like yours!

1.47 is out with tiny but critical change: no more unicode rubbish in graphs.

According to what I just saw, lfs sends only first 73 bytes of an user message via insim. No wonder long messages are being cut, because lfs is supposed to be sending 128 b messages.

I tried to receive messages via MsgOutSplit, but stumbled upon the same behaviour.

So, it looks like nothing I can do there.

Davo, I'll try to look into the problem a bit later.

Gai-Luron, what do you mean by incomplete? I and a few people I know are using chat logs and didnt find any problems besides wrong system messages encoding.

Davo, graph relies on presence of Verdana font in your system, do you have it? Looks like it is getting substituted by Fixedsys-or-alike font for some yet unknown reason.

Oliv76000, I believe this is corrected... finally

U30.

I capture LFS ingame messages via insim's MsgOutPack. The problem is that LFS system messages don't contain proper codepage flag in the beginning of a message, while player messages are ok.
Usage of localized lfs version leads to problems. For example, captured cyrillic text is translated as latin (I assume ^L is default message codepage), what leads to completely unreadable text.

Sample mesages received via insim, the same russian lfs translation:

Lines 1,2,3 are lfs system messages (pit out, joined session and can't load skin) and specified codepage is ^L, while it should be ^C.
Line 4 is a cyrillic player message with proper codepage flag.

Evasive solution of the problem in case of russian translation is adding ^C to the beginning of every string in russian.txt, but it isnlt quite beautiful.

Quote from Oliv76000 :

Why don't you use PlayerNameColoured everywhere?

Well, I don't really like colours in every table.
Good thing that you are free to change this to fit your needs

Renku, that nasty bug is fixed.

Oliv76000, I guess you have to install windows support of hieroglyph languages to be able to see japanese hieroglyphs.
If anyone can confirm this, I'd appreciate it.

Renku, looks like it is broken indeed, shall fix later.