InSim changes needed (bug fixes, new packets needed, etc) [Archive]

Scawen

6th March 2007, 21:44

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! :)

joshdifabio

6th March 2007, 22:57

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.

Frankmd

7th March 2007, 05:50

Becky Rose

7th March 2007, 07:04

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. :D

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.

Brilwing

7th March 2007, 08:20

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

Soeren Scharf

7th March 2007, 08:38

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

Becky Rose

7th March 2007, 09:38

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 (http://www.bansheestudios.com/LFS-RaceWatcher.zip)*
*STCC Servers not currently relaying - Could Victor change the 15 retry period please to extend up to 1 day for the 15th attempt :)

Becky Rose

7th March 2007, 09:42

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.

MonkOnHotTinRoof

7th March 2007, 10:16

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 :D. Otherwise, most important are pitting messages already described by above posts :nod:.

NotAnIllusion

7th March 2007, 10:37

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 :D 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.

Leifde

7th March 2007, 10:40

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.

CLRS530

7th March 2007, 11:21

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.

Becky Rose

7th March 2007, 11:49

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.

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.

CLRS530

7th March 2007, 12:21

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.

Becky Rose

7th March 2007, 12:42

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

Peptis

7th March 2007, 23:40

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).

CLRS530

7th March 2007, 23:52

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 :)

Scawen

19th March 2007, 19:11

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 ]

CLRS530

19th March 2007, 19:43

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

Scawen

19th March 2007, 22:57

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.

Dygear

20th March 2007, 00:31

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

CLRS530

20th March 2007, 07:42

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.

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.
[/URL]

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 :)

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 (http://www.lfsforum.net/showthread.php?p=355131#post355131)

I also miss one another package
[URL]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

Scawen

20th March 2007, 08:39

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.

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.

I posted them at the beginning of this thread
http://www.lfsforum.net/showthread.php?p=355131#post355131I 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 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 implementedIt 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.

CLRS530

20th March 2007, 09:05

Am I so unclear? :(

]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
byte Tyres; // number of tyres changed ... NOT YET IN MULTIPLAYER!
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... ;)

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.

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

icyocean

20th March 2007, 09:26

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 :)

CLRS530

20th March 2007, 09:37

joshdifabio

20th March 2007, 13:10

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

I think he means a packet telling you the number of times a driver has pitted, not the length of the stops.

icyocean

20th March 2007, 13:21

by pit times i wasn't refering to the time a player spent in the pitlane, which the earlier posts were talking about, but rather how many times a player has pitted in the race, since the IS_RES packet contains this info i assume this is something the server knows :)

CLRS530

20th March 2007, 13:23

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)

Frankmd

20th March 2007, 19:51

Becky Rose

21st March 2007, 06:35

Insim Feature Request
Hi, could it be possible to add the player flags (the one that stores driver controller/aids like throttle help etc) into the SPX or LAP packet please.

This would unfortunately make the packet incompatible.

I use this feature extensively now to control driver aid use on my servers, I check when people join, but drivers have complained that if they turn the aids on mid-race and get caught using driver aids they are banned for a day for cheating the system, as the ultimate deterrent.

If I could detect the driver aids mid-lap then I could just spectate them and that would be much better all round.

Thank you.

*iHug - The simpler non complicated hug from Apple*

Scawen

21st March 2007, 08:15

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 [number of] pit times like in the IS_RES packet while the race is still going...Yes IS_PIT is sent at the start of the pit stop. In a multiplayer incompatible version I should be able to add another one at the end of the pit stop, which says how long the stop was.

But that's not what you are asking... you want to know the number of stops, continually? I don't know how you could have that info continually, but I was thinking of adding the number of stops to a new packet, IS_FIN, sent immediately as soon as someone finishes (before the RES is sent). Would that be good enough? Also, I think I could add the stop number to the IS_PIT packet (i.e. 1 for the first stop, 2 for the second, etc).

There is one other way I could give it more "continually" than it is now, if I replace CName[32] in the IS_NPL and IS_LAP packets, with CName[4] the skin prefix instead of the whole name - which would be consistent with the IS_RES packet. Would anyone object to that semi-compatible change which allows some spare bytes in existing packets?

Scawen

21st March 2007, 08:20

I dont see anything mentioned about new/different functions in the camera position system (CPP packets). Reading back my initial post I might have been unclear... By custom camera's I mean the custom camera's stuck to the car, which you normally set from within Options > View > Default driver view > Custom. It might have changed but not mentioned or maybe it is something that would only be possible to change in an incompatible version.No, your description was clear and I have made a note of this request but I have been working on quite a few test patch things and development version things as well for the last week, I've been very busy and it gets hard to keep track of what's going on, making sure I finish things and note them all for testing.

The camera thing would confuse me more and delay the patch a while so I have decided not to look into it, and concentrate only on Race Tracking for the InSim updates in this patch.

Becky Rose

21st March 2007, 09:35

Scawen

21st March 2007, 10:55

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.It seems that the problem is you are using the VTA packet to decide when a start race / start qualifying / end race event occurs.

But that is the wrong thing to do. The VTA just means that a race or qualifying or end race vote (SHIFT+R, SHIFT+Q, SHIFT+X) vote is completed (or done by the host). This just means the countdown has started - it can still be terminated by the host for a few seconds.

You should use IS_RST and IS_REN instead.

Scawen

21st March 2007, 13:03

Change to /lap command
This isn't really insim, but it would be nice if my server software could issue the /lap command without going to the end race screen.

I would like this because I set the number of laps based upon several criterea such as how many people are online. If people leave I like to shorten the races. At the moment this change can only happen by going to the end race screen which I do every 2 hours, but i'd like to be able to issue the change before sending the /restart command.

EDIT: Actually i'll do it just after restart so it takes effect the following race, that way people get some notice of the change :)I have just made it so that admins can use /laps /qual /hours and /wind even when they are in game. You will get this in V3.

You will have to use this with care, because the first 3 can change it LIVE during a race or qualifying! Now you know why I've made it admin only.

/laps and /hours - It's ok to change this any time after the winner has finished. The remaining results are not corrupted, apparently in my small amount of testing. I would suggest in your case Becky to do this after you have a IS_RES for the winner - and put out a message to warn everyone to change their fuel loads for the next race.

/qual - Can be used any time during qualifying, for example to bring an early end to qualifying.

/wind - doesn't really do anything until the next race, but does cause flags to appear or disappear.

icyocean

21st March 2007, 13:05

Yes IS_PIT is sent at the start of the pit stop. In a multiplayer incompatible version I should be able to add another one at the end of the pit stop, which says how long the stop was.

But that's not what you are asking... you want to know the number of stops, continually? I don't know how you could have that info continually, but I was thinking of adding the number of stops to a new packet, IS_FIN, sent immediately as soon as someone finishes (before the RES is sent). Would that be good enough? Also, I think I could add the stop number to the IS_PIT packet (i.e. 1 for the first stop, 2 for the second, etc).

There is one other way I could give it more "continually" than it is now, if I replace CName[32] in the IS_NPL and IS_LAP packets, with CName[4] the skin prefix instead of the whole name - which would be consistent with the IS_RES packet. Would anyone object to that semi-compatible change which allows some spare bytes in existing packets?
IMHO since the number of player's pitstops is more like a status info of the player, it's better to have it acquirable any time during the race (so if a player connects in the middle of a race, he would still be able to track this info). The compact IS_NPL packet seems a good idea :)

Scawen

21st March 2007, 13:07

St4Lk3R

21st March 2007, 17:36

No one has yet objected to what I said in this post :

http://www.lfsforum.net/showthread.php?p=366808#post366808

I am suggesting a change from 32 byte car name to a 4 byte car name (skin prefix) in the NPL and LAP packets, to allow some more space while leaving it nearly compatible with existing software.

