This is a client side problem that has been fixed in cgame.  The bbox shown is correct, the model was just drawing in the wrong place.

Actually I think this one is actually valid. It happens because the buildable drawing code uses a cap trace (so that things sit on slopes properly), whereas the server side uses a box trace.

It's been there forever, but it's pretty much a corner case so I've always avoided doing anything about it.

How about just tying the bbox and model together using some common point (origin)?

Because that wouldn't work. In that case anything that sat on a non-axial surface would appear to float above it.

The fix is really to further restrict where buildings can be placed, so that they can't sit with say >50% of their base overhanging an edge. That has the side effect of preventing some of the more "creative" base designs though. I think such things look ridiculous, but some may complain.

like this ? http://www.keepmyfile.com/image/388a0b1245600
this is latest svn :(

imo martin has a point, player doesnt care about bboxes, he wants to shoot stuff and kill it or jump over it.
Is there some restriction that doesnt let bboxes to cross map surfaces? if not then just tie "bbox and model together using some common point
(origin)", like for example the center or the model. 
I mean whats worse, invisible BBox that blocks you, and you have no idea where to shoot, or a little smaller bbox (some of it would end up inside map geometry) in the right place? Just use current client buildable drawing code for determining where stuff should go, and then slapping bbox over it regardless of map geometry.



and proper down to single triangle collision detection procedure would really be neat :P

Just... let me deal with it.

It's very bad when is allowed build on top of each other buildable and bbox is somewhere else than model. And building like this is so fun...

Created attachment 2392 [details]
Fix

The function CG_PositionAndOrientateBuildable uses CG_CapTrace initially to
place the buildable, and if errors are detected, then it resorts to CG_Trace.
However, it appears that not all of the errors can be caught, resulting in the
nasty visual bugs described above. Using CG_Trace in all cases fixes the bug
and does not appear to degrade performance significantly or break anything else
as far as I have found.

*** Bug 4695 has been marked as a duplicate of this bug. ***

Created attachment 2413 [details]
Screenshot describing buggy behavior

Simply mandating that a specific portion of the buildable's bbox be touching a solid suface would not fix this unless the mandated portion was close to 100%. Not only is it merely a workaround, but it does not solve this in all cases. The new screenshot shows the a telenode glitched into a skid of barrels on niveus. It would be perfectly natural for a telenode to be built there if thinking of the real properties of steel, and most of the telenode is built on a solid surface (actually I believe its all solid for player movement purposes).

To make this even more difficult I believe this picture means that one could also engineer a map where 99% of the buildable is placed on a solid surface.

I think the only true solution here is a change in the trace. Even if a box trace isn't used in the end, a cap trace is insufficient.

Created attachment 2443 [details]
alternative fix

I think that the main problem is that cap traces don't work well for "flat" structures, i.e. whose height is less than their width.

This is because the engine constructs the largest capsule that fits entirely within the bbox passed. A capsule is defined as two hemispheres connected by a vertical cylinder of the same radius.

When the bbox height equals the width, the capsule degrades to a sphere, if the height is less than the witdth, the "capsule" is a sphere with diameter equal to the height. So for a telenode (width = 80 units, height = 10 units) the capsule trace traces only a diameter 10 sphere, which fits between the barrels, although a diameter 80 sphere would not.

This patch increases the height of the bbox for the cap trace, so that the capsule uses always the full width of the bbox.

Created attachment 2547 [details]
Second Alternate Fix

This patch prevents buildables from appearing more than 15 quake distance units away from where it would be rendered using a bbox trace, enough to prevent buildables appearing to be invisible, but still allowing buildables to sink into the ground.

I suggest two small improvements to your patch:

You can use the function Distance(tr.endpos, box_tr.endpos) to calculate mag, and the assignment tr = box_tr does an unnecessary struct copy, but you're only interested in the fraction component, so you should just use a temporary float var for the fraction value.

Created attachment 2557 [details]
cleaned up second alternative fix

Applied gimhael's suggestions and otherwise cleaned up WilliamH's "second alternative fix" patch.

After testing it a bit I think about does it and really ought to make everyone happy. I'm going to ci it shortly if nobody objects. Going once, going twice?

r2104. Thank you all.