| 00:04.31 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 00:08.58 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 00:25.16 | *** join/#bzflag sanandresm (~andres@181.49.242.146) |
| 00:33.53 | alpha1-2 | sanandresm: kierra tambien habla español; no es una programadora pero ayuda en general. No se si hay otros |
| 00:34.25 | sanandresm | Porque me dices eso ahora? |
| 00:34.50 | alpha1-2 | vos preguntaste el otro dia, pero cuando conteste, ya te habias ido |
| 00:35.25 | sanandresm | Gracias entonces |
| 00:35.31 | blast007 | please use English in this channel |
| 00:36.28 | alpha1-2 | de nada. He asked the other day if someone else speaked Spanish. |
| 00:37.45 | alpha1-2 | I just told him kierra does, though is not a developer, but help in general, and don't know about others |
| 00:37.56 | alpha1-2 | helps* |
| 00:39.00 | alpha1-2 | Tim Riker and Flash tambien/Tim Riker and Flash also |
| 01:03.42 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 01:45.23 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 02:03.36 | *** join/#bzflag sirquine (~quine@2601:281:8202:ef46:226:bbff:fe19:5689) |
| 10:46.05 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 12:34.00 | *** join/#bzflag valera_rozuvan (~Valera@193.105.216.6) |
| 13:24.28 | *** join/#bzflag valera_rozuvan (~Valera@193.105.216.6) |
| 13:36.36 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 13:41.01 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 14:48.17 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 15:19.22 | *** join/#bzflag kaadmy (uid135503@gateway/web/irccloud.com/x-chbcwncffhdwujyg) |
| 16:10.11 | *** join/#bzflag valera_rozuvan (~Valera@193.105.216.6) |
| 16:47.31 | *** join/#bzflag valera_rozuvan (~Valera@193.105.216.6) |
| 17:27.59 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 18:27.53 | *** join/#bzflag alpha1-2 (~alpha1@host95.201-252-189.telecom.net.ar) |
| 18:36.41 | alpha1-2 | what does the last BZNotify line mean: "16:28.02Notify03BZFlag:Blast * 8949 /Main_Page:" on here http://infobot.rikers.org/%23bzflag/20160124.html.gz ? |
| 18:37.03 | blast007 | wiki changes |
| 18:38.48 | alpha1-2 | ah. Is that number the line? Even if BZNotify left? |
| 18:39.09 | blast007 | revision number |
| 18:39.41 | alpha1-2 | ah I see Notify here |
| 18:43.40 | alpha1-2 | it puts a colon at the end; is that maybe incomplete? |
| 18:44.36 | alpha1-2 | also here: "16:32.58Notify03BZFlag:Blast * 8950 /MediaWiki:Sidebar: " |
| 18:44.50 | blast007 | no |
| 18:45.18 | alpha1-2 | ok |
| 18:48.46 | alezakos | alpha1-2: the summary of the wiki change is expected to go after the ":". If there is no summary, nothing is shown after it. |
| 18:48.48 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 18:48.48 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 18:48.53 | alezakos | Notify is an old bot that works as intented. |
| 18:49.03 | blast007 | kinda |
| 18:49.31 | blast007 | it sometimes chops off the last letter of the page name |
| 18:50.46 | alpha1-2 | I supposed. Though I don't know very much about editing Wiki pages |
| 18:52.19 | alpha1-2 | is it supposed that in every change the summary should go or that is not very practical? |
| 19:01.51 | alpha1-2 | "01:06.24 blast007 do we still want to release our own source tars?" Yes, I agree with the idea, since it is like a picture, of a time of the development stage. GitHub ones are always dynamic, or they are encouraged, it seems. |
| 19:02.40 | blast007 | not true |
| 19:02.49 | allejo | GitHub's targs for releases are the code at that point |
| 19:08.28 | allejo | https://github.com/BZFlag-Dev/bzflag/releases |
| 19:11.08 | alpha1-2 | yes, I remember that. But always I go to code page, it says "donload ZIP" and that is the dynamic one. The other ones are in other pages (not so easy to see). I am just making a comparaison with SF method, which encouraged the packages. Apart, if you are going to use download.bzflag.org instead, which I opine is better, you should put all there, together. |
| 19:19.32 | allejo | The release tars are appropriately located under the Releases page, I don't see why "Download ZIP" would download the last release tar if you're looking at the current code |
| 19:21.43 | alpha1-2 | I am saying that GH encourages dynamic downloads, while SF encourages static ones. Do you think tars should be only in GH and not in download.bzflag.org, then? |
| 19:22.54 | blast007 | the only reason to put them in download.bzflag.org is if we intend on supplying source tars that already have the 'autogen.sh' script run so that automake/autoconf isn't required to build the game |
| 19:23.36 | blast007 | that was mainly done for some platforms that had buggy/old/missing autoconf/automake tools |
| 19:27.51 | alpha1-2 | ah okay, it was more complicated than I thought |
| 19:29.06 | alpha1-2 | and you can't put compiled versions in GitHub, then? |
| 19:30.55 | blast007 | I'm not talking about compiled versions |
| 19:31.06 | blast007 | I'm talking about ones that have autogen.sh already run |
| 19:31.35 | blast007 | and yes, we could put them on there *also*, but we have no choice about including the github generated source tars |
| 19:35.20 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 19:35.38 | alpha1-2 | I see. Well, just agreeing/proposing the idea of all together, if possible, and always having a local copy is not a bad idea either (on download subdomain) |
| 19:40.28 | blast007 | refers back to his "the only reason..." message |
| 19:43.50 | alpha1-2 | okay, blast007! :D then why did you put compiled version on download subdomain?? |
| 19:44.11 | blast007 | compiled version? the Windows and Mac builds? |
| 19:44.15 | alpha1-2 | yes |
| 19:44.24 | blast007 | we are not talking about those |
| 19:44.29 | blast007 | we are talking about source tars |
| 19:45.28 | alpha1-2 | okay, NVM, I just hope my message about "all together" and "keeping copies" are understood :) |
| 19:46.23 | blast007 | not at all |
| 19:47.35 | alpha1-2 | may I explain them further? |
| 19:48.41 | blast007 | we will have binary downloads on download.bzflag.org. If we still want to provide source tars that already have autogen.sh run, they will also be on download.bzflag.org. Otherwise, we will just use github's source release. |
| 19:50.01 | alpha1-2 | may I ask why do you seperate the downloads? |
| 19:50.50 | blast007 | meaning what? |
| 19:51.28 | alpha1-2 | placing ones in one domain/page and others in others |
| 19:52.16 | alpha1-2 | (apart of the autogen issue) |
| 19:52.24 | blast007 | nothing is set in stone for this - we just need to decide on the ONE THING I had mentioned, and then we can choose the next step |
| 19:53.01 | alpha1-2 | okay, thanks for the time |
| 20:05.01 | *** join/#bzflag valera_rozuvan (~Valera@176.104.51.77) |
| 20:20.40 | BulletCatcher | 20+ years ago, a lot of widely used portable software had few dependencies and could be built with little more than a working C compiler and some implementation of the "make" command. |
| 20:20.46 | BulletCatcher | The GNU autotools evolved to create target-specific makefiles, but the autotools themselves were often not installed on those target systems. |
| 20:20.51 | BulletCatcher | This led to the convention of using the autotools to create the "configure" script and Makefile.in files included in source tarballs. |
| 20:20.56 | BulletCatcher | These days, installing the autotools is just as easy as installing all of the other BZFlag dependencies (e.g., cURL), so I think it is not worthwhile for us to distribute tarballs in which the autotools have already been run. |
| 20:23.17 | blast007 | there's also probably not a lot of platforms that have a c++11 compiler but can't get autotools |
| 20:26.56 | BulletCatcher | We should continue to support "make dist" so that traditional tarballs can be created by anyone who needs them, but *we* don't have to provide them for downloading. |
| 20:28.22 | blast007 | so then the next decision, where to have the source tars: on github, on downloads.bzflag.org, or both? |
| 20:31.46 | alpha1-2 | I suggest always keeping a local copy; never is too much. Apart, local downloads seems always better for me (more independence). |
| 20:32.21 | blast007 | keep stats is part of the decision as well |
| 20:32.25 | blast007 | keeping* |
| 20:33.48 | alpha1-2 | you make often backups of the forum, which is huge. Making backups of the files is much more important :) |
| 20:34.32 | blast007 | I'd personally prefer to not use Github releases at all |
| 20:34.51 | valera_rozuvan | blast007, Why do you not like GitHub releases? |
| 20:35.29 | blast007 | no stats at all |
| 20:36.04 | valera_rozuvan | https://help.github.com/articles/getting-the-download-count-for-your-releases/ -> "Getting the download count for your releases" |
| 20:36.24 | valera_rozuvan | Simply need to create a service to display this info on the BZFlag page. |
| 20:36.29 | allejo | that's just a total |
| 20:36.50 | allejo | you'd have to make an api call every day to check the previous day to keep track of |
| 20:36.50 | blast007 | sourceforge at least has nice graphics, country and OS info, etc |
| 20:36.59 | blast007 | graphs* |
| 20:37.03 | valera_rozuvan | If you write a smart enough service that will poll this API, you can present very cool statistics about release downloads! |
| 20:37.20 | allejo | GitHub doesn't provide OS or country info even with the API |
| 20:37.39 | valera_rozuvan | You can use any graph API to present your data: For example: http://d3js.org/ . |
| 20:37.52 | blast007 | I know how to make a graph :P |
| 20:37.54 | BulletCatcher | https://github.com/BZFlag-Dev/bzflag/graphs/traffic doesn't have the details we want. |
| 20:38.40 | allejo | ^ that's only visible to people with commit access i believe. just as an fyi |
| 20:38.40 | alpha1-2 | I need to be registered to see that page, BulletCatcher |
| 20:39.25 | BulletCatcher | That makes it even less useful, then. :-) |
| 20:39.32 | valera_rozuvan | Point taken. |
| 20:39.40 | blast007 | knowing rough country information would be nice so that we could prioritize translations, for instance, or to plan where to host stuff. |
| 20:40.15 | blast007 | I already run a Piwik instance for the main bzflag.org site, and it'd be easy enough to extend that to tracking downloads |
| 20:40.41 | blast007 | I've started to work on the download interface already |
| 20:40.54 | valera_rozuvan | Oh! Someone already made a service to view project's release stats! = ) http://www.somsubhra.com/github-release-stats/ . |
| 20:41.34 | allejo | where players are connecting from and actively playing would be simple to provide from game server log. so download stats could show where people are downloading from and not understanding where to go |
| 20:42.17 | BulletCatcher | It seems to me that geolocation data for players (which blast007 can derive from the list server logs) is more important than that data for downloads. |
| 20:42.36 | BulletCatcher | (That is almost the same as what allejo just said.) |
| 20:42.48 | valera_rozuvan | Here are the stats for BZFlag: http://www.somsubhra.com/github-release-stats/?username=BZFlag-Dev&repository=bzflag |
| 20:43.14 | valera_rozuvan | Pointless, I know... = ) |
| 20:43.20 | blast007 | even if we use github releases for the source, I could still track downloads if they are initiated from the bzflag.org site |
| 20:43.33 | BulletCatcher | yup |
| 20:43.35 | blast007 | I'd just miss ones where people get it from github directly |
| 20:43.37 | allejo | which is what is currently happening, no? |
| 20:43.46 | allejo | oh for sources, nvm |
| 20:44.18 | BulletCatcher | You also can't track people who clone our repo from GitHub. |
| 20:44.22 | valera_rozuvan | I guess the best case scenario is having a small download for installer, and then that installer gets all the necessary files from some server. This installer can pass on to the main server a whole lot of info. PC type, video card, language, etc. |
| 20:44.24 | blast007 | or I could have them at both, and give people the option |
| 20:44.50 | blast007 | valera_rozuvan: our entire installer is something like 15MB. We don't need a web installer. ;) |
| 20:45.16 | blast007 | (and that 15MB includes the Visual C++ runtime installer) |
| 20:46.07 | allejo | who's the target audience for the tars with autogen already run? |
| 20:46.11 | alpha1-2 | running a local copy of git... can be a posibility at anytime? |
| 20:46.25 | blast007 | allejo: probably old versions of Solaris or something like that |
| 20:46.57 | alpha1-2 | I saw it in other country (Germany). Even they had an own bug tracker |
| 20:47.01 | allejo | is there a significant solaris usage? |
| 20:47.34 | BulletCatcher | It is nice not to have to deal with autotools on Solaris, but I am likely the only person who still runs BZFlag on it. |
| 20:48.45 | BulletCatcher | And only bzfs, at that. |
| 20:49.10 | blast007 | BulletCatcher: well, I sorta ran bzfs on a Solaris derivitive recently (SmartOS, which is based on OpenSolaris/illumos) |
| 20:49.50 | blast007 | an OS that I'm pondering the use of for the next iteration of BZFlag web services |
| 20:51.17 | alpha1-2 | this is the project: http://www.openclonk.org/ |
| 20:51.46 | BulletCatcher | I am actively looking at SmartOS as the hypervisor for a new set of servers, but I expect to run Linux in the guest that is the BZFlag server. |
| 20:53.04 | blast007 | the big advantage of SmartOS is that you don't have to do actual virtualization for your zones, unless you're intended to do something like run Linux |
| 20:53.18 | blast007 | it's got jails on steroids |
| 20:54.06 | BulletCatcher | Solaris zones are awesome, and even better when on top of ZFS. |
| 20:54.59 | BulletCatcher | I am currently experimenting with an lx guest, which is Linux in a regular Solaris zone instead of KVM. |
| 20:56.32 | blast007 | were you looking at using their Smart Data Center stuff? |
| 20:57.05 | blast007 | at least for me, I don't believe that's an option since it's geared towards environments with at least 2 servers |
| 20:57.29 | BulletCatcher | At this time I have only 1 server, so that is outside my scope. |
| 20:57.40 | blast007 | k, so same as me ;) |
| 20:57.50 | BulletCatcher | :-) |
| 20:59.13 | blast007 | prior to finding SmartOS, I had been leaning towards using a Linux host with KVM linux guests, isolated with SELinux, but that was getting complicated, and Debian Jessie shipped with a gimped SELinux due to time constraints |
| 20:59.28 | BulletCatcher | I expect to eventually have a 2nd server for redundancy, but automated migration between them is not a requirement. |
| 21:02.00 | BulletCatcher | I don't need five nines of uptime for my BZFlag server. :-) |
| 21:02.15 | valera_rozuvan | By the way! I think you guys should really update https://wiki.bzflag.org/Development_RoadMap ! [last modified on 28 April 2013, at 15:32] |
| 21:03.24 | blast007 | that's newer than our last release of the game :) |
| 21:03.29 | valera_rozuvan | = ) |
| 21:03.37 | blast007 | 2.4.2 came out 2012-07-28 |
| 21:05.07 | BulletCatcher | Alas, the world did not end along with the Mayan calendar. |
| 21:05.49 | blast007 | I survived the Mayan apocalypse, and all I got was this lousy t-shirt. |
| 21:06.12 | blast007 | (I do actually have a t-shirt that says "I survived the Mayan apocalypse") ;) |
| 21:07.32 | valera_rozuvan | +1 |
| 21:07.35 | alpha1-2 | (there is just one which is true - the Biblie one - better be prepared for this one) |
| 21:08.01 | the_map | well, sorta |
| 21:08.08 | BulletCatcher | Not in this channel, guys. |
| 21:08.11 | alpha1-2 | Bible* (Biblia in Spanish) |
| 21:08.15 | blast007 | the year 2039 will probably have more real issues |
| 21:08.44 | valera_rozuvan | What's very interesting about the whole apocalypse thing - different religions (societies) had/have different views about when/and how it's going to happen... |
| 21:08.53 | the_map | blast007: what happens in 2039? |
| 21:09.05 | blast007 | or actually 2038, since it happens on January 19th |
| 21:09.12 | blast007 | https://en.wikipedia.org/wiki/Year_2038_problem |
| 21:09.32 | the_map | oh...should have known that |
| 21:10.33 | valera_rozuvan | I don't know what will happen in 2039 ... but I know what will happen in 2027... A man will land on Mars! http://www.valuewalk.com/2015/12/tesla-ceo-musk-reusable-rockets-key-mars-colony/ |
| 21:10.35 | the_map | why would epoch time be signed? it can't be negative |
| 21:10.47 | alpha1-2 | wow, interesting blast007 |
| 21:10.49 | macsforme | sure it can :P |
| 21:11.01 | the_map | macsforme: do explain |
| 21:11.15 | alpha1-2 | let's migrate back to Windows, then!! :D |
| 21:11.19 | macsforme | if we're referring to a date prior to the epoch |
| 21:11.30 | the_map | in seconds? |
| 21:11.35 | valera_rozuvan | milliseconds? |
| 21:11.51 | blast007 | no, seconds |
| 21:11.59 | BulletCatcher | When unix was invented in the 1970s, time values were stored in a 32-bit signed integer. |
| 21:12.18 | valera_rozuvan | As a physicist - I can tell you all that there is an absolute time frame. And it starts at second 0 - the Big Bang! |
| 21:12.48 | BulletCatcher | It has taken us a long time to get past that, but modern 64-bit Linux systems are already prepared for 2038. |
| 21:12.53 | alpha1-2 | (fortunatelly we have our historian here... BulletCatcher!) |
| 21:12.54 | blast007 | time doesn't exist |
| 21:13.31 | valera_rozuvan | actually time exists from second 0, and is constant. We simply pass on it time. From second N to second N+1. |
| 21:13.32 | macsforme | since we can't talk about the great tribulation in here, we shouldn't discuss the big bang either :P |
| 21:13.42 | BulletCatcher | Time is what keeps everything from happening at once. |
| 21:13.48 | the_map | yeah, my thought too, macsforme |
| 21:14.03 | alpha1-2 | agree :) |
| 21:14.04 | blast007 | the universe is a hologram |
| 21:14.29 | the_map | blast007: if there's no such thing as time, why hasn't 2.4.4 been released yet? |
| 21:14.32 | the_map | :P |
| 21:14.41 | blast007 | sure, sure, they did that test that might prove it's not, but that's just what the hologram creators *want* us to think! |
| 21:14.53 | alpha1-2 | go Matrix! |
| 21:15.14 | blast007 | the_map: because I just haven't found the time |
| 21:15.38 | BulletCatcher | I find your lack of faith disturbing. |
| 21:15.41 | BulletCatcher | (Have we referenced enough sci-fi movies yet?) |
| 21:16.13 | the_map | live long and ... may the odds be ever in your favor! |
| 21:16.21 | BulletCatcher | lol |
| 21:16.29 | the_map | <star trek hand symbol> |
| 21:16.32 | alpha1-2 | go Shortcircuit! :P (I liked this one) |
| 21:16.55 | blast007 | need input |
| 21:16.59 | valera_rozuvan | Wait, wait! You are telling me that we are not inside a holodeck right now?!?!?! |
| 21:17.03 | the_map | blast007: 42 |
| 21:17.40 | alpha1-2 | cin, blast |
| 21:18.26 | alpha1-2 | aahh we need to relax sometimes, don't we? :) |
| 21:18.55 | alpha1-2 | now work hardly for the next middle february release! |
| 21:19.52 | the_map | alpha1-2 is telling us to hardly work for the release :D |
| 21:19.55 | alpha1-2 | (or let's work :P) |
| 21:20.19 | alpha1-2 | let's continue working*! |
| 22:36.01 | *** join/#bzflag valera_rozuvan (~Valera@176.104.51.77) |
| 22:43.06 | alpha1-2 | blast007: I was thinking: maybe the way would be to hide the releases section of GH (or disabling the download feature on there) and including the links for the files from downloads.bzflag.org. Then you will re-direct all the traffic (except the clonned ones, which should be minor) to one place. There, you could implement the counting system you need (no need to hurry about all, tho; it's important to do the work correctly). |
| 22:44.16 | blast007 | you can't disable the releases section as it generates them automatically for each tag |
| 22:45.49 | valera_rozuvan | So don't make tags! Only use branches to mark releases. |
| 22:45.57 | blast007 | we are going to use tags |
| 22:46.28 | alpha1-2 | I see "Available Downloads: Windows, Mac OS X 10.7+. Downloads: Source code (zip), Source code (tar.gz)." Any of these are created automatically? |
| 22:46.28 | valera_rozuvan | By the way - another good point to use branches instead of releases. You can back port bug fixes to your previous releases. |
| 22:46.54 | valera_rozuvan | instead of *tags |
| 22:49.23 | alpha1-2 | the first 2 are okay, though in different sections from the second 2. I wonder if the second ones are automatically (which should be corrected) |
| 22:49.42 | alpha1-2 | automatic* |
| 22:50.18 | alpha1-2 | or obligatory |
| 22:51.35 | allejo | valera_rozuvan, we use branches already. 2.4 and master (2.5 dev) can be merged back and forth |
| 22:51.53 | allejo | alpha1-2, the "Available Downloads" are content I've added manually in the release to link to the bzflag.org downloads |
| 22:52.29 | allejo | I'm copy pasting the info from the forum announcements as releases for those who use github to checkout releases and not force them to find them by themselves |
| 22:53.41 | alpha1-2 | yes, that should be the right way. But if the second 2 links are obligatory to be used from github, then, we have a problem |
| 22:55.41 | allejo | as blast already said, they are generated automatically |
| 22:56.50 | blast007 | valera_rozuvan: we use branches and tags |
| 22:57.05 | blast007 | tags are for releases |
| 22:58.10 | alpha1-2 | then, include a sign "*IMPORTANT* For a better track system, please don't click on these links below but above!" :) Those links can't be edited? |
| 22:59.32 | alpha1-2 | or any option to incude more links, instead of doing it in the prev. text? |
| 22:59.36 | alpha1-2 | include |
| 23:00.48 | alpha1-2 | well... it's a GH problem, to not have a good stats system |
| 23:05.56 | blast007 | we just won't worry about the downloads from github |
| 23:10.19 | alpha1-2 | okay, but include at least some info so the people can redirect to bzflag page and download "preferably" from there, as I mentioned |
| 23:11.40 | alpha1-2 | you just can copy/paste the same text every time |
| 23:12.12 | alpha1-2 | it would be good to have a web page made specially for that too |
| 23:14.36 | alpha1-2 | wel, yes, just link to http://bzflag.org/downloads |
| 23:39.39 | alpha1-2 | blast007: other topic, I was searching some good videos to invite people I met and I found these 2. Maybe you are interested in include them in the page. #1: HIX + 2 Tanks; #2 Missile War 2.3. The only doubt is that the first one uses a special version; not sure if it is a modified version to improve view as I have seen in other video or if that was the real original one about 2010. |
| 23:39.40 | alpha1-2 | https://www.youtube.com/watch?v=Kt2ySuDz260 |
| 23:39.42 | alpha1-2 | https://www.youtube.com/watch?v=Eeyf6LRgvU4 |
| 23:39.43 | alpha1-2 | Also, the music of the #1 is a little sad (I don't understand very well the lyrics)... I suppose, maybe, it was made related to Alice D who died the previous year (2009) 'cause of a sickness, played 2 Tanks (and maybe HIX too), and has a sign on that map. |
| 23:41.58 | blast007 | a 480P video and music that's probably used ilegally.. yeah.. no. |
| 23:43.07 | blast007 | if we're gonna have some official videos up, it's gonna be a quality capture |
| 23:43.54 | blast007 | I probably won't bother with that for a while though |
| 23:44.29 | alpha1-2 | okay |
| 23:46.30 | blast007 | so, we have gotten any feedback on 2.4.4-RC3? nothing on the forum post |
| 23:46.52 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 23:48.18 | blast007 | I don't spend much of any time in the game itself though, so maybe someone has heard some feedback there |
| 23:48.49 | alpha1-2 | just to know, not sure if I will be able to test 3 very much: is there any special feature to be tested different from 2? |
| 23:49.59 | alpha1-2 | or is it useful to test it in general also, even if I did it a lot with 2? |
| 23:50.04 | alpha1-2 | or it is* |
| 23:51.56 | blast007 | some crash bugs were fixed (when exiting bzfs and the client), one of which was a memory corruption issue with the client, which had some other odd effects when running on macsforme's Raspberry Pi port |
| 23:52.09 | blast007 | the main thing though was for Mac users |
| 23:52.46 | alpha1-2 | I read something about SDL 2 for that, and then you will test it for Wdinows, right? |
| 23:53.00 | alpha1-2 | Windows |
| 23:53.10 | blast007 | a newer SDL2 that fixed an issue that preventing mouse clicks from registering at the top of the screen, and some resizing issues |
| 23:53.24 | blast007 | SDL2 for Windows is for 2.4.6 |
| 23:53.42 | blast007 | and it will be a test to see how well it works and if it resolves that Windows 10 + AMD issue |
| 23:53.48 | blast007 | if it works great, might just go with it |
| 23:53.59 | alpha1-2 | okay |
| 23:54.12 | alpha1-2 | for now then only Mac uses SDL2 right? |
| 23:54.36 | blast007 | SDL1 had some shortcomings, especially with input handling (the number of joystick/mouse buttons, force feedback support, etc) |
| 23:54.45 | alpha1-2 | (which you said it was somewhat buggy IIRC) |
| 23:54.55 | blast007 | I think SDL2 is better about that stuff though, so might be less of an issue to use SDL2 on Windows |
| 23:55.24 | blast007 | the only downside is that some of my earliest contributed code will no longer be used ;) |
| 23:55.36 | alpha1-2 | hehe |
| 23:55.45 | blast007 | probably the first actual fix I contributed |
| 23:57.09 | alpha1-2 | and what about Linux? |
| 23:58.10 | alpha1-2 | is it still using SDL1 on RC3? |
| 23:58.40 | alpha1-2 | or any issues with SDL2? (you said it was somewhat buggy IIRC) |
| 23:59.16 | blast007 | Linux doesn't automatically use SDL2 even if it's installed |
| 23:59.31 | blast007 | you have to use --enable-SDL2 on configure, iirc |
| 23:59.39 | alpha1-2 | aahh okay |