What is 0:0 in lfs coordinates, is 1280:1280 in my svgs. Exactly speaking, lfs coordinates x and y are converted to X and Y:
X = 1280 + x
Y = 1280 - y
(all of them expressed as meters)

Those are also the coordinates that are used to place all objects, as I use that coordinate system for the viewbox.

What range is actually shown on the picture depends on whether the contents are higher than wide (h>w) or wider than high (w>h).
Having minx, miny, maxx and maxy as boundary limits for the contents (each of which being between 0 and 2560 as for the transformed coordinate system) and w and h for width and height we get:

h = maxy - miny
w = maxx - minx

now, what is shown on the image is the rectangle between:
if w>h:
topleft:
x: minx - 0.1w
y: miny - 0.1w - (w-h)/2
bottomright:
x: maxx + 0.1w
y: maxy + 0.1w + (w-h)/2

if h>w:
topleft:
x: minx - 0.1h
y: miny - 0.1h - (h-w)/2
bottomright:
x: maxx + 0.1h
y: maxy + 0.1h + (h-w)/2

This is done to always have a small border around the track (or the drivable part actually) itself. Thus it is also possible to have negative coordinates in the viewport, as for example in th AS2 picture.
Btw: I plotted you the center, which, as I said is at 1280:1280 as a circle here:

Hey folks!

I've just uploaded a new version with a few minor bugfixes.
Also now a change of tyre type is displayed on the pitstop pane.
Piticons have been changed in a way that any tyre that has been changed (but remained the same type) is shown on blue (as before), when the type was changed it is shown in green.
The details for tyre types (including the changes) are shown in a tooltip when hovering over the icon.
There is one known bug though: I can at the moment not differentiate between "road normal" and "hybrid" as the initial tyres (when leaving the pits or at race start). Whenever a car comes to track with one of these, I will assume "road normal" as default. If this was really "hybrid", then there will be a false "type change" upon a pitstop.

Quote from Gutholz :

avetere, nice vector graphics.
But I was wondering where is the 0:0 in them and how to find the scale?

Thanks!

0:0 is in the upper left corner, if that's what you mean. I'm not entirely sure about whatyou are refering to by "scale", but I just crop the entire viewspace (which has a maximum of 2560x2560) down to what is actually used. The coordinates of the single points are really based on this maximum scale and I just adapt the viewbox to the minimum and maximum values that are used (plus some extra space for a nice framing).

Did that answer your question?

As far as I know, LFSStats uses all the laps including those pitstops are made. I think the outlap is not considered as this is obviously very slow.
This is also the way I'm doing it. The problem with pitstop-laps is simply that 2 laps will be affected, so actually you would need to skip both of them ...

Hm ... ok I was now able to reproduce the error I think ... seems like IE tries to load one of the images for an extended period of time. For me hitting Esc (abort loading) helped and the png-image was displayed ... I'll have a look into it ...

And please don't worry! I'm happy with any error that is finally found ... this way i can fix them

No, the original notation is ok but should actuallz read images/tracks ...
I also tried it on your site and it worked well for both svg and png tracks

Actually, if you change the path to the one you stated above, you will just be able to show track images that are already present. This is just the storage path. The original path ultimately leads you to the corresponding trackimage_xxx.php that looks for an image in the storage path and if it is not present, then renders it on the fly (and afterwards stores it).

As I said, I tried and it wirked well ... but your server took a bit of time for the rendering ... maybe you were just to unpatient?!

As for the errors, I think, I know the reason ... I'll send you a hotfix by pm. please try it out and if that works, I'll correct that

new version online (see first post)

For handicaps to be shown on "old" races please parse again using force_load option (or delete .mprdata from saves directory)

Thanks!

I'll have a look into the handicap stuff and then implement it alongside the changed en.ini (and one or two minor bugs I found) ...

Quote from therbo :

I was hoping the intake and mass were available in the mpr headerhttp://www.lfs.net/?page=MPR..guess it is not that easy

