Quote from horrgakx :

Hi chaps, is there any more news on this (race 5) -40 point result please?

Hi horrgakx,

Please bear with us, we have not forgotten you and a decision should be made soon. I would hope that this will be made before the next race.

Thanks for your patience.

Tim

Quote from Renku :

Cya when You get back .

LOL to that Renku!

'tis true! You won't be able to stay away from racing LFS for long, Ant!

Seriously, though, good luck and I have only the greatest of respect for you and your decision.

Tim

Quote from AtomAnt :

Already found him.......sorry ,Tim Kay is the next name to watch.
You could try to bribe him, but he's on staff with OLFSL. The largest LFS league....and one of the oldest.

Thanks ANT!

I would like to help, but I have my work cut out with the Original LFS League and the app I am writing for it.

Sorry,
Tim

Quote from AtomAnt :

Take note, this is an Application test for hosts to review stats CSV, and HTML files.

Ant, please note I am away from this Saturday so I will not be around if you have questions/problems with the app. Just email me and I will pick it up on my return.

Thanks
Tim

Quote from Bogey Jammer :

an out of topic question: UDP vs TCP, what are the differences? I've heard that UDP is potentially faster

This seems to be the best (and most to the point) description I have found.

Edit: and another.

Tim

Thanks for the info Bawbag! That is really kind of you to share your skills. I will definately try these things and see if I can improve my hotlap.

Its good to know you have a heavy right foot also!

Tim

Oops, I really thought we were running them on Patch W, sorry, but thanks. They are now on Patch X so the problem will be gone.

Thanks again (and sorry again)

Tim

Just tested and when "Voluntary added mass" = 0 kg the "Added mass position (front)" is greyed out and it makes no difference to the cars weight distribution when you move it.

This was tested offline. Maybe when online a server can force the mass and you do not see it. I can't test this 'cos my server is off.

Tim

Hi,

I noticed this bug at our last league race (OLFSL 3 by 500servers - 19:26, 03 Jun 2007 - Fernbay Rallycrss Rev - 35 laps). During the race, I left and decided to watch the race in the Progress window. But it was very strange. There were about 15 in the race, only 3 were shown with positions, 1 was spectating (which he was) and the rest were all showing as "in pits".

Also, during the race, the positions of the three racers that had positions shown moved randomly all over the place.

I took screenshots as different times during the race (one on lap 16 and one on lap 18) and they are attached.

The race server was on Patch W at the time (with no test patches).

Thanks

Tim

Quote from russraine :

Well you need the right setup to start with - when we did MRT before I was good but not great, then Solar gave me his set and I went on to win the race.

Thanks, but I was test driving the car and setup Mooney used in the 53.66 lap I was watching!

Quote from Jonas8431 :

A really good tip is: turn 90 degrees on the set, the mrt has 190° availables.then...
...
...

Thanks, I will try that...

Tim

Well, I thought I would get the ball rolling on the next event...

First, a question - how to hell do you keep the MRT floored through the back complex (down and up "big dipper" part)! Everytime I try, I just spin around. I just watched Mooney's lap (53.66) and you are flat all the way through it!

Amazin'

Oh, well - more practice and hopefully I can get below the 56.00 where I am stuck at the moment. Then again, I don't fancy my chances of getting around this track sixty times!

Tim

I was really looking forward to this one and I had managed to claw my way into Pool 3 for only the second time ever

Unfortunately, I had installed an over-clocking utility which came with my motherboard and (even though it wasn't doing much) it caused me to "time travel" in LFS when connected to a server (because it couldn't keep in time with the server). This meant that after about 4 or 5 laps, I was just showing as lagging and I was running around on my own. I could still see other peoples chat and I could chat, but racing was out of the question.

It took me a while (and a system restore ) to get it back, but I am now ready for MRT at AS1R!

Tim

Quote from LupusC :

Hmm, don't make a messagebox.

I know, don't worry I am just testing at the moment. And even when this is complete I do not intend releasing it to the masses - only a select few

Quote from LupusC :

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.

This is the type of thing I need! I am not, by any means, an expert programmer. I know what I need to do when I get less data than I need - wait for some more and then add on the bits I am missing. BUT I can guarantee that it will not work if I code it and just wait for it to happen. I need to test it and make sure, and I can only do that when it happens.

