Arc and box, same Z axis height, same parameters size height

[fox in the fog]

[I'm talking about the file attached] Why if the arc and the box-shaped bridge (long and narrow) have the same height in the Z axis and the same height in the parameters size, I can not drive from the box to the arc? When I arrive in front of the arc, the tank stops and does not pass above the arc... Why? What's wrong?
I have posted a bzw file of a very very sample example of what I mean... try
Thanks to all Fox

[blast]

Because BZFlag is buggy. Try using a meshbox instead.

[fox in the fog]

meshbox... So what should I do? Just call these 2 object (in the example map file) instead of box and arc, meshbox and mesharc?

[blast]

Arc is already a mesh object. And a meshbox is actually based on an arc, if I recall correctly.

[fox in the fog]

so just:

arc
position 0 0 10
size 10 10 1
ratio 1
end

meshbox
position 0 0 10
size 5 100 1
rotation 0
end

?

[fox in the fog]

yes blast.... that worked but isn't the best thing to see... but thank you!
Maybe I could post my map so you can see what's the effect and if there is a better way to do that

[fox in the fog]

I have said that isn't the best thing to see because: It has a strange effect ... You can see in jerky a bit of the surface of the arc and a little bit of the surface of the box. Like a frame shooting

[blast]

Are the objects overlapping?

[fox in the fog]

I don't know what is that... Sorry

[fox in the fog]

Sorry blast, I didn't understand... yes are overlapping.

[blast]

Make them so they are not overlapping and that issue will go away.

[fox in the fog]

But... it's impossible... it's going to change all the map. Ah, I've got an idea
Thank you

[hutty]

In almost all 3d games overlapping objects cause a flicker effect.... its not just bz

[optic delusion]

This is just one more time I see what I call "the floating point bug". Pi is used in the calculation of an arc, this is what causes the bug.
To make it worse.... sometimes the bug does not appear when the mapper is testing, it only appears when others use the map. One CPU may calculate Pi differently than another.
The only reliable solution is to re-make one object or the other, probably turn the arc into a mesh.
I have heard that if you get out the calculator, and make your arc with perfect math, it will work. However, I would not bet on that.

[fox in the fog]

Hm.... Ok Optic, i think is going to be a little bit complicated and I'll bear this bug
Thank you for the great information

[anomaly]

It's called 'z fighting' when two overlapped textures at the same height flicker like that. With each frame one or the other may appear to be on top. I"m not sure better calculations will correct that issue. Usually pi is not calculated by the machine, but rather defined as a specific value by the math library. Although you can calculate it if you wish.
4.0 * arctan(1.0) works fairly well.

[trepan]

From the 2.0.14 Changelog:
* Add Options -> Display -> AntiFlicker option - trepan

Only affects boxes and pyramids, iirc. The trick used is to
make coplaner faces use the same texture coordinate space.
The 2.99.x code makes it possible to use a similar setup on
any mesh face is well.

[fox in the fog]

But the AntiFlicker options on my bzflag is on...

[trepan]

Reread my message, as many times as is necessary.

[fox in the fog]

I Have reread your message, and I have understand what you meant. Now the problems is... how do that?

[JeffM]

Only affects boxes and pyramids,

No.. you didn't read it.

[fox in the fog]

Ah... sorry, but i'm not an English man, i reread this message many times, but i didn't understand exactly the literally meaning. Thought another thing But now is ok