I haven't really left much time for anyone to reply but I will get on with this this afternoon, because it's InSim day for me - I don't want to spend much longer on V3...
If I got you right, then the skin prefix should be something that is consistent all the time the racer is connected to the host or even consistent through the whole lifetime of the account. If it's like that, then I think it would be really REALLY useful to do the change, this makes life so much easier for developers :)

AndroidXP

21st March 2007, 17:45

Becky Rose

21st March 2007, 17:58

No one has yet objected to what I said in this post :
tbh Scawen it would be better to use the short/skin prefix name anyway... It's actually something of a pig to convert them to short names when making an insim application (the userbase uses the skin prefix/short names :) ), but for those of us who use this value then our programs will need adaption so this isn't what i'd call compatible, although for my part i'm happy to make the changes. It will also mean 1 less task to do on future insim programs :).

EDIT: Tripple hug-tastic on the /lap command change Scawen, thank you lots :D.

malex2

21st March 2007, 18:57

Cue-Ball

21st March 2007, 19:14

I'm late to the party in posting this, and I'm not a developer, but I thought it would be relevant anyway.

I'd like to see a setting that shows what kind of transmission and clutch each user is using.

auto = 0
sequential = 1
shifter = 2

auto clutch = 0
button clutch = 1
axis clutch = 2

This would allow people to have the "hardcore" races that so many of us have asked for as we could eliminate people using auto clutch or sequential shifter when everyone else in the field is using axis clutch and h-shift. I'm hoping to put together a "G25 Cup" one of these days, and can't do it until I have a way to tell what controls are being used.

edit: Of course, it would be a lot easier for server admins to have these settings in the server itself, but if we at least had the info in InSim, someone could program an app for the server themselves.

Becky Rose

21st March 2007, 19:39

*thumbs up for adding h-shifter to the player flags* :)

can't the equivalent be achieved by sending an NPL InSimPack as a response to every SPX
Thank you, I will look into this - you may have spotted something I *should* have, but didn't :D.
EDIT: I've had a quick glance and it seems NPL is the player join packet, as far as I knew - and I may be wrong - it is not possible to request this packet. You get sent it when a player joins. Am I missing something?

St4Lk3R

21st March 2007, 19:53

@St4Lk3R: Now, I don't know much about InSim, but how is the car name consistent throughout a connection lifetime? How has the car anything to do with identifying a player at all? As far as I understand, Scawen wants to shorten the full car name ("RaceAbout") to the short prefix used for skins ("RAC"), thus saving a few bytes to make space for other flags in the packet.

Sorry if I'm talking complete rubbish here, your answer just seemed odd to me :tilt:

May really be that my answer IS complete rubbish. I just do not know what is meant by the term "skin prefix" so I guessed it's a unique prefix for every user. If I am mistaken, please correct me :)

malex2

21st March 2007, 19:58

*thumbs up for adding h-shifter to the player flags* :)

Thank you, I will look into this - you may have spotted something I *should* have, but didn't :D.
EDIT: I've had a quick glance and it seems NPL is the player join packet, as far as I knew - and I may be wrong - it is not possible to request this packet. You get sent it when a player joins. Am I missing something?

Line 692 of my InSim.txt says you can request it. In the manager I'm writing, I also request them when I connect to LFS, to get the current state.

\malex\

CLRS530

21st March 2007, 20:11

Becky Rose

21st March 2007, 20:50

My software is already adapted to work with both the current carname and the change :).
EDIT: Nearly finished adding all the new funky V3 features too - I just have no idea if they work ! lol

@malex2 - thank you :)

Scawen

21st March 2007, 23:45

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?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).

My software is already adapted to work with both the current carname and the change :).
EDIT: Nearly finished adding all the new funky V3 features too - I just have no idea if they work ! lolJust watch out when you see the new InSim.txt because some of the new packets from the last InSim.txt might change in size. For example I plan to make the new IS_PIT packet 4 bytes bigger so there is a Tyre Compound for each wheel.

Scawen

21st March 2007, 23:55

If I got you right, then the skin prefix should be something that is consistent all the time the racer is connected to the host or even consistent through the whole lifetime of the account. If it's like that, then I think it would be really REALLY useful to do the change, this makes life so much easier for developers :)No, as someone said the Skin Prefix is simply the short name for a car, e.g. XRT instead of XR GT TURBO

You do have something consistent and unique for the racer - the LFS user name (UName) is 100% unique and can't change. That is easiest when you run a host for licensed users. If you make a program to watch a demo host then you must use PName instead of UName - but yes that can change while the racer is connected - there is a notification though.

I was discussing this with Victor to understand the difficulty people have. I think InSim developers at first imagine managing a single list, with a unique identifier. They want something unique that applies to racers, as if a racer had a unique identifier the same as his connection. But that's not possible as some racers on a connection may be an AI. Also, a "player" can swap between connections, when you take over.

The only possible solution and what everyone must do for it to work correctly and mirror LFS, is manage two lists :

1) List of Connections, unique by UName (preferably) or PName
2) List of Players in Race (linked to a connection, and identified by UniqueID)

Becky Rose

22nd March 2007, 00:06

Just watch out when you see the new InSim.txt because some of the new packets from the last InSim.txt might change in size. For example I plan to make the new IS_PIT packet 4 bytes bigger so there is a Tyre Compound for each wheel.
No problemo Scawen, the main thing is that i've got the logic and actions that interpret the packet in place, changing which bytes on the stream correspond to which value is pretty easy with the way my code is structured. :) I just have to wait to find out if it works now, logically - it all 'appears' correct ... but we shall see.

CLRS530

22nd March 2007, 01:06

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 :thumb:

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

Scawen

22nd March 2007, 15:03

Just so you know, I can't do the shifter and axis clutch flags in this version as that change to player flags would put the versions out of sync. It is on my list for the multiplayer incompatible version.

I have managed to do most of the other requests, I think. But you will be the judges of that. I expect to post an updated InSim.txt here later today. The PIT (pit stop start) packet is only sent for V3 guests but is fully functional with todays changes (and does include the tyre compounds if they are changed). And yes, they are sent in the NPL as well.

Cue-Ball

22nd March 2007, 16:18

Just so you know, I can't do the shifter and axis clutch flags in this version as that change to player flags would put the versions out of sync. It is on my list for the multiplayer incompatible version.I'm bummed that they're not going to make it into V3, but completely understand. It's great just to know that it will happen eventually. Thank you. Thanks not only for listening to your customers, but for even going so far as to ask them what they need. Very few developers go to such lengths and it's so refreshing to see.

I'm really looking forward to V3, but I really can't wait to see what you guys have up your sleeves for the following patch.

Scawen

22nd March 2007, 20:53

Here are the updates so far. I'm getting very close to V3, which I'd like to release tomorrow.

You can see all the new packets by searching for NEW!

Changes are listed near the start of the file. Please let me know of any problems with them.

Take a good look at the FIN and RES packets as well, make sure the notes make sense.

[ EDIT : here's another update : http://www.lfsforum.net/showthread.php?p=368950#post368950 ]

CLRS530

22nd March 2007, 23:06

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 :) :)

Brilwing

23rd March 2007, 08:16

Thanks Scawen. Really great work :thumb:
Now I can even make better stats for the austrian championship :D

St4Lk3R

23rd March 2007, 09:35

got a bit of a problem with the pitstop flags. could someone explain them?

PSE_FR_DAM Front Right damage?
PSE_FR_WHL Front Right Wheel changed?
PSE_LE_FR_DAM What do LE and RE mean?
PSE_LE_FR_WHL
PSE_RI_FR_DAM
PSE_RI_FR_WHL
PSE_RE_DAM
PSE_RE_WHL
PSE_LE_RE_DAM
PSE_LE_RE_WHL
PSE_RI_RE_DAM
PSE_RI_RE_WHL

hackerx

23rd March 2007, 09:43

It's quite obviously FR = front, RE = rear, LE = left, RI = right.

St4Lk3R

23rd March 2007, 11:06

It's quite obviously FR = front, RE = rear, LE = left, RI = right.

you enlighted me^^ Thanks :)

