Timestamps are in GMT/BST.
| 00:17:56 | | bobdaduck Quit (Remote host closed the connection) |
| 00:41:49 | | koda Quit (Quit: koda) |
| 01:17:49 | | koda has joined |
| 03:19:52 | | Flynnn has joined |
| 03:44:00 | | Watusimoto has joined |
| 04:09:46 | | Watusimoto_ has joined |
| 04:12:36 | | Watusimoto Quit (Ping timeout: 276 seconds) |
| 04:18:02 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 05:08:16 | | koda Quit (Read error: Connection reset by peer) |
| 05:19:06 | | Watusimoto_ Quit (Ping timeout: 256 seconds) |
| 07:15:37 | | koda has joined |
| 08:10:29 | | raptor has joined |
| 08:10:29 | | ChanServ sets mode +o raptor |
| 08:27:18 | | bobdaduck has joined |
| 09:07:57 | | watusimoto has joined |
| 09:07:57 | | ChanServ sets mode +o watusimoto |
| 09:08:08 | watusimoto | hello |
| 09:12:56 | bobdaduck | hello |
| 09:40:29 | raptor | hello |
| 10:12:15 | | raptor Quit () |
| 10:20:16 | | koda Quit (Ping timeout: 256 seconds) |
| 10:56:52 | | raptor has joined |
| 10:56:52 | | ChanServ sets mode +o raptor |
| 10:57:29 | | watusimoto Quit (Quit: Leaving.) |
| 12:20:34 | | Flynnn has joined |
| 12:21:52 | | Flynnn Quit (Client Quit) |
| 12:23:28 | bobdaduck | :( there's no room in the shop for slipzones |
| 12:50:04 | raptor | heh - random catfight posts |
| 12:53:39 | bobdaduck | I dunno. Until I think of something to do with them xD |
| 12:53:51 | bobdaduck | just gonna dump them there |
| 13:08:39 | | bobdaduck Quit (Remote host closed the connection) |
| 14:13:44 | | Watusimoto has joined |
| 14:24:17 | | bobdaduck has joined |
| 14:37:37 | bobdaduck | okay so |
| 14:37:43 | bobdaduck | playerInfo:setName() |
| 14:40:23 | bobdaduck | also I know how to fix circles. |
| 14:45:16 | bobdaduck | Watusimoto, raptor, hows this: |
| 14:45:39 | bobdaduck | We take circles, and we make them *only* circle spawners |
| 14:45:57 | bobdaduck | and then make it so the spawn timer doesn't go off until the current circle dies |
| 14:46:07 | bobdaduck | and then we give circles team affiliations. |
| 14:46:21 | bobdaduck | And then we do the same thing with mines. |
| 14:46:40 | Watusimoto | I kind of get the circle idea... but not the mine one |
| 14:47:16 | bobdaduck | Turn the level editor mines into a mine spawner. |
| 14:47:33 | bobdaduck | And if the mine is dead then after ten seconds or whatever spawn another one. |
| 14:47:42 | Watusimoto | should mine spawners be points or zones? |
| 14:47:47 | bobdaduck | points |
| 14:47:59 | Watusimoto | if they were zones, the mines would be less predictable |
| 14:48:21 | Watusimoto | but basically the idea is to make mines work like negative health packs |
| 14:48:29 | bobdaduck | Zones are confusing, we would have to figure out a new graphic, and there might be weird things like mines spawning at the very edge of a zone ending up in a wall or something |
| 14:48:39 | bobdaduck | uh... Yeah! |
| 14:48:39 | bobdaduck | xD |
| 14:48:50 | bobdaduck | And then we turn the mine spawner and circle spawners |
| 14:48:59 | bobdaduck | into engineerable/repairables. |
| 14:49:29 | Watusimoto | well, the zone would be invisible |
| 14:49:42 | bobdaduck | And that would be confusing |
| 14:49:52 | Watusimoto | that's the idea :-) |
| 14:50:05 | Watusimoto | I think the idea of regenerating mines is fundamentally good |
| 14:50:21 | Watusimoto | but I think they should be unpredictable somehow |
| 14:50:41 | bobdaduck | I don't like unpredictabilty |
| 14:50:53 | bobdaduck | if I wanted that I would just cover levels in asteroid spawners with random times |
| 14:51:31 | bobdaduck | I assume that a dislike of unpredictablility is exactly why we're giving asteroid spawners a graphic in 019 |
| 14:52:51 | bobdaduck | With the original circle concept of an enemy that tries to touch you and kill you: I think this would make a great engineered item. |
| 14:53:05 | bobdaduck | like build an enemy spawner for your team |
| 14:58:57 | Watusimoto | so circles are attracted to enemies and damage them when they hit? |
| 15:00:00 | bobdaduck | yeah |
| 15:00:17 | Watusimoto | it's an interesting idea |
| 15:00:23 | Watusimoto | it could work |
| 15:00:35 | bobdaduck | Also I've been gunning for a new repairable/engineerable item for a while now (suns) |
| 15:00:38 | Watusimoto | almost like an attracted mine of some sort |
| 15:00:56 | Watusimoto | well, maybe not like that |
| 15:01:27 | bobdaduck | I was thinking more like |
| 15:01:30 | bobdaduck | a base sentinel |
| 15:01:35 | Watusimoto | yes |
| 15:01:58 | Watusimoto | well, it certainly wouldn't be worse than what we have :-) |
| 15:02:21 | Watusimoto | what would happen when it hit a ship? do some damage and then... |
| 15:02:25 | Watusimoto | do some more damage? |
| 15:02:50 | bobdaduck | I dunno |
| 15:02:55 | bobdaduck | I think your original idea was instakill |
| 15:03:01 | Watusimoto | retreat a bit then attack again? |
| 15:03:05 | Watusimoto | instakill? |
| 15:03:08 | Watusimoto | explode? |
| 15:03:09 | bobdaduck | And since they can be destroyed in one shot instakill isn't that bad an idea |
| 15:03:12 | bobdaduck | like asteroids. |
| 15:03:48 | Watusimoto | that might work |
| 15:04:07 | Watusimoto | kaen: are you around? |
| 15:25:48 | raptor | howdy folks |
| 15:26:07 | bobdaduck | howdy |
| 16:05:26 | | bobdaduck Quit (Remote host closed the connection) |
| 16:34:53 | kaen | just got back Watusimoto |
| 16:52:07 | raptor | Watusimoto: what are your specific suggestions for ROBOT menu improvements again? |
| 17:13:40 | | raptor Quit () |
| 17:37:40 | | Little_Apple has joined |
| 17:50:22 | | Little_Apple Quit (Quit: Page closed) |
| 19:04:49 | | Watusimoto Quit (Ping timeout: 252 seconds) |
| 19:26:40 | | sam686 has joined |
| 19:26:40 | | ChanServ sets mode +v sam686 |
| 20:01:35 | | Little_Apple has joined |
| 20:21:00 | | SolumnMushroom has joined |
| 20:22:43 | SolumnMushroom | I'm installing Fedora 8 |
| 20:22:53 | SolumnMushroom | PPC |
| 20:24:05 | Nothing_Much | Fedora 8? |
| 20:24:11 | Nothing_Much | That's pretty ancient, is it not? |
| 20:24:22 | Nothing_Much | Unless you mean 18? |
| 20:28:29 | SolumnMushroom | No, I mean 8. I'm working with an iBook G4 here |
| 20:33:11 | Nothing_Much | Ohh, why Fedora though? |
| 20:34:15 | Nothing_Much | Debian has much better support for PPC as well as many other architectures |
| 20:38:12 | | Little_Apple Quit (Quit: Page closed) |
| 20:41:51 | SolumnMushroom | That was my original idea for my iBook |
| 20:47:46 | Nothing_Much | What happened, SolumnMushroom? |
| 20:48:14 | SolumnMushroom | The installer I tried froze midinstallation |
| 20:48:27 | SolumnMushroom | It was Fedora 14, I think |
| 20:49:07 | Nothing_Much | Oh, I thought you meant Debian. Why not use that one when it has more updated packages and supports PPC fully? |
| 21:06:47 | | fordcars has joined |
| 21:08:06 | SolumnMushroom | I'm concerned that the newer installs will freeze my computer again |
| 21:09:51 | Nothing_Much | Debian is relatively lightweight |
| 21:10:01 | Nothing_Much | I think they switched to XFCE as the default desktop |
| 21:28:20 | Nothing_Much | nope, still gnome, but you can configure it to use a lightweight DE |
| 21:33:23 | | raptor has joined |
| 21:33:23 | | ChanServ sets mode +o raptor |
| 21:35:15 | kaen | raptor, can we add some sort of auto crash reporter thing? |
| 21:35:35 | raptor | now that's an interesting idea... |
| 21:35:38 | kaen | like, add a signal handler to dump the stack trace when we crash |
| 21:35:45 | kaen | then upload it when we find dumps at startup |
| 21:35:52 | raptor | osx and windows 7 provide automatic stack traces |
| 21:36:20 | raptor | however - I've only ever seen one game do what you want on Linux, and that was naev |
| 21:36:20 | kaen | I mean some mechanism to automatically send reports about it |
| 21:36:31 | kaen | interesting |
| 21:36:53 | raptor | oh, naev just spit out a relevant trace somewhere, then restarted itself where it left off.. |
| 21:36:55 | kaen | I was reading this and got all inspired: http://www.joelonsoftware.com/articles/fog0000000014.html |
| 21:37:04 | kaen | oh |
| 21:37:17 | raptor | you mean to actually post reports somewhere |
| 21:37:22 | kaen | yeah |
| 21:38:05 | fordcars | I just thought of a way to find all objects in levelgen mhahahahahhaha |
| 21:38:10 | kaen | would help find crashes and stuff that people are too lazy/unknowledgeable to report |
| 21:38:15 | kaen | fordcars, do tell! |
| 21:38:41 | Nothing_Much | How do you find bugs in bf? |
| 21:38:50 | Nothing_Much | Like, I'm unsure where the dumps are |
| 21:38:53 | fordcars | well I just thought of that but, find object by id, when object is found, get info bla bla bla, change it's id to 2, repeat |
| 21:38:55 | raptor | so two problems: catch the crash (appropriately on each platform), and send the crash.. |
| 21:39:31 | raptor | (still reading that post) |
| 21:39:35 | kaen | send the crash is easy. we could set up a stupid little php script or something and use that handy httprequest :) |
| 21:40:04 | raptor | but you have to send the crash *after* the crash.. |
| 21:40:12 | kaen | no you don't |
| 21:40:16 | kaen | just dump it to a file in the handler |
| 21:40:22 | kaen | then send it on normal startup |
| 21:40:32 | raptor | oh so wait until they restart the game? |
| 21:40:34 | SolumnMushroom | I just took a shower |
| 21:40:37 | kaen | yeah |
| 21:40:42 | raptor | sounds good |
| 21:40:50 | raptor | back to reading.. |
| 21:41:10 | Nothing_Much | Where are the crash files located? |
| 21:41:15 | kaen | I think his main point in using that system is to measure how economic it is to fix bugs |
| 21:41:18 | raptor | Nothing_Much: non-existent |
| 21:41:22 | kaen | Nothing_Much, there are none :/ |
| 21:41:28 | raptor | we are discussing options to code it now |
| 21:41:29 | Nothing_Much | Oh dear |
| 21:41:35 | Nothing_Much | Well that's good! |
| 21:41:38 | raptor | kaen: yes, but we're hobbyists! |
| 21:41:54 | kaen | yes, but time is an economized resource :) |
| 21:42:00 | raptor | oh yeah, huh.. |
| 21:42:27 | kaen | plus like I mentioned it'll help us find bugs from users that don't idle in IRC |
| 21:42:35 | raptor | heh |
| 21:42:53 | SolumnMushroom | Hey BFLogBot, how are you? |
| 21:43:00 | raptor | after each release I create a 'Bugs in 018a' like forum thread |
| 21:43:06 | kaen | that's true |
| 21:43:10 | raptor | but we should think bigger! |
| 21:43:13 | raptor | ok |
| 21:43:29 | raptor | so basically the article was ok, but we need to figure out how he did step #1 |
| 21:43:38 | raptor | i.e. 'catch the bugs' |
| 21:43:51 | raptor | and do it cross-platform |
| 21:43:54 | raptor | also |
| 21:44:08 | raptor | we'd probably have to do release builds with debuginfo built it |
| 21:44:10 | raptor | *in |
| 21:44:53 | kaen | on linux at least we can use addr2line |
| 21:45:01 | kaen | I imagine there's something similar for the other platforms |
| 21:45:18 | kaen | (addr2line translates memory offsets to lines of code) |
| 21:45:27 | kaen | (without symbols) |
| 21:45:44 | raptor | i've heard of that... is it accurate with compiler optimizations? |
| 21:45:55 | kaen | no |
| 21:45:58 | kaen | :| |
| 21:46:00 | raptor | heh |
| 21:46:03 | kaen | forgot about that |
| 21:46:12 | kaen | uhh |
| 21:47:14 | raptor | hmm... would it be more accurate with debuginfo compiled in? |
| 21:47:42 | kaen | yes, it's perfectly accurate with debug info |
| 21:48:16 | raptor | i wonder how optimizations plus debuginfo affect performance |
| 21:48:55 | kaen | ah that's right |
| 21:49:16 | kaen | theres' a way to have just a local copy of the debug info and use that against release build offsets with addr2line |
| 21:49:31 | kaen | but that seems like a bunch of hassle |
| 21:49:45 | raptor | yeah, we'd want it seamless.. |
| 21:49:48 | kaen | especially to do it with all three platforms :/ |
| 21:50:47 | kaen | https://code.google.com/p/google-breakpad/wiki/ClientDesign |
| 21:51:06 | kaen | google's cross-platform crash handler |
| 21:51:09 | raptor | ooooo |
| 21:51:28 | raptor | "A Linux implementation has been written and is currently under review." |
| 21:51:48 | kaen | :| |
| 21:52:36 | kaen | according to the quickstart guide it uses the symbol-file-against-release-builds method as well |
| 21:53:24 | kaen | wow this suddenly sounds like a lot of trouble |
| 21:56:53 | raptor | you've probably seen this: http://stackoverflow.com/questions/77005/how-to-generate-a-stacktrace-when-my-gcc-c-app-crashes |
| 21:57:28 | raptor | we could install handlers for specific signals |
| 21:57:51 | raptor | create a CrashReporter class or something and specify a method to be the handler |
| 21:59:42 | raptor | there are several informative responses in there |
| 22:02:06 | kaen | and here's the window's solution it seems: http://msdn.microsoft.com/en-us/library/bb204633(VS.85).aspx |
| 22:02:24 | raptor | is signal.h standard on windows, too? |
| 22:02:53 | kaen | seems that way: http://msdn.microsoft.com/en-us/library/xdkz3x12(v=vs.80).aspx |
| 22:03:22 | raptor | oooo good... |
| 22:04:30 | kaen | backtrace() depends on debug symbols... |
| 22:04:46 | kaen | and is apparently is a gcc-only thing, so what about osx (and clang?) |
| 22:05:02 | raptor | yeah... i think we'd want to use signal, then use a handler with lots o' ifdefs |
| 22:05:37 | kaen | oh, clang supports execinfo (and backtrace()) |
| 22:05:40 | raptor | well.. osx already catches application traces |
| 22:05:44 | raptor | it does? |
| 22:05:46 | raptor | well good |
| 22:05:52 | kaen | groovy |
| 22:05:57 | kaen | so one ifdef :) |
| 22:06:08 | kaen | and a signal handler. that doesn't sound so bad |
| 22:06:40 | raptor | i wonder... could the signal handler spawn a thread right there and send the report? |
| 22:06:47 | kaen | I'm certain it could |
| 22:07:23 | fordcars | can levelgen change the ID of an object? |
| 22:08:26 | raptor | fordcars: i'm afraid not, those don't change |
| 22:08:33 | fordcars | arhghghgh ok |
| 22:08:39 | fordcars | I'll figure something out |
| 22:09:40 | raptor | i know this is crazy... but depending on how large your level is, you could call one big for loop at the start that loops through like -1000 to 1000 |
| 22:09:52 | raptor | and sees if there's an object with that id |
| 22:10:05 | kaen | ah, that's a good idea! |
| 22:10:07 | raptor | if so, grabs its type and stores it for later reference |
| 22:10:29 | raptor | there's always a maniacal way to do things... |
| 22:11:00 | fordcars | how would you get the object, detect it? |
| 22:11:20 | kaen | levelgen:getObjectById() I believe |
| 22:11:31 | fordcars | it only gets one item |
| 22:11:39 | kaen | yeah... that's the maniacal part |
| 22:11:53 | fordcars | wouldn't it just always get the same object? |
| 22:12:03 | kaen | you call it on each number from -1000 to 1000 |
| 22:12:06 | kaen | and see what sticks |
| 22:12:14 | kaen | and you eventually build a list of all objects |
| 22:12:26 | fordcars | with diffent ids |
| 22:12:49 | kaen | maybe I missed something... |
| 22:13:03 | kaen | you're looking for a set of objects which share the same ID? |
| 22:13:08 | kaen | you shouldn't do that. |
| 22:13:17 | fordcars | or if they don't have an id |
| 22:13:31 | kaen | if they don't have an assigned one they get a negative one by default |
| 22:13:42 | fordcars | is it unique? |
| 22:13:44 | kaen | which is unique afaik |
| 22:13:51 | fordcars | oOOoooohh nice |
| 22:13:53 | kaen | it's auto-decremented I'm sure |
| 22:14:11 | raptor | ids are unique |
| 22:14:26 | raptor | guaranteed, no matter how much bobdaduck complains |
| 22:14:36 | fordcars | haha |
| 22:14:53 | raptor | yes, non-assigned ones start from 0 and decrement into the negatives |
| 22:16:23 | | SolumnMushroom Quit (Read error: Connection reset by peer) |
| 22:22:36 | raptor | fordcars: a working example of your object finder: http://pastie.org/pastes/7987199/text |
| 22:24:16 | fordcars | hehe I nearly have the same code "-" |
| 22:24:21 | fordcars | thanks :P |
| 22:27:24 | raptor | back in a bit.. |
| 22:33:06 | fordcars | later guys gtg |
| 22:37:22 | | fordcars Quit (Ping timeout: 250 seconds) |
| 23:29:31 | raptor | kaen: still up? |
| 23:33:47 | raptor | I'm curious if you've worked on the signal stuff at all yet.. |