R U B I C O N R U M B L E P A C K

[Spike]

@ericw, I still think the same way as I did 4 years ago, detect overflows and trivially accept the entity when it happens.
DP can get away with just making these entities visible, as it has a proper deltaing protocol anyway. with the vanilla or fitz protocols you really can't get away with just unconditionally broadcasting ents.

makestatic can be made to work with solid entities by making an invisible clone in ssqc (same modelindex, but the model field clear so it never gets sent). a mod can do this even without mapper assitance.
however, what it can't do is avelocity. the client won't see that field with makestatic, which is what really limits its use in this case.

quake's zone memory is stupid, the hunk too. I could say lots against it, but my chief complaint would be that it breaks valgrind's use-after-free checks.

[ericw]

Ah, I remember reading that somewhere, Spike - yes, sounds like the most appealing approach to me. Thanks for the note MH. I guess dynamically allocating the leafs array would stop any flickering entities, but have the problem that weirdo entities, like the rotator touching many 10s of thousands of leafs, could cause some slowdown during scanning that huge leaf array. Would need benchmarking I guess.

[Baker]

[mh]

[Baker]

Not too many entities hit the 32. The trivial accept method works very well!

[ericw]

[Spike]

hurrah for one-liners

[metlslime]

glad to see this bug finally vanquished.

[ericw]