Quote :

I suppose it's to avoid intersecting physics objects that fly apart madly when touched. That problem doesn't really apply to unmovable objects. But then the question is, why would you want ordinary objects to intersect?

I always found this restriction to be a hindrance. It is useful for them to intersect to make proper selections or to make things more visually pleasing. EDIT: See the attachments in the next post for illustration. It looks better to have barriers or speed humps touch instead of having a small gap. It also gives the impression it's just 1 big barrier. That's another advantage (the heading precision limitation can be tricky though), visually you can make a bigger object out of several objects without showing it's actually several objects intersecting.

Quote :

It's not a kart, but it is an FSAE car (with suspension and a 600cc motorbike engine).

I tried to find out if FSAE cars had handbrakes, and I asked on the forum too. I did not hear from anyone on the forum and I could not find any reference that stated that FSAE cars have a handbrake.

In the end, after watching some FSAE videos, I thought it was quite unlikely that they have one, so decided to exclude them like the other single seaters.

Personally, I sometimes used handbrake (on MRT & F08 mainly) in situations where I had to make a quick U - turn and you have only a small spot to do this. It's probably very unrealistic so I suppose it's better to just get used to it. Otherwise, making it optional with a server command (/FormulaHandbrake=yes)?


OFF-TOPIC:

The new InSim packets are refreshing, but I still have some small debatable suggestions:
• You must setup your IS_AXM with the players UCID when the PMOACTION is PMO_SELECTION. When the PMOACTION is PMO_ADD_OBJECTS the UCID in the IS_AXM reply is always 0. It could be useful to report the UCID set even when PMOACTION is not PMO_SELECTION. I suppose this would require 2 new PMO's though:

Quote :

PMO_ADD_OBJECTS_UCID
PMO_DEL_OBJECTS_UCID

• Marshall objects can be diameter 0 with InSim IS_AXM (useful to have a marshall that doesn't spectate you when you drive through it). I suggest the ability to lower the diameter to 0 but perhaps you don't want this with the autocross editor because a restricted area wouldn't be one anymore if diameter is 0?

• You must click edit in the autocross editor for an IS_AXM with PMOACTION == PMO_SELECTION to work. Why not lift this limitation? When the packet is sent even when edit is not clicked it should work. Some InSim programs might want to prepare a selection of objects before edit in the autocross editor is pressed.

Quote from sicotange :

When the PMOACTION is PMO_ADD_OBJECTS the UCID in the IS_AXM reply is always 0. It could be useful to report the UCID set even when PMOACTION is not PMO_SELECTION.

I think the UCID is zero because the objects were created by the InSim program running on the host.

Quote from sicotange :

• You must click edit in the autocross editor for an IS_AXM with PMOACTION == PMO_SELECTION to work. Why not lift this limitation?

So what is the suggestion really? That LFS should automatically change the editor into edit mode if a selected objects packet is received?

Quote :

I think the UCID is zero because the objects were created by the InSim program running on the host.

I understand it would be confusing to be able to set UCID when the PMOACTION is PMO_ADD_OBJECTS or
PMO_DEL_OBJECTS (that's why new PMOACTIONS would probably be required). The global picture here is that his would make it easier for InSim programmers to know what objects are related to whom. For example: an admin clicks an InSim button. The InSim program adds object(s) by sending an IS_AXM. In the reply, the InSim program would detect this and deal with it / maintain things accordingly.

Quote :

So what is the suggestion really? That LFS should automatically change the editor into edit mode if a selected objects packet is received?

For example, I suggested it the other way around. The selection is hidden until edit is pressed.

Can the spawn on concrete objects detection Zbyte be lowered a bit by default? I have custom pitboxes but with a concrete roof the cars are spawned on the concrete object instead of the LFS track asfalt (see attachments).
Anyone else encounters this annoyance?

Having no problems if pitbox arrow placed just below (where Z height of ground is above 0) or on ground.

Did you click the 'place on ground' button?

Edit: Just tested, and if pit arrow placed 0.5m above ground, then you will pit on slab above.

It seems to me the spawn points just have too high a Z value. LFS searches for a surface downwards from 2m above the spawn point's z value.

If you put a start position on the ground there and reset, are you spawned on top of the concrete? [edit - sinanju says it's ok in this case].

Also if you car is below there and you press SPACE, does your car jump above the concrete?

If you are using car positions to get the original value for spawn points, you could try lowering the Z value by 0.5m so it's near ground level instead of near the centre of gravity.

It looks like if Z of slab is 2.25m above arrow spawn point then you spawn on ground.

I did more tests where ground was 10.25 and slab was 12.50 and car spawns on ground, but if slab was lowered to 12.25, then car spawns on slab.

Ok my bad. I can now reproduce things. The car Z reported in IS_MCI is 15 on the ground. The concrete object as in the screenshot has a Zbyte of 17.25. In this case it gets spawned on the concrete (if I press space or send an IS_JRR) no matter the Zbyte in IS_JRR (even 0).

I conclude that the check is the car's Z relative to the concrete object Z? So moving my chalk arrows didn't change anything but moving the concrete object by factor 1 (from 17.25 to 17.50) fixed the issue. If it is a constant value, could you provide the documentation? To be safe a difference between car Z and object Z of 2.50m is advisable?