I have noticed that some requests for InSim updates have not got to me - there's no way I will ever be able to read all new posts on this busy forum! I have started this thread so that you can alert me to any problems that are stopping you from making InSim programs that should be possible, or any new packets that are required.

For example, I have just read that at least two people want a pit packet. However, there isn't any information about what they want a pit packet for. If you need a new packet, please explain to me an example of a situation it would be used and what sort of information you need in the packet.

But please don't use this thread to discuss at length with other programmers, new functions and interfaces. I'm very busy and where possible it's best if I'm not involved until you have worked it all out. It would be very helpful to me if you would discuss your ideas with other programmers on other threads, and when you have the best idea worked out, then post here so I'll find out.

Thanks, and I hope I can help to keep InSim updated for you!

I think there are a lot of people who would appreciate packets being sent when a driver enters the pitlane, when a driver actually makes a stop, completes a drive through or a stop and go etc. Maybe a packet giving the length of a pit-stop would also be good. At the moment I think fairly complex methods have to be used to determine if someone is pitting. Packets indicating whether a tyre change took place and whether or not fuel was added might be a good idea too. I don't think it would be fair to give specifics (amount of fuel added, which tyre compound used), but obviously in real life you would be able to see whether or not either took place just by watching the pit-stop, so I don't think it would be unfair to be able to see whether or not fuel was added / tyres were changed, via insim.

Obviously some of these packets would be useful for race tracker scripts, such as the one used for MoE. I guess it would also be useful for replay parsers, such as LFS stats. Being able to tell if tyres were changed and if fuel has been added at a pitstop might be good for league admins who impose compulsory pit-stops.

One of my teammates has been working on a tool for use in endurance races so that teammates can see the current drivers' fuel usage, projected laps and pit-time etc. I know that a packet denoting a pit stop would be useful to him, as well as one allowing him to see if any fuel was added at a pit-stop.

Edit: Just saw this post http://www.lfsforum.net/showthread.php?p=354872#post354872. May as well ignore this reply and let some others discuss it properly. Sorry.

Would it be possible to make the camerapositioning work on the custom camera's too? Right now this camera can be rotated, pitched and rolled, but not translated. I guess only my own tool and LFS TV Director would benefit from this, but it would really add a lot more realism and possibilities for streams etc.

Ideally

PIT
Time in pits
Current lap
Car Repaired 1 or 0
Car Refueled 1 or 0
Tyres Changed nnnn (FR,FL,RR,RL) 1 or 0
Penalty 1 or 0

Useful for so much stuff, stats calculation (driver consistency charts forgiving last and first sector), stats reporting. League regulations where compulsory tyre changes are required. Pit stop time reporting useful for commentary.

UniqueID & ConnectionNumber are hard to keep track of because there are two numbers that both change without notice.

It would be nice if players had a unique reference number throughout their time on the server that could be used to message them, with the number included in the new connection, join race, lap and result packet.
EDIT: This could be put in the 4th byte of the packet header to maintain compatability.

Outguages packet of 96 bytes is not the only packet of 96 bytes, a special detection routine is needed. Giving this packet a header would solve the problem.

YEL (Yellow flag packet)
Car issuing a yellow flag packet
Cause (binary mask?) 1 stationary, 2 wrong bearing

Useful for calculating an incident per lap algorythm.
EDIT: I would also like to use this as part of a server side system that detects oncoming cars and notifies driver to hold position (and spectate if they dont) to prevent less race experienced drivers from rejoining into traffic.

IMP (Impact packet)
Car involved in inter-car impact collision detection

Useful for calculation an incident per lap alogrythm.

HUG (virtual hug)

Useful for thanking Scawen for putting some attention on Insim.

These are the things I think i'd most like, although over time i've found several others - perhaps later I will try to trawl through some old posts and find them.

Quote from Becky Rose :

Ideally

PIT
Time in pits
Current lap
Car Repaired 1 or 0
Car Refueled 1 or 0
Tyres Changed nnnn (FR,FL,RR,RL) 1 or 0
Penalty 1 or 0

Looks good for me, but the penalty could be a drive through or a stop and go.
So my suggestion for penalty:
1 DRIVE_THROUGH
2 STOP_AND_GO
4 COMPLETED_DRIVE_THROUGH
8 COMPLETED_STOP_AND_GO

Quote from Frankmd :

Would it be possible to make the camerapositioning work on the custom camera's too? Right now this camera can be rotated, pitched and rolled, but not translated. I guess only my own tool and LFS TV Director would benefit from this, but it would really add a lot more realism and possibilities for streams etc.

1) I totally agree. I would like to use different car cams so I would have to control the position relative to the car too. (priority high)

2) Additionally a pit stop packet for LfS TV director too. (priority low)
Requirement: ideally at the moment when the car enters the pit lane.
Required information:
- Unique ID
Desired information:
- reason (drive through, stop n go, or pit stop)
- estimated time of pit stop

Oh yes I nearly forgot - when I finaly get around to finishing my LFS Race Watcher (LFS Spectator replacement) I would like to pull off the players skin so I can apply it to the car. This would also be useful on stats output to put car graphics on the web page output.

I can check the installed LFS folder for presence of the skin and I can download a skin from LFS world, but I dont know what skin to apply

EDIT: Race Watcher Application in Development*
*STCC Servers not currently relaying - Could Victor change the 15 retry period please to extend up to 1 day for the 15th attempt

