I'm having some difficulty finding the LAP struct, I have turned on ISF_RACE_TRACKING and am getting NLP packets, I get SPx packets too, but I dont get anything when a car crosses the start finish line and I really dont know why.

Here is my initialisation for insim

[/COLOR]
[COLOR=black]Function inSimInit()[/COLOR]
[COLOR=black]WriteByte UDPout,Asc("I")[/COLOR]
[COLOR=black]WriteByte UDPout,Asc("S")[/COLOR]
[COLOR=black]WriteByte UDPout,Asc("I")[/COLOR]
[COLOR=black]WriteByte UDPout,0[/COLOR]

[COLOR=black]smallEndian=portIn[/COLOR]
[COLOR=black]While smallEndian>255[/COLOR]
[COLOR=black]smallEndian=smallEndian-256[/COLOR]
[COLOR=black]largeEndian=largeEndian+1[/COLOR]
[COLOR=black]Wend[/COLOR]
[COLOR=black][/COLOR]
[COLOR=black]WriteByte UDPout,smallEndian[/COLOR]
[COLOR=black]WriteByte UDPout,largeEndian[/COLOR]
[COLOR=black]WriteByte UDPout,1[/COLOR]
[COLOR=black]WriteByte UDPout,1[/COLOR]
[COLOR=black][/COLOR]
[COLOR=black]For n=1 To 16[/COLOR]
[COLOR=black]WriteByte UDPout,0[/COLOR]
[COLOR=black]Next[/COLOR]
[COLOR=black][/COLOR]
[COLOR=black]SendUDPMsg UDPout,loopback,portOut[/COLOR]
[COLOR=black]End Function[/COLOR]
[COLOR=black]

Am I missing something please?

Can't see how it would be possible to automatically receive SPx packets without correctly enabling race tracking, thus you should also be getting LAP packets.

Presumably you're responding to the Race Tracking packets as LFS sends them? I dont have access to LFS or an InSim app here to test, but I think (if my memory serves me correctly) if you don't respond using an InSimPack ACK packet you can get a similar behaviour.

I thought that was only if you had guaranteed delivery on, so this is probably it - thank you

Unless I'm being a complete tit, aren't you setting the guarantee bit?

No, it's not clear from above because I didn't use constant, but i'm sending a flag of "1" which is ISF_RACE_TRACKING. I've just tried a flag of "3" which is race tracking + guaranteed delivery and tried sending back ACK packets but LFS keeps resending.

I've tried sending the ACK as a short, a word, and a signed int and none seem to acknowledge the receipt :/.

The ACK packet is very simple and so undocumented, but nothing seems to be accepted by LFS

Quote from Becky Rose :

No, it's not clear from above because I didn't use constant, but i'm sending a flag of "1" which is ISF_RACE_TRACKING.

:doh: of course

Quote from Becky Rose :

I've tried sending the ACK as a short, a word, and a signed int and none seem to acknowledge the receipt :/.

The ACK packet is very simple and so undocumented, but nothing seems to be accepted by LFS

According to the docs its just the following;
So, an Id of ACK\0, and a Value set to the VerifyID. But I guess you've already tried that? If I remember correctly LFS doesn't respond to the ACK packet.

Thank you for your continuing help. With verify on I can tell LFS isn't acknowledging the ACK packets because it resends the split data which i'm putting into the debuglog.

Here is my function that processes the split time data, I hope you can understand it

[/COLOR]
[COLOR=black]Function splitSector()[/COLOR]
[COLOR=black]sector=Chr(PeekByte(bank,2))[/COLOR]
[COLOR=black]id=PeekByte(bank,8)[/COLOR]
[COLOR=black]getPlayer(id)[/COLOR]

[COLOR=black]If PeekByte(bank,3)=0[/COLOR]
[COLOR=black]Select sector[/COLOR]
[COLOR=black]Case 1[/COLOR]
[COLOR=black]split.splittime=driver\s1[/COLOR]
[COLOR=black]Case 2[/COLOR]
[COLOR=black]split.splittime=driver\s2[/COLOR]
[COLOR=black]Case 3[/COLOR]
[COLOR=black]split.splittime=driver\s3[/COLOR]
[COLOR=black]Default[/COLOR]
[COLOR=black]split.splittime=driver\s4[/COLOR]
[COLOR=black]End Select[/COLOR]
[COLOR=black]m=PeekByte(bank,4)[/COLOR]
[COLOR=black]s=PeekByte(bank,5)[/COLOR]
[COLOR=black]t=PeekByte(bank,6)[/COLOR]
[COLOR=black]reportSector(id,split,m,s,t)[/COLOR]
[COLOR=black]EndIf[/COLOR]
[COLOR=black][/COLOR]
[COLOR=black][/COLOR]
[COLOR=black][/COLOR]
[COLOR=black]littleEndian=PeekByte(bank,9)[/COLOR]
[COLOR=black]largeEndian=PeekByte(bank,10)[/COLOR]
[COLOR=black]sendVerify(littleEndian,largeEndian)[/COLOR]
[COLOR=black][/COLOR]
[COLOR=black][/COLOR]
[COLOR=black]DebugLog("Car: "+id+" sector "+sector+" "+m+"m"+s+"s"+t)[/COLOR]
[COLOR=black]End Function[/COLOR]
[COLOR=black]

