"Big Maps" FitzQuakeprotocol: [90/10 Non-Tutorial]
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
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.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.
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.metlslime wrote: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.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.
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)
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
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.
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.