hui Looks fantastic :wow:

mhm yes seems like cracking... or only looked for very much information

Yes I mean that with "bug" .
So it comes in one of the next incompatible patches?!?

Thats bad, so I can not really test car take over
But thanks for the information.

Here again, I found a possible bug?

I tried a 25h race replay made with U (I think) it runs well but I don´t get PIT or TOC (maybe some others not also). But I get The yellow and blue flag package

Hi Scawen,

first thank you

I now implemented nearly every new information:

- a counter for the flags (works)
- a list of takeovers (test now)
- a list of changed playerflags (seems to work but total test now)
- a list of pit stops (works)
- a list of penalties

So I used all packages beside the enter pit lane, but I send the verifyid back for all without getting a warning.

You did a good job, there is no problem for me. But you could write into insim.txt that player flag will be sent only on changes and not at beginning (thats good in my opinion)

Hi, there are lots of InSim addons and also some tools like InSim Gateway Companion wich provides more then one tool working. But I don´t think thats a good deal because of much configuration work and more important very much network traffic.
Then there is a good tool lualfs with wich you can write own "programs" in the scripting language lua.

I ever wonder about those very good plugin systems like in firefox, miranda, winamp... wich are so powerful. So I thought for myselv how that works and want to make such a interface.

The idea is to load the plugins (DLLs) dynamic while the program is working into it. Then get the insim packets and provide them over the interface (control wich packets to get (same like LFS does)

So in my opinion that could be a good part of LFS with some points

1. Some addon writer have to use it (best is to write there addon for this, should be not to much work)
2. It should have a easy but detailed interface wich is easy to use


I ask here for some feedback good or bad from everyone and some developers wich are willing to write plugins, working on the interface (idea) and/or implement it .

lfs tv director has to send an answer packet to the new packets (pit, flag...).
But it´s only a warning.

fine today is my birthday so I won´t do too much. Tomorrow I´m going to include Flag and penalty so I will see if everything else is working for me

Hi Scawen I now nearly finished implementing the pit stop feature. It works well now


( Scroll down for pit data )

And is it right that the PSF package won´t be sent yet? I got no breakpoint there.
I know you said that it works only in a incompatible version, but you wrote nothing before release and insim.txt says it should be send upon V3

Last edited by CLRS530, Sat 24 Mar 2007, 10:55.

Quote from Scawen :

Becky : I cannot reproduce that. FinishLine and NumNodes seem fine to me. I didn't change MCI at all.

CLRS530 : Yes I am sorry about that, you should be getting FIN then RES but I put the wrong header and your RES packet is named FIN and your FIN packet is named RES.

I have done some other fixes and I will upload the fix in the test patch forum. It might take up to half an hour as I don't want to make any mistakes.

Ah ok thanks. I´m not so fast in saying it´s a bug, because I was too often wrong and at least it was my fault

Am I wrong or sends the RES package now everytime resultnumber 255?
I capture the IS_RES package like before surely I changed the struct.

Can someone confirm this?

Example: drove one lap with BF1 in single and multiplayer on Kyoto ring normal.

Last edited by CLRS530, Fri 23 Mar 2007, 23:09.

Awesome Scawen. That looks more then good Thanks for all you did again for us.

I have some notes for insim.txt.

1. The top line shows the wrong version
2. For IS_RES you wrote that resultNumber is 255 in qualification if the position won´t added. Does that mean if I drive a worse time then before and my position isn´t better it now shows 255? I know that was strange before and I tested myselv if the time was better.

One question at least. If a flag gone off, does in this packages flag shows the right color (from the flag wich was cleared).
And one last request, could you add a time also to this wich is only need in the situation of an flag cleared use of this package?
So that we could analyze the reaction of players to those situations.

Thanks again, I´m very happy with this now

Quote from Scawen :

In IS_NPL I hope to add SkinName[16] and TyreCompound[4].
In IS_LAP I hope to add NumberOfPitStops[1] and PlayerFlags[2].

Nothing's definite until I have a look (the same goes for the shifter thing - I don't know what info is available and I'm too tired to look this evening).

Sounds good

EDIT: One idea came in my mind wich makes everything a bit easier.
Whats with a lap number in all new packets (word)?

Last edited by CLRS530, Thu 22 Mar 2007, 04:17.

Sorry Scawen didn´t notice your post.
From my site you could do that because its nealy the same but really not compatible because someone could compare the name.
For me and or better for the site of my tool would there be some work to do.
But for what do you want to use the space?

Yes you are right.
Is easy to count IS_PIT isn´t it? - but yes it would make it a bit easier. Also this could be in the IS_PIT themselv (the count of pit stops with the current included)

Quote from icyocean :

the new IS_PIT packet is great as it's language independent, but is it sent only when a pitstop is taking place? it would be great if there is a status info about a player's pit times like in the IS_RES packet while the race is still going, so a race monitor tool does not have to be connected to the server all the time to catch all the IS_PIT packets just to count the pit times (if the race requires mandatory pitstops this would really help the race adm). i hope this is not very hard to implement

Its ever good to read the whole thread
http://www.lfsforum.net/showthread.php?p=365626#post365626

EDIT: AH bad read from me sorry

Last edited by CLRS530, Tue 20 Mar 2007, 14:21.

Am I so unclear?

Quote :

]But you don't know which tyre he uses, even if he does pit, do you? There is no info about tyre types at all in any packet, as far as I can see. It seems you are asking for something completely new - info about the type of tyre used on every wheel, in the NPL packet and the PIT packet. I'm not sure if that's a good idea, isn't that giving away the setup? Is that good? I'm concerned that may be a big discussion - not something I can just decide to do just like that. Is there any other previously secret setup info that we should be revealing through InSim? Please say what you are going to do with this information, so I can try to understand what it's about.

