Timestamps are in GMT/BST.
| 00:00:11 | raptor | looks at the Triangle comment |
| 00:00:21 | raptor | looks like we're adding an extra point to each hole |
| 00:01:14 | raptor | oh weird |
| 00:01:35 | raptor | so basically all holes are already added, and building the holes list is just to tell with polys are holes |
| 00:01:44 | raptor | does PP use that same input? |
| 00:01:47 | kaen | yes, that's what I gathered |
| 00:01:48 | kaen | no |
| 00:02:01 | kaen | it uses a list<TPPPoly> |
| 00:02:07 | kaen | and TPPPoly has a SetHole method |
| 00:02:29 | raptor | is that a boolean? |
| 00:02:32 | kaen | yes |
| 00:02:50 | raptor | ah ok, so you've already adapted that somehow? |
| 00:02:53 | kaen | yes |
| 00:03:03 | kaen | I've done terrible, unspeakable things to the data |
| 00:03:11 | kaen | and then passed it along without making eye contact. |
| 00:03:19 | raptor | ha ha ha |
| 00:03:41 | raptor | maybe the issue is with mergeBotZoneBuffers |
| 00:03:43 | kaen | anyway I'm going to try adapting the hole list building code |
| 00:03:50 | kaen | yes, I think so |
| 00:04:04 | kaen | basically, I want it to only output one polygon per barrier |
| 00:04:17 | raptor | ok |
| 00:04:46 | kaen | which it does, except when the barrier is circuitous |
| 00:05:08 | kaen | I'm going to give my brain a short rest |
| 00:05:10 | kaen | back in a bit |
| 00:05:11 | raptor | I'm going home |
| 00:05:14 | raptor | ok |
| 00:05:16 | raptor | later |
| 00:05:18 | kaen | later |
| 00:05:26 | raptor | also... maybe we'll get Triangle in a better license? :) |
| 00:06:42 | kaen | that would be by far the most desirable outcome |
| 00:07:00 | raptor | yeah.. |
| 00:07:04 | raptor | ok, leaving |
| 00:07:08 | | raptor Quit () |
| 00:29:43 | | bobdaduck has joined |
| 00:41:47 | kaen | I wish raptor would come back :x |
| 00:41:51 | kaen | I am lost in the sauce. |
| 00:53:11 | | fordcars has joined |
| 01:14:07 | | fordcars Quit (Ping timeout: 245 seconds) |
| 01:35:56 | | bobdaduck Quit (Ping timeout: 272 seconds) |
| 01:38:09 | | bobdaduck has joined |
| 01:56:58 | | fordcars has joined |
| 02:16:43 | | Little_Apple has joined |
| 02:38:42 | | fordcars Quit (Ping timeout: 245 seconds) |
| 03:08:58 | | Little_Apple Quit (Quit: Page closed) |
| 03:20:38 | | kaen Quit (Remote host closed the connection) |
| 03:25:53 | | raptor has joined |
| 03:25:53 | | ChanServ sets mode +o raptor |
| 03:34:12 | sam686 | Found a way to do findGlobalObjects in 018a http://sam6.25u.com/upload/text1304/130416_22-04-43.txt |
| 03:34:24 | sam686 | except it stops working when someone does /kickbots |
| 03:35:31 | bobdaduck | Thewhat |
| 03:35:32 | bobdaduck | xD |
| 03:35:55 | bobdaduck | Did you just work around the lack of a findGlobalObjects function |
| 03:36:01 | sam686 | also not sure if it is a bug, needing an extra argument on function onPlayerJoined(something, playerinfo) |
| 03:36:05 | bobdaduck | By adding a bot, finding the object, and then passing it to the levelgen? |
| 03:36:13 | sam686 | yes |
| 03:37:04 | bobdaduck | That's both praiseworthy and horrifying at the same time |
| 03:38:17 | sam686 | although, I wonder if a bot can control any objects a levelgen can (except addItem).. |
| 03:39:00 | bobdaduck | That would be rather significant. |
| 04:10:10 | raptor | sam686: that's really clever! |
| 04:52:02 | raptor | I found the problem with the FF snapping issue |
| 04:52:07 | raptor | like really found it... |
| 04:52:13 | raptor | but I odn' tknow what to do about it... |
| 05:13:16 | bobdaduck | teag? |
| 05:13:26 | bobdaduck | yeah? |
| 05:18:24 | raptor | yeah... and it's an algorithm problem |
| 05:18:29 | raptor | and it's messy |
| 05:18:30 | raptor | and |
| 05:18:32 | raptor | and |
| 05:18:39 | raptor | yuk |
| 05:21:15 | bobdaduck | lol |
| 05:23:23 | bobdaduck | The populace appreciates your efforts. |
| 05:23:55 | raptor | man, this is deep in the code... this must have been around for ever |
| 05:36:49 | bobdaduck | Yes. |
| 05:37:01 | bobdaduck | Think fixing it will fix the rotation part too? |
| 05:37:15 | bobdaduck | In fact it might be as old as Zap! |
| 05:37:36 | bobdaduck | I remember that in zap you would place something at say, 5.2 and the code would do something funky like 5e20343291234 |
| 05:39:07 | bobdaduck | Anyone know who FB7-whatever is? He seems to get on, make these big levels, and then test them all with like 40 bots on his own instead of playing with actual people |
| 05:39:22 | raptor | nope |
| 05:46:16 | bobdaduck | Odd |
| 05:46:38 | | bobdaduck Quit (Remote host closed the connection) |
| 05:56:23 | raptor | nothing like a good math problem late at night! |
| 06:33:22 | | sam686 Quit (Ping timeout: 245 seconds) |
| 07:10:32 | | koda has joined |
| 07:39:20 | raptor | oh man, I think I finally fixed it... |
| 07:51:46 | | watusimoto has joined |
| 07:51:46 | | ChanServ sets mode +o watusimoto |
| 08:00:10 | raptor | I'm not up! |
| 08:03:46 | | BFLogBot Commit: 84ed46702cde | Author: buckyballreaction | Message: Greatly increase the accuracy (probably exact now) of the anchor finding for engineered items. This fixes the issue with tiny movement changes of engineered items being introduced when loading and saving the level. This fix has two parts: - Better algorithm for finding the anchor more accurately - Reducing the inaccuray of finding the anchor against a wall edge by using the position point instead of previously calculated anchor |
| 08:03:49 | raptor | watusimoto: that last commit took me 3 hours |
| 08:04:03 | raptor | and I only had to be really really tired to figure out what to do |
| 08:04:17 | raptor | but it's fixed! |
| 08:06:42 | koda | morning |
| 08:06:45 | raptor | I should get a badge: 'improved algorithm while sleepy' |
| 08:06:51 | raptor | hi koda |
| 08:06:52 | koda | :D |
| 08:06:57 | koda | i wanna that too |
| 08:07:30 | raptor | :) |
| 08:09:01 | raptor | ok well... I should sleep now |
| 08:09:10 | raptor | good night! (and good morning) |
| 08:09:48 | raptor | parting question for watusimoto: did you send your e-mail to the Triangle author? |
| 08:09:56 | watusimoto | hi |
| 08:09:58 | watusimoto | yes, I did |
| 08:10:15 | raptor | oh good |
| 08:10:25 | watusimoto | no response yet |
| 08:10:45 | raptor | yes well, only crazy people are up in the wee hours over here |
| 08:11:02 | watusimoto | I didn't send it in the wee hours *over there* |
| 08:11:08 | watusimoto | :-) |
| 08:11:31 | watusimoto | redid the anchoring, eh? |
| 08:11:44 | raptor | improved the algorithm |
| 08:11:50 | watusimoto | excellent |
| 08:11:58 | raptor | should be near exact (at least to 8 or decimal points..) |
| 08:12:21 | raptor | probably exact for our purposes |
| 08:12:25 | watusimoto | when is our next bbb? |
| 08:12:30 | watusimoto | i.e. do we have one planned? |
| 08:12:45 | raptor | well, we should set a date - I've stuck bobdaduck and quartz on coming up with a map list |
| 08:12:52 | raptor | it's almost enough |
| 08:13:00 | raptor | see here: http://beta.etherpad.org/p/BBBX |
| 08:13:09 | watusimoto | ok -- I can advertise it on the WeaselZone youtube vid for Bitfighter |
| 08:13:18 | raptor | they've been working at it for like 3 weeks... |
| 08:13:26 | raptor | and even built new levels for it |
| 08:13:40 | watusimoto | ok |
| 08:13:42 | raptor | so there's a hefty amount by Quartz and bobdaduck |
| 08:14:33 | raptor | feel free to add suggestions (edit your username so we can tell what was added by you) |
| 08:14:42 | watusimoto | ok |
| 08:15:27 | raptor | time for bed... good night! |
| 08:15:31 | watusimoto | night! |
| 08:16:15 | | raptor Quit () |
| 16:44:06 | | watusimoto Quit (Quit: Leaving.) |
| 16:49:09 | | raptor has joined |
| 16:49:11 | | ChanServ sets mode +o raptor |
| 16:49:15 | raptor | good day! |
| 16:55:31 | | koda Quit (Ping timeout: 272 seconds) |
| 17:08:15 | | BFLogBot Commit: 99c60fa762f5 | Author: buckyballreaction | Message: Minor clarifications about the engineered item anchor searching from last night |
| 17:09:11 | | Watusimoto has joined |
| 17:11:37 | Watusimoto | hey there |
| 17:11:45 | raptor | hi |
| 17:12:19 | Watusimoto | the weasel dude said he'd rereview bitfighter after the next release |
| 17:12:29 | raptor | ha! great |
| 17:12:48 | Watusimoto | and still no word from the triangle dude |
| 17:12:55 | Watusimoto | now you are up to date |
| 17:13:30 | raptor | oh good |
| 17:16:16 | | watusimoto1 has joined |
| 17:17:30 | Watusimoto | and... with that.... it was dinner time |
| 17:17:32 | Watusimoto | back later |
| 17:22:14 | | Watusimoto Quit (Ping timeout: 248 seconds) |
| 17:36:03 | raptor | I don't want to look at EngineeredItem ever again |
| 18:18:11 | | Watusimoto has joined |
| 18:28:32 | raptor | I think my fix last night helped a little bit with arbitrary rotation of a map and FF going all goofy |
| 18:28:53 | raptor | still loses some precision in that case, though.. |
| 18:31:06 | Watusimoto | what was your strategy? |
| 18:33:46 | raptor | well I basically went over and over the code until I knew what was going on |
| 18:35:05 | raptor | I documented, hopefully, what I did - but funny thing was that inspiration on how to fix it didn't come until I was sleepy at like 1:30 in the morning |
| 18:35:15 | raptor | * documented well |
| 18:42:38 | Watusimoto | the proper solution, I think is relatively straightforward... find all the possible things to attach to within a certain radius (using the database), then visit each one in turn and find the closest |
| 18:43:01 | raptor | that was what was done |
| 18:43:01 | Watusimoto | i thinik the shooting rays strategy will always be prone to error |
| 18:43:11 | Watusimoto | you mean before? |
| 18:43:22 | raptor | I left what was done before |
| 18:43:32 | Watusimoto | well, why didn't that work? |
| 18:43:34 | raptor | and added on a little be to increase accuracy |
| 18:43:49 | Watusimoto | I thought it went every 5 degrees and shot a ray out to see what it hit |
| 18:44:18 | Watusimoto | because the strategy I outlined should be exact and repeatable |
| 18:44:28 | Watusimoto | and not be affected by rotation |
| 18:45:31 | raptor | ok, then maybe I don't understand how yours differs - I basically left teh ray-finding in place, then applied a fix to make sure teh anchor was on a line perpendicular to the surface instead of a line on the ray |
| 18:46:16 | raptor | are you saying to do a rect-based database search? then just iterate through the objects to find the closest edge? |
| 19:06:36 | Watusimoto | sorry stepped a way for a sec |
| 19:06:42 | Watusimoto | yes, that's exactly it |
| 19:07:44 | Watusimoto | I wrote a function for finding the perpendicular to a line through a point (line being edge, point being turret mount point), that gave the distance and intersectoin (which would be the poential wall-mounting point) |
| 19:08:03 | Watusimoto | unfrotunately, i *think* this was for my previous job... but it is exactly what we would use here |
| 19:08:24 | Watusimoto | i never worked on this stuff because it always seemed to work well enough |
| 19:09:06 | raptor | we have that function in GeomUtils and that is what I used to find the accurate anchor |
| 19:09:16 | Watusimoto | but then you foudn some failure modes |
| 19:09:43 | raptor | well... arbitrary rotation of walls has always messed up FF placement... |
| 19:10:32 | raptor | and I think my fix solves somet of it, but after rotating around 360 degrees at increments, they were off by like 20 or points |
| 19:10:45 | raptor | more like 5- 10 poitns actually |
| 19:11:18 | Watusimoto | wow |
| 19:11:32 | Watusimoto | well |
| 19:11:37 | raptor | but at least they're on the same wall edge, before they could be anywhere |
| 19:11:42 | Watusimoto | do you change the turret coords after snapping? |
| 19:11:55 | raptor | i didn't touch any of that |
| 19:12:09 | Watusimoto | I recall that they were not changed |
| 19:12:13 | raptor | but i think snapping inheritently changes coords |
| 19:12:45 | raptor | the editor calls a resnap on any move - and that adjusts the anchor point and thus the whole geometry |
| 19:13:31 | Watusimoto | ok; I thought it kept the "placed" coords and moved it to the snapped coords |
| 19:13:54 | Watusimoto | if the "placed" coords are changing, then our course repeated rotation could screw things up.... lots of little increments can add up |
| 19:14:24 | Watusimoto | but if the "placed" coords are not changing, a 360 degree cumulative rotation should end up with the exact same thing as a 0 degree rotation |
| 19:15:03 | raptor | i'm not sure there is a definition of 'placed' (and therefore skip the resnap?), but maybe there should be? |
| 19:15:35 | Watusimoto | now that I think more about it, I thik you are right -- we just move the object to its new snapped location |
| 19:15:57 | Watusimoto | well, I'm really not sure this matters much |
| 19:16:18 | Watusimoto | what is the problem we are trying to solve |
| 19:16:20 | Watusimoto | ? |
| 19:16:29 | raptor | there are two problems |
| 19:16:35 | Watusimoto | selecting a turret and a wall and rotating them both? |
| 19:16:52 | raptor | 1. small migration of coordinates due to innaccurate resnapping of the engineered items |
| 19:17:03 | Watusimoto | under which circumstances/ |
| 19:17:06 | raptor | that would be triggered just but opening a level, and resaving it |
| 19:17:06 | Watusimoto | ? |
| 19:17:18 | raptor | that's it |
| 19:17:19 | Watusimoto | doing that twice should not move the turret |
| 19:17:39 | raptor | open a level with FFs, save it --> point moved |
| 19:17:42 | Watusimoto | ok, well, just talk me thorugh this a little |
| 19:17:50 | Watusimoto | I place a ff, it snaps to a nearby wall |
| 19:17:53 | Watusimoto | I save |
| 19:17:56 | raptor | yes |
| 19:17:57 | Watusimoto | I reload |
| 19:17:59 | raptor | yep |
| 19:18:10 | Watusimoto | the ff should reload with the position it was last snapped to |
| 19:18:16 | raptor | then resave and you'll see that the saved coords in the level file have changed by 0.003 or so |
| 19:18:18 | Watusimoto | then it probably resnaps |
| 19:18:23 | raptor | yep |
| 19:18:43 | Watusimoto | then it should end up back where it was |
| 19:18:52 | raptor | *should* but didn't |
| 19:19:05 | Watusimoto | actually, I could see with the ray method why it might not |
| 19:19:14 | raptor | the resnap code was inaccurate |
| 19:19:15 | raptor | yes |
| 19:19:20 | raptor | and I wrote that in the comments with my fix |
| 19:19:29 | Watusimoto | and is that problem now fixed? |
| 19:19:35 | raptor | yes, I bandaged it |
| 19:19:39 | Watusimoto | :-) |
| 19:19:39 | raptor | and it is quite accurate now |
| 19:19:55 | Watusimoto | I suspect when we go to levelcode 2.0 this problem will disappear |
| 19:20:00 | raptor | nope |
| 19:20:05 | Watusimoto | in fact, you can easily test it by creating a level with |
| 19:20:08 | Watusimoto | no? |
| 19:20:09 | raptor | it had nothing to do with gridsize |
| 19:20:16 | raptor | i tested with gridsize = 1 |
| 19:20:21 | Watusimoto | yes, that! |
| 19:20:37 | raptor | and output all the input and output points at various stages of the logic |
| 19:20:42 | raptor | gridsize was not the culprit |
| 19:21:02 | Watusimoto | I guess... if a turret was snapped to x,y, and then resnapped, with the ray method, it might end up at x',y' |
| 19:21:06 | raptor | printf was my friend for a few hours... |
| 19:21:10 | Watusimoto | ha |
| 19:21:13 | raptor | Watusimoto: correct |
| 19:21:28 | raptor | i found the exact point in the code that added the fuzziness |
| 19:21:53 | raptor | and that was with the ray-searching method for the closes wall |
| 19:22:16 | raptor | the output anchor point had moved oh-so-slightly from the input point (which was previously snapped) |
| 19:22:40 | Watusimoto | maybe if the anchor point is within x of the wall, consider it snapped and do no further snapping |
| 19:22:47 | raptor | I documented it in the comments of EngineeredItem.cpp:622 |
| 19:23:31 | raptor | Watusimoto: I thought about doing that too, but didn't go down that road because having an FF near a corner might be dicey |
| 19:23:32 | Watusimoto | so the issue is resnapping already snapped points |
| 19:23:37 | raptor | yes |
| 19:23:44 | Watusimoto | why would that be dicy? |
| 19:24:05 | raptor | how small of a distance check are you thinking? |
| 19:24:29 | Watusimoto | .1??? The proper number would be easy to determine with some printfs |
| 19:24:40 | raptor | within 0.001 of a point or less? because an FF in a corner could be close to two edges at that distance |
| 19:24:41 | Watusimoto | I'd look at how close they get to the wall after snapping |
| 19:25:11 | Watusimoto | ah, I see... and you need to know which wall its snapped to to orient it properly |
| 19:25:29 | raptor | yes - it may be possible to do, but I decided against it at the time.. |
| 19:25:37 | raptor | and came up with what I have.. |
| 19:25:48 | Watusimoto | ok, well, I won't argue with what works |
| 19:25:59 | Watusimoto | we can revisit it after we've fixed all our other bugs |
| 19:26:07 | Watusimoto | :-) |
| 19:28:46 | raptor | heh |
| 19:28:48 | raptor | yes |
| 19:29:41 | raptor | what matters is that it's better now, and I don't have the brain power for more algorithmic work before finals.. :) |
| 19:30:24 | Watusimoto | perfect! |
| 19:37:40 | | kaen has joined |
| 20:11:40 | raptor | interesting |
| 20:12:03 | raptor | the Provo city mayor just announce that we will become the 3rd city in the US to use Google Fiber |
| 20:14:34 | raptor | err maybe 4th city |
| 20:14:41 | raptor | I'm still looking for the catch.. |
| 20:16:07 | Watusimoto | wow |
| 20:16:19 | Watusimoto | you're not in provo are you? |
| 20:16:34 | Watusimoto | http://img832.imageshack.us/img832/1407/clipboardimagej.jpg |
| 20:16:34 | Watusimoto | http://img541.imageshack.us/img541/6540/screenshot41t.png |
| 20:16:40 | Watusimoto | so here aer two images |
| 20:16:47 | Watusimoto | the first shows minecraft's initial screen |
| 20:17:01 | Watusimoto | the second shows ours (with a little modification I'm trying out) |
| 20:17:15 | Watusimoto | I like our screen better |
| 20:17:22 | raptor | I like our screen better |
| 20:17:31 | Watusimoto | echo? |
| 20:17:33 | raptor | I think we should reduce the text at the bottom |
| 20:17:40 | raptor | and maybe add teh MOTD? |
| 20:17:51 | raptor | marco? |
| 20:17:51 | Watusimoto | I was thinking about the text at the bottom |
| 20:18:05 | Watusimoto | but it's kind of useful, no? |
| 20:18:07 | raptor | maybe we don't need the key instructions... |
| 20:18:15 | raptor | and the big para is a bit wordy |
| 20:18:32 | Watusimoto | hmmm maybe not |
| 20:18:57 | raptor | i mean, even my 3 year old can use the arrow keys... |
| 20:19:32 | Watusimoto | well, we could drop the para altogether and make some menu option somewhere that lets you enable autologin |
| 20:20:15 | Watusimoto | but |
| 20:20:28 | Watusimoto | when this screen is shown, the animatino plays |
| 20:20:39 | Watusimoto | and it feels like it takes forever |
| 20:20:49 | Watusimoto | because I'm used to instant start |
| 20:21:15 | raptor | yeah, waiting for the animation is no good.... maybe it can be quickened? |
| 20:21:30 | raptor | or constrained to just the top part |
| 20:21:49 | raptor | but one can skip it with ESC anyways, right? |
| 20:22:14 | raptor | and just have it do the quick fade it |
| 20:22:16 | raptor | *in |
| 20:22:48 | Watusimoto | currently, pressing any keys skips it |
| 20:23:17 | Watusimoto | thoguh that's disabled on the nick screen while I'm trying stuff out |
| 20:23:43 | raptor | because that's how it is now... nick -> animation -> main |
| 20:23:47 | Watusimoto | recall also that the instructions you want removed show joystick commands as well |
| 20:23:50 | Watusimoto | yes |
| 20:23:50 | raptor | now it's animation -> nick -> main |
| 20:24:00 | Watusimoto | yes |
| 20:24:02 | raptor | ah yes, the joystick commands |
| 20:24:09 | raptor | ok, maybe leave them |
| 20:24:12 | Watusimoto | but they're kind of obvious as well |
| 20:24:46 | Watusimoto | and they're currently not on the main menu |
| 20:24:58 | Watusimoto | and people seem to find their way past that pretty well |
| 20:25:11 | raptor | yeah... so back to removal :) |
| 20:31:33 | Watusimoto | http://img855.imageshack.us/img855/8436/screenshot42m.png |
| 20:31:49 | Watusimoto | too much green? |
| 20:32:08 | raptor | looks good |
| 20:32:24 | raptor | (and yes, I'm in Provo) |
| 20:32:53 | Watusimoto | well awesome |
| 20:33:02 | Watusimoto | let me solidify things a little and I'll check this in |
| 20:33:25 | Watusimoto | I think we'll need a menu item for skipping the login |
| 20:33:41 | raptor | (and Google will probably taking over my current fiber connection) |
| 20:33:43 | raptor | ok |
| 20:34:17 | Watusimoto | suddenly, I expect you'll find the alternatives get a lot better too |
| 20:36:32 | raptor | well... comcast/Quest and a couple of others have been horrible here, in my opinion |
| 20:37:08 | raptor | the fiber networks (which are probably going to merge with Google - that's probably why we were chosen) have been the only 'honest' ISPs around |
| 20:37:45 | Watusimoto | do I create a new class to eliminate repeating a single boolean? |
| 20:38:01 | raptor | comcast is notorious for taking advantage of non-provident people ($29 a month for 6 months! then they go to $80 and not tell you) |
| 20:38:13 | Watusimoto | comcast stinks |
| 20:38:18 | raptor | Watusimoto: maybe? |
| 20:38:24 | raptor | a new class... |
| 20:38:33 | raptor | so a parent class to handle a common member? |
| 20:38:37 | Watusimoto | yes |
| 20:38:45 | Watusimoto | a common boolean member |
| 20:39:04 | Watusimoto | IntroAnimationShowingMenu |
| 20:39:09 | raptor | ha |
| 20:39:20 | Watusimoto | because now we have two |
| 20:39:26 | Watusimoto | well, 3 if you count the credits |
| 20:39:35 | raptor | I have no problems with extra classes... as long as it doesn't include boost headers :) |
| 20:39:35 | Watusimoto | but that works a tad differently |
| 20:39:43 | raptor | or just keep it simple.. |
| 20:40:03 | Watusimoto | superclass! |
| 20:44:40 | raptor | kaen: I just played with one 'spicey' who was an admin of one of your servers... |
| 20:44:46 | kaen | indeed. |
| 20:45:51 | kaen | (that's my girlfriend playing from my other computer) |
| 20:45:55 | raptor | ah ha! |
| 20:46:03 | raptor | makes sense |
| 20:46:19 | raptor | Watusimoto: minecrafts' intro screen is waaaay too busy... |
| 20:46:36 | Watusimoto | indeed |
| 20:46:42 | Watusimoto | and they're quite popular |
| 20:46:49 | raptor | yeah we can do better! |
| 20:47:00 | Watusimoto | We have. they don't even have an animation. |
| 20:47:06 | raptor | heh |
| 20:47:12 | raptor | think the MOTD would be good to move there? |
| 20:47:16 | Watusimoto | I was showing it to make you feel better |
| 20:47:21 | Watusimoto | not sure about that |
| 20:47:35 | Watusimoto | let's try this first and see |
| 20:48:03 | raptor | ok |
| 21:25:29 | raptor | now i wonder kaen - if that poly2tri bug wouldn't affect us |
| 21:26:08 | raptor | because we're using clipper beforehand to merge all the holes into polygons, so there shouldn't be more than two points on a single line... |
| 21:27:33 | raptor | because if that's the case, poly2tri might be perfect - also it performs faster than Triangle in many cases |
| 21:27:45 | raptor | (according to the benchmarks it gives) |
| 21:41:00 | Watusimoto | we should do our own benchmarks if we get serious about this |
| 21:45:11 | | BFLogBot Commit: b5a3391a298c | Author: watusimoto | Message: Var name |
| 21:45:13 | | BFLogBot Commit: 35a31447cb4a | Author: watusimoto | Message: Use existing function instead of custom code |
| 21:45:15 | | BFLogBot Commit: 25065c692524 | Author: watusimoto | Message: Minor cleanups |
| 21:45:16 | | BFLogBot Commit: ddf1cd51a13c | Author: watusimoto | Message: Play intro animation before login screen, try to get a more integrated feel going on |
| 21:45:33 | raptor | well.. kaen has already devoted some work to it - but I think we should wait for Triangle guy's response |
| 21:46:14 | Watusimoto | I was just suggesting that we might make sure it performs well on our particular flavor of dataset |
| 21:46:25 | Watusimoto | but waiting is easiest! |
| 21:53:03 | raptor | commits! |
| 21:54:18 | raptor | and magicifying numbers! |
| 21:57:37 | raptor | Watusimoto: I like it! |
| 21:58:38 | Watusimoto | good! |
| 22:08:08 | | koda has joined |
| 22:38:44 | | raptor Quit (Disconnected by services) |
| 22:39:08 | | raptor has joined |
| 22:39:08 | | ChanServ sets mode +o raptor |
| 22:40:12 | | raptor Quit (Remote host closed the connection) |
| 22:42:43 | | raptor has joined |
| 22:42:43 | | ChanServ sets mode +o raptor |
| 22:52:49 | | masterkaen has joined |
| 22:55:40 | | kaen Quit (Ping timeout: 252 seconds) |
| 22:59:39 | | masterkaen is now known as kaen |
| 22:59:50 | | kaen Quit (Changing host) |
| 22:59:50 | | kaen has joined |
| 23:02:24 | raptor | interesting.. apparently while 1000 cities were bribing Google to be the next on the list to receive fiber, Google approached us |
| 23:03:29 | raptor | because Provo went into debt to build extensive fiber infrastructure already, and has been having management problems (because not enough people are buying it) |
| 23:03:42 | raptor | so Google said, we'll manage it |
| 23:13:30 | | fordcars has joined |
| 23:40:52 | | BFLogBot Commit: 77e3aaff84af | Author: watusimoto | Message: Create Input options menu |
| 23:40:53 | | BFLogBot Commit: 3d5ba9d51647 | Author: watusimoto | Message: Create a Sound Options menu |
| 23:41:09 | | Watusimoto_ has joined |
| 23:41:22 | raptor | oooo |
| 23:41:24 | raptor | yay |
| 23:41:25 | raptor | menus! |
| 23:41:35 | raptor | *sniff* we're growing up as a project |
| 23:43:17 | | Watusimoto Quit (Ping timeout: 256 seconds) |
| 23:46:34 | raptor | sound & other startling things |
| 23:50:49 | | fordcars_ has joined |
| 23:51:17 | Watusimoto_ | ever have the volume up too loud? |
| 23:51:36 | | fordcars Quit (Ping timeout: 245 seconds) |
| 23:52:53 | raptor | not in a long wile |
| 23:52:55 | raptor | *whil |
| 23:52:57 | raptor | e |
| 23:53:00 | raptor | coyote |
