BUG?: func_button lip value not working as supposed to

[Toolwut]

http://panjoo.tastyspleen.net/rust/tutorials/func_button/func_button.html says "Lip is the length of the button that is offset after being activated. So if you have a large lip value then more of the button will stick out after being pressed in.". I understand this as "set a lip value equal to the length of the button in the direction it will move, it won't move at all".

I made a func_button with a size of (64 units)³, set "angle 90" and "lip 64" but the button moves. setting "lip 66" makes it entirely static.

[jitspoe]

Looking at the code, I don't see anything adding an extra 2 units:

dist = abs_movedir[0] * ent->size[0] + abs_movedir[1] * ent->size[1] + abs_movedir[2] * ent->size[2] - st.lip;

Perhaps the ent size is an extra 2 units for some reason?  Maybe there's a 2 unit area around it so you can touch it?  Do triggers that are shot behave the same?

[Toolwut]

I'm not sure about the first two questions or how to test them. For the third, yeah it's the same for "health" "1".

Probably not worth fixing though as it could "break" other maps.

[jitspoe]

Hmm, yeah, for some reason it thinks the size of the entity is 66x66x18.  And that is set from the mins and maxs, which means those must be off by one: VectorSubtract(ent->maxs, ent->mins, ent->size);

Edit: Took a while to finally track this down.  It's in CMod_LoadSubmodels().

Code: [Select]

for ( i=0 ; i<count ; i++, in++, out++)
{
out = &map_cmodels[i];

for (j=0 ; j<3 ; j++)
{ // spread the mins / maxs by a pixel
out->mins[j] = LittleFloat (in->mins[j]) - 1;
out->maxs[j] = LittleFloat (in->maxs[j]) + 1;
out->origin[j] = LittleFloat (in->origin[j]);
}
out->headnode = LittleLong (in->headnode);
}
Not sure why they increase it by 1.  Wonder what would break if that were removed.

[Toolwut]

Wouldn't it be the safest then if all the lip values are increased by 2 internally? If I got it right, lip values are always relative to the position of the bmodel if it is translated once by its own length in the direction of "angle". Such a change would probably do nothing to existing maps as apparently no one ever did such high precision things, or otherwise someone would have already reported this behavior.

Also, wonder why it's called pixel instead of unit in that comment.