| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 252 seconds) | 03:47 | |
| *** flash[m] <flash[m]!~flashgnur@2001:470:69fc:105::e302> has quit IRC (*.net *.split) | 03:48 | |
| *** cods <cods!~fred@82-65-232-44.subs.proxad.net> has quit IRC (*.net *.split) | 03:48 | |
| *** Agatha <Agatha!~agatha@user/agatha> has quit IRC (*.net *.split) | 03:48 | |
| *** cods <cods!~fred@82-65-232-44.subs.proxad.net> has joined #bzflag | 03:48 | |
| *** Agatha <Agatha!~agatha@50.38.40.200> has joined #bzflag | 03:48 | |
| *** flash[m] <flash[m]!~flashgnur@2001:470:69fc:105::e302> has joined #bzflag | 03:52 | |
| *** FastLizard4 is back | 04:02 | |
| *** FastLizard4 is now away: AWAY from keyboard | 04:09 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 06:15 | |
| BZNotify | bzflag: devindelong commented on pull request #311 "add missing bzfsAPI function bz_getPlayerCurrentState()" (https://github.com/BZFlag-Dev/bzflag/pull/311#issuecomment-1283561554): The reason I was interested in this function was to avoid dynamic m... | 07:34 |
|---|---|---|
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 09:39 | |
| *** Harlin <Harlin!~DonQixote@75-163-132-93.clsp.qwest.net> has joined #bzflag | 13:02 | |
| *** Harlin <Harlin!~DonQixote@75-163-132-93.clsp.qwest.net> has quit IRC (Quit: Leaving) | 13:11 | |
| *** FastLizard4 is back | 13:11 | |
| *** FastLizard4 is now away: AWAY from keyboard | 13:34 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 13:38 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 13:52 | |
| *** the_map <the_map!~the_map@user/the-map/x-5158391> has quit IRC (Quit: *.banana *.split) | 16:38 | |
| *** the_map <the_map!~the_map@user/the-map/x-5158391> has joined #bzflag | 16:40 | |
| *** Agatha_ <Agatha_!~agatha@user/agatha> has joined #bzflag | 17:42 | |
| *** Agatha <Agatha!~agatha@user/agatha> has quit IRC (Ping timeout: 252 seconds) | 17:46 | |
| *** FastLizard4 is back | 18:23 | |
| *** Agatha_ is now known as Agatha | 18:32 | |
| *** FastLizard4 is now away: AWAY from keyboard | 18:34 | |
| Agatha | Aight I'm sick of the 'MG fires when you pick it up, accidentally ricoing and killing you' bug. So are other people since at least 2008; e.g.: | 21:08 |
| Agatha | https://forums.bzflag.org/viewtopic.php?p=169760 | 21:08 |
| Agatha | https://forums.bzflag.org/viewtopic.php?p=122502 | 21:08 |
| Agatha | https://forums.bzflag.org/viewtopic.php?p=133091 | 21:08 |
| Agatha | @SpringTank and I have just finished sandboxing this bug. It seems completely dependent on the scrollwheel being involved. Using my (sortof probably typical?) config, the *easiest* way to reproduce it is to have MG and then scroll down, which turns the MG on forever. The way this occurs *in practice* is you scroll down *without* MG to fire a spread shot, then pick up MG, which then starts firing unexpectedly. | 21:08 |
| Agatha | The input code ("playing.cxx") is a tangled mess, but ultimately simple enough to see why this happens (even if the rest of the file is so enormous it literally lags out my text editor). Firing is handled through `doKeyCommon(...)`, which sets the value of variable `fireButton` to the pressed or unpressed state. E.g. 'click' sets to `true`, 'unclick' sets to `false`. | 21:08 |
| Agatha | The scroll wheel scrolling (in either direction) is treated by this code as 'pressed'. There is *no associated unpress event*. Thus: | 21:08 |
| Agatha | - If you have MG, it fires permanently (via `playingLoop()` -> `LocalPlayer::fireShot()`). | 21:08 |
| Agatha | - If you don't, it fires one shot for each event (via `doEvent(...)` -> `doKey(...)` -> `doKeyCommon(...)` -> (slightly gratuitous function pointer dispatch) -> `cmdFire(...)` -> `LocalPlayer::fireShot()`). The fire variable `fireButton` remains `true`, yet because you aren't actually pressing anything, no events are issued and you don't continue firing. When you do fire again, the unpress/unclick cancels `fireButton` as usual. | 21:08 |
| Agatha | Basically, if you use the scroll wheel, it's like someone is holding down the click/fire key afterward. You can't observe a difference with normal shots, but with MG it means the bullets fire forever—even if you pick up MG *after* you used the scroll wheel, and in fact even if you pick up MG *after death*. | 21:08 |
| Agatha | The fundamental problem here IMO is the treatment of the scroll events. They should not produce keydown events—after all, it's not a key and it's not going down! Scrolling is an instantaneous and singular event; it's a different thing. Thus, the 'right' way to fix this is adding a new type to `BzfEvent` and adjusting the creation of the events, as well as the mentioned code locations, accordingly. | 21:08 |
| spldart | WT.. | 21:09 |
| SpringTank | i agree | 21:11 |
| blast007 | the reason why it happens has been known for a long time, but nobody has cared enough to fix it | 21:11 |
| SpringTank | lmao | 21:13 |
| SpringTank | sooooo | 21:13 |
| SpringTank | why not just make an "unclick" even happen as soon as you are out of shots? | 21:13 |
| SpringTank | wouldn't that be a simple fix? | 21:13 |
| blast007 | or make the wheel trigger both a press *and* release | 21:14 |
| SpringTank | yes | 21:14 |
| blast007 | the source of the problem might be SDL not sending a release event for the button | 21:14 |
| blast007 | so we'd have to special case it for the wheel | 21:14 |
| SpringTank | or, make a simulated unclick event once all shots have been fired. I don't think that would effect regular shots in a negative way | 21:15 |
| SpringTank | and also do the same when the MG flag is picked up | 21:16 |
| SpringTank | i could see how that would turn into spaghetty code though | 21:16 |
| blast007 | it shouldn't be tied to the shots being fired | 21:21 |
| Agatha | I think it's more like, many people cared about it, but it was not a development priority. | 21:33 |
| Agatha | The cause has been roughly known, but not, I think, to this precision before. In particular, reference 1 has workarounds which don't work (at least anymore) or break things further. | 21:33 |
| Agatha | Also in particular, the cause here is not SDL not sending a release event for the button; the problem is that *we* aren't sending a release event for the button . . . *ever*. (Though it is possible to trigger a related bug in this manner, with SDL the culprit, if the window loses focus while you're e.g. clicking or something.) | 21:33 |
| Agatha | Also, yes, making the wheel trigger a press and release event would workaround the issue just as well, but is not as correct IMO as making a separate event type for this separate type of event—and the last thing the code needs is more hacks. | 21:33 |
| blast007 | joystick buttons/hats and mouse buttons/wheels are all treated as "key events" | 22:20 |
| blast007 | changing mouse wheel to be a different kind of event would mean you can't bind it in the key mapping menu | 22:21 |
| blast007 | so, I guess that would solve the problem :) | 22:21 |
| Agatha | :/ if refactoring is too difficult, sending a double event keydown+keyup for each scrollwheel tick event is likely significantly easier, while still being better than nothing. | 22:54 |
| blast007 | that's also a bit of a pain, since we currently only support sending a single BZ event for an SDL event | 23:17 |
| blast007 | and the SDL event for mousewheel isn't treated like a button, so there's only ever one event | 23:17 |
| flash[m] | is "keypress" an event, or are "key down"/"key up" two related events? | 23:39 |
| blast007 | there is a KeyUp and a KeyDown event | 23:41 |
| flash[m] | so there is an impedance mismatch between scroll wheel (and joystick button/hat) and key presses | 23:42 |
| flash[m] | Because MG tries to live in the space between KeyDown and KeyUp, it exposes this mismatch | 23:43 |
| blast007 | yeah, because SDL triggers an pressed/released event for keys and buttons, but mouse wheel is just how much the wheel has moved and in what direction | 23:43 |
| flash[m] | without looking at the code, and solely based on Agatha 's analysis, is there space to differentiate between `doKey()` and `doKeyCommon()` so that `LocalPlayer::fireShot()` can tell the difference between a key held down and a non-pressed key? | 23:47 |
| Agatha | `fireShot` can be invoked from other places, such as from bots or maybe even the network | 23:51 |
| flash[m] | does "fire key pressed" have meaning in that case? Is the state held in the wrong place? | 23:52 |
| flash[m] | (of course it it; that's one of the major flaws of playing.cc) | 23:52 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!