bzflag-dev / bzflag Goto Github PK

There is a desire to allow IP bans to be represented in CIDR format (a.b.c.d/e) so that a specific block of addresses can be easily banned. Currently we only have wildcard support, effectively giving us /8, /16, and /24 CIDR bans, but there are times when you may have to enter several bans to cover a range, or banning a much larger range than necessary may occur.

As of 806942d, there has been the start to CIDR ban support, but it needs additional work to be functional:

• Store and compare CIDR in BanInfo class
• Support saving/loading CIDR syntax bans
• Support adding/removing CIDR syntax bans
• Update IP comparison code to use contains method of BanInfo class
• Add more ban related test cases to ensure proper functionality

Currently there is minimal support for changing team colors on radar and on untextured tanks. It would be nice if there was a menu that would allow setting radar/tank colors, and possibly have some presets. It would also be nice if the tank textures were colored dynamically so that you wouldn't have to alter texture files to change the shade of color.

• Better handling of the BZDB variables for radar and tank colors (making them first class BZDB variables instead of only checking at startup)
• Adding support for observer, hunter, and rabbit teams
• Menu to control radar/tank colors
• Dynamically colored textures
• Selectable camouflage patterns per-team

Reported by Mopar Madness:

I found a bug in the countdown plugin on BZFlag.Allejo.io:5158, not sure if its 2.4.4 related or plugin related. Players who are alive when the countdown ends or gameover is called can be /killed by admins after the game ends even though they are already dead. Attempting to kill them again results in "player is not alive" message. Attempting to kill players already dead at the time of the game ending also results in "player not alive". It affects all 2.4 clients and seems to be either server or plugin related. The server is running build 2.4.3.20150915-DEVEL-linux-gnu.

I haven't looked into this, but I think this is probably related to the fact that clients kill themselves instead of the server killing players (correct me if I'm wrong).

I'm using 2.4.4 RC2, for Mac OSX. On the Clay Hills server, a particular player (not known for cheating) was invisible on main screen for duration of game. Other players were fine. I quit the app, restarted it and signed back, and the same player was still invisible. I also seemed unable to land a bullet on this player. They showed up on the radar fine, and I could see their shots.

I was able to make the problem go away by using 2.4.2 on the same server. When I next launched 2.4.4 RC2 the problem had gone away, but on a subsequent launch it reappeared after a couple minutes of play. Each time, it was the same player who was invisible/unshootable.

I have found out this while playing on Quickshot.

If you grab a PZ flag, then become zoned by driving through a teleport, you can lose the flag by using up your shot limits to become un-zoned at any time you want, without a teleporter.
But if you get un-zoned that way, without going back through a teleporter, then try to pick up a PZ flag again, you get re-zoned without needing to go through a teleporter.

I don't know how this could be fixed, as it's partly a map problem with the shot limit, but the PZ state should be reset when the flag is dropped.

Didn't realize this plugin used custom zones

As a reminder...

One of my low-priority todo items is to replace character arrays with std::string to help ensure that there are no overflows we have overlooked.

• BulletCatcher

Currently we have various third party libraries such as curl, ares, and GLEW within our source repository inside the src/other/ path. This causes a headache for some Linux distributions, such as Debian, who have to remove these embedded code copies and update the build scripts for every new release. Additionally, I am having a difficult time modifying our custom curl project file so that we can use an updated copy of curl. After several discussions in IRC, I believe the opinion is that it would be best to remove these embedded code copies.

Mac OS X only makes use of ares and GLEW at present, while everything else included in src/other/ is already part of the OS X SDK. Windows I can easily make work with external copies of the code. Linux is already generally built with system-installed copies of the libraries.

Tasks to complete:

• Recreate the bzflag-dependencies repository with git submodules and update the build script for Windows
• Remove src/other/
• Update the Visual Studio project files to point to the external headers/libraries via environment variables
• Update the Xcode project to use a system-installed ares and GLEW
• Update the autoconf/automake build system to not try building src/other/ libraries and to have configure error out if system versions of needed libraries are not available

Bad flags should not be dropped when a player pauses

My password contains a semicolon. When I enter it and connect it works well, but when I exit and connect again I notice that the password field is shorter, the semicolon and anything after it is removed.
If I connect I get rejected for wrong password. This also applies to the Callsign field and possibly any string field.