Ah yes I also remember being stuck once because INSIM does not tell you if a race has a compulsory pitstop, ideally placed in the restart packet. This was needed for my radio mod last year, and would be handy if I return to it.

When player times out, LFS could output InSim packet (PTO?), instead of writing language dependent message "nick timed out". Not directly related to InSim, but WRONG WAY (and flags) message is really annoying, cannot be turned off, and it cannot be overwritten with rcm message (option somewhere in menu to disable all these default center messages (but still allowing custom rcm messages) would be great). I would suggest packet for notifying about resetting player's car, but in next? patch not allowing reset will be possible, so this is not necessary . Otherwise, most important are pitting messages already described by above posts .

Quote from Becky Rose :

UniqueID & ConnectionNumber are hard to keep track of because there are two numbers that both change without notice.

It would be nice if players had a unique reference number throughout their time on the server that could be used to message them, with the number included in the new connection, join race, lap and result packet.
EDIT: This could be put in the 4th byte of the packet header to maintain compatability.

Dunno about any other stuff because I'm not a leet hacker This one I though is a packet I'd appreciate infinitely. A per-connection ID that does not change for the entire duration of the connection. I'd like to have it because keeping up with constantly changing conn ids and stuff is just needlessly complicated.

A damage packet would be good, maybe included with the player information?

There could be, say, 4 packets each with this structure:

0 No Damage
1 Slight Damage
2 Medium Damage
4 Heavy Damage
8 Full damage

Unless you could just give the proper percentage damage, as shown on the F10 page.

This may only be useful to me and maybe the CLC server so I guess it isn't too important.

Hi Scawen, nice to see.
I made a thread some time before, where I thought about some new packets

http://www.lfsforum.net/showthread.php?t=16290

Also I found some bugs wich are very annoying:

1. All packets you got early in race (MCI and STA) have information from the last race. That problem is surely only in the real race but not in a replay.

2. There were many other responses to the node bugs in the MCI packet.
The new lap don´t comes on a static time. Sometimes it comes before the finishline.
It would be good if you could be sure that it comes 1 node behind the finish line.

(3.) I´m not sure here, but in my Stats tool I send a MST packet if I save the stats or not, sometimes at the end of a race there comes a warning "Thats not a right MST packet" (the message is something similar). But I don´t know why it could appear from my side.

EDIT:
One thing wich gives you very hard work, is to make sure you get all information at a race in progress. It would be nice, if a new player gets a welcome packet or more welcome packets.
Important is the race start packet and there could be send all players and the results from players wich finished.

Quote :

send all players

This would be really useful when I restart my management tool and cannot get certain information again until players leave/spectate & rejoin etc.

Quote :

and the results from players wich finished

At the moment if a player finished with a ? mark for position when the race replay ends or race restarts i'm not sure if they ever get a RES packet. I use the RES packet to advance licences.

Quote from Becky Rose :

At the moment if a player finished with a ? mark for position when the race replay ends or race restarts i'm not sure if they ever get a RES packet. I use the RES packet to advance licences.

Yes good that you mention that, this is one of the hardest design problems I had to work with. If a player finished and has no result but went to pit and back I have to reset him.
So it would be good if you send two result packets for this reason with a special flag set or the position to 255 (better would be a new packet for that reason to be compatible).

I meant a result packet for players wich finished before you joined the race with InSim.

Oh yes, driver swaps. Could there be an insim packet to detect this please? and/or a config file ability to disable it

We weren't supposed to be discussing ideas in this thread, it was supposed to be for finalised ideas that had been discussed and agreed on.

I suggest for a mod to move these posts (and delete this one).

You are right, but for now it didn´t go out of control and not to many saying something to it.
Also it wasn´t a discussion about one idea against another. So I don´t think Scawen has problems to read it and see fast whats interesting.

But it would be nice if you (Scawen) could write something to my (finished) packets whats ok and what you don´t see so or isn´t possible to do.
That are all new packets I have a idea for and the others didn´t mentione new ones.
The new packets and the bugs are very important for me to be fixed, so Im happy that you finally see that its needed

Here are the changes I've done for V3 so far. I'm not sure if I'll add more but I was thinking of implementing the "get all connections and players" request.

You can see the new packets by searching for the word "NEW!"

Let me know if these are helpful changes, or if there are any issues like you can *nearly* do something but not quite! I've tried to do the requests that were easy enough or possible to do in a compatible patch.

[ EDIT : removed the file because there is a new update http://www.lfsforum.net/showthread.php?p=368449#post368449 ]

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

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.

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.

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.

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.

Scawen, dude I love you! PIT packet! W00T!

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

Quote from CLRS530 :

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.

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.

Quote from CLRS530 :

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.

Yes blue flag is if you are given a blue flag. Yellow flag is if you are causing a yellow flag. The player causing a yellow flag can be moving so a single node may not be a good idea.

Quote from CLRS530 :

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

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.

Quote from CLRS530 :

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

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.

1) You seem to be asking for two packets about the player finishing. One that the player has finished, with no information about the final position, followed by the result packet when the position is finalised?

2) You are saying that if you join with InSim when some people have finished, and others have not yet finished, then there can be a problem. But maybe that is just going too far. I don't see why we need to support InSim programs that join after the winner has already crossed the line, and still expect it to have a full set of race results.

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

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