| 00:00.37 | blast007 | iirc, the mouse wheel only triggers a 'key down' event, but never a 'key up' event, which is why it makes MG keep going |
| 00:01.09 | blast007 | BulletCatcher: and your case could be a missed key up event |
| 00:03.20 | blast007 | I imagine there's various cases where certain events could be lost |
| 00:15.36 | alpha1-2 | other cause can be lag issues. When I had high lags, sometimes I got killed by my own GMs for example, IIRC |
| 00:16.15 | alpha1-2 | if I was walking ahead when I shot |
| 00:18.22 | alpha1-2 | it is like when you walk ahead on a [highway rail] and you shoot (like those on Urban Jungle) |
| 00:23.05 | blast007 | that's not lag, that's low framerate |
| 00:23.17 | blast007 | or moving very fast and getting in front of your own shot |
| 00:34.03 | the_map | at apoc if I shoot through the teleporters while exiting I usually catch my own (normal) bullet |
| 00:34.56 | blast007 | that's because it creates a new shot segment, and only the first shot segment can't kill you |
| 00:35.20 | the_map | what? |
| 00:35.47 | the_map | I'm talking about normal bullets, while not holding any flags |
| 00:36.03 | blast007 | right, that's what I'm talking about |
| 00:36.45 | blast007 | normal shots are calculated into segment. If they rico or go through a teleporter, that creates a new segment. |
| 00:37.08 | blast007 | you're only immune to dying to the first segment of your own shots |
| 00:38.56 | blast007 | hmm, or maybe that only applies to laser |
| 00:39.46 | blast007 | so you can still get shot by the first segment of non-laser segmented shots if you run into them |
| 00:40.20 | blast007 | and teleporting probably does some wonky things with positioning |
| 00:40.30 | the_map | no kidding :) |
| 00:40.47 | the_map | that's sorta the idea |
| 01:08.35 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 01:09.13 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 01:45.51 | blast007 | Working on renaming plugins/*/README.txt to plugins/*/<plugin name>.txt to make it easy to include the plugin readmes along with binaries, and renaming the help pages included with some plugins (such as keepaway) to have a .help.txt ending. Any objections/suggestions? |
| 01:56.44 | the_map | if you're on linux (maybe mac), a for loop and use of the `rename` function? |
| 01:57.30 | the_map | if you can figure out the rename function; it's never worked well for me |
| 01:58.07 | blast007 | I don't mean suggestions about how to rename them :P |
| 01:58.46 | blast007 | I mean suggestions regarding naming scheme |
| 01:59.19 | the_map | so, suggestions on how they should be named, not how to name them? :) |
| 01:59.38 | the_map | --> how to name them, not how to name them |
| 02:01.02 | the_map | ins't English great? |
| 02:01.21 | the_map | it's the opposite of logic |
| 02:01.35 | the_map | a â a sometimes |
| 02:02.12 | BulletCatcher | README.<plugin name>.txt would work. |
| 02:23.30 | blast007 | BulletCatcher: what about help files? (ones used with -helpmsg) |
| 02:23.49 | blast007 | and should plugin changelogs just be part of the readme files? |
| 02:37.10 | BulletCatcher | I don't see any value in maintaining separate version numbers for the bundled plugins. |
| 02:37.35 | BulletCatcher | I think we can just delete the CHANGELOG.txt files and remove version numbers from the corresponding README.txt files. |
| 02:49.16 | *** join/#bzflag Indy_ (4a4d2546@gateway/web/freenode/ip.74.77.37.70) |
| 02:49.24 | Indy_ | hello chat |
| 02:53.33 | BulletCatcher | Most of the plugins/*/[a-z]*.txt files exceed the 10-line limit for -helpmsg. |
| 02:53.38 | BulletCatcher | If that is their intended use then they need editing, and renaming them to help_<plugin name>_<mumble>.txt would help convey that intent. |
| 02:53.40 | BulletCatcher | Otherwise, it would be better to move the helpful info from those files into the corresponding README.txt files. |
| 07:56.24 | *** part/#bzflag bizarrefish (~lee@86.ip-5-196-225.eu) |
| 08:01.58 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 09:29.06 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 09:39.27 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 10:23.50 | Constitution | http://fairserve.net/~josh/bzflag/embedded/ios1.png |
| 10:27.27 | blast007 | "Siri, destroy my enemies" |
| 10:34.41 | Constitution | it doesn't respond at all, much less support mobile-specific features like that, but it does load :) |
| 10:35.14 | Constitution | I'm thinking SDL 2 on iOS might not support physical keyboards :( |
| 10:35.29 | Constitution | was hoping for a new benchmark |
| 10:38.52 | blast007 | "now I get *double* digit FPS!" |
| 10:53.35 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 11:10.45 | blast007 | Constitution: for a test, you could just modify it to join a specific server in observer automatically |
| 14:33.50 | Constitution | for some reason I had a lot of trouble getting that to work |
| 14:35.54 | Constitution | tried modifying argv, and got stuck with a bunch of unused variable warnings which became errors, and the command line arguments parser seems very finicky |
| 14:37.20 | Constitution | I wonder if Xcode could specify runtime arguments though... hmmm |
| 14:40.21 | blast007 | should just have to initialize three startupInfo variables somewhere: https://github.com/BZFlag-Dev/bzflag/blob/2.4/src/bzflag/playing.cxx#L7343 |
| 17:56.51 | *** join/#bzflag dngor (~abuse@p3m/dngor) |
| 22:04.18 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 23:14.33 | Delusional | my 2cents - server and port are also in config.cfg, possible conflict? |
| 23:37.04 | blast007 | Delusional: conflict with what? setting the startupInfo variables? |
| 23:42.22 | Constitution | it looks like Xcode lets you specify command-line arguments... at least in the simulator... have to see it lets you do it when testing on a real device |
