Rhama, any data can be sent from client to server by using /i command even in current patch. What was suggested is server->client communication.

Quote from EQ Worry :

Finding car nodes and the resulting positions are relatively expensive operations

This shouldn't be too expensive, if you only do the full "search for node" on each car at the start of the race or when they leave the pits. Then each time you receive an MCI you only have to check each car's position against the direction and position of the next and previous nodes to see if their line has been crossed. All LFS guests and hosts do it with minimal CPU usage.

Something like this I guess.


One thing about LFS is you can just install the software and you can go and join any host you see in your list. It's a pity if you don't get the full experience without installing some extra software. We'll start to lose something if LFS isn't so easy to use and people need to figure out how to install InSim programs and find out how to connect them.

Scawen, anything about what I posted on #112?

Quote from morpha :

Rhama, the situation you describe still requires the user to install a local InSim application. Now why would anyone with malicious intent bother to transmit the info via LFS when he can spread an application capable of doing virtually anything he desires?

There is no security issue with allowing bi-directional hidden communication, the issue is always the client-side InSim application itself.

It can happen to anyone when you trust someone that you should not. It's also the nature of compiled languages, you just don't know what's running on your system.

Quote from Scawen :

This shouldn't be too expensive, if you only do the full "search for node" on each car at the start of the race or when they leave the pits. Then each time you receive an MCI you only have to check each car's position against the direction and position of the next and previous nodes to see if their line has been crossed. All LFS guests and hosts do it with minimal CPU usage.

Indeed, I do it in a similar way, full node search done just once, then expecting the car to be in the same node, or one or two nodes ahead or one or two back. Only if all these fail, full search is done again.

But still, I would see a great advantage in doing all this node checks and position calculations at the server, sending only results to client InSims. If all clients were to do this, they would all have to include the current custom PTH files and all the code of these calculations, which seems an overkill to me.

Also, for users that would just complicate matters, because if new PTH files are available, they'd need to install them. Having a way to send race position PIDs to clients seems to me as a very nice shortcut. Most clients would ignore such data, some may process it in local InSims.

Quote from Scawen :

One thing about LFS is you can just install the software and you can go and join any host you see in your list. It's a pity if you don't get the full experience without installing some extra software. We'll start to lose something if LFS isn't so easy to use and people need to figure out how to install InSim programs and find out how to connect them.

I completely agree, I would never require the use of a certain client InSim, I know it can be too complicated for many to set it all up properly, even though it may take setting up just 2 or 3 parameters.

I remember that "unnamed" matter, people being kicked by Airio just because they had no nickname. I changed this long time ago, so that now unnamed people just cannot join the race (if admins choose so) and they see messages both in chat and using BIG buttons what should they do to rename.

On the other hand, there's the question of "full experience". For example Aonio, the client-side InSim I'm developing, offers a lot of additional data, like position list with live time differences and their tendencies on splits, car types, penalties, pit stops, correct race positions on multiclass servers, live time/speed comparison with a PB lap, min/max speeds in configurable sections, even a not-so-realistic-but-very-useful radar display showing car locations around/behind you, etc.

For me, full experience from LFS includes all such data, with customizable display and positions on screen, local PBs, remaining fuel laps estimate... Receiving additional data processed at the server (Airio) can make some things more precise. E.g. the race positions can be for Aonio users connected to Airio managed server more precise and updated say every second or two, not just at splits. Also, receiving info about the fact that this is a special half-official track (certain open site + specific layout) makes managing local PBs simple. New layouts are loaded at server, new tracks defined in Airio, clients just receive all the updated info.

Ouch, sorry for these lengthy explanations. In short, ability of client InSims to receive additional info from server InSims can have its uses, I think. I do not see security problems (though I may be short-sighted), as there are already ways to send infos both ways, just not invisibly from server to clients. On the other hand I perfectly understand your concerns. Airio is a large system and quite wide-spread now. It manages many servers in ways that maybe were not your intentions. But I would still hope it is overall perceived as a good thing, especially for the demo servers which are extremely hard/impossible to manage using standard LFS options alone.

Just a quick note about a small change.

In Z32, which I am still aiming to release today, I have changed the meaning of the /cv command.

I realised that there was still no way of removing all game votes, until the vote was activated (majority reached).
So I've made that /cv remove all game votes even if not yet activated - but not affecting the kick / ban vote.

So the two are now separated :

/ck - no change - cancels kick / ban vote
/cv - remove any game votes (restart / end / qualify)

Aaahh, very nice, thanks! Yes, indeed, even the vote canceling packet worked (works?) only after majority was reached, that means in the 3 seconds after restart/qualify/end countdown actually starts.

Quote from EQ Worry :