OK, it is available there, but only for those cars, that physically finished the race. For any car that retired we do not get the information. That's why I decided to not have it at all, also as it only states the handicaps for that moment ...
Nevertheless I could implement that quite easily for the next release, but only with the restrictions mentioned above.

Hey!

Well, thanks for testing (and the the nice rating)!

If you have any suggestions for customizations or improvements, please feel free to tell me. For the language fixes, please do so (just post the corrected one afterwards, so I'll be able to implement it for later releases).
(Also for anybody else who is willing to translate to his own language, please submit a corresponding file, I'll implement it for coming releases!)

For the handicaps, unfortunately that's not possible, because these two parameters are not available to me.

The graphs that are sometimes not expanding to full width are a known bug. I'm quite sure that this is because the qidth is not explicitly stated in the object-tag of the html-code. Still need to come up with an idea for that. Suggestions are strongly appreciated

Oh, and in case you come across any errors, please provide the replay (or a link to it) and the settings (as stated in event_definitions.txt and/or .mprdiff) ... I'll have a look into it

MOST RECENT DOWNLOAD
mpRes V2.08 to V2.10
mpRes V2.08
----------------------------------------------------------------------

Hello fellow racers and admins!

After by now a couple of years of playing around with it, I finally decided to publish my webscript for getting race statistics out of the replays.

About the script - the basics

mpRes is a php-script, designed to analyze multiplayer replays gathered from the racing simulation Live for Speed and to produce statistics out of them.
A great deal of the data thereby produced is long known to the community as the InSim-tool Live for Stats originally written by Gai-Luron offers similar features and is widely used to display race statistics. The features offered by mpRes are thus inspired by that tool.
A second basis for this script was the work done by MikeB during the development of his tool mprEdit. Thanks to MikeB - who published his results - we gained a little understanding to the inner structure of LfS multiplayer replays apart from the documented replay headers.
I was able to hook on here ...
The basic idea was to provide a possibility to simplify the offering of race statistics and results by rendering it unnecessary to cope with screenshots or to run the replay through the InSim tool and then manually adapt all the linking inside the resulting HTML-output.

The target audience
This script is designed especially for leagues that want to or must display whole seasons of results and for organizers of big single events, particularly those where takeovers are included and/or rejoining the race (possibly maintaining already done laps) is allowed.
As this script uses some predefined (via config-file) values that determine the outcome of it, I explicitly do not recommend parsing through random replays. For this purpose the abovementioned tool Live for Stats surely is the better choice.

What it does and what not
Well ... the script reads the replays, that you upload to your server and generates results in written and graphical form ...
To a certain extend you can alter the outcome of the results in order to comply with your event's rules. You might also incorporate penalties into your results (penalties may include time, laps or even disqualification of a racer).
On the other hand, it does not make things more simple than possible. The drawback of a quite easy handling once everything is configured is, that you have to configure things first, aditionally you are restricted in naming your replays in order to assign them to the event, they belong to. This might change in the future, when I'll have a database based version of the script ... but you'll be able to see average fuel consumption and engine damages ... just search for it ...

Differences to ingame results
Out of various reasons the results gained by using this script can - and are to some extent meant to - differ from those obtained from LfS itself. These differences are mainly as follows:

• Disqualifications (e.g. due to not having done a mandatory pitstop) are not automatically done by this script. Instead the racers are included normally into the result as I want the people responsible for an event to be able to decide, when a racer is to be disqualified and when not. Penalties (including disqualifications) can be given on a per file/player basis.
  

• Unfinished racers can - depending on the configuration - be defined as finished and thus achieve a regular position (A minimum percentage of the total race distance is to be defined.).
  

• Rejoining the race after a defined race progress will be rigorously and impartially ignored. Thus everything done (i.e. any laps) after such a rejoin will not show up in the result.
  

• Results of different stints (due to rejoins) can - the corresponding setting provided - be added up to give a total result. A lack of that setting will result in only the last valid stint (see above for invalid ones) being evaluated.
  

• Unfinished races, e.g. due to mass disconnections can be reasonably evaluated by manually adjusting the desired race distance.
  

OK, I think, that's it for the moment ... try it out and let me know, what you think

Here it comes:
mpRes V2.08 to V2.10
mpRes V2.08

Changelog
Legend:

# -> Bug Fix
$ -> Language fix or change
+ -> Addition
- -> Removed
^ -> Change
! -> Note

-------------------------- 2.10 [08-Mar-2021] ------------------------

+ Added support for new mpr file version since LFS0.6V (Test)

-------------------------- 2.08-HFphp55 [11-Feb-2017] ------------------------

# fixed function for colored driver names in case php >= 5.5 is used

------------------------------ 2.08 [07-Feb-2017] ----------------------------

+ Added support for new mpr file version since LFS0.6Q10
+ Added support for updated Blackwood track

------------------------------ 2.07 [21-Feb-2016] ----------------------------

# Fixed broken support for replay containing layout data
! /setlap commands are not yet implemented at this stage, this will be done in the next version

------------------------------ 2.06 [14-Feb-2016] ----------------------------

+ Added support for new mpr file version since LFS0.6K9
+ Added support for Rockingham weather update
# Path files for Kyoto-Bugfix included
! /setlap commands are not yet implemented at this stage, this will be done in the next version

------------------------------ 2.05 [20-Dec-2015] ----------------------------

+ Added support for new Rockingham tracks in LFS0.6K
# fix for racers finishing laps before race even started
! /setlap commands are not yet implemented at this stage, this will be done in the next version

------------------------------ 2.04-hf [02-May-2015] ----------------------------

# fix for compatibility with php > 5.5.0 (modified pack/unpack)
! /setlap commands are not yet implemented at this stage, this will be done in the next version

------------------------------ 2.04 [02-April-2015] ----------------------------

+ add new Westhill tracks compatibility
^ increase of maximum players to 40
! /setlap commands are not yet implemented at this stage, this will be done in the next version

------------------------------ 2.03 [06-Janury-2015] ----------------------------

+ ignore takeovers in single driver replays
+ added quick results overview for simple lists (res) and csv exports (csv)

------------------------------ 2.02 [01-November-2013] ----------------------------

# fixed some error in graph_select.php
# fixed wrong function getlanguage() in includes/functions.php
# fixed wrong argument for font width in graphs_png.php
+ added language variables graph->all and graph->nosvg to lang/en.ini and lang/de.ini
+ added change of tyretype to pit icons (green tyre means type was changed, details are shown in tooltip)
^ added script version to footer, the script also checks now, if a result was created with a previous version and recreates it in that case

------------------------------ 2.01 [01-April-2013] ----------------------------

# fixed wrong language variable for race progress chart in graphselect.php (line 43)
# fixed wrong variable for lap-deviation of single drivers in tpl/sta.tpl.php (line 48)
# fixed some language variables in lang/en.ini
+ added handicap shown on results for finished players (includes/get_replays.php | includes/readmpr/header.php | includes/readmpr/postprocess.php | tpl/erg.tpl.php | lang/en.ini | lang/de.ini)

--------------- 2.00 final (first official release) [22-March-2013] -----------

Last edited by avetere, Tue, 9 Mar 2021 09:07.

Quote from TypeRacing :

I'm not sure that those flags are right - I'm using custom view and manual clutch for XRR, but this thingy says that I don't use none of them...

And my teammate, J. Dohnalík, should use mouse instead of wheel, so it is certainly bugged.

Honestly I would have to take a look, how I process those flags when a driver change is performed. Might be, that there is still a quick'n'dirty approach which obviously has some problems. I'll try to look into that, but anyways, thanks for the comment

btw: The graphs should now be working. But please allow them to be created and/or displayed. As there is quite a bit of information, that has to be processed (and in case of the svg-graphs rendered!!!) that may take a bit of time with such a long race

Either I'm a bit blind, or you are missing a function/method:
Call to undefined method Node::toPointRoad() in LVS.php on line 35

So I'm curious ... is it working?

... as long as you don't mix up left with right

Quote from Dygear :

As I get deep and deeper into this, I'm seeing some of the power, and some of the problems with this setup. First off the problems. Where as I can provide it with a set of points, do I have to provide the inside edge first, then the outside?Should I make sure that I supply the left side of the road, then the right side should it be the other way around when the track is in reverse? Does any of this matter really?

Well, going one way, the left boundary is the outer one, going the other way round, it's the right one ... to complicate things even more this changes at a section like in FE Gold ... but for a simple check if a car is on the track, it shouldn't really matter because to be on the track you will ALWAYS be within one polygon (the outer, whichever that may be) and out of the other one (the inner). If you are out of both, you are always on the outside of the track, if you are inside both you are always on the inside ...

Might be a little overkill, since the polygon will always be a trapezium, but this way it stays compatible in case one wishes to use other polygons ...
Saying this, it might be worth a try not to check only actual and following nodes, which might produce errors if one takes an extra turn (is the node changed, when I pass one in reverse?!?) but the entire track, which with your function should not be any problem ... all you'd have to check was if the car is within the polygon set by the outer boundary but not that set by the inner boundary.

ok ... but as I understand, you can't really determine whether a car is on the track or not by simply looking at one node(line).

If I see it correctly, MCI gives you:
- the last node (regularly) crossed
- current coordinates

So, what you should do is:
- span an area between the last node crossed (poly1, red) and the next one to come (poly2 , blue)
(in the image this area is closed by green lines, giving you a "virtual boundary" ... actually this boundary should be curved as seen in the dashed green lines, so even this gives an error, but I currently have no idea how to simply avoid this)

- check, whether the current position (orange dot, point x) is within this polygon

... or have I missed something?!



EDIT: here a basic approach for checking (function requires 2 nodes being given as poly1 and poly2 (see image))
This basically splits the polygon into two triangles 123 and 134 and for each one checks if the point is within the triangle (by checking if the the point lies on the same side of a baseline as the opposing triangle point (dot product of cross products) ... no check for 1->3 as this isn't necessary).

untested:

Last edited by avetere, Mon, 15 Aug 2011 13:40.

I'll have a look at it tomorrow ... here's bedtime now

So, it should be:
that should be constistent with the coordinate system provided by MCI and give you something like this:

Actually I reviewed my code and there was a factor, because x,y and z are given as 65536=1meter whereas Limit and Road are already given in meters ... so the functions I really used were:
with "delta" corresponding to either Limit or Road

1280 offset was used here to fit everything within coordinates 0,0 and 2560,2560.
Inversion for y axis was to achieve same orientation as ingame in the generated images ... alternatively you could do:
depending on your coordinate system ...

Well, didn't mean to harm you ... I guess the directness is merely a lack of speech

Limit (or Road) give the distance of the corresponding boundary (drivable area or track) to the point of the node (given by Center). This is simply a length of a vector.
But you also have to consider the orientation (direction) of the node to see "where to" this distance is drawn.
Your approach makes every node being rotated by 45° ...
For clarification I append an image:
left: my approach
right: your's
Here you can easily see, that Your approach must be wrong, as it creates very small tracks around the apex of a sharp turn.

To be precise, You'd also have to consider rotation around x- and y-axis for elevations but this would be minor differences of some cm only as the left one fits very well, when layered over the track images found here:
http://www.lfsforum.net/showthread.php?p=676857#post676857

*grmblfx* I had a more lenghty version of this but then my computer froze and I'm quite annoyed by that, so here the short version:

If I'm not completely mistaken you'd have to multiply your Limit and Road values with:
cos(atan2($this->Direction->X, $this->Direction-Y)) for x-values and with:
sin(atan2($this->Direction->X, $this->Direction-Y)) for y-values

$this->Center->X + $this->Limit->Left*cos(atan2($this->Direction->X, $this->Direction->Y))
or
$this->Center->Y + $this->Limit->Left*sin(atan2($this->Direction->X, $this->Direction->Y))

Last edited by avetere, Fri, 12 Aug 2011 18:53.

Well, the title already states it:
I'd like to know, which characters are never allowed inside a username (not ingame, but the account-name) or alternatively: which ones are allowed?

I know there are some invalid ones like # or %, but there are also some legal special characters like Æ ... so ... I'd like to have a list