#bitfighter IRC Log

IRC Log for 2012-08-05

Timestamps are in GMT/BST.

00:11:14 Little_Apple Quit (Ping timeout: 245 seconds)
00:33:18 raptor Quit ()
01:02:59 raptor has joined
01:02:59 ChanServ sets mode +o raptor
01:34:06 raptor Quit (Read error: Connection reset by peer)
01:46:04 raptor has joined
01:46:04 ChanServ sets mode +o raptor
01:59:52 raptor Quit ()
03:56:49 raptor has joined
03:56:49 ChanServ sets mode +o raptor
05:08:27 raptor Quit ()
06:29:21 Watusimoto has joined
08:32:07 Watusimoto Quit (Ping timeout: 246 seconds)
09:19:17 sam686 Quit (Ping timeout: 245 seconds)
09:35:20 Watusimoto has joined
10:03:32 LordDVG has joined
10:41:17 LordDVG Quit (Remote host closed the connection)
10:58:03 LordDVG has joined
11:21:11 LordDVG Quit (Remote host closed the connection)
12:17:04 Watusimoto Quit (Ping timeout: 246 seconds)
12:23:44 Watusimoto has joined
14:04:02 raptor has joined
14:04:03 ChanServ sets mode +o raptor
14:04:10 raptor buenos!
14:33:04 Watusimoto hi
14:37:18 raptor i
14:37:20 raptor hi
14:37:43 raptor how was two week away from bitfighter?
14:38:08 Watusimoto exhausting!
14:38:38 Watusimoto I had my birthday while we were away, and today, my oldest son gave me a book of Bitfighter ideas
14:38:49 raptor haha
14:38:55 raptor happy birthday
14:53:53 raptor you should test the heat-seeker with me  :)
14:59:23 Watusimoto I need to update and build; let me try doing that
15:06:29 Watusimoto ok, updating
15:06:39 Watusimoto took me a while to get all my tools started up
15:06:50 raptor finally shut down your computer for once?
15:07:43 Watusimoto crashed just before I left
15:07:54 Watusimoto ok, building
15:07:58 raptor that's one wat to do it..
15:08:02 raptor way
15:15:09 Watusimoto ok, built; running.  you host?
15:15:15 raptor yes, i'm hosting
15:15:32 raptor if too much lag, i can set it up on the master
15:15:45 Watusimoto punching...
15:15:52 Watusimoto fail
15:16:10 Watusimoto now seeing you (?) as ping timed out
15:16:20 raptor ok, compiling on master...
15:16:21 Watusimoto 172.174?
15:16:26 raptor nope
15:16:28 raptor 69.169...
15:16:43 Watusimoto I see you, but ping timed out
15:17:08 Watusimoto this menu music is drving me crazy!
15:17:22 Watusimoto we need a longer loop
15:17:24 raptor haha
15:18:14 Watusimoto this won't work... want to try on the master?
15:18:24 raptor yes, trying to get dedicated to compile...
15:19:05 raptor fixing an error...
15:19:11 Watusimoto muted the music
15:21:20 raptor huh, another error..
15:23:56 raptor man...  dedicated is broken all over...
15:25:06 raptor 4th error...
15:27:25 raptor 5th
15:27:31 raptor this one is mine  :-/
15:27:59 Watusimoto Maybe we need to create an automated test build when we checkin that builds dedicated and emails errors
15:29:20 raptor yay it compiled
15:29:23 raptor ok, back to master...
15:30:12 BFLogBot - Commit d079ad41f934 | Author: buckyballreaction | Log: Fix dedicated compile
15:30:57 raptor ok starting server...
15:31:29 raptor it's up
15:32:10 Watusimoto let's try
16:17:57 raptor ok wrote those two down
16:23:33 Watusimoto great
16:23:34 Watusimoto thanks
16:24:04 Watusimoto read the swedish Pirate Party copyright manifesto on the train
16:24:09 Watusimoto all 100+ pages
16:24:21 raptor wow
16:25:38 Watusimoto they think there should by no injunction against non-profit copyright violation
16:26:19 Watusimoto they think (and I agree) that it is difficult to enforce copyright laws while also maintaining strong free speech rights
16:26:26 Watusimoto there is in inherent conflict
16:26:28 raptor yes
16:26:40 Watusimoto and which is the stronger right?  they argue free speech
16:27:00 Watusimoto therefore, where there is a conflict, we should err on the side of free speech
16:27:02 raptor i believe copyright needs to be reduced - and certainly not carried beyond the death of the creator (except in special, humanitarian circumstances)
16:27:14 Watusimoto that is a related but different issue
16:27:19 raptor yes
16:27:27 Watusimoto they argue for 20 years
16:27:31 Watusimoto for commercial copyright
16:27:48 raptor because death +70 (or 90 now?) is absurd
16:27:51 Watusimoto not sure I totally agree, but maybe
16:28:20 Watusimoto where I have difficulty is protecting my own content; not commercial stuff, but how do I keep you from copying my personal photos and using them in an ad?
16:28:25 raptor yeah, i don't have an opinion on the time scale
16:28:37 Watusimoto their manifesto didn't address that point
16:28:43 Watusimoto so I may write to the author
16:28:46 Watusimoto and ask
16:29:09 raptor i think it has to do with courst system overhaul
16:29:21 raptor it must be easier for the little guy to stop the big guy
16:29:35 Watusimoto there is small claims court
16:29:44 Watusimoto often overlooked
16:29:49 Watusimoto but very powerful
16:30:02 Watusimoto little guy has a distinct advantage there, I think
16:30:47 raptor also enforcement should be more than just a payout, but like public admittance of wrong doing
16:31:04 Watusimoto into the stocks with you, scoundrel!
16:31:13 raptor haha
16:31:25 Watusimoto in the museums here, they have thses things called "fiddles"
16:31:38 raptor ?
16:31:47 Watusimoto that go round your neck and hold your hands in front of you like you one after the other
16:32:08 Watusimoto http://en.wikipedia.org/wiki/Shrew's_fiddle
16:32:54 Watusimoto into the double-fiddle with you scoundrels
16:32:58 Watusimoto until you make amends
16:32:58 raptor hehe
16:36:20 raptor huh - it was explicitly chosen to not render flags on cloaked ships...  any idea why?
16:37:29 raptor maybe because of the difficulty of determining the client-side alpha...
16:39:30 raptor well, i'll leave it be, i guess..
16:40:17 Watusimoto what do you mean?
16:40:28 raptor i mean to forget the whole lot of it
16:40:33 Watusimoto on cloaked ships in nexus games?
16:40:49 Watusimoto now you got me wondering :-)
16:40:56 raptor yeah - you can't see your team mates flags in team nexus when they're cloaked
16:41:13 raptor or your own
16:43:09 Watusimoto should be an easy fix, no?
16:43:27 Watusimoto just alpha-ize the flag rendering, and pass an alpha
16:43:51 raptor hmm....
16:43:57 raptor actually probably yes...
16:52:03 raptor ha!
16:52:20 raptor resource items show up as not cloaked with you cloak with one on top of you
16:52:32 raptor is that what we want?
16:53:24 raptor notice anything?:  http://sam686.maxhushahn.com/upload/111111111screenshot_1.png
16:55:21 Watusimoto ha
16:55:31 Watusimoto no, not what we want
16:55:38 Watusimoto I think resources should be cloaked as well
16:55:42 raptor me too
16:55:48 Watusimoto good!
16:56:03 Watusimoto so we need to alphaize the resources?
16:56:07 raptor so you're saying we should change the MoveItem::renderItem() method to include an alpha?
16:56:14 Watusimoto I guess I am
16:56:20 Watusimoto are you saying that too?
16:56:28 raptor that will change the signatures of all of those that inherit:  http://bitfighter.org/~raptor/doxygen/current/class_zap_1_1_move_item.html
16:58:33 raptor or maybe I could implement a second virtual renderItem() method that is only implemented in the mountable resources?
16:58:43 raptor that seems easier, but which is proper...
17:02:45 Watusimoto hmmm... dinner time.  Will think it over and we can discuss later if you haven't settled on a solution.  We probably need to just have a universal alpha though that seems lame if we don't use it 90% of the time
17:02:49 Watusimoto back later.
17:07:36 Watusimoto Quit (Ping timeout: 240 seconds)
18:05:30 BFLogBot - Commit 795558a05c7c | Author: buckyballreaction | Log: Fix cloak bugs.  Mounted resources are now cloaked.  Nexus flag count is now shown when cloaked
18:18:30 Watusimoto has joined
18:20:23 sam686 has joined
18:20:23 ChanServ sets mode +v sam686
18:27:30 raptor fix cloaking issues
18:27:33 raptor *fixed
18:28:31 raptor next task:  making sure all render*() methods are properly compiled out of dedicated build - because we sometimes have #ifdefs inside the methods, sometimes outside
18:28:45 raptor but that'll have to be in about 4 hours...
18:32:28 raptor Quit ()
21:08:30 Little_Apple has joined
21:08:35 Little_Apple helloo
22:26:25 raptor has joined
22:26:25 ChanServ sets mode +o raptor
22:26:55 raptor hi hi
22:27:57 raptor true.  i'm guilty:  http://abstrusegoose.com/474
22:29:32 Watusimoto ha
22:31:19 Watusimoto I think I forgot how to code
22:31:33 Watusimoto Looking at C++ and thinking what does this stuff do?
22:31:44 raptor awesome!
22:31:52 raptor nothing like a new perspective!
22:32:59 Little_Apple helloo
22:33:14 Watusimoto hi
22:33:16 raptor hi
22:33:20 Little_Apple where be sam's upload ling thing?
22:33:26 Little_Apple :3
22:33:28 raptor http://sam686.maxhushahn.com/upload3.php
22:33:31 raptor that?
22:33:32 Little_Apple ty
22:34:06 Little_Apple i played with flash some more :D http://sam686.maxhushahn.com/upload/crackneck.gif
22:34:25 raptor oh l ovely
22:34:35 Little_Apple :D
22:41:15 raptor ok, i'm starting the Great Dedicated Server Render Method Signature Hunt
22:41:29 Watusimoto ok, so heatseekers lock onto a specific target and continue towards that until they lose it
22:41:34 raptor correct
22:41:58 Watusimoto my original thought was that each tick they would steer towards hottest thing they could see.  would that be different in practice?
22:42:22 Watusimoto perhaps holding a target would be more efficient; most times no new searching
22:43:03 raptor hmmm
22:43:05 Watusimoto not criticizing, just thinking aloud
22:43:42 raptor interesting idea - not sure how prone to abuse it'd be
22:43:43 Watusimoto not going to touch that at the moment
22:44:09 Watusimoto in practice, once locked, it will continue to draw closer to hot object
22:44:20 Watusimoto so at distance x, hottest object is a
22:44:30 Watusimoto at distance x/2, a will still probably be hottest
22:44:49 Watusimoto especially if we factor in that heat dissapates by dist^s
22:44:52 Watusimoto ^2
22:45:28 Watusimoto so I think that unless an object is rapidly changing heat, locking and not lockiing will produce similar results
22:45:53 raptor so every move item would have mHeat member?
22:46:04 raptor ok
22:46:34 Watusimoto as to mHeat, we may want that if we can target multiple item types
22:46:51 Watusimoto probably woiuld be a getHeat() that would return constant for most things, var for ships
22:47:01 Watusimoto maybe var for ffs and turrets
22:47:12 Watusimoto but those are details for later
22:47:24 Watusimoto your comments are very helpful
22:48:02 raptor mHeat could be changed each tick as a function of whatever (like available energy), or left constant
22:48:17 raptor ok later
22:48:30 raptor i'm at your disposal for other info about the current code
22:54:16 raptor hmmm
22:54:25 raptor render methods are everywhere...
23:01:36 Watusimoto ha
23:01:48 Watusimoto I just sped up heatseekers by 5x, and shot at a stationary bot
23:01:59 raptor too fast?
23:02:02 Watusimoto the projectile went around the bot, and hit me in the butt
23:02:08 raptor haha
23:02:30 Watusimoto actually, kind of cool!
23:05:28 raptor ok, before I get too deep under water - Watusimoto, do you consider it good to #ifdef out all the render methods (and maybe others) from the dedicated build?
23:05:48 Watusimoto as opposed to what?
23:06:17 raptor so it would be this:
23:06:58 raptor #ifndef ZAP_DEDICATED
23:07:00 raptor void Item::render()
23:07:01 raptor {
23:07:03 raptor    renderItem(getPos());
23:07:04 raptor }
23:07:06 raptor #endif
23:07:11 raptor and grouped together with others
23:07:17 raptor instead of all the many instances of:
23:07:19 Watusimoto right
23:07:23 raptor void Item::render()
23:07:25 raptor {
23:07:26 raptor #ifndef ZAP_DEDICATED
23:07:28 raptor    renderItem(getPos());
23:07:29 raptor #endif
23:07:31 raptor }
23:07:43 Watusimoto so remove the method or remove the guts only
23:07:52 raptor correct
23:08:13 Watusimoto removing method seems better but... also have to remove stuff from header
23:08:14 raptor it's really a housekeeping chore, and i'm in that kind of mood...
23:08:27 Watusimoto which I don't love
23:08:41 Watusimoto third option (not pushing this, just mentioning it)
23:09:08 Watusimoto is your first option coupled with
23:09:15 Watusimoto #ifdef ZAP_DED
23:09:25 Watusimoto void Item::render() { }
23:09:27 Watusimoto #endif
23:09:37 Watusimoto so header could remain the same
23:09:52 Watusimoto could also be grouped
23:10:22 Watusimoto drawback there is we need to provide two implementations for each method, so if sig changes we wouldn't catch it until dedicated compile
23:10:50 Watusimoto I *think* I prefer #2 least
23:11:00 Watusimoto I like being able to group everything
23:11:11 raptor ok, the greater question:  would it be advantageous to eventually have a client-only section of all the headers for better readability, etc.?
23:11:24 Watusimoto maybe
23:11:39 raptor dinner time!
23:11:43 Watusimoto I've been through this before though, some things are inherently both client and server
23:11:46 Watusimoto ok
23:11:50 raptor i'lll be back to continue discussion if you're still here...
23:12:03 Watusimoto I probably won't be, but I'll try ot leave a thought
23:12:05 Watusimoto enjoy
23:12:13 raptor yes, but there is a lot that is client-only (and very little server-only)
23:12:22 Watusimoto yes
23:12:30 Watusimoto ok, overall, more organization == better
23:12:53 Watusimoto (I'm assuming you'll be reading this after dinner)
23:12:58 raptor ok
23:13:08 raptor to the forks!
23:13:12 Watusimoto ciao
23:13:13 Watusimoto chow
23:14:20 Watusimoto I have started breaking out things where possible into client and server, such as having idle call idle_srerver and idle_client (or something similar) to clarify things a little
23:14:41 Watusimoto you might try perusing stackOverflow to see if there are good solutions there
23:15:45 Watusimoto overall, I think I prefer the option I proposed, so you could be spare on the ifdefs, and leave the headers intact (though they could still be organized into client and server sections, just wouldn't need to have ifdefs there)
23:16:03 Watusimoto if you don't ike that, my 2nd choice would be your first proposal
23:16:28 Watusimoto which would put some ifdefs into the header, but really, it's not that bad
23:16:48 Watusimoto so between #1 and #3, I don;t have a strong preference
23:36:48 raptor or maybe...
23:36:57 raptor we split up the files completely!
23:37:25 raptor so  item_shared.cpp and item_server.cpp and item_client.cpp
23:37:31 raptor or...  maybe just separate folders
23:38:38 raptor our combined solution is starting to feel cumbersome...  (ok, maybe not just starting..)
23:42:28 Little_Apple pie
23:42:35 raptor with ice cream!
23:46:21 Little_Apple and… walnuts...
23:46:30 raptor blech
23:46:41 Little_Apple and… whipped cream...
23:46:48 Little_Apple and dirty socks...
23:51:04 Little_Apple byeee
23:51:07 Little_Apple Quit (Quit: Page closed)

Index Search ←Prev date Next date→

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

00:11:14		Little_Apple Quit (Ping timeout: 245 seconds)
00:33:18		raptor Quit ()
01:02:59		raptor has joined
01:02:59		ChanServ sets mode +o raptor
01:34:06		raptor Quit (Read error: Connection reset by peer)
01:46:04		raptor has joined
01:46:04		ChanServ sets mode +o raptor
01:59:52		raptor Quit ()
03:56:49		raptor has joined
03:56:49		ChanServ sets mode +o raptor
05:08:27		raptor Quit ()
06:29:21		Watusimoto has joined
08:32:07		Watusimoto Quit (Ping timeout: 246 seconds)
09:19:17		sam686 Quit (Ping timeout: 245 seconds)
09:35:20		Watusimoto has joined
10:03:32		LordDVG has joined
10:41:17		LordDVG Quit (Remote host closed the connection)
10:58:03		LordDVG has joined
11:21:11		LordDVG Quit (Remote host closed the connection)
12:17:04		Watusimoto Quit (Ping timeout: 246 seconds)
12:23:44		Watusimoto has joined
14:04:02		raptor has joined
14:04:03		ChanServ sets mode +o raptor
14:04:10	raptor	buenos!
14:33:04	Watusimoto	hi
14:37:18	raptor	i
14:37:20	raptor	hi
14:37:43	raptor	how was two week away from bitfighter?
14:38:08	Watusimoto	exhausting!
14:38:38	Watusimoto	I had my birthday while we were away, and today, my oldest son gave me a book of Bitfighter ideas
14:38:49	raptor	haha
14:38:55	raptor	happy birthday
14:53:53	raptor	you should test the heat-seeker with me :)
14:59:23	Watusimoto	I need to update and build; let me try doing that
15:06:29	Watusimoto	ok, updating
15:06:39	Watusimoto	took me a while to get all my tools started up
15:06:50	raptor	finally shut down your computer for once?
15:07:43	Watusimoto	crashed just before I left
15:07:54	Watusimoto	ok, building
15:07:58	raptor	that's one wat to do it..
15:08:02	raptor	way
15:15:09	Watusimoto	ok, built; running. you host?
15:15:15	raptor	yes, i'm hosting
15:15:32	raptor	if too much lag, i can set it up on the master
15:15:45	Watusimoto	punching...
15:15:52	Watusimoto	fail
15:16:10	Watusimoto	now seeing you (?) as ping timed out
15:16:20	raptor	ok, compiling on master...
15:16:21	Watusimoto	172.174?
15:16:26	raptor	nope
15:16:28	raptor	69.169...
15:16:43	Watusimoto	I see you, but ping timed out
15:17:08	Watusimoto	this menu music is drving me crazy!
15:17:22	Watusimoto	we need a longer loop
15:17:24	raptor	haha
15:18:14	Watusimoto	this won't work... want to try on the master?
15:18:24	raptor	yes, trying to get dedicated to compile...
15:19:05	raptor	fixing an error...
15:19:11	Watusimoto	muted the music
15:21:20	raptor	huh, another error..
15:23:56	raptor	man... dedicated is broken all over...
15:25:06	raptor	4th error...
15:27:25	raptor	5th
15:27:31	raptor	this one is mine :-/
15:27:59	Watusimoto	Maybe we need to create an automated test build when we checkin that builds dedicated and emails errors
15:29:20	raptor	yay it compiled
15:29:23	raptor	ok, back to master...
15:30:12		BFLogBot - Commit d079ad41f934 \| Author: buckyballreaction \| Log: Fix dedicated compile
15:30:57	raptor	ok starting server...
15:31:29	raptor	it's up
15:32:10	Watusimoto	let's try
16:17:57	raptor	ok wrote those two down
16:23:33	Watusimoto	great
16:23:34	Watusimoto	thanks
16:24:04	Watusimoto	read the swedish Pirate Party copyright manifesto on the train
16:24:09	Watusimoto	all 100+ pages
16:24:21	raptor	wow
16:25:38	Watusimoto	they think there should by no injunction against non-profit copyright violation
16:26:19	Watusimoto	they think (and I agree) that it is difficult to enforce copyright laws while also maintaining strong free speech rights
16:26:26	Watusimoto	there is in inherent conflict
16:26:28	raptor	yes
16:26:40	Watusimoto	and which is the stronger right? they argue free speech
16:27:00	Watusimoto	therefore, where there is a conflict, we should err on the side of free speech
16:27:02	raptor	i believe copyright needs to be reduced - and certainly not carried beyond the death of the creator (except in special, humanitarian circumstances)
16:27:14	Watusimoto	that is a related but different issue
16:27:19	raptor	yes
16:27:27	Watusimoto	they argue for 20 years
16:27:31	Watusimoto	for commercial copyright
16:27:48	raptor	because death +70 (or 90 now?) is absurd
16:27:51	Watusimoto	not sure I totally agree, but maybe
16:28:20	Watusimoto	where I have difficulty is protecting my own content; not commercial stuff, but how do I keep you from copying my personal photos and using them in an ad?
16:28:25	raptor	yeah, i don't have an opinion on the time scale
16:28:37	Watusimoto	their manifesto didn't address that point
16:28:43	Watusimoto	so I may write to the author
16:28:46	Watusimoto	and ask
16:29:09	raptor	i think it has to do with courst system overhaul
16:29:21	raptor	it must be easier for the little guy to stop the big guy
16:29:35	Watusimoto	there is small claims court
16:29:44	Watusimoto	often overlooked
16:29:49	Watusimoto	but very powerful
16:30:02	Watusimoto	little guy has a distinct advantage there, I think
16:30:47	raptor	also enforcement should be more than just a payout, but like public admittance of wrong doing
16:31:04	Watusimoto	into the stocks with you, scoundrel!
16:31:13	raptor	haha
16:31:25	Watusimoto	in the museums here, they have thses things called "fiddles"
16:31:38	raptor	?
16:31:47	Watusimoto	that go round your neck and hold your hands in front of you like you one after the other
16:32:08	Watusimoto	http://en.wikipedia.org/wiki/Shrew's_fiddle
16:32:54	Watusimoto	into the double-fiddle with you scoundrels
16:32:58	Watusimoto	until you make amends
16:32:58	raptor	hehe
16:36:20	raptor	huh - it was explicitly chosen to not render flags on cloaked ships... any idea why?
16:37:29	raptor	maybe because of the difficulty of determining the client-side alpha...
16:39:30	raptor	well, i'll leave it be, i guess..
16:40:17	Watusimoto	what do you mean?
16:40:28	raptor	i mean to forget the whole lot of it
16:40:33	Watusimoto	on cloaked ships in nexus games?
16:40:49	Watusimoto	now you got me wondering :-)
16:40:56	raptor	yeah - you can't see your team mates flags in team nexus when they're cloaked
16:41:13	raptor	or your own
16:43:09	Watusimoto	should be an easy fix, no?
16:43:27	Watusimoto	just alpha-ize the flag rendering, and pass an alpha
16:43:51	raptor	hmm....
16:43:57	raptor	actually probably yes...
16:52:03	raptor	ha!
16:52:20	raptor	resource items show up as not cloaked with you cloak with one on top of you
16:52:32	raptor	is that what we want?
16:53:24	raptor	notice anything?: http://sam686.maxhushahn.com/upload/111111111screenshot_1.png
16:55:21	Watusimoto	ha
16:55:31	Watusimoto	no, not what we want
16:55:38	Watusimoto	I think resources should be cloaked as well
16:55:42	raptor	me too
16:55:48	Watusimoto	good!
16:56:03	Watusimoto	so we need to alphaize the resources?
16:56:07	raptor	so you're saying we should change the MoveItem::renderItem() method to include an alpha?
16:56:14	Watusimoto	I guess I am
16:56:20	Watusimoto	are you saying that too?
16:56:28	raptor	that will change the signatures of all of those that inherit: http://bitfighter.org/~raptor/doxygen/current/class_zap_1_1_move_item.html
16:58:33	raptor	or maybe I could implement a second virtual renderItem() method that is only implemented in the mountable resources?
16:58:43	raptor	that seems easier, but which is proper...
17:02:45	Watusimoto	hmmm... dinner time. Will think it over and we can discuss later if you haven't settled on a solution. We probably need to just have a universal alpha though that seems lame if we don't use it 90% of the time
17:02:49	Watusimoto	back later.
17:07:36		Watusimoto Quit (Ping timeout: 240 seconds)
18:05:30		BFLogBot - Commit 795558a05c7c \| Author: buckyballreaction \| Log: Fix cloak bugs. Mounted resources are now cloaked. Nexus flag count is now shown when cloaked
18:18:30		Watusimoto has joined
18:20:23		sam686 has joined
18:20:23		ChanServ sets mode +v sam686
18:27:30	raptor	fix cloaking issues
18:27:33	raptor	*fixed
18:28:31	raptor	next task: making sure all render*() methods are properly compiled out of dedicated build - because we sometimes have #ifdefs inside the methods, sometimes outside
18:28:45	raptor	but that'll have to be in about 4 hours...
18:32:28		raptor Quit ()
21:08:30		Little_Apple has joined
21:08:35	Little_Apple	helloo
22:26:25		raptor has joined
22:26:25		ChanServ sets mode +o raptor
22:26:55	raptor	hi hi
22:27:57	raptor	true. i'm guilty: http://abstrusegoose.com/474
22:29:32	Watusimoto	ha
22:31:19	Watusimoto	I think I forgot how to code
22:31:33	Watusimoto	Looking at C++ and thinking what does this stuff do?
22:31:44	raptor	awesome!
22:31:52	raptor	nothing like a new perspective!
22:32:59	Little_Apple	helloo
22:33:14	Watusimoto	hi
22:33:16	raptor	hi
22:33:20	Little_Apple	where be sam's upload ling thing?
22:33:26	Little_Apple	:3
22:33:28	raptor	http://sam686.maxhushahn.com/upload3.php
22:33:31	raptor	that?
22:33:32	Little_Apple	ty
22:34:06	Little_Apple	i played with flash some more :D http://sam686.maxhushahn.com/upload/crackneck.gif
22:34:25	raptor	oh l ovely
22:34:35	Little_Apple	:D
22:41:15	raptor	ok, i'm starting the Great Dedicated Server Render Method Signature Hunt
22:41:29	Watusimoto	ok, so heatseekers lock onto a specific target and continue towards that until they lose it
22:41:34	raptor	correct
22:41:58	Watusimoto	my original thought was that each tick they would steer towards hottest thing they could see. would that be different in practice?
22:42:22	Watusimoto	perhaps holding a target would be more efficient; most times no new searching
22:43:03	raptor	hmmm
22:43:05	Watusimoto	not criticizing, just thinking aloud
22:43:42	raptor	interesting idea - not sure how prone to abuse it'd be
22:43:43	Watusimoto	not going to touch that at the moment
22:44:09	Watusimoto	in practice, once locked, it will continue to draw closer to hot object
22:44:20	Watusimoto	so at distance x, hottest object is a
22:44:30	Watusimoto	at distance x/2, a will still probably be hottest
22:44:49	Watusimoto	especially if we factor in that heat dissapates by dist^s
22:44:52	Watusimoto	^2
22:45:28	Watusimoto	so I think that unless an object is rapidly changing heat, locking and not lockiing will produce similar results
22:45:53	raptor	so every move item would have mHeat member?
22:46:04	raptor	ok
22:46:34	Watusimoto	as to mHeat, we may want that if we can target multiple item types
22:46:51	Watusimoto	probably woiuld be a getHeat() that would return constant for most things, var for ships
22:47:01	Watusimoto	maybe var for ffs and turrets
22:47:12	Watusimoto	but those are details for later
22:47:24	Watusimoto	your comments are very helpful
22:48:02	raptor	mHeat could be changed each tick as a function of whatever (like available energy), or left constant
22:48:17	raptor	ok later
22:48:30	raptor	i'm at your disposal for other info about the current code
22:54:16	raptor	hmmm
22:54:25	raptor	render methods are everywhere...
23:01:36	Watusimoto	ha
23:01:48	Watusimoto	I just sped up heatseekers by 5x, and shot at a stationary bot
23:01:59	raptor	too fast?
23:02:02	Watusimoto	the projectile went around the bot, and hit me in the butt
23:02:08	raptor	haha
23:02:30	Watusimoto	actually, kind of cool!
23:05:28	raptor	ok, before I get too deep under water - Watusimoto, do you consider it good to #ifdef out all the render methods (and maybe others) from the dedicated build?
23:05:48	Watusimoto	as opposed to what?
23:06:17	raptor	so it would be this:
23:06:58	raptor	#ifndef ZAP_DEDICATED
23:07:00	raptor	void Item::render()
23:07:01	raptor	{
23:07:03	raptor	renderItem(getPos());
23:07:04	raptor	}
23:07:06	raptor	#endif
23:07:11	raptor	and grouped together with others
23:07:17	raptor	instead of all the many instances of:
23:07:19	Watusimoto	right
23:07:23	raptor	void Item::render()
23:07:25	raptor	{
23:07:26	raptor	#ifndef ZAP_DEDICATED
23:07:28	raptor	renderItem(getPos());
23:07:29	raptor	#endif
23:07:31	raptor	}
23:07:43	Watusimoto	so remove the method or remove the guts only
23:07:52	raptor	correct
23:08:13	Watusimoto	removing method seems better but... also have to remove stuff from header
23:08:14	raptor	it's really a housekeeping chore, and i'm in that kind of mood...
23:08:27	Watusimoto	which I don't love
23:08:41	Watusimoto	third option (not pushing this, just mentioning it)
23:09:08	Watusimoto	is your first option coupled with
23:09:15	Watusimoto	#ifdef ZAP_DED
23:09:25	Watusimoto	void Item::render() { }
23:09:27	Watusimoto	#endif
23:09:37	Watusimoto	so header could remain the same
23:09:52	Watusimoto	could also be grouped
23:10:22	Watusimoto	drawback there is we need to provide two implementations for each method, so if sig changes we wouldn't catch it until dedicated compile
23:10:50	Watusimoto	I think I prefer #2 least
23:11:00	Watusimoto	I like being able to group everything
23:11:11	raptor	ok, the greater question: would it be advantageous to eventually have a client-only section of all the headers for better readability, etc.?
23:11:24	Watusimoto	maybe
23:11:39	raptor	dinner time!
23:11:43	Watusimoto	I've been through this before though, some things are inherently both client and server
23:11:46	Watusimoto	ok
23:11:50	raptor	i'lll be back to continue discussion if you're still here...
23:12:03	Watusimoto	I probably won't be, but I'll try ot leave a thought
23:12:05	Watusimoto	enjoy
23:12:13	raptor	yes, but there is a lot that is client-only (and very little server-only)
23:12:22	Watusimoto	yes
23:12:30	Watusimoto	ok, overall, more organization == better
23:12:53	Watusimoto	(I'm assuming you'll be reading this after dinner)
23:12:58	raptor	ok
23:13:08	raptor	to the forks!
23:13:12	Watusimoto	ciao
23:13:13	Watusimoto	chow
23:14:20	Watusimoto	I have started breaking out things where possible into client and server, such as having idle call idle_srerver and idle_client (or something similar) to clarify things a little
23:14:41	Watusimoto	you might try perusing stackOverflow to see if there are good solutions there
23:15:45	Watusimoto	overall, I think I prefer the option I proposed, so you could be spare on the ifdefs, and leave the headers intact (though they could still be organized into client and server sections, just wouldn't need to have ifdefs there)
23:16:03	Watusimoto	if you don't ike that, my 2nd choice would be your first proposal
23:16:28	Watusimoto	which would put some ifdefs into the header, but really, it's not that bad
23:16:48	Watusimoto	so between #1 and #3, I don;t have a strong preference
23:36:48	raptor	or maybe...
23:36:57	raptor	we split up the files completely!
23:37:25	raptor	so item_shared.cpp and item_server.cpp and item_client.cpp
23:37:31	raptor	or... maybe just separate folders
23:38:38	raptor	our combined solution is starting to feel cumbersome... (ok, maybe not just starting..)
23:42:28	Little_Apple	pie
23:42:35	raptor	with ice cream!
23:46:21	Little_Apple	and… walnuts...
23:46:30	raptor	blech
23:46:41	Little_Apple	and… whipped cream...
23:46:48	Little_Apple	and dirty socks...
23:51:04	Little_Apple	byeee
23:51:07		Little_Apple Quit (Quit: Page closed)