Dave, remember that after that post, I added a backward compatibility system to continue to support Airio, so it was unaffected by the change to those packets.
So although your post might be an example of something that could happen, it's not really an example of something that has happened yet.
But I hope the InSim system gets more advanced at some point where you need to make so many changes (button colors/ text colors for example) that it gets too much of a burden to support backward compatibility. You warn about that in this particular thread (I sort of hope people can read it). Last year there was not so good replacement for race trackers, but LFSTop and KingTracker (PHP => I like) are making it's way to my surprise. These initiatives get more advanced if usage would increase, so lets see. It only increases if LFS racing increases, hopefully you dev guys can make some more steps this year towards that goal.
As far as I understand, the backspace key was used by older InSim programs because they need or needed to send keypresses to LFS. For example to switch lights on or off. And the problem was that if a chat box was open, the characters would mess up the chat, so they used to send a delete keypress straight after the character.
Obviously that was a bit of a hack and it all went wrong when the virtual keyboard was introduced.
I then coded to avoid that problem altogether. There is a new flag ISS_TEXT_ENTRY which is part of the Flags word in the IS_STA packet.
So now you just shouldn't send keypresses when a text entry is open. And then you don't need to send backspace keys.
Also, to reduce the need to send keypresses at all, I did code a new packet SMALL_LCS which operates car switches, signals, flash, headlights, horn, siren. And that packet works even if a text entry box is open.
So as far as I know, it's all solved and the only problem is that older keypress programs don't work properly any more.
If there is a specific use case that isn't covered please let me know about it.
hello all, I just bought s2 license today mainly because everyone says how good VR implementation is in LFS. Unfortunately looking to the side you can see an interruption in the movement of things like trees or whatever is not at the same speed of the car. Read somewhere it was related to the response frequency of the physics being 100hz and the oculus rift being 90hz. Is there a possible solution for this from the developers? or is it a lost case? thanks
That's something I'm interested in working on but it's a really big project to sort out. We need graphical frames in between physical frames, or alternatively 1000 Hz physics update rate. The solution will probably be connected with having physics and graphics on separate threads.
I'm interested in looking into this after the new tyre physics system is finished, which will allow many things to start happening.
40 is enough for racing, otherwise you get stuff like what happened on Bathurst last weekend with 50+ cars. More a parade then quality racing and every X minutes a safety car (zzz...). I do agree that for open layout it should/could be massivly more. Like 128 for example. But that is a lot of work, Scawen explained this earlier, it's not just simply increasing a number. And as always; "first, tire physics"..
Bathurst is crazy cause it is like 1 meter wide.... They shouldn't hold multiclass there and i should be limited to 40 cars there. As for LFS, all of the tracks are wide, even south city is very wide for a street circuit, so, i wouldn't see a problem with more people.