| 00:34.17 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |
| 01:31.21 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 05:56.49 | *** join/#bzflag allejo (~allejo@bzflag/developer/allejo) |
| 05:56.49 | *** mode/#bzflag [+v allejo] by ChanServ |
| 07:12.30 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 07:16.43 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 07:18.03 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 07:18.29 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 07:33.32 | *** join/#bzflag cods (~fred@tuxee.net) |
| 11:36.20 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 13:29.01 | blast007 | http://fabiensanglard.net/doom3_documentation/The-DOOM-III-Network-Architecture.pdf page 9 and 10 start describing a lag compensation method that seems worth looking into further |
| 13:30.29 | blast007 | basically, the client simulation runs a bit more than the round trip lag time ahead of the server via client-side prediction, and gets state snapshots from the server at regular intervals, and re-runs the simulation from that snapshot time up back up to the local client time |
| 15:05.57 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |
| 15:31.58 | *** join/#bzflag Flak18 (~Flak@2601:58b:c400:4681:65e8:dd06:351e:7cfe) |
| 15:45.24 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |
| 16:19.03 | *** join/#bzflag blast007 (~blast007@bzflag/developer/Blast) |
| 16:26.58 | *** join/#bzflag I_Died_Once_ (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 16:37.00 | *** join/#bzflag Kaelten (Kaelten@WoWUIDev/WoWAce/WoWIFA/CurseStaff/kaelten) |
| 16:37.55 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 17:01.46 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 17:13.38 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 17:55.22 | *** join/#bzflag I_Died_Once_ (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 18:00.55 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 18:06.24 | *** join/#bzflag I_Died_Once_ (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 18:31.47 | macsforme | sounds like a similar concept to what we were trying to do with 3.0, re-predicting enemy tank positions with every update based on the latest data |
| 18:32.56 | blast007 | except I think the client time was behind the server time |
| 18:33.15 | macsforme | not that it's a bad concept, but it seems to me like it would still result in the perception of extremely laggy tanks jumping around and/or shells appearing far in front of where they were fired |
| 18:34.37 | blast007 | I'd have to map out a timeline to see how that would work |
| 18:35.32 | blast007 | I think the doom III model favors lower lag, but it's a bit hard to wrap my head around just reading text :) |
| 18:36.04 | macsforme | yeah |
| 18:37.07 | macsforme | I think we would want to generally favor players with low lag, but also avoid making players with high lag perform a "lag dodge" to avoid being hit |
| 18:38.27 | blast007 | it sounded like the doom III model that players would see other players on their screen in the same location that the server thinks they are at |
| 18:39.42 | blast007 | "Unlike Quake III Arena there is no time difference between what the player sees on screen and the player movement through the environment. Therefore the player does not need to lead targets because the system does the prediction for the player. " |
| 18:43.24 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 18:43.46 | macsforme | yes, where the server thinks they will be, but still based on outdated data... that's the big stumbling block we can't get past |
| 18:44.31 | blast007 | yes, I'm not sure how input sent from the client is handled in Doom III |
| 18:47.00 | blast007 | not sure if it's rolled back to the point where the input would have happened, or if it's just treated like the player has not sent that input until "time from client to server latency" later |
| 18:48.22 | blast007 | the former might not be easily feasible without storing old state on the server and doing a lot of recalculations, so it might be the former, which would certainly make players with high lag have more issue playing |
| 18:48.30 | blast007 | might be the latter* |
| 18:50.42 | macsforme | I assume the latter, because the client providing the input is running ahead of the server time |
| 18:55.51 | blast007 | time travel is hard |
| 18:58.50 | macsforme | we might be able to find the "sweet spot" with some combination of position prediction, a slight delay in shots being fired on the shooter's side (based on shooter's lag), and a slight advance of shots being fired on the target's side (based on target's lag) if we play around with it a little bit |
| 19:00.49 | macsforme | and this is yet another problem with the BZDB, where people started making tanks faster (and now everyone is used to that), which exacerbates the lag problem |
| 19:02.38 | blast007 | I'm not worrying about fixing the current codebase |
| 19:02.56 | blast007 | I'm thinking about the possible rewrite |
| 19:03.33 | blast007 | been working on collecting information and drafting up a rough design plan |
| 19:04.21 | blast007 | what's the best way to do collaborative work on such a thing? I've been putting it in Google Docs, but that seems "evil" for an open-source project. ;) |
| 19:08.12 | macsforme | where's alpha1-2 when you need him? :) |
| 19:08.47 | blast007 | Etherpad might be an option |
| 19:10.04 | zuii | genmymodel, plantuml? |
| 19:16.40 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-swjtuhkfttpyeitq) |
| 19:23.19 | blast007 | mines mostly been an information dump so far: https://docs.google.com/document/d/1xBUByF5D2-tmLe5NZW7yg5D5oUKwbaZkjKoN7PJ1dR4/edit?usp=sharing |
| 19:23.47 | blast007 | was starting to work out how services would work but haven't added anything there yet |
| 19:24.33 | KaadmY | blast007: what's that? |
| 19:24.41 | KaadmY | that meaning NewGameNG |
| 19:24.48 | blast007 | start of a rough play for a rewrite |
| 19:24.50 | blast007 | plan* |
| 19:25.20 | KaadmY | wow |
| 19:25.26 | KaadmY | what, 4th rewrite in progress? |
| 19:25.49 | blast007 | it's not a rewrite in progress |
| 19:26.02 | blast007 | it's a plan for a rewrite |
| 19:26.17 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |
| 19:26.17 | KaadmY | about the 5th plan, too :) |
| 19:26.25 | KaadmY | 5th=my plan which failed |
| 19:26.32 | blast007 | oh there's always lots of ideas ;) |
| 19:26.35 | zuii | quite properly put together |
| 19:27.45 | zuii | sry google translate... |
| 21:56.55 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 23:28.13 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |