Timestamps are in GMT/BST.
| 00:00:17 | YoshiSmb_ | kaen? |
| 00:00:34 | kaen | weekly play time :) |
| 00:00:44 | kaen | 8PM eastern every friday |
| 00:01:14 | YoshiSmb_ | ahh, |
| 00:01:14 | YoshiSmb_ | well, ONE PROBLEM |
| 00:11:24 | kumul | what is it YoshiSmb_ ? |
| 00:11:41 | YoshiSmb_ | dint sleep after 34hs |
| 00:12:32 | kumul | so you'll sleep later :) |
| 00:12:52 | YoshiSmb_ | nope |
| 00:13:16 | kumul | oh well, not like i can play either |
| 00:13:25 | YoshiSmb_ | i dint sleep this day and the other |
| 00:13:34 | YoshiSmb_ | but i have a energetic habit |
| 00:13:45 | YoshiSmb_ | so i can continue playing |
| 00:14:09 | kumul | lucky you :) |
| 00:14:34 | YoshiSmb_ | yea. |
| 00:14:44 | kumul | is it cocaine? |
| 00:15:06 | YoshiSmb_ | nope |
| 00:15:34 | YoshiSmb_ | i dont use drugs. what do you think? im a drogadict? |
| 00:16:01 | YoshiSmb_ | if you want, im hosting a server right now, you can join. |
| 00:16:06 | YoshiSmb_ | Gamemode: asteroids |
| 00:16:13 | kaen | I'm sure he was joking YoshiSmb_ :) |
| 00:16:21 | YoshiSmb_ | ahh. |
| 00:39:03 | kumul | literal person huh? this is gonna be fun :D |
| 00:39:34 | YoshiSmb_ | http://es-es.twitch.tv/sirdifferential |
| 00:39:38 | YoshiSmb_ | me vs Gekko |
| 01:01:11 | | amgine123 has joined |
| 01:01:17 | amgine123 | sup |
| 01:03:15 | amgine123 | hello? |
| 01:13:51 | YoshiSmb_ | hi |
| 01:15:17 | amgine123 | well osmone is here mlamo |
| 01:15:29 | YoshiSmb_ | yea |
| 01:19:00 | amgine123 | so any word on Bf 19 |
| 01:19:15 | YoshiSmb_ | nope |
| 01:21:51 | | Skybax Quit (Ping timeout: 246 seconds) |
| 01:23:59 | amgine123 | koda you afk? |
| 01:31:08 | koda | yes |
| 01:31:23 | amgine123 | any new uilds |
| 01:31:31 | amgine123 | builds for debugging |
| 01:32:00 | | Nothing_Much has joined |
| 01:32:46 | | Nothing_Much Quit (Client Quit) |
| 01:33:05 | | Nothing_Much has joined |
| 01:34:06 | Nothing_Much | Hi guys |
| 01:34:39 | YoshiSmb_ | hi |
| 01:34:51 | Nothing_Much | What's going on? |
| 01:41:15 | kaen | nothing much, one might say :) |
| 01:41:19 | kaen | back already, Nothing_Much ? |
| 01:46:13 | amgine123 | hey ken anything new/ |
| 01:50:54 | Nothing_Much | kaen: usin' an old laptop from a college at my aunts |
| 01:51:06 | kaen | ah I see |
| 01:51:14 | Nothing_Much | lags pretty badly with ubuntu 14.04 here |
| 01:51:20 | Nothing_Much | but it's all good |
| 01:51:20 | kaen | nope, nothing new really, amgine123 |
| 01:51:38 | Nothing_Much | tryin' to figure out why vivaldi fonts aren't working |
| 01:52:13 | Nothing_Much | do fonts have to be installed in the OS in order to see them in html? |
| 01:52:36 | kaen | yeah, usually that means font-config has to know about them (on linux) |
| 01:52:42 | Nothing_Much | oh nice |
| 01:52:54 | YoshiSmb_ | well. |
| 01:53:02 | YoshiSmb_ | G'nights |
| 01:53:07 | | YoshiSmb_ has left #bitfighter |
| 01:53:12 | Nothing_Much | l8r |
| 01:53:14 | | raptor has joined |
| 01:53:14 | | ChanServ sets mode +o |
| 01:53:23 | Nothing_Much | howdy |
| 01:53:48 | raptor | hi |
| 01:54:02 | kaen | hi |
| 01:54:09 | raptor | an odd thing just happened: my parents-in-law gave me a raspberry pi |
| 01:54:26 | Nothing_Much | :O |
| 01:54:29 | kaen | wow |
| 01:54:35 | Nothing_Much | wow, what a coincidence! |
| 01:54:35 | kaen | what divine providence |
| 01:54:41 | Nothing_Much | or something like that |
| 01:58:26 | Nothing_Much | that's fantastic news though! |
| 01:58:37 | Nothing_Much | but you might need an hdmi cable |
| 01:59:15 | raptor | have one |
| 01:59:22 | raptor | so now to install something |
| 01:59:44 | raptor | raspbian is the obvious choice |
| 01:59:48 | raptor | but then... |
| 01:59:50 | Nothing_Much | raspbian or just plain debian (armel version) |
| 01:59:55 | raptor | wheezy? |
| 02:00:00 | Nothing_Much | sure |
| 02:00:07 | Nothing_Much | wheezy's the latest stable version |
| 02:00:07 | raptor | what did fordcars install? |
| 02:00:16 | Nothing_Much | he just has raspbian |
| 02:00:19 | Nothing_Much | which has the pistore |
| 02:01:11 | raptor | kaen what do you think I should install? |
| 02:02:09 | raptor | maybe I should try openSUSE! |
| 02:02:56 | amgine123 | ehy rptor anything new to testing?? |
| 02:03:01 | Nothing_Much | does OpenSUSE have an arm build? |
| 02:03:25 | | koda Quit (Quit: koda) |
| 02:04:10 | raptor | yes, but it's too primitive - better stick with something more mature.. |
| 02:04:16 | raptor | wheezy it is |
| 02:04:24 | raptor | kaen: what are you running now? sid? |
| 02:04:37 | kaen | ubuntu 13.10 |
| 02:04:54 | kaen | what would I put on a pi? probably wheezy |
| 02:05:00 | raptor | yeah |
| 02:05:02 | raptor | ok |
| 02:05:04 | raptor | will do |
| 02:07:41 | | Nothing_Much Quit (Remote host closed the connection) |
| 02:10:48 | | Nothing_Much has joined |
| 02:11:36 | Nothing_Much | raptor: I would recommend using Raspbian for the time being |
| 02:14:26 | Nothing_Much | for dependency reasons |
| 02:15:09 | Nothing_Much | (ie, what dev files are needed to be installed for compiling on raspbian) |
| 02:20:04 | amgine123 | soni new builds raptor? |
| 02:46:28 | | Nothing_Much Quit (Ping timeout: 240 seconds) |
| 02:52:50 | | Nothing_Much has joined |
| 02:56:10 | Nothing_Much | what'd i miss? |
| 03:01:54 | Nothing_Much | brb |
| 03:03:05 | Nothing_Much | op hang on |
| 03:05:56 | | Nothing_Much Quit (Remote host closed the connection) |
| 03:06:54 | | Nothing_Much has joined |
| 03:07:11 | Nothing_Much | woo |
| 03:07:30 | Nothing_Much | so raptor, ya havin' fun with your Pi? |
| 03:26:58 | amgine123 | zzzzzz |
| 03:35:22 | | kumul Quit (Read error: Connection reset by peer) |
| 03:42:26 | Nothing_Much | well, good night everyone |
| 03:42:35 | | Nothing_Much Quit (Remote host closed the connection) |
| 03:54:35 | amgine123 | asdf |
| 04:01:41 | | raptor Quit () |
| 04:04:10 | amgine123 | uh master down? |
| 04:37:18 | amgine123 | never mind |
| 04:46:51 | | Platskies has joined |
| 05:01:19 | | amgine123 Quit (Ping timeout: 250 seconds) |
| 05:39:48 | | fordcars_pi has joined |
| 05:39:54 | fordcars_pi | Hi |
| 05:41:58 | fordcars_pi | Hey kaen, I have some weird javascript bug. When I alert(document.getElementById("acidId").value), everything is fine, but when I do var poo = document.getElementById("acidId"); alert(poo.value);, it says poo is null |
| 05:42:17 | fordcars_pi | It's a text field btw |
| 05:46:16 | fordcars_pi | oh, it says poo is undefined when I use var poo = document.getElementById.value |
| 06:07:05 | fordcars_pi | nm, I had to run that after the page was loaded, sorry! |
| 06:20:09 | | fordcars_pi Quit (Quit: Page closed) |
| 07:48:51 | | Platskies Quit (Quit: Leaving) |
| 07:54:50 | | Skybax has joined |
| 08:05:59 | | Skybax Quit (Ping timeout: 272 seconds) |
| 09:40:36 | | Watusimoto has joined |
| 10:05:47 | | HylianSavior Quit (Read error: Connection reset by peer) |
| 10:46:19 | | kaen Quit (Ping timeout: 272 seconds) |
| 10:54:28 | | Invisible1 has joined |
| 12:05:56 | | kumul has joined |
| 12:06:14 | | Nothing_Much has joined |
| 12:10:04 | Nothing_Much | good morning |
| 12:24:48 | kumul | morning |
| 12:25:06 | kumul | what are you up to? Nothing_Much ? |
| 12:55:03 | | Watusimoto Quit (Ping timeout: 260 seconds) |
| 12:55:31 | | Invisible1 Quit (Ping timeout: 260 seconds) |
| 13:04:29 | | Invisible1 has joined |
| 13:14:46 | | Invisible1 Quit (Ping timeout: 245 seconds) |
| 13:15:06 | | YoshiSmb has joined |
| 13:20:26 | Nothing_Much | kumul: myself and probably gonna head out sometime today |
| 13:50:11 | kumul | i thought you were gonna say Nothing_Much |
| 13:50:16 | kumul | who's probably though? |
| 13:50:44 | Nothing_Much | uh |
| 13:50:45 | Nothing_Much | lol |
| 13:50:59 | Nothing_Much | "what am I up to? Myself (nothing much)" |
| 13:51:15 | Nothing_Much | I'm actually going to go watch a musical in Manhattan today |
| 13:51:22 | Nothing_Much | or actually a pianist or something |
| 14:04:27 | YoshiSmb | Hi. |
| 14:34:43 | | Nothing_Much Quit (Remote host closed the connection) |
| 15:42:47 | kumul | hi YoshiSmb |
| 15:43:47 | YoshiSmb | hi |
| 15:43:57 | YoshiSmb | why dint you respond after 45 Min.? |
| 15:44:58 | kumul | i was jerking off? |
| 15:45:58 | kumul | YoshiSmb, why havent you responded after 1 minute? |
| 15:46:22 | kumul | :) |
| 15:46:29 | | YoshiSmb *sigh* |
| 15:46:42 | kumul | i was making an hdd to install freebsd |
| 15:46:51 | kumul | vdi** |
| 15:48:00 | YoshiSmb | ahh. |
| 15:48:16 | YoshiSmb | after 1 min i dint respond?? |
| 15:58:18 | kumul | yeah |
| 15:58:22 | kumul | it was timed perfectly |
| 15:58:24 | kumul | look |
| 15:58:31 | kumul | [11:44:42] <kumul> i was jerking off? |
| 15:58:31 | kumul | [11:45:42] <kumul> YoshiSmb, why havent you responded after 1 minute? |
| 15:58:34 | kumul | EXACTLY 1 MINUTE |
| 15:58:37 | | kaen has joined |
| 15:58:42 | YoshiSmb | ahh |
| 15:58:53 | YoshiSmb | well later, my brother want to use the netbook |
| 15:58:55 | YoshiSmb | bye |
| 15:58:58 | kumul | bye |
| 15:58:59 | | YoshiSmb has left #bitfighter |
| 16:42:57 | | koda has joined |
| 17:15:01 | | LordDVG has joined |
| 17:27:40 | | Canseco has joined |
| 18:07:53 | | koda Quit (Quit: koda) |
| 18:17:50 | | raptor has joined |
| 18:17:59 | | ChanServ sets mode +o |
| 18:27:45 | | raptor Quit () |
| 19:02:44 | | Darrel Quit (Read error: Connection reset by peer) |
| 19:02:53 | | Darrel has joined |
| 19:08:31 | | Canseco Quit (Quit: Leaving) |
| 19:17:33 | | Skybax has joined |
| 19:38:48 | | Watusimoto has joined |
| 20:07:58 | | HylianSavior has joined |
| 20:57:40 | | Invisible1 has joined |
| 21:01:05 | | raptor has joined |
| 21:01:05 | | ChanServ sets mode +o |
| 21:01:15 | raptor | hello! |
| 21:02:41 | kaen | hi! |
| 21:04:04 | kumul | Welcome! |
| 21:06:03 | kaen | "51/51 test methods complete: 20 passes, 7 fails, 48 assertions and 24 exceptions." |
| 21:06:10 | kaen | down from 41 exceptions this morning @_@ |
| 21:06:46 | kaen | I'm setting up pleiades onto my new dev machine |
| 21:07:03 | | bobdaduck has joined |
| 21:07:26 | | bobdaduck has left #bitfighter |
| 21:08:12 | | bobdaduck has joined |
| 21:08:15 | bobdaduck | Every time. |
| 21:08:42 | bobdaduck | Someone got a math second? |
| 21:09:58 | kaen | yep! |
| 21:10:21 | bobdaduck | Okay so when a player casts slow |
| 21:10:30 | bobdaduck | the enemy ship gets +5 seconds of slow |
| 21:10:44 | bobdaduck | I want their slow to gradually decay in that time, relative to how many seconds of slow they have left |
| 21:11:17 | bobdaduck | Kind of almost exactly the same as when I wanted to make gravity affect players more the closer they were to the center of the gravity well. |
| 21:11:40 | kaen | local currentSlow = MaxSlow * (slowTimeLeft / StartingSlowTime) |
| 21:11:44 | bobdaduck | What I currently have is something like shipVel = shipVel / slowTime |
| 21:12:05 | bobdaduck | but then the maximum ship speed before it hits normal is .5 and I want that to be bigger |
| 21:12:54 | kaen | ok, then you could do |
| 21:13:55 | kaen | local shipVel = normalVel * (slowTimeElapsed / MaxSlowTime) |
| 21:14:12 | bobdaduck | There's no maximum slow time |
| 21:14:14 | kaen | which will make it go from unable to move -> normal speed gradually over five seconds |
| 21:14:27 | bobdaduck | or a slowtime elapsed |
| 21:14:44 | kaen | you'll probably need at least one of those |
| 21:16:51 | bobdaduck | ugh |
| 21:17:35 | bobdaduck | why? |
| 21:18:22 | bobdaduck | I don't even know how I would make a slowTimeElapsed variable... |
| 21:19:29 | bobdaduck | I swear there is some way to do this using logarithms |
| 21:42:38 | kaen | local shipVel = realVel - math.min(math.log(slowTimeLeft * SlowFactor), 1.0) |
| 21:42:41 | kaen | bobdaduck: ^ |
| 21:42:47 | kaen | sorry I was afk |
| 21:43:49 | kaen | maybe use realVel instead of 1.0 |
| 21:44:40 | kaen | and SlowFactor might need to be less than 1.0 do get a good effect |
| 21:48:23 | Watusimoto | hello |
| 21:48:37 | Watusimoto | hey raptor, I'm working on the editor geometry problem |
| 21:48:46 | Watusimoto | do remember how to reproduce it? |
| 21:48:57 | Watusimoto | the precision issue |
| 21:50:37 | bobdaduck | what is slowfactor kaen? |
| 21:50:56 | kaen | it's a constant you tweak to control the log's curve |
| 21:51:58 | bobdaduck | so I set shipVel to be realVel? |
| 21:54:43 | kaen | it might actually be better to control the ship's thrust |
| 21:54:58 | bobdaduck | or shipVel IS realvel? |
| 21:55:12 | kaen | shipVel is what you set the ship's velocity to |
| 21:55:27 | kaen | realVel is the real velocity it would have normally |
| 21:55:32 | bobdaduck | okay |
| 21:56:21 | bobdaduck | attempt to perform arithmetic on a point value... |
| 22:01:23 | kaen | ok use point.lengthSquared(realVel) instead of realVel |
| 22:01:31 | kaen | or might as well actually be point.length() |
| 22:03:45 | kaen | local shipVel = (realVel / point.length(realVel)) * point.length(realVel) - math.min(math.log(slowTimeLeft * SlowFactor), point.length(realVel)) |
| 22:04:07 | kaen | obviously point.length(realVel) should be assigned to a variable and used instead |
| 22:04:52 | kaen | and you'll probably need parentheses around everything after the first * |
| 22:12:54 | raptor | hi Watusimoto |
| 22:13:04 | Watusimoto | hi |
| 22:13:06 | raptor | two polywalls |
| 22:13:07 | Watusimoto | I think I fixed it |
| 22:13:17 | raptor | put a corner of one not on snapped grid |
| 22:13:22 | Watusimoto | testing with zones, but should work with polywalls |
| 22:13:34 | raptor | put corner of other on the first corner |
| 22:13:36 | raptor | save file |
| 22:15:01 | Watusimoto | well... not quite fixed, but better |
| 22:15:26 | Watusimoto | probably as good as we'll get with F32s |
| 22:17:45 | raptor | better how? |
| 22:17:55 | raptor | before the level file would have differences of up to 0.002 |
| 22:18:36 | Watusimoto | this is about the worst case I've found: |
| 22:18:37 | Watusimoto | PolyWall -0.47385 -1.58934 -0.47385 -1.28934 0.42615 -1.28934 0.42615 -1.58934 |
| 22:18:37 | Watusimoto | PolyWall -0.473847 -1.589337 -0.473847 -1.289337 0.426153 -1.289337 0.426153 -1.589337 |
| 22:18:42 | | bobdaduck Quit (Ping timeout: 246 seconds) |
| 22:20:42 | raptor | that is better |
| 22:21:07 | Watusimoto | yes... about 10x better |
| 22:21:11 | Watusimoto | often it is perfect |
| 22:21:17 | raptor | within 0.00001 |
| 22:22:00 | Watusimoto | you know, I could do this one little bit of math with F64 and I bet we'd be perfect |
| 22:22:12 | raptor | sure, try that |
| 22:22:27 | raptor | i think the tostring() rounds at 6 decimal places, right? |
| 22:22:53 | raptor | these numbers get muliplied by 255000 |
| 22:22:57 | raptor | for clipper |
| 22:24:26 | Watusimoto | I don't think toString rounds at all |
| 22:24:33 | Watusimoto | I think it prints with %f |
| 22:25:11 | raptor | I %f chops after 6, no? |
| 22:25:16 | raptor | *I think |
| 22:25:18 | Watusimoto | not perfect |
| 22:25:18 | Watusimoto | PolyWall -1.255233 -1.530992 -1.255233 -1.230992 -0.355233 -1.230992 -0.355233 -1.530992 |
| 22:25:19 | Watusimoto | PolyWall -1.255231 -1.530992 -1.255231 -1.230993 -0.355231 -1.230993 -0.355231 -1.530992 |
| 22:25:25 | Watusimoto | but better still |
| 22:25:45 | Watusimoto | I don't know about %f |
| 22:26:00 | raptor | worst case within 0.000002 |
| 22:26:09 | Watusimoto | PolyWall -1.148478 -1.138424 -1.148478 -0.838424 -0.248478 -0.838424 -0.248478 -1.138424 |
| 22:26:09 | Watusimoto | PolyWall -1.148481 -1.138425 -1.148481 -0.838426 -0.248481 -0.838426 -0.248481 -1.138425 |
| 22:26:22 | raptor | 0.000003 |
| 22:26:29 | Watusimoto | not much better than with F32 |
| 22:26:47 | Watusimoto | good to 4 decimals either way |
| 22:27:07 | Watusimoto | well, a little better, perhaps |
| 22:27:15 | Watusimoto | but worth the ugliness? |
| 22:27:24 | raptor | maybe the toString() can S32(F32*10000)/10000 |
| 22:27:31 | Watusimoto | the top 2 lines replace the bottom one |
| 22:27:32 | Watusimoto | F64 x = ((F64)obj->getVert(j).x - (F64)obj->getPos().x) + ((F64)mMoveOrigins[i].x + (F64)offset.x); |
| 22:27:32 | Watusimoto | F64 y = ((F64)obj->getVert(j).y - (F64)obj->getPos().y) + (F64)(mMoveOrigins[i].y + (F64)offset.y); |
| 22:27:32 | Watusimoto | //newVert = (obj->getVert(j) - obj->getPos()) + (mMoveOrigins[i] + offset); |
| 22:27:47 | Watusimoto | newVert = Point((F32)x, (F32)y); |
| 22:27:49 | raptor | I think truncation in the toString might be better... |
| 22:28:31 | Watusimoto | with truncation, things will move slightly when saving, no? |
| 22:29:08 | Watusimoto | is this really still a problem? |
| 22:30:00 | raptor | it's not a problem wiht poly2tri anymore after my fixes |
| 22:30:02 | raptor | but |
| 22:30:51 | raptor | it is a problem when putting polywalls together so they're flush, then saving, then loading a level and seeing a thin wall break where you put it as flush |
| 22:31:04 | Watusimoto | truncating won't fix that, will it? |
| 22:32:10 | raptor | well, if we're guaranteed within 0.00001 with F32 then truncatation at 0.0001 (10x) will always work and add consistency |
| 22:32:24 | Watusimoto | I think the fix is to get rid of gridsize |
| 22:32:33 | Watusimoto | and stop dividing the level by 256 |
| 22:32:38 | raptor | level file version 2! |
| 22:32:40 | raptor | I agree |
| 22:32:45 | Watusimoto | we don't even need that |
| 22:33:49 | raptor | no gridsize + your precision adjustments would guarantee the within 0.001 we need with clipper |
| 22:34:10 | Watusimoto | set gridsize to 1 and draw grid differently on levels with gridsize = 1 |
| 22:34:25 | Watusimoto | I think everything else will work as-is |
| 22:34:42 | raptor | server-side, load values at 1 unless gridsize exists |
| 22:35:01 | raptor | client-side, have gridsize be an ini option for editor viewing only |
| 22:35:36 | Watusimoto | server-side is the same as defaulting gridsize to 1 |
| 22:35:59 | Watusimoto | and I would say clientside, we just don't add it to levels any more |
| 22:36:05 | raptor | yes |
| 22:36:14 | Watusimoto | or if we do, we say gridsize 1 |
| 22:36:41 | Watusimoto | the only thing not putting gridsize in might break are existing levels with no gridsize param that depend on current default of 255 |
| 22:37:03 | Watusimoto | but the editor has been adding gridsize param forever that there can't be many such levels out there |
| 22:38:05 | raptor | yeah, i'm not sure those levels exist... |
| 22:38:36 | Watusimoto | set gridsize to 5 (min in editor currently) |
| 22:38:36 | Watusimoto | BarrierMaker 50 -884.180054 1906.580322 -879.580078 1906.980225 -879.380066 1909.280273 -876.580078 1910.180298 -876.480103 1911.380249 -872.78009 1913.080322 |
| 22:38:37 | Watusimoto | BarrierMaker 50 -884.180054 1906.580322 -879.580078 1906.980225 -879.380066 1909.280273 -876.580078 1910.180298 -876.480103 1911.380249 -872.78009 1913.080322 |
| 22:38:44 | Watusimoto | and that's with F32 |
| 22:38:54 | raptor | oh wow |
| 22:38:57 | raptor | that's great! |
| 22:39:15 | raptor | ok, I have 167 levels... all have gridsize in them |
| 22:39:20 | Watusimoto | I can't get any error anywhere |
| 22:40:52 | Watusimoto | ok, so gridsize = 1 is the full solution |
| 22:41:08 | Watusimoto | the question is is this a 019 or 019a/020 issue? |
| 22:42:08 | | Invisible1 Quit (Ping timeout: 240 seconds) |
| 22:43:04 | raptor | depends on how much we break things... |
| 22:43:35 | raptor | well, your precision changes should be included for sure |
| 22:45:31 | | bobdaduck has joined |
| 22:45:36 | Watusimoto | I pushed the F32 fix |
| 22:45:45 | Watusimoto | the F64 fix is included as well, but is commented out |
| 22:46:00 | Watusimoto | I closed the current case for this |
| 22:46:01 | | BFLogBot Commit: b8ce14eee855 | Author: watusimoto | Message: Break up big function into smaller parts |
| 22:46:02 | | BFLogBot Commit: a95f31058408 | Author: watusimoto | Message: Remove temp logging |
| 22:46:04 | | BFLogBot Commit: 0798e96b0bae | Author: watusimoto | Message: Improve editor precision when dragging objects |
| 22:46:06 | Watusimoto | I opened a new case about gridsize |
| 22:46:22 | raptor | ok |
| 22:46:29 | Watusimoto | I tagged it with 019a |
| 22:46:31 | Watusimoto | but |
| 22:46:55 | Watusimoto | if we are going to do this in 019a, we probably need to change the default gridsize (curr. 255) now, so servers will remain compatible |
| 22:47:18 | Watusimoto | so I'll do that now |
| 22:47:20 | raptor | ok |
| 22:47:31 | raptor | i'll do the client-side fixes when you're done |
| 22:47:44 | raptor | so the server-side logic is just to change default to 1.0f? |
| 22:47:53 | raptor | no other logic needed? |
| 22:48:17 | Watusimoto | interesting comment: |
| 22:48:18 | Watusimoto | static const S32 DefaultGridSize = 255; // Size of "pages", represented by floats for intrapage locations (i.e. pixels per integer) |
| 22:49:02 | Watusimoto | not sure :-) But I think so, as grid size is only used when reading/writing levels... I think |
| 22:49:46 | raptor | weird |
| 22:50:24 | Watusimoto | doesn't appear to be used anywhere in the game itself |
| 22:50:32 | Watusimoto | so i think we're safe |
| 22:56:32 | raptor | it's in geomobject saving somewhere |
| 22:56:44 | raptor | there's a getGridSize method somewhere... |
| 22:58:09 | Watusimoto | actually, I think we should do it all at once -- just get rid of the gridsize, and not change the default earlier |
| 22:58:30 | raptor | what about old levels? |
| 22:58:49 | raptor | maybe I misunderstood... |
| 22:59:07 | Watusimoto | we'll still use it if its in the levelfile; multiply all coordinates by the gridsize as always, but save without gridsize |
| 22:59:21 | raptor | actually, we broke GridSize in 017, I think - it was changed to be permanently 255 |
| 22:59:29 | raptor | yes |
| 22:59:33 | raptor | ok, that sounds good |
| 22:59:33 | Watusimoto | you can set it in the editor |
| 22:59:50 | Watusimoto | earlier I said we should change the default now so we can alter the editor later |
| 22:59:57 | Watusimoto | but now I think we should just do both at once |
| 23:00:02 | Watusimoto | fewer surprises that way |
| 23:00:10 | raptor | I agree |
| 23:00:21 | Watusimoto | so that would mean eitehr for 019 or 020 |
| 23:00:24 | raptor | (honestly, I was planning on doing the other half of the work for 019 anyways) |
| 23:00:35 | Watusimoto | sounds like you just want to get it done now |
| 23:00:53 | Watusimoto | in which case I'll leave you to it and I'll work on other stuff for the release |
| 23:00:53 | raptor | yes... |
| 23:01:10 | Watusimoto | I know that you and kaen are itching to do the release |
| 23:01:14 | raptor | ok, should we truncate to 0.001 in the level file when saving real points? |
| 23:01:25 | Watusimoto | I'd say no |
| 23:01:29 | raptor | k |
| 23:01:46 | Watusimoto | I think the gridsize = 1 will fix the issue |
| 23:01:51 | Watusimoto | completely |
| 23:02:18 | Watusimoto | and truncation won't fix the problem |
| 23:02:19 | raptor | me too, but i was thinking about the increase of level filesize |
| 23:02:28 | Watusimoto | you'll still get things moving after you save |
| 23:02:39 | Watusimoto | because their coords will be changed |
| 23:02:42 | raptor | also, do we have a line length limit? |
| 23:02:45 | raptor | kaen? |
| 23:02:50 | Watusimoto | I think we no longer do |
| 23:03:07 | Watusimoto | I'm not really worried about file size |
| 23:03:11 | Watusimoto | it's all local disk |
| 23:03:34 | Watusimoto | and we're currently saving with 6 decimals anyway |
| 23:03:36 | | LordDVG Quit (Remote host closed the connection) |
| 23:04:23 | Watusimoto | I created a new tag for the bug tracker... gci |
| 23:04:41 | Watusimoto | for tasks that could be appropriate for gci students/others who want to get their feet wet |
| 23:06:05 | raptor | how is it transmitted then? |
| 23:06:19 | raptor | ok, gci, ok |
| 23:07:17 | Watusimoto | it's transmitted as F32, I think |
| 23:07:34 | Watusimoto | but that happens long after points are reconsitituted from the file |
| 23:08:13 | raptor | ok good |
| 23:08:31 | Watusimoto | so truncating won't help |
| 23:08:37 | raptor | FYI - my parents-in-law just gave me a raspberry pi |
| 23:08:46 | raptor | so... a new platform to test! |
| 23:10:43 | Watusimoto | I love pie! |
| 23:11:29 | Watusimoto | I'm not sure which I would prefer -- a rasberry pi or a rasberry pie |
| 23:11:51 | raptor | if there's enough whipped cream, then either sounds fine... |
| 23:19:35 | | BFLogBot Commit: fcf5a02203ec | Author: watusimoto | Message: Avoid crashing when the "empty vertex problem" arises... however that happens |
| 23:19:36 | | BFLogBot Commit: 10fe5502f742 | Author: watusimoto | Message: Add some debugging advice to assert |
| 23:19:38 | | BFLogBot Commit: 58638e8b37a2 | Author: watusimoto | Message: Head off an unlikely bug before it happens -- we depend on this being the 0th vert, so let's just be explicit in case getPos() ever gets a different vert. |
| 23:34:28 | Watusimoto | kaen: quick question about the mysterious empty vertex assert you reported |
| 23:34:45 | raptor | Watusimoto: that empty vertex problem is related to amgines asserts as well, it hink |
| 23:34:49 | Watusimoto | could you have got that when you were playing with loadout zones that had been scrunched onto one single point? |
| 23:35:03 | Watusimoto | yes, that was where I was going |
| 23:35:07 | raptor | ha, exactly |
| 23:35:17 | Watusimoto | I just got that assert playing with the weird geom problme |
| 23:35:31 | Watusimoto | ultimately, the fix is probably not to load b0rked geometries |
| 23:35:49 | Watusimoto | but I want to understand what is happening to make the editor more fault tolerant in general |
| 23:37:26 | raptor | i've given it some thought... and I don't know what to do when people do things like that.. |
| 23:37:37 | raptor | i know that it was popular for a while to make 0-point barriers |
| 23:38:48 | raptor | alsi in release mode, the game wouldn't actually crash, would it? |
| 23:39:27 | Watusimoto | yes, it would |
| 23:39:49 | raptor | ok, then that's bad |
| 23:39:59 | Watusimoto | yes it is |
| 23:40:11 | Watusimoto | the assert was protecting a crash situation |
| 23:42:10 | kaen | you know, I think you're right |
| 23:42:27 | kaen | that it was related to a zero-vertex loadout zone |
| 23:42:35 | kaen | but only after I had saved the level and reloaded it |
| 23:42:46 | kaen | and it moved back to the origin, too |
| 23:43:33 | kaen | also, I'm not familiar with the function in question, but if an assert is protecting the program from a crash, we should probably just return when the assert would fail in release mode |
| 23:46:08 | Watusimoto | returning also causes a crash |
| 23:46:43 | Watusimoto | kaen -- you expanded the number of vertices in a wall to infinity, right? |
| 23:46:53 | kaen | yes |
| 23:46:55 | Watusimoto | did you do the same for polywalls and loadout zones? |
| 23:47:04 | kaen | polywalls, yes |
| 23:47:07 | kaen | zones... I'm not sure |
| 23:47:17 | Watusimoto | I think maybe not |
| 23:47:25 | kaen | I think you're right |
| 23:47:41 | Watusimoto | I think they still have 64 point limit |
| 23:47:50 | kaen | or actually, I know they can *have* infinite vertices, but they only write 64 |
| 23:48:04 | Watusimoto | and only read 64 |
| 23:48:10 | kaen | that sounds right |
| 23:48:31 | raptor | kaen: any objects to changing the default gridsize to 1? |
| 23:48:35 | raptor | *objections |
| 23:48:40 | kaen | nope |
| 23:48:45 | kaen | been a long time coming :) |
| 23:48:51 | raptor | oh goodie |
| 23:49:24 | Watusimoto | ok, made a case for 019a |