Scawen

23rd March 2007, 13:07

1. The top line shows the wrong versionOK thanks. I've fixed that and also added some Pit Lane information in a new packet. See attached file.

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?Yes. Previously it showed 0, now it shows 255 (if it's a worse time and LFS will ignore it).

If a flag gone off, does in this packages flag shows the right color (from the flag wich was cleared).Yes, it should show yelllow off if you aren't sitting in a dangerous position any more, and blue off if you aren't obstructing a faster racer any more.

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.I would prefer not to add another timer. These flags will always come in pairs (on then off at a later time) so you can time it yourself.

Becky Rose

23rd March 2007, 13:14

A very useful data byte for the blue flag packet is which car is being obstructed, otherwise one blue flag could merge to another and the possibilities of having this data will be reduced.*

*EDIT: I cede it is possible to calculate which car via NPL/MCI - but that can be innacurate with the 8 cars per packet being overlapped or slightly out of sync. A timing issue which LFS doesnt need to worry about courtesy of its excellent timing correction data.

Scawen

23rd March 2007, 15:13

I agree that would be good. I've looked in the code and unfortunately cannot add that in a compatible version. So I've added it to my notes to look at that in a multiplayer incompatible version. At least there is space so that byte could be added in a compatible way to that InSim packet.

Becky Rose

23rd March 2007, 21:47

Small bug?: This may be my error, but as far as I can see the MCI packet is sending %11111111 11111111 for the finishLine() node on Fe1 and Bl1 where i've been testing. I dont know if this is for all tracks, but i've spent some time on this and I really dont see the error in anything i've done - although i'd quite happily accept i've had a blonde moment(s). :)

CLRS530

23rd March 2007, 22:06

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.

Scawen

23rd March 2007, 22:31

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.

Becky Rose

23rd March 2007, 22:52

Thank you Scawen, I will return to bashing my head against a brick wall to find the error in my code then :)

I spotted the RES FIN thing too and swapped it over, I guess i'll be swapping back again ;)

CLRS530

24th March 2007, 08:26

CLRS530

24th March 2007, 09:52

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

<?xml version="1.0" encoding="ISO-8859-1"?>
<LFSSSTATS output="1.50" program="1.60" readflags="0">
<HOST/>
<LFSVERSION>0.5V4</LFSVERSION>
<TRACK>
<TRACKNAME>KY1</TRACKNAME>
<TOTALLAPS>2</TOTALLAPS>
<WEATHER>0</WEATHER>
<WIND>0</WIND>
<QUALMINS>0</QUALMINS>
<PLAYERCOUNT>1</PLAYERCOUNT>
<SPLITCOUNT>1</SPLITCOUNT>
</TRACK>
<PLAYERS>
<PLAYER>
<NAME>CLRS530</NAME>
<UNAME/>
<STARTORDER>1</STARTORDER>
<LFSID>0</LFSID>
<CARNAME>BF1</CARNAME>
<TOTALTIME>00:02:26:38:00</TOTALTIME>
<OVERALLPOS>1</OVERALLPOS>
<BESTLAP>01:10:56:00</BESTLAP>
<BESTSPEED>28919</BESTSPEED>
<PLLAPCOUNT>2</PLLAPCOUNT>
<PITCOUNT>2</PITCOUNT>
<PENALTYFLAGS>2</PENALTYFLAGS>
<PLAYERFLAGS>4687</PLAYERFLAGS>
<LAPS>
<LAP>
<LAPNUMBER>1</LAPNUMBER>
<LAPPOSITION>1</LAPPOSITION>
<LAPTIME>01:15:82:00</LAPTIME>
<LAPSPEED>7019</LAPSPEED>
<SPLITS>
<SPLIT>
<SPLITPOSITION>1</SPLITPOSITION>
<SPLITTIME>00:18:38:00</SPLITTIME>
<SPLITSPEED>25790</SPLITSPEED>
</SPLIT>
</SPLITS>
</LAP>
<LAP>
<LAPNUMBER>2</LAPNUMBER>
<LAPPOSITION>1</LAPPOSITION>
<LAPTIME>01:10:56:00</LAPTIME>
<LAPSPEED>7018</LAPSPEED>
<SPLITS>
<SPLIT>
<SPLITPOSITION>1</SPLITPOSITION>
<SPLITTIME>00:19:18:00</SPLITTIME>
<SPLITSPEED>28127</SPLITSPEED>
</SPLIT>
</SPLITS>
</LAP>
<PITS>
<PITTIME>00:00:00:00</PITTIME>
<WORK>778</WORK>
<TYRES>
<FRONTLEFT>3</FRONTLEFT>
<FRONTRIGHT>3</FRONTRIGHT>
<REARLEFT>3</REARLEFT>
<REARRIGHT>3</REARRIGHT>
</TYRES>
<PITTIME>00:00:00:00</PITTIME>
<WORK>522</WORK>
<TYRES>
<FRONTLEFT>3</FRONTLEFT>
<FRONTRIGHT>3</FRONTRIGHT>
<REARLEFT>3</REARLEFT>
<REARRIGHT>3</REARRIGHT>
</TYRES>
</PITS>
</LAPS>
</PLAYER>
</PLAYERS>
</LFSSSTATS>

( 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 ;)

Scawen

24th March 2007, 11:47

Yes you are right. I am sorry, in my changes last night fixing the OOS bug, I forgot to update one line and so I broke the PSF send - and it sends a wrong PLA instead. I'm continuing to work today so should get a fix out quite soon. I'm not sure exactly when but please report any issues you find.

CLRS530

24th March 2007, 13:32

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 :thumb:

Scawen

24th March 2007, 14:40

Happy birthday! :)

CLRS530

26th March 2007, 12:43

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)

CLRS530

26th March 2007, 13:52

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

Scawen

26th March 2007, 14:22

That's because the internal flag packets already existed before V. But the PIT and TOC InSim Packets rely on new internal packets specially made for this purpose, and they don't exist in your replay because it was made with an old version. So... not a bug :)

CLRS530

26th March 2007, 15:00

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 :shrug:
But thanks for the information.

Scawen

26th March 2007, 16:49

Um, I thought you were saying that using a version U replay there was a problem. And yes, I would expect that, and no it's definitely not a bug, that packets that don't exist, are not reported. I have nothing planned to be fixed in any compatible patch, because I don't know of any InSim bugs.

Actually I would think that if you play an old replay, TOC would work but PIT and PLA definitely will not work.

But if you use a MPR made with V5 and with other V5 guests, then all the documented packets should work correctly, live or in replay.

CLRS530

26th March 2007, 16:56

:D I understood what you wrote. Yes it was a version U replay on a V5 client.
I only wrote the sentence because I thought that you didn´t change the replay format and in the replays made from V5 the packets are also not in (but later then in the incompatible version).
On the other hand I don´t know from where to get a replay with car take overs :P

axus

26th March 2007, 16:57

I know this would be way too much work (I think) for these patches but it would be nice if a live telemetry system could be coded, including the RAF data as well as tyre temps and whatever other information you feel is realistic to supply in real time. Combined with some way to change strategy from an external program, I imagine this will put big smiles on the enduro guys' faces. :) As I say though this is more of a "one day when there's time to polish off things more" thing I think.

Scawen

26th March 2007, 17:25

Here is a replay with a pit and a take over. Hopefully it should produce PIT and TOC packets, and the enter and exit information as well.

geeman1

26th March 2007, 17:52

I don't know if this is intentional or a bug, but OutGauge isn't sending the shiftlight info when the shiftlight is switched OFF in game. I would like to switch the ingame shiftlight off and use an external light instead.

CLRS530

26th March 2007, 18:02

Haha thanks Scawen, works good, but yes I will try a longer one for myselv.
For you important everything is right

Tyres in NPL (only 2 because you can´t select each tyre)

<TYRES>
<FRONT>5</FRONT>
<REAR>5</REAR>
</TYRES>

