[ for programmers ]

The new Blackwood uses unmovable objects on many of the kerbs, and this has resulted in many IS_OBH packets being sent, with index 0 (unknown object). Clearly external programs don't want to know about this. It's just part of the ground and they don't want a flood of packets, one for each individual kerb object.

But looking into this, there are more issues and considerations.

It turns out that the same info is sent constantly, every time a car drives on any object, including the concrete objects. Sometimes these are used extensively for large areas of track and a new packet is sent every time a car touches a new piece of concrete.

One simple solution would be to avoid reporting contacts with any unmovable objects at all. I haven't thought of any other solutions yet! But would this be too drastic? What reasons might there be to report any kind of contact with unmovable objects?

Do we need to avoid this reporting on a subset of unmovable objects, or all of them?

Well, some servers has a type of Car Health. Every crash the Health decreases, so I think it is the problem. But it is not my problem

I am not a programmer, but I do know what is the thing here. Ultimately, I am used indirectly for this...

First of all, it would be absolutely too drastic to remove any reports of contact/collisions. Unless there is way to add more and/or different InSim objects, or even tag some areas with specific one, which could then send invidual data. BTW, InSim Objects which are becoming to be very, very useful as more people starts using them.

In my opinion the recent addition of InSim checkpoints/circles renders IS_OBH less useful. The following scenarios I can think of where IS_OBH shines:
• any kind of stunting where landing on platforms etc. should be detected
• manoeuvring in areas filled with unmovable objects where penalties are given if an object is hit
• touching an object to remove it

Hard to do deep analysis so easy. Here are things to consider:

* being able to detect specific curbs (the set ones on blackwood) might help insim clients to detect illegal or unsafe moves, crashes, whatnot

* those are not good considering traffic saving and backwards compatibility (the fixes seem to be easy for my app though)

Personally, I think it would be ok to have info about the whole drivable surface crossing(with another type of packet, not with IS_OBH). But contact report should really happen only when you hit something movable, or when you hit it with any car part but rubber.

Those my initial thoughts, need to consider more...

Thanks for the comments. I may have a solution here. In fact I have found the tyres on concrete "roads" gave unreliable results anyway, because they depend on a "closing speed" and that is near to zero because your car is traveling parallel to the surface. So that's why it didn't in fact report IS_OBJ on every concrete object, but often did on hitting a new concrete objects with a steeper gradient.

The possible solution I've tested is to carry on reporting body contacts as before, but avoid reporting when a tyre contact point touches an unmovable object. This way the excessive kerb reporting issue is avoided, and the unreliable concrete reporting is turned to zero.

So far this seems to be working but I'll test some more now. I'm concerned about the situation of someone with low suspension scraping a little, reporting too many of these "collisions".

EDIT:

Quote from vitaly_m :

But contact report should really happen only when you hit something movable, or when you hit it with any car part but rubber.

Interesting that while I was posting, you came up with this that matches my proposed solution.

Quote from Scawen :

Interesting that while I was posting, you came up with this that matches my proposed solution.

Still it is hard to tell what to do with low suspension cars scratching the road... I don't think you should take responsibility of filtering those out in any complicated way, but simply report them with some specific flag, or just exclude from report.

Interesting note btw, there is this wooden thing they put on racing cars, so that metal parts are protected a bit.

You mean the undertray skid plank (i.e tea table?)
Those are used in GT, Open wheel cars, and might solve the problem... but you can't stick the same plank under road cars like the XRT..

Nice solution with ignoring tyres contacts. I'm using OBH packets for clean laps validation, yes low suspension cars scratching the road could be problem. Could it be possible to change index of surface objects (kerbs) to something else then 0, so I can filter false OBH packets?

Further testing shows there is a definite problem with body touching kerbs, e.g. using a FO8 with default setup.

I don't really want to just allow you to filter the packets, I really don't want to send so many packets at all because these are sent from guests to host, not only through InSim.

I wonder if another exclusion can be added - how about excluding bodywork that touches a non-movable object that was not placed in a layout? It would still report body contact with all movable objects and all unmovable layout objects.

Quote from Scawen :

I wonder if another exclusion can be added - how about excluding bodywork that touches a non-movable object that was not placed in a layout? It would still report body contact with all movable objects and all unmovable layout objects.

I wouldn't have a problem with that. Sounds reasonable, not sure if those cruise servers rely on that though...

I see, think it should be OK in my use case too

Quote from Scawen :

I wonder if another exclusion can be added - how about excluding bodywork that touches a non-movable object that was not placed in a layout? It would still report body contact with all movable objects and all unmovable layout objects.

Sounds acceptable to me. It is not so perfect, because with layouts there won't be any bulletproof solution of clean laps detection on layouts which use concrete objects... But it's okay and it is definitely not worse than before.

Maybe i'm thinking to easy now but,
whould it be an idea to disable the "Unknown objects" by default. And enable it when Host/Insim sents a packet to the guest(s).

Sort like the "Siren" command.

OK, here is a test for this specific issue.

IS_OBH will be reported less frequently now.

TYRE contacts - IS_OBH is only reported when a movable object is hit
BODY contacts - IS_OBH is reported for all movable objects and unmovable layout objects

Previously, TYRE and BODY reported all object contacts regardless of movable or in a layout.

