.float scale

[Seven]

Hello Spike (or anybody who can help me),

I could not find documentation about how .scale is handled in FTE.
fteextensions has not much comments (which a beginner like me needs).

Does FTE also has .scale accuracy steps of 1/16th, like DP does ?
Or is FTE free to produce whatever .scale you want ?
That would effect fluent morphing quite much, which is a bit choppy in DP.


Do other engines also support .scale ?
Anybody knows of any ?

Thank you very much for your help.

[Spike]

aye, 1/16th precision. a byte that scales up to 15.9375 or so.
if you want more precision, use csqc. you should get full float precision then.

I think nehahra might also support scale. I don't know what it uses it for, but I'm sure the demo format has lots of nice large floats on every single entity that are never really used...

hexen2 support added a drawflags field:
self.drawflags = SCALE_ORIGIN_BOTTOM; //=32
this setting will keep the bottom of the entity at the bottom of the bbox, so it won't float around, etc.

[Seven]

[Spike]

.scale doesn't affect collisions. which is the problem. because it means that with a scale of 2 or so, the feet of the enemy are clearly inside the floor.

You can fix that with something like the following

self.scale = floor(self.scale*16)/16; //match the engine's scaling.
minz = self.mins_z * self.scale; //determine the new model mins
sizez = self.size_z * self.scale; //determine the new model size
self.origin_z += minz*(1-sizez); //move the monster around to keep its mins_z constant despite the resize
setsize(self, [self.mins_x,self.mins_y,minz], [self.maxs_x, self.maxs_x, sizez-minz]); //and resize it.

bsp/bbox collisions are aligned to the bbox mins value. this means that the mins_z needs to be correct for the new position, and the maxs_z can be almost whatever it wants (although if the scale is too high, you might notice the monster's head passing through walls - which you can generally get away with with good map design). but you can't get away with changing the x+y mins without offsetting that so noticably.

anyway, that's the idea.

[Seven]

[frag.machine]

Both solutions will work, but Spike's *theorically* avoid trial-and-error adjusts.
Is there any Quake engine that supports multiple/composite bound boxes ?

[Spike]

seven, your code potentially allows people to shoot through the monster's head.
note that your monster's bbox is already 8qu taller than the hull size.
hardcoding is fine if you want less code. its just that you need to hardcode every case and thus quite likely more code in the end.

frag.machine, while it would be possible to simulate larger hull sizes from smaller ones, doing so would require 8 times as much work, and would not aid with crouching. enabling such a feature would likely break a load of mods (like any monster that's defined to be 64qu high placed a qu or two above the ground in a small passageway, for instance).
q2+q3 use brush collisions and thus do not require descrete hull sizes. this is the preferable way to do it, especially as this also potentially allows support for capsules too. taniwha added some poly collision code to quakeforge a while ago which would have the same effect, while tonik has previously made a direct q1bsp->q2bsp converter. the problem with these automatic methods is that they ignore clip brushes, which means the player suddenly gets stuck on all sorts of sticky out bits of the map.
as bbox sizes increase, the axial nature of bboxes gets more and more goofy, so anything that allows ditching aabb collisions completely is a good thing.
I really do wonder what would happen if a qbsp were to generate capsule-shaped hulls instead of bbox ones. theoretically it would be possible to support any convex shape from the qbsp...