Aaahh, very nice, thanks! Yes, indeed, even the vote canceling packet worked (works?) only after majority was reached, that means in the 3 seconds after restart/qualify/end countdown actually starts.

Now you said that, I've made IS_VTC do the same thing now as well.

One more small thing I might as well tell you in advance.

There's also one new "Timing" byte in the IS_RST packet :


I added this when I did a similar thing for the LFS World equivalent.

Uhm, I'm not sure what these timing options mean. Anyone please point me somewhere where I could learn more? (How to choose timing, what could it be used for...) Thanks!

They aren't really options, it's just information sent when the race restarts.

standard timing : an official LFS track
custom timing : user placed checkpoints
no timing : car park / X / Y with no timing

I think it could be helpful for some InSim programs to know how many checkpoints there are and if lap timing is enabled.

Understood now, thank you! Also thanks for some of the InSim changes, the OG_CTRL and OG_SHIFT bits.

Can z33 have adding/moving/removing objects via InSim, please? That will be awesome and will give you some time to make new physics, Rockingham, Scirocoo while we will be making new type of cruise and drift servers.

Quote from EQ Worry :

Understood now, thank you! Also thanks for some of the InSim changes, the OG_CTRL and OG_SHIFT bits.

Thank you for asking the question, I was thinking I was being some what dense yesterday when I read that and just did not understand it at all.

Can anyone explain to me, why lfs ignore FOV value in IS_CPP packet with inGameCam = VIEW_CUSTOM and flags = VIEW_OVERRIDE (worked only in SHIFTU mode), its a bug or feature?

If it normally, maybe add Note in InSim.txt

ps test in z28 version

Anyone noticed that there are some LFSW messages in Z32 open tracks? It is really strange and confusing, because I make like 10 laps on some layout (say F11) and then suddenly I see "LFSW - this was your first lap...", next lap shows "LFSW - new PB by ...", but /w pb returns something like "LFSW - PBs are not stored for open tracks". What am I missing? Is that a LFSW bug or how/where can it store open track data? Any ideas?

I can see only one explanation: It is somehow (maybe unintentionally) storing lap times for e.g. FE1X+XFG, any layout. Then it reports all lap time improvements, again without distinguishing between layouts. If that's really the case, then I believe the LFSW messages should not be shown at all because they have zero value. Maybe if Scawen or Victor read this, can you please confirm my assumption? (I was already mentioning this in the main Z32 thread, without response.)

those pb's shouldn't be stored then, no. I'll have a look why apparently they are.

Quote from NeOn_sp :

I think I have found a bug in SPX.

By definition, on Lap 1 in practise mode, STime and ETime must have 3600000 (1 hour) value.

When you play in a server for more than an hour ( or the game in that server started 1 hour ago), SPX sends instead of that 3600000, the time of the game started.

Replay #2: http://www.mediafire.com/file/cppk3iauf2zay0z/replay2.mpr
Replay #1: http://www.mediafire.com/file/dndo091rk5at7ni/BugInsim.mpr

...

Edit: Add replay 2.. Cleaner than first..

OK, I see why this happens. If it's the first lap in practice or qualifying mode LFS just makes sure that split (or lap) times are one hour or more when it sends the packet. This indicates to the packet receive function not to display split times, lap time, or record a qualifying lap in this case, where the time is really invalid. It does allow the split or lap to be greater than one hour - I think the idea is so that it only makes the split or lap time longer than it really is, and never shorter.

It doesn't really seem to be a bug. Does it cause a problem? I guess it depends what you are trying to do. LFS just isn't really interested in split or lap times longer than an hour, so that's why it uses this method to indicate that it shouldn't do anything with this information.

Quote from kutu :

Can anyone explain to me, why lfs ignore FOV value in IS_CPP packet with inGameCam = VIEW_CUSTOM and flags = VIEW_OVERRIDE (worked only in SHIFTU mode), its a bug or feature?

If it normally, maybe add Note in InSim.txt

ps test in z28 version

Yes, this appears to be normal, the FOV is ignored in this case. The documentation only says that Heading Pitch and Roll will be taken from this packet (if ISS_VIEW_OVERRIDE is set). I've now added a note in InSim.txt to make it clear that the FOV will not be used.

I'm sorry for bringing this up this late, but could I make a small request regarding OutGauge? Would it be possible to use the last spare byte to send PLID of the car whose telemetry is contained in the packet? Recording live telemetry is kind of impossible if player switches view to another car.
I can't rely on ViewPLID in STA packets because there's no way to ensure they always arrive before OutGauge packets when player switches view.

Quote from Scawen :

OK, I see why this happens. If it's the first lap in practice or qualifying mode LFS just makes sure that split (or lap) times are one hour or more when it sends the packet. This indicates to the packet receive function not to display split times, lap time, or record a qualifying lap in this case, where the time is really invalid. It does allow the split or lap to be greater than one hour - I think the idea is so that it only makes the split or lap time longer than it really is, and never shorter.

