Background: I'm creating a new InSim app for my team and I have a couple of simple questions. I'm using the very handy JInSim Java library.

Question 1: I'm trying to monitor when track changes happen. I'm using the hostXXXX.txt file (the one that's created when the dedi host is running) to determine the current track and car(s) enabled. The only way I can track track changes is to listen out for StateResponse packets and perform a check against the current track combo (by querying the above file) and doing a comparison against what the combo was the last time I got a StateResponse packet. This doesn't seem to me to be a very good way to do it (lots of checks, lots of disk accesses). Is there a simpler way to listen out for track changes? The other way I was thinking of doing it was listening for a message by connectionID 0 (the host) saying "Track loaded" but I don't know if that would cover all situations.

Question 2: What's the best way to listen out for changes to the enabled car(s)? At the moment I'm using the same mechanism as above (checking host file) but I can't help thinking there's a better way.

Thanks in advance for any help or advice you can give

1. Can you not just check the track when the program connects and store it in a variable? Then compare the variable and the track in the ISP_STA packet.

2. I don't know if there's a way to obtain the allowed cars by InSim, so on first connect you might have to read the host file. From then on you can detect '/msg cars=blah+blah', (ISP_MSO I think) and check it against what's allowed at the moment.

I don't see it being a big issue reading the cars from the host file though, but don't take my word for it

Quote from NotAnIllusion :

1. Can you not just check the track when the program connects and store it in a variable? Then compare the variable and the track in the ISP_STA packet.

I can't do this at the moment because I'm relying on reading the host file when I receive the StateResponse packet (to check for car changes). If someone can point me in the right direction of finding a way to listen for car changes I can just use the track code from the StateResponse and compare it rather than doing the file IO I am at the moment. I'd like to move to this solution but my hands are tied at the moment.

Quote from NotAnIllusion :

2. I don't know if there's a way to obtain the allowed cars by InSim, so on first connect you might have to read the host file. From then on you can detect '/msg cars=blah+blah', (ISP_MSO I think) and check it against what's allowed at the moment.

I don't see it being a big issue reading the cars from the host file though, but don't take my word for it

I've tried to listen for the MessageResponse when I type in the /cars command but I don't see one being sent. It looks as though LFS is keeping it internally and not relaying it to InSim (I could be wrong though...hopefully). The reason I don't want to be checking the file all the time is because it's disk IO. It hurts in terms of time plus there may be file locks (if the program and LFS access it at the same time).

Thanks for the quick reply

Oops, I misread question one. Thought it was just about track change. I don't think there's any way to detect changes in allowed cars directly via InSim.

Though, one option would be to 'proxy' the car change: If you have a custom command e.g., !cc FXO+XRT you can now detect when, where and who is changing the cars, without reading the host file. If you store the cars string in a variable you can compare it when you get a different track in the StateResponse packet.

Quote from NotAnIllusion :

I don't think there's any way to detect changes in allowed cars directly via InSim.

I was fearing that might be the case but hoping it wasn't.

Quote from NotAnIllusion :

Though, one option would be to 'proxy' the car change: If you have a custom command e.g., !cc FXO+XRT you can now detect when, where and who is changing the cars, without reading the host file. If you store the cars string in a variable you can compare it when you get a different track in the StateResponse packet.

I think I've seen that done before somewhere (maybe it was lapper) but I don't like it. It's something I'll bear in mind but I would take my current solution over this way I think. Thanks though