SO Sprint2 Single Player. After 4 Rounds of qualification the AI drivers are scattered around the track.They do not drive back into pits

Why do you want to choose the sending port? Your program acts as a client program so the sending port is not of interrest.

You also do not select a sending port for Firefox or the IE (ok this is TCP, but also only a client). Googling I found this page http://evolt.org/node/60276. I dont't know if the program is correct but IMHO it shows the difference between client an server programming.

There also could be some programming problems.
If you use for example different threads in your program it could be that one thread opens the channel to InSim, but before the intialising ISI packet ist sent another thread that uses the connection sends a request for another packet.

Set a breakpoint at the send routine an have a look at:
1. Which source port do you use (buedi mentioned it already)
2. The order of the packets you send. Escpacially, if the ISI packet is really the very first you send. In my Java program I use many threads and under certain circumstances I had a race condition where the ISI packet was not the first packet that was sent.

The difference between UDP and TCP is simple:
1. UDP has no mechanism to check if the packets you send really arrive.TCP is trusted. The packet you send will be recieved. Simplified you can say that UDP is "Fire and forget" and TCP is a protocol with verifying that a packet that is sent will arrive at the other end. Because of the TCP protocol nature TCP is slower than UDP but therefore reliable.
2. UDP ist packet oriented. TCP ist stream oriented. With UDP you know where a packet begins and a packet ends. TCP is a constant flow of data. The most common problem with TCP is that only the first packet in the recieve buffer is handled. But due to the nature of TCP there can be multiple packets in the recieve buffer and also be splitted LFS packets.

SHIFT+CTRL is the solution

1. got a car onto my roof in the pits on bugserver2 after joining the race.
2. its very hard to get into the pits when a lot of player joins. pressing ESC on time too often lets me leave the pits instantly after I finally got into the pits and I have to try again SHIFT+P

Quote from Scawen :

No, because it's a real C header file used in LFS.

:hide: sorry forgot it.

One little thing in the docs:

Wouldn't be Info[NumP] a little bit clearer? At the first look it seems to be fixed length. The same in IS_MCI with Info[8].

From my point of view the best would be to make the hotlapping start selectable (pit or last split) or let it be as it is.

Hotlapping from the pits is no option for me. Maybe others have more time than me, but I'm 43 of age and I also have a real life and only a limited amount of time for LFS and hotlapping from the pits is waste of time for me.

Maybe it's more realistic. But what is the benefit for hotlapping from the pits? Warming up the tires? Look at the hotlapping replays of the best drivers in the OLFSL Leage and you see how they warm up the tires.

If you speek of realism then a super pole mode for qualification could be interesting (Only one warum lap and a qualification lap). There the purists will need the skill of warming up the tires in time and get a good result in only one lap.

Hotlapping is no racing. If you fail you can start again. So I think that the realism should be kept in racing not in an offline mode where you want to make many laps in short time and not wasting time for no benefit.

If you are using VB6 then http://www.freevbcode.com/ShowCode.Asp?ID=8271 should help you. There is a function FloatToTwoSInt I think you can adapt.

If you use .NET have a look at http://msdn2.microsoft.com/en- ... /system.bitconverter.aspx and the System.BitConverter class.

Ehm, one thing I forgot to mention. If you cannot fetch all incoming packets fast enough then you might loose the connection to LFS because LFS thinks that there is a problem with the InSim client. I didn't test this but I think it could be possible. Have to test this also for my app.

+1, then it's a good alternative to IS_MCI

Quote from Scawen :

I could in fact take one more step and make it variable sized packet, ...

Should't the IS_MCI packet then also be variable? I think IS_NLP and IS_MCI should be handled in the same way because they stand in near relation.

Quote from t1ger :

All I have here is a message box waiting to pop up and say "Not enough data received".

Hmm, don't make a messagebox. If there is a splitted package then just wait for the rest of the package. As Scawen said, TCP is streaming, splitted packages are normal and no exception. The messagebox has no useful information for the user. If you want you can make an entry in a log file. Personally I use Java and log4j and for such information the log level DEBUG.

Thinking about how to get splitted packages maybe the following wil be a solution:
1. No MCI packets (they are too large and not so good to handle for that)
2. Set receive buffer size to 100-120 Bytes (not kByte!!!)
3. Maximum AI player or a replay from a server with more player
4. Fire out TINY_NPL requests in a loop to get many many many packets