Quote from LupusC :

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

I will try this, because the one thing I am so far unable to do is find out and change how big the receive buffer is. If I can do this, then I can test it and then I will know I am covered when it occurs.

Thanks very much for the info LupusC.

Tim

Quote from LupusC :

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.

Hi LupusC,

Thanks, and yes that is exactly what I do. I have the routine that receives data from the TCP stream which passes the array of bytes received to a routine which checks the first byte ("size") and then checks it against the size of bytes received on the stream.

As you know, there are three possiblities:

1. The size received matches the size of the LFS packet. I then pass the data to the process routine. The process routine only knows how to deal with full and complete LFS packets.

2. The size received is greater than the size of the LFS packet. In this case, I pass the first LFS packet to the process routine and then re-process the rest of the actual data received.

3. The size received is less than the size of the LFS packet. In this case I know that I need to wait for more data and then add it to the end, and then process it. I have as yet, never encountered this case. All I have here is a message box waiting to pop up and say "Not enough data received".

Last night, I connected to a very full server, which had about 23 people connected and people joining and leaving and talking and pitting and racing and everything. Now, apart from my PC having some issues and my application not being able to keep up with where everybody was (but I know this is a limitation of what I have coded) then I never saw case 3 as described above.

I then connected to another server with about 7 racers and I got the same results again.

Like I say, I do not deny that this is not possible, I am just saying that I would have expected to have seen it by now with the amount of testing I have done.

Thanks

Tim

Quote from the_angry_angel :

It shouldn't do - VB has no understanding of how the insim data is packetized (all TCP data is basically a constant stream, its upto you how you packetize it), so you're probably just very lucky, or you've got a huge buffer..

Connect your InSim client upto LFS and join a really busy server with a fair bit of chat, and start watching the packets, odds are you'll probably see a split one.

Thanks, that is a good point, I haven't yet connected to a "busy" server and tried.

Tim

Quote from Scawen :

The multiple packets case is very easy to deal with - just see if there is more data there after reading the first packet.

The incomplete packets case is a bit more complicated but it's really just a case of your code realising that there isn't enough data received for the specified packet size, so you must leave that incomplete packet in the buffer until you get some more info and find that the packet is complete.

I have been using the new insim over TCP/IP for quite some time now, including connecting to a local guest, a local host and a remote host over the internet and have yet to experience the "not receiving enough data" and have never yet had to buffer the received data and wait for some more to finish the LFS Packet.

Now, I am using VB6 with its standard WinSock control and it fires a routine called _DataArrival when data is received from the TCP socket. I do not know if this function somehow compensates for the fact that TCP can break up the initial "packet".

Getting a few LFS packets in altogether happens all the time and I have been able to accomodate this (as I had it happening and could test and debug it until it worked). However, with the split packet, I have never had it so I have not worked how what to do with it. I am of course looking for it and I just have a message box which will pop up the first time it happens!

Don't get me wrong, I fully understand the reasons that it can and will happen, I just wonder if VB6 compensates already.

Can anyone else confirm of clarify this?

Tim

Oh dear, my bad!

I spot one mistake just like it and then I miss one altogether! How bizarre.

Thanks GeForz.

Tim

Hi,

I think I may have found a bug in InSim. I have a program which can talk to InSim and the first thing it does with received packets is check the amount of bytes received against byte 0 and byte 1 (using a lookup table) to ensure it has received enough or not.

This works fine everywhere apart from one place - when I start a multiplayer replay. I haven't tried it with a single player replay yet as I have been scratching my head hard to make sure I am not missing anything obvious (apologies again, if I have )

When I start a multiplayer replay I get a packet which is 40 bytes long (0 to 39) and the first two bytes are as follows:

byte(0) = 40
byte(1) = 10

The rest of the bytes from 2 to 39 are all = 0.

Now, this packet seems to be an ISP_ISM, but this should be 8 bytes in size, so I expect byte(0) to be 8 not 40. I can't see any LFS packets that are 40 bytes and there is nothing in the rest of the packet which gives me any clue as to what it is.

Can anyone else confirm this before Scawen takes a look? I am using W29.

