Quote from avetere :

Although this thread is originally for INSIM, I'd still like to know one thing:

Will this patch affect the current mpr-version (i.e. will other things than track config be altered?)

The MPR should still be exactly the same, other than the config specification.

By the way, if there are any files where "R" would normally indicate "Reversed" then there could be an "X" or "Y" to indicate an open config (as you know already). If there are any files where the byte 1 (not character R) indicates Reversed, then the equivalent bytes for X and Y are 2 and 3.

Quote from hyntty :

Any chance to be able to completely remove objects (all of them)? Then you could remove an object that has just been run over instead of it respawning in it's original place.

I don't know, yet, about adding and removing objects, though it's on my list to consider it. If I do that function, I think it would only remove objects that have been added, not original objects that are in the default track.

Quote from Scawen :

If there are any files where the byte 1 (not character R) indicates Reversed, then the equivalent bytes for X and Y are 2 and 3.

Ooh, nice to know that one, thanks

Quote from Flame CZE :

I think that 1 pixel equals 1 metre.

Can anyone confirm this please?

The perpendicular closing speed of the car with the object would be useful for a program idea that I have. We want to assign ballast penalties for out of control driving and this would help especially on the city tracks.

Quote from PoVo :

Can anyone confirm this please?

Yes each pixel corresponds to one meter. The track environments are 2560 meters square, the same in pixels.

Quote from PoVo :

Very good script! Thank you!

Just a question. How can I find the X/Y coordinates from the TIF track files?

http://denisbatya.narod2.ru/ <== exsample for SO

i'll use it today to generate streets on cruise with polygons

look sourse code

Quote from denis-takumi :

http://denisbatya.narod2.ru/ <== exsample for SO

i'll use it today to generate streets on cruise with polygons

look sourse code

This one gets Mouse position, so if you keep your mouse stable and scroll up/down/left/right coords will be still the same.

Quote from DarkKostas :

This one gets Mouse position, so if you keep your mouse stable and scroll up/down/left/right coords will be still the same.

i write fats script for firefox and this work right.

if u want to work with it on IE or Safari fix it

Quote from denis-takumi :

i write fats script for firefox and this work right.

if u want to work with it on IE or Safari fix it

hmm, it was working fine on firefox(bad boy chrome)

i'm begin new thread for this tools.
http://www.lfsforum.net/showthread.php?p=1579556

Quote from Scawen :

There is no path and no nodes, so NLP and MCI packets will contain zero in the Node field.

Is this because it is essentially autocross, or because there is no path file to load? Could it not be done so that if for example, a FE4X.pth file exists, it attempts to load that? Just in case someone manages to make one in the future - could the .pth dependant functions (map, racing line, flags, positions, etc) be made to function only if there is a valid .pth file for the track?

Interesting question! But I do not think there can be FE4X.pth covering all FE roads. I would say a PTH file must represent just one path without splits and joins, also with incremented node numbers. So I think there are two questions:

1) Is a PTH file all that the LFS engine needs to assess car positions in race?

2) Is it possible for LFS to load custom PTH files?

Well, overall, I think this is rather complicated, because the same PTH files must be guaranteed to be available on all clients, that is if race positions and flags are not handled only by the server. That would make things much easier, but I do not think that is the case.

It would be great if the PTH on open circuits could be downloaded from the host while connecting. Allowing us to do whatever layout we wan (as far as not using the same road twice).

Scawen, would it be hard to report lap or car change via InSim? I mean when an admin changes that.

Quote from EQ Worry :

.... the same PTH files must be guaranteed to be available on all clients....

Failing a standard PTH file, what about a standard SHIFT-U Layout file, with agreed start/finish line and checkpoint placement.

That way, if you jump from server to server, at least you'll be comparing like for like on lap and split/sector times.

Also, might be better if there was an additional checkpoint included as part of the layout choice, even at the expense of a barrier, tyre or line, as some of the tracks will be lot longer on average, and 4 splits may be better than 3.

Well, the problem is the position of start/finish line + splits in a layout are reported using node numbers. And those X and Y tracks will have no nodes, so almost nothing would be available to InSim applications concerning the actually loaded layout.

There are ways to overcome that limitation, like using a CRC check or something on the layout file, as Dave of CG suggested, or maybe even parsing the LYT file and seeing the X,Y,Z placement of important things, but overall it is not really easy. At least I do not see an easy way.

