Timestamps are in GMT/BST.
| 00:31:08 | | BFLogBot Commit: a81730a483 | Author: buckyballreaction | Message: Housekeeping. Move library includes into the lib directory to clean-up our root directory a little. A CMake re-run from scratch will be required |
| 00:36:19 | raptor | night! |
| 00:36:22 | | raptor Quit () |
| 03:10:30 | | Nothing_Much Quit (Remote host closed the connection) |
| 03:22:57 | | Flynnn has joined |
| 05:54:50 | | LordDVG has joined |
| 06:27:02 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 06:45:45 | | Flynnn has joined |
| 06:46:13 | | Flynnn Quit (Client Quit) |
| 07:36:32 | | LordDVG Quit (Ping timeout: 264 seconds) |
| 07:47:51 | | empyrean has joined |
| 07:49:35 | | LordDVG has joined |
| 09:34:52 | | koda has joined |
| 10:41:24 | | empyrean Quit (Remote host closed the connection) |
| 11:53:21 | | Nothing_Much has joined |
| 11:55:44 | | raptor has joined |
| 11:55:44 | | ChanServ sets mode +o |
| 12:51:02 | | Flynnn has joined |
| 13:00:34 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 13:47:25 | | watusimoto has joined |
| 13:47:25 | | ChanServ sets mode +o |
| 14:08:14 | watusimoto | hello |
| 14:08:19 | raptor | hi |
| 14:08:22 | watusimoto | I forged on with physfs a bit last night |
| 14:08:26 | watusimoto | and quickly got mired |
| 14:08:40 | watusimoto | Everyone has their own stream.... |
| 14:08:51 | watusimoto | so physfs can create a stream |
| 14:08:56 | watusimoto | and alure and consume a stream |
| 14:09:11 | watusimoto | but a physfs stream is not the same as an alure stream |
| 14:09:38 | watusimoto | so I conclude I need to learn more about streams |
| 14:09:49 | raptor | ah, ok |
| 14:10:01 | raptor | i did a lot with stream in java |
| 14:10:35 | raptor | basically, they boil down to 2 things: a long line of data; how to interpret the data |
| 14:10:41 | watusimoto | yes |
| 14:10:56 | raptor | 'everything is a byte stream' is what i'd tell myself |
| 14:11:07 | raptor | now what to do about those pesky bytes |
| 14:11:22 | raptor | long story short... i don't like streams |
| 14:11:32 | watusimoto | unfortunately the alstream (which I think is what we want) is abstract... the implementations seem to be format specific, like a wav_stream and such |
| 14:11:55 | watusimoto | and we don't want to get into the details of file formats |
| 14:11:58 | raptor | why are you caring about an audio stream for physfs? |
| 14:12:25 | watusimoto | if we want to load a sound file from a physfs file, stream seems to be the best way |
| 14:12:50 | watusimoto | unless, I suppose, there is a way to get an absolute filepath to the phsyfs file, which for some reason didn't occur to me until just now |
| 14:12:55 | watusimoto | despite it being so obvious |
| 14:14:23 | watusimoto | like if only there were this function: PHYSFS_getRealDir |
| 14:14:42 | watusimoto | because then my stream problem would simply go away |
| 14:15:03 | raptor | i thought physfs would always return a file (stream or pointer, whatever) then just pump that into the normal alure operations already used |
| 14:15:21 | raptor | heh, yes |
| 14:15:30 | watusimoto | I think it will... I was tired |
| 14:15:48 | watusimoto | I was thinking about streams because I want to migrate our level loading to streams to improve performance |
| 14:16:08 | raptor | i did some distro re-org last night, so if you merge, make sure to re-run cmake and compile from scratch |
| 14:16:15 | watusimoto | ok |
| 14:16:31 | watusimoto | I'm currently thinking we'll use physfs for everything except loading levels |
| 14:16:44 | raptor | streams wiill only work if the parsing is linear |
| 14:16:59 | raptor | or you'll have to put in complexity to manage the non-linearness |
| 14:17:02 | watusimoto | you mean the file p;arsing? |
| 14:17:14 | watusimoto | I'll juse use readline, which grabs the next line from a stream |
| 14:17:24 | watusimoto | since our levels are all based on lines, that should work nicely |
| 14:17:52 | raptor | not libreadline, i hope; you mean the function readline()? |
| 14:17:58 | watusimoto | yes |
| 14:18:01 | raptor | ok phoew |
| 14:18:02 | watusimoto | not libreadline |
| 14:18:09 | watusimoto | you think I'm nutz?? |
| 14:18:09 | raptor | i had envisioned a nightmare |
| 14:18:54 | watusimoto | I think I'm also going to introduce a level hash that gets stored in the first line of the file |
| 14:19:02 | watusimoto | it will be updated by the editor |
| 14:19:03 | raptor | Levelformat 3? |
| 14:19:09 | watusimoto | maybe 2.1 |
| 14:19:15 | raptor | hmm |
| 14:19:26 | watusimoto | if it's there, we need only read that and then we can use cached metadata |
| 14:19:30 | raptor | i know we discussed a hashing algo once... |
| 14:19:34 | raptor | maybe that was with kaen |
| 14:19:34 | watusimoto | if it's not, we'll parse the level as normal |
| 14:19:44 | watusimoto | I was thinking of md5 |
| 14:19:49 | raptor | you'll have to ignore the newlines |
| 14:19:59 | watusimoto | why? |
| 14:19:59 | raptor | oh, on the straight file itself? |
| 14:20:02 | watusimoto | yes |
| 14:20:25 | raptor | because... uh... levels can be identical with reordered lines and different line endings |
| 14:20:33 | watusimoto | perhaps during save we would create a string version, and hash that |
| 14:20:56 | watusimoto | what you said was true, but the idea isn't to compare two levels to see if they are the same, it's to see if the level is known |
| 14:20:59 | raptor | so i guess we should determine what the hash actually means - unique level? or unique file? |
| 14:21:17 | watusimoto | if someone rearranges the lines in the level file, we'd treat that as an unknown level |
| 14:21:22 | watusimoto | so here is how it would work |
| 14:21:29 | watusimoto | 1) read first line of level file |
| 14:21:37 | raptor | or maybe - we go to a binary format that does ordering and forbids external editing! |
| 14:21:44 | watusimoto | if it is a hash, look to see if we know the metadata |
| 14:21:44 | raptor | then we'd have absolute assurances |
| 14:22:02 | watusimoto | if so, we use that until we need to actually load the level |
| 14:22:25 | raptor | ah... maybe a hash of just the metadata? |
| 14:22:27 | watusimoto | if unknown, we read the level and generate whatever we need for metadata |
| 14:22:49 | watusimoto | (no because I want to compute the area of the level so we can know if this is a big or small level) |
| 14:23:14 | watusimoto | when it comes time to actually load the level, we'll recompute the hash as we load |
| 14:23:23 | raptor | hmmm... the rest of level loading better be *really* fast |
| 14:23:38 | watusimoto | if it differs from what the level said it was (i.e. because someone manually edited the level), then we'll update our metadata |
| 14:24:06 | watusimoto | when level is edited, a hash line will be inserted |
| 14:24:14 | watusimoto | that's what I'm thinking |
| 14:24:49 | watusimoto | so for most levels, we can read only the first line and be done |
| 14:25:01 | watusimoto | at least until we load it |
| 14:25:47 | watusimoto | maybe we can include a cmd line option to read all levels in a folder, insert hashes, and store the metadata, so loading at gametime can be fast |
| 14:26:11 | raptor | first line is LevelFormat, if it exists |
| 14:26:17 | raptor | no wait |
| 14:26:36 | raptor | yeah, that's right, then GameType |
| 14:26:43 | watusimoto | I'm thinking first line will be hash, 2nd line levelformat, 3rd line gametype |
| 14:27:29 | watusimoto | because you don't really care about the format until you start parsing the level itself |
| 14:27:30 | raptor | level parsing code is expecting first line to be LevelFormat because that triggers different parsing types |
| 14:27:42 | raptor | including, perhaps, reading in a hash |
| 14:27:55 | raptor | or discarding a hash |
| 14:27:59 | watusimoto | that's a fair question... is the hash something that would change with different formats? |
| 14:28:11 | raptor | well, it's also not found on older levels |
| 14:28:17 | raptor | so we can't expect it always |
| 14:28:18 | watusimoto | I'm thinking that all levels could have a hash, even old ones |
| 14:28:28 | watusimoto | but it could be absent as well,e ven in new levels |
| 14:28:35 | watusimoto | absent, or even wrong |
| 14:28:51 | watusimoto | it's intended to be a speedup, not something foolproof |
| 14:29:04 | watusimoto | and I do not yet know how to handle generated levels |
| 14:29:09 | raptor | I think it's wise to have LevelFormat first to trigger various logic(s) |
| 14:29:18 | raptor | that's what it's there for |
| 14:29:23 | watusimoto | yes |
| 14:29:25 | watusimoto | true |
| 14:30:11 | watusimoto | maybe there should be a level data line that specifies level size |
| 14:30:29 | watusimoto | it can be generated automatically for traditional levels at edit time, or manually overridden for levelgened levels |
| 14:30:30 | raptor | and by size, you mean computed area? |
| 14:30:36 | watusimoto | yes |
| 14:30:46 | raptor | that would work |
| 14:31:00 | watusimoto | I want to be able to let people choose levels sorted by approximate size |
| 14:31:10 | watusimoto | so they can pick from a menu of small/med/big levels |
| 14:31:21 | raptor | old levels would have to be generated and cached |
| 14:31:24 | watusimoto | making it easier to find a level for a small (or big) group |
| 14:31:47 | watusimoto | that's the real factor driving all this |
| 14:31:55 | watusimoto | how to sort by size, but still keep load times fast |
| 14:32:08 | raptor | yes, so we have a .cache folder, maybe? to persist level computations |
| 14:32:10 | watusimoto | because computing size is slow |
| 14:32:21 | raptor | because i don't like the idea of modifying the original level |
| 14:32:25 | watusimoto | I was thinking of using a sqlite db |
| 14:32:43 | watusimoto | indexed by hash |
| 14:32:48 | raptor | that would work - it may be overkill |
| 14:32:57 | watusimoto | there could be several hundred records |
| 14:33:02 | watusimoto | and we have sqlite in there already |
| 14:33:26 | raptor | or a simple txt file with one line per hash pointing to a file name (or something) |
| 14:33:48 | raptor | sqlite is sadly unused for the most part... |
| 14:33:59 | watusimoto | well, we'f probably store hash/size/author/gametype/all other metadata |
| 14:34:19 | watusimoto | so once we get a hash, we can stop reading the levelfile and move to the next one\ |
| 14:34:40 | watusimoto | and this data doesn't need to be user accessible |
| 14:36:03 | watusimoto | one minro issus is that as levels change, the old orphaned hashes will still be in our db |
| 14:36:10 | watusimoto | so over time, size will grow |
| 14:36:41 | watusimoto | though maybe after a certain size, old records can be flushed |
| 14:38:35 | watusimoto | and it just may not matter at the number of potential records we are talking... hundreds, not thousands... |
| 14:39:58 | raptor | there are a few people with thousands - sky_lark and amgine (and maybe a bobdaduck) |
| 14:40:11 | raptor | or at least on the order of 1 - 3 thousand or so |
| 14:40:47 | raptor | I have to take a break for a bit and get back to studies. I'll be back later |
| 14:41:09 | | raptor Quit () |
| 14:46:02 | | LordDVG Quit (Remote host closed the connection) |
| 15:00:01 | | Nothing_Much Quit (Remote host closed the connection) |
| 15:21:30 | | koda Quit (Ping timeout: 250 seconds) |
| 15:44:30 | | empyrean has joined |
| 16:36:54 | | koda has joined |
| 17:09:16 | | Flynnn has joined |
| 17:15:56 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 18:01:49 | | amgine123 has joined |
| 18:03:00 | amgine123 | hi wattsimo are you afk ? |
| 18:06:57 | watusimoto | hi |
| 18:07:28 | watusimoto | Btw, I could not reproduce the team assignemtn editor bug you reported; hopefully it was because I'd already fixed it |
| 18:07:54 | watusimoto | I was able to reproduce some of the other bugs, but, alas, not reliably... I know they're there, but not how to make them happen |
| 18:11:50 | amgine123 | yeah i had that same issue |
| 18:12:17 | amgine123 | yeah when I did alt # the teams changed but the color was the same |
| 18:13:23 | amgine123 | is te ZAP lib somehwere im working on a procjet but im not familer with BF varibles and such |
| 18:13:49 | | amgine123 Quit (Quit: Page closed) |
| 18:15:50 | | amgine123 has joined |
| 18:54:24 | | raptor has joined |
| 18:54:24 | | ChanServ sets mode +o |
| 19:29:26 | | amgine123 Quit (Ping timeout: 246 seconds) |
| 19:29:27 | | Flynnn has joined |
| 19:29:36 | | amgine123 has joined |
| 20:02:05 | | koda Quit (Quit: koda) |
| 20:33:08 | | amgine123 Quit (Ping timeout: 246 seconds) |
| 20:33:55 | | raptor Quit () |
| 20:34:02 | | raptor has joined |
| 20:34:02 | | ChanServ sets mode +o |
| 20:42:01 | | watusimoto Quit (Read error: Connection reset by peer) |
| 20:44:49 | | raptor Quit () |
| 20:56:19 | | Canseco has joined |
| 21:00:08 | | amgine123 has joined |
| 21:01:37 | | Canseco Quit (Remote host closed the connection) |
| 21:20:59 | | empyrean Quit (Remote host closed the connection) |
| 21:22:50 | | amgine123 Quit (Quit: Page closed) |
| 21:23:19 | | Aniball2 has joined |
| 21:42:08 | | Aniball2 is now known as amgine123 |
| 23:29:20 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 23:32:41 | | amgine123 Quit (Ping timeout: 246 seconds) |