| 00:10.47 | BZNotify | bzflag: 03jwmelto 03opened pull request #203 "simplify singleton pattern, silencing compile warnings for issue #176" (06https://git.io/fji8W) |
| 00:10.48 | BZNotify | bzflag: 03jwmelto review_requested pull request #203 |
| 00:11.57 | BZNotify | bzflag: 03jwmelto commented on issue #176 "XCode Build Warnings" (052.4.20 - 06https://git.io/fji8l): #203 |
| 00:18.19 | *** join/#bzflag infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:18.19 | *** topic/#bzflag is https://BZFlag.org || https://www.openhub.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || Current version: 2.4.18 || New shiny website! https://forums.bzflag.org/viewtopic.php?f=8&t=20201 |
| 00:18.19 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:18.23 | Flash | maybe so |
| 00:18.33 | blast007 | on Windows it's already exporting only the API stuff |
| 00:19.00 | blast007 | (which is why plugins that bypass the API don't work on Windows) |
| 00:40.41 | Flash | Q3BSP.hh in modeltool is (C) Id Software ... should we have it? |
| 01:08.29 | blast007 | dunno. it's from here: https://github.com/OGRECave/ogre/blob/master/PlugIns/BSPSceneManager/include/OgreQuake3Types.h |
| 01:08.43 | blast007 | not seeing the same thing in the ioquake3 codebase |
| 01:15.02 | BZNotify | bzflag.org: 03jwmelto 11synchronized pull request #31 "offer a homebrew alternative" (06https://git.io/fj6bS) |
| 01:15.03 | BZNotify | bzflag.org: 03jwmelto 11synchronized pull request #31 |
| 01:44.51 | Flash | macsforme: the BZFlag project has debug symbols not hidden and release symbols hidden, but bzfs has both version not hidden |
| 01:45.15 | Flash | everything I've read suggests that all compilation units should have the same setting |
| 01:49.02 | Flash | if I change it to be the same as the default, the warnings go away |
| 02:19.34 | Flash | nope. never mind. Xcode is smarter than me ... looks like I wasn't actually building :( |
| 02:20.25 | blast007 | the settings should be the same for all projects regardless |
| 02:21.47 | blast007 | for mac, we previously had debug symbols enabled for release builds because the builds (or apple's drivers) used to be quite crashy |
| 02:46.02 | *** join/#bzflag Dracos85_ (~dracos85@24-119-188-49.cpe.cableone.net) |
| 02:46.47 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98455.dyn.optonline.net) |
| 03:08.34 | BZNotify | bzflag: 03jwmelto commented on issue #176 "XCode Build Warnings" (052.4.20 - 06https://git.io/fji4D): >>ld: warning: direct access in function 'AccessControlList::sendId... |
| 03:11.58 | *** mode/#bzflag [-v short_circuit] by ChanServ |
| 03:34.56 | BZNotify | bzflag: 03macsforme commented on issue #176 "XCode Build Warnings" by 03jwmelto (052.4.20 - 06https://git.io/fji4b): The `-fvisibility=hidden` was I believe the suggested remedy in the... |
| 04:13.43 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98455.dyn.optonline.net) |
| 06:24.31 | macsforme | tupone: great, I'll check it out |
| 06:27.06 | macsforme | I'm a little confused by all your PRs and branches, and all the forced pushes... I hope you can eventually do one clean feature per PR, so each feature can be understood and evaluated independently (although I know some features depend on others) |
| 06:28.16 | macsforme | I'm excited to get shader support... that will facilitate the new menus I want to implement |
| 06:34.03 | macsforme | blast007: yes, -NSDocumentRevisionsDebugMode has YES after it, although it looks like you figured that out... without checkargc, the client was trying to join the server with the address "YES" |
| 06:43.27 | macsforme | tupone: yep, looks good |
| 06:43.48 | macsforme | the clouds look like they're lower than in the standard client, though... not sure where that issue was introduced |
| 06:53.53 | macsforme | Flash: okay, it looks like in Xcode the default behavior is for symbols to not be hidden by default for libraries, and for symbols to be hidden by default on executables |
| 06:55.07 | macsforme | I probably had to change bzfs way back in the day to not hide symbols in order to make plugins load |
| 07:11.21 | macsforme | when I delete all of the overrides for that setting, and then override it just once at the workspace level to NO, the only times I see those errors are when linking bzfs and when linking bzflag: https://pastebin.com/kHgnXSVH |
| 07:21.12 | macsforme | looks like overriding it to YES still throws warnings in those same two places |
| 07:46.09 | macsforme | curiously, in master, with the premake-generated Xcode projects, using -fvisibility=hidden eliminates those warnings entirely... I wonder if there is some linker setting in our 2.4 Xcode project that is causing those to show up |
| 07:46.47 | macsforme | passing -fvisibility=default, or leaving it out entirely, causes the warnings to appear in those same two link steps |
| 08:00.43 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98455.dyn.optonline.net) |
| 08:44.43 | tupone | macsforme: I would like to push glm and missile first. But I don't want to break the tree so I need some support from you. Then I have to cleanup my port to GL1.5 reducing the number of commits |
| 08:45.56 | tupone | after that GL2.0 ... I have some dependency on SDL2 that needs to be ported on other platform |
| 08:46.48 | tupone | like selecting opengl version and reading file |
| 08:47.05 | tupone | file -> shader |
| 08:48.40 | tupone | I will check the cloud when at home. Doing a bisect should be enough |
| 09:16.05 | *** join/#bzflag Dracos85 (~dracos85@24-119-188-49.cpe.cableone.net) |
| 11:11.06 | blast007 | I still don't like the idea of applying the glm/missile changes to 2.4. |
| 11:57.41 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98455.dyn.optonline.net) |
| 12:05.54 | tupone | i can remove the missile things. but glm is my gl2.0 porting |
| 12:59.56 | blast007 | isn't GL 2.0 a big enough feature that it could be the focus of a new major release of the game? |
| 13:00.50 | *** join/#bzflag Dracos85_ (~dracos85@24-116-38-202.cpe.cableone.net) |
| 13:24.50 | tupone | why change the protocol if only the graphics is changing |
| 13:28.47 | *** join/#bzflag Dracos85 (~dracos85@24-119-188-49.cpe.cableone.net) |
| 15:15.25 | The_Noah | Does anyone have an idea when GL2.0 will be ready? |
| 15:15.45 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98455.dyn.optonline.net) |
| 15:48.57 | blast007 | tupone: major releases aren't just for network protocol changes |
| 15:54.12 | The_Noah | I think his point is why force people and servers to update when it is not required. |
| 15:54.44 | blast007 | because I want a 2.6 release to happen :) |
| 15:55.13 | blast007 | and part of the change is switching to a new math library and I don't want some odd issues to crop up that cause 2.4.18 and 2.4.20 to behave differently |
| 15:56.23 | blast007 | protocol is also about client behavior - if the client behavior changes, the protocol should be bumped |
| 16:14.17 | The_Noah | True. And I also really want 2.6 to be released :) |
| 16:15.15 | The_Noah | What do you think about when you are locked on to someone with GM it will highlight them somehow on the radar? Kinda like when graphics are set to experimental. |
| 16:27.11 | tupone | I would like to have GL2.0 on current server. If 2.6 is going to mantain the current protocol I agree on moving my branch on it. But I think the protocol was already moved ahead |
| 16:43.24 | blast007 | I want 2.4 to be done with just minor maintenance |
| 16:44.11 | tupone | I agree with that |
| 16:44.32 | tupone | But why 2.6 had network changes if not needed |
| 16:48.48 | blast007 | because we're adding new features that require network or behavior changes |
| 16:52.28 | blast007 | I'll try to take some time to look at the changes. I'm probably just worried about nothing and it'll be fine for 2.4. |
| 16:56.54 | tupone | glm and Missile I won't be worried. GL2.0 is a bigger change and need to be tested. I did playing but something I missed, macsforme found some problem that I fixed then |
| 17:31.19 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98455.dyn.optonline.net) |
| 19:22.38 | macsforme | I say we take all the projects currently being discussed/worked on, roll them into master, and move ahead with releasing 2.6 |
| 19:24.55 | tupone | macsforme: is that anything there that needs protocol changes ? |
| 19:26.15 | macsforme | yes, several things (I have to look back to remember what)... and anyway, IMHO, we need to move to a process where the protocol is updated regularly, and we can push out new clients to all platforms |
| 19:28.17 | macsforme | I suggest that the 2.6 release is an ideal time to do that |
| 20:08.15 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98455.dyn.optonline.net) |
| 20:14.34 | blast007 | 2.4 could even be the "classic" version, if we'd want to have one :) |
| 20:28.08 | tupone | fog is coded (not tested). Bisecting the snow now |
| 21:27.10 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:03.30 | BZNotify | bzflag: 03The-Noah 03opened issue #204 "Thief doesn't always set reload timer before being able to fire." (06https://git.io/fjiPD) |
| 22:04.15 | *** join/#bzflag spldart (~james@2601:2c5:c600:2365::7c1e) |
| 22:04.15 | *** join/#bzflag spldart (~james@bzflag/contributor/spldart) |
| 22:04.15 | *** mode/#bzflag [+v spldart] by ChanServ |