Sorry for the missunderstanding, it was my fault

I didn´t read this well and thought its the number of the tyres...

I plan to integrate informations about pit stops in my program, so write whats changed and wich tyres used.
Its nothing totally important but would be nice. If its a problem for you, you can leave that out. But I don´t know why that would too dangerous to use. I ever think of a normal race, the team can see wich tyres are in use.
If you have a tactic and use special tyres then the other players at beginning or after pit its mostly too late if you know that...

Quote :

I can take a look at those though it's not very clear what you mean by saying that all info at the start of the race is from the previous race. More specific info would be helpful.

I requested a STA package at the first MCI package I get, to have the race infos also if the race is in process. If its a race and there was a qualify before I ever wondered why I get 0 laps but 20 minutes qualifying for example. It took some time until I get that I got the information from before.
Maybe the problem could be, because I export the stats after VTA, delete it and continue with processing the next race. If there would come a MCI package after VTA wich belongs to the qualification and not to the next race I understand where the problem comes from. But that should be fixed also.
I have the problems also for the MCI package for sure.

Quote :

It doesn't seem very easy to me, partly because I don't really understand the situation.

That posts seems to be combining two issues together and that is confusing.

I want to describe it again on my example.
I capture the race and save all important informations. If a player fly to pit and go back to race I have to reset his informations like LFS does it also.
But if a player finished some laps back and gets "?" instead of a position you don´t send a package. So if the player fly to pit after finishing to make some setup changes or something else I reset him there or lately when he comes back before his position is clear.
For that reason wich is a big designing problem in my eyses this package would be very helpful.
At the moment I don´t reset him if one or more players finished. But mostly his stats should be reseted in this situation

Last edited by CLRS530, Tue 20 Mar 2007, 10:09.

Nice words, but I don´t think you use my tool, what I found is only LFS stats

http://simfia.com/resources/St ... 5.50.16_results_race.html

my tool and lfsreport for generating a website is this
http://www.vrl-simracing.be/lf ... spergraph=24&cssstyle=
(for the same replay)

Quote :

I don't know what you mean about tyre numbers and tyre information in the NPL package. Please try to explain some kind of reason why you want tyre info, so I can understand why and how it should be implemented.

First there is no information what tyre number is wich tyre.
The other thing is. I don´t know wich tyre a player uses at beginning of a race (or if he don´t pits) so I want to have it in the NPL.

Quote :

About the yellow flag packet, sorry but I don't know what you mean, please explain, what information you need added to the packet and why.

I mean two packets. One for blue flag like you did. But a own for yellow flag, because a yellow flag isn´t for a player, it belongs to a track point.
Or does it show the player who initiaded the flag? - I though who get it. If its the one who causes the flag it would be good.
But it would be good to have a node information to easy now where the flag caused. I don´t need it, but I think of some... On the other hand everyone can get this themselv.

Quote :

About pit stop time, are you talking about another packet after the stop is finished, that tells the host how long the pit stop was? That is impossible in a multiplayer compatible version, because the host does not know how long the pit stop is. But I've made a note for a future MP incompatible version.

yes thats good and enough

Quote :

I don't seem to have any notes about your bug reports. Perhaps you could collect them into a single post to make it easy for me, there is a lot going on and I am trying to avoid being confused.

I posted them at the beginning of this thread
http://www.lfsforum.net/showthread.php?p=355131#post355131


I also miss one another package
http://www.lfsforum.net/showthread.php?p=355189#post355189
That should say everything. That would be very important for me and should easy be implemented

Yes thats a lot better (you forgot the activity time :P)

Scawen said before that mainly the gtrs will be updates with some new parameters, so surely the physic will be changed too (thats what my status is ).

Hi, I said it some time before. Live for Stats is now open source. You can download it from sourceforge (Link to Live for Stats Project).
Until now the feedback to it wasn´t good, maybe because of too many other programs .
But especially with the long run support it is very interesting. Enough of that, if someone is interested to work with everyone is welcome. Next I plan to implement the insim changes from V3 and then I want to see a tracker system to make best use of the long run support.

The source code is mostly well commented and in english language. Its my first so big project so I don´t know how good the code and structure is
Most things are implemented with classes (OOP)

Hope it helps and for some comments if you want to work with , want to use parts of it or have critism/ a bug


EDIT: Link to the thread about the binary http://www.lfsforum.net/showthread.php?t=13368

Last edited by CLRS530, Sun 25 Mar 2007, 22:56.

Ok, read it and have some questions/ notes

- there are no information about the tyre numbers

- also there is no tyre information in the NPL package (ahhh I see, there is no byte availible, could you then make it requestable?

- could the yellow flag been given in a overall pack with a node information? Cause I think that would be better for it

- there is no time information for pit stops (yet) but I think thats one of the most interesting things


- did you noted some of my bug reports? Maybe for later change

Hi, functional its very clear and works fine.
But it looks like a debugging program, the design isn´t beautiful but more important, the distance is in metres for example and thats not good for viewing/ reading.
If you change this its a good program for a fast lookup from information

Quote from Scawen :

New InSim packets (pit / penalty / take over / flags)

Hi Scawen, could you attach the new insim.txt (if you finished wrote it) so that we can start updating our programs?
Or also for possible wish for something to change