This is only the EXE - 0.6Q10 must already be installed!

[In a Hypotethical case | This is just an example]

Let's say that IS_OBH reports will be removed, shouldn't this mean that for example people could create shortcuts with concrete slabs to make faster laps (for example BL chicanes)?? Or there will be exceptions to when IS_OBH are ignored or listed??.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-


Also, I noticed that when normally racing, even if you drive off the track, touch the grass or go off-bounds, if you make a fast lap, it counts, when in reality it shouldn't be a valid lap because of the reasons before mentioned. Like it ignores any of these packets.

Quote from Ibtasim6781 :

Also, I noticed that when normally racing, even if you drive off the track, touch the grass or go off-bounds, if you make a fast lap, it counts, when in reality it shouldn't be a valid lap because of the reasons before mentioned. Like it ignores any of these packets.

Technically, as long as you have at least two wheels on the track, ie, inside the white lines, you're still considered in-bounds. In NZ, you are only considered out of bounds if all four wheels leave the track.

Quote from Shirtkicker :

Technically, as long as you have at least two wheels on the track, ie, inside the white lines, you're still considered in-bounds. In NZ, you are only considered out of bounds if all four wheels leave the track.

Of course I meant off-bounds when you have all 4 wheels off the white lines, which in LFS also means the bounds of the track itself.

The best example of this is how FBM fast drivers/WR get a low split (0.23s), they cut directly thru the first chicane after T1, exiting to the straight, 2 wheels are on the green sausage kerb and the other 2 wheels are on the grass. I leave an example with an old WR:
https://youtu.be/BDBXOJCAgaM?t=37s
This is how people (included me) take that last part of the chicane.

So I think that the new kerbs are there to avoid this type of driving/cutting.

Quote from Ibtasim6781 :

Of course I meant off-bounds when you have all 4 wheels off the white lines, which in LFS also means the bounds of the track itself.

The best example of this is how FBM fast drivers/WR get a low split (0.23s), they cut directly thru the first chicane after T1, exiting to the straight, 2 wheels are on the green sausage kerb and the other 2 wheels are on the grass. I leave an example with an old WR:
https://youtu.be/BDBXOJCAgaM?t=37s
This is how people (included me) take that last part of the chicane.

So I think that the new kerbs are there to avoid this type of driving/cutting.

Probably in the long run we could get the times down to what "old" Blackwood was, because in widening the second island on the chicane you can straighten up more, meaning less reliance to bunny hop the third island.
In simracing terms if one part of the corner is tightened but the other widened in theory it should compensate and give back the time you lost on the tightened bit.
Another example is the turn 6-7 esses. Previously the GTi class would cut the second part by putting all 4s through the grass between tire bundle and kerb - now with a willy kerb you can't do that anymore. Yes, lost time, but on the corner before that, the apex kerb has been moved inwards and widened, meaning you can take a widing line and not hit the next willy kerb.
Right I'm straying off topic,
One problem I found yesterday is when your tire touches the yellow/black round circles on the chicane it registers as an object hit..? (Happened on a cruise server, and also race server where LFSLazy detected it as invalid lap (object). Is it fixed?

Sorry that I'm late for this.

I think that the hitting the concrete of the road with the car (tire or body) should not emit an OBJ packet. I think that hitting the curb with the car (tire or body) should not emit an OBJ packet. Everything else should because that's unexpected behavior.

Which means you can hit the track as hard as you want without detection (and kerbs are part of valid track).

Makes sense to me, but I'm afraid that's not the categorization which is easy to achieve, it would require to mark objects as part of valid-track.

With the built-in tracks it's probably ok, but with concrete in layouts, you can't reliably tell which part is "wall" and which is "surface", so it would be up to layout editor to either mark them in some post-process, or to have two different concrete object to select (I mean the identical 3D model, but with different flag).

I think that's fine. It's up to us as InSim programmers to say that for this object in this layout file ignore the OBJ packet.

Quote from Ped7g :

...

With the built-in tracks it's probably ok, but with concrete in layouts, you can't reliably tell which part is "wall" and which is "surface", so it would be up to layout editor to either mark them in some post-process, or to have two different concrete object to select (I mean the identical 3D model, but with different flag).

Well, to me current situation is reasonable enough. You should make layouts the way it is impossible to drive over illegal objects. With concrete surfaces you don't get the OBH as long as you only touch them with tyres. (scratching is too complex case, and to me it doesnt really matter too much)

Hello programmers,

I've come across this again in the code and think I should ask you again now that the current system has been around for years.

I've been updating the collision detection of non-movable objects. There are so many objects around now, it has become quite inefficient to use the old system which uses the storage system of a movable physics object even for unmovable objects. I'm now using a much more compressed data structure for unmovable objects, that uses less memory and CPU.

But now that the movable and unmovable objects use a different type of data structure, it has become harder to support the reporting of contacts with unmovable objects.

I'm wondering if it is reasonable to stop reporting collisions with unmovable layout objects now. The way I'm thinking of this, the unmovable layout objects would be treated just the same as default non-layout objects that Eric has placed.

Movable objects would continue to be reported as before.

i know server that using collision detection with unmovable objects for drift score. its named "kiss the wall"
my server use collision detection with unmovable objects in "drive school"