Timestamps are in GMT/BST.
| 01:00:48 | | fordcars Quit (Quit: Page closed) |
| 01:05:22 | | raptor has joined |
| 01:05:22 | | ChanServ sets mode +o |
| 01:05:27 | raptor | good evening! |
| 01:13:31 | sam686 | hi |
| 01:13:38 | raptor | hi |
| 01:14:24 | raptor | i'm looking for examples of opus+FEC (forward error correction) |
| 01:14:35 | raptor | apparently it's built-in somehow, i jsut need to figure it out |
| 01:17:55 | sam686 | we went from the horrible and weard sound quality (bf 015) to speex (018), then whats next, opus? |
| 01:18:12 | raptor | yes, or.. maybe... nothing? |
| 01:18:19 | raptor | do we need voice chat? |
| 01:18:35 | raptor | ... this has just been a fun project for me trying to figure out the technology |
| 01:20:12 | sam686 | i don't know if its worth all the work just for opus over speex when its about only a little bit better opus quality |
| 01:20:26 | raptor | it will be lower bitrate |
| 01:20:53 | raptor | i tested with the larger packet size, the max went from ~17kpbs to ~12kbps |
| 01:21:05 | sam686 | ok |
| 01:21:07 | raptor | so most of the overhead was s2c sending |
| 01:21:32 | raptor | yeah, it's probably not worth the work.. but it's been a fun project :) |
| 01:21:44 | sam686 | bandwidth maybe somewhat reduced on opus |
| 01:27:23 | sam686 | http://en.wikipedia.org/wiki/Speex hey look it says "obsolete" |
| 01:27:30 | sam686 | http://en.wikipedia.org/wiki/Opus_(audio_format) |
| 01:27:35 | raptor | yes |
| 01:27:49 | sam686 | most says opus is better, |
| 01:43:34 | raptor | huh, so I think I'm close to getting it but |
| 01:43:43 | raptor | how would i tell if a packet was lost from TNL? |
| 01:45:25 | sam686 | you could run it and press F6 button multiple times |
| 01:45:39 | raptor | i mean, from within c++ |
| 01:45:53 | raptor | i used your /lag 0 10 trick |
| 01:47:21 | sam686 | controlObjectConnection.cpp have some handling of ControlObjectConnection::packetReceived, and packetDropped can also be used there |
| 01:47:42 | sam686 | but for RPC i don't think theres an easy way |
| 01:49:38 | sam686 | in addition, 1 packet could pack in 2 or more events, packet dropped? then all events in that packet need to be re-sent if guaranteed, or its gone if unguaranteed |
| 01:50:17 | raptor | woudl it be bad if the s2c was sent as GuaranteedOrdered? |
| 01:51:30 | sam686 | you can try it |
| 01:52:07 | raptor | Guaranteed increases bitrate doesn't it? |
| 01:52:25 | sam686 | bye the way RPC doesn't break network compaibility from simply changing RPCUnguaranteed to RPCGuaranteed or anything |
| 01:52:40 | sam686 | guaranteed increases bandwidth only when there is dropped packets |
| 01:53:03 | sam686 | well, the receiver won't see the increase bandwidth, only the sender does.. |
| 01:53:37 | raptor | oh really... i didn't know that it didn't break network compatibility |
| 01:55:23 | sam686 | I think I once changed from Guaranteed GuaranteedOrdered and it stayed compatible, it goes by what the sender have it set to |
| 01:56:56 | sam686 | an idea to reduce bandwidth at the cost of server CPU, have the server decompress everyone's voice, compine into one stream, then send it to clients. |
| 01:57:33 | raptor | ha! |
| 01:58:29 | sam686 | but then theres a problem with that, we don't want to echo your voice back to you if not on... |
| 01:59:44 | sam686 | another idea is to have one client's voice send directly to other clients bypassing the server, that may help reduce server load... |
| 02:00:05 | sam686 | but then problems with NAT and firewall may limit that ability.. |
| 02:00:56 | raptor | packet max is 1500 bits or bytes? |
| 02:01:05 | sam686 | bytes |
| 02:01:25 | sam686 | http://en.wikipedia.org/wiki/Maximum_transmission_unit |
| 02:02:51 | sam686 | the ip header may reduce the limit of UDP without fragmenting |
| 02:05:49 | sam686 | THE UDP header is 20 bytes long for ipv4 http://en.wikipedia.org/wiki/User_Datagram_Protocol#IPv4_Pseudo_Header |
| 02:12:54 | | Watusimoto has joined |
| 02:22:11 | raptor | ok, need to sleep... looks like my implementation didn't quite work out |
| 02:22:17 | raptor | i need to see example code |
| 02:30:58 | | raptor Quit () |
| 04:08:23 | | Watusimoto Quit (Ping timeout: 245 seconds) |
| 05:15:37 | | Nothing_Much Quit (Read error: Connection reset by peer) |
| 05:15:56 | | Nothing_Much has joined |
| 05:20:00 | | LordDVG has joined |
| 07:22:31 | | LordDVG Quit (Remote host closed the connection) |
| 10:11:01 | | Raven67854 Quit (*.net *.split) |
| 10:18:06 | | Raven67854 has joined |
| 10:46:54 | | Watusimoto has joined |
| 10:49:13 | | Raven67854 Quit (Ping timeout: 272 seconds) |
| 10:58:49 | | Raven67854 has joined |
| 11:09:34 | | Watusimoto Quit (Ping timeout: 240 seconds) |
| 11:30:48 | | Raven67854 Quit (Remote host closed the connection) |
| 11:34:38 | | fordcars has joined |
| 11:41:37 | | Raven67854 has joined |
| 12:17:00 | | Watusimoto has joined |
| 12:31:26 | | watusimoto1 has joined |
| 12:37:32 | | Watusimoto_ has joined |
| 12:40:04 | | Watusimoto Quit (Ping timeout: 258 seconds) |
| 13:04:49 | | Raven67854 Quit (Quit: Leaving) |
| 13:08:15 | | Raven67854 has joined |
| 13:24:25 | | raptor has joined |
| 13:24:25 | | ChanServ sets mode +o |
| 13:24:37 | raptor | good day! |
| 13:31:41 | fordcars | Hi! |
| 13:32:07 | | Watusimoto_ Quit (Ping timeout: 272 seconds) |
| 13:40:59 | watusimoto1 | guten morgen! |
| 13:41:05 | | watusimoto1 is now known as watusimoto |
| 13:41:13 | raptor | buenos dias! |
| 13:41:20 | watusimoto | bom dia! |
| 13:41:36 | raptor | I get to do a technical assessment of a possible new hire for our team today... |
| 13:41:55 | watusimoto | sounds like lots of fun |
| 13:42:29 | raptor | it's really just a filter test, i think |
| 13:42:57 | raptor | maybe i'll make hime write something that can be done with a for loop or done with nested if statements... |
| 13:52:17 | | Watusimoto_ has joined |
| 13:54:51 | | Watusimoto__ has joined |
| 13:56:07 | watusimoto | write a function to reverse a string |
| 13:56:14 | watusimoto | that's what they did in one of my interviews |
| 13:56:38 | raptor | that seems like an OK idea.. |
| 13:56:49 | watusimoto | have them write a bot for bitfighter |
| 13:57:30 | | Watusimoto_ Quit (Ping timeout: 258 seconds) |
| 13:57:45 | raptor | i'm pretty sure this candidate doesn't have tons of experience with JEE which we use... so it'll have to more-or-less language agnostic |
| 13:58:13 | watusimoto | my string reversal was in a blend of python and c++, with a few other random bits thrown in |
| 13:58:26 | raptor | you used two languages?? |
| 13:58:51 | watusimoto | I used no languages, just threw my stuff up there; that's what came out |
| 13:59:11 | raptor | ahhh... a whiteboard test! |
| 13:59:29 | watusimoto | ha ha, just kidding... I actually wrote a small python interpreter in C++, and wrote the reversal in python |
| 13:59:38 | raptor | right... |
| 13:59:39 | watusimoto | I mean, how else would you do it? |
| 14:00:23 | raptor | i should require he write a simple java bytecode compiler with his own made-up language |
| 14:00:53 | watusimoto | should be easy enough... that way he can use whatever syntax he's comfortable with |
| 14:03:41 | watusimoto | I have a bad bitfighter design dilemma... when adding walls to the spatial db, historically we've added full-on wall items when in the editor, and short 2-point segments in the game. The short segments are faster for hit detection, the full walls are better for manipulation. I'm trying to unify the two worlds so we can just add walls (or segments) to the database when we load the level and treat them like any other object. But I'm not |
| 14:04:12 | raptor | i think i only got part of that statement... |
| 14:04:23 | watusimoto | only received, or only understood? |
| 14:04:27 | raptor | received |
| 14:04:34 | raptor | ended with "But I'm not" |
| 14:04:43 | watusimoto | But I'm not sure which of the two models would work better as a universal solution |
| 14:04:59 | raptor | so it's an either/or scenario? |
| 14:05:09 | watusimoto | I started porting the editor to use segments, but it makes the code complex and ugly |
| 14:05:23 | watusimoto | it's an either/or situation if we want a universal solution |
| 14:05:29 | raptor | yeah... i wouldn't do that to the editor |
| 14:05:33 | raptor | well |
| 14:05:43 | raptor | how are the walls transmitted from server -> client? |
| 14:06:11 | fordcars | With internet, raptor |
| 14:06:24 | watusimoto | well, I made each segment point to a full wall object that was not in the database, so you had an extra level of indirection in the editor (click on a segment, and you need to then grab the wall from the segment's wall pointer) |
| 14:06:25 | raptor | quiet you... |
| 14:06:29 | fordcars | :3 |
| 14:06:40 | watusimoto | walls are transmitted as a series of points |
| 14:06:51 | watusimoto | the ones that are stored in the level file |
| 14:07:19 | raptor | so one, say, 5-point barrier is transmitted as one barrier at level load, right? |
| 14:07:32 | watusimoto | on the client, it's not problem; we can use either/both/whatever -- we don't have a unified loading situation there |
| 14:07:45 | watusimoto | transmitted, yes |
| 14:07:52 | raptor | ok, so that's good |
| 14:07:55 | raptor | now server side |
| 14:08:02 | watusimoto | but added to the database on the client as 4 items |
| 14:08:22 | raptor | ok |
| 14:08:30 | watusimoto | which makes sense from a performance pov |
| 14:08:34 | raptor | is that for efficiency in render-triangulation? |
| 14:08:46 | watusimoto | mostly for hit-detection |
| 14:08:51 | raptor | on the client side? |
| 14:08:54 | watusimoto | yes |
| 14:09:11 | raptor | ah ok, that's right. now i remember why /showids was useless for walls |
| 14:09:19 | watusimoto | rendering is a separate beast... we do trianguation of the whole wallset, I think, or perhaps seach segment.... not sure |
| 14:09:33 | raptor | server side does the same thing, correct? builds 4 segments and inserts them into the DB? |
| 14:09:46 | watusimoto | if we move to whole walls, we could allow server manipulation of walls on the client |
| 14:09:57 | raptor | OOoooo |
| 14:10:10 | fordcars | Yes! |
| 14:10:11 | raptor | then @admin->type Lua in console-> cheat! |
| 14:10:16 | | LordDVG has joined |
| 14:10:17 | watusimoto | well, we might be able to do that in any case, as long as the server has whole walls |
| 14:10:26 | raptor | ok, how are polywalls handled? |
| 14:10:31 | watusimoto | the client could work either way, easily |
| 14:10:44 | watusimoto | polywalls are the same as anything else... a single multipoint object |
| 14:10:58 | raptor | what if the barrier was jsut converted to a polywall like structure with appropriate polygon collision? |
| 14:11:01 | watusimoto | when walls are added to the db, they are added as 4 pt polywalls, essentially |
| 14:11:16 | watusimoto | still have the performance issue |
| 14:11:25 | watusimoto | imagine a large arcing wall |
| 14:11:28 | raptor | higher than normal polywalls? |
| 14:11:32 | watusimoto | the same |
| 14:11:41 | raptor | then we need to implement... bezier curves! |
| 14:11:44 | watusimoto | but polywalls tend to be more compact |
| 14:11:50 | watusimoto | so you have a long arcing wall |
| 14:11:56 | watusimoto | it's bounding box is huge |
| 14:11:56 | raptor | that's true |
| 14:12:16 | watusimoto | so when you add it to the db, more db "bins" get marked as contining that wall |
| 14:12:27 | raptor | hmmm |
| 14:12:50 | watusimoto | and then when you cycle through the items in the db to do the hit detection, you have lots more points to consider on the wall that may or may not actually touch a bin |
| 14:13:00 | watusimoto | more, smaller objects are better |
| 14:13:11 | raptor | yes ok |
| 14:13:12 | watusimoto | to a point, obviously |
| 14:13:29 | watusimoto | so there are two performance issues |
| 14:13:30 | raptor | sounds like we'll need complexity if we want efficiency |
| 14:13:41 | raptor | back in 5... sorry! |
| 14:13:46 | watusimoto | the first could be solved by being more intelligent about which bins we mark as containing the item |
| 14:13:56 | watusimoto | no worries... I'll jsust finish this thought |
| 14:14:39 | watusimoto | so if we spent a little more time figuring out which bins actually touched an object, the large arcing wall would not be problematic from the first pov |
| 14:14:52 | watusimoto | and it would improve performance of large, weird polywalls |
| 14:15:17 | watusimoto | but the second issue would still exist... long complex walls would still require much more processing to determine if there was a hit or not |
| 14:15:58 | watusimoto | the solution to the first problem involves a moderate one-time cost during game setup |
| 14:19:39 | watusimoto | the hit detection is a recurring cost |
| 14:20:02 | raptor | ok back |
| 14:21:27 | raptor | it seems to me that if we ever want wall manipulation server-side, then we need to have some way to maintain the large wall structure |
| 14:22:15 | raptor | i'm not sure we'll get around complexity |
| 14:23:13 | raptor | i'm trying to think about how major FPS games do it - I think they just use polygon collision detection, but probably have far fewer of them than we do |
| 14:23:32 | raptor | and maybe they use a better spatial database implementation |
| 14:25:03 | raptor | maybe we need a different physics engine... |
| 14:25:06 | watusimoto | I'm less worred about the database than I am about doing lots of edge detection on multipoint wall segments |
| 14:25:22 | raptor | well yes |
| 14:25:46 | watusimoto | so anyway... that's where I'm stuck at the moment |
| 14:26:26 | watusimoto | well, we could do this... |
| 14:26:37 | watusimoto | add the full wall to the database |
| 14:26:52 | watusimoto | and the segments as well |
| 14:27:14 | watusimoto | then use the segments for collision detection, but the walls for other stuff |
| 14:27:25 | raptor | i'm thinking down those lines, too |
| 14:27:42 | watusimoto | if a wall gets delted or manipulated, find all the sgments, and delete/recreate them |
| 14:28:17 | watusimoto | but that may mean doubling-up the database methods... one for using walls and one for using segments |
| 14:28:48 | raptor | or delegating a method from a parent to child |
| 14:29:06 | watusimoto | I don't follow that |
| 14:29:13 | raptor | err... by adding a flag to the search method |
| 14:29:23 | raptor | so you'd do a search with flag of useOrigWalls |
| 14:29:41 | raptor | or do a search with that false, and internally it'll return either/or |
| 14:37:46 | raptor | crazy idea - what if we decomposed every non-point object to 2d lines to fit into the spatial DB... then it would be super fast! |
| 14:38:08 | raptor | with a whole host of other problems... |
| 14:38:14 | raptor | nevermind |
| 14:41:08 | watusimoto | we actually do your "crazy idea" with walls and polywalls |
| 14:41:24 | watusimoto | we have a "walledgedatabase" |
| 14:41:31 | watusimoto | but we only use it for mounting engr items |
| 14:41:39 | watusimoto | it's useful because it contains no interior segments |
| 14:41:57 | watusimoto | so the turrets only snap to outside edge of overlapping walls |
| 14:42:18 | raptor | ah that's right... |
| 14:42:25 | watusimoto | then, when we get the location right, we snap again to the actual wall so we know which wall we're attached to |
| 14:42:34 | watusimoto | because the segments are all "anonymous" |
| 14:42:52 | watusimoto | ids don't survivie angus's geom methods |
| 14:43:15 | watusimoto | we know where they are, but not who they belong to |
| 14:43:24 | raptor | ah ok |
| 14:43:37 | watusimoto | but they might work fine for collision detection |
| 14:43:41 | watusimoto | I hadn't considered that |
| 14:43:57 | watusimoto | we need them for rendering on the client; not sure if we generate them on the server |
| 14:44:02 | raptor | it may pos a problems with being stuck on walls... |
| 14:44:18 | watusimoto | interesting, yes |
| 14:44:20 | raptor | i don't remember them on the server |
| 14:44:24 | watusimoto | not sure how that works now, to be honest |
| 14:44:40 | watusimoto | I'd think a collision detection would prevent you from leaving as well as entering a wall |
| 14:44:59 | watusimoto | but it obviusly doesn't |
| 14:45:15 | watusimoto | but edges would be even more efficient than segments |
| 14:45:29 | watusimoto | smaller, simpler |
| 14:45:46 | watusimoto | fewer of them potentially (interior lines are removed) |
| 14:46:06 | raptor | i think the physics 'engine' we have detects into/out-of collisions |
| 14:46:18 | watusimoto | ha ha, yes "engine" |
| 14:48:38 | watusimoto | well, I'll think about this edge detection idea... it might be just the ticket |
| 14:48:56 | raptor | which one? |
| 14:49:07 | raptor | (my last one was sort of a joke...) |
| 14:49:11 | watusimoto | the idea of using our wall edge database to do collisions |
| 14:49:17 | raptor | ha |
| 14:49:26 | watusimoto | really... it might just work well |
| 14:49:42 | raptor | there's one thing we haven't considered... |
| 14:49:48 | watusimoto | it might be more efficient that what we're doing |
| 14:50:27 | raptor | ripping out the griddb and the physics enging and replacing iwth something like this: https://code.google.com/p/box2d/ |
| 14:51:52 | watusimoto | interesting |
| 14:52:50 | raptor | if we had a real-live physics engine like that we wouldn't really need to maintain the database |
| 14:53:07 | raptor | jsut make sure our objects fit the correct format |
| 14:53:17 | watusimoto | you are probably right |
| 14:53:30 | watusimoto | but we use the database for lots of stuff, not just physics |
| 14:53:48 | raptor | i remember one guy ("beard" was it?) suggested chipmunk physics |
| 14:53:48 | watusimoto | like keeping lists of all textitems, for example |
| 14:53:59 | raptor | ah yes |
| 14:54:02 | raptor | that's right |
| 14:54:04 | watusimoto | but I'm not in principle opposed to using an external lib |
| 14:54:18 | raptor | that one is portable c++, too! |
| 14:54:21 | watusimoto | most of the non-physics functions could be easily reproduced in a wrapper or something |
| 14:54:25 | raptor | anyways, i'm just brain storming... |
| 14:54:47 | watusimoto | yes -- htat's more a long term solution; I need a short-term fix |
| 14:55:00 | raptor | do nothing! |
| 14:55:22 | watusimoto | well, the reason I'm doing this is to avoid fixing some other weirdness intorduced by my level refactor |
| 14:55:33 | raptor | actually, I'm not sure I know if this stems from a problem or not... |
| 14:55:38 | raptor | ah ok |
| 14:55:47 | watusimoto | after simplifying polywaalls, I got the hunger to likewise simplify walls |
| 14:55:52 | raptor | oh no! |
| 14:55:56 | raptor | self-control! |
| 14:56:05 | raptor | one one refactor starts... |
| 14:56:07 | watusimoto | well, it's simplify here, or fix there |
| 14:56:08 | raptor | *once |
| 14:56:21 | watusimoto | this is all still related to the level refactor |
| 14:56:31 | watusimoto | the hugest refactor ever in the project's history |
| 14:56:49 | raptor | yeah... this is pretty crazy |
| 14:56:57 | watusimoto | we're mostly there |
| 14:57:20 | watusimoto | what's in the repo works for most things |
| 14:57:31 | watusimoto | it's mainly scripting that is broken, I think |
| 14:57:50 | raptor | uh oh |
| 14:57:58 | raptor | I don't ever want to touch LuaW again |
| 14:58:01 | watusimoto | no, but not deeply |
| 14:58:13 | watusimoto | it's jsut stuff like making sure walls are added to the database/game properly |
| 14:58:28 | raptor | ah, so script previews from the editor? |
| 14:58:35 | watusimoto | polywall scripting is fixed |
| 14:58:42 | watusimoto | haven't tested that yet |
| 14:58:50 | watusimoto | mostly using the ctrl-g script, for example |
| 14:58:59 | watusimoto | that's what I've been testing |
| 14:59:02 | raptor | ah ok |
| 14:59:25 | watusimoto | yeah, nothing difficult |
| 16:05:32 | raptor | interesting, box2d implements a quad-tree hybrid spatial database that doesn't require buckets of a certain size |
| 16:06:29 | raptor | actually, it's a balanced tree |
| 16:10:08 | | Watusimoto__ Quit (Ping timeout: 258 seconds) |
| 16:24:12 | fordcars | Box2d is cool |
| 16:26:31 | raptor | "Box2D is tuned for meters-kilograms-seconds" |
| 16:27:05 | raptor | and i found their dtabase code: https://code.google.com/p/box2d/source/browse/trunk/Box2D/Box2D/Collision/b2DynamicTree.cpp |
| 16:33:41 | watusimoto | we'd need to decide how big our ship is |
| 16:33:52 | watusimoto | I know, but I'm not telling :-) |
| 16:34:48 | raptor | radisu == 24 meters? |
| 16:34:52 | raptor | *radius |
| 16:40:15 | | LordDVG Quit (Remote host closed the connection) |
| 16:58:03 | watusimoto | no |
| 16:58:14 | watusimoto | didn't you watch "Bitfighter the Movie"? |
| 16:58:18 | watusimoto | there's a clue there |
| 17:15:43 | raptor | phoew |
| 17:15:46 | raptor | interview over |
| 17:16:03 | raptor | this guy was pretty good |
| 17:16:21 | raptor | adaptable |
| 17:16:37 | raptor | has the skill set to do the work |
| 17:39:00 | fordcars | watusimoto: Are ships 15 pixels of radius? |
| 17:39:10 | raptor | 24! |
| 17:39:18 | fordcars | Oh crap never mind |
| 17:39:22 | fordcars | 24 meters? |
| 17:39:42 | fordcars | Wait, you want to implement Box2d in Bitfighter?? |
| 17:40:02 | sam686 | pixels? it depends on your window size and if your ship have sensor, if you try to screen shot |
| 17:40:25 | fordcars | Yeah that's true |
| 17:42:41 | fordcars | Bitfighter is miniaturized, right? |
| 17:42:45 | fordcars | In the Movie |
| 17:43:07 | fordcars | radius = 0.0000000000000000000024 meters |
| 17:44:36 | raptor | thank goodness we aren't working on that type of floating precision level |
| 17:54:56 | watusimoto | 24 "units" |
| 17:55:26 | watusimoto | I always imagined bitfighter took place inside a cpu |
| 17:55:43 | watusimoto | in a weird sort of not quite physical, not quite electronic space |
| 17:55:59 | watusimoto | inner space |
| 18:11:33 | raptor | testitems are floating charge-disrupting heat anomalies |
| 18:14:42 | fordcars | s_bot is a big evil virus |
| 18:15:08 | | Raven67854 Quit (Quit: Leaving) |
| 18:17:54 | | Watusimoto_ has joined |
| 18:25:43 | | Watusimoto_ Quit (Ping timeout: 244 seconds) |
| 18:32:40 | | sam686 Quit (Ping timeout: 256 seconds) |
| 18:45:31 | raptor | GCI this year? |
| 18:45:37 | raptor | and with that... later! |
| 18:45:39 | | raptor Quit () |
| 18:49:29 | | sam686 has joined |
| 18:49:29 | | ChanServ sets mode +v |
| 20:07:00 | | amgine123 has joined |
| 20:07:08 | amgine123 | hi there |
| 20:34:32 | amgine123 | afk |
| 20:36:35 | amgine123 | LOL |
| 20:36:46 | amgine123 | its lagged at 8000+ spybugs |
| 20:36:50 | amgine123 | @ford |
| 20:36:56 | amgine123 | wait for it to catch up |
| 20:37:36 | fordcars | Lol |
| 20:37:48 | amgine123 | wonder how long it will take me |
| 20:37:50 | amgine123 | XD |
| 20:37:51 | fordcars | That's a bit intense haha |
| 20:38:09 | amgine123 | wonder if i will be at flaot zone w3hen its done lagging |
| 20:38:37 | amgine123 | who about you find a good nubmer ? |
| 20:38:53 | amgine123 | im trying to find the highest nubmer that will get you to hte flaot zone hte fasest wihout it lagging |
| 20:39:12 | amgine123 | bitfighter 19c not responding XD |
| 20:39:50 | amgine123 | Guess ill just use emulators in the mean time |
| 20:40:08 | amgine123 | maybe ill finish super mario star road today |
| 20:41:45 | fordcars | Sure :P |
| 20:47:18 | | amgine123 Quit (Quit: Page closed) |
| 20:47:35 | | amgine123 has joined |
| 20:47:37 | amgine123 | its still frozen! |
| 20:51:03 | fordcars | Float lands in editor is really weird |
| 20:51:32 | amgine123 | it is ? |
| 20:51:44 | amgine123 | jsut wonder how would you get to a the falot zone in the editor |
| 20:53:21 | fordcars | I modified the level file :P |
| 21:05:32 | amgine123 | still frozen |
| 21:05:48 | amgine123 | maybe ill reopen BF |
| 21:16:19 | | watusimoto Quit (Quit: Leaving.) |
| 21:40:35 | | Invisible1 has joined |
| 22:09:36 | | Invisible1 Quit (Quit: Invisible1) |
| 23:24:12 | amgine123 | spam spam spammy spam spam. |
| 23:31:18 | amgine123 | spammy spammy spam spammy spammy. |
| 23:40:52 | | Nothing_Much Quit (Remote host closed the connection) |