Steps to reproduce:
Start the game. Select Join Game in main menu.
Enter Callsign: 123;123
Enter Password: 123;123
Exit the game.
Start the game again, select Join Game.
Notice Callsign and Password are now "123" instead of "123;123"

Tested with BZFlag client 2.4.2.20140102-MAINT-linux-gnu-SDL (protocol 0221) http://BZFlag.org/

The current master branch crashes on occasion when teams are automatically selected.

Server conf:

# no -autoteam
-mp 0,16,0,16,0,5

Message:

Program received signal SIGFPE, Arithmetic exception.
0x00000000004598e8 in teamSelect (t=t@entry=AutomaticTeam, teams=...) at bzfs.cxx:1756
1756      return teams[rand() % teams.size()].color;

Backtrace:

(gdb) bt
#0  0x00000000004598e8 in teamSelect (t=t@entry=AutomaticTeam, teams=...) at bzfs.cxx:1756
#1  0x0000000000506b6a in autoTeamSelect (t=AutomaticTeam) at bzfs.cxx:1840
#2  AddPlayer (playerIndex=playerIndex@entry=2, playerData=playerData@entry=0x89c080) at bzfs.cxx:2102
#3  0x000000000045d7ad in doStuffOnPlayer (playerData=...) at bzfs.cxx:5278
#4  main (argc=<optimized out>, argv=<optimized out>) at bzfs.cxx:6727

Full backtrace:

#0  0x00000000004598e8 in teamSelect (t=t@entry=AutomaticTeam, teams=...) at bzfs.cxx:1756
No locals.
#1  0x0000000000506b6a in autoTeamSelect (t=AutomaticTeam) at bzfs.cxx:1840
        numplayers = <optimized out>
        i = <optimized out>
        teams = {<std::_Vector_base<TeamSize, std::allocator<TeamSize> >> = {_M_impl = {<std::allocator<TeamSize>> = {<__gnu_cxx::new_allocator<TeamSize>> = {<No data fields>}, <No data fields>}, _M_start = 0x939130, _M_finish = 0x939148, _M_end_of_storage = 0x939148}}, <No data fields>}
        maxTeamSize = 1
        unBalanced = <optimized out>
#2  AddPlayer (playerIndex=playerIndex@entry=2, playerData=playerData@entry=0x89c080) at bzfs.cxx:2102
        allowData = {<bz_EventData> = {_vptr.bz_EventData = 0x5977f0 <vtable for bz_AllowPlayerEventData_V1+16>, version = 1, eventType = bz_eAllowPlayer, eventTime = 1280.5844450031493}, playerID = 2, callsign = {data = 0x939360}, ipAddress = {data = 0x9311d0}, reason = {data = 0x930e00}, allow = true}
        result = <optimized out>
        rejectMsg = "\000\000\000\000\000\000\000\000\033", '\000' <repeats 13 times>, " \000\255gL", '\000' <repeats 21 times>, "\060\026\223", '\000' <repeats 13 times>, "\n\301\211\000\000\000\000\000\200\300\211\000\000\000\000\000\260ʼn\000\000\000\000\000>\331\r\367\377\177\000\000\360\333\377\377\377\177\000\000\n\301\211\000\000\000\000\000\210\300\211", '\000' <repeats 12 times>
        playerIP = {s_addr = 131947103}
        info = {addr = {s_addr = 131947103}, cidr = 32 ' ', banEnd = {seconds = 315360000000, static currentTime = <same as static member of an already seen type>, static tickTime = <same as static member of an already seen type>, static sunExplodeTime = <same as static member of an already seen type>, 
            static sunGenesisTime = <same as static member of an already seen type>, static nullTime = <same as static member of an already seen type>, static startTime = <same as static member of an already seen type>}, bannedBy = {static npos = <optimized out>, 
            _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7de338 <std::string::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4+24> ""}}, reason = {static npos = <optimized out>, 
            _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7de338 <std::string::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4+24> ""}}, fromMaster = false}
        numplayersobs = <optimized out>
        teamIndex = <optimized out>
        message = "\000\000\000\000\000\000\000\000\334\066H\000\000\000\000\000@\337\377\377\377\177\000\000\200\300\211\000\000\000\000\000\300\337\377\377\377\177\000\000`g\321\366\377\177\000\000\070\343}\000\000\000\000\000\v\000\000\000\000\000\000\000`\376\222\000\000\000\000\000\003\000\000\000\000\000\000\000\067\000\000\000\000\000\000\000\340\336\377\377\377\177\000\000\000\000\000\000\000\000\000\000\341\032N\000\000\000\000\000\000\300\211\000\000\000\000\000\310\350\230\000\000\000\000"
        resultEnter = <optimized out>
        playerIsAntiBanned = <optimized out>
        t = <optimized out>
        autoTeamData = {<bz_EventData> = {_vptr.bz_EventData = 0x8, version = 9745680, eventType = bz_eNullEvent, eventTime = 0}, playerID = -154048672, callsign = {data = 0x34}, team = eRogueTeam, handled = false}
        numplayers = <optimized out>
        buf = <optimized out>
        mottoEvent = {<bz_GetPlayerMottoData_V1> = {<bz_EventData> = {_vptr.bz_EventData = 0x140e0, version = -154048672, eventType = 32767, eventTime = 5.1199825252270043e-317}, motto = {data = 0x13a00}}, record = 0x0}
        lines = 0x0
        rejectCode = 0
        idInfo = {idpat = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7de338 <std::string::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4+24> ""}}, banEnd = {seconds = 315360000000, 
            static currentTime = <same as static member of an already seen type>, static tickTime = <same as static member of an already seen type>, static sunExplodeTime = <same as static member of an already seen type>, static sunGenesisTime = <same as static member of an already seen type>, 
            static nullTime = <same as static member of an already seen type>, static startTime = <same as static member of an already seen type>}, bannedBy = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, 
              _M_p = 0x7de338 <std::string::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4+24> ""}}, reason = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, 
              _M_p = 0x7de338 <std::string::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4+24> ""}}, fromMaster = false}
        joinEventData = {<bz_EventData> = {_vptr.bz_EventData = 0x4, version = 0, eventType = bz_eNullEvent, eventTime = 6.953355807370138e-310}, playerID = -157440080, record = 0x98ac20, reason = {data = 0x34}}