Flags (I realized that you fast get those yellow flags if you brake heavy...)

<YELLOWFLAGS>1</YELLOWFLAGS>
<BLUEFLAGS>0</BLUEFLAGS>

Playerflag (works well in your example there is only the first one. So here mine

<PLAYERFLAGS>
<PLAYERFLAG>
<PFLAPNUMBER>1</PFLAPNUMBER>
<CONTROLERFLAGS>4687</CONTROLERFLAGS>
</PLAYERFLAG>
<PLAYERFLAG>
<PFLAPNUMBER>2</PFLAPNUMBER>
<CONTROLERFLAGS>4623</CONTROLERFLAGS>
</PLAYERFLAG>
<PLAYERFLAG>
<PFLAPNUMBER>2</PFLAPNUMBER>
<CONTROLERFLAGS>4679</CONTROLERFLAGS>
</PLAYERFLAG>
<PLAYERFLAG>
<PFLAPNUMBER>2</PFLAPNUMBER>
<CONTROLERFLAGS>4687</CONTROLERFLAGS>
</PLAYERFLAG>
</PLAYERFLAGS>

Takeover

<TAKEOVERS>
<TAKEOVER>
<TAKEOVERLAPNUMBER>1</TAKEOVERLAPNUMBER>
<NAME>Scawen2</NAME>
<UNAME>scawen</UNAME>
<DISCONNECTED>0</DISCONNECTED> //is 1 if its a selv detection with a disconnect
</TAKEOVER>
</TAKEOVERS>

Number the last Penalties again from my test

<PENALTIES>
<PENALTY>
<PENALTYLAPNUMBER>2</PENALTYLAPNUMBER>
<VALUE>5</VALUE>
</PENALTY>
<PENALTY>
<PENALTYLAPNUMBER>2</PENALTYLAPNUMBER>
<VALUE>6</VALUE>
</PENALTY>
</PENALTIES>

Oh number more then last :P Pit

<PITS>
<PIT>
<PITLAPNUMBER>1</PITLAPNUMBER>
<PITTIME>00:04:32:00</PITTIME>
<WORK>131074</WORK>
<TYRES>
<FRONTLEFT>255</FRONTLEFT>
<FRONTRIGHT>255</FRONTRIGHT>
<REARLEFT>255</REARLEFT>
<REARRIGHT>255</REARRIGHT>
</TYRES>
</PIT>
</PITS>

Cue-Ball

26th March 2007, 18:25

Haha thanks Scawen, works good, but yes I will try a longer one for myselv.
For you important everything is right

Tyres in NPL (only 2 because you can´t select each tyre)Hopefully that won't be the case in the future. Being able to change each tire individually has been requested many times, so I can foresee this changing in InSim too, eventually.

I'm not sure if/how changing the tires on one side or the other would affect your app either. Not sure if you need to take this into consideration or not.

CLRS530

26th March 2007, 18:27

Thanks for that, I thought about and if you write this I will change to the same then in pit because it could happen there yet.

The only affect would be, that you have the left front for both front and the left right for both right.

CLRS530

26th March 2007, 19:59

Yeah :)

a new export with 3 take overs and I played a bit with penalties from drive through to stop and go, then abort the stop for stop and go and cleaned it.
Everything well, nice job Scawen

stats_070326_2130_BL1_race10.xml (http://www.packer-online.de/stats_070326_2130_BL1_race10.xml)

I forgot one thing, whats with a package on the reset event? or a counter into the result.
Nice for statistic and also nice for limiting in a league.
Also I wondered why the host name isn´t inside the replay, could that be done?

MoHaX

11th April 2007, 17:30

Is it possible to make common players able to issue command which will be visible only to insim? Something like "/mso <command>" but for all players, not only for host

MonkOnHotTinRoof

11th April 2007, 18:26

Is it possible to make common players able to issue command which will be visible only to insim? Something like "/mso <command>" but for all players, not only for host

I think there is /out command, but it's quite useless because you can't get who posted it...

Scawen

11th April 2007, 22:02

Dygear

14th April 2007, 12:52

Maybe a /i command?

So you could type /i xxx on the guest, and this would make the host send out an InSim packet with your user name and the text xxx. Other than that InSim packet, it would be invisible.

The letter i is for InSim or info - seems to be the best letter, unless someone has a better idea. :)

I love it, I've been waiting for this for a very long time. It would allow for and tiered admin system where the InSim program would decide who get's what prefs. It would make me VERY happy to see this implemented.

/i login [username] [password] ; Or you could have the InSim Program log them in automatically (depends on the setup of the system really, say you happen to have a system where only the highest ranked admin can do things like change map, ban players, and change cars. other admins can only kick, it's a great way to test the more immature admins what's what.).

/i logout ; Logs that user out of top admin.

/i whisper [target] [message] ; Sends the target's UName or PName (With or Without Color Codes) the message that only that target can see. Ex. I want to send a message to (EAGLE)Thunderchild with the UName thunderchild telling him to look at this guy on track, he might be a wrecker. I could do "/i whisper thunderchild Check out the guy in last place I think he's sitting on the track."

Oh man, the things it allows for are mind blowing!

Scawen

14th April 2007, 13:14

I love it, I've been waiting for this for a very long time. It would allow for and tiered admin system where the InSim program would decide who get's what prefs. It would make me VERY happy to see this implemented.You are happy then because it's done :) I'll be posting here soon, the InSim updates.

/i login [username] [password] ; Or you could have the InSim Program log them in automatically (depends on the setup of the system really...Yes, better do it automatically, or you are opening a danger there - what if your admin did a small typo, like leaving out the slash - then everyone would see the message!

Scawen

14th April 2007, 13:43

OK, I've updated the InSim file for the multiplayer incompatible test version which I hope to release today in the test patch forum. InSim.txt is attached. Here are also some parts of the change log which are relevant to some InSim developers.

----- some changes -----

Implemented the canreset option while leaving hotlaps valid
Increased number of cars in race from 20 to 28
Increased number of connections from 24 to 48
Single player and demo races now up to 16 cars
Removed the need to pass a split after receiving admin penalty
Start grid remains when track or config changes (if possible)
More commands now work on AI drivers : /spec /pitlane /p_xxx
More commands work even if player joining e.g. /spec /laps
Grid reordering is now done on end race as well as restart
New /i command to send a message to a race control program
More race tracking info added to InSim (see InSim.txt)
Admins can now see other admins in list of connections
Admins can now edit and /axsave layouts while online
Race penalty can now be removed with /p_clear command
Send all players to their pits with /pit_all command

[ EDIT : Just updated the InSim.txt - Victor pointed out the /i packet used a duplicate header ]

Dygear

14th April 2007, 13:56

You are happy then because it's done :) I'll be posting here soon, the InSim updates.

Yes, better do it automatically, or you are opening a danger there - what if your admin did a small typo, like leaving out the slash - then everyone would see the message!

Very good point.

So, /i login and /i logout. No password needed, it would only check the UName of the client and that would be the only auth it needed to allow for login.

YESSSSSSSSSSSSSSSSSS!
Increased number of cars in race from 20 to 28
Increased number of connections from 24 to 48

Love that, love it, love it!

Leifde

14th April 2007, 14:12

48 connections, 28 racers :trampolin

And also the /spec, etc. commands work on AI :)

icyocean

14th April 2007, 14:13

is it possible to allow race admin control the grid order before a race starts, maybe through insim? for example a flag can be set by the admin to disable player joining etc. and then appoint grid position to each player.

ideally a race admin can do this through a insim tool, as well as in the race setup screen.

imho this would open up possibilities for custom grid arrangements (for example in league races which consist of more than one starts). so it'd be good to see it implemented, if it's not too much trouble. :)

Scawen

14th April 2007, 14:23

Can an AI be added while online? (Not in setup screen)
Yes, I made it so it works in game, not only in entry screen. :)

Scawen

14th April 2007, 14:25

CLRS530

14th April 2007, 14:45

