| 00:20.01 | *** join/#bzflag allejo (~allejo@unaffiliated/allejo) |
| 00:20.01 | *** join/#bzflag mdskpr (~quassel@li59-174.members.linode.com) |
| 02:33.46 | apeman | https://github.com/BZFlag-Dev/bzflag-import-3/blob/v2_4_x/src/bzfs/GameKeeper.cxx#L395 is annoying |
| 02:35.33 | apeman | it inconveniently filters out what one believes are valid shots in two scenarios: explodeTime is low and the player respawns and shoots, and when a player shoots very very shortly after reloading |
| 02:36.41 | apeman | personally i remove it for my servers, though not sure it would be accepted into the code base |
| 02:38.08 | apeman | so the second case where it removes a shot is because the client believes he has reloaded and therefore shoots, but the server's clock is not the same |
| 02:40.12 | apeman | a real example is client tries to fire but server says he has to wait 0.001759 s. Client wasted a bullet that no one can see. |
| 02:41.00 | *** join/#bzflag spldart (~james@c-76-30-94-74.hsd1.tx.comcast.net) |
| 02:41.00 | *** join/#bzflag spldart (~james@bzflag/contributor/spldart) |
| 02:41.00 | *** mode/#bzflag [+v spldart] by ChanServ |
| 02:55.57 | JeffM_ | apeman, ohh yeah that stuff is wonkey |
| 02:56.11 | JeffM_ | we've writen up how we'd like to see shots redone |
| 02:56.33 | JeffM_ | let the server do more of it and tell the client more info about how many shots it has |
| 04:08.26 | *** join/#bzflag apeman (~Victor@222-155-154-108.jetstream.xtra.co.nz) |
| 04:30.35 | *** join/#bzflag JeffM_ (~JeffM@cpe-23-241-222-73.socal.res.rr.com) |
| 05:08.46 | allejo | if there's only a host and/or port so it still auto connect? command line parsing that is |
| 05:09.21 | allejo | s/so/should |
| 05:45.09 | BulletCatcher | Yes. "bzflag localhost" should connect directly to localhost:5154. |
| 05:47.21 | allejo | just leave the callsign and password be I'm assuming? |
| 05:48.17 | BulletCatcher | Yes. They will have already been loaded from the config file. |
| 05:49.33 | allejo | alrighty |
| 05:56.29 | *** join/#bzflag apeman (~Victor@222-155-154-108.jetstream.xtra.co.nz) |
| 06:01.16 | Not-002 | [02bzflag-import-3] 07allejo pushed 031 commit to 03v2_4_x [+0/-0/±1] 13https://github.com/BZFlag-Dev/bzflag-import-3/compare/93325d7c6157...9e6a4797a2fd |
| 06:01.17 | Not-002 | [02bzflag-import-3] 07allejo 039e6a479 - Added case when only a destination is given to command line parsing |
| 06:02.18 | allejo | ugh the tabs and spaces are driving me nuts... |
| 06:02.44 | BulletCatcher | What editor do you use? |
| 06:03.17 | apeman | do a `sed` replace on all the files... i dare you :P |
| 06:11.35 | allejo | BulletCatcher, sublime and xcode |
| 06:12.13 | allejo | apeman, I'm kinda tempted :P |
| 06:13.00 | allejo | xcode handls the spaces and tabs fine but sublime doesn't |
| 06:14.54 | BulletCatcher | Consider this a reason to use either vi or Emacs, both of which know how to handle tabs. |
| 06:17.33 | allejo | sublime is just setup to u se sapces that's why since I use spaces in all my projects |
| 06:19.24 | BulletCatcher | As you expand your horizons you'll find that BZFlag isn't the only project that uses tabs. |
| 06:20.13 | allejo | i know it's not |
| 06:20.44 | apeman | emacs doesnt smart-indent for me in python or c++ :\ |
| 06:21.10 | BulletCatcher | It does for me, apeman. |
| 06:22.54 | BulletCatcher | Basically, allejo, I'm trying to (gently) suggest that Sublime may not be the best editor choice for you. |
| 06:23.55 | apeman | the message appearing on allejo's console is "allejo your editor is wrong. WRONG." |
| 06:25.40 | allejo | :( |
| 07:43.12 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 07:43.12 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 07:51.54 | *** join/#bzflag noyb (~noyb@cpe-172-250-108-23.socal.res.rr.com) |
| 08:30.32 | *** join/#bzflag khonkhortisan_ (~kyle@c-50-132-81-139.hsd1.wa.comcast.net) |
| 08:34.31 | *** join/#bzflag EvilJStoker_ (jstoker@unaffiliated/jstoker) |
| 08:35.04 | *** join/#bzflag [dmp] (~dennis@users.d75.net) |
| 08:35.23 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 08:38.16 | *** part/#bzflag apeman (~Victor@222-155-154-108.jetstream.xtra.co.nz) |
| 09:51.20 | *** join/#bzflag brad`_ (~brad@s2.ninja.so) |
| 09:51.37 | *** join/#bzflag mebigfatguy (~dave@128.177.74.185) |
| 11:22.05 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 16:27.47 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 16:27.47 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 16:52.50 | *** join/#bzflag tw1sted (~tw1sted@192.241.163.210) |
| 16:54.05 | *** join/#bzflag mebigfatguy (~dave@128.177.74.185) |
| 16:54.54 | *** join/#bzflag JBdiGriz (~dbw@108-197-33-160.lightspeed.sndgca.sbcglobal.net) |
| 17:39.55 | *** join/#bzflag JeffM_ (~JeffM@12.167.61.62) |
| 18:08.09 | *** join/#bzflag tw1sted (~tw1sted@unaffiliated/tw1sted) |
| 20:48.57 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 20:48.57 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 21:02.57 | *** join/#bzflag Tuxist (~quassel@79.238.206.156) |
| 22:07.11 | *** join/#bzflag apeman (~Victor@222-155-154-108.jetstream.xtra.co.nz) |
| 22:21.32 | apeman | In a non-rico world, im trying to make my autopilot dodge. For sensing bullets i'm relying purely on ShotPath::getVelocity() and getPosition(). Practice has shown that the results are VERY different depending on whether the shooter has 200 ms lag or no lag. |
| 22:21.59 | apeman | is there some need to do a manual update on ShotPath that i have neglected? |
| 22:29.13 | apeman | one thing i am noticing is the shot position teleporting shortly before death. |
| 22:38.47 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 23:40.43 | Chestal | apeman: I am probably missing some context, is this some server-side autopilot? |
| 23:41.01 | JeffM_ | no it's client side autopilot |
| 23:41.12 | JeffM_ | apeman, it's suposed to update the shots every frame |
| 23:41.14 | Chestal | I don't see how opponent's lag could matter at all then |
| 23:41.51 | JeffM_ | it's based off the client state so it the lag is burned into what that client knows |
| 23:42.03 | JeffM_ | apeman, make sure that you are still calling the shot updates |
| 23:42.12 | JeffM_ | that may have been in the guts of the rendering code you removed |
| 23:43.13 | apeman | the shot position does change each frame without me doing anything |
| 23:43.26 | JeffM_ | ok good |
| 23:43.49 | JeffM_ | how many updates per second is it doing? |
| 23:44.12 | apeman | havent checked, but usually hundreds |
| 23:44.20 | JeffM_ | you may want to slow it down |
| 23:44.30 | JeffM_ | the update gets wonkey if the DT gets very small |
| 23:44.37 | JeffM_ | 60 fps is usualy fine |
| 23:48.55 | apeman | wow you were right. I put the fps limit back in and its ok now |
| 23:49.19 | JeffM_ | as the delta for the time gets very small you run into errors in the floating point resolution |
| 23:50.05 | JeffM_ | I thought I had a FPS cap in, but maybe that was only 2.99 |
| 23:50.35 | apeman | there is a 1000 FPS cap for drawing, dont remember if for physics also |
| 23:50.46 | JeffM_ | it's all the same thing |
| 23:50.50 | JeffM_ | we don't have multiple threads |
| 23:50.55 | JeffM_ | and 1000 is way too high |
| 23:51.01 | JeffM_ | it should be like 150 |
| 23:51.24 | apeman | well it wasnt technically an FPS cap, it was just dont draw if less than 1/1000 had passed |
| 23:51.56 | JeffM_ | that's frame skipping |
| 23:52.00 | JeffM_ | so yeah slightly different |
| 23:52.34 | JeffM_ | optimilay you'd have your sim run at a fixed frame rate in it's own thread and then pull off as many drawing frames as you needed per second |
| 23:52.58 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 23:54.10 | apeman | actually how does too fast FPS explain any difference due to lag? |
| 23:54.26 | JeffM_ | exterpolation |
| 23:54.39 | JeffM_ | we only know the last known place |
| 23:54.46 | JeffM_ | so it has to be extrapolated out to where it is now |
| 23:54.56 | JeffM_ | doing that math with a very small delta gets wierd |
| 23:55.06 | JeffM_ | and we get some compounding errors |
| 23:55.17 | JeffM_ | is not happy with any of the sim math |
| 23:55.37 | apeman | its only the ShotPath though, which is deterministic once received |
| 23:55.47 | JeffM_ | ish |
| 23:55.52 | JeffM_ | it's buggy |
| 23:56.02 | apeman | well, the nondeterministic part is when it updates so exactly what values you observe |
| 23:56.24 | JeffM_ | yeah and when the delta gets very small, the resutls don't make sense |
| 23:56.45 | JeffM_ | so you may think that you are multiplying something by 0.000001 but in reality it's 0.0000933 |
| 23:57.03 | JeffM_ | like the computer can't actualy keep an exact represention of 0.1 |
| 23:57.09 | JeffM_ | it's 0.0999999999999 |
| 23:57.29 | JeffM_ | it may not seem like it's off by much but when the delta gets down that low stuff gets wierd |
| 23:57.56 | JeffM_ | I haven't studied it extensivly, just from what I looked into when we were trying to move the shot path stuff to the server |
| 23:58.04 | JeffM_ | and we saw the logic is full of holes |
| 23:59.22 | JeffM_ | I started a rewrite on the server that could be used for both the server and client |