Timestamps are in GMT/BST.
| 00:00:01 | sam686 | powerpc mac compiler and maybe 32-bit x86 don't support c++11 |
| 00:00:21 | Watusimoto | ok |
| 00:00:50 | sam686 | linux gcc allows disabling c++11 extensions im not sure if thats true on visual c++ 2013 |
| 00:02:20 | raptor | OSX 10.6 doesn't support c++11 |
| 00:03:03 | raptor | oh |
| 00:03:09 | raptor | this release we can do a win64 build! |
| 00:03:19 | raptor | except... I'm not sure about the updater |
| 00:04:28 | sam686 | 64 bit windows build can start other win32/64 programs, but the updator might end up downloading 32 bit update instead of 64 bit.. |
| 00:04:52 | raptor | we have it hit a PHP file, so we can alter the response |
| 00:06:09 | raptor | now i just need to figure out a 64bit signature... |
| 00:06:21 | raptor | in the user agent maybe? |
| 00:06:54 | raptor | oh wait... |
| 00:07:00 | raptor | where did our getDownloadUrl.php go?? |
| 00:08:12 | sam686 | bitfighter (32 bit or 64 bit) runs bfup.exe, bfup.exe access bitfighter.org / some update checking php |
| 00:12:02 | sam686 | http://bitfighter.org/wiki/index.php/Building_Bitfighter is a bit outdated, mostly the linux part with a broken "Shortcut" link |
| 00:12:02 | fordcars | Hmm, using the second argument of a GoalZone LoadoutZone constructor in Lua to set the team, well, doesn't do anything and sets the object to neutral. When you don't have this argument, it'll crash saying it needs more arguments, so you have have to have the team in the constructor and use setTeam() after |
| 00:13:32 | raptor | fordcars: can you please write that in the forum bugs thread? |
| 00:13:51 | fordcars | Sure |
| 00:15:09 | raptor | oh yay, i found the php |
| 00:15:28 | raptor | old one from 017b, but it's still has most of my modifications |
| 00:24:21 | raptor | ok, OSX updates are broken now.. |
| 00:24:23 | raptor | sigh |
| 00:24:56 | sam686 | zap/main.cpp line 647 might be of interest on how to differentiate between 32 bit and 64 bit builds: use (itos(buildVersion) + "_64bit").c_str() and #ifdef (see tnl/tnlTypes.h) |
| 00:25:17 | sam686 | (for windows builds) |
| 00:28:07 | raptor | hmmm... do we need to adjust TNL to handle win64 better? |
| 00:33:29 | raptor | i wonder what user agent GUP uses |
| 00:33:48 | raptor | and can it even compile/work on win64? |
| 00:34:10 | | Watusimoto Quit (Ping timeout: 255 seconds) |
| 00:36:53 | raptor | looks like the XML is invalid for the updater |
| 00:36:58 | sam686 | bfup.exe could remain at 32 bit if you wish, im pretty sure all 64 bit windows still runs most 32 bit programs.. maybe at first future windows might soon require 64 bit cpu but still allows running 32 bit programs |
| 00:37:12 | raptor | windows 10 is coming out soon - it will not have 32bit |
| 00:37:51 | sam686 | windows 7 32 bit could still run 16 bit programs (64 but does not run 16 bit) |
| 00:38:05 | raptor | oh really? |
| 00:38:08 | raptor | i didn't know that... |
| 00:38:10 | sam686 | ]yes |
| 00:38:23 | sam686 | but 64 bit version of windows will not run 16 bit, 32 bit does |
| 00:39:20 | sam686 | and of sourse windows 95 is probably the first that requies 32 bit cpu - 16 bit cpu not supported |
| 00:39:55 | sam686 | and here windows 7 (32 bit only) still could run 16 bit programs |
| 00:41:00 | sam686 | linux is a different story, 99% of binary have source code so they could easily make everything compile at specific cpu |
| 00:53:36 | raptor | our bfup system is broke somehow... |
| 00:53:47 | raptor | not sure why the XML says it's bad |
| 00:54:07 | raptor | and compiling the new stuff doesn't look for the proper uRL |
| 00:54:16 | raptor | and now i'm getting sleepy so good night! |
| 00:55:32 | fordcars | Night! |
| 00:55:35 | | fordcars Quit (Quit: Page closed) |
| 00:55:39 | | raptor Quit () |
| 01:58:49 | | Watusimoto has joined |
| 02:06:06 | | sam686 Quit (Ping timeout: 256 seconds) |
| 02:17:06 | | vs73nx has joined |
| 02:58:08 | | vs73nx Quit (Remote host closed the connection) |
| 03:16:41 | | vs73nx has joined |
| 03:16:41 | | vs73nx Quit (Changing host) |
| 03:16:41 | | vs73nx has joined |
| 03:34:07 | | LordDVG has joined |
| 03:54:39 | | vs73nx Quit (Ping timeout: 272 seconds) |
| 05:37:32 | | Watusimoto Quit (Ping timeout: 265 seconds) |
| 07:22:28 | | LordDVG Quit (Remote host closed the connection) |
| 07:34:43 | | Darrel Quit (Read error: Connection reset by peer) |
| 07:35:29 | | Darrel has joined |
| 10:53:06 | | starseeker Quit (Read error: No route to host) |
| 10:58:01 | | starseeker has joined |
| 11:04:52 | | Nothing_Much Quit (Ping timeout: 245 seconds) |
| 12:45:35 | | watusimoto has joined |
| 12:45:36 | | ChanServ sets mode +o |
| 13:41:31 | | Watusimoto_ has joined |
| 13:49:39 | | BFLogBot Commit: ffae2cf31b | Author: buckyballreaction | Message: Fix GoalZone/LoadoutZone Lua constructors |
| 13:49:40 | | BFLogBot Commit: 173f2ab5e4 | Author: buckyballreaction | Message: Fix a number of stack-index related bugs in the constructors of various game objects |
| 13:49:42 | | BFLogBot Commit: 3952dd1cbb | Author: buckyballreaction | Message: Add note about Lua getRandomNumber requiring parameters that are greather than or equal to zero |
| 13:55:47 | | BFLogBot Commit: bb460de082 | Author: buckyballreaction | Message: Fix minor error in Lua doc of getRandomNumber |
| 13:56:53 | | Watusimoto_ Quit (Ping timeout: 240 seconds) |
| 14:03:06 | | BFLogBot Commit: c8408674a6 | Author: buckyballreaction | Message: Add query param to GUP updater request if we're on Win64 |
| 14:39:39 | | LordDVG has joined |
| 15:07:05 | | raptor has joined |
| 15:07:06 | | ChanServ sets mode +o |
| 15:07:09 | raptor | good day! |
| 15:55:13 | | sam686 has joined |
| 15:55:13 | | ChanServ sets mode +v |
| 15:58:18 | | Nothing_Much has joined |
| 15:58:59 | | watusimoto Quit (Quit: Leaving.) |
| 16:26:07 | | watusimoto has joined |
| 16:26:17 | | ChanServ sets mode +o |
| 16:29:12 | watusimoto | hello |
| 16:33:01 | raptor | hello |
| 16:33:39 | raptor | I'm looking into compiling bfup for win64... but it looks like lots has changed since what was released for 019. Do you remember the extent of your changes to bfup? |
| 16:35:08 | watusimoto | I don't recall exactly what I did, but I think it was relatively minor. Is there any reason why we want to go 64 bit? And if so, any reason we can't just use our existing source? What do you mean by "lots has changed"? You mean in gup (where I stole code from)? |
| 16:35:20 | raptor | yes |
| 16:35:32 | raptor | looks like the gup xml does not have bitfighter info in it... |
| 16:36:41 | raptor | I'm shooting for a win64 release because... windows 10 is not going to be released for 32bit and will probably be dropping full 32bit support (may have partial support, whatever that means) |
| 16:36:47 | watusimoto | where did you find the gup sources? |
| 16:36:58 | raptor | in the 'updater' directory in our tree |
| 16:36:58 | watusimoto | sourceforge? |
| 16:37:08 | watusimoto | oh wait, now I am confused |
| 16:37:10 | raptor | no, just what's in our tree |
| 16:37:24 | watusimoto | gup in SF hasn't changed since 2010 |
| 16:37:55 | watusimoto | ok, so is there a problem with compiling our source 64 bit? |
| 16:38:45 | raptor | just that I want to do it, but I don't find bitfighter customizations in the XML source in the 'updater' folder |
| 16:40:17 | watusimoto | ok, obviously not using bfup.xml |
| 16:40:33 | raptor | there were source updates put here within ~2 years: http://svn.tuxfamily.org/viewvc.cgi/gup_trunk/ |
| 16:41:33 | raptor | it looks like you added source updates to our tree back in Jan/Feb |
| 16:42:54 | watusimoto | Look here |
| 16:42:55 | watusimoto | https://code.google.com/p/bitfighter/source/browse/#hg%2Fbuild%2Fwindows%2Finstaller%2Fupdater |
| 16:43:09 | watusimoto | there's our bfup.xml file |
| 16:43:14 | raptor | ah ha! |
| 16:43:39 | watusimoto | ah, I see |
| 16:43:47 | watusimoto | so we compile and build from the updater source |
| 16:44:00 | watusimoto | then copy the final exe into the install folder |
| 16:44:11 | watusimoto | and its only there that the xml file matters |
| 16:44:25 | raptor | ok, now i know what to look for... thanks! |
| 16:44:32 | watusimoto | the copy in the original location is never used, or perhaps only good for testing |
| 16:44:47 | raptor | yep, winmain.cpp even points to bfup.xml |
| 16:45:02 | watusimoto | so if we go 64 bit, we'll probably need new libcur.dll |
| 16:45:06 | watusimoto | libcurl.dll |
| 16:45:36 | raptor | i can do that - I have considerable experience compiling libraries on various systems now... thanks to bitfighter :) |
| 16:45:49 | watusimoto | maybe both if we continue to build a 32 bit version |
| 16:46:10 | watusimoto | feel free to rearrange things if you think you can make it less confusing |
| 16:46:29 | raptor | i was thinking of integrating bfup into CMake for windows only |
| 16:46:39 | watusimoto | yes, that would make sense |
| 16:46:54 | watusimoto | can we do a full windows release build from the cmd line? |
| 16:46:58 | watusimoto | with cmake? |
| 16:47:22 | raptor | almost - we have to integrate bfup and probably nsis, still |
| 16:47:39 | raptor | but otherwise, a full build with mingw/gcc is already possible |
| 16:47:54 | watusimoto | on windows? |
| 16:47:57 | raptor | yes |
| 16:48:00 | watusimoto | huh |
| 16:48:27 | watusimoto | so we (I) develop in vcc, but do the release builds with gcc |
| 16:49:12 | raptor | we could, but i 'm not sure of the state of gcc-based builds on windows. I suspect they force you to include the entire libstdc++ becasue of licensing issues |
| 16:49:21 | raptor | so that would make them much, much bigger |
| 16:49:36 | watusimoto | ok, can we do cmd line cmake building with vcc? |
| 16:50:13 | raptor | yes-ish... it's been a while since i've done it, though. I think you have to set up a special shell with lots of ENV variables set |
| 16:50:34 | watusimoto | ah, ok |
| 16:50:37 | watusimoto | well, nevermind |
| 16:59:49 | | Nothing_Much Quit (Remote host closed the connection) |
| 17:00:26 | | Nothing_Much has joined |
| 17:32:34 | | LordDVG Quit (Remote host closed the connection) |
| 17:33:51 | raptor | yay another major web bug! POODLE SSL protocol insecurity |
| 18:11:56 | raptor | I suppose it's good SSL 3.0 will be retired... |
| 18:12:05 | raptor | it's been a long time coming |
| 18:20:06 | | Darrel Quit (Read error: Connection reset by peer) |
| 18:20:23 | | Darrel has joined |
| 18:25:52 | watusimoto | poodles are cute! |
| 18:26:10 | raptor | they're like white footballs with legs! |
| 18:26:57 | watusimoto | with a buggy ssl implementation |
| 18:29:22 | | fordcars has joined |
| 18:29:26 | | fordcars Quit (Client Quit) |
| 18:29:55 | | fordcars has joined |
| 18:44:05 | raptor | so many of my coworkers are gone this week... I think several are hunting |
| 19:36:21 | | Watusimoto_ has joined |
| 19:45:33 | | Watusimoto__ has joined |
| 19:46:46 | | Watusimoto_ Quit (Ping timeout: 240 seconds) |
| 20:28:12 | | Watusimoto__ Quit (Ping timeout: 245 seconds) |
| 21:08:13 | | watusimoto Quit (Quit: Leaving.) |
| 22:08:58 | | Watusimoto has joined |
| 22:23:37 | | Watusimoto Quit (Ping timeout: 245 seconds) |
| 22:29:39 | | watusimoto has joined |
| 22:29:39 | | ChanServ sets mode +o |
| 22:42:11 | | Watusimoto_ has joined |
| 22:59:28 | | watusimoto Quit (Quit: Leaving.) |
| 23:00:36 | | Watusimoto_ Quit (Ping timeout: 244 seconds) |
| 23:33:42 | | Watusimoto has joined |
| 23:38:17 | | raptor Quit (Disconnected by services) |
| 23:38:34 | | raptor has joined |
| 23:38:34 | | ChanServ sets mode +o |
| 23:40:09 | raptor | good evening |
| 23:40:19 | raptor | on to 64bit compile of GUP! |
| 23:46:57 | raptor | sam686 / Watusimoto: I have an odd issue I can't seem to solve - |
| 23:47:24 | raptor | since moving to luajit, if you run a bad Lua script that throws a c++ exception, the exception string is never printed out |
| 23:47:39 | raptor | so if you do something like: local a = nil a.hello() |
| 23:47:41 | | Watusimoto Quit (Remote host closed the connection) |
| 23:48:38 | raptor | oops wrong exception |
| 23:48:47 | raptor | wrong example |
| 23:49:32 | raptor | this does it: o = SpeedZone.new("hello") |
| 23:50:13 | raptor | since that is calling a constructor with a bad argument in c++, it throws a LuaException with the exception string... but the string doesn't get printed out for some reason |