Hey Scawen just a short question wich I´m not totally sure of.
I think if you take over a car and have anothother player flag the new playerflags will be used by that driver (sure) but no IS_PFL will be sent.
I´m not 100% sure of it because I didn´t test it a second time.

Scawen

14th April 2007, 15:02

Ok, you mean FLG not PFL.

Anyway I've checked the code and in this new version which tells you the obstructed car, it should send a new FLG if the obstructed car changes.

CLRS530

14th April 2007, 15:22

No I mean a takeover in the pit ;)
If the no player has different settings and a different playerflag the IS_PFL should be sent (and I think it currently don´t do)

Scawen

14th April 2007, 18:58

OK, you'll need to check that in W9. I've looked in the code and it appears that it should work correctly (it does check flags at the moment of take over).

Dygear

15th April 2007, 15:56

Is there a way we could get a packet so we could put a message here (shown in red) via an InSim packet, and an forward slash command?

Commands

Race Control Messages
/rcm [message] // Message To Send
/rcm_ply [uname or pname] // Name to send the message to.
/rcm_all // Sends the message to all users.
/rcc_ply [uname or pname] // Clears the message from that user.
/rcc_all // Clears the message from all users.

Race Control Sub Messages
/rsm [message] // Message To Send
/rsm_ply [uname or pname] // Name to send the message to.
/rsm_all // Sends the message to all users.
/rsc_ply [uname or pname] // Clears the message from that user.
/rsc_all // Clears the message from all users.

InSim Packets: (Sent to the server over an InSim Connection)
struct RaceControlMessage // UDP packet to send a Race Control Message.
{
char RCM [4]; // RCM + zero
char Msg [32]; // Message.
byte Sec; // Seconds the message will last for.
};
struct RaceSubMessage // UDP packet to send a Race Control Sub Message.
{
char RSM [4]; // RSM + zero
char Msg [32]; // Message.
byte Sec; // Seconds the message will last for.
};

MoHaX

15th April 2007, 20:24

Even more, it would be nice if there be the way to display custom table (2-3 columns, 1-10 rows should be enough) on the left side of screen (under chat) via insim. Just like /rcm - prepares the message, /rcm_ply shows it.

And it would be really fantastic if cells of that table will be clickable and we can catch that clicks via insim also.

Dygear

16th April 2007, 00:04

GeForz

16th April 2007, 10:55

What would be the purpose of that table?

A Trackvote?

MoHaX

16th April 2007, 12:00

What would be the purpose of that table?

A Trackvote?

advanced permament statistics for player and closest opponents, advanced voting (wind, number of laps etc, kicking/banning), admin menu, debug pannel for developers of insim app, list of current track records in history, menu for current race organizators to select mode (drifting tournament, drag tournament, stunt tournament, classic race, race with many stages and complicated start order calculation etc.) and options for current mode, just menu for players to individually enable/disable some notifications, select current language of notifications etc.

Just give us that table and it became possible to write amazing feature-rich intercative insim applications.

Scawen

17th April 2007, 08:41

That is a nice idea - though I wouldn't make it a table, I'd make it buttons you could add, at the position you like, with parameters, something like :

struct Button
{
byte click_id; // button identifier for click packet
byte for_connection; // send to this connection id
byte style; // with button / centred text / etc...
byte spare;
byte l, t, r, b; // left, top, right, bottom
char text[64]; // button text
};

struct BClick
{
byte click_id;
byte from_connection;
byte sp2;
byte sp3;
};

Scawen

17th April 2007, 08:45

The request for the clickable interface constructed by InSim programs has got me thinking now, the current UDP based insim system and guaranteed delivery system is too clumsy and starting to result in too many packets flying around, and has a major drawback that the guaranteed delivery does not guarantee order. Also there is a well known problem that connections must be identified by user name comparisons, instead of a unique connection identifier assigned when the user connects - that is ok for licensed hosts but doesn't work on demo hosts where changing player name must be used instead, and doesn't help our insim programmers testing on a local network. So I'm thinking that a major overhaul is required, including a change to TCP instead of UDP, and using connection ID, not user name in packets that refer to a user.

All InSim packets would start with a consistent three bytes, specifying the size, the packet type and an optional request id (useful for individual clients making a request through an insim relay). Then a minimum of one data byte. For example :

struct IS_NCN // new connection
{
byte size; // 56
byte id; // packet identifier, from an enum (e.g. 28)
byte request_id; // zero unless this was sent in response to a request
byte conn_id; // unique identifier of new connection

char UName [24]; // username
char PName [24]; // nickname

byte Admin; // user is admin
byte TotalConns; // number of connections on host, including host
byte Sp2;
byte Sp3;
};

struct IS_CNL // conn leave
{
byte size; // 4
byte id; // packet identifier, from an enum (e.g. 29)
byte request_id; // not used for this packet - zero
byte conn_id; // unique identifier of leaving connection
};

So what do you think? I might leave some packets UDP based - the time based ones that report car positions, just like in LFS, if you miss one of those, you just want the next one, you don't want TCP tripping over itself trying to correct that kind of data.

Becky Rose

17th April 2007, 09:18

I loathe the thought of recoding everything to TCP now i've got such comprehensive software in place, such a total overhaul is a lot of work. *grumble moan!* :), but i'll do it.

There are some things that make sense to be TCP (SPX/LAP/MSO), and some things that make sense to be UDP (MCI).

Have you considered splitting insim down into more sub-systems like Outguage? The end-user uses one /insim 49999 port, but the software that connects then requests: Outguage; Messaging; Race Tracking; Car Tracking (MCI) etc on separate ports?

Dygear

17th April 2007, 09:20

Can you elaborate on request_id? What it is meant for.

Scawen

17th April 2007, 09:47

Can you elaborate on request_id? What it is meant for.First thing to say - it's totally optional - just provided for your convenience, if required, or if you want your software to make requests to an LFS host through a relay system.

Request ID is like, if you connected to the InSim relay server, Victor's program would send you a unique id on connection. Then, if you sent one of the packets that requests some info, like "send me a list of all connections", your program or the relay would insert your request_id into the request packet.

From LFS's viewpoint it's just an optional user defined packet identifier - whenever it gets such a request packet, it fills in your request id into the reply packet(s) and sends it back. Then Victor's relay program, for example, can direct the relayed packet to the required guest (instead of sending the requested packet to ALL connected clients as it does now). It also distinguishes between a new connection packet, and info about a connection requested by a connected InSim client. Basically use it for what you want, LFS just takes it and puts in into the requested packet(s).

So, request_id is always non-zero in a request packet. If request id in any outgoing packet is zero then it goes to all guests, if non-zero then it goes to the appropriate guest. It's just a simply way for LFS to support a single connection with multiple clients (e.g. Victor's InSim relay system which a lot of people use).

One thing that also occurred to me is that the TCP method, because it is connection oriented, would also make it easier to support multiple InSim clients on one host without using the relay system.

Scawen

17th April 2007, 10:00

I loathe the thought of recoding everything to TCP now i've got such comprehensive software in place, such a total overhaul is a lot of work. *grumble moan!* :), but i'll do it.I suppose one option is to allow UDP as well - but without the guaranteed delivery system. That's ok on a local network where there is not usually any UDP packet loss anyway. But I'd have to unify the packets - i.e. use the same packets for the UDP and TCP versions - I can't support the whole old system and the new version as well. I think it would be easy to adapt your software that way, just using the slightly modified packet structures, and using connection unique id instead of "user name" to track things.

the_angry_angel

17th April 2007, 10:42

I suppose one option is to allow UDP as well - but without the guaranteed delivery system. That's ok on a local network where there is not usually any UDP packet loss anyway. But I'd have to unify the packets - i.e. use the same packets for the UDP and TCP versions - I can't support the whole old system and the new version as well. I think it would be easy to adapt your software that way, just using the slightly modified packet structures, and using connection unique id instead of "user name" to track things.Assuming connection id stays unique, aside from a little hesitance over the prospect of moving from the current packet structure to a bstrings-style of packets, I actually really like the idea and fully embrace it :)

