Ylöstalo, sorry for the bump, I think I misjudged the braking point there. 
Ugh, would have had a decent pace for the race if it wasn't for the wind. Did several dirtdrop spins. No experience with wind whatsoever. Plus massive areowash. I guess it's just learning by doing, I should practice stints with random low wind probably. Also is it just me or does the car tend to be more oversteery with wind?
Session AND SERVER of Incident (Official Sessions for Round 2: Free Practice, Qualifying, Race) Race
Lap AND MPR timecode of incident (or session time or UTC Time of Day) 30, 43:45
Car(s) involved 24, 57
Location of Incident Turn 8
Brief Description of Incident Protesting myself. Recovered badly from crash and ran into 57. Sorry to M.Stankus.
Lap AND MPR timecode of incident (or session time or UTC Time of Day) 30, 43:45
Car(s) involved 24, 57
Location of Incident Turn 8
Brief Description of Incident Protesting myself. Recovered badly from crash and ran into 57. Sorry to M.Stankus.
Well, this looks ultimate. Bravo 
Nothing would be sent under 0.5m/s sounds weird to me.
An option to limit number of contact packets would be restrict events with some timer so 2 cars wouldnt trigger more than for example 1 event per second. However maybe this approach isnot so easy to implement, compared to a speed cutoff.
From my own insim programing experience, it seems the AXO packet has a nice cutoff system, never flooding the bandwidth, but still reports even the lightest contact. Idk how it works, but it looks efficient.
Sometimes, the cause of an accident can be a driver blocking the way on straights or at braking by changing lane when someone attempts overtake can result in blocking car being pushed by the other one even if the follower keeps his lane (kinda fish tail). I would like those contacts to be reported, but it seems to me most of them are under 2m/s and maybe even under the 0.5m/s cutoff threshold.
I am aware that small refinements are often those which eat much time. and I didnt test online so i wont discuss more over your inputs,
The "closing speed times 2" will still be better precision, and that contact packet still will be a major boost for racing spirit, am confident.
Closing speed could be more efficient use when its unit would be more precise.
With meter/second, we wont know more than :
closing = 1 for >0 - 1.49 m/s (how will it report closing speed if under 0.5m/s ? null ? idk)
closing = 2 for 1.5 - 2.49 m/s
closing = 3 for 2.5 - 3.49 m/s
etc... till 255 m/s, but do i rly need to know car X rammed Y at 255m/s ?
To me a "fast/slow" boolean would be as efficient.
As i consider anything above 2.5 m/s a too hard contact, and as i can have more clues about the intent of faulty car with throttle/brake info, i believe it would open more possibilities of using the closing speed value if it was labelled in a more precise unit like decimeters or centimeters /second, even if it has to be clipped for higher speeds.
With meter/second, we wont know more than :
closing = 1 for >0 - 1.49 m/s (how will it report closing speed if under 0.5m/s ? null ? idk)
closing = 2 for 1.5 - 2.49 m/s
closing = 3 for 2.5 - 3.49 m/s
etc... till 255 m/s, but do i rly need to know car X rammed Y at 255m/s ?
To me a "fast/slow" boolean would be as efficient.
As i consider anything above 2.5 m/s a too hard contact, and as i can have more clues about the intent of faulty car with throttle/brake info, i believe it would open more possibilities of using the closing speed value if it was labelled in a more precise unit like decimeters or centimeters /second, even if it has to be clipped for higher speeds.
This IS_OBH struct would be great for sure.
SurfaceType and ObjectInfo are the ones i can't think about being usefull right now.
A nice refinement would be to have this added, like in car contact struct :
byte Closing; // the closing speed of the collision in m/s (suggests severity)Closing speed would not be car speed even when colliding a non moving object, as a 'fast' car can nudge a cone so it doesnt move much and car speed would be different than 'collision speed'.
edit:
Also, thinking about some precision, could the closing speed unit be changed to cm/s instead of m/s ?
with the current closing speed unit we would not be able to have values under 1m/s
this would limit max closing speed to 2.5 m/s but i would rather have precision downside than upside : with planes anything more than 2 m/s is a quite hard landing.
Lets hope this can be done easily : )
Last edited by fat-oil, .
Right.
Another option, instead of modifying AXO packet would be that in the case of object contact
the CarContact B struct could have 0 in its speed field, and the object type in another one.
Regarding number of packets sent, some car crashes will also generate many contacts. So maybe this could be filtered so lfs sends at max like 1 contact event per 1 second per object.
Another option, instead of modifying AXO packet would be that in the case of object contact
the CarContact B struct could have 0 in its speed field, and the object type in another one.
Regarding number of packets sent, some car crashes will also generate many contacts. So maybe this could be filtered so lfs sends at max like 1 contact event per 1 second per object.
could it be that a new byte for object type would be added in the AXO packet ?
something like this :
// If an autocross object is hit (2 second time penalty) this packet is sent :
struct IS_AXO // AutoX Object
{
byte Size; // 4
byte Type; // ISP_AXO
byte ReqI; // 0
byte PLID; // player's unique id
byte ObjType; // collided object type
};with an enum that could taken from the LYT file format
Objects indexes allowed by tracks.
* Autocross track :
TYRES (white) : 0
TYRES (red) : 1
post1 : 2
TYRES2 (white) : 3
TYRES2 (red) : 4
TYRES (white) : 19
bale1 : 23
AD_banner1 : 24
Banner_AD2 : 25
Banner_AD3 : 27
CONE red : 29
CONE red3 : 30
...etc
* Blackwood track :
cone1 : 0
cone2 : 1
bale : 3
tyre_white_s2 : 5
tyre_blue : 6
railing : 8
...etcin case of non AXO object, maybe send an struct IS_CON with a null CarContact B.
Having info on type of object collided would allow insim to know whenever a clipping point (in a drift context) is touched, even if it is surrounded by other layout objects.
I guess some other ideas would pop in people's head.
oh nice, so u mean there's some hope left ?
amazing
something like laxatives to be shipped with new membership ?
omg sry i got an emergency bb
1. LFS Lapper is already open source... Do you know what u are writing about ?
2. is this the main intent u have for open source ? being able to change credits to your own name without actually adding or modifying anything else ? OMG !
My modified release of lapper will remain open source, but for OMG reasons i wont distribute it anymore. Find it elswhere.
facepalm seems appropriate for the whole thread, so :
facepalm:
I removed link to insim, due to people running it, removing credits and claiming they made it ([Apex] drift demo server). A wormhole full of pigs, thats lfs community Nice spirit guyz.
I share, and you lie... U know what ? get lost, get ****ing lost, pig.
yes bad english.... never said such things
hi
i got a private message about this thread and read it.
First some precisions
the author of this thread 'giorgobani' has been ip banned from my servers with a windows system ip ban
LFS bans proved inefficient after banning at least 25 different accounts from that same guy.
People that dont respect a ban period from my servers, and connect with a spare account, that spare account will be perm banned for non respecting ban period. If user still connects with more spare accounts, then a windows ip ban happens. File closed.
4 peoples are ip banned atm, and am sorry about that too.
I always shared my insim with people that asked me, it's written in the !ver command of the insim.
Just last time i said no, 2 weeks ago, because i have currently stopped coding it and there still much work to make it user friendly for editing clips. I said no because i dont want to provide technical support anyhow.
Now, this thread is here so i put an archive of LFS Lapper Fat Oil Edition on my site, with a default marker file for BL1 track
archive is complete with LFS Lapper 5.7.1.6 standard files + modified lapper.exe + modified lpr config file + some tracks apex markers + some corresponding layouts for apex markers + C# source code
- the source code is quite commented and modified parts are isolated with "// rtz code" and '// end rtz" comments, the whole drift scoring algorythm has changed, there's a whole new 'driftmark' class too.
feel free to ask me things if u need
- the config file needs editing of server ip and password, also take a look at added commands in the #Command actions# section and change allowed usernames according to ur needs
!displayON
!displayOFF
master angle+score display switch
!guest username
invite/leave switch for private tchat system
use /i message ingame to send to private tchat
other commands available for competition and things but quite useless
- the clips marker .mrk files are new. They contain apex and grass zones location, size etc...
the insim ALLWAYS look for the 'temp.mrk' file, if it is not present, lapper will start anyway, but apex scoring wont be available
the current temp.mrk file in the archive has info for BL1
there are other tracks available, check the other .mrk files, if u want to use another one, just copy it and rename it to temp.mrk and restart lapper, also check layout i provided in bin/layouts and load it to get cones at markers location
editing of track markers and changing marker file when track changes is not user friendly at all and would need some more coding, and thats the part i dont want to provide technical support, it is too user unfriendly
now some copy/paste of some infos i wrote
Corner scoring
Now score depends on entry, apex, exit and average car attitude in the 20m zone of marker position.
An attitude bonus multipler is available when best apex distance < 4m and average angle +25°.
From each angle, speed or distance recorded, a formula is applied to get a factor with logarithmic progression (the higher, the harder to increase).
Then all factors (angle speed distance) are multiply with the following weighting (still experimental) :
2 entries + 3 apex + 2 exit + 6 average
(edit june 2010 : maybe i changed the formula, i dont remember, check source code...)
So most important is average attitude then apex then entry and exit.
I added a stability bonus. It is triggered when car angle variation in zone of marker is less than 15°. The bonus is higher as angle stability is higher = angle variation is lower. For 15° variation u get 6% bonus, for 1° u get 100% for 0.5° get 200% etc. (this may change) Then stability bonus is added to the existing attitude bonus if there has been one, then corner score is increased according to the total amount of bonuses.
This feature may allow to stretch drift angle limit up to 100° or more, as keeping stable a 90° drift angle during whole corner should definitely get a bonus. On the other hand if the drifter makes wide angle entry and looses too much of it (15° atm) even a small amount of time, then bonus factor is lost.
in game u can type !showstats to have a display of scoring parameters. Display will only happen after a scored marker. Then u'll get for each entry, apex, exit, average, the scoring factors and raw data for speeds angles & distance
There's now a spin detector when car is inside 20m zone.
Grass penalty
Anti-lawnmower system !
Grass markers added. Driving on one displays warning on screen, and cuts the totalscore to 95% of its value at time of eval. If next eval reports grass again, then another cut to 95% etc,... endlessly till car exits the grass marker zone. This can be heavy penalty when score is high.
Marked BL1 GP for demo server, now scans 289 grass markers + 8 apex... runs fine but system is pretty heavy in CPU processing atm (now my lapper eats 1% of a core on a quad6600 at 3Ghz (which is quite huge seen what the toy does...), and the positioning is a pain, I may rewrite it.
But it works fine : )
Twin scoring (still experimental, i dont remember where i stopped code)
!twin username
!twinoff
very touchy, some bad bugs left, can crash insim when !twin or !twinoff commands not correct
The scoring is based upon those parameters (in decreasing order of weight in the magic formula) :
- angle synchronisation between the 2 cars : same drift angle at a given time awards more points
- speed synchronisation between the 2 cars : same speed, more points. (Thanx Glazer for this one)
- distance between the 2 cars : the more distance, the less points.
and of course :
- average drift angle of the twinmates at given time
- average speed of the twinmates at given time
- average drift time length of the twinmates at given time
When twin mode is handshaked by both twinmates, the first 3 parameters are displayed on top of the player screen when in twin mode under the form :
- distance
- angle difference in the twin ( best is 0)
- speed difference in the twin (best is 0)
So, the most important is to keep synchronous, then keep close, and then after u can think to get wider and faster and longer. The variation is exponential, not linear : try twin 50m away other car or just drift while twinmate goes straight, then the score can actually become negative because too far and/or angle amplitude too high.
As it is a twin the score is shared by both twinmates.
if u have problem to run it, plz try to figure out yourself, use your brain, give it some patience/time, look for info on original lapper thread from gai-luron, and if u are really stuck, u may try to ask me
have fun
i got a private message about this thread and read it.
First some precisions
the author of this thread 'giorgobani' has been ip banned from my servers with a windows system ip ban
LFS bans proved inefficient after banning at least 25 different accounts from that same guy.
People that dont respect a ban period from my servers, and connect with a spare account, that spare account will be perm banned for non respecting ban period. If user still connects with more spare accounts, then a windows ip ban happens. File closed.
4 peoples are ip banned atm, and am sorry about that too.
I always shared my insim with people that asked me, it's written in the !ver command of the insim.
Just last time i said no, 2 weeks ago, because i have currently stopped coding it and there still much work to make it user friendly for editing clips. I said no because i dont want to provide technical support anyhow.
Now, this thread is here so i put an archive of LFS Lapper Fat Oil Edition on my site, with a default marker file for BL1 track
archive is complete with LFS Lapper 5.7.1.6 standard files + modified lapper.exe + modified lpr config file + some tracks apex markers + some corresponding layouts for apex markers + C# source code
- the source code is quite commented and modified parts are isolated with "// rtz code" and '// end rtz" comments, the whole drift scoring algorythm has changed, there's a whole new 'driftmark' class too.
feel free to ask me things if u need
- the config file needs editing of server ip and password, also take a look at added commands in the #Command actions# section and change allowed usernames according to ur needs
!displayON
!displayOFF
master angle+score display switch
!guest username
invite/leave switch for private tchat system
use /i message ingame to send to private tchat
other commands available for competition and things but quite useless
- the clips marker .mrk files are new. They contain apex and grass zones location, size etc...
the insim ALLWAYS look for the 'temp.mrk' file, if it is not present, lapper will start anyway, but apex scoring wont be available
the current temp.mrk file in the archive has info for BL1
there are other tracks available, check the other .mrk files, if u want to use another one, just copy it and rename it to temp.mrk and restart lapper, also check layout i provided in bin/layouts and load it to get cones at markers location
editing of track markers and changing marker file when track changes is not user friendly at all and would need some more coding, and thats the part i dont want to provide technical support, it is too user unfriendly
now some copy/paste of some infos i wrote
Corner scoring
Now score depends on entry, apex, exit and average car attitude in the 20m zone of marker position.
An attitude bonus multipler is available when best apex distance < 4m and average angle +25°.
From each angle, speed or distance recorded, a formula is applied to get a factor with logarithmic progression (the higher, the harder to increase).
Then all factors (angle speed distance) are multiply with the following weighting (still experimental) :
2 entries + 3 apex + 2 exit + 6 average
(edit june 2010 : maybe i changed the formula, i dont remember, check source code...)
So most important is average attitude then apex then entry and exit.
I added a stability bonus. It is triggered when car angle variation in zone of marker is less than 15°. The bonus is higher as angle stability is higher = angle variation is lower. For 15° variation u get 6% bonus, for 1° u get 100% for 0.5° get 200% etc. (this may change) Then stability bonus is added to the existing attitude bonus if there has been one, then corner score is increased according to the total amount of bonuses.
This feature may allow to stretch drift angle limit up to 100° or more, as keeping stable a 90° drift angle during whole corner should definitely get a bonus. On the other hand if the drifter makes wide angle entry and looses too much of it (15° atm) even a small amount of time, then bonus factor is lost.
in game u can type !showstats to have a display of scoring parameters. Display will only happen after a scored marker. Then u'll get for each entry, apex, exit, average, the scoring factors and raw data for speeds angles & distance
There's now a spin detector when car is inside 20m zone.
Grass penalty
Anti-lawnmower system !
Grass markers added. Driving on one displays warning on screen, and cuts the totalscore to 95% of its value at time of eval. If next eval reports grass again, then another cut to 95% etc,... endlessly till car exits the grass marker zone. This can be heavy penalty when score is high.
Marked BL1 GP for demo server, now scans 289 grass markers + 8 apex... runs fine but system is pretty heavy in CPU processing atm (now my lapper eats 1% of a core on a quad6600 at 3Ghz (which is quite huge seen what the toy does...), and the positioning is a pain, I may rewrite it.
But it works fine : )
Twin scoring (still experimental, i dont remember where i stopped code)
!twin username
!twinoff
very touchy, some bad bugs left, can crash insim when !twin or !twinoff commands not correct
The scoring is based upon those parameters (in decreasing order of weight in the magic formula) :
- angle synchronisation between the 2 cars : same drift angle at a given time awards more points
- speed synchronisation between the 2 cars : same speed, more points. (Thanx Glazer for this one)
- distance between the 2 cars : the more distance, the less points.
and of course :
- average drift angle of the twinmates at given time
- average speed of the twinmates at given time
- average drift time length of the twinmates at given time
When twin mode is handshaked by both twinmates, the first 3 parameters are displayed on top of the player screen when in twin mode under the form :
- distance
- angle difference in the twin ( best is 0)
- speed difference in the twin (best is 0)
So, the most important is to keep synchronous, then keep close, and then after u can think to get wider and faster and longer. The variation is exponential, not linear : try twin 50m away other car or just drift while twinmate goes straight, then the score can actually become negative because too far and/or angle amplitude too high.
As it is a twin the score is shared by both twinmates.
if u have problem to run it, plz try to figure out yourself, use your brain, give it some patience/time, look for info on original lapper thread from gai-luron, and if u are really stuck, u may try to ask me
have fun
Last edited by fat-oil, .
wanted to write something like that for a while
globally speaking, omg what a dispappointment s2 'scene' was !
i stick on back demo for monthes...
FGED GREDG RDFGDR GSFDG