| 00:08.29 | macsforme | tupone: so that's it? you just include GL/glew.h and all the functions are loaded automatically (if available)? |
| 00:12.04 | macsforme | trying to test on macOS... of course compiling GLEW is a pain |
| 00:20.02 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:20.02 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.14 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19953 |
| 00:20.02 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:23.56 | allejo | so I can't remember where I saw it or if I even saw it, but I *thought* setting a team count in -mp to -1 would force spawn that team flag. was useful when bzsocccer, bzhockey, and the like were popular maps. was that my imagination and/or should that be supported? |
| 00:25.12 | Zehra | Those are the maps I was looking on, along with a few others, which basically required a player slot to be taken for the map to work. :p |
| 00:25.40 | Zehra | From viewing the topic, mrapplecomputer1 did a server modification to get that to work. |
| 00:26.30 | Zehra | It would be nice as an option though. |
| 00:28.51 | Zehra | Or maybe just having a server side bot join is a better solution? |
| 00:31.13 | allejo | it used to be common for maps to do that. any other support for/against this feature? there shouldn't be a requirement of having a bot on there |
| 00:33.37 | Zehra | I'm for it. It provides a way of introducing maps and settings and prevents people from having to mod their server to get it to work. |
| 00:34.18 | Zehra | It also has been mentioned in the forums a few times too, by different map makers too and some who have been server hosts as well. |
| 00:36.43 | blast007 | we can revisit that stuff for 2.6 |
| 00:53.32 | *** join/#bzflag nitroxis (n@nxs.re) |
| 01:10.58 | kierra | JeffM ping |
| 01:21.37 | JeffM | Make all flag spawns come from a plugin ð§ |
| 02:12.57 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 02:54.04 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 02:55.23 | Zehra | I did a few tests with the server side player. |
| 02:55.43 | Zehra | It seems joining as an observer is fine, but joining a team doesn't work. :p |
| 02:56.50 | Zehra | The /playerlist command seems to trigger a crash too.(Although I was using a slightly modified version of the server side player.) |
| 04:44.10 | tupone | macsforme: loaded with glewinit after createcontext |
| 12:33.57 | *** join/#bzflag I_Died_Once_ (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 12:47.00 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 14:12.11 | macsforme | well that is pretty simple if that's all you need to do, and would also make it easy to transition to newer OpenGL standards... I'll see if I can get it to work on macOS |
| 14:29.41 | macsforme | got it to work on macOS... everything we had before seems functional |
| 15:17.38 | *** join/#bzflag the_map (~the_map@unaffiliated/the-map/x-1795707) |
| 16:10.33 | tupone | ok. We just need a build on windows. I hope that putting the dependency on windows is not so hard |
| 16:30.45 | JeffM | it's just a project file right? |
| 16:31.49 | tupone | I have not prepared it for windows. We need to link libGLEW.so |
| 16:32.00 | JeffM | so then there would be a dll |
| 16:32.15 | JeffM | does it's source package have a vcxproj? |
| 16:33.16 | tupone | I dunno. |
| 16:33.24 | JeffM | can you... look? |
| 16:33.56 | JeffM | and is this in the 2.4 branch or head? |
| 16:34.23 | tupone | It is in my own git. It is a pull request. |
| 16:34.39 | *** join/#bzflag the_map (the_map@gateway/vpn/privateinternetaccess/themap/x-38220869) |
| 16:34.44 | tupone | I'm going to see how we integrated previously, if we did |
| 16:34.55 | JeffM | I know that, but what branch is your branch based on .... |
| 16:35.20 | tupone | my branch is based on 2.4 |
| 16:35.46 | tupone | and is called glew |
| 16:35.55 | JeffM | I'm making sure MY branch is current, so I can get your branch with minimal diffs :) |
| 16:36.17 | tupone | http://glew.sourceforge.net/ seems to have the binary of glew |
| 16:36.23 | tupone | for windows |
| 16:36.51 | JeffM | are you including the headers in the source tree or using them from an external dependency? |
| 16:39.00 | tupone | external dependency |
| 16:39.13 | tupone | in include bzfgl.h |
| 16:39.35 | tupone | #include <GL/glew.h> |
| 16:39.51 | JeffM | then blast007 would need to put the .lib files in the lib dirs for his external dependeicies, the GL folder in his include, and the .dll files in the bin dir |
| 16:40.05 | JeffM | what modules need glew just BZFlag or geometry too? |
| 16:41.31 | tupone | I dunno. All the gl calls are now from glew, and SDL2 initialize it |
| 16:42.10 | JeffM | heh |
| 16:42.17 | JeffM | windows is already setup to use glew |
| 16:42.19 | JeffM | it was never removed |
| 16:42.24 | tupone | Removed GLEW from the autotools build system, a few more README files⦠macsforme committed on Jul 2, 2015 |
| 16:42.27 | JeffM | just include the files in the deps and it's all good |
| 16:42.40 | JeffM | yeah nobody removed it from windows |
| 16:42.57 | JeffM | <PROTECTED> |
| 16:42.57 | JeffM | <PROTECTED> |
| 16:43.12 | JeffM | glu32.lib still sitting pretty right there in the deps |
| 16:43.49 | JeffM | people ignore the windows build system all the time, it's very sad |
| 16:44.49 | tupone | Maybe I will merge my pull request today, and make it works with all platforms (except maybe windows, that I don't know) |
| 16:44.56 | tupone | Hope it is ok |
| 16:45.01 | JeffM | it should work |
| 16:45.06 | JeffM | it's already setup |
| 16:45.25 | JeffM | just have blast put the dependencies in |
| 16:45.32 | JeffM | also, WHY is work still going into the 2.4 line? |
| 16:45.42 | JeffM | put it in the head |
| 16:46.38 | tupone | hmm, a change in the protocol, if not needed, does not allow me to test it really |
| 16:47.18 | tupone | I would see if there is an hope to stay in the 2.4 line |
| 16:47.35 | JeffM | you want more 2.4.x versions? |
| 16:48.39 | tupone | I dunno now |
| 16:48.58 | JeffM | developmen needs to move past that |
| 16:49.06 | JeffM | so many things needs to be fixed |
| 16:49.25 | JeffM | but if people keep staying with 2.4.x because it's "safe" nothing will ever be done. |
| 16:49.33 | JeffM | do it in both. |
| 16:49.38 | JeffM | at the very least |
| 16:51.03 | tupone | I guess we need to move the master where 2.4 is now, or create on 2.4 a 2.6 branch |
| 16:51.22 | tupone | I don't use master at work |
| 16:51.42 | JeffM | the use of head for bzflag devleopment is up to blast007 he is the maintainer |
| 16:51.54 | JeffM | I've seen people do it both ways |
| 17:00.20 | blast007 | https://github.com/nigels-com/glew/tree/master/build/vc15 <-- GLEW has VC15 project files |
| 17:00.45 | blast007 | I'd like to be done with 2.4 and start working more on 2.6 |
| 17:01.03 | JeffM | so you can build glew as part of your deps then |
| 17:01.09 | blast007 | yup |
| 17:01.12 | JeffM | should just merge in fine |
| 17:01.26 | JeffM | the bzflag projects STILL reference the .lib files |
| 17:02.04 | tupone | I don't see the call to glewInit ... When it was removed ? |
| 17:06.03 | blast007 | tupone: https://github.com/BZFlag-Dev/bzflag/commit/4d0722e2c15660f77a50399f172951a511385e5a |
| 17:08.20 | blast007 | JeffM: glu != glew |
| 17:08.27 | JeffM | bahhh |
| 17:08.28 | JeffM | my bad |
| 17:08.50 | JeffM | then yeah, you'd need to add glew32.lib to that list |
| 17:08.58 | *** join/#bzflag the-map (the_map@gateway/vpn/privateinternetaccess/themap/x-38220869) |
| 17:09.05 | JeffM | just edit the XML if you arn't on windows |
| 17:09.09 | JeffM | just use an editor that doesn't suck |
| 17:09.26 | blast007 | nah, don't |
| 17:09.41 | JeffM | cool, going to make all developers install windows now? |
| 17:09.44 | blast007 | there's something wonky with line endings when you do that |
| 17:09.53 | JeffM | hence why you don't want to use an editor that sucks |
| 17:10.02 | JeffM | I do it all the time, but your editor needs to be line ending aware |
| 17:10.05 | blast007 | I tried several |
| 17:10.20 | JeffM | surely there must be a linux editor that doesn't suck? |
| 17:10.33 | blast007 | I think it was git being silly, not the editors |
| 17:10.51 | JeffM | you can tell git what to force the line endings too |
| 17:11.26 | blast007 | yeah, I just haven't taken time to look into that.. I just turn on my Windows PC instead.. |
| 17:11.27 | JeffM | if windows devs are expected to add stuff to makefiles, it stands to reason that linux devs should do the same for windows. |
| 17:11.52 | tupone | blast007: are you fine to add glew? if, which branch ? |
| 17:12.05 | tupone | or I can wait :) |
| 17:12.29 | blast007 | probably master, but let me try it out when I get home |
| 17:13.54 | blast007 | I'm of the opinion that we should be done with 2.4 now, short of bug fixes |
| 17:14.05 | JeffM | critical bug fixes |
| 17:14.35 | tupone | Are you going to rebase the master? |
| 17:14.47 | blast007 | yeah, I'll merge the 2.4 branch into master |
| 17:15.21 | tupone | thinks is better to rebase - for the history |
| 17:15.37 | blast007 | I mean.. it brings history with it |
| 17:16.21 | JeffM | merge and rebase are the same thing in git arn't they? |
| 17:18.20 | blast007 | I use 'git merge origin/2.4' and fix any conflicts |
| 17:21.53 | JeffM | guhh, debugging CGIs is a pain in the butt.... |
| 18:06.24 | tupone | rebase move the commit from one place to another |
| 18:06.49 | tupone | so the history could be linear |
| 18:07.04 | tupone | you can bisect for instance more easily |
| 18:08.22 | tupone | with rebase on the server, there is a problem in the synchronization with clients |
| 18:10.28 | blast007 | I don't see a problem with how we're doing it now. |
| 18:11.00 | blast007 | the way we're doing it now, I know stuff came from 2.4 |
| 18:31.06 | *** join/#bzflag tupone (~alfredo@gentoo/developer/tupone) |
| 18:59.40 | tupone | blast007: did you have some feedback from SDL2 standalone test? |
| 19:14.11 | blast007 | don't think so |
| 19:42.38 | allejo | the only thing I want to push for in a another 2.4.x release would be possible some colorblindness stuff. get feedback on that asap so it'll be better for 2.6 |
| 20:01.11 | JeffM | allejo: do that as a special build |
| 20:01.19 | JeffM | since it's for a specific purpose |
| 20:03.30 | allejo | that'd also work for my case |
| 20:17.01 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 20:17.01 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 20:30.22 | JeffM | yeah your test users are limited, it doesn't need a full release just for that ;) |
| 20:44.16 | *** join/#bzflag allejo (~allejo@bzflag/developer/allejo) |
| 20:44.16 | *** mode/#bzflag [+v allejo] by ChanServ |
| 21:52.22 | *** join/#bzflag the_map__ (the_map@gateway/vpn/privateinternetaccess/themap/x-38220869) |
| 22:28.37 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:30.31 | BulletCatcher | I'll make time tomorrow to do the standalone SDL2 test. |
| 23:46.21 | macsforme | wouldn't rebasing master on top of 2.4 ruin the history for people who've already checked it out? I thought you don't want to rebase code that is already published |
| 23:47.02 | JeffM | I belive he was saying to rebase master from 2.4, not the other way around. |
| 23:47.15 | JeffM | 2.4 needs to stay the way it is, |
| 23:47.29 | JeffM | use rebase to push 2.4 into master |
| 23:48.01 | macsforme | that's what I meant... but master is a public branch and people have checked it out |
| 23:48.15 | JeffM | next time they get they will get more |
| 23:48.23 | JeffM | people with branches will have to rebase |
| 23:48.43 | blast007 | and we have commited stuff to master, so rebasing it would be a destructive operation that would require a force push, no? |
| 23:48.45 | JeffM | you want your next version to have all the fixes from your current version. |
| 23:48.51 | macsforme | I believe they will actually get an error for a non-fast-forward merge |
| 23:49.00 | macsforme | hence merge, rather than rebase |
| 23:49.01 | JeffM | is that why a merge is better? |
| 23:49.04 | JeffM | ok |
| 23:49.19 | blast007 | the merge works fine, I'm just gonna keep doing that |
| 23:49.23 | JeffM | what is the techicnal differece between a git merge and a rebase? |
| 23:49.57 | JeffM | in the system we use a work, there is only one function, merge, rebase is just you merging along a branching tree |
| 23:50.07 | JeffM | but it uses the merge feature |
| 23:50.15 | blast007 | "But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch." |
| 23:50.18 | blast007 | https://www.atlassian.com/git/tutorials/merging-vs-rebasing |
| 23:50.27 | blast007 | rewriting history is bad, m'kay |
| 23:50.30 | JeffM | oh yeah |
| 23:50.42 | JeffM | that seems like something you'd only do in dire circumstances |
| 23:50.56 | blast007 | that's something you'd be before pushing |
| 23:50.57 | JeffM | like someone done screwed up your branch |
| 23:51.04 | allejo | rebase will rewrite the history. where merge will merge the history |
| 23:51.32 | JeffM | so if you do parallel development, you always want to do merge, |
| 23:51.33 | allejo | rebase should be done for bringing up feature branches up to par with a master branch |
| 23:51.57 | allejo | if itâs not a WIP branch, always merge |
| 23:52.29 | JeffM | well that is sort of what is happening with master. it' is kinda a 'feature" for the next release, and it needs to be brought up to spec with the current de-facto master of "2.4" |
| 23:52.42 | JeffM | but development was kind of backwards. |
| 23:57.47 | blast007 | allejo: does a rebase require a force push? |
| 23:58.41 | macsforme | I agree it's time for our work to go into the next major release... however, we've had problems in the past with ambiguity in status between the stable and development branches, and things have gone stagnant |
| 23:58.46 | macsforme | is it feasible for us to transition to a process where protocol breaks are a regular, expected occurrence, so we can push out major new features faster? |
| 23:59.39 | macsforme | every multiplayer game I've played lately requires you to download the latest patch or you can't play, so I question if that would actually be a barrier for players |