Timestamps are in GMT/BST.
| 00:00:16 | | Aggropanda Quit (Quit: Page closed) |
| 01:19:11 | | BFLogBot - Commit 8f803d4a7f91 | Author: watusim...@bitfighter.org | Log: Changed signatures |
| 01:19:12 | | BFLogBot - Commit 22956ae63043 | Author: watusim...@bitfighter.org | Log: Added color |
| 01:19:14 | | BFLogBot - Commit 3ecf80a8c249 | Author: watusim...@bitfighter.org | Log: Move spark emissions to CoreItem, other consolidation... somehow, this makes "leak sparks" worse |
| 01:24:10 | | Watusimoto Quit (Ping timeout: 272 seconds) |
| 02:19:20 | | BFLogBot - Commit 42ced7fe1f2b | Author: sam8641 | Log: Fix a possible crash when getClientInfo returns NULL |
| 02:27:39 | | sam686 Quit (Ping timeout: 245 seconds) |
| 02:27:44 | | sam686 has joined |
| 02:27:44 | | ChanServ sets mode +v sam686 |
| 02:31:49 | | Little_Apple has joined |
| 02:31:55 | Little_Apple | aww |
| 02:31:57 | Little_Apple | hellooo |
| 02:40:26 | | Little_Apple Quit (Ping timeout: 245 seconds) |
| 03:18:49 | | raptor has joined |
| 03:18:49 | | ChanServ sets mode +o raptor |
| 03:50:40 | raptor | good evening |
| 03:56:50 | raptor | somehow Core is rendered in reverse... |
| 03:57:57 | sam686 | or is it that core is moving in reverse? |
| 03:58:05 | raptor | yes, that |
| 03:58:37 | raptor | and your center kaleidoscope graphic is in reverse, too |
| 03:59:26 | sam686 | it was going the right way on 016 |
| 03:59:31 | raptor | yep |
| 04:00:00 | sam686 | also, a problem with /settime 0 (unlimited / no time limit) makes core not move. |
| 04:00:10 | raptor | yeah, that a larger problem |
| 04:00:24 | raptor | that will require synchronizing a different timer between server and client |
| 04:03:04 | raptor | that is so weird... |
| 04:03:09 | raptor | what is making it go backwards? |
| 04:03:51 | sam686 | taking from time remaining which count down (where in 016, a simple milliseconds is used which count up) |
| 04:04:12 | raptor | ahh |
| 04:07:05 | raptor | maybe I can change it to getTimeElapsed |
| 04:13:38 | raptor | nope, guess not... |
| 04:13:59 | raptor | oh wait, yes i can |
| 04:16:35 | raptor | ha! i had no idea, that to render the Bitfighter logo, you just have to add a TextItem called 'Bitfighter' |
| 04:19:27 | | Little_Apple has joined |
| 04:19:44 | Little_Apple | HELLOOOO |
| 04:19:48 | sam686 | hi |
| 04:19:52 | raptor | hola |
| 04:20:06 | Little_Apple | Raptor |
| 04:20:27 | Little_Apple | Do you ever give your kids piggy back rides? |
| 04:20:38 | Little_Apple | :3 |
| 04:20:39 | raptor | my oldest is 2 |
| 04:20:43 | raptor | so not yet |
| 04:20:56 | Little_Apple | http://www.geekalerts.com/daddle-the-dad-saddle/ |
| 04:20:59 | Little_Apple | :D |
| 04:21:43 | Little_Apple | Isn't it genius? |
| 04:22:09 | Little_Apple | Ergo |
| 04:22:11 | Little_Apple | Laters |
| 04:22:18 | | Little_Apple Quit (Client Quit) |
| 04:27:06 | raptor | actually it may just be easier to reverse the kaleidoscope.. |
| 04:27:19 | raptor | sorry, spirograph thingy |
| 04:34:48 | sam686 | maybe, as easy as using -time_remaining to reverse the effects.. but that won't solve the unlimited time / no time limit.. |
| 04:35:13 | raptor | yeah, that's a different problem we may want to tackle for after 017 |
| 04:40:12 | sam686 | i don't see anything in TNL bitfighter code that sends server current getMilliseconds to client |
| 04:40:23 | sam686 | maybe i could add that.. |
| 04:40:32 | raptor | there isn't |
| 04:40:47 | raptor | but there needs to be - there may be future things we want to sync |
| 04:42:23 | sam686 | another problem to solve is a problem with how sending a clientGame's time remaining can be inaccurate, i frequently see 9:32 jump to 9:30 skipping 9:31.. |
| 04:43:05 | raptor | yes, maybe people have their cpu running faster, slower, and the time sync from server is slow sometimes |
| 04:43:35 | sam686 | it is mostly something to do with, internet lag delaying receiving.. |
| 04:44:34 | raptor | you think so? |
| 04:46:37 | sam686 | the tnl ping system only happens about once every second, that makes getting ping number somewhat inaccurate |
| 04:46:49 | raptor | ah |
| 05:04:35 | | BFLogBot - Commit c02e8a5bbc14 | Author: buckyballreaction | Log: Make Core center atomic-like graphic render correctly (not reversed) |
| 05:04:36 | | BFLogBot - Commit 29353375e747 | Author: buckyballreaction | Log: Fix compiler warning |
| 05:29:40 | | BFLogBot - Commit 7ce889d351a8 | Author: buckyballreaction | Log: Consolidate panel damaged logic |
| 06:02:41 | sam686 | good night, i think we will leave with BFLogBot being lonely... |
| 06:02:47 | raptor | yes |
| 06:02:49 | raptor | good night |
| 06:02:54 | | raptor has left |
| 06:19:58 | | sam686 Quit () |
| 08:41:42 | | watusimoto has joined |
| 08:41:42 | | ChanServ sets mode +o watusimoto |
| 14:26:54 | | raptor has joined |
| 14:26:54 | | ChanServ sets mode +o raptor |
| 14:58:31 | | LordDVG has joined |
| 15:03:51 | | LordDVG Quit (Remote host closed the connection) |
| 15:06:32 | | LordDVG has joined |
| 15:16:43 | | LordDVG Quit (Ping timeout: 245 seconds) |
| 15:19:15 | | LordDVG has joined |
| 15:42:40 | | LordDVG Quit (Read error: Connection reset by peer) |
| 15:43:11 | | LordDVG has joined |
| 16:21:58 | | LordDVG Quit (Remote host closed the connection) |
| 17:01:10 | | Watusimoto_ has joined |
| 17:28:16 | | watusimoto Quit (Read error: Operation timed out) |
| 17:31:37 | | raptor Quit () |
| 18:10:00 | | LordDVG has joined |
| 18:26:31 | | Watusimoto_ Quit (Ping timeout: 260 seconds) |
| 18:30:07 | | raptor has joined |
| 18:30:07 | | ChanServ sets mode +o raptor |
| 19:32:15 | | Watusimoto has joined |
| 19:35:45 | | LordDVG Quit (Read error: Connection reset by peer) |
| 19:39:52 | | LordDVG has joined |
| 19:49:43 | raptor | hi Watusimoto |
| 19:50:08 | raptor | so I can get the ship location in CoreItem::damageObject() to properly heal only those panels that are nearest |
| 19:50:22 | raptor | but i cannot get the ship location in getRepairTargets() |
| 19:50:33 | raptor | so the repair rays are always going to all damaged panels |
| 19:57:14 | Watusimoto | hi |
| 19:57:29 | Watusimoto | ok |
| 19:57:36 | Watusimoto | is your code checked in? |
| 19:58:04 | raptor | i did not check in that enhancement because of those problems |
| 19:58:13 | raptor | i did save it as a patch though |
| 19:59:00 | Watusimoto | so if I work on the getRepairTargets, will that overly conflict with what you did? |
| 19:59:05 | raptor | nah |
| 19:59:14 | raptor | i'm good with managing patchsets |
| 19:59:15 | Watusimoto | ok, let me take a look |
| 20:02:07 | raptor | also, if we get this to work - do you want the health divided amongst panels, still? I'm figuring no, since we'll be making panels have the same behavior as other objects |
| 20:03:01 | Watusimoto | correct -- no |
| 20:03:09 | raptor | ok, that's what i coded |
| 20:03:17 | Watusimoto | cores are so easy to kill, and hard to repair... |
| 20:03:36 | raptor | a little harder to kill now with targets.. |
| 20:07:39 | raptor | we're definitely closer to your star castle thingy |
| 20:08:02 | Watusimoto | a little |
| 20:08:28 | Watusimoto | I have more (feasible) ways to get closer |
| 20:08:59 | raptor | i would like my ship to be able to leave the screen on the left and appear on the right when attacking Cores |
| 20:09:09 | raptor | :) |
| 20:09:31 | Watusimoto | great idea |
| 20:09:52 | Watusimoto | ok, I think the solution is simply to pass the ship's pos into getReapirLocations() |
| 20:10:43 | Watusimoto | then compare pos.distanceSquared(mid) to repair radius |
| 20:11:04 | Watusimoto | in CoreItem::getRepairLocations() |
| 20:11:15 | raptor | yes, that is what i do in damageObject |
| 20:11:18 | Watusimoto | or, rather, CoreItem::getRepairLocations(const Point &repairOrigin) |
| 20:11:21 | Watusimoto | or somesuch |
| 20:11:38 | Watusimoto | well, that seems an easy and benign solution |
| 20:11:41 | raptor | are you adding this in? |
| 20:11:52 | raptor | because i can, if your not there |
| 20:12:00 | Watusimoto | go for it |
| 20:12:09 | Watusimoto | you have all the other related stuff |
| 20:12:21 | raptor | ok |
| 20:12:49 | Watusimoto | of course, you will need to change all the other places where we define gRL() to have the same sig, but you certainly know this |
| 20:18:47 | raptor | this might actually work... |
| 20:19:28 | raptor | except, i'm checking to see if each panel midpoint is within RepairRadius |
| 20:20:44 | Watusimoto | do you think we should check at the repair pioint? We could create a function to caluclate it |
| 20:21:00 | Watusimoto | we use it elsewhere; for rendering, for example |
| 20:21:02 | raptor | the ship may be too far away |
| 20:21:05 | Watusimoto | and for sparks |
| 20:21:14 | raptor | repair point is the health bar stake? |
| 20:21:19 | Watusimoto | yes |
| 20:21:19 | raptor | (or it should be?) |
| 20:21:36 | Watusimoto | we currently use the center of the core for repair, do we not? |
| 20:21:42 | raptor | yeah, RepairRadius is too small... |
| 20:21:57 | raptor | well... object detection is at RepairRadius |
| 20:22:01 | raptor | so any part of the object |
| 20:22:14 | raptor | which is why you get a longer beam with Core |
| 20:23:01 | raptor | hey it works... |
| 20:23:03 | raptor | cool |
| 20:23:12 | raptor | but you can only heal at most 2 panels |
| 20:23:31 | raptor | because repair radius is only comparing the midpoint instead of the whole line |
| 20:23:45 | raptor | maybe i should compare endpoints |
| 20:25:07 | raptor | is there an easy way to get those stake points? |
| 20:26:13 | raptor | ahhh... much better repair behavior... |
| 20:26:26 | raptor | i'm going to chekc in what i've got |
| 20:29:56 | Watusimoto | ok |
| 20:30:01 | Watusimoto | no way to get the stakepoints |
| 20:30:08 | Watusimoto | but we could create one easily |
| 20:30:24 | Watusimoto | in fact, I'll do that now |
| 20:31:13 | raptor | ok, i just pushed |
| 20:31:19 | raptor | if you want to work off of that |
| 20:32:25 | | BFLogBot - Commit 9d82b6bf3151 | Author: buckyballreaction | Log: Only repair the panels closest to the ships. This brings panel repair more in line with standard gameObject behavior |
| 20:45:28 | Watusimoto | ok |
| 20:45:32 | Watusimoto | I think it's done |
| 20:45:41 | Watusimoto | compiling now |
| 20:59:09 | Watusimoto | checked in |
| 20:59:18 | raptor | oh boy |
| 20:59:19 | Watusimoto | it compiles, but I haven't actually tested it yet |
| 20:59:35 | Watusimoto | we need to use those same calculations in the renderer |
| 20:59:42 | Watusimoto | and I'm a little torn |
| 21:00:08 | Watusimoto | I don't think the renderer should be calling methods on the core -- generally, we pass everything the renderer needs and it just draws |
| 21:00:12 | Watusimoto | I think we shoul dkeep this |
| 21:00:14 | Watusimoto | but |
| 21:00:28 | Watusimoto | I don;t like duplicating the calcuations in the renderer metohd |
| 21:00:39 | Watusimoto | and passing 40 points to the renderer seems excessive |
| 21:00:50 | raptor | yes, this was my dilemma, too |
| 21:00:59 | Watusimoto | and I don't like the fact that we do these relatively expensive calcs over and over |
| 21:01:13 | raptor | yep |
| 21:01:19 | Watusimoto | so I was thinking about doing them once (in idle) and caching them in a vector |
| 21:01:28 | Watusimoto | we could pass that vector to the renderer |
| 21:01:37 | raptor | I thought about creating a CoreItem::PanilInfo struct |
| 21:01:48 | Watusimoto | that would probably be better |
| 21:02:21 | Watusimoto | but we only really want to calc them when we need them -- most of the time during a game they are off screen and out of sight |
| 21:02:27 | Watusimoto | and who cares about the angle of a panel? |
| 21:02:29 | | BFLogBot - Commit 0de6dd4c3701 | Author: watusim...@bitfighter.org | Log: Centralize the calculation of the "stake" point, called repair point here. |
| 21:02:32 | Watusimoto | so |
| 21:03:31 | Watusimoto | my next idea is to create a getPanelStruct() function that lazily inits itself; if used, it caches the result. if unused, the points never get calced |
| 21:03:37 | raptor | you broke repair... |
| 21:03:40 | Watusimoto | seems excessive |
| 21:03:51 | Watusimoto | but probably not too hard |
| 21:03:54 | Watusimoto | what broke |
| 21:03:55 | Watusimoto | ? |
| 21:04:08 | raptor | i fix |
| 21:04:17 | Watusimoto | this was such a straightforward fix! |
| 21:04:31 | raptor | you changed my distance test to: repair.distSquared(repairOrigin) |
| 21:04:43 | raptor | which is *always* outside RepairRadius |
| 21:05:12 | raptor | have to test against the start and end panel points for determining if the panel is in range |
| 21:05:47 | Watusimoto | wait.. what? |
| 21:06:12 | Watusimoto | before this latest round of mods, we checked if the center of the core was in repair radius, no? |
| 21:06:16 | raptor | i fix |
| 21:06:23 | raptor | no |
| 21:06:27 | Watusimoto | no? |
| 21:06:28 | raptor | repair radius is only 65 |
| 21:06:32 | Watusimoto | oh |
| 21:06:35 | Watusimoto | core rad is 100 |
| 21:06:39 | Watusimoto | ok |
| 21:06:41 | raptor | the test is against the the extents of the gameobject |
| 21:06:52 | raptor | i fix |
| 21:06:53 | Watusimoto | ok, so I "fixed" something that wasn |
| 21:06:56 | Watusimoto | t broke |
| 21:07:00 | raptor | hehe, yes |
| 21:07:14 | Watusimoto | hrm |
| 21:07:16 | Watusimoto | sorry |
| 21:07:25 | Watusimoto | ok, why is mCurrentExplosionNumber static? |
| 21:07:32 | Watusimoto | what happens if two cores explode at once? |
| 21:07:47 | raptor | ahh, much better |
| 21:08:17 | Watusimoto | I think it should not be static |
| 21:08:27 | raptor | agreed |
| 21:08:31 | raptor | my fault |
| 21:08:51 | raptor | and that explains some oddities i've noticed... |
| 21:08:57 | Watusimoto | ok, I'll remove |
| 21:09:14 | raptor | just pushed my repair fix... |
| 21:09:33 | Watusimoto | rats -- you beat me |
| 21:10:18 | raptor | i win! |
| 21:10:22 | Watusimoto | was using svn today... it feels so clunky |
| 21:10:33 | raptor | oh my goodness yes |
| 21:10:46 | raptor | all of my work code is in SVN, and i feel restricted with it |
| 21:10:58 | raptor | i yearn to use hg or git |
| 21:11:01 | Watusimoto | we use git hub, except for documents |
| 21:11:18 | raptor | can you use github for work? |
| 21:12:21 | Watusimoto | sure |
| 21:12:32 | | BFLogBot - Commit a1224f036887 | Author: buckyballreaction | Log: Fix repair distance test |
| 21:12:33 | | BFLogBot - Commit 5260aa5e7f17 | Author: watusim...@bitfighter.org | Log: whitespace |
| 21:12:35 | | BFLogBot - Commit 774631e14952 | Author: watusim...@bitfighter.org | Log: should not be static |
| 21:12:36 | | BFLogBot - Commit 8a7fbaea7cb1 | Author: watusim...@bitfighter.org | Log: Merge |
| 21:12:36 | Watusimoto | everything I do is opensource |
| 21:12:45 | raptor | interesting... ok |
| 21:12:55 | raptor | makes sense then |
| 21:13:20 | Watusimoto | I |
| 21:13:29 | Watusimoto | 'm working on 2 projects in github |
| 21:13:42 | Watusimoto | well, 1 isn't there yet, but will be soon |
| 21:18:45 | raptor | Core sparkles have been increased again? |
| 21:24:36 | | jan______ has joined |
| 21:24:57 | | jan______ Quit (Client Quit) |
| 21:31:08 | | LordDVG Quit (Ping timeout: 240 seconds) |
| 21:31:54 | Watusimoto | no, I think I just screwed it up last night |
| 21:32:11 | Watusimoto | I made an inconsequtial change, and it all just went to hell |
| 21:32:24 | Watusimoto | so yes, actually, but not intentionally |
| 21:32:30 | Watusimoto | or rather yes maybe |
| 21:32:43 | Watusimoto | maybe the same number, just the linger longer |
| 21:32:46 | Watusimoto | or something |
| 22:07:17 | raptor | vnc + stuck modifier are driving me mad! |
| 22:42:45 | | BFLogBot - Commit 48ce182c6faf | Author: watusim...@bitfighter.org | Log: Comment |
| 22:42:46 | | BFLogBot - Commit 185692a3ebe2 | Author: watusim...@bitfighter.org | Log: Reduce redundant calculations boy was this a pain! |
| 22:43:10 | raptor | yay |
| 22:53:36 | Watusimoto | this is a nightmare |
| 22:53:45 | raptor | nightmare |
| 22:56:58 | raptor | hey explosions work better now |
| 22:59:02 | | sam686 has joined |
| 22:59:02 | | ChanServ sets mode +v sam686 |