#bitfighter IRC Log

IRC Log for 2012-03-21

Timestamps are in GMT/BST.

00:48:17 koda Quit (Quit: I used to be chatting like you. Then I took an arrow in the knee)
01:09:15 sam686 Quit (Read error: Connection reset by peer)
01:13:32 sam686 has joined
01:13:32 ChanServ sets mode +v sam686
02:17:31 kodaws Quit (Read error: Connection reset by peer)
03:23:56 raptor has joined
03:23:57 ChanServ sets mode +o raptor
03:26:25 raptor hi sam686
03:32:54 raptor would you like to do some playtesting some time?
04:25:00 sam686 i was kind of buzy this week, but i guess i can do some play testing
04:25:09 raptor you're alive!!
04:26:20 raptor you can do some play testing with me now?
04:26:32 raptor if you're busy, then don't worry about it..
04:26:57 sam686 ok
04:27:35 sam686 one problem, f1 f5 f7 doesn't work anymore
04:33:33 LoneWolfy has joined
04:59:42 sam686 or not, it will take a little bit longer, i thought it was dome compiling..  (i guess i changed .h files to compile dedicated_master)
04:59:58 raptor oops
05:00:00 raptor ok
05:00:01 raptor no problem
05:01:18 sam686 got my dedicated bitfighter going on windows, still compiling non-dedicated
05:05:54 sam686 i did push my changes to fix dedicated compile, though..
05:07:35 raptor oops, sorry i put VideoSystem.cpp in the wrong place in your project
05:07:51 BFLogBot - Commit afe3284d4e10 | Author: sam8641 | Log: Fix dedicated compile, i guess dedicated doesn't need VideoSystem.cpp
05:07:53 sam686 dedicated doesn't need VideoSystem
05:08:01 raptor yes, correct
05:09:49 sam686 got the F5 / F7 / F1 buttons working again
05:09:59 raptor great!
05:12:53 BFLogBot - Commit df58de65cc25 | Author: buckyballreaction | Log: Rename Boost module kinetic component as 'Pulse'; be consistent in the code
05:32:35 raptor i added bugs here:  http://bitfighter.org/wiki/index.php/Running_Bug_List
05:32:44 raptor please add any you may have found..
05:32:47 sam686 ok
05:35:27 raptor good ngiht
05:35:59 raptor Quit ()
07:07:39 sam686 Quit (Ping timeout: 245 seconds)
07:18:48 Watusimoto has joined
07:59:17 Watusimoto Quit (Ping timeout: 246 seconds)
08:17:33 kodaws has joined
08:51:30 watusimoto has joined
08:51:30 ChanServ sets mode +o watusimoto
09:05:31 kodaws Quit (Ping timeout: 264 seconds)
09:05:51 kodaws has joined
09:11:49 kodaws Quit (Ping timeout: 244 seconds)
09:30:51 kodaws has joined
10:19:20 kodaws Quit (Ping timeout: 272 seconds)
10:24:12 kodaws has joined
12:21:59 LordDVG has joined
12:42:55 raptor has joined
12:42:55 ChanServ sets mode +o raptor
13:08:59 raptor Quit ()
13:23:34 LoneWolfy Quit (Ping timeout: 260 seconds)
13:45:03 LoneWolfy has joined
15:14:54 LordDVG Quit (Remote host closed the connection)
15:16:54 LordDVG has joined
15:42:42 raptor has joined
15:42:52 ChanServ sets mode +o raptor
15:43:00 raptor good mronign!
16:07:47 watusimoto  good mronign
16:07:57 raptor hi
16:08:02 watusimoto got your emai
16:08:03 watusimoto l
16:08:06 watusimoto grrr
16:08:10 raptor yeah...
16:08:37 raptor did you test any of the nexus bugs?  the one with the timer near zero is trippy
16:08:44 watusimoto I totally understand the flashing problem -- that may actually be fixed on my machine
16:10:27 watusimoto and I think I understand the can't drop flags problem as well
16:10:31 watusimoto both are likely related
16:10:57 watusimoto can't drop flags is because client's notion of when nexus should open is different than server's
16:11:12 watusimoto client updates nexus visually, but can't drop flags until the server approves
16:11:31 raptor ok
16:11:44 watusimoto I guess I know what I get to work on tonight :-(
16:11:51 raptor the other problems may be my fault...  i'm not sure\
16:12:02 raptor because i know i have played with the repair code a little
16:13:08 watusimoto I marked two items on the bug list that we can potentially defer
16:13:39 raptor really?
16:13:58 watusimoto one is semi-done, perhaps done enough (if it withstands testing)
16:15:27 raptor google code issue?
16:15:37 watusimoto ?
16:19:27 raptor the items you marked, which bug list are you looking at?
16:20:40 watusimoto oh, sorry, running bug list
16:20:49 watusimoto #5 and #8 at the bottom
16:20:59 raptor ha!
16:26:21 raptor i was hoping #8 was the most important one...
16:30:52 watusimoto :-)
16:55:07 Watusimoto_ has joined
17:28:13 raptor I fixed the fullscreen problem on mac with SDL2 - now I have to figure out how to do the text input
17:28:30 raptor if you defer #8, maybe i'll have time...  :)
17:28:39 watusimoto exactly my thoughts!
17:29:05 watusimoto alas, I added a new bug to the list (probably exists in 016, not in 015a), and another to my "paper list"
17:36:36 raptor what did you add to the paper list?
17:40:46 watusimoto easeir to fix than describe
17:40:52 raptor okey doke
17:40:59 watusimoto has to do with well... you'll see when I fix it
17:41:04 watusimoto error messages
17:41:09 watusimoto cascading and crashing
17:41:15 watusimoto easy to fix
17:41:21 watusimoto hard to reproduce
17:41:23 kodaws Quit (Quit: Sto andando via)
17:41:27 raptor ok
17:43:00 watusimoto out of here... later
17:44:22 raptor bye
17:47:44 watusimoto Quit (Ping timeout: 272 seconds)
17:50:26 LordDVG Quit (Ping timeout: 246 seconds)
17:59:40 Watusimoto_ Quit (Ping timeout: 252 seconds)
18:51:45 LoneWolfy Quit (Read error: Connection reset by peer)
18:52:54 Watusimoto has joined
19:29:27 BFLogBot - Commit ba372a5e8a4b | Author: buckyballreaction | Log: Fix repair radius
19:30:03 raptor the other repair bug will require a bisect  :(
19:44:57 raptor ok, fixed it!
19:46:19 Watusimoto good!!
19:46:50 raptor sneaky bugs
19:47:19 Watusimoto tell me about it :-(
19:48:50 Watusimoto that settime .1 bug is really sneaky
19:49:01 Watusimoto basically, U32 math underflows
19:49:09 raptor what
19:49:16 raptor thats goofy
19:49:30 BFLogBot - Commit e781428d6c1b | Author: buckyballreaction | Log: Fix energy recharging when a module is in use
19:49:31 Watusimoto x - y < 0
19:49:37 Watusimoto z = x - y
19:49:42 Watusimoto when z is U32...
19:49:53 Watusimoto suddenly z > x
19:50:05 Watusimoto causing things to freak out
20:00:11 raptor now i have to rewrite part of the input system...
20:05:35 Watusimoto better than rewriting the timer crap... again...
20:05:51 Watusimoto Sunday, Monday, Tuesday, ... now Wedenesday
20:05:53 raptor i'm sorry for your pain...
20:06:02 Watusimoto I wish I had taken the easy way out
20:06:14 Watusimoto sure, I've done harder things
20:06:27 Watusimoto but really... even when this works it will be utterly unrewarding
20:07:35 raptor are you going to do the one-timer-to-rule-them-all ?
20:14:48 Watusimoto I already did
20:14:56 Watusimoto oh, you mean the ongoing timer
20:15:05 Watusimoto for all games
20:15:08 raptor yes
20:15:09 Watusimoto not now
20:15:11 raptor ok
20:15:16 Watusimoto I'm just going to make this work
20:15:26 Watusimoto then have a big slug of whiskey
20:15:27 raptor i wasn't sure if that'd be more or less work than what you're doing...
20:15:38 Watusimoto it would be more
20:15:46 Watusimoto here's a design question
20:15:58 Watusimoto only asking because I can and it would be easy
20:16:25 Watusimoto in nexus games, when the nexus is open, and the game will end before it closes, do we want to print a special message in the timer slot?
20:16:39 Watusimoto likewise when nexus is closed, and will not be reopening
20:17:05 Watusimoto right now, the times "snap" to the end of the game
20:17:15 raptor oh really?
20:17:29 raptor i've played loads of levels where the nexus closes and won't open again
20:17:30 Watusimoto so that if nexus is normally open for 30 secs and opens at 0:10, it will say "Nexus closes in 10"\
20:17:33 raptor and there's still time left
20:17:34 Watusimoto which is actually not bad
20:17:55 raptor yeah, i think eventually that would be good
20:17:58 Watusimoto but if it's closed for 30 secs, and closes at 0:10, it will say "nexus opens in 10"
20:18:01 Watusimoto which is a lie
20:18:16 Watusimoto so maybe it's only this second situatino that matters
20:18:25 raptor lie = bad, right?
20:18:29 Watusimoto I think so
20:18:34 raptor me too\
20:18:35 Watusimoto if it will never open again
20:18:55 Watusimoto then...  "nexus closed for the season"
20:19:03 raptor haha
20:19:04 Watusimoto oh brother
20:19:16 Watusimoto I'll bet there;s a bug
20:19:30 Watusimoto I made it snap to 0 to fix the underflow bug
20:19:43 Watusimoto so the changing time would never be negative
20:19:46 Watusimoto but
20:20:10 Watusimoto if it closes for 30, and closes at 0:10, that means the cycle would end at -0:20, right?
20:20:19 Watusimoto so we snap that to 0 and call it good
20:20:30 raptor ok
20:20:36 Watusimoto all fine and dandy until someone adds 3 mins to the game
20:20:42 raptor ah
20:20:44 raptor wonderful
20:20:45 Watusimoto now the nexus should close at 2:40
20:20:56 Watusimoto but will probably still want to close at 3:00
20:21:07 Watusimoto because I take the existing close time and add 3:00 to it
20:21:23 Watusimoto everything I do falls into some trap or the other
20:21:32 Watusimoto every fix has its own pitfalls
20:21:35 raptor blech
20:21:41 Watusimoto that's why this has been such a nightmare
20:21:50 Watusimoto ok, well, to my question...
20:22:02 Watusimoto if the nexus is closed for the rest of the game, what should it say?
20:22:40 Watusimoto Normal message is "Nexus opens in 0:10"
20:22:54 Watusimoto Maybe just "Nexus is closed."
20:23:53 raptor or 'Game ends'
20:24:07 Watusimoto If we set the nexus to never open, the message says "Nexus never opens"
20:24:16 Watusimoto "Nexus closed until game ends"?
20:25:01 Watusimoto "Nexus closed through end of game"
20:25:23 raptor Nexus closed until end of game
20:25:36 Watusimoto good enough
20:27:13 Watusimoto now to test that purported error condition I theorized
20:37:44 raptor oh no...  i have to look at UIEditor...
20:46:22 koda has joined
20:49:19 raptor we made a mistake with coupling the input codes and the ascii text input into all our methods...
20:55:41 Watusimoto how so?
20:56:50 raptor other than that is the only way to do it with SDL 2, I think that they were right to treat character input as something different than a key press
20:57:12 raptor we do for the most part in our code
20:57:37 raptor except for the method signature of  onKeyDown(InputCode inputCode, char ascii)
20:57:40 Watusimoto they are different, agreed
20:57:44 Watusimoto that came from glut
20:57:52 Watusimoto it wasn't really our decision
20:57:56 raptor ah ok
20:58:15 Watusimoto i.e. not really my decision, as you weren;t around then:-)
20:58:25 Watusimoto well, you were around
20:58:31 Watusimoto just not around here
20:58:56 Watusimoto except that here is meaningluess when you're in UT and I'm in Lux
20:58:57 Watusimoto but you get the idea
21:00:44 raptor hehe
21:03:12 raptor phoew!  got past UIEditor...
21:31:08 Watusimoto did you know you can set the game time after the game has ended?
21:31:28 raptor no
21:31:30 raptor cool
21:31:40 raptor what on earth is UIMenus.cpp:564 for??
21:32:07 Watusimoto (U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii)) ||
21:32:07 Watusimoto       processMenuSpecificKeys(inputCode, ascii) ||
21:32:07 Watusimoto       processKeys(inputCode, ascii);
21:32:08 Watusimoto ??
21:32:17 raptor what crazy syntax is that
21:32:45 Watusimoto ah yes
21:32:47 Watusimoto ok
21:33:00 Watusimoto it's Perl style
21:33:07 Watusimoto (seriously)
21:33:35 Watusimoto it's short hand for if(xxx) {} else if(dfdf) {} else {}
21:33:44 Watusimoto except with out all the ifs
21:34:07 Watusimoto it just evaluates the logic, until one of the or conditions evaluates true
21:34:30 raptor written for maximum obscurity
21:34:37 Watusimoto you can rewrite if you like
21:34:43 raptor i think i will  :)
21:34:47 Watusimoto but it's not obscure for me :-)
21:35:07 Watusimoto but yeah, I think I see why it's confusing
21:36:38 raptor is this equivalent?:
21:36:39 raptor    if(U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii))
21:36:41 raptor       processMenuSpecificKeys(inputCode, ascii);
21:36:42 raptor    else
21:36:44 raptor       processKeys(inputCode, ascii);
21:37:12 Watusimoto no
21:37:53 Watusimoto I'll rewrite... just a sec
21:38:49 Watusimoto    if(U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii))
21:38:50 Watusimoto    {
21:38:50 Watusimoto       // Do nothing
21:38:50 Watusimoto    }
21:38:50 Watusimoto    else if(processMenuSpecificKeys(inputCode, ascii))
21:38:50 Watusimoto    {
21:38:51 Watusimoto       // Do nothing
21:38:53 Watusimoto    }
21:38:55 Watusimoto    else
21:38:58 Watusimoto       processKeys(inputCode, ascii);
21:39:16 Watusimoto you can see why I didn;t like the C++ syntax...
21:39:24 Watusimoto it's confusing too
21:40:03 Watusimoto I'm not altering the file -- if you like this better, you can paste it in on your end
21:42:21 Watusimoto possibly better?
21:42:23 Watusimoto    if(!(U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii)))
21:42:23 Watusimoto       if(!processMenuSpecificKeys(inputCode, ascii))
21:42:23 Watusimoto          processKeys(inputCode, ascii);
21:42:32 Watusimoto all terrible
21:43:51 raptor ha ha ok
21:43:56 Watusimoto or more verbose
21:43:57 Watusimoto    bool keyHandled = (U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii));
21:43:57 Watusimoto    if(!keyHandled)
21:43:57 Watusimoto       keyHandled = !processMenuSpecificKeys(inputCode, ascii)
21:43:57 Watusimoto    if(!keyHandled)
21:43:58 Watusimoto       processKeys(inputCode, ascii);
21:44:15 Watusimoto that last one is probably the clearest
21:44:31 Watusimoto oops... take out the ! in the second keyHandled
21:46:54 Watusimoto or stick with the orginal, but add this comment
21:46:55 Watusimoto / Try all three key handlers in turn until we find one that returns true, signaling that it processed the key
21:47:55 Watusimoto or
21:47:56 Watusimoto    if((U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii)) ||
21:47:56 Watusimoto       processMenuSpecificKeys(inputCode, ascii) ||
21:47:56 Watusimoto       processKeys(inputCode, ascii))
21:47:57 Watusimoto    {
21:47:59 Watusimoto       // Do nothing
21:48:01 Watusimoto    }
21:48:05 raptor hahaha
21:48:21 Watusimoto else
21:48:23 Watusimoto {
21:48:30 Watusimoto    // Do nothing here, either
21:48:36 Watusimoto }
21:49:03 raptor this seems clearest to me:  http://pastie.org/3644094
21:49:35 Watusimoto looks great
21:49:42 Watusimoto I can almost make out what it does
21:50:35 Watusimoto there may be one other place I used this logic, but generally I shied away from it
21:51:49 raptor even better?:  http://pastie.org/3644104
21:52:15 Watusimoto yes, but wrong
21:52:21 raptor rats
21:52:32 Watusimoto that outer if condition only applies to the first keyhandled thing
21:52:38 raptor ah ok
21:52:40 Watusimoto the other two happen either way
21:52:51 raptor ok
21:53:03 Watusimoto but other than that, pleasantly clear
21:56:16 raptor so like this:  http://pastie.org/3644135
21:57:20 raptor and now that i think about it, you're right  c/c++ doesn't really have a good negative boolean expression syntax
22:03:11 Watusimoto I think this was best
22:03:12 Watusimoto http://pastie.org/3644094
22:03:16 Watusimoto i.e. your first
22:07:08 raptor okey doke
22:39:38 raptor well, it compiled....
22:48:17 raptor i sure broke stuff
22:48:29 raptor well, i gotta go.  see you later
22:49:06 raptor Quit ()
23:02:39 Watusimoto later
23:09:53 BFLogBot - Commit 71c864ca8f97 | Author: watusim...@bitfighter.org | Log: I *think* this fixes the nexus timing issues... I'm leaving in my debugging statements for the moment -- if you are hosting on your machine, it will from time to time print out to the console the client and server opinions about when the nexus should next change phase.  As long as these numbers are identical, you won't get the "can't return flags to the nexus" error.  If they diverge, there is trouble.  Tried to both combine similar concepts and stop overloading dissimilar ones in an attempt to get a handle on this problem.  Will test further tomorrow.
23:09:54 BFLogBot - Commit f122fe3e220f | Author: watusim...@bitfighter.org | Log: Merge
23:20:51 raptor has joined
23:20:51 ChanServ sets mode +o raptor
23:47:30 sam686 has joined
23:47:30 ChanServ sets mode +v sam686

