| 00:21.27 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:21.27 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.10 released! https://forums.bzflag.org/viewtopic.php?f=8&t=19401 |
| 00:21.27 | *** mode/#bzflag [+v infobot] by ChanServ |
| 01:12.37 | *** join/#bzflag llrr (~llrr@203.220.116.215) |
| 01:14.33 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 02:34.54 | *** join/#bzflag Andradite (~Zehra@unaffiliated/zehra) |
| 05:50.41 | *** join/#bzflag llrr (~llrr@203.220.116.215) |
| 07:40.10 | *** join/#bzflag tw1sted (~tw1sted@104.236.87.240) |
| 07:41.29 | *** join/#bzflag tupone_ (~alfredo@gentoo/developer/tupone) |
| 09:07.08 | *** join/#bzflag nafta_ (~nafta___@host250-129-dynamic.49-82-r.retail.telecomitalia.it) |
| 09:12.19 | *** join/#bzflag nafta_bz (~nafta_bz_@host250-129-dynamic.49-82-r.retail.telecomitalia.it) |
| 10:26.17 | Nafta_bz | Anyone here using Linux Mint and installed latest BZFlag? I'm stick to version 2.4.2 and I don't know what is best way to upgrade |
| 10:28.38 | blast007 | build from source |
| 10:43.27 | Nafta_bz | blast007, I'm building thanks. Launching it, it says: "no fonts found (-directory option may help)" |
| 10:47.05 | blast007 | run src/bzflag/bzflag from the root of the source tree, or remove the packaged version of bzflag (sudo apt-get remove bzflag bzflag-client bzflag-server bzflag-data) and the 'sudo make install' the version from source |
| 10:47.13 | blast007 | though you'd have to add a menu item yourself |
| 10:47.33 | blast007 | and then* |
| 10:51.38 | Nafta_bz | blast007, launching from root of source tree worked, thanks a lot!!! |
| 11:06.23 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-tczqdyapzquqetff) |
| 12:35.55 | the_map | Nafta_bz: you should also be able to navigate to src/bzflag/bzflag in a file browser and drag and drop that on a system panel (where the mint menu and the window list are), and that will create a launcher from the panel for it |
| 12:38.17 | Nafta_bz | the_map: thanks a lot. Actually I never ever launched bzflag by the menu (which would be the right thing to do). I open a console, type b<up> and <cr> and go *shrug* |
| 12:39.54 | the_map | I use a hotkey :) |
| 12:39.59 | the_map | I'm actually on Mint too |
| 12:40.44 | the_map | control center --> keyboard shortcuts --> scroll down to custom shortcuts |
| 12:41.50 | Nafta_bz | :))) |
| 13:00.58 | blast007 | if you want to launch it from the menu, I'd suggest doing what I said above first |
| 13:01.17 | blast007 | if it's installed with 'make install', it will know where to look for its data files |
| 13:07.40 | the_map | yeah, you should do whatever blast007 says before you listen to me :) |
| 13:08.12 | the_map | I'm just a random nerd that bugs them |
| 13:12.26 | blast007 | and we do provide a bzflag.desktop file in the data/ directory that can be used for a menu item |
| 13:14.24 | Nafta_bz | blast007: ok. Yes I can manage to add the add the shortcut I think. |
| 13:15.43 | blast007 | eventually I'd imagine that a newer mint would have a new bzflag. Debian Stretch will have 2.4.8, which means that Ubuntu will eventually have 2.4.8, and then Mint... :) |
| 13:18.05 | blast007 | on the other hand, the Debian package also makes the server run by default... so that's less than ideal |
| 13:40.42 | brad | ubuntu already has 2.4.8 for me |
| 13:41.29 | blast007 | ah, I guess their package search defaults to 16.10 |
| 13:41.53 | brad | probably |
| 13:41.58 | brad | 2.4.8 is in zesty |
| 13:42.01 | blast007 | yeah, zesty has 2.4.8 |
| 13:42.21 | Nafta_bz | yes, I think Ubuntu/Mint aren't going to have 2.4.10 for a while for this reasons. |
| 13:42.33 | blast007 | right |
| 13:42.43 | blast007 | probably another couple years-ish |
| 13:42.55 | blast007 | er, wait, they pull from testing, so nvm |
| 13:43.05 | brad | that long? |
| 13:43.09 | blast007 | not for several months |
| 13:43.44 | blast007 | once Debain Stretch is out I'd imagine the Debian package gets updated at that time, and then it will trickle down into the next Ubuntu release |
| 13:43.45 | Nafta_bz | Anyway, I was a bit skeptic about building from source because (hmm usually?) there is always some issue to solve. Indeed (and thanks to blast007 help) it went really really smooth. Just read README file. |
| 13:44.03 | blast007 | yeah, we have pretty good build instructions :) |
| 13:44.33 | blast007 | at least if you run Debian/Ubuntu or Fedora |
| 13:45.56 | Nafta_bz | blast007: if it is the case, I would just add a little faq about the "no fonts found" thing and the solution you provided |
| 13:50.27 | Nafta_bz | but thinking about it, I would haven't had the issue if I had boldly removed the older bzflag installation and $ make install on first time, as written |
| 13:53.24 | blast007 | the question does still come up often enough that we could mention it somewhere |
| 13:53.58 | blast007 | (or we could possibly just make bzflag look two directories up for it's data files if it doesn't find them where it expects) |
| 16:01.05 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-pbhqramcsrqmriwb) |
| 16:25.00 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 17:11.55 | JeffM | is the data dir always somewhere relative to the bin on linux? or can it vary by distro? |
| 17:12.21 | JeffM | on windows, it finds the exe dir and starts from there, looking in common relative paths. |
| 17:33.34 | blast007 | JeffM: the build system defines a location where the data files would end up if installed, which gets etched into the resulting executable |
| 17:33.45 | JeffM | ewww |
| 17:36.19 | blast007 | and yes, the location of the binary and the data files can vary |
| 17:36.44 | JeffM | that doesn't seem like a stable way of doing it all.... |
| 17:37.20 | JeffM | I've pondered making windows version, check for program data before doing install dir on a per file basis |
| 17:37.22 | blast007 | for instance, on Debian, the binary is at /usr/games/bzflag and the data files are at /usr/share/games/bzflag/* |
| 17:37.32 | JeffM | then it'd be easier to replace individual files |
| 17:38.33 | blast007 | if you run the build system yourself, it might go into /usr/local/bin/bzflag for the binary and /usr/local/share/bzflag/* for the data |
| 17:40.17 | JeffM | so none of it is really portable |
| 17:42.49 | blast007 | though we do already try ../../data/filename |
| 17:43.01 | blast007 | at least for BzfMedia::readImage |
| 17:43.19 | blast007 | and readSound |
| 17:49.50 | blast007 | if we moved checks like that to where we run setMediaDirectory(), it would work |
| 17:50.24 | blast007 | having the checks in just readImage and readSound doesn't help since the client will fail to find the font .fmt files |
| 17:52.33 | JeffM | yeah, there really should be an abstracted file accessor |
| 17:52.36 | JeffM | for all client read files |
| 20:08.40 | blast007 | we should just put everything in a doom WAD file |
| 20:10.05 | JeffM | I've actualy theought aobut it |
| 20:10.09 | JeffM | put all the files in a zip |
| 20:10.12 | JeffM | and run from that |
| 20:10.19 | JeffM | then merge zips in a specific order |
| 20:10.28 | JeffM | it's relativly easy to do |
| 20:10.54 | blast007 | what benefits does it have over a flat file structure? |
| 20:13.42 | JeffM | for bzflag's amount of data, nothing really |
| 20:14.01 | JeffM | for larger file sets you can get compression, faster access, etc... |
| 20:14.18 | JeffM | it can also make it easier to package mods that need asset data |
| 20:14.24 | blast007 | most of what we're storing is already compressed |
| 20:14.31 | JeffM | thats one reaosn why I never did it, the benifits were minimial |
| 20:14.36 | JeffM | yeah |
| 20:15.12 | JeffM | if for instance we had a system where we distributed images WITH the maps, then a package structure like that could make map delivery and transport simpler |
| 20:15.18 | JeffM | but I don't think bzflag needs it |
| 20:15.43 | JeffM | I'd just do a two tierd folder search, search user files, then install files |
| 20:15.58 | JeffM | so that instaling a user file does not remove the install file |
| 20:20.03 | blast007 | at least not yet |
| 20:20.20 | blast007 | I want there to be a better system for managing maps and assets |
| 20:20.33 | blast007 | I just don't know what that should look like |
| 20:20.45 | JeffM | yeah there are several ways to do it these days |
| 20:20.56 | blast007 | dunno if it should be basically (or literally) a Git repo per map 'project', or what |
| 20:21.01 | JeffM | a pack file works if you have a lot of out of band/manual file management |
| 20:21.19 | JeffM | but in this modern internet age, it should be all automagic/cloud boused |
| 20:21.33 | JeffM | yeah, there are many ways to make it work |
| 20:28.38 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 21:01.38 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 21:01.53 | JeffM | GIt doesn't really support externals does it? |
| 21:02.35 | *** join/#bzflag zaa (~lewalters@192.112.102.252) |
| 21:14.41 | blast007 | JeffM: meaning what? pulling in another git repository? |
| 21:14.47 | blast007 | https://git-scm.com/book/en/v2/Git-Tools-Submodules |
| 21:15.07 | JeffM | yeah |
| 21:15.28 | JeffM | I like the idea of making people pubilish repos for maps and assets and stuff, but you'd want an easy way to share them |
| 21:15.42 | JeffM | in subversion I'd just do externals to the other repos that I needed |
| 21:16.03 | JeffM | so my repo looks complete, but doesn't have to dupe the data |
| 21:16.04 | blast007 | I was thinking something where a central site would clone their repo |
| 21:16.54 | blast007 | throw a webhook onto the github repo so the asset site knows when changes have been pushed |
| 21:19.13 | JeffM | ahh |
| 21:19.25 | JeffM | so an aggrigator |
| 21:19.42 | JeffM | that makes sense so that there would be a single place to do stuff |
| 21:20.08 | JeffM | I defentaly think that a VCS as a backend for an asset managment system makes sense. |
| 22:16.56 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 22:16.56 | *** mode/#bzflag [+v trepan] by ChanServ |
| 22:26.04 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 22:43.02 | *** part/#bzflag zaa (~lewalters@192.112.102.252) |
| 22:44.42 | blast007 | does someone want to make a documentation page that covers some of the common words or phrases that are used in BZFlag? Stuff like "tk" or "flag running" |
| 22:47.18 | blast007 | and when documenting the syntax of a command, how would I show that something is a literal instead of a placeholder? |
| 22:47.31 | blast007 | Like for the flag command: /flag <up | show | reset (all | unused |team | B* | R* | G* | P*) [noteam] | take (slot# | player name) | give (slot# | player name) (FlagAbbv)> |
| 22:47.47 | blast007 | there, [noteam] is an optional literal |
| 22:48.05 | blast007 | is it enough to just mention that in that description of the command? |
| 22:49.38 | blast007 | hmm, and perhaps I should also split the flag command syntax up into separate lines from the start.. it seem to wrap to three lines of text in the resulting HTML :) |
| 22:56.30 | allejo | i'll start writing docs on API events (be using/modifying data from my plugin generator) and then API functions |