The online racing simulator
LFS doesn't send state packets if you're the one making changes to state pack?
Hiya.

So I was running LFS TV Director and another insim program at the same time. The other program is triggered to do something whenever a state packet is received. However, if you use tv director LFS (apparently) stops sending those packets that would normally be sent when changing view or viewed player.

Why is that and is there any smart way of getting that info in some other way?
I'm not sure I can answer your question, however I just tried running TV Director and InSimSniffer at the same time, and I was successfully getting STA packets. In fact, I can't think of any way that another program could *stop* LFS sending packets to your app, unless there was a bug in LFS (unlikely). This would suggest to me that this is the manifestation of a bug in your own code, rather than an issue with TV Director.
#3 - Krayy
I've also noticed that in LFS Lapper if you sned a TINY_SST, then a STA does not get sent to InSim Sniffer if it's connected to the server but it does get sent back to the Lapper instance. This also works the other way, where a TINY request in Sniffer does not egt sent to Lapper (TINY_REO for instance). This would indicate to me that responses to TINY_* requests are linked to the session requesting them.
Well yes, requests only get sent back to the connection that requested them, that makes sense really. I've remembered as well that InSimSniffer has a reserved ID of 254, so if a packet is sent with that same request ID InSimSniffer won't display it, because that's the ID it uses to maintain its own internal state*. That might indeed cause some confusion, as if you request a packet with an ID of 254, InSimSniffer won't display it. This was mentioned in the FAQ, although that seems to have disappeared somewhere. This might be a flaw that needs correcting :P.

* Although InSimSniffer is designed to show you exactly what InSim is doing, this is actually an illusion. It has to maintain its own internal state and does this by making its own series of InSim requests under the ReqI '254', which it then hides from the user. For some reason a long time ago I decided that 254 was a benign request ID that anyone else was unlikely to use, and while it used to be mentioned in the FAQ that 254 was a no-no, it seems the FAQ itself has gone bye-bye.

Note: You can see the ReservedId of 254 set in the source repository.
Quote from DarkTimes :Well yes, requests only get sent back to the connection that requested them

Yes, that. I didn't mean I LFS stopped sending packets completely, I can still request the state packet (or any other) at will.

As I understood it, LFS should send a state packet when ever something in it has changed. However, if the change has occurred because of an instruction being sent over insim, then the state packs will wont be sent anymore.

For the record, I ran Tv Director with Insim Sniffer, and it did not show state packets being received when view is changed or viewed player is changed. The state packets that were received were triggered by other events, such as pausing the game.
Right, after a while it occurred to me that perhaps LFS doesn't send the state packets because there are no state changes! What tv director does is basically going to shift-u mode and then it somehow figures out where cars are and focuses the 'cameras' in the correct place - therefore there are no view changes that LFS reports.

So my follow up question is, is there any way of determining the viewed player in shift-u mode?

FGED GREDG RDFGDR GSFDG