| 02:06.04 | *** join/#bzflag routeveg (~lee@51.195.136.197) |
| 02:06.07 | routeveg | Hi all |
| 02:06.34 | routeveg | Question from a long-time lurker; did anything happen with the bzflag 2.99 branch? |
| 02:06.43 | routeveg | Last I heard it was abandoned because stability probs |
| 02:10.47 | blast007 | 2.4 was released after we abandoned 2.99. It was based on 2.0 and backported some of the lower risk stuff from 2.99, reworked some other 2.99 features, and had some new features. |
| 02:16.49 | routeveg | Ah k, so 2.4 has just been chugging along since then |
| 02:24.26 | blast007 | yup. We're close to a 2.4.22 release and that *might* be the last 2.4 release. |
| 02:25.13 | JeffM[m] | If 2020 wonât ever end, nether will 2.4.x |
| 02:25.37 | blast007 | :) |
| 02:28.52 | allejo | we said there'd be a last 2.4.x release like at least 5 releases back :p |
| 02:30.55 | blast007 | 2.4.24 "This time we mean it, maybe" |
| 02:33.44 | Zehra | Why not make it a living standard, like HTML5? (oO) 2.4.x "Releases are a thing of the past". XD |
| 02:34.29 | JeffM[m] | Because then you can never fix the bugs in the protocol |
| 02:35.53 | Zehra | They're features. :p |
| 02:36.36 | JeffM[m] | Then give up on all that Api stuff you want |
| 02:37.34 | spldart | heh @ 'features' X) |
| 02:40.11 | Zehra | well, hopefully nobody takes the idea of a live release seriously. ;) |
| 02:54.01 | blast007 | I've been working on an extension for the forum that would an HTTP API, starting with the ability to register accounts and validate a login (username/password). The intent is to then make an account management page so we can have registration on a custom page that blends with our site, and also in-game registration. |
| 03:03.40 | routeveg | This 'last 2.4.x release for realz srs' is giving me Brexit vibes :P |
| 03:04.12 | blast007 | why? |
| 03:04.33 | routeveg | "last deadline srs for realz" has been quite a theme so far |
| 03:04.56 | blast007 | I do want to start putting more focus on 2.6 |
| 03:05.24 | routeveg | eg, last night the UK PM and the EU person met - there was a deadline for Sunday to know if they are going to stop negotiating or keep negotiating.... :P |
| 03:05.46 | routeveg | They chose to keep negotiating. |
| 03:05.56 | routeveg | Anywho, don't wanna drag any more OT stuff in here |
| 03:06.01 | blast007 | :) |
| 03:07.01 | routeveg | I remember there was some neat server side scripting stuff, including a lua-powered turret, in 2.99. |
| 03:07.08 | routeveg | Is that pencilled in for 2.6? |
| 03:09.36 | blast007 | probably not |
| 03:11.00 | routeveg | It's quite likely i'll have some spare time in the new year to do contributing and stuff. If there's some kind of priority list of stuff that'd be cool to see. I checked the GH bug tracker and it looks like there really aren't that many bugs open |
| 03:11.31 | blast007 | https://github.com/BZFlag-Dev/bzflag/projects/2 |
| 03:12.17 | blast007 | also intending to support IPv6, which also needs changes to the authentication system (since currently we rely on restricting an authentication token to an IP address) |
| 03:14.17 | blast007 | also another list of possible features/changes for 2.6: https://wiki.bzflag.org/DevelopmentPlans/2.6.0 |
| 03:14.59 | blast007 | and there has been some work on migrating to a newer version of OpenGL |
| 03:15.16 | blast007 | 2.4 still currently targets OpenGL 1.4 or 1.5 |
| 03:25.48 | routeveg | Oh neat; thanks for all the info. Looks like there's a bit to do |
| 03:31.17 | *** mode/#bzflag [-v short_circuit] by ChanServ |
| 03:56.44 | blast007 | to be clear, there's not (yet) any formal plan for 2.6, just some ideas |
| 04:01.23 | allejo | in our defense, there's no formal plan for 2.4 releases, either. just some ideas |
| 04:06.35 | blast007 | there was for 2.4.0 |
| 04:24.48 | routeveg | Serious question - is there a test suite? |
| 04:25.03 | routeveg | Been a while since I poked around and I can't remember |
| 04:25.35 | blast007 | nope |
| 04:28.37 | blast007 | the main things that I'm planning to work on for 2.6 is IPv6 support and some UI improvements |
| 04:28.42 | routeveg | Righto; I guess it might not be trivial to usefully system-test an app like this |
| 04:29.31 | blast007 | IPv6 support is a reasonably involved change since it also touches on the ban system and ban commands, and we have a lot of code all over the place that in some way makes uses of IP addresses |
| 04:29.57 | blast007 | also, banning an IPv6 address via text entry is a bit.. "bleh" :) |
| 04:30.36 | blast007 | so a better UI could make it more clicky |
| 04:31.32 | blast007 | and yeah, tests would probably be challenging to add |
| 04:31.33 | routeveg | mhm, yes. Perhaps uniquely assign a dictionary word to every IPv6 address you see. So you would ban "sausage" or "elephant" |
| 04:31.56 | blast007 | we can ban by name, but that currently only works if the player is still connected |
| 04:37.16 | routeveg | I just mean as a shorthand to be used by server admins. Circular buffer of pairs: (IPv6 addr, name) , in order of connections. |
| 06:50.31 | *** join/#bzflag Agatha (~agatha@2601:681:527f:e8f0:bd5d:57ae:d6e9:fa5f) |
| 07:27.15 | Agatha | Vague sort of bug report: building dependencies fails on Windows if there is a space in the path to the directory. |
| 08:19.41 | *** join/#bzflag infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net) |
| 08:19.41 | *** topic/#bzflag is BZFlag Support and Development || Latest version: 2.4.20 || https://www.bzflag.org || https://www.bzflag.org/help/ || https://www.openhub.net/p/bzflag || https://logs.bzexcess.com/freenode/%23bzflag/ || New release! https://forums.bzflag.org/viewtopic.php?f=62&t=20395 |
| 08:19.41 | *** mode/#bzflag [+v infobot] by ChanServ |
| 08:25.31 | *** join/#bzflag ashvala (~quassel@unaffiliated/ashvala) |
| 10:30.13 | *** join/#bzflag bier (~bier@helixnetworks.de) |
| 11:20.22 | blast007 | Agatha: I seem to recall the issue was actually in one of the dependencies, not in our build script |
| 12:43.06 | *** join/#bzflag joes (~joes@ip5f5ac84e.dynamic.kabel-deutschland.de) |
| 13:10.33 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 13:10.33 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 13:27.10 | *** join/#bzflag fanta1 (~fanta1@p200300f76f02c100017180df77d34422.dip0.t-ipconnect.de) |
| 13:40.20 | *** join/#bzflag _I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 13:41.03 | *** join/#bzflag bier (~bier@helixnetworks.de) |
| 15:20.39 | *** join/#bzflag Sgeo (~Sgeo@ool-18b98aa4.dyn.optonline.net) |
| 15:54.12 | Agatha | Possibly. In any case, the build process for the dependencies seems very fragile. Another issue was that the Windows SDK version is hardcoded for some dependencies as a command-line option. |
| 15:55.19 | blast007 | yup |
| 15:56.47 | Agatha | Another thing: for the main project, the debugged bzflag.exe executable is the direct output of the build, instead of the post-build-step copy. This means that the debugged version can't find DLLs or data. I think the debugged executable should point to the copied "final" output executable. |
| 15:58.08 | blast007 | the debug target is stored in the user settings, not in the normal project files |
| 15:59.05 | blast007 | that is covered in README.WINDOWS |
| 16:00.18 | blast007 | regarding the dependencies, some of them may work better if built with cmake, but not all of them fully supported cmake (or at least, didn't support the build options we needed) |
| 16:04.22 | Agatha | Yes; I saw the readme. The point is, regarding the statement "If you wish to debug the program, you must set the debug executable path and working directory inside VC to use this executable and path." that there doesn't seem to be any reason to require this? Why not just point the debugger to the application that can actually be debugged in the first place? |
| 16:07.18 | blast007 | because we don't ship user settings with the repo |
| 16:08.51 | blast007 | the debug target, just like the startup project, is not stored in the project files. it is stored in the user settings file. |
| 16:14.32 | Agatha | Hmmm you appear to be right. I guess it makes sense why it's this way, but it's still confusing, you ask me :/ |
| 16:14.32 | Agatha | And finally: after I finally got the thing building, I made a few GUI improvements to help me get precise information in an effort to catalogue Two Tanks. Notice the finer tick marks and the tick marks on the interior of the mousebox here: https://postimg.cc/hh0VcCGr |
| 16:14.32 | Agatha | I feel like these GUI changes are more useful than just my experiment, and for fairness everyone should have access to them. I can't see a reason not to add it, perhaps as an optional feature to enable. What do we think about that? |
| 16:18.51 | blast007 | what is the purpose of the tick marks inside the mousebox? |
| 16:30.29 | Agatha | These divide the position of no movement and the position of full movement into 5% increments. This is useful primarily for calibrated jumps (e.g. on various obstacle courses you have to jump "40%", say; this allows precision in this, not a guess). |
| 16:36.45 | blast007 | I believe you reach full reverse speed when you're halfway between the inner box and the bottom of the mousebox |
| 17:20.45 | Agatha | Yes I think you're right. I think the clearest way to handle is just to drop those tick marks below halfway; I have done this. |
| 17:50.41 | *** join/#bzflag DTRemenak (~DTRemenak@2603-8001-3700-003f-54c5-c88c-84ff-7b1c.res6.spectrum.com) |
| 17:50.41 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 17:50.41 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 18:17.27 | *** join/#bzflag joes (~joes@95.90.200.78) |
| 23:28.31 | *** join/#bzflag Zehra (~Keiki_Han@unaffiliated/zehra) |
| 23:54.21 | *** join/#bzflag Agatha (~agatha@2601:681:527f:e8f0:bd5d:57ae:d6e9:fa5f) |