| *** infobot <infobot!ibot@c-174-52-60-165.hsd1.ut.comcast.net> has quit IRC (Remote host closed the connection) | 00:15 | |
| *** infobot <infobot!ibot@c-174-52-60-165.hsd1.ut.comcast.net> has joined #bzflag | 00:15 | |
| *** ChanServ sets mode: +v infobot | 00:15 | |
| *** brlcad <brlcad!~sean@104.225.5.10> has joined #bzflag | 03:15 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 264 seconds) | 03:31 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 03:35 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 03:36 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 244 seconds) | 03:40 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Read error: Connection reset by peer) | 03:41 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 04:48 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 246 seconds) | 05:22 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 08:18 | |
| *** BZNotify <BZNotify!~BZNotify@bzexcess.com> has joined #bzflag | 09:19 | |
| *** spldart <spldart!~james@bzflag/contributor/spldart> has joined #bzflag | 12:02 | |
| *** ChanServ sets mode: +v spldart | 12:02 | |
| *** Flash <Flash!~flash@2601:280:c200:4e39:e55a:6ce5:363b:9a85> has quit IRC (Ping timeout: 250 seconds) | 12:24 | |
| *** Notify <Notify!~notify@104.225.5.10> has joined #bzflag | 12:28 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 13:20 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 246 seconds) | 13:21 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 14:54 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 14:57 | |
| *** Cobra_Fast <Cobra_Fast!~coprah@wtwrp.de> has quit IRC (Quit: ZNC - http://znc.sourceforge.net) | 19:32 | |
| *** Cobra_Fast <Cobra_Fast!~coprah@wtwrp.de> has joined #bzflag | 19:35 | |
| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has joined #bzflag | 20:01 | |
| *** galileo <galileo!~QUJAAAAAA@24-224-250-196.eastlink.ca> has quit IRC (Ping timeout: 245 seconds) | 20:10 | |
| 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:27 |
|---|---|---|
| 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 |
| blast007 | I think reloading is handled purely client-side | 22:28 |
| blast007 | that specific issue may be that a thief shot is being reset to a normal shot on the server | 22:29 |
| *** spldart is now known as Foo_man_choo | 22:30 | |
| *** ChanServ sets mode: -v Foo_man_choo | 22:30 | |
| 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 |
| Zehra | myTank->forceReload(BZDB.eval(StateDatabase::BZDB_THIEFDROPTIME)); | 22:32 |
| 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:32 |
| blast007 | that, or the order of some code in the client could be wrong | 22:33 |
| Zehra | The order of the code seems right from what I can tell. | 22:38 |
| blast007 | so you've replicated the problem? | 22:39 |
| Zehra | Nope. But trying to see if one theory of mine holds water. | 22:40 |
| 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 |
| Zehra | Technically it should simply add additional "time", but I don't think this happens when the conditions are right. | 22:42 |
| Zehra | It might sound crazy, but I'm sort of thinking that may be where the problem lies. | 22:43 |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!