Hello, I noticed today that if I don't respond to InSim's keep alive packet, when the connection times out in LFS it makes the game become unresponsive and eventually crash. It does not give me any crash address... But it is very reproducable for me.
Thanks for the info. Before I try to reproduce it, is there any other info you can give me?
The questions I can think of are :
- Are you using TCP or UDP?
- Do you see a timeout message in LFS before the crash?
- Does LFS continue for a while after the message and before the crash?
- I'm using TCP, I've not tired it with UDP, but I can do.
- I get a message "InSim read error : <My Program Name>"
- The game does continue, but the framerate drops to about 1fps, then if I try to click on the window, to try to close LFS etc.. it just freezes then the game shuts down.
I can upload the version of my program, with the keep alive stuff turned off, that causes the bug if that will help...
I'm a noob in coding but Scawen plz can you say me...when can we start mods dev updates ?
Is another new changes in futures after this one ? or we can work on this basis in W17 ?
Because when X patch coming any mods can work if dont builded before, any league can continue,etc....
Whoops Scawen, I think I instigated a wild goose chase. Turns out it was my InSim app, when it timed-out my program jumped to 100% CPU useage, which was making LFS really slow... Sorry about that.
Does anyone else experience this message: could not find connection 1 client info (something similar to this). It happened in previous versions of insim too I believe.
Steps are: connect to server, run insim on client side, send ncn req to get ucid of already connected player, then send mtc to that ucid !=0 & plid = 0.
If same insim is started on dedicated server side, players can get that message to their ucid when joined...
I'd like to have the track length in IS_RST packet, as it would be handy for calculating average speeds and showing the race length in kilometres.
Currently I calculate the track length from the path file or use precalculated values. Path file loading is OK if I need to draw the track map but it's quite a heavy operation if only the length is needed.
It would also be nice to have the car direction, heading and angle velocity in 3D in IS_MCI packet for 3D spectator programs or something.
I've answered this same question a lot of times, but I guess I can say it again, because I think you missed my posts.
Any changes from now that can break any existing programs are really, tiny small changes. So any programmer who wants to develop, can do so, then they can make these very small changes when W18 comes out. Or they can wait - I intend to release a patch in one, two or three days (however fast I can get it done) with these tiny little changes included. If you did see my posts you would realise I am 100% aware that people need time to develop their code, and that is why I am working so hard to fix every problem as fast as possible, so there is a good time between the final incompatible change, and the release of Patch X.
OK no problem, thanks for letting me know - before I got round to looking into it
The comedy being that it makes LFS crash like buggery, but my program itself runs like like nothing ever happened! Oh well, I better keep sending those keep alive packets... God bless .net.
I don't know, I've looked in the code and it seems simple enough, I can't see why it wouldn't send all of them.
Right, you are using TCP.
Are you certain that you really are only getting 4 of them?
Are you sure it's not just that several packets arrived in the same "recv" ?
You need to check the amount of received data and compare that with the packet size, remembering that one call to "recv" doesn't necessarily return one "packet" - it can return half a packet or 10 packets...
OK, cool, I think that's is my problem. I wasn't considering more than one packet coming in a receive, so I was cutting it off before I'd gone through all of them... Sorry if I'm being annoying lol, I'm trying to learn sockets while figuring out InSim at the same time, so I can end up pretty lost sometimes... I think I'll stop posting in this thread now, at least until I know what I'm doing. Thanks Scawen, as always you're a star!
Probably not the best way to approach the issue. But I'd like to see ping/latency info in the MCI packet. It would make it possible for us to deal with players with very high latency.
If your car is warping, dis- and reappering, appears to be sliding but it is not I would not like to race you on any server. Though I have raced you without any such issues, Dygear. Maybe 110ms is enough for a smooth gameplay? I dont know yet. But such an addition to the MCI packet would certainly help me find out.
Currently, finding out who is lagging might be a difficult task, it takes time to find the person in question and you might even be mislead by his effect on others. I am sure programmers and host admins could put their heads together and come up with a sensible approach. I chose the word "deal with" for a reason, you know.
Doesn't LFS kick out a player if he lags too much? In my opinion the system should be inside LFS and in the server config file you could set how much delay is allowed (maybe with variance allowed over the limit). Not so that you need to make an insim program for that.
Delay of 110ms is not that much. I checked Call of Duty 2. The first page of servers seemed to have max ping of 100-250ms. Maybe half of them didn't use it (max ping=0). But I think LFS might handle larger delay because racing is bit more predictable than men running with guns. In demo I raced with somebody from India and he had quite bad ping, but he didn't seem to lag so much.
I'm a little confused. I am using a ReqID for my application, and i'm getting packets in on 0 (expected, global), 1 (my ReqID), and 255. I'm not expecting packets to arrive with a ReqID of 255.
Have I done something wrong? I've found this on two applications written in two totally different programming languages with no common code, so I am either not understanding it, or it's a minor bug.
On one application the keep alive packets where coming in on that ReqID. I'm not sure on the other one - I just saw my debug log show the diregarded packet a few times so i've started trapping them now - I just dont think it's right.
I think it's only the keep alive packets that have the ReqI of 255.
But that was a small bug, in this week's version that will be zero.
It was supposed to be last week's version but things took took longer than expected. I'm quite confident that the small InSim updates should be out in an incompatible new W version this week. The InSim updates are already done. By the way, due to the possible security risks, I've kept the admin password working as it did before, but I've put up a better error message if the wrong password is specified. The other changes are as expected and I'll document the changes on this thread, it's mainly the times changing from MSHT to MS and the elapsed time being included in SPX and LAP which makes them 4 bytes bigger. MSO's "User" byte is also more meaningful, having a different value for system messages, user messages, special prefix messages and the local /mso command.
