Insim problem: "position" in IS_MCI/IS_NLP is always zero
This is very confusing. First I thought the problem was my app, but I checked, and the packet analyzer shows, that the rest of the packet is perfectly ok. For example an IS_NLP: ( 0C 25 00 01 24 00 03 00 04 00 00 00 ).
Tested on W43 and W47, with 1-6 players - same thing.
1) 0C is that the length of the IS_NLP packet? Shouldn't that be 84 (hex)?
2) there is no position indication in a nodelap packet (see your post title)
3) what is the problem you are aiming at? Just the bold 00 doesn't tell me much tbh
struct NodeLap // Car info in 6 bytes - there is an array of these in the NLP (below) { word Node; // current path node word Lap; // current lap byte PLID; // player's unique id byte Position; // current race position : 0 = unknown, 1 = leader, etc... };
struct IS_NLP // Node and Lap Packet - variable size { byte Size; // 4 + NumP * 6 (PLUS 2 if needed to make it a multiple of 4) byte Type; // ISP_NLP byte ReqI; // 0 unless this is a reply to an TINY_NLP request byte NumP; // number of players in race
NodeLap Info[32]; // node and lap of each player, 1 to 32 of these (NumP) };
Thanks for your reply!
1) x0C is 12 and is perfectly fine as (4 + 6*1 + 2).. or am i missing something?
2) well, the InSim.txt says otherwise this might be one of the new features.
3) the problem is that byte 'position' is always zero.
right, i had an old version of the InSim.txt .. yet i did get the latest patches. Anyway, I now seem to have the proper insim.txt from w47 and yeah you're right. Sorry
I'm not sure which part of code you need? Because after I send an IS_ISI the problem is not in my code (as packet analyzer proves).
Edit: I'm also having troubles with IS_RST, which gives me Finish, Split1, Split2, Split3 all equal to 65535.
And yet again, the packet analyser gives the same info, here's the complete packet exchange (I hope that helps):
The very first IS_MCI has Position 0, while any other values are already filled. But the next IS_MCI have correct Position-values...
Checked with W47 in Single-Player mode, connection type TCP. Both requesting IS_MCI with IS_TINY and waiting for IS_MCI because of 'interval' set in IS_INI works fine here.
hmm i'm currently doing some insim stuff as well and actually noticed that at some point the mci packets were all the same. I could drive all i wanted, but no value at all changed. This was with w47.
Then I tried W45 and that worked.
Then went back to W47 and there it worked again strangely enough.
Haven't been able to reproduce it ever since unfortunately. But it does look like there's _some_ bug there.
i think there's a circumstance that LFS doesn't know where a car is anymore and then you get these static packets.
a related issue i encountered earlier when i had the static packets was that on autox with layout and route-checkers, the route checker did notice that i missed some checkpoints and lfs msg'd in red "wrong route", but it did not kick me.
Now, with working mci packets, if i take a wrong route, it kicks me as it should.
I noticed when it all worked, and I joined a race with my car, the first 3 mci packets also looked like this, but then started working.
Looks like some starting values for mci and then it just either gets stuck on them or fixes them.
Knu and Victor, you are talking about two different things.
Knu's "position" is also known as the "race standing", i.e. your current position in the race, 1st, 2nd, 3rd, etc. Victor's position is the car's location. I don't think these are LFS bugs and now I'll explain in each case.
OK, well I don't know what the actual problem is, what issues does it cause?
Position "0" just means that LFS hasn't worked out the race standings. As it involves searching through all the cars, and comparing each car with the others in the list and doing a sort, I don't do it every frame, it's done approximately once per second. So the "position" isn't 100% accurate and lags a bit behind real time, 3rd place man could pass 2nd place man and for a second his position would still be 3. In the case when you only have one car in the race, LFS doesn't bother to work out positions, so you are not in a list position list and the result is zero.
Does that help? If I know what you want to achieve and how this causes a problem, this will help me to consider it more.
Are you running a host on Wine again? That sounds identical to your issue that when we went on one of your wine hosts, after a minute or two, no-one could see any more cars and also it was impossible to join your host - the reason being that your host stops receiving UDP packets.
If the host isn't receiving position updates then the symptoms would be as you described, plus no-one could join that host and no-one already on the host would be able see anyone else's car.
I'm talking about the multiplayer guests, the people who joined the host and are driving cars (not the InSim clients). Their cars position packets are always sent to the host using UDP.
I was suggesting that Victor's problem was that his host stopped receiving UDP packets from his guests, and that's why his MCO packets always reported the same car positions, even though his InSim connection continued perfectly well.
this might be one of the new features.
