| 00:02.03 | Delusional | so there are signifigant differences between what any two clients see. |
| 00:02.45 | blast007 | there is |
| 00:03.00 | blast007 | 32-bit linux clients tend to have more issues than 64-bit linux clients |
| 00:03.14 | blast007 | though I don't see the same issues on 32-bit Windows builds |
| 00:07.08 | blast007 | (specifically referring to collision detection issues, like getting stuck in teleporters) |
| 00:07.32 | Delusional | I was eventually able to place my bases directly on my mesh, where it worked for all players, but i have no idea what is the secret sauce that made it work. |
| 00:07.50 | blast007 | nice even numbers? |
| 00:07.54 | Delusional | luck, i figure |
| 00:09.05 | Delusional | i think the base is 0.0001 higher than the mesh, but there were times that that didnât work, too |
| 00:09.36 | RoscoePColtrane | some numbers are exactly representable in base-2 |
| 00:09.41 | RoscoePColtrane | others are not |
| 00:09.55 | RoscoePColtrane | the first kind would be "magic" |
| 00:11.01 | BulletCatcher | 32-bit Linux clients used to (and probably still do) get stuck in teleporters that are far from the map center (e.g., on Two Tanks). I was able to narrow it to about 100 lines of code that suffered from the problem only when compiler optimization was used. I blame gcc, but was unable isolate it enough to lead to a fix. |
| 00:12.57 | BulletCatcher | Choosing coordinates and sizes that can be represented exactly by single-precision floats ought to prevent those sticky problems. |
| 00:14.19 | Delusional | can you give me examples? |
| 00:16.27 | Delusional | and is that for a mesh only? will it work for an arc that uses pi? |
| 00:20.10 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:20.10 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 00:20.10 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:20.41 | Delusional | whatâs killing me right now is⦠when I make a flat arc, It uses pi to compute only the XY dimensions. I would only need these magic numbers for the Z |
| 00:21.00 | Delusional | the Z is the one that matters |
| 01:16.39 | BulletCatcher | What seems to work is to ensure that the fractional part of a number can be multiplied by a small power of 2 to get an integer. For example, 0.125 is magic because when multiplied by 8 it equals 1. |
| 01:19.36 | BulletCatcher | BZFlag floats are https://en.wikipedia.org/wiki/Single-precision_floating-point_format that have 23 bits (just over 7 decimial digits) of precision, so even a number like 12345.125 cannot be represented exactly. |
| 02:25.50 | *** join/#bzflag galileo_ (~QUJAAAAAA@d216-108-171-73.nt.northwestel.net) |
| 02:43.57 | JeffM | Doubles for everyone! |
| 02:48.01 | BulletCatcher | Changing most of the calculations (not sure about the protocol) to use doubles would be a nice subproject for 2.6. |
| 02:49.13 | BulletCatcher | I suspect it would reduce or eliminate some of the oddities that accompany very high frame rates. |
| 02:49.51 | RoscoePColtrane | 6.7 significant digits is NOT very many |
| 02:50.54 | Zehra | Just so I'm not confused, 2.5x is the future 2.6? (I'm assuming it is.) |
| 02:51.04 | RoscoePColtrane | yes |
| 02:51.11 | RoscoePColtrane | odd numbers are development |
| 02:51.16 | RoscoePColtrane | even are releases |
| 02:59.41 | BulletCatcher | Changing from float to double will have subtle effects on gameplay because calculations will produce different results, so we don't want to make that change in version 2.4. |
| 03:01.49 | macsforme | not that the results are consistent now, across platforms and compilers :P |
| 03:02.16 | RoscoePColtrane | no, we must not change |
| 03:02.24 | RoscoePColtrane | change is bad |
| 03:02.38 | allejo | i'm allergic to change |
| 03:09.09 | Zehra | Quick question, would a modification which highlights ST while holding seer be accepted? |
| 03:11.34 | Zehra | thinks it would be a nice feature for 2.5x |
| 03:17.01 | JeffM | there are floating point libs that ensure the same math on all platforms |
| 03:17.04 | JeffM | at the cost of speed. |
| 03:24.20 | blast007 | https://gafferongames.com/post/floating_point_determinism/ |
| 03:25.10 | BulletCatcher | I don't see a good reason to change the balance of power between SE and ST, Zehra. |
| 03:25.40 | JeffM | is anyone complaining about it? or is it a change just for change sake? |
| 03:27.58 | allejo | the issue at hand is tanks getting stuck when driving between objects of slightly different heights |
| 03:28.18 | JeffM | fixed point for everyone! |
| 03:28.44 | allejo | no decimals for anyone! |
| 03:29.27 | Zehra | BulletCatcher, it was based on an idea posted on forums previously and sort of trying to add a hunting enhancement to the client. (basically an autohunt feature.) |
| 03:29.49 | JeffM | wasn't that you posting it? |
| 03:30.14 | Zehra | There was two topics, one which was old and another which I started. |
| 03:31.01 | Zehra | https://forums.bzflag.org/viewtopic.php?f=3&t=12408 |
| 03:31.08 | JeffM | so nothing recent by anyone else |
| 03:31.15 | JeffM | what problem does it solve? |
| 03:32.23 | Zehra | It doesn't solve anything, but I thought it would be an enhancement or something. |
| 03:32.44 | JeffM | sure |
| 03:33.39 | JeffM | but they should actualy enaance things, be very careful with things that affect flag balance. people are very opinionated because it changes gamepla |
| 03:33.59 | JeffM | a lot of stuff is the way it is for reasons of balance. |
| 03:35.54 | JeffM | if there was a problem with people finding hidden players, that could be a reason to enhance the flag, but it doesn't sound like there is that problem. and it risks shifting balance in a way that could be unfair |
| 03:37.15 | JeffM | I would like to see your code though |
| 03:40.02 | Zehra | https://pastebin.com/vJzTdEJd |
| 03:40.30 | Zehra | I know, it's really badly implemented. :p |
| 03:40.48 | JeffM | why are those static |
| 03:41.21 | JeffM | oh so you don't use a global? |
| 03:42.28 | JeffM | it could be made simpler |
| 03:43.09 | JeffM | but it's not horrible |
| 03:43.23 | RoscoePColtrane | not horrible |
| 03:43.37 | RoscoePColtrane | do you guys know about std::chronos? |
| 03:43.52 | JeffM | bzflag is older then that ;) |
| 03:43.58 | RoscoePColtrane | yes, much older |
| 03:44.07 | RoscoePColtrane | and we are frozen in the past |
| 03:44.17 | JeffM | a lot of stuff could and should be updated |
| 03:44.30 | RoscoePColtrane | just a question, not a suggestion |
| 03:44.54 | JeffM | we have talked about updating more stuff to std from newer versions of C++ |
| 03:45.37 | JeffM | prefers System.Diagnostics.Stopwatch |
| 03:52.40 | RoscoePColtrane | one of the best parts of the new standard is std::ratio |
| 03:53.07 | RoscoePColtrane | underappreciated |
| 03:53.38 | Delusional | irrrationally |
| 04:00.14 | JeffM | bzflag is crap if it doesn't use atomic clock resolutions |
| 05:10.47 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-djwugsncoiwrhewu) |
| 07:08.31 | RoscoePColtrane | so we agree |
| 12:51.51 | *** join/#bzflag galileo_ (~QUJAAAAAA@d216-108-171-73.nt.northwestel.net) |
| 14:50.46 | JeffM | RoscoePColtrane: yes, hence System.Diagnostics.Stopwatch |
| 15:10.25 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-vhjtuawcvotximgr) |
| 15:33.50 | Delusional | floating point bug happens when placing bases OR Teleporters on a mesh or arc. Forgot about telporters. |
| 15:42.25 | Delusional | and now I know why telporter thickness of 0.125. seems to work well. Looking at the bzw manpage, it gives an example size of âsize 5.06 4.48 20.16 â which does not work at all. |
| 15:42.54 | Delusional | so iâve already been using the magic number without realizing it. |
| 15:45.58 | Delusional | bzw manpage also gives 1.12 as the size of the tele border, that might be changed to 1.125. |
| 15:53.02 | Delusional | Tele borders have always seemed sloppy to me, easy to get stuck on them. Especially when touching the border and turning. As an alternative I use âborder 0â and put 8-division arcs in place of the side posts. It makes movement around the posts much smoother. |
| 15:54.29 | Delusional | maybe i could have just use 1.125 as border thickness |
| 16:31.18 | *** join/#bzflag zuii (~cauchy@BC9C5B1F.mobile.pool.telekom.hu) |
| 17:18.18 | JeffM | commonized collision code would probably help those kinds of interactions. |
| 17:28.08 | macsforme | after I read some article online (I think from that same site blast007 linked to above, but a different article), I was trying to brainstorm a way to have the server do the authoritative collision detection and have clients re-sync themselves to that on an ongoing basis |
| 17:30.14 | macsforme | could be something like 1) client sends input state to the server, then keeps doing local simulation, 2) server receives input state and steps the simulation, and sends an acknowledgement to the client with it's actual position at the end of that update |
| 17:31.39 | macsforme | then 3) the client receives that acknowledgement, goes rewinds the simulation to that moment, and replays all the other local simulation from that point, and 4) the whole thing repeats |
| 17:32.55 | macsforme | so even if the local simulation is just a tad off, it's constantly getting re-synced to the server's authoritative state |
| 17:37.31 | macsforme | that was a little hard to explain verbally... hopefully it makes sense |
| 17:38.26 | JeffM | it makes sense |
| 18:25.12 | *** join/#bzflag zuii (~cauchy@BC9C5B1F.mobile.pool.telekom.hu) |
| 19:13.57 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 19:43.22 | blast007 | macsforme: dunno if it was covered in the article you read, but the client can send all the input updates that the server has yet to acknowledge receipt of |
| 19:45.24 | blast007 | so the client would have a buffer of input events (ideally just slightly more than the round trip lag time) that it could use to roll back and recalculate the client state if the server provides differing state |
| 22:36.28 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 23:22.13 | macsforme | yes, that's the article I read... so there would be a "rolling buffer" of pending updates from the server, that the simulation would be replayed on top of once acknowledged (and the acknowledgement could provide the authoritative state) |
| 23:24.27 | macsforme | and I don't think our floating point issues between clients would be as much of a problem, since the server would correct them within the lag roundtrip time |
| 23:25.47 | blast007 | we'd still want to fix the floating point issues as that could still cause jankyness |
| 23:26.21 | blast007 | it would self-correct, but you'd still have instances of your tank getting stuck for a split second |
| 23:26.59 | blast007 | (or, if you were running the client on 32-bit linux, then maybe *all* tanks would get stuck in teleporters or when traveling between mesh and non-mesh objects) |