Cargame has been poking and prodding me for literally years now over the LVS plugin. The plugin verifies that each player's vehicle is on the track at all times. It currently only supports official tracks, using Node information within the packet. The next step is to enhance it to use custom pth files. To make sure this is as fast as possible, as we are talking potentially about doing this over 250 times a second, I've been looking up some solutions. The slowest solution in theory should be the standard PHP array. Then comes SPL (Standard PHP Library) Fixed Arrays and R* Tree using SQLite databases. These two are what I'm going to be testing to see what is faster ... let the battle commence!

Quote from Dygear :

Cargame has been poking and prodding me for literally years now

Excellent initiative!

I made something similar, unless I didn't understand what your planning to achieve. At the moment I have a method returning a bool (InsideConvexPolygon()). I then process the players info to choose from this enum:

• ON_ROAD
• ON_ROAD_RIGHT_LANE
• ON_ROAD_LEFT_LANE
• OFF_ROAD_GRASS
• OFF_ROAD_OOB

I don't see what use it can have though except to check if a car is idle on track, driving wrong way, going off road to often.

What I don't understand is how you can do this every 4ms since the IS_MCI interval has a higher limit. Would you use "predictory points" to anticipate where a car is going to drive to based on the previous locations, heading, speed,...A few months ago I had fun making my own paths. It worked well except:
• Have to find a better way to make the custom path (using SMX perhaps?)
• Autocross checkpoints have limitations, I tried making custom checkpoints method but it had precision issues (100ms variance)

If your goal is to make new LFS .PTH files I'm all ears

Quote from sicotange :

I don't see what use it can have though except to check if a car is idle on track, driving wrong way, going off road to often.

Cutting the track etc.

It's basically the most important tool for any server; knowing where somebody is with his/her car. For cruise servers it's not that critical but the racing environment needs to have something fast and accurate to determine position.

I thought of reducing the amount of data but if you do that too much you get something like this; http://www.claassen.net/geek/b ... ng-with-xaml-and-lfs.html

It's interesting to analyze. The problem is, I don't have enough time, energy, knowledge to figure this out on my own :/ ... It's however the key element missing to do awesome things. I didn't annoy avetere yet.

// lets do that

That's where I'm lost. In my eyes the main difficulty is the interval limitation. If you cut a corner you have to catch the event in a short amount of time. I'm not convinced the IS_MCI interval is low enough to detect a corner cut event. 40ms seems to be the LFS limit, I wonder if that's fast enough.

If the amount of nodes hammers performance to much your link seems to be an option. I wanted to visualize it for myself so I made the screenshots below, unfortunately the example below is probably a bad one, I should have taken a chicane or tighter corner. Either way I think using only a quarter of the nodes could still be enough, provided the IS_MCI interval is low enough. Unless I'm missing something I still think the MCI info updates is the key.

Airio already works like this and as far as I know flawlessly.

I haven't tried that but can't you use IS_HLV for this? I guess this would suffice is most cases where you need to check if a car is driving on a "legal" path. You could also define some zones where it would be legal to veer off track a bit (AS Nat final esses come to mind) and check against those using coords in CarContOBJ struct.
On the other hand if you want to check if a driver gained some advantage by cutting the track or if he just spun out of control, you'd have to use a custom system (IMHO). Perhaps a set of polygons that cover the entire track generated from the track nodes? This should allow you to detect cutting the track and maybe even calculate how big an advantage the driver gained...

Hello programmers! It is by pure luck that i saw this thread, it being viewable from the main forum page with highlighted last post and name of the topic, so it intrigued me

