InsideQC Forums

This is a diff of the FitQuake 0.85 src against the FitQuake 0.8 src. Helpful if you just want to look at what changed.

I started to start to add protocol666 but imagined that I would have to use all of it or parts that I would want which would basically be NOT protocol 666, so I have yet to start to begin adding it again.

You only really need to ensure that you write and read the correct data. The interpolation part of it might be problematic for engines that already have their own interpolation, for example, so you can just read the data on the client and do absolutely nothing with it after that.

mh wrote:You only really need to ensure that you write and read the correct data. The interpolation part of it might be problematic for engines that already have their own interpolation, for example, so you can just read the data on the client and do absolutely nothing with it after that.

I'm actually suprised that people consider that part of the protocol to be a stumbling block. It's just one number which is easy to store and send, and (like mh says) you could ignore it on the client if you want to.

But, i'm not sure why you would want to ignore it. I'm under the impression that everyone's interpolation code assumes the same thing: 0.1 second intervals between frames (i.e. thinks). If that's the case, wouldn't you want to know when that assumption is wrong, and wouldn't it be fairly simple to substitute a different value for the interval if you had access to it? (which the server does)

metlslime wrote:

mh wrote:You only really need to ensure that you write and read the correct data. The interpolation part of it might be problematic for engines that already have their own interpolation, for example, so you can just read the data on the client and do absolutely nothing with it after that.

I'm actually suprised that people consider that part of the protocol to be a stumbling block. It's just one number which is easy to store and send, and (like mh says) you could ignore it on the client if you want to.

But, i'm not sure why you would want to ignore it. I'm under the impression that everyone's interpolation code assumes the same thing: 0.1 second intervals between frames (i.e. thinks). If that's the case, wouldn't you want to know when that assumption is wrong, and wouldn't it be fairly simple to substitute a different value for the interval if you had access to it? (which the server does)

I think it's more the case that people might be thrown by the rest of your interpolation code (and possibly under the impression that there are dependencies) which is quite different to that which one may be normally used to seeing.

As mh pointed out in another post , a clipnodes fix is needed for more than 32768 clipnodes in a map. May not be obvious to those just looking at the protocol and limits (umm, like I was!). Look at SV_HullPointContents and SV_RecursiveHullCheck.

An easy way to see changes is search for mclipnode_t in Fitzquake source.

I would also suggest reading the 0.80-0.85 diff file (linked above) in notepad++, which does excellent syntax highlighting of diffs.

Thanks for the compliment, you incoherent spambot.

EDIT: oh, now the post i was responding to is gone. I should have quoted it i guess....