[FTE] Auto adjust collision after .scale in CSCQ

[toneddu2000]

[toneddu2000]

really anyone? Even Spike can't think of a workaround? It's quite frustrating to me to fall on this trivial glitch.. I COULD use a different approach but it wouldn't be so satisfying as this one!

[Spike]

if you're calling that repeatedly then you're accumulating those scale changes. which is probably not what you want...

[toneddu2000]

yeah, you're right, but still I don't understand why it increases size even if I don't change player position. And then, it gets smaller and smaller, becoming invisible after some sec.
calling setsize after every .scale operation, shouldn't clear things up?

[Spike]

self.scale = vlen(self.origin - player.origin) / limit;
s = self.scale / 2;
minx = self.mins_x * s; //determine the new model mins

so .scale is set according to the distance to the entity.
and that's fine...
but if your scale is *2, why are you calculating mins as though its scale 1?
and then, why are youreplacing .scale, and yet rescaling mins+maxs since the last call? if you're setting .scale directly you really ought to be setting the mins+maxs relative to their original values like you're rescaling .scale relative to its original value of 1.
also, why use .size when .maxs is easier and more consistent?


one thing you might want to try is using a mins_z of 0. this means you don't have to move the entity up/down as it gets resized. but will need to adjust your model too.
that said, you will need to use tracebox to see if the spot is empty enought for a slightly larger model to fit there.

[toneddu2000]

well, I tried almost everything but nothing changed. I guess I'll go for a static pre-defined increase / decrease way (a thing like "if distance > x setsize(blah)")
I think that a new way of determine collisions (possible via collision meshes) in FTE, would need to be taken in consideration one day, Spike, because it's a really pain in the "@X to manage dynamic collisions in real time (I did my best with tracebox but collision meshes are a MUST, IMO).

Could you please tell me where collisions are handled in engine?

[Spike]

fte still uses world.c to determine when something may need to collide, while pmovetst.c does the job for player prediction colliding against other stuff. its these files that decide which objects need to collide against others. however, the actual collisions themselves are done on a per-model basis, with callbacks specified via impactee->funcs.NativeTrace. If null then only bbox/bbox colisions can happen thanks to fallbacks, while if its set then hitmodel or bsp collisions can be used.

[toneddu2000]

As always I made a mistake in writing my question! My correct question should have been (and also the title of the thread): how engine sets bounding boxes for meshes? Did engine updates bboxes per-frame?
I read World_InitBoxHull () and World_HullForBox() in world.c but I wonder if it's possible to replicate a Bbox set function in a "update" function to re-update every x frame bounding boxes.

Collisions are not my problem, as long as I use tracebox, but I neet that bbox encompass totally model, as csqc defs defines.

[frag.machine]

I don't know if what I'll say applies to your use case, or even if it's valid or recommended in CSQC. But when I made a shrinking gun/attack some time ago I ensured that the .mins and .maxs vectors were directly proportional to .scale (obviously, like Spike already said, I stored the original values to be able to recalc with precision and to restore the entity back once the effect worn off). BTW this allowed me to implement inclusive the "stomp over" a monster attack, Duke Nukem style. From what you say it seems to me your intention is to make the entity look approximately the same size to the player, regardless the distance, right ?

[toneddu2000]

[frag.machine]

[toneddu2000]

Thanks a lot frag.machine, it worked! I know now where I was making a mistake with my old code.
I forgot, when entity is spawned, to save oldscale, oldmins and oldmaxs. Without them, the mins and maxs value will be set to 0, and, in think function, when multiplied * any value, they will produce only 0;
The clamp check it's also a great thing because it prevents over and down scaling

Many thanks again man!