For every request you get at least 20 times 76 bytes in return (with maxium AI)

The IS_NPL packet is 76 bytes long, so your buffer will be smaller than 2 packets and IMHO a splitted package has to occur.

You are using VB6 so have a look at http://support.microsoft.com/kb/237688/en-us to change socket options.

Last edited by LupusC, Mon, 4 Jun 2007 14:09.

For clarification a short (simplified) snipplet of my java program that shows the part where the packets are read in.

receiveBuffer: used for the incoming data stream
inSimData: ByteBuffer with the read packet you can convert into a structure you need (I do it with the factory pattern)

My program is in an alpha state so i cannot make it yet public.

For stress testing I use FernBay Club with the maximum ammount of AI driver with BF1 and enable receiving MCI packets with 100ms interval.

It's not the load of a 32 player server, but for initial testing it's ok.

The easiest way to deal with splitted packages is very simple. Just read the first byte of the incoming stream, but without removing the byte (!!). And then test if the ammount of bytes in the input buffer is greater or equal the byte you read. If yes read in the packet, if not wait for more bytes.

If you do this in a loop you have no problem to read multiple packets and splitted packets.

Sorry if I'm asking somthing that was solved in another thread but I couldn't find how to get the best laps of drivers currently racing.

Before the new patches they were shown beneath the race time and the current lap time. When spectating or during training I used to check the best lap times of the other competitors. But how do I get that information now?

If this question was solved in another posting I'm sorry.

Thanks for the info

Quote from Scawen :

Maybe the STA packet should be anti spammed a bit as well.

I have some troubles with changing the camera view in W32 and the IS_CCH packet.

I tested this in Single Player mode with only one vehicle and no AI driver. I drove only into the pit lane and changed the camera view.

1. I got an ISP_STA packet when changing the camera with the V key (thats clear)
2. The ISP_CCH came 2 or 3 seconds later
3. When changing to or leaving the custom view (SHIFT+U) I got no IS_CCH packet.

So my questions:
1. Is the time delay between ISP_STA and IS_CCH ok?
2. Is it inteded to get no ISP_CCH packet when changring to or leaving the custom view?

Quote from Scawen :

I have no idea why you would get an IS_STA packet just because you clicked on a standard clickable button, unless that button caused the state info to change.

Ok, I only mentioned it because it was strange for me.

Quote from Scawen :

Yes, I took this decision for a few reasons - for a start, I wanted the user to really know if the application had received your text. If it changed automatically without a reply you wouldn't really know that, and also you could enter invalid text.

Ok, perfect.

Thanks for your info.

I'm currently testing the custom buttons with W32. I have two short questions.

Question 1:
I saw that when I click a custom button on the main screen (where you can select single or multiplayer mode) then a ISP_STA pack is sent back to my application. Also when I click OK or CANCEL when changing the button text. Is that intended?

Question 2:
Is it correct, that after editing a button text the new text is not shown on the button? The new text is only sent back in a ISP_BTT packet and I have to change the text via an IS_BTN packet?

Two short questions about InSim:

1. Will the information about node and lap in the NodeLap structure be separated? In CompCar it's separated.

2. Does PLID and uniqueId have the same meaning?

It seems that there is wrong packet size in the documentation of IS_PSF in W17. IMHO the size should be 9 instead of 12.

Hi Stuff,

Thanks for the download. Zoom and pan looks very smooth in you app. I program in Java so I cannot use the freeimage.dll. Have to look if there is something similar.

Taking an image from F1PerfView is worth a try, but nevertheless I am interested in the points 2 and 3 i mentioned before.

Thanks Stuff for the hint. It's a good idea if I only need the image. But I have to draw it myself because I want to put data from ÍnSim into the image.
I don't have a reference point for the image of F1PerfView, for example the coordinates of the lower lefthand corner. So I cannot put my data exactly into these images without a lot of trial and error and zooming also is not possible.

Correction to previous post:

Gaps in image solved.

Hi Victor,

Hmmm, I thought I had it. As Attachment is a part of my result of Kyoto enclosed.

The following questions are left
1. Why are there such gaps in the image?

2. In the first block in "Kyoto Ring_2DH.smx" there are 180 (B4h) points and only 30 (1Eh) vertices. 30 vertices * 3 points per triangle result in 90 points. What is with the other 90 points?

3. What meaning has the "radius" in the Object block?

thanks for your help