| 00:00.10 | TyroneFHornigh | yes, we receive a packet. we know where the tank was at timestamp, so we predict where the tank is at timestamp+latency in order to correctly place it on the client screen. |
| 00:00.33 | Tupone | we don't do this |
| 00:00.51 | Tupone | we put the tank at the position in the packet |
| 00:00.57 | Tupone | I mean now |
| 00:01.09 | *** part/#bzflag drinian (~drinian@pcp03995358pcs.hamntn01.nj.comcast.net) |
| 00:01.13 | TyroneFHornigh | so the tank is always off by the latency of the connection. |
| 00:01.18 | Tupone | yeah |
| 00:01.43 | Tupone | at the next frame, we update the position of the tank to our computed value |
| 00:02.03 | Tupone | but this is true if we do not receive any other update |
| 00:02.17 | TyroneFHornigh | actually, the connections, since it is latency to the server from tank client plus the latency to the server from the display client. |
| 00:02.47 | Tupone | yeah, and I think with a good network this is the best we can do |
| 00:03.33 | TyroneFHornigh | Using DR, we can place the tank at the computed positions, which should be closer to the tank client's state. |
| 00:04.07 | Tupone | but we use DR, as I said just to save bw |
| 00:04.37 | Tupone | any frame, the remote see if the tank position is near to the prediction |
| 00:04.49 | Tupone | if it is near it does not send any update |
| 00:05.19 | Tupone | because the other use the prediction algorithm to position the tank, when new info are missing |
| 00:06.04 | Tupone | when the difference is over a threshold, or some time is passed, send an update |
| 00:07.10 | TyroneFHornigh | What is the reason not to use DR for the initial packet? |
| 00:07.27 | Tupone | what initial packet? |
| 00:08.01 | TyroneFHornigh | the update packet specifys a position. Why are we using that position rather than predicting based on the calculated latency? |
| 00:08.40 | Tupone | because the future is future :) |
| 00:08.55 | Tupone | we don't know what is happening |
| 00:09.01 | TyroneFHornigh | Actually, the future is now in that scenario. |
| 00:09.35 | TyroneFHornigh | some time has passed since the tank was at that position. The time that has passed is at least latency ms. |
| 00:10.10 | Tupone | so the remote will see a tank where is was, I say, 150 msecago |
| 00:10.21 | TyroneFHornigh | The one thing we are sure of is the tank is no longer there unless velocity is 0. |
| 00:10.39 | Tupone | yeah, but we know it was |
| 00:11.27 | Tupone | so what a player see is the exact position of the tank, at a wrong time |
| 00:11.44 | TyroneFHornigh | exactly true ;) |
| 00:11.56 | Tupone | but we cannot do more, unless lieing |
| 00:12.27 | TyroneFHornigh | and shooting a tank at the right position but the wrong time, is a miss, but looks like a hit to the player. |
| 00:12.43 | TyroneFHornigh | or it looks like it should be a hit. |
| 00:12.50 | Tupone | yeah |
| 00:13.23 | Tupone | but imagine a tank predicted wrong |
| 00:13.39 | Tupone | after an update it move instantaneously to another position |
| 00:14.02 | TyroneFHornigh | I don't have to imagine, we're already doing it. |
| 00:14.16 | Tupone | that is when we have jitter |
| 00:14.29 | Tupone | not fixed latency |
| 00:15.45 | TyroneFHornigh | We have it for fixed latency also, especially if we have just calculated and displayed and then we receive an update packet. |
| 00:16.43 | Tupone | the max move should be equal to the DR threshold plus the max move in a frame |
| 00:16.50 | *** join/#bzflag Grumbler (~Grumbler@pool-162-83-21-21.sal.east.verizon.net) |
| 00:17.17 | Tupone | the first is a system variable (IIRC), the other cannot be too much |
| 00:17.44 | TyroneFHornigh | plus the latency of the connections. It's 200ms from me to ducati, and if another player from this side of the pond has similar latency, it would be 200ms back. |
| 00:18.17 | Tupone | but that update take 200msec to arrive to you, so |
| 00:18.52 | TyroneFHornigh | update would be 200ms from tank client to server, and 200 ms from server to me (display client) |
| 00:19.21 | Tupone | I think we can use the wiki to wrote that, so the discussion can be followed and refined :) |
| 00:19.53 | TyroneFHornigh | That sounds like a good idea. |
| 00:20.56 | Tupone | 1 think that we should try is to enlarge the DR threashold, I don't know now the name, and see how many bw is saved, and the effect on the game play |
| 00:21.30 | TyroneFHornigh | I have to head home now, but I'll be back in a while. |
| 00:21.42 | Tupone | I'm heading bed :) |
| 00:52.47 | *** join/#bzflag carnage (strayer@dyn216-8-133-52.ADSL.mnsi.net) |
| 00:54.21 | Grumbler | Nidhoggr, i ran trepan's overlap tool, it handles all the common item block overlaps(ie, block overlaping block), but it does not appear to handle non-common items correctly at this point....ie pyramid bottom overlapping box.....i will ask if this is a real problem or not.....he has a better understanding than I do |
| 00:59.13 | Grumbler | anybody know what the "official" extension for bz maps is? ie is it .map or .bzw |
| 00:59.37 | purple_cow | there is none |
| 01:00.44 | purple_cow | i think .bzw is more common |
| 01:00.46 | purple_cow | and makes more sense |
| 01:00.50 | purple_cow | but it really doesn't matter |
| 01:01.18 | *** join/#bzflag JBdiGriz (~JBdiGriz@adsl-67-120-232-48.dsl.sndg02.pacbell.net) |
| 01:02.14 | Grumbler | yeah, i run into both, bzedit uses .map as default, and i dont think bzfs cares.....have to check |