#3  0x000000000045d7ad in doStuffOnPlayer (playerData=...) at bzfs.cxx:5278
        eventData = {<bz_EventData> = {_vptr.bz_EventData = 0x597e30 <vtable for bz_ServerAddPlayerData_V1+16>, version = 1, eventType = bz_eServerAddPlayer, eventTime = 1280.5844420031492}, player = 0x89c5b0, allow = true}
        warn = false
        kick = false
        nextPingSeqno = <optimized out>
#4  main (argc=<optimized out>, argv=<optimized out>) at bzfs.cxx:6727
        p = 2
        dropTime = <optimized out>
        timeout = {tv_sec = 0, tv_usec = 0}
        peerItr = <optimized out>
        resetGame = <optimized out>
        read_set = {fds_bits = {0 <repeats 16 times>}}
        write_set = {fds_bits = {0 <repeats 16 times>}}
        tm = {seconds = 1280.5844410031491, static currentTime = <same as static member of an already seen type>, static tickTime = <same as static member of an already seen type>, static sunExplodeTime = <same as static member of an already seen type>, 
          static sunGenesisTime = <same as static member of an already seen type>, static nullTime = <same as static member of an already seen type>, static startTime = <same as static member of an already seen type>}
        pluginMaxWait = <optimized out>
        toKill = {<std::_Vector_base<int, std::allocator<int> >> = {_M_impl = {<std::allocator<int>> = {<__gnu_cxx::new_allocator<int>> = {<No data fields>}, <No data fields>}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>}
        waitTime = 0
        itr = <optimized out>
        cURLmaxFile = <optimized out>
        adLines = 0x0
        tickData = {<bz_EventData> = {_vptr.bz_EventData = 0x584c30 <vtable for bz_EventData+16>, version = 1, eventType = bz_eTickEvent, eventTime = 1280.5843030031476}, <No data fields>}
        nfound = 0
        nextSuperFlagInsertion = {seconds = 0.62012499999999993, static currentTime = <same as static member of an already seen type>, static tickTime = <same as static member of an already seen type>, static sunExplodeTime = <same as static member of an already seen type>, 
          static sunGenesisTime = <same as static member of an already seen type>, static nullTime = <same as static member of an already seen type>, static startTime = <same as static member of an already seen type>}
        flagExp = 0.0693147182
        i = <optimized out>

/cc @macsforme

As we near the release of BZFlag 2.4.4, we should make sure that documentation that is in the repository (in-game help or otherwise) and localization in-game (provided by our data/l10n/ files) are updated.

Documentation:

• Update the contents in src/bzflag/HelpMenu.cxx
• Man pages inside man/
  • bzadmin.6.in
  • bzflag.6.in
  • bzfs.6.in
  • bzw.5.in
• Plugins README.txt files
• Various files
  • AUTHORS
  • ChangeLog
  • PORTING
  • README
  • README.BeOS
  • README.IRIX
  • README.Linux
  • README.MacOSX
  • README.MINGW32
  • README.SDL
  • README.SOLARIS
  • README.WINDOWS
  • README.XMINGW
  • package/win32/README.win32.html

Localization:

• Ensure that the generic language template (bzflag_xx.po) is updated to include any missing strings.
• Ensure that the other language files contain references to all the other strings (commented out if untranslated, unless they are languages based on another language as described in bzflag_xx.po)
• Update any outdated translation entries
  • bzflag_cs_CZ.po
  • bzflag_da.po
  • bzflag_de.po
  • bzflag_en_US_l33t.po
  • bzflag_en_US_redneck.po
  • bzflag_es.po
  • bzflag_fr.po
  • bzflag_it.po
  • bzflag_kg.po
  • bzflag_lt.po
  • bzflag_nl.po
  • bzflag_pt.po
  • bzflag_sv.po
• Add additional localizations?

The countdown timer runs significantly faster on Windows bzfs instances, jumping ahead about 10 seconds every 30 seconds (the interval that it sends out updates to clients). The countdown timer in the Windows client itself runs at the correct rate.

Hello, I made a Russian translation of the (translation made in transliteration)

http://git.altlinux.org/people/ruslandh/packages/?p=bzflag.git;a=summary

Here's the translation file
http://git.altlinux.org/people/ruslandh/packages/?p=bzflag.git;a=blob;f=bzflag_ru_utf8.po;h=b10a3f3a65bc15285bbf4bff0fac4d3acd5996d8;hb=70147de23aa10bb18e637ccb5edc7c5f4fbc2d93

Here you can see how getting transliteration from UTF8
http://git.altlinux.org/people/ruslandh/packages/?p=bzflag.git;a=blob;f=bzflag.spec;h=443b94939682e38c4143f7ae147bfd7b9b1a1c8e;hb=70147de23aa10bb18e637ccb5edc7c5f4fbc2d93

Add the ability to keep track of what flag was dropped by the victim when they were killed.

A bz_PlayerDieEventData_V2 would be required with this new information.

When building the test cases on Debian Jessie (via 'make check'), which has GCC 4.9.2 and either the 3.7.1 release or the bleeding edge git of CppUTest (installed system-wide with 'make install'), the build fails with:

make[1]: Entering directory '/home/user/bzflag/tests'
g++ -DHAVE_CONFIG_H -I. -I../include  -I../src/bzfs  -I../include  -lCppUTest -std=c++0x -MT unittests-tests.o -MD -MP -MF .deps/unittests-tests.Tpo -c -o unittests-tests.o `test -f 'tests.cxx' || echo './'`tests.cxx
mv -f .deps/unittests-tests.Tpo .deps/unittests-tests.Po
g++ -DHAVE_CONFIG_H -I. -I../include  -I../src/bzfs  -I../include  -lCppUTest -std=c++0x -MT unittests-bans.o -MD -MP -MF .deps/unittests-bans.Tpo -c -o unittests-bans.o `test -f 'bans.cxx' || echo './'`bans.cxx
In file included from /usr/include/c++/4.9/map:60:0,
                 from ../include/StateDatabase.h:21,
                 from ../include/global.h:26,
                 from ../include/Address.h:31,
                 from ../src/bzfs/AccessControlList.h:21,
                 from bans.cxx:15:
/usr/include/c++/4.9/bits/stl_tree.h: In member function 'std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_create_node(_Args&& ...)':
/usr/include/c++/4.9/bits/stl_tree.h:420:14: error: '__tmp' does not name a type
        ::new(__tmp) _Rb_tree_node<_Val>;
              ^
Makefile:501: recipe for target 'unittests-bans.o' failed
make[1]: *** [unittests-bans.o] Error 1
make[1]: Leaving directory '/home/user/bzflag/tests'
Makefile:486: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

The build works fine on Debian Wheezy, which has GCC 4.7.2. Am I hitting a GCC 4.9 bug, or is our code messing something up? One thing to note is that it seems the issue may be triggered by building in c++0x mode.

The mouse is currently restricted to the window when Options->Input Settings->Confine Mouse->Window is set. This appears to be in effect at all times. By contrast, when Confine Mouse->MotionBox is set, the mouse is confined to the mouse box only while playing, and a player may release the mouse temporarily by holding down ctrl. Confinement to the motionbox appears to be accomplished by taking the mouse position and warping it. On some platforms, there are reports that if the mouse escapes the window or motionbox (probably between frames), it remains there until moved back into the window. Additionally, because the mouse can escape the window, we currently require the use of the SDL_CaptureMouse() (which is not in any official releases of SDL 2 yet) function when using SDL 2, because motion events outside the window are not reported.

The desired behavior is for the mouse to be confined, whether to the window or to the motionbox, only while playing, and for it to work consistently across all platforms. We would also like to remove our dependency on SDL_CaptureMouse(), which could be accomplished by having the window grab the mouse when in confine to motionbox mode also.

Handling of group permissions needs to be revisited for 2.6.x and here are things that are to be done. Feel free to add more requirements/tasks.

• Handle custom permissions better than with just a vector
• Properly support +ALL for custom permissions
• Support negating (-) and denying (!) custom permissions
• Rewrite group permission parsing entirely

Steps to reproduce:

1. Start client
2. Minimize client with F4
3. Right click on taskbar icon for the running client, click "Close window"
4. Look in task manager under background processes and see BZFlag is still running

And it seems like the client loop itself is still running since if I join a server, enable autopilot, it will continue driving around like normal after I click "Close window".

We currently have our own code for both encoding (when creating screenshots) and decoding (for loading textures) PNG files. We should make use of libpng instead.

• Read textures with libpng
• Write screenshots with libpng
• Clean up existing textures that generate warnings
• Hook into libpng's error/warning reporting to show errors/warnings in the game client

Move the self-destruct process to the server or at least have the client use a BZDB variable for the self destruct countdown. For instance, in an obstacle course map an instant self destruct would be better than waiting 5 seconds waiting to die so you can start over at the checkpoint.

This may not occur with the version of the code in our repository at this time as I'm using the third party dependency package (meaning, no more src/other/ and newer versions of libraries in some cases). I had a release build of bzadmin on Windows that crashed as soon as I entered a server to connect to. Trying again with a debug build just makes it hang and never get past connecting. I didn't yet have time to investigate further.

When GM lock is established and shot fired, and the flag is dropped before the shot ends, either initiated by the player, or due to a flag shot limit, the GM lock is lost. GM's should retain lock until either the shooter is killed or the shot ends.

Currently, the bz_eGetWorldEvent allows you change the map the bzfs instance without killing the actual process but the event does not parse the options block to update the respective settings. In other words, if you start with a map that's FFA and try to use this event to switch to a CTF map, it'll remain FFA. This applies to everything in the options block, so BZDB variables, map settings, etc.

This would most likely require a refactor of how the options blocked is parsed since there's no function or class to parse a world file.

Add bz_incrementTeamWins() and bz_incrementTeamLosses() to the API similar to how bz_incrementPlayerWins and bz_incrementPlayerLosses exist.

Some slash commands sometimes fail based on case sensitivity.
This happens to effect the /help commands, but not sure on how many other commands it does effect.

As per my discussion with blast, it would be nice to support a modern data format such as JSON at least in the API to replace the current .ini format that's very limited. I would like to suggest the json-c library, which is what I use in my League Overseer plugin, since it has a package on most Linux distributions as libjson0-dev or json-c-devel and it has support for Windows as well. Which library we choose is also up for discussion.

We would be able to use JSON internally for configuration files and other files as well. When to implement this whether for 2.4.x or 2.5.x is up for discussion.

/cc @blast007

I'm using 2.4.4 RC2, for Mac OSX. After emptying my clip, when my bullets reload, there is a delay of a 2-3 seconds before I can fire. This delay occurs after the bullets have visually reloaded.

There are times when I can't fire, and I haven't recently fired, but I can reproduce it most easily by firing.

EDIT: The bug seems more correlated to my speed than to reload or spawning. If I am driving forward at full speed, I often can't fire, but then when I stop, I can fire again.

Can I get back the rights to update the repository.

1. I would like to push the subdir-objects pull request
2. Use libpng to read images
3. Add force feedback support for SDL2
4. ...

Windows 10
BZFlag v.2.4.4 RC1
Options→Input Settings→Confine mouse: MotionBox
Options→Display Settings→Change Video Format: 1600x900 @60Hz 32 bits
Options→GUI Settings→Mouse Box Size: [-----O----------------]
Join Game→Connect
Spawn
F1

Mouse is centered in the middle of the screen, while the game window is in the top-left corner.
Ctrl does not release the mouse.
If the mousebox was large enough to have a corner of the screen-centered mouse area overlap the window area, it could recenter on the window
Win+Tab to focus a specific window releases the mouse from being centered.
#15: "On some platforms, there are reports that if the mouse escapes the window or motionbox (probably between frames), it remains there until moved back into the window."

When joined to a game in observer mode, and when following a player, a line is shown under the name of the player you are following on the scoreboard. When you press esc to pull up the menu, this line is still shown with the same clarity notwithstanding the dark menu shading obscuring the other HUD elements. This should be corrected so that this line is obscured by the menu shading as expected.

The API header defines bz_addUrlJob() as such but URLFetchHandler::Tick() doesn't do any checking/handling for NULL so this causes a crash.

BZF_API bool bz_addURLJob(const char* URL, bz_BaseURLHandler* handler = NULL, const char* postData = NULL);

The details:

checking for c-ares DNS lookup functionality... yes
checking for ares_library_init in -lcares... yes
checking for gawk... (cached) gawk
checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.42.1
checking whether libcurl is usable... no
checking checking for curl library... configure: error: working curl library was not found
ts2@linux-0fiz:~/m_local/bin_p/BZFlag/kompil/bzflag-2.4.6-RC2$ locate libcurl
/usr/lib64/libcurl.so
/usr/lib64/libcurl.so.4
/usr/lib64/libcurl.so.4.3.0
/usr/lib64/fpc/2.6.2/units/x86_64-linux/libcurl
/usr/lib64/fpc/2.6.2/units/x86_64-linux/libcurl/Package.fpc
/usr/lib64/fpc/2.6.2/units/x86_64-linux/libcurl/libcurl.o
/usr/lib64/fpc/2.6.2/units/x86_64-linux/libcurl/libcurl.ppu
/usr/lib64/fpc/2.6.2/units/x86_64-linux/libcurl/libplibcurl.a
/usr/lib64/pkgconfig/libcurl.pc
/usr/share/aclocal/libcurl.m4
/usr/share/doc/packages/libcurl-devel
/usr/share/doc/packages/libcurl-devel/symbols-in-versions
/usr/share/fpcsrc/packages/libcurl
/usr/share/fpcsrc/packages/libcurl/Makefile
/usr/share/fpcsrc/packages/libcurl/Makefile.fpc
/usr/share/fpcsrc/packages/libcurl/examples
/usr/share/fpcsrc/packages/libcurl/fpmake.pp
/usr/share/fpcsrc/packages/libcurl/src
/usr/share/fpcsrc/packages/libcurl/tests
/usr/share/fpcsrc/packages/libcurl/examples/Makefile
/usr/share/fpcsrc/packages/libcurl/examples/Makefile.fpc
/usr/share/fpcsrc/packages/libcurl/examples/testcurl.pp
/usr/share/fpcsrc/packages/libcurl/examples/teststream.pp
/usr/share/fpcsrc/packages/libcurl/src/libcurl.pp
/usr/share/man/man3/libcurl-easy.3.gz
/usr/share/man/man3/libcurl-errors.3.gz
/usr/share/man/man3/libcurl-multi.3.gz
/usr/share/man/man3/libcurl-share.3.gz
/usr/share/man/man3/libcurl-symbols.3.gz
/usr/share/man/man3/libcurl-tutorial.3.gz
/usr/share/man/man3/libcurl.3.gz
ts2@linux-0fiz:~/m_local/bin_p/BZFlag/kompil/bzflag-2.4.6-RC2$ uname -a
Linux linux-0fiz 3.16.7-35-desktop #1 SMP PREEMPT Sun Feb 7 17:32:21 UTC 2016 (832c776) x86_64 x86_64 x86_64 GNU/Linux
ts2@linux-0fiz:~/m_local/bin_p/BZFlag/kompil/bzflag-2.4.6-RC2$ date
Sat Jun 11 14:28:16 EEST 2016
ts2@linux-0fiz:~/m_local/bin_p/BZFlag/kompil/bzflag-2.4.6-RC2$

On Mac OS X using SDL 2.0, with vsync enabled in display options, if the window is fully occluded, the framerate is no longer limited and the client begins consuming a high percentage of CPU. Switching back to the client or making the window visible shows that the framerate was at a high level, but it returns to the expected rate once the window is visible. This bug was reported to the SDL team at https://bugzilla.libsdl.org/show_bug.cgi?id=2998, but it is unclear if or when this will be fixed. A temporary workaround to limit the framerate to some sane number when this condition is detected may be necessary.

With 2.4.4-RC1 (and current git), on some systems (possibly only Windows) in some configurations (IPv6 enabled for sure), HTTP connections to the MOTD and list server (and probably things like texture/world downloads) are delayed by 10 to 20 seconds. When I ran a wiresharp capture filtered as "ip.addr == <listserverip> or dns" for the MOTD request, I noticed it first ran a AAAA (IPv6) record lookup, and then it waited roughly 18 seconds to do an A (IPv4) record lookup, after which there was about a 250ms delay to when it first tried to connect to bzflag.org to get the MOTD.

I imagine our previous builds of libcurl did not enable IPv6. When I set CUROOPT_IPRESOLVE to CURL_IPRESOLVE_V4, the long delay goes away as it does the IPv4 lookup only and immediately.

It's worth noting that when I use the built curl.exe from our bzflag-dependencies repo to access https://bzflag.org/motd.php, there is no delay. So it's possibly some issue with our curl setup.

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
objc[299]: garbage collection is OFF

Dyld Error Message:
  Symbol not found: _clock_gettime
  Referenced from: /Users/USER/Desktop/BZFlag-2.4.10.app/Contents/MacOS/BZFlag
  Expected in: /usr/lib/libSystem.B.dylib

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   dyld                          	0x00007fff658ed06d dyld_fatal_error + 1
1   dyld                          	0x00007fff658f0948 dyld::fastBindLazySymbol(ImageLoader**, unsigned long) + 128
2   libdyld.dylib                 	0x00007fff8e2e0716 dyld_stub_binder_ + 13
3   ???                           	0x0000000105f25030 0 + 4394733616
4   org.BZFlag                    	0x0000000105e8bf5e ares_init_options + 100
5   org.BZFlag                    	0x0000000105e066e1 AresHandler::AresHandler(int) + 129
6   org.BZFlag                    	0x0000000105d6e6ac initGlobalAres() + 30
7   org.BZFlag                    	0x0000000105cffa20 main + 48
8   org.BZFlag                    	0x0000000105cece84 start + 52

This appears to be an issue with a function that is only available in later macOS versions, but it involves a symbol that is supposed to get weak-linked. c-ares appears to have an autotools script section to handle this here, but it appears that this does not honor the deployment target (neither with MACOSX_DEPENDENCY_TARGET nor -mmacosx-version-min).

We can get around this by compiling our release binaries on Yosemite for now. We should probably try to find a long-term solution for this, though.

Have both /showperms and /groupperms display custom perms that are used by plug-ins.

It is possible for a client to send invalid floating point numbers to the server. This can cause unpredictable/undefined behavior in the game server or in the other game clients that then get passed this invalid floating point value.

Therefore, we should be validating floating point values on the server before we attempt to process or pass that data on. Changeset 680c5f7 was the first time we added an isnan check, and this one was done because it was specifically being used to trigger an infinite loop or crash in the game client. But we should also add checks to other messages that receive floating point values and either reject the message or kick the player.

When you type a message, the length is capped to 127 characters. When you type a message of this length, one additional character is left off somewhere during transmission. This should be corrected so that all entered characters are transmitted to the recipient.

When timestamps are enabled in the console, the timestamp color is normally white when the line is not long enough to wrap around. However, when a console line is wrapped into a second line, the timestamp colors for both the first and second line takes on the color of the text at the end of the second line (which depends on what kind of content it is). This can usually most easily be seen by switching between fullscreen and windowed mode.

The correct behavior would be for the timestamp to always have a consistent color, regardless of what color the rest of the line content is and regardless of whether the line wraps around.

I have been working on this issue for a couple weeks now and still haven't been able to figure out why it is failing to run. This is release critical, so we need to fix it before the 2.4.4 release, and I need some help with it. I'm not familiar enough with what is going on in the Windows platform code.

When the game starts, it ends up creating a child window and then trying to destroy it again. I believe the destroying part is just because it's going fullscreen, and display changes recreate the child window. In any case, it gets stuck in DestroyWindow(hwndChild) inside of the WinWindow::destroyChild() method. I set up some tracepoints in WinWindow::createChild(), WinWindow::swapBuffers(), WinWindow::destroyChild(), and WinDisplay::Rep::WindowProc(...) and ran the game client. The output of that (edited to show what the msg value refers to) as trace01.txt.

The system I am using has an AMD A10 Micro-6700T SoC, which has AMD Radeon R6 Graphics, running Windows 10 64-bit. I've tried using the latest stable driver from AMD (Radeon Software version 15.11, driver version 15.30.1025-151117a-296567C) and the latest beta (Radeon Software version 15.11.1, driver version 15.30.1025.1001-151129a-297019E).

NTH originally reported the issue. He's got a Radeon HD 78xx card running Windows 10 build 10586.14 with AMD driver version 15.30.1025-151117a-296567C. He mentioned the issue started after Windows 10 updated. So I'm not sure if it's a Windows 10 issue or an AMD driver issue.

I did not have an issue on a laptop with Intel/AMD hybrid graphics using a Radeon HD 8690M, but that may just be due to the hybrid graphics.

This issue may be the same or related: https://forums.bzflag.org/viewtopic.php?f=12&t=19152

Initially, our release of 2.4.2 worked, and then 2.4.4RC2 (or my other builds I ran) would work until a reboot. Now our old 2.4.2 build is having the same issue. Running the game windowed does work, but will still hang if you switch it to full screen.

To reproduce:

1. Start client in full screen
2. Switch to windowed with F1
3. Press green button to "enlarge" the window or make it full screen

In BZFlag 2.4.4, pausing the countdown no longer shows the "Paused" text at the top of the screen. Instead, the timer appears to continue running. When the countdown is resumed, the timer resets to the correct time from when it was paused. This occurs whether it is paused from a plugin, or paused with the command "/countdown pause."

Seems like I broke backwards compatibility for cylinder in the bz_CustomZoneObject class. The bbox backwards compatibility should work but I'll test it to make sure.

It's most likely the underscore on line 2918. I'll confirm in a bit.

The c-ares library is used for making asynchronous DNS lookups. We should investigate if we actually need this library or if we could get by with a simple threaded lookup. Libcurl can use c-ares or a threaded lookup already. Also, as mentioned in #74, c-ares may be the source of a crash when building on newer versions of macOS.

The input feedback system (mousebox) is not optimal and should be replaced.
See attached proposal.

InputFeedbackRedux_r2.pdf

When you select "Find Server," and immediately press '/' to begin typing search terms, once the list begins loading you cannot type further. You must press esc and then '/' again to continue typing. This should be corrected so that either you cannot type search terms until the list is loaded, or so that (preferably) the list will continue to load without interference while you are typing search terms.

A you choose to omit it?

The raw joystick axis readings are currently subject to several obscure calculations prior to being used for driving speed/rotation. One of the factors is based on the mousebox size. While this does allow for some control over the joystick sensitivity, the results do not seem ideal. For example, at mousebox size -5, my gamepad stick reaches the full value at approximately 10% in one axis, and about 15% in the other. This makes it very difficult to play the game with a joystick. The obvious solution is to just map the actual values onto a -1, 1 scale. However, with a circular axis (as some joysticks have), with the stick in a diagonal direction, the maximum in each axis will be (√2)/2 (or approximately 0.7), putting joystick players at a disadvantage. While a calculation is possible to map a circular area onto a square, some sticks (such as mine) do not have a 1.0 magnitude at all angles. Some users may also need/want to adjust the sensitivity of their sticks.

It appears the solution will be to map circular sticks to the control box (square), to have some kind of test to determine the full range of the joystick, then mapping it appropriately and also offering the user a way to adjust the sensitivity of the joystick. Some kind of visual feedback will probably also be helpful.

Burrow-depth-speed and time-of-day adjust slow on Macs
Using OS X Yosemite 10.5.5. Pretty sure this is a mac-only bug.

After picking up a burrow flag, It takes too long to sink underground, and to raise back up after dropping burrow. Approximately three times too much time.
Adjusting time of day using the + and - keys is way too slow. This drives me nuts when i'm mapping, because the time resets on each join.
Don't know if these issues are related, or not.