| 00:15.58 | *** join/#bzflag infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:15.58 | *** topic/#bzflag is https://BZFlag.org || https://www.openhub.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || Current version: 2.4.18 || New shiny website! https://forums.bzflag.org/viewtopic.php?f=8&t=20201 |
| 00:15.58 | *** mode/#bzflag [+v infobot] by ChanServ |
| 03:15.00 | *** join/#bzflag brlcad (~sean@104.225.5.10) |
| 03:35.22 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 03:36.51 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 04:48.20 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 08:18.02 | *** join/#bzflag Sgeo (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 09:19.04 | *** join/#bzflag BZNotify (~BZNotify@bzexcess.com) |
| 12:02.43 | *** join/#bzflag spldart (~james@bzflag/contributor/spldart) |
| 12:02.43 | *** mode/#bzflag [+v spldart] by ChanServ |
| 12:28.32 | *** join/#bzflag Notify (~notify@104.225.5.10) |
| 13:20.01 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 14:54.54 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 19:35.58 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 20:01.18 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:27.00 | Zehra | Two quick questions, can reload time be modified while the client is "reloading" and can "reloading" be forced again, even though the client is already reloading. |
| 22:28.21 | Zehra | The questions are related to https://github.com/BZFlag-Dev/bzflag/issues/204 - "Thief doesn't always set reload timer before being able to fire." |
| 22:28.23 | blast007 | I think reloading is handled purely client-side |
| 22:29.07 | blast007 | that specific issue may be that a thief shot is being reset to a normal shot on the server |
| 22:30.38 | *** mode/#bzflag [-v Foo_man_choo] by ChanServ |
| 22:32.14 | Zehra | I'm thinking that it might be related to "forceReload" under the conditions of when the client is already "reloading" and forcing another "reload" to occur. |
| 22:32.46 | Zehra | myTank->forceReload(BZDB.eval(StateDatabase::BZDB_THIEFDROPTIME)); |
| 22:32.49 | blast007 | I know that can happen at least with shot limits if you're shooting fast enough or have high enough latency. Your client still things it has X flag when you shoot, so it sends a shot message with that type. But the server has already dropped your flag, so when it receives that shot message, it resets it to no flag. |
| 22:33.37 | blast007 | that, or the order of some code in the client could be wrong |
| 22:38.29 | Zehra | The order of the code seems right from what I can tell. |
| 22:39.42 | blast007 | so you've replicated the problem? |
| 22:40.57 | Zehra | Nope. But trying to see if one theory of mine holds water. |
| 22:42.11 | Zehra | If "LocalPlayer::getReloadTime" is in the reloading state for all shots and the flag is dropped, this triggers "Player::forceReload", but what happens when it is already with all in the reloading state? |
| 22:42.52 | Zehra | Technically it should simply add additional "time", but I don't think this happens when the conditions are right. |
| 22:43.57 | Zehra | It might sound crazy, but I'm sort of thinking that may be where the problem lies. |