Hyperjumping calculation (server part)

[phi]

TLDR (not treally, just in a rush)

I was of the understanding that the game calculated targeted jumps with a straight xyz to xyz parabola and "mario" jumps by assuming maximum jump distance, and then recalculating the parabola to where you were (xz) when you released the jump key.
The "snap" back to the new parabola was calculated by % of max distance jumped (eg: 70%) and translating that to % of recalculated jump path.

Con trails are done by the client I believe and when it detected HJ mode it would add a trail object starting at XYZ packet #1 and then adding a end point /start of next trail object at the next XYZ packet. It might need a client patch to turn them back on. which was why the trails would go mental when you released the mario jump key. it would send the XYZ for the original path then for the new snap to point and then if you kept on pressing the HJ key it would send an immediate XYZ so you would get lots of trail objects overlapping.
Eg it would send XYZ #1 then XYZ #2 but if the HJ key was pressed in between points 1 & 2 then it would re-draw segment 1-2 then back from 2 to your current position (#1.5) close to snap points the requests would overlap with the next XYZ packet causing a trail point draw order of something like #1 - #2 - #1.9 - #3 - #2 - #3 - #3.2 ... hence the crazy overlapping contrails.

I could be wrong but most of the client location code seemed to work on the policy of: "client recieves current and next location and interpolates in-between, and then updates current and next location (re-calculating interpolation) if current client location was more than a few (2 or 3) game units apart."

I also think client-server location was synched at the start and end of every server interaction and at a fixed interval.

I'm prety sure that morph mentioned that the client possibly used splines for the parabolic arch which I believe to be true having reviewed game footage