| 00:31.22 | *** join/#bzflag mtnbkr (~mtnbkr@unaffiliated/mtnbkr) |
| 01:36.48 | allejo | Patlabor221, you there? |
| 01:37.07 | Patlabor221 | I am |
| 01:38.05 | allejo | did you see my question last night concerning relative paths in config files? |
| 01:38.07 | *** join/#bzflag alalalala (ba96827f@gateway/web/cgi-irc/kiwiirc.com/ip.186.150.130.127) |
| 01:38.13 | Patlabor221 | nope |
| 01:39.41 | allejo | i think, relative paths in config files are treated relative to where the command is being executed instead of being relative to the actual file |
| 01:40.21 | Patlabor221 | probably |
| 01:40.43 | allejo | shouldn't it be relative to the file? |
| 01:40.54 | Patlabor221 | it's whatever we define it to be |
| 01:40.59 | allejo | it'd make more sense that way, wouldn't it? at least in a *nix environment |
| 01:41.11 | Patlabor221 | depends on what your intent is |
| 01:41.25 | Patlabor221 | I'd think I'd want it to be consistent |
| 01:41.28 | Patlabor221 | relative to the application |
| 01:41.45 | Patlabor221 | why are configs reading other files anyway? |
| 01:41.52 | Patlabor221 | like maps? |
| 01:42.11 | allejo | group perms, bans, etc. |
| 01:42.19 | allejo | or if you want to have one "master" config |
| 01:42.35 | Patlabor221 | I could see reasons for wanting it ether way |
| 01:43.04 | Patlabor221 | but my guess is we just don't set the working dir, so it's up to the person calling the command line argument |
| 01:43.10 | allejo | what reason would there be for it to be relative to the working directory? |
| 01:43.14 | Patlabor221 | then you can have it ether way by CD to the dir you want |
| 01:43.16 | allejo | ah |
| 01:43.34 | Patlabor221 | because I may have a constant library of bans/maps or whatever that I want to use in multiple configs |
| 01:43.47 | Patlabor221 | and I don't want to care where the config is |
| 01:44.19 | Patlabor221 | like I may have a hosting service that starts configs from user dirs, but always includes a static library of maps, and always includes a ban file |
| 01:44.27 | Patlabor221 | but I don't want full paths in each per user config |
| 01:44.55 | _slime | i will buy 5 Gbps next week :) |
| 01:45.21 | *** mode/#bzflag [+o Patlabor221] by ChanServ |
| 01:45.29 | *** mode/#bzflag [+b *!*@gateway/web/cgi-irc/kiwiirc.com/ip.186.150.130.127] by Patlabor221 |
| 01:45.29 | *** kick/#bzflag [_slime!~JeffM@unaffiliated/jeffm2501] by Patlabor221 (_slime) |
| 01:46.26 | *** mode/#bzflag [+b *!*@gateway/web/cgi-irc/kiwiirc.com*] by Patlabor221 |
| 01:46.35 | *** mode/#bzflag [-b *!*@gateway/web/cgi-irc/kiwiirc.com/ip.186.150.130.127] by Patlabor221 |
| 01:47.36 | Patlabor221 | allejo, so I can see methods for ether way |
| 01:47.43 | Patlabor221 | part of me kinda likes it not being set |
| 01:47.51 | Patlabor221 | but it needs to be documented that it Isn't set |
| 01:48.44 | allejo | what do you mean? |
| 01:48.55 | allejo | like with your examples |
| 01:50.05 | allejo | oh hey look. so the script kiddie is wasting his money |
| 01:50.07 | allejo | good to know |
| 01:50.33 | allejo | but if it's a static library of maps, it'd always be a full path to it, wouldn't it? |
| 01:52.12 | Patlabor221 | 1) I may show the config to users and not want them to see a full path, 2) I may reserve the right to move my library at any time and only have to update my start shell script once |
| 01:52.25 | Patlabor221 | we dont' know what the end user is going to do |
| 01:55.27 | allejo | so the starts cript would always have to be at a specific location |
| 01:55.29 | allejo | ? |
| 01:55.38 | Patlabor221 | no it could change the working dir |
| 01:55.41 | Patlabor221 | CWD |
| 01:56.14 | allejo | ohh |
| 01:56.37 | allejo | actually changed the working dir in a script would fix my problem |
| 01:56.40 | allejo | changing* |
| 01:56.45 | allejo | thanks for the idea :D |
| 01:57.07 | allejo | but yea, bzfs'll remain relative to the cwd? |
| 02:01.27 | Patlabor221 | I think that's best unless someone can come up with a strong case for something else |
| 02:01.41 | Patlabor221 | if it was any dir I'd be more included to do the exe dir |
| 02:01.57 | Patlabor221 | the config is just ONE of the files we can pass into bzfs, why is it's folder special? |
| 02:02.11 | Patlabor221 | why not be relative to the map if the map isn't in the config? |
| 02:02.19 | Patlabor221 | or the ban list, etc... |
| 02:02.55 | allejo | well I meant just relative to whatever file is being read but alright |
| 02:03.09 | Patlabor221 | that's harder |
| 02:03.18 | allejo | and the config file is the only file that really accesses other files. maps can't set -conf |
| 02:03.20 | allejo | ah |
| 02:03.22 | Patlabor221 | what if a file isn't being read? |
| 02:03.30 | Patlabor221 | anything in the config can go into the command line? |
| 02:03.34 | allejo | like it's not found? |
| 02:04.00 | Patlabor221 | the config is just a shortcut to calling a bunch of stuff in the command line |
| 02:04.04 | Patlabor221 | it has no special status |
| 02:04.18 | Patlabor221 | can't maps reference other files with an include? |
| 02:04.25 | Patlabor221 | I thought that was added |
| 02:04.42 | Patlabor221 | and plugins can take there own configs, and read in files too |
| 02:05.02 | Patlabor221 | it's just really common for -conf to be the only file passed in, but it's not a hard requirment that it's the only one |
| 02:06.23 | allejo | oh no, you're right. maps can include other map files |
| 02:06.44 | Patlabor221 | so yeah |
| 02:06.51 | Patlabor221 | it's probably best to leave the dir choice external |
| 02:07.06 | allejo | fair enough |
| 02:07.25 | Patlabor221 | if we always looked for a config file or it was special in some way I could see using another convention |
| 02:07.33 | Patlabor221 | but it's just a conenience thing |
| 02:07.45 | Patlabor221 | and it works around a limitation of windows XP :) |
| 02:07.52 | Patlabor221 | 512 characters in the command line |
| 02:08.58 | allejo | oh windows |
| 02:09.02 | allejo | lol |
| 02:09.15 | Patlabor221 | yup |
| 02:09.20 | Patlabor221 | not that anyone hosts on windows |
| 02:09.40 | allejo | but it's supported, so might as well |
| 02:09.57 | *** join/#bzflag _slime (4d5c4441@gateway/web/freenode/ip.77.92.68.65) |
| 02:10.11 | allejo | aw he's so cute ^ |
| 02:10.18 | allejo | can I keep him vegeta?! |
| 02:10.35 | *** mode/#bzflag [+b *!*4d5c4441@*.77.92.68.65] by Patlabor221 |
| 02:10.35 | *** kick/#bzflag [_slime!~JeffM@unaffiliated/jeffm2501] by Patlabor221 (_slime) |
| 02:11.15 | *** mode/#bzflag [+b *!*@gateway/web/freenode/*] by Patlabor221 |
| 02:11.19 | allejo | awww i brokeded him, vegeta. must have been made out of something weak |
| 02:11.27 | Patlabor221 | we don't need any of that here |
| 02:11.43 | *** mode/#bzflag [-b *!*4d5c4441@*.77.92.68.65] by Patlabor221 |
| 02:12.08 | allejo | well i kinda figured you'd be quick to the ban hammer |
| 02:12.20 | Patlabor221 | that's a hard one to keep in place |
| 02:12.45 | Patlabor221 | but I can't remember how to set +q |
| 02:13.43 | allejo | same as +b except you rotate the b 180 degrees counter clockwise |
| 02:14.25 | Patlabor221 | I use /ban I forget the orther format |
| 02:14.52 | Patlabor221 | /mode doesn't seem to do anything |
| 02:15.25 | allejo | /mode #bzflag +q *!*@* |
| 02:15.34 | Patlabor221 | yeah did that, nope |
| 02:15.49 | Patlabor221 | /mode #bzflag +q *!*@gateway/web/freenode/* |
| 02:17.03 | allejo | huh |
| 02:26.55 | *** join/#bzflag manjaro (~chatzilla@186.150.130.127) |
| 02:26.55 | manjaro | BZFLAG IS DANGEROUS!!! Public Players's Ip List here -> http://pastebin.com/kbsN04iw (click now, part #1) FUCK YOU JEFFM!! 8====D FUCK YOU |
| 02:26.55 | manjaro | BZFLAG IS DANGEROUS!!! Public Players's Ip List here -> http://pastebin.com/kbsN04iw (click now, part #1) FUCK YOU JEFFM!! 8====D FUCK YOU |
| 02:27.00 | manjaro | BZFLAG IS DANGEROUS!!! Public Players's Ip List here -> http://pastebin.com/kbsN04iw (click now, part #1) FUCK YOU JEFFM!! 8====D FUCK YOU |
| 02:27.04 | manjaro | FUCK YOU |
| 02:27.06 | manjaro | BZFLAG IS DANGEROUS!!! Public Players's Ip List here -> http://pastebin.com/kbsN04iw (click now, part #1) FUCK YOU JEFFM!! 8====D FUCK YOU |
| 02:27.19 | manjaro | BZFLAG IS DANGEROUS!!! Public Players's Ip List here -> http://pastebin.com/kbsN04iw (click now, part #1) FUCK YOU JEFFM!! 8====D FUCK YOU |
| 02:27.22 | manjaro | BZFLAG IS DANGEROUS!!! Public Players's Ip List here -> http://pastebin.com/kbsN04iw (click now, part #1) FUCK YOU JEFFM!! 8====D FUCK YOU |
| 02:27.26 | manjaro | FUCK YOU JEFFM |
| 02:27.28 | manjaro | BZFLAG IS DANGEROUS!!! Public Players's Ip List here -> http://pastebin.com/kbsN04iw (click now, part #1) FUCK YOU JEFFM!! 8====D FUCK YOU |
| 02:28.04 | allejo | sacrebleu |
| 02:28.13 | *** mode/#bzflag [+b *!*chatzilla@186.150.130.127] by Patlabor221 |
| 02:28.13 | *** kick/#bzflag [manjaro!~JeffM@unaffiliated/jeffm2501] by Patlabor221 (manjaro) |
| 02:28.29 | allejo | wanna just ban his IP? |
| 02:28.42 | allejo | *!*@*186... |
| 02:28.53 | *** mode/#bzflag [+b *!*@186*] by Patlabor221 |
| 02:29.00 | *** mode/#bzflag [+o allejo] by Patlabor221 |
| 02:29.06 | Patlabor221 | I'm at work, don't go mad with power ;) |
| 02:29.25 | allejo | uhm I didn't mean the entire range. was just lazy to type the entire ip... lol |
| 02:29.42 | Patlabor221 | pff |
| 02:29.50 | Patlabor221 | class A, class C what's the diff? |
| 02:29.56 | *** mode/#bzflag [+b *!*@*186.150.130.*] by allejo |
| 02:30.03 | allejo | no difference at all :p |
| 02:30.14 | *** mode/#bzflag [-b *!*@186*] by allejo |
| 02:30.18 | Patlabor221 | thanks |
| 02:30.20 | allejo | mhmm |
| 02:30.58 | *** mode/#bzflag [-b *!*chatzilla@186.150.130.127] by allejo |
| 02:33.05 | Patlabor221 | well I guess they did cover them class A things in Net&Com |
| 03:00.37 | TD-Linux | by the way if anyone has related logs to that user let me know |
| 03:00.56 | TD-Linux | (in private obviously) |
| 03:07.25 | kierra | there are logs aplenty |
| 03:23.20 | *** join/#bzflag bzbugsy (bzbugsy@unaffiliated/bzbugsy) |
| 03:50.55 | Flash | it feels like I'm being personally DDoS'd right now |
| 03:57.48 | allejo | you might be |
| 04:05.28 | kierra | dont anyone click on any of his links |
| 04:05.42 | kierra | they're ip tracking links....gets your ip |
| 04:19.21 | *** join/#bzflag Flash (~flash@bzflag/developer/Flash) |
| 04:19.40 | Flash | jerk |
| 04:20.01 | kierra | mhmm....royally |
| 04:20.33 | Flash | comcast says they can do nothing |
| 04:23.28 | Flash | first level techs are worthless |
| 04:23.38 | Flash | moving on to the security department (finally) |
| 04:24.23 | blast007 | it's comcastic! |
| 04:43.51 | *** join/#bzflag Patlabor221 (uid48618@gateway/web/irccloud.com/x-uhfutnspkteqbjgs) |
| 04:43.51 | *** mode/#bzflag [+v Patlabor221] by ChanServ |
| 05:30.46 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 07:08.50 | Flash | list server still down? |
| 07:09.25 | Patlabor221 | update your DNS |
| 07:13.39 | blast007 | and "still" meaning what? |
| 07:14.13 | allejo | i think the correct wording is that it's relatively slow |
| 07:15.07 | Flash | last time I looked (which was quite a while ago) it was "down". I see no servers listed. |
| 07:15.33 | blast007 | Flash: check your hosts file for a hard-coded entry for my.bzflag.org and remove it if you find one |
| 07:16.12 | Flash | nope |
| 07:16.23 | blast007 | when you ping it, what IP does it show? |
| 07:16.48 | Flash | 192.169.83.30 |
| 07:16.55 | Patlabor221 | works fine and is quick for me |
| 07:16.59 | blast007 | okay, that's right |
| 07:17.55 | allejo | back to normal speed for me |
| 07:18.45 | Flash | hmmm. I'm seeing no servers |
| 07:19.04 | Patlabor221 | what version are you connecting with? |
| 07:19.24 | Flash | 2.4.2 |
| 07:20.06 | Flash | ok, the log jam finally broke |
| 07:41.34 | *** join/#bzflag Flash (~flash@bzflag/developer/Flash) |
| 08:30.19 | *** join/#bzflag DTRemenak (~DTRemenak@cpe-76-90-127-238.socal.res.rr.com) |
| 08:30.19 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 08:30.19 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 09:46.49 | Flash | so ... traceroute to list server is stuck ... |
| 09:46.59 | Flash | https://gist.github.com/jwmelto/83c46762414f579d8787 |
| 12:47.29 | *** join/#bzflag MonsieurApple (~MonsieurA@unaffiliated/mrapple) |
| 14:25.29 | kierra | i'm not seeing servers either and i cleared cache in options |
| 14:26.03 | alezakos | and your hosts file is clear too? |
| 14:26.57 | kierra | oh, its slow |
| 14:27.01 | kierra | geez |
| 15:19.23 | *** join/#bzflag mtnbkr (~mtnbkr@unaffiliated/mtnbkr) |
| 16:38.12 | *** join/#bzflag Bhoren (~quassel@2a01:e35:2eb9:21:91f:61c2:ab1f:e7b6) |
| 16:49.17 | *** join/#bzflag leemar (~leemar@c-50-189-137-96.hsd1.ct.comcast.net) |
| 16:49.56 | blast007 | just made some change that may cause a bit of an outage but will hopefully work better after it propagates |
| 16:50.20 | leemar | hello, I recently switched from KDE/kwin to Xfce/lightdm and my FPS has dropped to ~9..... I've tried turning on composting and no change-- even after reboot. How can I tell if bzflag correctly compiled with opengl? |
| 16:50.38 | leemar | waves @ mtnbkr |
| 16:51.43 | blast007 | it wouldn't be anything to do with how BZFlag was built |
| 16:52.09 | blast007 | what does the 'renderer' line show in the glxinfo command? |
| 16:53.26 | leemar | blast007: OpenGL renderer string: Gallium 0.4 on AMD CEDAR |
| 16:53.55 | leemar | glxgears always shows ~60 FPS, which is where I believe I should be |
| 16:54.00 | mtnbkr | waves back @ leemar welcome to #bzflag |
| 16:54.36 | blast007 | glxgears is quite worthless for checking for acceleration these days as even software rendering on modern CPUs can push out hundreds of FPS |
| 16:54.41 | leemar | I thought I acquired all the needed source packages when I compiled.... |
| 16:55.32 | blast007 | does the renderer string that shows up in the chat box of BZFlag when you start the game also match that string? |
| 16:56.01 | leemar | blast007: yes, it says the same line when starting up |
| 16:56.30 | blast007 | do you still have KDE on that system? |
| 16:56.58 | leemar | blast007: yes, I suppose I can just re-install kwin |
| 16:57.29 | blast007 | I'd just be curious if it is busted on KDE now too or if it really is specific to Xfce/lightdm |
| 16:59.10 | mtnbkr | I'm running bzflag here on Gentoo with Xfce4 even full screen 1920x1080 output is smoth |
| 16:59.14 | mtnbkr | smooth even |
| 16:59.43 | mtnbkr | blast007: in game, pressing "t" shows fps: 60 for me just above the sights |
| 17:00.23 | mtnbkr | a steady 60 |
| 17:00.42 | blast007 | yeah, because you have vsync turned on |
| 17:01.13 | leemar | iok, switching back to KDE/kdm-- standby... |
| 17:01.23 | blast007 | (which isn't a bad thing - our physics gets a bit weird with high FPS) |
| 17:01.34 | mtnbkr | blast007: wanted to say thanks for helping me get that straightened out the other day... I have noticed some strage desktop "artifacts" outside of bzflag though... xfce panel buttons not drawing until I mouse over them etc. :) |
| 17:10.48 | leemar | blast007: under KDE/kdm I'm still getting ~ 9/10 FPS |
| 17:11.34 | blast007 | any other games you can try? |
| 17:11.51 | leemar | any suggestion? |
| 17:12.04 | leemar | I really don't play other games... sometimes Xbill :P |
| 17:13.00 | leemar | blast007: do you think it can be related to they way I compiled bzflag? |
| 17:13.03 | blast007 | Xonotic or Nexuiz |
| 17:13.46 | blast007 | unlikely to be how you compiled it. it's not like we have a "don't build with OpenGL option" short of not actually building the client |
| 17:13.50 | leemar | is installing Nexuiz |
| 17:14.20 | mtnbkr | xBill!! :) |
| 17:17.32 | blast007 | mtnbkr: that wouldn't really test OpenGL ;) |
| 17:18.03 | leemar | ok, Nexuiz runs very smoothly-- how can I determine FPS |
| 17:19.48 | mtnbkr | blast007: re: xbill I was chuckling because leemar said that was the only other game he really played. :) |
| 17:23.03 | blast007 | not sure how to display FPS in Nexuiz |
| 17:34.55 | leemar | blast007: I'm getting 56-78 FPS in Nexuiz |
| 17:35.06 | leemar | very smooth and very playable.... |
| 17:36.07 | leemar | can I share any of the compiling information? |
| 17:38.18 | blast007 | sure |
| 17:38.45 | leemar | blast007: awesome, what should I send? |
| 17:38.55 | blast007 | I have no idea ;) |
| 17:39.33 | blast007 | what distribution of linux is this? |
| 17:39.56 | leemar | blast007: Debian stable-- hence why I need to compile the current version... |
| 17:41.18 | blast007 | are you building from our Git repo or just from the 2.4.2 tarball? |
| 17:41.27 | leemar | 2.4.2 tarball |
| 17:42.43 | blast007 | I'd actually recommend building from Git since there are some crash fixes, for instance. Probably won't help with the other issue though. |
| 17:43.01 | blast007 | did you follow the instructions in README.Linux? |
| 17:43.45 | blast007 | ~bzgit |
| 17:43.45 | infobot | hmm... bzgit is git clone --branch v2_4_x https://github.com/BZFlag-Dev/bzflag-import-3.git bzflag |
| 17:46.18 | *** join/#bzflag Patlabor221 (~JeffM@107-209-61-107.lightspeed.irvnca.sbcglobal.net) |
| 17:46.18 | *** join/#bzflag Patlabor221 (~JeffM@unaffiliated/jeffm2501) |
| 17:46.18 | *** mode/#bzflag [+v Patlabor221] by ChanServ |
| 17:54.03 | leemar | blast007: yes, I did read and follow the README.Linux |
| 17:57.05 | *** join/#bzflag Bhoren (~quassel@2a01:e35:2eb9:21:91f:61c2:ab1f:e7b6) |
| 17:57.49 | blast007 | does the version of 2.0.16 in the debian repos also run slow? |
| 17:58.11 | leemar | blast007: I don't think it does, but no one runs 2.0 servers! |
| 17:58.43 | mtnbkr | yeah, 2.0.x is not even in the gentoo portage tree anymore |
| 17:59.45 | blast007 | run a local server to test (just 'bzfs' and join localhost port 5154) |
| 18:15.27 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 18:35.55 | *** join/#bzflag infobot (ibot@rikers.org) |
| 18:35.55 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 Current version http://goo.gl/PI9KFD |
| 18:35.55 | *** mode/#bzflag [+v infobot] by ChanServ |
| 19:05.54 | *** join/#bzflag dngor_ (~abuse@73.179.11.69) |
| 19:07.45 | *** join/#bzflag Cobra_Fast_ (~coprah@wtwrp.de) |
| 19:43.15 | mtnbkr | arg... wiki.bzflag.org is down |
| 19:43.54 | mtnbkr | well, dns does not resolve anyway |
| 19:46.36 | BulletCatcher | Some of the BZFlag DNS records were changed earlier today. |
| 19:46.40 | BulletCatcher | The new settings are working now for me. |
| 19:48.15 | BulletCatcher | TTL values are less than 1 hour, but your browser may have cached an old value. |
| 20:24.22 | blast007 | I changed nameservers completely |
| 20:48.39 | mtnbkr | BulletCatcher: Oh Ok... thanks for that info |
| 20:50.18 | blast007 | could technically take 24 to 48 hours to be fully functional again |
| 20:51.51 | mtnbkr | should have lowered the TTLs to a few mins a few days b4 the migrations |
| 20:52.04 | mtnbkr | mitigates any percieved outages |
| 21:05.28 | blast007 | I can't... |
| 21:05.41 | blast007 | I changed *nameservers*, not records I directly control :) |
| 21:06.18 | blast007 | no IPs on A records changed. I simply switched from namecheap's V1 nameservers to their V2 nameservers |
| 21:07.19 | mtnbkr | there are TTLs on NS records too ;) |
| 21:10.38 | blast007 | my statement still holds true... |
| 21:12.33 | mtnbkr | Ahh, I see now. So you could not tell the people managing the bzflag.com domain to lower the TTL on the NS record(s) for the domain |
| 21:13.36 | mtnbkr | leemar: any luck re: frame rates?? |
| 21:13.42 | blast007 | it was the bzexcess.com domain |
| 21:16.54 | blast007 | leemar: which specific AMD GPU do you have? |
| 21:20.34 | blast007 | cuz now that I think about it, 60 to 80 FPS in Nexuiz seems rather low for a Radeon HD 5000 series |
| 21:37.04 | Patlabor221 | vsync |
| 21:40.39 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 21:49.39 | blast007 | didn't sound like vsync since it was "56-78 FPS", but perhaps it was enabled |
| 21:50.08 | blast007 | they're only getting 9 FPS in BZFlag |
| 21:50.25 | Patlabor221 | set the texture mode to nearest |
| 21:50.37 | Patlabor221 | and turn of "blending" |
| 21:58.46 | leemar | blast007: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450/6350] |
| 22:00.15 | leemar | Patlabor221: changes made, no change |
| 22:09.38 | Patlabor221 | I'd play with other modes then, some ATI drivers don't like our old GL 1.1 settings |
| 22:10.32 | leemar | yeah, I've tried tuning everything down... I think it has something to do with the way I compiled it..... |
| 22:12.18 | Patlabor221 | did you use SDL or native X windows? |
| 22:12.23 | blast007 | like I said, compare it with the debian provided 2.0.16 |
| 22:12.56 | Patlabor221 | that would be a good test |
| 22:13.11 | Patlabor221 | the drawing code in bzflag hasn't changed much in a decade |
| 22:15.58 | BulletCatcher | On the subject of code changes, I want to use the M_PI macro in plugins/flagStay/flagStay.cpp instead of calculating the value of pi. |
| 22:16.02 | BulletCatcher | That file already has "#include <cmath>", which is sufficient for unix systems, but http://msdn.microsoft.com/en-us/library/4hwaceh6.aspx says that _USE_MATH_DEFINES must first be defined to enable math constants in VS2013. |
| 22:16.22 | BulletCatcher | Can a Windows developer confirm that? |
| 22:16.23 | Patlabor221 | we can put that in the project |
| 22:16.27 | Patlabor221 | yeah you do |
| 22:16.37 | Patlabor221 | too many people #defed there own M_PI |
| 22:17.07 | Patlabor221 | your core problem is, we don't use 2013 for 2.4.x |
| 22:17.16 | Patlabor221 | we use 2010 |
| 22:17.21 | Patlabor221 | and I don't know if it has the math defs |
| 22:17.27 | leemar | Patlabor221: how can I determine if it's using SDL or native X? |
| 22:18.07 | blast007 | leemar: check the version string of your bzflag binary. if it says -SDL, it's using SDL. |
| 22:18.21 | BulletCatcher | Patlabor221, it should be easy enough to #define _USE_MATH_DEFINES and see if the plugin still compiles. |
| 22:19.32 | BulletCatcher | We already do that #define in include/win32.h, but I don't think that gets pulled in to plugins. |
| 22:19.41 | Patlabor221 | it does not |
| 22:19.49 | Patlabor221 | that I know for sure |
| 22:19.51 | BulletCatcher | k |
| 22:20.04 | Patlabor221 | you can do #ifndef |
| 22:20.19 | Patlabor221 | in the API header #ifndef M_PI then define PI |
| 22:20.51 | Patlabor221 | then for 2.6 we can pull that and just add the _USE to the project files |
| 22:21.04 | Patlabor221 | since they use 2013, or higher |
| 22:21.40 | leemar | blast007: how do I check the version string? |
| 22:21.56 | Patlabor221 | leemar, it'll be in the chat window when the game starts |
| 22:22.01 | blast007 | leemar: pass the -version string to the binary or run the game |
| 22:22.06 | BulletCatcher | Ok, I'll make the appropriate changes for both branches. |
| 22:22.10 | blast007 | s/string/option/ |
| 22:22.19 | TD-Linux | leemar, also pasting the output of glxinfo would be nice |
| 22:22.47 | leemar | yes, it ends in -SDL |
| 22:24.07 | leemar | TD-Linux: http://pastebin.com/g74dR2M8 |
| 22:25.09 | TD-Linux | leemar, your mesa version is very old. what distro are you using? |
| 22:25.24 | leemar | Debian GNU/Linux Stable |
| 22:25.27 | leemar | <sigh> |
| 22:25.36 | leemar | hence why I'm compiling by hand |
| 22:25.37 | TD-Linux | that might not be the best idea with a relatively new GPU |
| 22:25.44 | Patlabor221 | blame it on systemd |
| 22:25.55 | TD-Linux | especially when using the mesa drivers |
| 22:26.05 | TD-Linux | mesa is now on 10.3 and has had many improvements |
| 22:26.09 | leemar | does NOT have systemd |
| 22:26.26 | TD-Linux | I might suggest running a modern livecd and seeing if the performance problems go away |
| 22:27.38 | blast007 | leemar: not yet ;) |
| 22:27.48 | blast007 | Debian Jessie will be systemd |
| 22:28.05 | leemar | yeah, I've been following that... :-\ |
| 22:28.25 | *** join/#bzflag stinz (~Lingo@99-99-224-182.lightspeed.hstntx.sbcglobal.net) |
| 22:28.45 | TD-Linux | also that's a really low end card, but it should be able to handle bzflag |
| 22:29.07 | Patlabor221 | bzflag is a low end game |
| 22:30.20 | blast007 | ah, here's a question. leemar, do you have the 'firmware-linux-nonfree' package installed? |
| 22:31.15 | stinz | Is the list server down, or is it just me? |
| 22:31.16 | leemar | blast007: yes |
| 22:31.42 | blast007 | stinz: there's some DNS migration in progress, so it may be down for certain DNS providers |
| 22:32.09 | stinz | Ah, ok. That explains it. I'll change my DNS server temporarily then. Thanks. |
| 22:33.39 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 22:35.38 | leemar | does compile custom kernels... Could there be a kernel setting? |
| 22:36.29 | blast007 | why do you use a custom kernel? |
| 22:36.42 | leemar | I've been making them since the 90s! |
| 22:36.51 | leemar | is using Linux Kernel 3.17.7 |
| 22:36.57 | blast007 | why build though? |
| 22:37.15 | blast007 | debian offers newer kernel versions in the Wheezy Backports repo |
| 22:37.49 | leemar | blast007: I always compile custom for each hardware on servers, desktops and laptops.. |
| 22:37.58 | blast007 | 3.16 is currently in wheezy backports |
| 22:38.14 | blast007 | leemar: that really buys you very little.. |
| 22:39.13 | leemar | blast007: that's your opinion-- why have the kernel stuffed with drivers you'll never use? what about processor optimization? |
| 22:39.20 | blast007 | you're not trying to shove linux onto a tiny embedded system where saving 100KB of RAM or disk is going to make a huge difference, and plus then you have to manage security updates yourself |
| 22:39.53 | Patlabor221 | is somoene trying to run bzflag on a log-splitter again? |
| 22:40.20 | blast007 | no, custom kernel that probably removed something necessary for acceleration |
| 22:40.57 | leemar | blast007: can that be determined from my .configure results? |
| 22:40.59 | Patlabor221 | isn't that what people who build there own kernel want? the slowest possible system? ;) |
| 22:41.10 | Patlabor221 | configure doesn't check to see what your driver needs |
| 22:41.20 | Patlabor221 | the configure of your driver may tell that |
| 22:41.24 | Patlabor221 | but we don't build a driver |
| 22:41.37 | blast007 | leemar: you would have to see if Debian would support your custom kernel. We are not the Debian support channel. |
| 22:41.37 | Patlabor221 | we are abstracted several layers from your kernel and your hardware |
| 22:41.54 | blast007 | but it should be easy enough to try a stock kernel |
| 22:42.34 | blast007 | perhaps your custom kernel isn't using the firmware blobs |
| 22:42.51 | Patlabor221 | that is the part that isn't open source ;) |
| 22:45.13 | blast007 | right. Debian's kernel strips all that out and moves it to a linux-firmware-nonfree package, but perhaps the custom kernel doesn't know to look at that firmware. |
| 22:52.38 | leemar | hmmm, I do see errors when it tried loading 2 blobs related to the AMD video card |
| 23:13.17 | *** join/#bzflag James (ac380f6e@bzflag/contributor/spldart) |
| 23:13.17 | *** mode/#bzflag [+v James] by ChanServ |
| 23:15.23 | *** join/#bzflag khonkhortisan (~Khonkhort@c-24-18-42-215.hsd1.wa.comcast.net) |
| 23:37.27 | *** join/#bzflag jcp (~quassel@bzflag/contributor/javawizard2539) |