[PATCH] [proposal] Lerp FTE extension

[Xylemon]

https://sourceforge.net/p/fteqw/tickets/140/

nksf wrote on 2022-03-29:

NQ engines supporting the FTE protocol such as QSS and vkQuake experience jittery motion on some entities for which certain mods like Arcane Dimensions set nextthink. Details about this issue can be read at: https://github.com/Novum/vkQuake/issues/309 https://github.com/Shpoike/Quakespasm/issues/45

Instead of a private extension (which is an option), I'd like to add a common one so FTEQW can keep playing demos recorded with it.

The attached patch adds client support for it. Like the existing FITZU_LERPFINISH, the payload gets ignored.

Let me know if this is acceptable.

1 Attachments

interval.patch

[Xylemon]

@Shpoike wrote on 2022-04-10:

1. the fact that you discard the value in the patch demonstrates that the data is kinda redundant in the first place. If the client cannot make use of the info then reporting support to the server is pointless and wasteful.
2. the fact that you do not try to write any data demonstrates that it doesn't solve anything in the long term anyway. Vanilla/proquake+DPP7 servers will also continue to fail to provide any such info, gaining nothing in multiplayer.
3. no writing and no reading does not constitute a well-defined extension.
4. the 1<<30 bit is one of the later ones, and its use would increase typical packet sizes by 4 bytes per entity, instead of just 1 or 2 bytes.
5. 255 msecs as a maximum is insufficient for many custom lerp intervals.
6. this does nothing to smooth out Rogue's buzzsaws (which are in an even worse state). It only helps with its pendulums, which is a minor improvement in the grand scheme of things. (Rogue's lavamen are still an issue too.)

If you want to make improvements then please: a) find other examples where it'll actually help FTE/etc without causing issues/needless bloat. You're likely to find examples of entities moving through thinks of other ents or ents that move on alternate thinks or some such. b) use ULE128 coding or somesuch for the timers in order to allow slower thinkers (eg dpmod needs up to 15 secs or so for its viewmodels). This would not increase bandwidth with typical 0.1-sec intervals. c) repurpose the UF_16BIT flag instead. Using ULE128 encoding as appropriate would also free up UF_EFFECTS2 and make the protocol more robust for the future (if we ever need more than 16bit modelindexes/frames/skins/etc...). using this lower flag would reduce coding overhead. d) make SURE the sender isn't going to send nextthinks in every single snapshot. e) if its always a consistent interval for an entity then the previous value should be valid without needing to waste bandwidth in every packet. doing it based on nextthinks alone is unlikely to be robust enough for this (fitz forgot everything with each new snapshot so this was not previously an option).

Note that quake has other causes of judder too, including inconsistent packet arrival times (bursty connections are BAD). If only mods could depend on framegroups. :(