I still haven't seen split packets, but will test it with dedi on another server, maybe I see them then. The only way I got "split" packets was when I made my receive buffer to small so not all (combined) packets fit into it, so the packet was split in my own buffer. The handling is the same though, so I'm sure it will handle split packets correctly. Have a nice day!
I analyzed my code tonight and even found a bug in it. I already worked with a read buffer and continued reading from the tcp if packets weren't complete. Combined packets were handled correctly, but if there would be a split packet (I never saw them yet 
) the rest of the packet was written on the wrong position in the buffer. I still have to test it and hope it's fine now 
I'd like to share it with you guys. I removed the error handling to make the code more readable:
) the rest of the packet was written on the wrong position in the buffer. I still have to test it and hope it's fine now I'd like to share it with you guys. I removed the error handling to make the code more readable:// buffer
const int _BUFF_SIZE = 8096;
byte[] _anbBuff = new byte[_BUFF_SIZE];
int _nBuffUsed = 0, int _nBytesRead = 0, int _nOffset = 0; // start reading from the first position in buffer
public void Listen (IAsyncResult iaResult) {
// get tcp data
_nBytesRead = _nsNetworkStream.EndRead (iaResult);
if (_nBytesRead > 0) {
_nBuffUsed += _nBytesRead; // _nBuffUsed will contain total number of bytes in buffer
// as long as the buffer contains (more) data and the size of the data is at least equal to the size of the processed packet
while (_nBuffUsed > _nOffset && _nBuffUsed >= _nOffset + _anbBuff [_nOffset]) {
// if packetsize % 4 (valid packet size)
if (_anbBuff [_nOffset] % 4 == 0) {
// copy and handle the full packet
byte[] anbPack = new byte [_anbBuff [_nOffset]];
Array.Copy(_anbBuff, _nOffset, anbPack, 0, anbPack.Length);
_handlePacket (anbPack);
}
else {
// invalid packet found, throw exception and terminate connection
}
_nOffset += _anbBuff [_nOffset]; // put offset on next packet
}
// if all packets in buffer could be processed, reset buffer pointers
if (_nBuffUsed == _nOffset) {
_nBuffUsed = _nOffset = 0;
}
// wait for more tcp data
_nsNetworkStream.BeginRead (_anbBuff, _nBuffUsed, _BUFF_SIZE - _nBuffUsed, new AsyncCallback (Listen), _tcpClient);
}
else {
// no data received, throw exception and terminate connection
}
}
Thanks indeed Victor! I already used a "receive buffer", but now I notice I always copy the packet out of the buffer to use in my packet handler. So.. there is the overhead too. I should change that. I think i have the same problem as EQ with the "bad code" ;-) That tcp stuff is one of the first things you make when building a InSim library and hmm... I don't remember how long ago I did it, but when I watch the code I don't understand much of it anymore
I'll try to optimize it and will let you know Hmmm I'll try that... and the erroneous disconnects for bad packets? How should I imagine that?
Insim got disconnected with some error message or?Good to hear
I check the package size in TCP handling already and when the packet size is wrong I terminate the connection. This never happened though (according to my log). My handling is a little different and I think it always handled split and merge packets right. I read the packets like if it's one big stream. All packets go into a buffer and I read only (or until) the size I expect for the specific packet. I will add some logging to see it actually happens. Do you know if there is a specific situation that this splitting/combining occurs or is it completely random?Sorry, forgot about the thread because I've been quite busy this weekend. Lets check it
I think Scawen wrote something about invalid packet sizes before. Shouldn't they be ignored if not dividable by 4? In my code (which is slightly different) I added this check:
byte[] buff = new byte[256]; // number of bytes read stored in bts
int bts = tcp.Receive(buff, 1, SocketFlags.None); // InSim packet length stored in buff[0]
if (bts == 0) { return new byte[0]; } // disconnect
[COLOR="Red"]if (buff[0] % 4 != 0) { return new byte[0]; } // disconnect (invalid packet size)[/COLOR]
while (buff[0] > bts) // read from TCP until packet length
bts += tcp.Receive(buff, bts, buff[0] - bts, SocketFlags.None); // read only one packet
Array.Resize(ref buff, bts);
return buff;
Last edited by Mischa NED, .
Go ahead
And indeed thanks to the devs for all these nice updates 
MAX ALPHA (unsorted)
What does the (red) message "MAX ALPHA (unsorted)" in SHIFT+U mode mean?
When I'm in SHIFT+U with a lot of objects I'm spammed with these messages until I zoom in, close SHIFT+U or remove the objects.
I tried many things to find out when this message starts appearing and it seems that there must be 470 or more visible objects in SHIFT+U mode.
I hope you understand my explanation
UPDATE: It doesn't always send the messages. It seems to have to do with camera height too. I added a layout file with some objects so you can test it. When making it I found out the value isn't always 470 either. In this sample the message already appears above 444 objects.
When I'm in SHIFT+U with a lot of objects I'm spammed with these messages until I zoom in, close SHIFT+U or remove the objects.
I tried many things to find out when this message starts appearing and it seems that there must be 470 or more visible objects in SHIFT+U mode.
I hope you understand my explanation
UPDATE: It doesn't always send the messages. It seems to have to do with camera height too. I added a layout file with some objects so you can test it. When making it I found out the value isn't always 470 either. In this sample the message already appears above 444 objects.
Last edited by Mischa NED, .
Reason : Update
Ok thanks and you did it with the AXM packet? Then something must be wrong in my "short" conversion... weird though... lets check it
Thx again.UPDATE: I don't know what was wrong, but I implemented that conversion again and it worked straight away. You can forget my question
Sorry for wasting some of ur time.
Last edited by Mischa NED, .
Reason : Fixed
Hi
The coordinates are real x and y values, not the ones used in the AXM packet. I multiply them by 16 in the AXM packet and that comes close to your values.I got the comma values from the CompCar out of a MCI packet.
I was playing a bit with the AXM packets, but I get unexpected results. I put 8 objects on blackwood in 1 line:
X Y
A 251.48 45.44
B 254.93 32.52
C 258.38 19.59
D 261.83 6.67
E 265.29 6.26-
F 268.74 19.18-
G 272.19 32.11-
H 275.64 45.03-
I thought this should be a straight line, but the result is as in the attached image. Can somebody reproduce this or could there be an error in my insim library? It's on different spots on track where numbers go from + to - and opposite. I don't have time now to examine the problem, but if it's a lfs bug it would be nice if fixed. Thanks
X Y
A 251.48 45.44
B 254.93 32.52
C 258.38 19.59
D 261.83 6.67
E 265.29 6.26-
F 268.74 19.18-
G 272.19 32.11-
H 275.64 45.03-
I thought this should be a straight line, but the result is as in the attached image. Can somebody reproduce this or could there be an error in my insim library? It's on different spots on track where numbers go from + to - and opposite. I don't have time now to examine the problem, but if it's a lfs bug it would be nice if fixed. Thanks
Sorry I don't dare to write this to you because it's such a minor thing and I don't want to waste your time on it, but in the insim.txt file is written:
// InSim for Live for Speed : 0.5A2
// InSim for Live for Speed : 0.5A2
Is there a reason why there is no HLVC_OBJECT in the HLVC enumeration or should I read HLVC_WALL as "hit some object"? In some corners it's possible to hit objects before hitting ground or wall. If you hit an object (tyres on inside of corner for example) InSim tells me the player hit a wall. I think it's nice to be able to tell the user if he hit an object or a wall without checking the OBH packet.
Sorry, I should have seen it
I guess I was to excited that I got stuck to the patch test thread I just tested the CON, HLV, OBH and ACR packets, they work great
. Enjoy your well deserved weekend 
Scawen,
I guessed the value for ISP_PLC and sent the packet. It does what you would expect But I have a question.
This release you automatically spectate people who drive in a disabled car (after changing /cars). Is there a reason why you didn't do this after sending the PLC packet? I know it's simple to spectate someone from InSim, but I just wonder if this is the way it should work.
Thanks again,
Mischa
I guessed the value for ISP_PLC and sent the packet. It does what you would expect
But I have a question.This release you automatically spectate people who drive in a disabled car (after changing /cars). Is there a reason why you didn't do this after sending the PLC packet? I know it's simple to spectate someone from InSim, but I just wonder if this is the way it should work.
Thanks again,
Mischa
Insim.txt missing?
Hi Scawen,
Fantastic job! I have been waiting for all those InSim changes for some time and you did them all ;-) I was very curious for the description of the latest packets, but is the insim.txt file updated? It looks like if you put the Z32 version (of May 6th) in the archives.
Hope to hear from you,
Mischa
Fantastic job! I have been waiting for all those InSim changes for some time and you did them all ;-) I was very curious for the description of the latest packets, but is the insim.txt file updated? It looks like if you put the Z32 version (of May 6th) in the archives.
Hope to hear from you,
Mischa
Dakar 2010 - Live Tracking / Results
For the Dakar fans out there the following urls. Virtual stage and overal results:
Live Tracking / Results
http://tenharkeldakar.nl/live/
And if you want to follow a specific driver/country, just change the parameters in the following address:
http://tenharkeldakar.nl/2010/ ... country=NLD&track=417
See ya,
Mischa
Live Tracking / Results
http://tenharkeldakar.nl/live/
And if you want to follow a specific driver/country, just change the parameters in the following address:
http://tenharkeldakar.nl/2010/ ... country=NLD&track=417
See ya,
Mischa
First of all great work on your new project ;-)
I see advantages of a /lock. If you /spec people try to join the track and a message appears that the user joined the track. They keep trying even when they get a warning about a "lock". If you really lock them, they can't join at all and the people who are racing aren't bothered by these messages. After a lock you could show a friendly message in the middle of the screen why they are locked.
It's just an idea... I think it's not an extreme request... It's just an option in between the current /kick and /spec which I would use. I think when it's implemented you would sooner /lock somebody than /kick him.
Scawen, I hope you have an opinion on this one too. Thanx :-)
I want to prevent them from even trying to join... and give them neat message Scawen talks about. If you spec them... they keep try joining... even with red message explaining why they can't join... If you lock them with a nice popup they can't join, explain them why and how they could... then Scawen is happy, the user is happy, and peeps in server are happy...
I know about the /spec /kick /ban options :P please give me a /lock
at least I'll be happy then ;-)InSim - Lock user...
Hi there,
I think the main reason for kicking people from a server is preventing troubles and keeping the servers clean. There is no other way to "lock" a specific user from messing on a server. I understand we (insim developpers) have to realise often it's a users first impression of online racing with LFS. I think I have a nice solution that works for everybody.
Add an InSim package we can send to the host to "lock" a user. This means the user can't join the track. We could show the reason for the lock in a friendly message in the middle of the screen. This could even be an LFS feature. Let InSim developpers send a reason in the InSim package and let LFS show the popup why they are locked. Hmm? :-)
Thanx,
Mischa
I think the main reason for kicking people from a server is preventing troubles and keeping the servers clean. There is no other way to "lock" a specific user from messing on a server. I understand we (insim developpers) have to realise often it's a users first impression of online racing with LFS. I think I have a nice solution that works for everybody.
Add an InSim package we can send to the host to "lock" a user. This means the user can't join the track. We could show the reason for the lock in a friendly message in the middle of the screen. This could even be an LFS feature. Let InSim developpers send a reason in the InSim package and let LFS show the popup why they are locked. Hmm? :-)
Thanx,
Mischa
InSim Request
Hi there,
I mentioned it before in previous patch, but I have a request which is not listed yet. I think it would be nice for InSim developpers to know if a hotlap is valid or not. I made this check myself based on cars position, but during a (minor) lag the position can be estimated/calculated wrong and a very clean lap can be counted as invalid.
Scawen wrote before: "HLVC detection is not calculated in multiplayer mode - it's just for hotlapping - so it's not just a case of adding a flag". Maybe it's an idea to add this to the wishlist?
Thanx,
Mischa
I mentioned it before in previous patch, but I have a request which is not listed yet. I think it would be nice for InSim developpers to know if a hotlap is valid or not. I made this check myself based on cars position, but during a (minor) lag the position can be estimated/calculated wrong and a very clean lap can be counted as invalid.
Scawen wrote before: "HLVC detection is not calculated in multiplayer mode - it's just for hotlapping - so it's not just a case of adding a flag". Maybe it's an idea to add this to the wishlist?
Thanx,
Mischa
Great stuff Scawen! Thanx for including the screen angle and fov update in this patch. I'm going to test it right away and will let u know if I find something strange.
I asked the same in Z16 and for me it would be a great option! I hope it's simple to add. What is the angle now? 45? I'm using even less than 30, because the distance to my monitors is about 1 meter. I think I need only 20 degrees or so. Moving the screns to 45 degrees is not an option... Right now I drive without left/right enabled, so I'm on the old 3 screen setup..
Just to be sure, cause I didn't see a reply on the Z16 thread yet. Are there more people who have this little problem with bezel compensation?
When I activate bezel compensation on 3 screens you see the views on left and right monitor move a bit to the center. Sounds correct, but the most left vertical line of pixels on the center monitor is also rendered/changed.
It's like if the left render is 1281 pixels (screen width + 1) so the last vertical line of pixels of that render appears on the left side of the center monitor.
UPDATE: I think this is not LFS related.. I have a way to reproduce this problem in Windows too... thanx & post can be removed
When I activate bezel compensation on 3 screens you see the views on left and right monitor move a bit to the center. Sounds correct, but the most left vertical line of pixels on the center monitor is also rendered/changed.
It's like if the left render is 1281 pixels (screen width + 1) so the last vertical line of pixels of that render appears on the left side of the center monitor.
UPDATE: I think this is not LFS related.. I have a way to reproduce this problem in Windows too... thanx & post can be removed
Last edited by Mischa NED, .
FGED GREDG RDFGDR GSFDG