Scawen

17th April 2007, 10:55

Connection ID is unique yes, from when there is a new connection, until that connection disconnects, but note that it is different from player's unique id (as player can be AI or can swap between connections, in the case of a driver swap). The connection unique ids are also conveniently unique with (i.e. never shared with) the player id's because they are assigned from the same pool.

I don't know what bstrings are but anyway, once your TCP packet receive function is in place (to make sure you have a whole packet from the stream before processing it) it should be easy because every packet is marked with a size and you don't need to know if you should or should not reply with an acknowledgement - you never do - another of the disadvantages of the old system, people's InSim programs were never forward compatible if I added any packets.

Becky Rose

17th April 2007, 11:29

Relays too eh, i'm going to have to think up a load of new features to stay ahead of the things you are implementing :). Except that for now, I think I will stop all development until Insim has finished changing direction.

On TCP:
I've had problems in the past where the content of two bytes within a packet matches the HTML EOL marker when using TCP over the net (when it tested fine locally).

I can't say i'm keen on TCP as an extra 30 odd bytes or so on the packet header is a considerable ramp up in my bandwidth when I open the new server and run LFS servlets on each one, talking to one central program.

Having said that, TCP makes sense for MSO packets when dealing with a remote server, as the messages should appear in the right order, and it's reliability makes sense for race tracking.

However I'd certainly be happier if MCI data was available via UDP rather than TCP, just for the bandwidth saving alone - even if I did everything else with TCP.

Dygear

17th April 2007, 11:38

I don't think that UIds should change at all. In the current version of InSim you have it changing for no apparent rhyme or reason. Once that person get's that UId it should be theirs for the life of the server instance. So for example if they should come back 2 weeks later and the server is still running with that same Instance they should get their old UId back.

CLRS530

17th April 2007, 12:05

Whats with a method some or all ego- shooter games I know use (Enemy Territory for example). It has a guid wich is stored locally and have to be saved also on the master server that it don´t has two the same.
If you delete the local file LFS has to send a new one and maybe can delete not used ids after half a year and send a new one for a user who tries to connect with a id wich isn´t availible.

It´s just a short idea from me and I didn´t think in any direction over that problem but the new system should be much easier to use for everyone then the one we have now.

The id could also be a sha key from the username wich makes it unique. The only problem wich have to be managed is that demo racers don´t have such a user name.
Maybe a system to see them with there physical address

Becky Rose

17th April 2007, 12:11

You know, the more I think about the RequestID the more I wonder why you dont just have LFS handle more than one insim port?

Different software requires different packet data, for example LFSW might want MCI packets at one rate, and my 'traffic approaching' at another rate, with the current relaying system it's not possible to specify. With my relay system I adjust the MCI rate when LFSW connects to my management software, but wouldn't it be better to have LFSW just connect directly to LFS and have it's own ISI/ISC connection.

Currently there exists an incompatibility with relay systems where some of LFS' mutually exclusive packet types are used like MSO and the other one (I forget it's name, i've not used it).

In terms of bandwidth on the server it would make no difference to me as the relay sits on the same server, and I dont think many other people currently have a relay on their server anyway although I know i've been asked how to use LFSC for such a purpose (even though its not really designed for the job!).

If LFS supported multiple INSIM connections then we could do away with all the relays for using multiple insim applications.

Certainly those using the LFS clientside software would appreciate this, and a few people who've wanted to run multiple INSIM applications on their server would then be able too.

tbh the LFSW relay is a little impracticle at the moment as it cuts the connection too quickly when the server is lost, the 15th reconnection should really be 24hrs after connection is lost. Also it's maximum 'spectator' capacity could prove an issue for some events, such as the 24 hour race being organised for April. This 'unknown' factor invalidates the system. That and the custom packets mean software has to be written especially for it, and nobody does that.

MoHaX

17th April 2007, 12:27

Also there is a well known problem that connections must be identified by user name comparisons, instead of a unique connection identifier assigned when the user connects - that is ok for licensed hosts but doesn't work on demo hosts where changing player name must be used instead
Personally, I don't see any problem with changable usernames tracking. My software use it without any problems. If player changes name it means that another man takes place in front of computer, it really mean that player is changed and insim software should re-run routines same as if old player disconnects (free used memory, dump his stats for permament storage etc) and new player connects. To be clear, I don't see any reason to start so big job of rewriting InSim.

There is only one problem - team names. While player nickname is same , teamname changes from time to time, so it would be nice if in user profile there be a new field TeamName same as new field in some insim packets

Scawen

17th April 2007, 12:31

You know, the more I think about the RequestID the more I wonder why you dont just have LFS handle more than one insim port?You must have missed it up there where I did say that moving to TCP would allow multiple InSim connections to one instance of LFS.

If LFS supported multiple INSIM connections then we could do away with all the relays for using multiple insim applications.No, it wouldn't remove the need for a relay - it would remove *some* of the needs for the relay - don't forget the relay allows 100s of people to connect because it's on our webserver which can provide traffic that would bring down an LFS host dealing with som many connections.

Im talking one one hand about making LFS support multiple InSim instances, and on the other hand by this extremely simple request ID also allowing far better relay support than we have now (one client's request doesn't swamp all other clients with unwanted and unexpected packets).

MoHaX

17th April 2007, 12:39

struct IS_NCN // new connection
{
...
byte conn_id; // unique identifier of new connection
....
};

What is the difference from current "byte ConnNum; // new conn's number (0 = host, 1, 2...)" ?

Scawen

17th April 2007, 12:47

Well the ConnNum is quite useless because it's just the array index, when someone leaves, the end connection moves down into that ones slot, so now it has a new ConnNum (the same as the player who left). ConnNum is totally useless unless you maintain your connection lists exactly the same way as LFS does (and that's not very good without guaranteed packet order) The UniqueID will stay the same while that connection is there.

PlyNum and ConnNum are something to get rid of in the rewrite, just use ConnectionUniqueID and PlayerUniqueID.

I don't think it's that big a rewrite, it's about a day's work I guess for me to restructure (shrink) the packets, remove UName and PName where they aren't needed, where only one byte ConnectionID is needed.

It's just be a much cleaner and more streamlined system, allowing for future expansion, the addition of small packets which don't need this constant verifying procedure, etc. Unique ID for connections is an old request but couldn't be added easily due to compatibility. But it's not good everyone having to work around ropey old InSim's issues, better just get it right so we can move forward easilty in future - that's my opinion anyway.

Becky Rose

17th April 2007, 12:47

You must have missed it up there where I did say that moving to TCP would allow multiple InSim connections to one instance of LFS.
You are right, I did miss it.

Scawen 1 Becky 0

:D

filur

17th April 2007, 12:55

I'd love this update.

Brilwing

17th April 2007, 13:17

The idea with the buttons is great. I'm was also playing around lately to add a simple interface via insim to send race control messages for admins.
For this it would be create to have a textfield.
I think it would be enough if the chat input window is shown after a button is pressed, and the entered text is also transmitted with the button infos.

Dygear

18th April 2007, 08:39

Yeah, this is going to be massive for the Live For Speed modding Community. All like 7 of us.

Becky Rose

20th April 2007, 11:30

Scawen, I have some concerns over the release of insim v2, in that it will break my server management system. I'm most keen to have made the changes to the software before the patch moves from test to public so i'm ready for the udpate.

With everything else [LFS related] that I do it might be hard to fit in around your schedule, so would it be possible to give us some rough indication of when we'll get the test patch with this insim functionality and how long you'll from there 'very roughly' until it goes final.

I think for me, because i'm a bodge jobber at the best of times, and because of the size of my system, it might not be quick and easy to do this change.

If I can plan ahead I would be very grateful.

After some initial fear i'm actually rather excited to get my hands on it. I am such a nerd! No wonder i'm single.

Brilwing

20th April 2007, 11:58