The problem is that I though that I should be always 1 hour, exactly 1 hour.

So, in my League Qual InSim, I was comparing SPX with 1 hour to know if it´s in warm up lap, and don´t store splits then.

But no problem then, I have changed the comparation to >= 1 hour and ended.

Thanks for reply.

Scawen, first, BIG thanks for all the already implemented new features! Marvelous stuff. Here I dare to mention three more things, maybe not exactly InSim matters, but closely related, I hope:

1) One thing that, well, annoys me quite a bit is that the char "1" is narrower than all the other numbers. This is very unusual, because most fonts keep all the numbers of the same width, for easy aligning. Now if there's a LFS button showing fast changing numbers, the numbers tend to jump around instead of keeping their places. Is there please any chance to make the char 1 the same width as the other numbers?

2) LFS clients support at least 2 more colors that cannot be used by InSim apps, dark gray (when someone disconnects), and light red (when someone is banned). Is there any chance to make these colors (plus possible additional ones) available? I think somebody already asked for this, but I'm not sure if there was any answer.

3) Below the race control message area on screen there seems to be a smaller (and not much used) space for additional info. It displays info e.g. at the race start when pit stop is required. Could this line become available for changes/display, probably using some new commands similar to the RCM ones?

Scawen, of course none of the above is anything major, but if they seem reasonable (especially point 1) and correction/addition is possible and simple, maybe they could be part of some patch.

And how about that server to client (and vice versa) hidden communication, is it still considered a security issue or do you plan to add this in the future? Just so that I know which way to go concerning Airio/Aonio information exchange. Thanks again for all the work and answers!

PS: There is also light blue color when someone is connecting and light orange when showing race results...

I would love a whole patch update process for just InSim requests, I think what the 3rd party devs could add to the community could be huge.

Quote from MadCatX :

I'm sorry for bringing this up this late, but could I make a small request regarding OutGauge? Would it be possible to use the last spare byte to send PLID of the car whose telemetry is contained in the packet?

OK, I have changed OutGauge SpareB to PLID.

Quote from EQ Worry :

1) One thing that, well, annoys me quite a bit is that the char "1" is narrower than all the other numbers. This is very unusual, because most fonts keep all the numbers of the same width, for easy aligning. Now if there's a LFS button showing fast changing numbers, the numbers tend to jump around instead of keeping their places. Is there please any chance to make the char 1 the same width as the other numbers?

OK, I've done that now and it will be in the next test patch.

Quote from EQ Worry :

2) LFS clients support at least 2 more colors that cannot be used by InSim apps, dark gray (when someone disconnects), and light red (when someone is banned). Is there any chance to make these colors (plus possible additional ones) available? I think somebody already asked for this, but I'm not sure if there was any answer.

3) Below the race control message area on screen there seems to be a smaller (and not much used) space for additional info. It displays info e.g. at the race start when pit stop is required. Could this line become available for changes/display, probably using some new commands similar to the RCM ones?

I don't know yet, I can't really think of these as a high priority at the moment with a lot of other things on my list.

Quote from EQ Worry :

And how about that server to client (and vice versa) hidden communication, is it still considered a security issue or do you plan to add this in the future? Just so that I know which way to go concerning Airio/Aonio information exchange. Thanks again for all the work and answers!

I still don't have a very good feeling about this. I don't get excited about it and I do feel negative about it.

I think if I have to do this, then InSim has failed in its mission. The idea is that a user can install LFS, with no additional software, go online and join the hosts that are out there. They should be able to get the full experience, same as anyone else, without installing anything else. I do not want to make it harder for them.

I do want to provide the packets you need to do what you have to do from a host controller only. I realise that this takes time because I have to do a lot of other things.

I would prefer in each case to understand the problem you are having, the thing you are trying to implement, which cannot be done from the host side, then I can code a new packet to allow your planned feature and more.

There was a problem with demo racers joining "demo" hosts which had previously allowed non-demo cars and then demo racers getting an OOS kick, unless of course they had cracked the game, in which case they did not get an OOS kick, so I had to make a change today. Now, when the allowed cars are changed with the /cars command, anyone who is driving a disallowed car will be instantly spectated.

I realised that could sometimes cause a problem, if for example a host only allowed formula cars but occasionally swtched temporarily to allow a safety car to join.

So I thought I'd better quickly implement an old request which is to be able to specify which cars an individual player can drive. So here's the new packet, in case you have any comments about it. This does not allow anyone to drive any cars that aren't actually allowed on the host, but it can limit their selection within the allowed cars.


P.S. Is there any way to specify TAB size in CODE blocks?