| 01:17.07 | *** join/#bzflag infobot (ibot@69-58-80-29.ut.vivintwireless.net) |
| 01:17.07 | *** topic/#bzflag is http://BZFlag.org || http://ohloh.net/p/bzflag || https://wiki.bzflag.org/Getting_Help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.4-RC2 https://goo.gl/KNuYQF |
| 01:17.07 | *** mode/#bzflag [+v infobot] by ChanServ |
| 03:32.00 | *** join/#bzflag meeba (~lamer@c-73-14-146-7.hsd1.co.comcast.net) |
| 03:46.19 | Constitution | I postulate that windows machines are such poor timekeepers that the clock has to be adjusted by ten seconds with every thirty seconds that elapse, and that is the reason for the weird countdown behavior ;) |
| 03:47.23 | blast007 | the odd part is that the game client's countdown keeps time correctly, but not the server |
| 03:47.46 | blast007 | maybe we need to run bzfs on Windows Server ;) |
| 03:49.20 | *** part/#bzflag Nivex (~kjotte@2606:a000:a461:4500::4) |
| 03:49.24 | Constitution | let's do a kickstarter to fund the purchase of a windows server box and OS, and have version 2.4.4 be the deliverable |
| 03:50.13 | Constitution | allejo can add some new API features as stretch goals |
| 04:26.51 | allejo | is in |
| 04:27.06 | the_map | the_map is present |
| 04:54.05 | *** join/#bzflag develCuy (~quassel@unaffiliated/develcuy) |
| 05:37.47 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 06:08.24 | allejo | the_map will see you now |
| 06:31.39 | the_map | allejo: it doesn't look good, so I'll give it to you straight: it looks like you broke a build |
| 06:39.03 | allejo | :'( |
| 06:43.42 | the_map | don't worry, it shouldn't be that hard to fix; you can probably even fix it yourself! |
| 06:43.51 | the_map | just don't break anything else ;) |
| 06:45.20 | allejo | now that consti mentioned it, I kinda do want to add some stuff to the API but i'm waiting for 2.4.4 because I'm bound to break things :p |
| 06:46.25 | allejo | has a list somewhere |
| 10:05.18 | alezakos | I have a list of 23 features to add to 2.6 |
| 10:05.38 | alezakos | I've already implemented 1/4 of a feature! |
| 13:35.23 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 14:12.43 | *** join/#bzflag develCuy (~quassel@unaffiliated/develcuy) |
| 16:18.41 | *** join/#bzflag develCuy (~quassel@unaffiliated/develcuy) |
| 18:47.43 | *** join/#bzflag alpha1-2 (~alpha1@181.90.27.129) |
| 18:51.56 | alpha1-2 | Hi, I am trying to load a new map from ahs3 ("Paradise") and I am changed automatically to default download system (very slow) despite he uses the "-cache" option. I run bzflag with "-debug" option and I got this output: |
| 18:51.57 | alpha1-2 | "File transfer terminated with error from libcurl 7 : Failed to connect to 2600:3c03::f03c:91ff:fe67:c7ab: Network is unreachable |
| 18:51.59 | alpha1-2 | Server BZDB change blocked: 'poll' = '9334736'" |
| 18:52.00 | alpha1-2 | Since both of us are using version 2.4.0, is this maybe a IPV6 compatibility issue between site and our BZ software? |
| 18:52.30 | blast007 | alpha1-2: did you generate the cache file yourself, or are you using one he provided? |
| 18:52.34 | blast007 | and why are you using 2.4.0? |
| 18:54.32 | alpha1-2 | the cache file is provided by his site and I could try other versions, just before it, I'm checking it is not other issue |
| 18:55.13 | allejo | i would think ahs3 is using IPv6? |
| 18:55.33 | alpha1-2 | (I use 2.4.0 since I had some troubles with 2.4.2 I mentioned long time ago) |
| 18:56.35 | blast007 | you should make your own cache file |
| 18:56.42 | alpha1-2 | don't know, the debug output says it, tho |
| 18:56.49 | blast007 | or just use the fastmap plugin which makes one and serves it automatically |
| 18:57.18 | blast007 | you should not run 2.4.0 or even 2.4.2 for a server |
| 18:57.25 | blast007 | you should be running the latest git version |
| 18:57.39 | alpha1-2 | ah, yes, as a server |
| 18:57.55 | blast007 | unless you don't mind your server crashing or having admin password bypassing issues |
| 18:58.16 | allejo | I still run 2.0.17 |
| 18:58.23 | alpha1-2 | yuo are talking of ahs3 right? |
| 18:59.03 | blast007 | I am talking about you, who is running the server |
| 18:59.09 | allejo | it's ahs3's server |
| 18:59.18 | alpha1-2 | then I suposse 2.4.0 client doesn't support IPV6? |
| 18:59.31 | allejo | bz as a whole doesn't support IPv6 |
| 18:59.32 | blast007 | BZFlag doesn't support IPv6 at all, but libcurl does |
| 19:00.12 | alpha1-2 | ah yes, ahs3 is hosting the map, maybe that was not clear enough |
| 19:00.44 | blast007 | I didn't read closely enough |
| 19:00.47 | alpha1-2 | it is a beta map, but I have still troubles with other servers from him |
| 19:00.53 | blast007 | he should definitely upgrade to the latest git code, though |
| 19:01.13 | blast007 | and you should try the latest git code as well and report any issues you find so we can FIX them |
| 19:01.20 | allejo | i don't know what you're talking about alpha1-2, his server was built 20151114 and it's 2.4.3 |
| 19:01.30 | allejo | it's not the latest RC but it's definitely not 2.4.0 |
| 19:01.30 | blast007 | otherwise you'll be left in the dark when we start enforcing HTTPS |
| 19:01.46 | alpha1-2 | it is weird, because "-cache" option in Animal Lover's servers works fine for me |
| 19:02.02 | blast007 | it works fine if you actually generate a valid cache file :P |
| 19:02.23 | blast007 | if you change the map (and possibly the settings) you have to create an updated cache file |
| 19:02.39 | alpha1-2 | oh, as it takes 5 minutes to download, I used strayers info |
| 19:02.43 | blast007 | but there's really no point in doing it manually unless you're going to host the cache file on a different server |
| 19:02.47 | allejo | and the server has an uptime of at least 1 day and I connected fine with the cached file |
| 19:02.57 | blast007 | allejo: it didn't for me |
| 19:03.09 | allejo | paradise? |
| 19:03.11 | blast007 | it loaded the cache file and then redownloaded it over the slower in-protocol method |
| 19:03.23 | blast007 | whichever one was at the top of the list yesterday |
| 19:03.40 | allejo | i just connected right now |
| 19:04.14 | blast007 | regardless, the fastmap plugin is what all the cool kids do |
| 19:04.42 | allejo | not unless you use drawinfo :p |
| 19:04.47 | alpha1-2 | animal lover told me that she tried that pluing and had troubles and went to -cache method |
| 19:04.53 | alpha1-2 | plugin |
| 19:05.09 | alpha1-2 | I don't know details tho |
| 19:05.12 | allejo | mofo had problems with fastmap as well |
| 19:05.31 | blast007 | had or has? |
| 19:05.47 | blast007 | if you're still having problems, we should try to fix it :P |
| 19:05.59 | blast007 | again, with the latest code |
| 19:06.15 | allejo | i don't how to reproduce the issue though |
| 19:06.22 | alpha1-2 | blast007: you are talking of generating the cache file, but it is not my intention to host the map, just to join his server fastly and play |
| 19:06.40 | allejo | and don't want to necessarily cause a crash on the live server |
| 19:07.31 | alpha1-2 | why do you use 2.0.17 allejo still or it was a joke? |
| 19:07.34 | blast007 | allejo: I was thinking the issue before what that it didn't generate (or send) the file correctly, so it did the double download things (once from fastmap, then the old in-protocol method) |
| 19:07.38 | blast007 | was a joke |
| 19:07.41 | alpha1-2 | ah |
| 19:08.06 | blast007 | allejo: if so, that's easy enough to duplicate on a copy of the server files on a different port |
| 19:08.42 | allejo | what i do remember was that mofo would run fine for a while and then it'd hang |
| 19:09.16 | allejo | maybe Delusional remembers more than I do |
| 19:12.09 | alpha1-2 | then, if I understand well (apart of having to try the latest version), the difference between animal lover's servers and ahs3's ones (ones working well for me and the others not) is that the first ones are hosted using IPV4 and the second ones IPV6? |
| 19:12.37 | alpha1-2 | (the cache files) |
| 19:12.41 | alpha1-2 | cached* |
| 19:14.00 | alpha1-2 | I know that ahs3's new server is new and AL's one has some time running, then it's possible |
| 19:15.09 | alpha1-2 | well, in the meantime, I will start downloading latest version (weird that strayers says 2.4.0 also) |
| 19:16.25 | alpha1-2 | BTW, I think I am a good tester :) |
| 19:22.58 | blast007 | there is 3 2.4.0 servers, 1 2.4.1, 3 2.4.2, 31 2.4.3 from last year, 69 2.4.3 from this year, 23 2.4.4RC1, and 12 2.4.4RC2 (plus 1 on 2.0.16 and 2 on 2.0.17) |
| 19:25.01 | alpha1-2 | should servers owners be trying RCs also? would it not be a security risk? |
| 19:25.21 | blast007 | yes, they should be trying the RC as well |
| 19:25.42 | blast007 | the current git has *fewer* issues than the 2.4.0 or 2.4.2 |
| 19:25.47 | alpha1-2 | ah, yes, they are the latest versions also |
| 19:26.06 | alpha1-2 | always the safest |
| 19:27.15 | alpha1-2 | and is it planned a no reverse compatibility step? |
| 19:27.24 | alpha1-2 | soon* |
| 19:27.33 | blast007 | And 2.4.4 is almost ready to ship. We're just looking into some crash bugs (specifically "crash on exit") and maybe an odd timing issue on the Windows bzfs. |
| 19:27.44 | blast007 | 2.4.4 is compatible with 2.4.x |
| 19:27.58 | alpha1-2 | and force HTTPS? |
| 19:28.05 | blast007 | the first two numbers indicate compatibility |
| 19:28.13 | allejo | i'm using a mix between 2.4.3 and RC1. haven't restarted any of servers to use RC2 |
| 19:28.17 | blast007 | (except when the second number is odd) |
| 19:29.15 | alpha1-2 | would not forcing HTTPS be a no reverse compativility? |
| 19:29.26 | blast007 | we're not forcing it yet |
| 19:29.38 | alpha1-2 | ah okay |
| 19:29.40 | blast007 | 2.4.4 *supports* HTTPS, where previous versions did not |
| 19:29.45 | alpha1-2 | nice |
| 19:30.11 | blast007 | so we want to get everyone running at least 2.4.4 so that later (say, after one or two releases of 2.6) we can enforce HTTPS on our web server |
| 19:30.53 | alpha1-2 | yes, seems good |
| 19:31.13 | allejo | protobreaks! |
| 19:31.19 | allejo | imma break far more than just the protocol |
| 19:31.24 | alpha1-2 | I didn't understand the odd number situation, tho |
| 19:32.02 | blast007 | alpha1-2: in x.y.z for our version, the y is odd during a major development version (such as between 2.4 and 2.6) |
| 19:32.04 | alpha1-2 | I hae heard that odd numbers are not for shipping, but for developing, but nothing to do with reverse compatibility |
| 19:32.06 | alpha1-2 | have |
| 19:32.25 | alpha1-2 | (IIRC) |
| 19:32.38 | allejo | 2.5.1 |
| 19:32.46 | blast007 | so 2.5.1 may not be compatible with 2.5.2, since we might have bumped the protocol to fix/change/improve something |
| 19:33.24 | alpha1-2 | ah, an intermediate version before the new one, breaking protocols |
| 19:33.25 | blast007 | but when the second number is even, it means that our protocol (and gameplay) are not going to be changing within that set of revisions |
| 19:33.35 | allejo | hmm actually would 2.5.2 be a release for 2.5.x even though 2.5.x is the dev version for 2.6.x? |
| 19:33.48 | blast007 | so 2.4.0 is compatible with 2.4.1, 2.4.2, 2.4.128, etc |
| 19:34.12 | blast007 | allejo: no, there are no 'releases' for a major dev release |
| 19:34.27 | blast007 | only x.even.even is a true release |
| 19:35.09 | blast007 | for a major dev branch* |
| 19:35.14 | alpha1-2 | an intermediary *family* of versions |
| 19:35.35 | alpha1-2 | intermediate* |
| 19:35.49 | alpha1-2 | I think I got it |
| 19:36.04 | alpha1-2 | linux uses it too I think |
| 19:36.13 | alpha1-2 | what I have heard |
| 19:36.21 | alpha1-2 | ad free soft in general |
| 19:36.23 | alpha1-2 | and |
| 19:40.04 | allejo | what justifies a bump from 2.5.1 to 2.5.2 |
| 19:42.21 | alpha1-2 | I think that progress in developing (goals reached). Maybe not necessary, tho |
| 19:43.27 | alpha1-2 | it is not meant to be shiped, take this in mind |
| 19:43.34 | alpha1-2 | keep* |
| 19:43.41 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 19:43.57 | alpha1-2 | only for developers (I am talking if I was one of them :P) |
| 19:46.05 | alpha1-2 | (I only ask that don't force me to update my OS to compile this new version...) |
| 19:47.25 | alpha1-2 | now asking for c-ares, wow I think I have to update my libcurl4 version, BTW :P |
| 19:47.54 | alpha1-2 | 3 years old |
| 19:52.15 | alpha1-2 | uh oh not c-ares in my repository... it is no into the new libcurl right? |
| 19:53.32 | alpha1-2 | oh yes sorry |
| 19:53.35 | alpha1-2 | :X |
| 19:53.35 | allejo | i think the 'cares' package is different |
| 19:53.54 | alpha1-2 | yes libcares2 |
| 19:54.07 | alpha1-2 | was searching c-ares |
| 19:58.20 | alpha1-2 | (compiling now... watchstop running) |
| 19:58.28 | alpha1-2 | stopwatch* |
| 20:09.13 | alpha1-2 | done, 10 minutes, 15 seconds :) What is your timing compiling? |
| 20:10.09 | allejo | ~1 week |
| 20:11.47 | alpha1-2 | weird: 2.4.0 tar - 15.6 MiB, while 2.4.4RC2 zip - 14 MiB |
| 20:12.36 | allejo | not really |
| 20:12.45 | alpha1-2 | but your timing in every compilation, like I did? |
| 20:12.48 | allejo | the /src/other/ folder was removed |
| 20:13.03 | allejo | yea i time it. ~1 week to compile |
| 20:13.51 | alpha1-2 | I don't understand. I mean from you start the "make" command until it ends |
| 20:14.11 | allejo | yea. ~1 week |
| 20:14.18 | alpha1-2 | can you explain it? |
| 20:14.35 | alpha1-2 | are you debugging? |
| 20:15.11 | allejo | don't know, it just takes that long |
| 20:15.25 | allejo | might explain why it takes me a long time to commit things |
| 20:15.30 | alpha1-2 | you are joking |
| 20:16.03 | allejo | nah, I compile on a Pi |
| 20:16.10 | alpha1-2 | hehe |
| 20:16.22 | alpha1-2 | and in your Mac one? |
| 20:16.36 | alpha1-2 | or Apple one |
| 20:18.24 | alpha1-2 | wow yes src/other: 29.7 MiB |
| 20:20.01 | alpha1-2 | should I run RC2 always in debug mode? |
| 20:22.01 | allejo | i wouldn't say there's a need for that. unless you find an issue then i'd say it's necessary |
| 20:22.15 | alpha1-2 | ok |
| 20:23.46 | *** join/#bzflag develCuy (~quassel@unaffiliated/develcuy) |
| 20:30.39 | Delusional | My problems with creating map cache files ended a long time ago with trepanâs commits to enable drawinfo cache creation. |
| 20:31.11 | Delusional | I messed around with fastmap for awhile after that, but gave it up. |
| 20:58.40 | alpha1-2 | very good, it works fine now! thanks guys |
| 20:58.53 | alpha1-2 | (it loads fast) |
| 21:03.04 | alpha1-2 | what are the exit issues you are willing to get tested? should I read any chat logs? if I should, which days? |
| 21:10.34 | alpha1-2 | okay here what I saw: http://infobot.rikers.org/%23bzflag/20151119.html.gz |
| 21:12.13 | alpha1-2 | well, I have not issues on exit yet |
| 21:12.45 | alpha1-2 | opensuse 11.4 |
| 21:12.55 | blast007 | alpha1-2: it's not weird that the 2.4.2RC2 tar is smaller. We removed all the third-party libraries from our source tree. :) |
| 21:13.54 | alpha1-2 | allejo said /src/other, yes, 27.9 MiB in 2.4.0 :) |
| 21:14.17 | blast007 | ah, yes, missed him saying that |
| 21:14.23 | alpha1-2 | ah third-party libraries, seems good |
| 21:15.12 | blast007 | allejo: "what justifies a bump from 2.5.1 to 2.5.2" when we make an incompatible change, for one, but we don't always remember to do that (or care enough to do that) |
| 21:19.11 | alpha1-2 | then, every incompatible change would require a new number? sounds good. Like when you edit any file and you save several versions of it, with every important change, just in case |
| 21:19.34 | blast007 | doesn't require, it's just good practice |
| 21:19.39 | alpha1-2 | okay |
| 21:22.08 | alpha1-2 | well, I just joined that ahs's server again with debug mode on and noone weird message :) |
| 21:23.57 | alpha1-2 | and yes, it is 2.4.3.20151114-DEVEL... version |
| 21:30.56 | alpha1-2 | now I will have to update my logconverter script, 'cause of alezakos' new color system. He told me about it time ago. I hope it is into any new standard, to [being worth it]: |
| 21:30.57 | alpha1-2 | original: http://i.imgsafe.org/48aae20.png |
| 21:30.58 | alpha1-2 | new: http://i.imgsafe.org/5b23408.png |
| 21:31.16 | alpha1-2 | to be* |
| 21:34.22 | allejo | oh hey my name's there |
| 21:34.27 | allejo | feels special |
| 21:35.46 | alpha1-2 | you are becoming more and more famous allejo ;) |
| 21:36.28 | allejo | cheers |
| 21:37.00 | alpha1-2 | what I remember is that it was made for new gama of colors, not sure if the classical ones should show well still |
| 21:37.52 | blast007 | it's so that we can customize team radar colors and have the text labels match |
| 21:38.48 | blast007 | that's one big thing (that seems minor) going into 2.4.4 - better handling of color modifications for radar (and other UI elements) and shot/tank color |
| 21:39.18 | alpha1-2 | but having still the 5 main colors in teams, right? |
| 21:39.39 | blast007 | we didn't get a GUI in there, but that will probably come for 2.6 - we could probably even include some presets for various forms of colorblindness |
| 21:39.45 | blast007 | yeah |
| 21:40.02 | blast007 | it's for people that might want to make the blue a bit brighter, for instance |
| 21:40.24 | blast007 | our UI elements had fixed colors before, so when changing a team color, only certain things would actually change |
| 21:40.31 | alpha1-2 | ah yes |
| 21:41.14 | alpha1-2 | is it still ANSI colors? he said something like... new system, much more colors IIRC |
| 21:41.46 | alpha1-2 | won't it affect console output as well? |
| 21:42.24 | alpha1-2 | searching chat log |
| 21:55.44 | alpha1-2 | found it: "24-bit RGB ANSI color codes - ISO-8613-3", "about 16.7 million colors", "it should be taken by the ANSIfilter developer ;) |
| 21:55.45 | alpha1-2 | " :) |
| 21:58.14 | alpha1-2 | well, I will have to research it |
| 22:04.07 | alpha1-2 | won't it affect console output as well? I understand that console can handle "Black, Red, Green, Yellow, Blue, Magenta, Cyan, White, xterm 256 color codes", or am I wrong? |
| 22:04.36 | alpha1-2 | http://www.andre-simon.de/doku/ansifilter/en/ansifilter.php |
| 22:05.10 | blast007 | I think it will work for the console as well, since that will probably use the radar color when referring to player names |
| 22:05.53 | alpha1-2 | I will test console right now |
| 22:11.04 | alpha1-2 | yes, it works fine... then ANSIfilter can't handle well new color codes? the intro text is fine, not the killing ones, weird |
| 22:36.41 | alpha1-2 | I don't know why but I am getting a very weird behaviour when trying to upload a specific PNG image with your page, brad: |
| 22:36.42 | alpha1-2 | http://i.imgsafe.org/98ef393.png . It converts it to .lob file. |
| 22:37.48 | alpha1-2 | even JPG |
| 22:38.18 | alpha1-2 | maybe because it is too large in height? |
| 22:42.23 | Constitution | allejo: must be the very first pi model ever? :P |
| 22:42.52 | alpha1-2 | (I splited it and it worked) |
| 22:42.57 | Constitution | I actually do compile on the pi (latest model), and I think it takes about half an hour |
| 22:43.28 | alpha1-2 | Constitution: how much does it take to compile in your *normal* machine? :) |
| 22:43.40 | alpha1-2 | (not Pi) |
| 22:45.17 | alpha1-2 | no need to compile it now OFC |
| 22:45.31 | Constitution | less than a minute, I believe |
| 22:45.41 | alpha1-2 | oh nice |
| 22:45.52 | alpha1-2 | what machine? |
| 22:48.08 | Constitution | I guess I was off a little bit... 1:23 |
| 22:48.37 | alpha1-2 | mine 2 cores Pentium P6200 2.13GHz - 3 GB RAM |
| 22:48.50 | alpha1-2 | I did 10 minutes :P |
| 22:48.59 | alpha1-2 | but I am happy still |
| 22:49.10 | Constitution | but that's using Xcode... it's probably slower to compile with makefiles, since it compiles everything in one directory at a time |
| 22:49.17 | alpha1-2 | alezakos, did you maybe only modify the in-game messages color codes, not the intro ones? Only the in-game ones are all grayscale colored: |
| 22:49.19 | alpha1-2 | http://i.imgsafe.org/201d25c.png |
| 22:49.20 | alpha1-2 | http://i.imgsafe.org/3245220.png |
| 22:51.10 | alpha1-2 | ahh, don't know about OSX... I did normal linux one: ./autogen.sh, ./configure, make |
| 22:51.17 | blast007 | I'd imagine you could answer that question yourself without even looking at any code... |
| 22:51.37 | blast007 | obviously if some of them still work for you, they're not using the 24-bit RGB ANSI codes.. |
| 22:52.54 | alpha1-2 | this is the screenshot of the server: http://i.imgsafe.org/b4f0c17.png |
| 22:53.40 | alpha1-2 | ah okay, yes, not necessary to change intro colors, right |
| 22:54.16 | alpha1-2 | well, but someone could want to change them or not? |
| 22:54.40 | blast007 | why? they're not teams |
| 22:54.48 | alpha1-2 | should they be all the same codes? |
| 22:54.55 | alpha1-2 | should not* |
| 22:55.13 | alpha1-2 | but if we are talking of player customizations? |
| 22:55.22 | alpha1-2 | players'* |
| 22:55.31 | blast007 | the server messages, maybe |
| 22:55.32 | alpha1-2 | like colorblind persons, etc |
| 22:56.53 | alpha1-2 | IMO all, all are console messages, and important. Apart to maintain conistency in all the code also |
| 22:57.04 | alpha1-2 | consistency |
| 22:57.31 | alpha1-2 | well, have to run, I will keep online |
| 23:00.47 | alpha1-2 | I still wonder if all these changes are really necessary or if it is enough with 256 colors for example |
| 23:18.16 | alezakos | alpha1-2: only player names are using RGB ANSI codes, everything else is plain ANSI |
| 23:33.40 | alpha1-2 | alezakos: are you sure is there not any mistake? I see some inconsistencies, for example bold/unbold characteres... "killed" should be bold always... Just a little doubt, because they don't appear in BZ/shell console, and I still have not researched it into ANSIfilter. Just, if you all are hurried. |
| 23:35.32 | alpha1-2 | or in a hurry* |
| 23:43.13 | alpha1-2 | other one: "piggy" being rogue is not changing bold "flag" (it starts bold state since then until the flag is turned off again), but "fifvop" being blue does |
| 23:44.29 | alpha1-2 | again, maybe they are only in ANSIfilter side, so don't worry too much |
| 23:44.52 | alpha1-2 | AFK now again |