The current plan is to release patch X in one or two weeks, depending how it goes. Two weeks might be a better or more realistic option because it'll probably take a week just to get the remaining updates finished - nothing really big or interesting for most people, but includes an updated InSim system (which is hopefully only 1 or 2 days' work) and some other compatible and incompatible things on my list of varying importance, and some bugs reported here. I guess we should really have a week of stable testing after the changes are implemented, so that we know version X will be bug free.

found here: http://www.lfsforum.net/showthread.php?p=397415#post397415

I have a similar problem, because I have to update my tools to manage the austrian championship. This time I'm lucky, because the last race is before patch X is released, when the schedule is right. :D

A nice feature would be that we can tell LFS which InSim version we want, so that with Patch X also old tools can work.
One other solution could be that multible LFS versions are supported. e.g. in the LFS directory a LFS_W.exe and a LFS_X.exe is located, and when the user connects to a server that runs the W version the LFS_W.exe is started, and vice versa.
But this would only make sense if the InSim changes constantly.

Dygear

21st April 2007, 01:05

After some initial fear i'm actually rather excited to get my hands on it. I am such a nerd! No wonder i'm single.

Tis the curse of the nerd, we are meant to be single.

Scawen

21st April 2007, 16:38

I hope to release X on friday or saturday in just under two weeks time, though that depends how everything goes.

I've been on the case with the InSim updates the last two days and I think I am at a point where all the packets are converted and I've done a brief test - but the new button response system is not done and it still only works in UDP.

I'm considering giving it to you as it is right now, or some time this evening, so you can already start to convert your software to the new system. You would have to change your packet send and receive functions to TCP after that - but that's probably not a bad way to upgrade. I do want the day off tomorrow so it'll have to be this evening if it will be this weekend.

I've put a lot of documentation in this attached header file which replaces InSim.txt - if you can set your tab spacing to 4 spaces the file will be a lot easier to read. It's actually a .h file but I've renamed it to .txt so I can upload it here.

Please have a read through it and see if you spot any problems, or if anything is confusing before I release the first version to you (if you want it in this unfinished state - which is already as better than the old system except it has no packet guarantee system).

Becky Rose

21st April 2007, 17:14

Being slightly uneducated I mostly go by feel, but the docs look ok from what I can see.

I see no reference to outguage in this document (maybe I is fick :) ), I dont use it for my stuff but when I did do an outguage application the lack of a header was frustrating (length wasnt unique) so that's worth considering but otherwise yes, go for it and i'll start rewritting my manager tonight and tomorrow and giving the new insim a real going over.

Becky Rose

21st April 2007, 17:16

Just one other request actually Scawen, if I may.

The new /i command is brilliant, but because i'm using it for PM's and channels (live on STCC2b already! - i'm such an addict) I end up having to get people to type two headers...

/i talk user message

It would be great if I could abbreviate this to $talk user message

Is it possible that the config file could specify a non-echo prefix, like:

/noecho=$

would make any message starting with $ non-echoed?

It would make the whole system a little less cumbersome for my end users if that is possible :)

Thank you.

MoHaX

21st April 2007, 17:21

If you remove PlyNum field, how is it possible to get start order of players?

Cue-Ball

21st April 2007, 17:25

Will "shifter type" and "clutch type" fields be added in patch X, since the whole InSim system is being redone, or will that be added later? I know that several of us are looking forward to this, and thought now might be the time to do it since you're revamping.

Scawen

21st April 2007, 17:37

If you remove PlyNum field, how is it possible to get start order of players?Good question. Normally it comes from the REO packet, but that is only on a restart, I think, when it is actually reordered, not when you first come in from the entry screen. I think the solution is for LFS to send a REO on every race start, even if no reordering takes place.

Will "shifter type" and "clutch type" fields be added in patch X, since the whole InSim system is being redone, or will that be added later? I know that several of us are looking forward to this, and thought now might be the time to do it since you're revamping.That was already added to the player flags in W9.

MoHaX

21st April 2007, 17:42

Good question. Normally it comes from the REO packet, but that is only on a restart, I think, when it is actually reordered, not when you first come in from the entry screen. I think the solution is for LFS to send a REO on every race start, even if no reordering takes place.

That was already added to the player flags in W9.

And small bugreport. If I swap places with bot in track selection screen no reordered packet is arrives, but plyNum fields are changed.

Cue-Ball

21st April 2007, 17:56

That was already added to the player flags in W9.How the heck did I miss that?

Great to hear! Looks like now I have to get off my butt and work on that league I've been talking about so long. Thanks! :bowdown:

Scawen

21st April 2007, 18:18

OK, here is the first test of the new InSim which uses a unique identifier UCID for connections (still different from the player unique identifier PLID). This allows many of the packets to be more compact, and you don't need to track things through the User Name. Your programs will work on LAN and Demo as well as online S1 / S2 - and that helps tsting and development.

This rewrite is designed to be suitable for TCP packets (needing a size byte at the start of every packet). Currently it only works on UDP, because I haven't got to the TCP listen and send yet - but if you update your programs to use this new version, then when the TCP is done you'll only need to change your connect, send and receive functions. This current converted version should do all the old version could do, but without the acknowledgment packets and guaranteed delivery system. That is scrapped now, we'll use TCP for guaranteed delivery.

By the way, I've also just changed it so the IS_REO is sent at the start of every race. It specifies the order every time, regardless of whether it was re-ordered or not.

DOWNLOAD : EXE and DEDI (to be used in an already patch W10 folder)
[ EDIT : link to W11 removed, as W12 is now available ]
http://www.lfsforum.net/showthread.php?p=400729#post400729

NOTE 1 : This is 100% compatible with W10 and there are NO OTHER CHANGES - so don't get this unless you are testing InSim.

NOTE 2 : The InSim buttons and response functions have not been done yet, although they are a large part of the inspiration for the move to TCP.

NOTE 3 : ISPackets.txt is attached, this includes all documentation and is actually a C++ header file (.h) renamed to .txt so I could attach it. Please read with a TAB size of 4.

NOTE 4 : This is mainly untested though I did connect with a test program and start sending a few packets, so I know that it does basically work, I just can't say for sure that all packets are working 100%.

GOOD LUCK :) And let me know about any problems you have come across.

Becky Rose

21st April 2007, 21:03

@Scawen, how far away are we from the TCP version please?

Scawen

22nd April 2007, 06:28

I'm going to try and quickly do it this morning before I have my day off.
Should be ok, it's mostly a bit of cut and paste from some other code.
I'll need to do it in my test program as well so give me a few hours.

mcintyrej

22nd April 2007, 09:30

Becky Rose

22nd April 2007, 10:03

hehe Scawen, I know those days off only too well. I had one Friday, was trying to get home and the boss was phoning me! Then I spent all night coding my LFS Private Messaging system, and woke up Saturday morning and did the channels... I took yesterday off whilst you updated insim :)

Scawen

22nd April 2007, 11:09

All right, done and briefly tested, here is the version which can accept TCP.

It's the same as yesterday's version except that it allows you to connect using TCP. It obviously replies to you on that same socket using TCP, if you connect via TCP. The Port member of the IS_ISI (InSimInit) packet is ignored in that case (unless you start OutGauge or OutSim). I plan to allow NLP and MCI to be sent over UDP even if you connect via TCP - but that is not implemented yet, in this version they'll come over whatever protocol you connected with, just like all the other packets.

[ EDIT : link to W12 removed, as W13 is now available ]
http://www.lfsforum.net/showthread.php?p=401002#post401002

For anyone who is not familiar with TCP programming, or have not used it to receive "packets" before, please remember it is a STREAM - you do not get exactly one packet, for every "recv" like you do with UDP. Even though it might seem like you do for a while - do not trust that! You might get two packets in one "recv" or you may get half a packet, while the other half comes along in the next call to "recv". The way to deal with this is to store your received info in a buffer, adding on to the end whatever you receive, and don't process the first part of the buffer unless there is a complete packet there (i.e. you've already read at least as many bytes as the first byte in the buffer - packet size). Then after reading that packet you can shunt down your buffer and carry on (i.e. read the next packet if there is a complete one, or do a recv if there is data there, etc...)

