Scawen, I can not avoid another request.

Could we get slipstream value into IS_HLV::HLVC? It would let developers throw the burden of calculating the slipstream themselves (which we implement just by common sence, since there is no precise data on how it actually works in LFS). Also it would save quite a lot of bandwidth.

I hope it is a trivial thing to do

I don't think that would be a trivial update, because of the complexity of it. The slipstream effect is calculated as a contribution of a varying air speed vector in a stretched oval behind the lead car(s) combined with the actual wind speed. It can vary from a tiny amount to a large amount depending on several factors.

It's possible it could be boiled down in some way, but that depends on what you want to use it for.

EDIT: To me it sounds more like something that could be in the MCI packet. Something like "amount of slipstream" or "similarity to driving in a vacuum" though I haven't looked into how that could be calculated.

Quote from Scawen :

I don't think that would be a trivial update, because of the complexity of it. The slipstream effect is calculated as a contribution of a varying air speed vector in a stretched oval behind the lead car(s) combined with the actual wind speed. It can vary from a tiny amount to a large amount depending on several factors.

It's possible it could be boiled down in some way, but that depends on what you want to use it for.

I am going to use it to filter laps to clean and non-clean categories in server stats.

By saying trivial, I meant just to send the packet whenever the drag gets to non-zero level. We could filter it up to 1..3% of the difference slipstream does to the car acceleration... There is also some need to exclude too short periods, like 10msecs or something like that.

Ok, it turned out not any trivial indeed.

Quote from sicotange :

Will the InSim checkpoints & circles be reported by IS_AXM? And will there be a limit to the amount of InSim checkpoints?

Yes they are reported in the same way as the other circles.

The checkpoints also use the 'circle' system, although they are not circles and can overlap unlike the actual circles.

I've just increased MAX_CIRCLES from 120 to 180. That covers these:

Time to stop now, got the circles working and outputting to insim on entry and departure. Still need to remove the sequential numbers and code for the checkpoint crossing. So you should get that tomorrow.

Thanks for all the testing, feedback, suggestions and discussion so far!

Quote from Scawen :

I don't think that would be a trivial update, because of the complexity of it. The slipstream effect is calculated as a contribution of a varying air speed vector in a stretched oval behind the lead car(s) combined with the actual wind speed. It can vary from a tiny amount to a large amount depending on several factors.

It's possible it could be boiled down in some way, but that depends on what you want to use it for.

EDIT: To me it sounds more like something that could be in the MCI packet. Something like "amount of slipstream" or "similarity to driving in a vacuum" though I haven't looked into how that could be calculated.

How do you calculate the amount of drag that is removed from each aero feature on the car? Shouldn't you be able to use the same calculation as the basis of scale?


We can then use this as a basis for any value of > 0.0 is a car that is receiving a draft and other programs that want to threshold this information could use anything above 0.20 as the basis for DSQing the lap.

--- Edit ---

Odd request perhaps. But once you start an InSim instance (by the command /insim=$port) could it send a ISP_ISI packet on loopback? Kinda like "Hey, I'm here." I leave my InSim instance running, in the background even when I disconnect and close LFS. If it could automatically reconnect once the LFS instance of InSim is ready that would be cool. Useful when debugging, I think.

Quote :

I've just increased MAX_CIRCLES from 120 to 180. That covers these:

const int CIRCLE_IS_CP = 252; // insim checkpoint
const int CIRCLE_IS_AREA = 253; // insim circle
const int CIRCLE_MARSHALL = 254; // restricted area
const int CIRCLE_ROUTE = 255; // route checker

Such a clean implementation


One more inquiry, is there any shareable data available concerning:

• The autocross objects dimensions.
• The cars dimensions.
• The center of gravity of the cars.

I'm asking because if it's easy to share, this data can be useful. For example when adding objects relative to a car or organising grids (the gap you should leave between cars at start). It's unimportant so don't bother if it's no easy copy/paste.

Quote :

IS_MSO / IS_III / IS_ACR message out packets now have variable size

While we are at it ... There is also BTT, MSL, and MSX. Havent really tested anything with the new patch and Im away from the PC at the moment, but just wanned to mention this.

K13 is now available in the first post. You can add InSim checkpoints and InSim circles in the autocross editor. Then you will get a report any time a car enters / leaves a circle or crosses a checkpoint in forward / reverse direction.

https://www.lfs.net/forum/thread/88999

So far so good except for 1 little artefact. When you add an InSim checkpoint and spam the arrows in the autocross editor to move the InSim checkpoint a new InSim checkpoint is added at that position. It doesn't happen with InSim circles.

With marshall objects there was always that odd "Can't add : intersecting object" message when you move the object with the arrows.

OFF-TOPIC:
Another (old) artefact but unrelated to 0.6K (or 0.6J) is that you can't select multiple marshall objects (CTRL +) but I'm sure you are well aware of this. Or is this intentional?

We've yet to test this, but the packet and interface in the game looks fine. Thanks for doing it so fast!

Quote from sicotange :