Thanks in advance.

Tim

Last edited by t1ger, Thu 24 May 2007, 22:30.

Quote from BurnOut69 :

Thanks fel, that will surely do the trick

I have another question: if several players can be bound to one connection (when adding AI), what would be the UCID of these AI drivers if the connection that created them leaves?

AI dont have UCIDs so when the the connection that created them leaves, I would expect the AI to leave also. I can not confirm this at this moment, but I am fairly sure this will happen.

Tim

Hello,

Small mistake noted in the InSim.txt file:


byte Type should have ISP_RES not ISP_PFL as the comment.

Nothing major, but worth noting.

Thanks
Tim

Quote from Scawen :

Admins can now use the IS_REO (race reorder) packet

I know this is spam, but I couldn't let this go with out expressing my deepest thanks, could I!

Thank you.

Tim

Quote from Scawen :

Hi Tim.

Sorry, yes I did read your post and was going to get back to it after thinking a bit. But an unreasonable time has passed with no reply from me.

IS_REO is host only, yes. It would be a bit dangerous to allow guests to do this... and if they could it would be admins only. And if admins can do it then there is a possibilty of conflict with the host. I couldn't see any reason for a guest to send an IS_REO so that's why it's host side only (all race reordering has always been host controlled).

But what is the reason for allowing guests to do it? I think it would be quite easy to allow admins to reorder the race, if there is a good reason and if no-one thinks of any problems with it.

Phew, I am glad you understand my reasons for re-posting.

The reason I ask for this is because I am writing a race control app which will be used for the hosts that watch and manage league races. By the term "host" I mean a guest connecting to the server with admin rights who then just spectates the entire race and ensures that rules etc are followed. In our league, the "hosts" are not hosts in the LFS sense of the word, they are guests who log on with admin rights. (I hope this makes sense so far).

Currently, re-ordering a race to start in the correct order is done by everyone joining in the correct order. The IS_REO function would simplify this immensly and streamline the hosting process.

I would be perfectly happy for an admin to be able to re-order the race, but I can see that there could be issues if there were multiple admins all trying to re-order the race at the same time. Perhaps only the first admin to connect could do the re-ordering or the admin with the lowest UCID only.

If not, then I will have to get the hosts to know the IP address of the server they are "hosting" and connect as the proper host.

I think that is enough uses of the word host now!

Can anyone else think of any issues this may cause?

Thanks
Tim

Last edited by t1ger, Fri 18 May 2007, 18:57.

Quote from t1ger :

My pleasure!

I can confirm that it now works as expected. However, I now have another question about this IS_REO feature. When I connect InSim directly to the server, it works. When I connect InSim to a client connected to the server (logged in as admin) it does not work.

Is this by design?

EDIT: using W24 host and W24 client. By "does not work", I mean, nothing happens, no errors no nothing including no packets back from LFS.

Thanks in advance.
Tim

Hi Scawen,

I don't mean to be pushy, but I get the feeling that you missed my last post (quoted above). If you did notice it - then I am really sorry, but I don't want to keep coding this the way I am doing if it is not going to work.

Again, apologies x 1,000,000 if you noted it.

Thanks
Tim

Quote from Scawen :

Thanks for that very good IS_REO bug tracking.

I've fixed that in my version - I hope to release that in a minor update today (also fixing the occasional crash on leaving a host).

My pleasure!

I can confirm that it now works as expected. However, I now have another question about this IS_REO feature. When I connect InSim directly to the server, it works. When I connect InSim to a client connected to the server (logged in as admin) it does not work.

Is this by design?

EDIT: using W24 host and W24 client. By "does not work", I mean, nothing happens, no errors no nothing including no packets back from LFS.

Thanks in advance.
Tim

Last edited by t1ger, Tue 15 May 2007, 22:36.

I just changed the packet size to 32 (ie 28 cars) and I don't get the error any more. It doesn't reorder the grid for me, but that may be that I am not doing it at the right time.

The InSim.txt definately says 36 bytes for this struct.

EDIT: Packet size changed (using 32) and then connected to multiplayer host and it works!

Hopefully, this will help you Scawen!

Thanks
Tim

Last edited by t1ger, Sat 12 May 2007, 23:16.