Becky Rose

22nd April 2007, 11:41

Thank you Scawen, it's much appreciated that you did this on your day off because it means I can really get going now - I was a bit hesitant to have rewritten SRA with UDP and migrated.

It's been a long time since I did any TCP programming, so if anyone needs me i'll be in that dimly lit closet over there...

*dissapears into darkness with a cup of coffee*

Becky Rose

22nd April 2007, 12:38

I've removed this post because I was asking a technical question on a problem I had - only to realise I had been a complete idiot and spotted my problem.

I would like to thank all those who don't ever talk about this ever again ;) !

Aquilifer

22nd April 2007, 13:30

Few questions...

1. (from ISPackets.txt)
"// The regular packets IS_NLP and IS_MCI are the only exceptionss - not sent via TCP."

So I need to listen UDP too? I have to implement TCP communication, but still listen UDP too? :really:

2. Is this decided that TCP is the future and UDP is abandoned in the (near?) future? (if so, what about IS_NLP and IS_MCI then?)

TIA

Becky Rose

22nd April 2007, 14:21

W12 Bug: Restarting via shirt-r or /restart command puts the server into qualifying mode even if /qual=0. Host type, client based 'start new game'.

Aquilifer

22nd April 2007, 14:25

Basically I have same questions as Aquilifier (I don't see any point in having 2 types of communication - gateway, anyone? :schwitz: ), and in addition:
1.UDP no long works in W12, specification says connection will work with protocol started...
2./i command yields unknown command, am I missing something here?

@Becky: you can delete post, it's easier than editing it, and write it's deleted :D

This post will self-remove in few hours to reduce spam (and decrease my posts again :()

To your two points. I haven't tried W12 with insim yet, because I haven't done anything to my insim prog yet.

Your point 2. I got that answer when I tryed the /i command when there was no insim prog running in the same computer (non dedi server). But worked as soon as I run insim program (W10). It's bit misleading and it should say no insim prog running. I didn't try how it works if you type it in a guest computer.

Like Monk said I don't like the idea of having both TCP and UDP either (at the same time). If somebody didn't get it from my 1st post. It is good that UDP is kept at least in the beginning but it's just confusing need to have both running at the same time.

GeForz

22nd April 2007, 14:39

There is a Bug in W11 and W12.

Shift+R starts Qualification - not Race
Tested in single/multiplayer

btw: http://www.lfsforum.net/showthread.php?t=23135 ;)

Becky Rose

22nd April 2007, 15:06

I regard UDP + TCP simulatenously as essential. Imagine my position, before the year is out i'll have over a dozen LFS server applets all talking to 1 central control program from 2 dedicated boxes. TCP data being reliable is great, but the packet header is around 30 bytes larger, so for MCI data UDP is by far the better choice. I'm sure Scawen will make it optional, when he does I for one will be very thankful :), so please - dont complain it out of existence :) *hug*

Scawen

22nd April 2007, 15:53

1. (from ISPackets.txt)
"// The regular packets IS_NLP and IS_MCI are the only exceptionss - not sent via TCP."

So I need to listen UDP too? I have to implement TCP communication, but still listen UDP too? :really:

2. Is this decided that TCP is the future and UDP is abandoned in the (near?) future? (if so, what about IS_NLP and IS_MCI then?)
1) No, that is wrong in the documentation. It will be your choice, you can have NLP and MCI by TCP or UDP. For many applications if the InSim program is on a different computer, it's best to have them sent by UDP because they are regular, and not vital, so you save bandwidth - you do not need guaranteed delivery, just like car pos packets in LFS, if you miss one, you just want the next one, you don't want to know what the car's position was some time ago.

2) There are 3 ways to do race tracking :

a) UDP for all
b) TCP for all except NLP and MCI
c) TCP for all

I've updated the document and attached it here.

Basically I have same questions as Aquilifier (I don't see any point in having 2 types of communication - gateway, anyone? :schwitz: ), and in addition:
1.UDP no long works in W12, specification says connection will work with protocol started...
2./i command yields unknown command, am I missing something here
1) UDP and TCP seem to work just fine, but you must use the new packets.

2) /i only works if you have InSim connected to the host, otherwise it's an unknown command.

W12 Bug: Restarting via shirt-r or /restart command puts the server into qualifying mode even if /qual=0. Host type, client based 'start new game'.OK, fixed here in W13

[ EDIT : LINK REMOVED - new update available - http://www.lfsforum.net/showthread.php?p=402972#post402972 ]

Scawen

22nd April 2007, 15:56

@Scawen: ISI_SPX - Could you add player flags back in again please? They appear to have been removed and I use them to prevent drivers cheating my driver aid system.It seems unnecessary now because you receive an IS_PFL immediately if the flags ever change. Let me know if there's a problem with that.

About your other request, about a custom prefix, I was thinking it would be better if you could define custom commands, like /talk or whatever, and any custom commands would be passed right through to InSim, just as they are.

Aquilifer

22nd April 2007, 16:30

...
2) There are 3 ways to do race tracking :

a) UDP for all
...

So this is now verified to stay like this for a distant future? My program is ment to be used over loopback so TCP communication is not really needed. I hope this option won't be removed. I have used guaranteed delivery, but I have no idea when the packet could get lost when talking to localhost (queue overflow?). So maybe I can live w/o it.

I guess in that case most insim programmers like me, just need to
1) change the packet formats
2) remove guaranteed delivery (stop ACKing packets) if used

ok thanks for info.

Becky Rose

22nd April 2007, 19:47

I spotted the PFL packet a little while after (deleted my post et all - I guess you still see it though :)), cheers for that :).

About your other request, about a custom prefix, I was thinking it would be better if you could define custom commands, like /talk or whatever, and any custom commands would be passed right through to InSim, just as they are.

This is very good, I would like that.

I can see a drawback though, if you added a command in the future this could cause problems both in terms of software compatibility, and in user 'training'. The only way around it would be if we used a tag phrase on our commands (ie: /sraTrack) - but that would defeat the purpose of using the '/' prefix in the first place.

With a different prefix we solve these problems, for instance I have a command for $track. LFS has /track.

My $track command tells people when the next track change occurs. For admins, it'll return the next track change unless they do $track=fe1, then it gets passed to LFS as a /track command - so both track commands exist in parallel without any conflicts.

Becky Rose

22nd April 2007, 20:13

Whilst you are looking at this, i'm expecting III packets but they are coming in via MSO. I'm not sure if this was intentional or not? (I'll hold off working on that for now).

GeForz

22nd April 2007, 21:02

Hmm when I enter a /i command in lfs I get both. MSO and III packets

TCPReader - reading 136 bytes
TCPReader - reading 72 bytes
Received MSO_Packet(ISP_MSO)
Received Unknown_Packet(ISP_III)

(unknown equals not implemented :))

Scawen

22nd April 2007, 21:18

That sounds like a bug, I'll fix that tomorrow and continue with the remaining features.

Becky Rose

23rd April 2007, 08:16

Yay! One in the back of the net for me then :)
Scawen 8 Becky 1

lol

Scawen

24th April 2007, 14:41

OK, I'm going to close this old thread now. It didn't really work out the way I intended originally, so it doesn't really match the description in the first post. Anyway we've got a lot done here and that's good. But now the new InSim needs to be seen by all InSim programmers (just in case there are some who weren't reading this thread). And it's all about the new system now, so...

Changes since W13 :

ISI changed so you can specify a name and command prefix
Several option flags removed from the IS_ISI packet
Multiple TCP clients can connect
NLP / MCI can be sent by UDP even if you connect by TCP
Better error checking and messages
Type /insim with no parameter to get simple status info
You can request an IS_REO to find out race order info
You can send an IS_REO to reorder the grid

Here's the new thread about the new system!

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