The important stuff is right at the end where I take the 10th and 11th byte (bank starts at 0) of the SPX packet struct and store them in two int's.

Here is where i'm sending the ACK packet back too LFS

[/COLOR]
Function sendVerity(littleEndian,largeEndian)
[COLOR=#aaffff][COLOR=black]WriteByte UDPout,Asc("A")[/COLOR]
[COLOR=black]WriteByte UDPout,Asc("C")[/COLOR]
[COLOR=black]WriteByte UDPout,Asc("K")[/COLOR]
[COLOR=black]WriteInt UDPout,(largeEndian Shl 8)+littleEndian[/COLOR]
[COLOR=black]SendUDPMsg UDPout,loopback,portOut[/COLOR]
[COLOR=black]End Function[/COLOR]
[COLOR=black]

"Shl 8" in case you are unsure is a binary shift left of 8 bits, it's the same as "*256" which I have also tried just to be sure it wasn't that (shl 8 is faster which is why I use it).

[/COLOR]

EDIT: Sorry for the lack of tabulation, the forums dont seem to support it

OMG no 0 byte !

EDIT: Still no luck

I even tried reading the two verifyId bytes into an int and just sending that natively.

[/COLOR]
[COLOR=black]verify=PeekShort(bank,9)[/COLOR]
[COLOR=black]sendVerify(verify)[/COLOR]
[COLOR=black][/COLOR]
[COLOR=black]End Function[/COLOR]

[COLOR=black]Function sendVerify(verify=0)[/COLOR]
[COLOR=black]WriteByte UDPout,Asc("A")[/COLOR]
[COLOR=black]WriteByte UDPout,Asc("C")[/COLOR]
[COLOR=black]WriteByte UDPout,Asc("K")[/COLOR]
[COLOR=black]WriteByte UDPout,0[/COLOR]
[COLOR=black]WriteInt UDPout,verify[/COLOR]
[COLOR=black]SendUDPMsg UDPout,loopback,portOut[/COLOR]
[COLOR=black]End Function

Edit: Nevermind, you'd already noticed the lack of 0 byte still looking (note: this is why I dislike vb )

/shrug - i've never used vb. This is Blitz, which is a good language that would be a great one if it had strict.

Found it ! The offset where I was reading in the verify was wrong. I thought I was reading Unique ID but apparently I was reading playerNumber instead, so when I read the next byte it was giving me uniqueID and the first byte of verifyID.. So now I am sending ACK packets correctly.

I just need to find out if that translates to LAP packets being received now - I hope this lot i'm watching restart soon

I'm still not getting lap data though - with no packets in the acknowledge que.

Bleh, syntax-wise they're pretty similar. I realised my mistook after looking for the PeekShort function

I'm obviously being horrendously dense, because I'm not seeing the problem Not using a test patch by any chance?

I am using outguage for this mod too, is it possible that outguage is not compatable with the LAP struct? I read something about outguage changing from 92 to 96 bytes when activated via insim because of something to do with the LAP struct, but the post wasn't that intelligeable to me. However my outguage packets are 92 bytes so I don think i've been effected by this.

Yes U16. It's a valid point I will try a fresh install.

I just did a fresh install directory and that did the same thing - i'm still getting no LAP struct. *cry*

Having not yet used outgauge properly, and not being able to recall that discussion, I can't go by anything but the docs\InSim.txt I've got infront of me According to that, regardless of how Outgauge is being turned on, the only way to identify the outgauge packet is by is size and the 4th byte

Given that, how are you checking the packets to see if they are an IS_LAP packet?

I'm detecting LAP (and others) by the first three [char] bytes = "LAP". I have a debug console that displays the length and first three bytes in [char] format of all unprocessed packets, and currentkly this fills with NLP's. I don't see any unrecogniseable packets, so i'm fairly sure LFS just isn't sending them.

Is it only ISF_RACE_TRACKING that needs to be on? I tried setting the MCI packets on earlier, but I wasn't ACK'ing packets then.

Yeah, ISF_RACE_TRACKING should be the only flag thats required. I'm having a poke around trying to find the InSim test app I wrote some time ago right now, maybe that will shed light on something I've forgotten

Edit: Presuming Blitz follows the same structure for select statements as everything else, have you tried adding a call to DebugLog to see if it picks up anything?

Quote :

have you tried adding a call to DebugLog to see if it picks up anything?

What like the one in the code example above ? *snicker*

Thanks again for your help with this Angry Angel, i'm completely baffled atm.

Quote from Becky Rose :

What like the one in the code example above ? *snicker*

Assuming it even resembles your "real" code, unless I'm being a complete dork (highly likely) the only case you're calling DebugLog in is LAP, whereas I meant the default case

Quote from Becky Rose :

Thanks again for your help with this Angry Angel, i'm completely baffled atm.

We've not fixed it yet

Quote :

the only case you're calling DebugLog in is LAP, whereas I meant the default case

oic, yes all packets are dumped to the debuglog anyway, it's just that if I do pickup a LAP one I get that extra line as a marker to make sure I see it.

Funky monkeys. Shame that doesn't help much though.

I'm still digging around for my InSim app between ironing and stuff. It's backed up *somewhere*....I think :o Might've been quicker just to write it again from scratch at this rate