The online racing simulator
weird NCN problem
(8 posts, started )
weird NCN problem
I had a bug in my MCI package but now it seems to be that the bug is not in the mci package but i didn't receive the connection his details... so the user is only joined as player but not as connection:

When I list the details:
//Unique playerid / Conn Playerid -username
//Players List:
17/17 - Mr. hansen
4/4 - mikus
60/60 - ergin
30/30 - McTw1st
42/42 - Wavedoctor
47/47 - HighRoad
18/18 - spiritless
31/31 - G. Dierckx
62/62 - ToXiC10
56/56 - defille20
39/39 - Paradam
23/23 - racer325
9/9 - jamodabestdood
53 - ^2minty^3moose error -> no connection found
70/70 - fumanshu3
73/73 - hipomenes2
71/71 - canerman
43/43 - b0ss
15/15 - royk1991
32/32 - 2k7markcfc
55/55 - robbo01

//Connections list:
0 - spectating
30/30 - McTw1st playing
17/17 - Mr. hansen playing
4/4 - mikus playing
18/18 - spiritless playing
60/60 - ergin playing
15/15 - royk1991 playing
62/62 - ToXiC10 playing
32/32 - 2k7markcfc playing
73/73 - hipomenes2 playing
47/47 - HighRoad playing
55/55 - robbo01 playing
71/71 - canerman playing
42/42 - Wavedoctor playing
39/39 - Paradam playing
56/56 - defille20 playing
31/31 - G. Dierckx playing
43/43 - b0ss playing
9/9 - jamodabestdood playing
64 - kimberly spectating
23/23 - racer325 playing
70/70 - fumanshu3 playing

and ass u can see in the Connections list there is no Unique id 53...

Does anybody know what it could be? (no exception was trown at the NCN event)
Could be lag, It rarely happends tbh. The NCN and NPL packet both contain the current amount of each.

struct IS_NCN // New ConN
{
byte Size; // 56
byte Type; // ISP_NCN
byte ReqI; // 0 unless this is a reply to a TINY_NCN request
byte UCID; // new connection's unique id (0 = host)
char UName[24]; // username
char PName[24]; // nickname
byte Admin; // 1 if admin
[B]byte Total; // number of connections including host[/B]
byte Flags; // bit 2 : remote
byte Sp3;
};

And...

struct IS_NPL // New PLayer joining race (if PLID already exists, then leaving pits)
{
byte Size; // 76
byte Type; // ISP_NPL
byte ReqI; // 0 unless this is a reply to an TINY_NPL request
byte PLID; // player's newly assigned unique id
byte UCID; // connection's unique id
byte PType; // bit 0 : female / bit 1 : AI / bit 2 : remote
word Flags; // player flags
char PName[24]; // nickname
char Plate[8]; // number plate - NO ZERO AT END!
char CName[4]; // car name
char SName[16]; // skin name - MAX_CAR_TEX_NAME
byte Tyres[4]; // compounds
byte H_Mass; // added mass (kg)
byte H_TRes; // intake restriction
byte Model; // driver model
byte Pass; // passengers byte
int Spare;
byte Sp0;
[B] byte NumP; // number in race (same when leaving pits, 1 more if new)[/B]
byte Sp2;
byte Sp3;
};

What you could do is check the amount against each list. If its wrong either boot all or send tiny NCN & NPL. Then recollect all the info.
It could just be the fact that it has a logged "movement" hense the MCI fire, but, they have already left :P
Quote from Krammeh :It could just be the fact that it has a logged "movement" hense the MCI fire, but, they have already left :P

Nope, I started it 10 times again the insim and each time the same problem, same user unless the user leaves it doesn't has a problem
#5 - Stuff
Hmm, if I read your list right, are your connection IDs the same as your player IDs? Thats usually not the case afaik. Connection IDs go from 0 (host) to number_connected (not including AI) sequentially. Your player IDs look right as I think they are semi random. I dunno maybe I'm missing something. And you say its the same user? Maybe check something in the user name that could be throwing off your code? That ^2 and ^3 look unique to me
what i'd do next is debug all your received ncn packets (log them in hex before you even process the packet) and see if you actually received all ncn's or not. If you do, there may be a bug in your ncn packet processing. If you don't, then LFS might be omitting something or even weirder.
I've personally not come across missing ncn packets though, unless i haven't noticed. But that's why i recommend to debug at the source first before concluding it's an LFS bug.

And the entry wasn't an AI, was it? You won't get NCN's for them, but of course the NPL should still have the UCID of the owner of the AI.

yeah and what Stuff said - i don't think UCID and PLID are usually the same. Better check your NCN and NPL processing functions
Quote from Stuff :Hmm, if I read your list right, are your connection IDs the same as your player IDs? Thats usually not the case afaik. Connection IDs go from 0 (host) to number_connected (not including AI) sequentially. Your player IDs look right as I think they are semi random. I dunno maybe I'm missing something. And you say its the same user? Maybe check something in the user name that could be throwing off your code? That ^2 and ^3 look unique to me

Nono, both were Unique id's, but also a NPL contains the Unique idea, that was just to check if my own insim didn't mixed up the clients
Quote from Victor :what i'd do next is debug all your received ncn packets (log them in hex before you even process the packet) and see if you actually received all ncn's or not. If you do, there may be a bug in your ncn packet processing. If you don't, then LFS might be omitting something or even weirder.
I've personally not come across missing ncn packets though, unless i haven't noticed. But that's why i recommend to debug at the source first before concluding it's an LFS bug.

And the entry wasn't an AI, was it? You won't get NCN's for them, but of course the NPL should still have the UCID of the owner of the AI.

yeah and what Stuff said - i don't think UCID and PLID are usually the same. Better check your NCN and NPL processing functions

well, I tried that and it didn't receive tho, but I reinited the server and then there were no problems at all.. But I don't think it's an LFS bug, I'm gona start a clean project and add packet after packet (ain't that much work tho) and see where it goes wrong..

weird NCN problem
(8 posts, started )
FGED GREDG RDFGDR GSFDG