So far so good except for 1 little artefact. When you add an InSim checkpoint and spam the arrows in the autocross editor to move the InSim checkpoint a new InSim checkpoint is added at that position. It doesn't happen with InSim circles.

With marshall objects there was always that odd "Can't add : intersecting object" message when you move the object with the arrows.

At first I couldn't reproduce this but then I tried in multiplayer (host only) and did get the bug when clicking fast.

It seems to happen if you click to move again before the previous move has finished.

Noted, thanks.

Am I missing something or is there no way to stop an object floating after you have used the Z adjuster?

In other words, a way to make a blue object selection button go back to orange?

Yes, you can't ground level check your object again once the dot is blue. I always thought it was a design choice. Although it works with InSim IS_AXM.

Quote from Scawen :

Am I missing something or is there no way to stop an object floating after you have used the Z adjuster?

In other words, a way to make a blue object selection button go back to orange?

That awkward moment when you forget how your software works.

(I have no idea how PRISM works at this point. I'll admit it.)

OFF-TOPIC:

One small suggestion. In the autocross editor you can right click the X Y Z arrows for incrementation to move your object faster. What about having this also for concrete objects flags (WIDTH, LENGTH, HEIGHT, SIZEX, SIZEY, PITCH, ANGLE).

For example:
• Increment factor 2 when right click width arrows.
• Increment factor 3 when right click pitch arrows.

It would make it easier to make a horizontal slab object (pitch 0°) vertical (pitch 90°) for example.

LOL! OK guys, who hacked Scawen's forum account?
(But yeah, I know the feeling. Last night I was re-reading some code that I only wrote last May, and I barely recognised any of it...)

I will venture a guess that this particular object-placement issue will now be fixed

Interessting with the insim-checkpoints.
There is one thing which would make it very flexible:
https://www.lfs.net/forum/thread/88037-AutoX-editor-%28objects-%26-functions%29
see point (4)

The circle checkpoints have properties: X,Y,Z, diameter, index
Would it be possible to squeeze in some extra attribute "userdata"?
Being to save some numbers with objects (beside index) in editor could be useful.
If the circle-objeckt had a rotable direction that could potentially be useful too.

Insim programer could use it as constants to recognize type of checkpoint:

Could be done with external files, but having it saved in the layout itself and editable by editor would make it more userfriendly.
Think a scripted rallye co-pilot, editing what instructions he reads would be done by simply moving the insim-checkpoints in autoX editor.

One would need to remember the number constants but I think that is okay.

Gutholz, Scawen already squished the index into the Heading byte because there was no more bits available.

As you'll still need and InSim app to control all those things you propose, you don't need any text string inside the layout object. Just use an array/dictionary with all the additional information you need.

I mean the "insim Circle" object. Shouldn't one more number fit?
Its only extra property is diameter & index.

Yes, needs insim app. (I think I could do that.)
But the app needs to know more than detecting "Car is driving into insim checkpoint at x=123 y=456 z=789 diameter=8 playerID=1 objectType=circle objectID=5"

It also needs a way to detect "This was a jokerlap start checkpoint." and "This other checkpoint has some other function."
Problem is from insim's point of view the checkpoitns all look the same.

Of course there could be external array/dictionary like:
objectID 5 => jokerlap start.
But that complicates things a bit...
Being able to put markers on a map is good, but being able to label the markers is better

Thanks for the new circle/packet Scawen. I will test it as soon as I have some free time.

Quote from Gutholz :

But the app needs to know more than detecting "Car is driving into insim checkpoint at x=123 y=456 z=789 diameter=8 playerID=1 objectType=circle objectID=5"

It also needs a way to detect "This was a jokerlap start checkpoint." and "This other checkpoint has some other function."

You can create a simple protocol when you create layouts, and always assign id=1 to Joker Start, id=2 to Joker end, etc.. This way your insim would be compatible with any layout created in that way. And when you read it, it would be:

Car is driving into insim checkpoint at x=123 y=456 z=789 diameter=8 playerID=1 objectType=circle objectID=1 ( Joker Start )

Quote from Gutholz :

Problem is from insim's point of view the checkpoitns all look the same.

Exactly, all circles checkpoints look the same for insim, so you can code what do you want to do with any expecific index ( or range ). I don´t see the problem there.

NeOn_sp: That was the idea excactly.
I had not looked closely.
The normal green circles do not allow several circles with same index. (And also do not allow indexes higher than number of existing circles)
But the new insim-circles have no such restrictions!
Per insim-circle we can store one number with range 0-179.

Quote from Gutholz :

... But the new insim-circles have no such restrictions! ...

I know that the Route Checker circle has index that can be changed, but is this a new kind of circle, and can it only be placed using insim and not thru Autocross editor?

In editor.

All circles (red,green,insim) circles have the restriction not to overlap.
For the green routechecker circles it makes kinda sense, but is it nessecary for the others?

Quote from Gutholz :

All circles (red,green,insim) circles have the restriction not to overlap.
For the green routechecker circles it makes kinda sense, but is it nessecary for the others?

I agree, it'd be better if we have total freedom where to place them.