While i have zero programing or insim knowledge i have sufficient Airio path check validation experience (which is the only real-time online lap verification widely used in LFS nowadays to my knowledge) to share my advice on the subject which i hope will help you make it better.
The guy who made airio, EQ Worry, among other features made the path checks for official and unofficial tracks. This was uber hard and tedious work because of having to put custom nodes all over each track, then test and re-test. Tedious stuff all in all but he did a great job. This was wanted because there was no easy way to check online top tables for 'legitimacy'. So that problem was solved, the new problem was having to memorize invisible 'legit' track on top of the real one because the nodes were not placed perfectly, following the track boundaries pixel perfect so to say. More then a few places by a few meters off. Highly irritating but hey better this than nothing.
Shorty after that painstakingly job being done Scawen trolled him by putting HLVC packets into insim negating the need for any nodes . Those packets are probably called IS_HLV, like MadCatX said, and what they do is check for wall collisions, more then two wheels on grass thingy (exactly the same as HLVC) and probably car touches, both official tracks or custom layouts, path file or no path file. But what they don't do is checking draft. For that we would need those nodes but at a much lesser accuracy resolution. And that is the whole deal - HLVC packets for everything but the draft covered.

Why those hlcv packets were not put into airio when they were released? Who knows. Another guy with his own server lapper put them few hours upon release. Few years later, seeing this initiative i had to post this. If the ball gets rolling i hear word that speed hacks might also be checked and invalidated. We live to see.

Those packets you talk about are being used in Airio. There is collision detect and there is also a draft check.

However with some flaw. (You can gain advantage by drafting on the previous lap into the next one. The next lap will still be seen as a valid time).

But hhmm.. I don't know how this HLV works with custom tracks. The thing is that LFS doesn't use PTH files itself so it doesn't know where 'ground' is. I think.. (?) .. Need to check.

Quote from cargame.nl :

I didn't annoy avetere yet.

// lets do that

How very annoying of you

Anyway, I don't really see, how I can be of too much help this time, as I didn't get, where the problem actually is.
Is it getting the track data, or getting the car info from lfs or simply processing it all.
In that case: There should be lots of optimization possible regarding the algorithm. I don't now, how you are donig it at the moment, but a combination of two "in_polygon" calculation (inside for outer track boundaries, outside for inner buondaries) should do the trick. There are plenty of was of doing it, though. I nice overview is here:
http://erich.realtimerendering.com/ptinpoly/

The problem is speed of the algorithm. One car (C), on one track (T), on one node (N) using one point is one calculation, and that's what we offer with the MCI packets, with the official tracks, as we get node information (C * N). When we don't get node information, we have One car, on one track, times by the number of points on the track (C^N). Because now we have to test for each node within the pth file. Now when your talking about multiple cars, and multiple points the problem is compounded again. You have to check every car against every point. This quickly becomes an expensive operation for just one server, yet alone a few that PRISM could be installed on, effectively becoming multiple cars, on multiple tracks, using all of the nodes. It's a question of speed, what the fastest way to get this done without having the node information for each client.

To this end, I'm designing PRISM to be fast first. It's going thorough a whole redesign for PHP 5.5, and that upgrade with the same code base alone is a 20% - 40% speed improvement without any code changes (Cool, free performance.) Using SPL, on top of that it should be 25% faster then native arrays when writing data, and use 40% of the memory size, but there is hardly any difference in iteration speed. So my last hope is implementation of R* Trees. It would be odd if an SQLite query would be faster then native memory because of the underlying C structure, but who knows! It's worth a shot for speed.

I see, so my first guess was right.

I'm afraid that in this case reducing the number of node points per track will not be a good solution. This will work for drawing the tracks, as cargame showed (nice and interesting thing by the way!). But that is very probably only because the graphics algorithms are using splines to connect the nodes to make them smooth. In this case you want to rely on the bare node points as much as possible, because calculating all those splines wil be even more time consuming.
The only part were you might consider leaving some points out should be near the apex of a turn, but on the other hand, that is where you want most precsion, as that is the areas where cutting happens.
So all that is left for optimizing is really the algorithm.
In that respect I would give the grid-approach (link above) a try. Unfortunately I am also very busy at the moment, so I cannot give it a shot myself to see how we could optimize that.

Can someone post a reply of a packed server, with as many people as possible (I'd like to see a full server, with every car racing that is possible.) So I can run benchmarks against the same data set.

Hmm that luckily isn't a difficult request. Also open layout;

http://www.sendspace.com/file/fxor3y

Thank you kind Sir.