Index Search ←Prev date Next date→

These logs were automatically created by BFLogBot on irc.freenode.net.

00:48:17		koda Quit (Quit: I used to be chatting like you. Then I took an arrow in the knee)
01:09:15		sam686 Quit (Read error: Connection reset by peer)
01:13:32		sam686 has joined
01:13:32		ChanServ sets mode +v sam686
02:17:31		kodaws Quit (Read error: Connection reset by peer)
03:23:56		raptor has joined
03:23:57		ChanServ sets mode +o raptor
03:26:25	raptor	hi sam686
03:32:54	raptor	would you like to do some playtesting some time?
04:25:00	sam686	i was kind of buzy this week, but i guess i can do some play testing
04:25:09	raptor	you're alive!!
04:26:20	raptor	you can do some play testing with me now?
04:26:32	raptor	if you're busy, then don't worry about it..
04:26:57	sam686	ok
04:27:35	sam686	one problem, f1 f5 f7 doesn't work anymore
04:33:33		LoneWolfy has joined
04:59:42	sam686	or not, it will take a little bit longer, i thought it was dome compiling.. (i guess i changed .h files to compile dedicated_master)
04:59:58	raptor	oops
05:00:00	raptor	ok
05:00:01	raptor	no problem
05:01:18	sam686	got my dedicated bitfighter going on windows, still compiling non-dedicated
05:05:54	sam686	i did push my changes to fix dedicated compile, though..
05:07:35	raptor	oops, sorry i put VideoSystem.cpp in the wrong place in your project
05:07:51		BFLogBot - Commit afe3284d4e10 \| Author: sam8641 \| Log: Fix dedicated compile, i guess dedicated doesn't need VideoSystem.cpp
05:07:53	sam686	dedicated doesn't need VideoSystem
05:08:01	raptor	yes, correct
05:09:49	sam686	got the F5 / F7 / F1 buttons working again
05:09:59	raptor	great!
05:12:53		BFLogBot - Commit df58de65cc25 \| Author: buckyballreaction \| Log: Rename Boost module kinetic component as 'Pulse'; be consistent in the code
05:32:35	raptor	i added bugs here: http://bitfighter.org/wiki/index.php/Running_Bug_List
05:32:44	raptor	please add any you may have found..
05:32:47	sam686	ok
05:35:27	raptor	good ngiht
05:35:59		raptor Quit ()
07:07:39		sam686 Quit (Ping timeout: 245 seconds)
07:18:48		Watusimoto has joined
07:59:17		Watusimoto Quit (Ping timeout: 246 seconds)
08:17:33		kodaws has joined
08:51:30		watusimoto has joined
08:51:30		ChanServ sets mode +o watusimoto
09:05:31		kodaws Quit (Ping timeout: 264 seconds)
09:05:51		kodaws has joined
09:11:49		kodaws Quit (Ping timeout: 244 seconds)
09:30:51		kodaws has joined
10:19:20		kodaws Quit (Ping timeout: 272 seconds)
10:24:12		kodaws has joined
12:21:59		LordDVG has joined
12:42:55		raptor has joined
12:42:55		ChanServ sets mode +o raptor
13:08:59		raptor Quit ()
13:23:34		LoneWolfy Quit (Ping timeout: 260 seconds)
13:45:03		LoneWolfy has joined
15:14:54		LordDVG Quit (Remote host closed the connection)
15:16:54		LordDVG has joined
15:42:42		raptor has joined
15:42:52		ChanServ sets mode +o raptor
15:43:00	raptor	good mronign!
16:07:47	watusimoto	good mronign
16:07:57	raptor	hi
16:08:02	watusimoto	got your emai
16:08:03	watusimoto	l
16:08:06	watusimoto	grrr
16:08:10	raptor	yeah...
16:08:37	raptor	did you test any of the nexus bugs? the one with the timer near zero is trippy
16:08:44	watusimoto	I totally understand the flashing problem -- that may actually be fixed on my machine
16:10:27	watusimoto	and I think I understand the can't drop flags problem as well
16:10:31	watusimoto	both are likely related
16:10:57	watusimoto	can't drop flags is because client's notion of when nexus should open is different than server's
16:11:12	watusimoto	client updates nexus visually, but can't drop flags until the server approves
16:11:31	raptor	ok
16:11:44	watusimoto	I guess I know what I get to work on tonight :-(
16:11:51	raptor	the other problems may be my fault... i'm not sure\
16:12:02	raptor	because i know i have played with the repair code a little
16:13:08	watusimoto	I marked two items on the bug list that we can potentially defer
16:13:39	raptor	really?
16:13:58	watusimoto	one is semi-done, perhaps done enough (if it withstands testing)
16:15:27	raptor	google code issue?
16:15:37	watusimoto	?
16:19:27	raptor	the items you marked, which bug list are you looking at?
16:20:40	watusimoto	oh, sorry, running bug list
16:20:49	watusimoto	#5 and #8 at the bottom
16:20:59	raptor	ha!
16:26:21	raptor	i was hoping #8 was the most important one...
16:30:52	watusimoto	:-)
16:55:07		Watusimoto_ has joined
17:28:13	raptor	I fixed the fullscreen problem on mac with SDL2 - now I have to figure out how to do the text input
17:28:30	raptor	if you defer #8, maybe i'll have time... :)
17:28:39	watusimoto	exactly my thoughts!
17:29:05	watusimoto	alas, I added a new bug to the list (probably exists in 016, not in 015a), and another to my "paper list"
17:36:36	raptor	what did you add to the paper list?
17:40:46	watusimoto	easeir to fix than describe
17:40:52	raptor	okey doke
17:40:59	watusimoto	has to do with well... you'll see when I fix it
17:41:04	watusimoto	error messages
17:41:09	watusimoto	cascading and crashing
17:41:15	watusimoto	easy to fix
17:41:21	watusimoto	hard to reproduce
17:41:23		kodaws Quit (Quit: Sto andando via)
17:41:27	raptor	ok
17:43:00	watusimoto	out of here... later
17:44:22	raptor	bye
17:47:44		watusimoto Quit (Ping timeout: 272 seconds)
17:50:26		LordDVG Quit (Ping timeout: 246 seconds)
17:59:40		Watusimoto_ Quit (Ping timeout: 252 seconds)
18:51:45		LoneWolfy Quit (Read error: Connection reset by peer)
18:52:54		Watusimoto has joined
19:29:27		BFLogBot - Commit ba372a5e8a4b \| Author: buckyballreaction \| Log: Fix repair radius
19:30:03	raptor	the other repair bug will require a bisect :(
19:44:57	raptor	ok, fixed it!
19:46:19	Watusimoto	good!!
19:46:50	raptor	sneaky bugs
19:47:19	Watusimoto	tell me about it :-(
19:48:50	Watusimoto	that settime .1 bug is really sneaky
19:49:01	Watusimoto	basically, U32 math underflows
19:49:09	raptor	what
19:49:16	raptor	thats goofy
19:49:30		BFLogBot - Commit e781428d6c1b \| Author: buckyballreaction \| Log: Fix energy recharging when a module is in use
19:49:31	Watusimoto	x - y < 0
19:49:37	Watusimoto	z = x - y
19:49:42	Watusimoto	when z is U32...
19:49:53	Watusimoto	suddenly z > x
19:50:05	Watusimoto	causing things to freak out
20:00:11	raptor	now i have to rewrite part of the input system...
20:05:35	Watusimoto	better than rewriting the timer crap... again...
20:05:51	Watusimoto	Sunday, Monday, Tuesday, ... now Wedenesday
20:05:53	raptor	i'm sorry for your pain...
20:06:02	Watusimoto	I wish I had taken the easy way out
20:06:14	Watusimoto	sure, I've done harder things
20:06:27	Watusimoto	but really... even when this works it will be utterly unrewarding
20:07:35	raptor	are you going to do the one-timer-to-rule-them-all ?
20:14:48	Watusimoto	I already did
20:14:56	Watusimoto	oh, you mean the ongoing timer
20:15:05	Watusimoto	for all games
20:15:08	raptor	yes
20:15:09	Watusimoto	not now
20:15:11	raptor	ok
20:15:16	Watusimoto	I'm just going to make this work
20:15:26	Watusimoto	then have a big slug of whiskey
20:15:27	raptor	i wasn't sure if that'd be more or less work than what you're doing...
20:15:38	Watusimoto	it would be more
20:15:46	Watusimoto	here's a design question
20:15:58	Watusimoto	only asking because I can and it would be easy
20:16:25	Watusimoto	in nexus games, when the nexus is open, and the game will end before it closes, do we want to print a special message in the timer slot?
20:16:39	Watusimoto	likewise when nexus is closed, and will not be reopening
20:17:05	Watusimoto	right now, the times "snap" to the end of the game
20:17:15	raptor	oh really?
20:17:29	raptor	i've played loads of levels where the nexus closes and won't open again
20:17:30	Watusimoto	so that if nexus is normally open for 30 secs and opens at 0:10, it will say "Nexus closes in 10"\
20:17:33	raptor	and there's still time left
20:17:34	Watusimoto	which is actually not bad
20:17:55	raptor	yeah, i think eventually that would be good
20:17:58	Watusimoto	but if it's closed for 30 secs, and closes at 0:10, it will say "nexus opens in 10"
20:18:01	Watusimoto	which is a lie
20:18:16	Watusimoto	so maybe it's only this second situatino that matters
20:18:25	raptor	lie = bad, right?
20:18:29	Watusimoto	I think so
20:18:34	raptor	me too\
20:18:35	Watusimoto	if it will never open again
20:18:55	Watusimoto	then... "nexus closed for the season"
20:19:03	raptor	haha
20:19:04	Watusimoto	oh brother
20:19:16	Watusimoto	I'll bet there;s a bug
20:19:30	Watusimoto	I made it snap to 0 to fix the underflow bug
20:19:43	Watusimoto	so the changing time would never be negative
20:19:46	Watusimoto	but
20:20:10	Watusimoto	if it closes for 30, and closes at 0:10, that means the cycle would end at -0:20, right?
20:20:19	Watusimoto	so we snap that to 0 and call it good
20:20:30	raptor	ok
20:20:36	Watusimoto	all fine and dandy until someone adds 3 mins to the game
20:20:42	raptor	ah
20:20:44	raptor	wonderful
20:20:45	Watusimoto	now the nexus should close at 2:40
20:20:56	Watusimoto	but will probably still want to close at 3:00
20:21:07	Watusimoto	because I take the existing close time and add 3:00 to it
20:21:23	Watusimoto	everything I do falls into some trap or the other
20:21:32	Watusimoto	every fix has its own pitfalls
20:21:35	raptor	blech
20:21:41	Watusimoto	that's why this has been such a nightmare
20:21:50	Watusimoto	ok, well, to my question...
20:22:02	Watusimoto	if the nexus is closed for the rest of the game, what should it say?
20:22:40	Watusimoto	Normal message is "Nexus opens in 0:10"
20:22:54	Watusimoto	Maybe just "Nexus is closed."
20:23:53	raptor	or 'Game ends'
20:24:07	Watusimoto	If we set the nexus to never open, the message says "Nexus never opens"
20:24:16	Watusimoto	"Nexus closed until game ends"?
20:25:01	Watusimoto	"Nexus closed through end of game"
20:25:23	raptor	Nexus closed until end of game
20:25:36	Watusimoto	good enough
20:27:13	Watusimoto	now to test that purported error condition I theorized
20:37:44	raptor	oh no... i have to look at UIEditor...
20:46:22		koda has joined
20:49:19	raptor	we made a mistake with coupling the input codes and the ascii text input into all our methods...
20:55:41	Watusimoto	how so?
20:56:50	raptor	other than that is the only way to do it with SDL 2, I think that they were right to treat character input as something different than a key press
20:57:12	raptor	we do for the most part in our code
20:57:37	raptor	except for the method signature of onKeyDown(InputCode inputCode, char ascii)
20:57:40	Watusimoto	they are different, agreed
20:57:44	Watusimoto	that came from glut
20:57:52	Watusimoto	it wasn't really our decision
20:57:56	raptor	ah ok
20:58:15	Watusimoto	i.e. not really my decision, as you weren;t around then:-)
20:58:25	Watusimoto	well, you were around
20:58:31	Watusimoto	just not around here
20:58:56	Watusimoto	except that here is meaningluess when you're in UT and I'm in Lux
20:58:57	Watusimoto	but you get the idea
21:00:44	raptor	hehe
21:03:12	raptor	phoew! got past UIEditor...
21:31:08	Watusimoto	did you know you can set the game time after the game has ended?
21:31:28	raptor	no
21:31:30	raptor	cool
21:31:40	raptor	what on earth is UIMenus.cpp:564 for??
21:32:07	Watusimoto	(U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii)) \|\|
21:32:07	Watusimoto	processMenuSpecificKeys(inputCode, ascii) \|\|
21:32:07	Watusimoto	processKeys(inputCode, ascii);
21:32:08	Watusimoto	??
21:32:17	raptor	what crazy syntax is that
21:32:45	Watusimoto	ah yes
21:32:47	Watusimoto	ok
21:33:00	Watusimoto	it's Perl style
21:33:07	Watusimoto	(seriously)
21:33:35	Watusimoto	it's short hand for if(xxx) {} else if(dfdf) {} else {}
21:33:44	Watusimoto	except with out all the ifs
21:34:07	Watusimoto	it just evaluates the logic, until one of the or conditions evaluates true
21:34:30	raptor	written for maximum obscurity
21:34:37	Watusimoto	you can rewrite if you like
21:34:43	raptor	i think i will :)
21:34:47	Watusimoto	but it's not obscure for me :-)
21:35:07	Watusimoto	but yeah, I think I see why it's confusing
21:36:38	raptor	is this equivalent?:
21:36:39	raptor	if(U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii))
21:36:41	raptor	processMenuSpecificKeys(inputCode, ascii);
21:36:42	raptor	else
21:36:44	raptor	processKeys(inputCode, ascii);
21:37:12	Watusimoto	no
21:37:53	Watusimoto	I'll rewrite... just a sec
21:38:49	Watusimoto	if(U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii))
21:38:50	Watusimoto	{
21:38:50	Watusimoto	// Do nothing
21:38:50	Watusimoto	}
21:38:50	Watusimoto	else if(processMenuSpecificKeys(inputCode, ascii))
21:38:50	Watusimoto	{
21:38:51	Watusimoto	// Do nothing
21:38:53	Watusimoto	}
21:38:55	Watusimoto	else
21:38:58	Watusimoto	processKeys(inputCode, ascii);
21:39:16	Watusimoto	you can see why I didn;t like the C++ syntax...
21:39:24	Watusimoto	it's confusing too
21:40:03	Watusimoto	I'm not altering the file -- if you like this better, you can paste it in on your end
21:42:21	Watusimoto	possibly better?
21:42:23	Watusimoto	if(!(U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii)))
21:42:23	Watusimoto	if(!processMenuSpecificKeys(inputCode, ascii))
21:42:23	Watusimoto	processKeys(inputCode, ascii);
21:42:32	Watusimoto	all terrible
21:43:51	raptor	ha ha ok
21:43:56	Watusimoto	or more verbose
21:43:57	Watusimoto	bool keyHandled = (U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii));
21:43:57	Watusimoto	if(!keyHandled)
21:43:57	Watusimoto	keyHandled = !processMenuSpecificKeys(inputCode, ascii)
21:43:57	Watusimoto	if(!keyHandled)
21:43:58	Watusimoto	processKeys(inputCode, ascii);
21:44:15	Watusimoto	that last one is probably the clearest
21:44:31	Watusimoto	oops... take out the ! in the second keyHandled
21:46:54	Watusimoto	or stick with the orginal, but add this comment
21:46:55	Watusimoto	/ Try all three key handlers in turn until we find one that returns true, signaling that it processed the key
21:47:55	Watusimoto	or
21:47:56	Watusimoto	if((U32(selectedIndex) < U32(mMenuItems.size()) && mMenuItems[selectedIndex]->handleKey(inputCode, ascii)) \|\|
21:47:56	Watusimoto	processMenuSpecificKeys(inputCode, ascii) \|\|
21:47:56	Watusimoto	processKeys(inputCode, ascii))
21:47:57	Watusimoto	{
21:47:59	Watusimoto	// Do nothing
21:48:01	Watusimoto	}
21:48:05	raptor	hahaha
21:48:21	Watusimoto	else
21:48:23	Watusimoto	{
21:48:30	Watusimoto	// Do nothing here, either
21:48:36	Watusimoto	}
21:49:03	raptor	this seems clearest to me: http://pastie.org/3644094
21:49:35	Watusimoto	looks great
21:49:42	Watusimoto	I can almost make out what it does
21:50:35	Watusimoto	there may be one other place I used this logic, but generally I shied away from it
21:51:49	raptor	even better?: http://pastie.org/3644104
21:52:15	Watusimoto	yes, but wrong
21:52:21	raptor	rats
21:52:32	Watusimoto	that outer if condition only applies to the first keyhandled thing
21:52:38	raptor	ah ok
21:52:40	Watusimoto	the other two happen either way
21:52:51	raptor	ok
21:53:03	Watusimoto	but other than that, pleasantly clear
21:56:16	raptor	so like this: http://pastie.org/3644135
21:57:20	raptor	and now that i think about it, you're right c/c++ doesn't really have a good negative boolean expression syntax
22:03:11	Watusimoto	I think this was best
22:03:12	Watusimoto	http://pastie.org/3644094
22:03:16	Watusimoto	i.e. your first
22:07:08	raptor	okey doke
22:39:38	raptor	well, it compiled....
22:48:17	raptor	i sure broke stuff
22:48:29	raptor	well, i gotta go. see you later
22:49:06		raptor Quit ()
23:02:39	Watusimoto	later
23:09:53		BFLogBot - Commit 71c864ca8f97 \| Author: watusim...@bitfighter.org \| Log: I think this fixes the nexus timing issues... I'm leaving in my debugging statements for the moment -- if you are hosting on your machine, it will from time to time print out to the console the client and server opinions about when the nexus should next change phase. As long as these numbers are identical, you won't get the "can't return flags to the nexus" error. If they diverge, there is trouble. Tried to both combine similar concepts and stop overloading dissimilar ones in an attempt to get a handle on this problem. Will test further tomorrow.
23:09:54		BFLogBot - Commit f122fe3e220f \| Author: watusim...@bitfighter.org \| Log: Merge
23:20:51		raptor has joined
23:20:51		ChanServ sets mode +o raptor
23:47:30		sam686 has joined
23:47:30		ChanServ sets mode +v sam686