All current tracks have 3 splits max plus start/finish. LFSW, AIRW and Airio, Lapper (plus maybe other tools) rely on this fact that there can be max. 4 sectors on any track. So again, adding a 4th (or higher) split could do a lot of damage concerning compatibility.

Quote from dj_hitas :

Scawen, would it be hard to report lap or car change via InSim? I mean when an admin changes that.

The number of laps is reported via IS_STA, but I don't think there's anything for the cars, aside from reading the hostXXXXXX.txt file. Could be done via a SMALL.

Quote from EQ Worry :

Well, the problem is the position of start/finish line + splits in a layout are reported using node numbers. And those X and Y tracks will have no nodes, so almost nothing would be available to InSim applications concerning the actually loaded layout.

There are ways to overcome that limitation, like using a CRC check or something on the layout file, as Dave of CG suggested, or maybe even parsing the LYT file and seeing the X,Y,Z placement of important things, but overall it is not really easy. At least I do not see an easy way.(

wouldnt it be quite simple? get the x,y of one part go over to other side or road, get another x,y.

Quote from cargame.nl :

Hhhmmm maybe it could be very useful to include the pedal status in CarContact. It's one of the first things people analyze during a crash replay with help of the 'show pedal' bars.

Determining pedal usage is not easy by just looking at pure acceleration (/deceleration) values. Actually I even think it's mandatory information, I can give an extended explanation if needed.

I'll add this to the CarContact structure. I guess they only need accuracy of 0 to 15 so I could squeeze both into a single byte.

I was considering a "hit point" as well, so you'd know roughly which part of the car took the impact (front, right, etc). Though I guess you can work this out from position and heading so maybe that's not needed. There isn't any space left anyway, if the accelerator / brake byte replaces the one spare byte (Sp2).

I guess the easiest thing would be to leave the CarContact just as it is now but include a single byte pedal status byte instead of Sp2. But that leaves no spare space at all (to add anything later in a compatible way). If we do need any more data in the CarContact, I'm wondering if the AccelF and AccelR are needed - are they actually going to be useful? I guess you can tell if a person was actually turning left on a left bend...

Quote from Scawen :

I'll add this to the CarContact structure. I guess they only need accuracy of 0 to 15 so I could squeeze both into a single byte.

How about clutch? Throttle+brake at once heavily depends on clutch position.

Quote from E.Reiljans :

How about clutch? Throttle+brake at once heavily depends on clutch position.

I've now added the ThrBrk byte and the CarContact structure is now full. Adding any more data per car will mean the IS_CON has to go up by 8 bytes (4 per CarContact) or we will need to delete something.

I don't know if a programmer can make use of the clutch status as well... or how important that could be when detecting whose fault a collision was. But this packet is nearly final so please do have a final think about that and tell me if I've missed something (I've been very busy this last week on other things so I might have forgotten a point). I'm still considering if a time stamp is needed. I'll have a look at that hit object packet now.

IS_CON as it stands :

You could add handbrake and clutch as flags in the Info byte, clutch would be disengaged, slipping (some friction, enough to cause heat/wear but not sufficient to move the vehicle / overcome the inertia), gripping (slipping but sufficient friction to move the vehicle) or fully engaged, handbrake could be 0%, 33%, 66% or 100%.

I don't really want to do that, in case CCI bits are added to CompCar some time in the future.

But to understand why it is important, I'd like to know how someone would use clutch and handbrake information in a collision analysis.

I guess they could be put into one byte, if the lateral and longitudinal accelerations were also put into a single byte, though that would be a bit of a squeeze.

Or of course I could extend those structures by 4 bytes each, leaving a bit of space for the future. Maybe that is the best idea, just in case...

Quote from Scawen :

But to understand why it is important, I'd like to know how someone would use clutch and handbrake information in a collision analysis.

Well I don't think it's important, but if your analysis takes driver input into consideration at all, it might as well take all available factors into account.

Quote from Scawen :

Or of course I could extend those structures by 4 bytes each, leaving a bit of space for the future. Maybe that is the best idea, just in case...

Indeed, I'd go with that

OK, here it is, final unless anyone thinks of anything... now CarContact has steer, throttle, brake, clutch, handbrake, gear and IS_CON has a looping time stamp.


Maybe I'll add a switch just like ISF_MCI so connected programs don't receive contact reports unless they ask for them them. Then there isn't really a bandwidth problem.