#bitfighter IRC Log

IRC Log for 2015-05-15

Timestamps are in GMT/BST.

00:00:25 raptor Quit (Client Quit)
00:36:23 empyrean has joined
00:37:54 empyrean Quit (Remote host closed the connection)
00:52:27 empyrean has joined
00:57:08 empyrean Quit (Remote host closed the connection)
01:07:22 Flynnn has joined
05:12:51 Flynnn Quit (Quit: Leaving)
08:14:57 koda has joined
13:16:04 empyrean has joined
13:18:01 empyrean Quit (Remote host closed the connection)
13:25:31 watusimoto has joined
13:25:32 ChanServ sets mode +o
14:54:24 koda Quit (Ping timeout: 264 seconds)
14:55:07 raptor has joined
14:55:07 ChanServ sets mode +o
15:01:01 raptor hello
15:08:14 molodoy has joined
15:08:24 molodoy Quit (Client Quit)
16:22:14 raptor watusimoto: sorry i've been busy and haven't had much time to spend on physfs yet - however, before I precompile it; are we sure we want to use it?  I think it's a good idea, but I honestly haven't thought of all the implications yet
18:53:55 raptor Quit (Ping timeout: 265 seconds)
19:15:21 raptor has joined
19:15:21 ChanServ sets mode +o
19:20:56 raptor luajit updated - i should update our repo, too
19:21:03 amgine123 has joined
19:21:18 amgine123 hello anything new to test ?
19:22:38 watusimoto hello
19:22:48 raptor hi
19:22:58 watusimoto raptor: I think so -- it solves a problem we will have
19:23:08 watusimoto which is hosting out of zip files
19:23:15 watusimoto which is something I'd like to support
19:23:24 watusimoto though arguably not a critical feature
19:23:40 raptor it also removes complexity with copying resources, etc.
19:23:48 raptor which I wholeheartedly want to remove
19:23:59 raptor however, i was htinking about one thing-
19:24:19 amgine123 wattsimo did you see my privite message
19:25:04 raptor if we have a 'system' dir with sfx/music/levels/etc., and a user dir all meshed together, how would we allow editing of 'system' level files (assuming they would be the default stock levels)
19:25:07 raptor ?
19:25:14 watusimoto amgine123: how do you add the teams?
19:25:43 watusimoto raptor: how do we manage it now?
19:26:06 raptor we copy all system resources into the user dir on first launch, then from thereafter onward the game is run out of the user dir
19:26:07 watusimoto they normally would copy the stock levels to their "working" folder
19:26:13 amgine123 If you add prest teams they are not the correct color [17:22] <amgine123> they will all be red even though some teams should be blue ect [17:22] <amgine123> or yellow
19:26:24 watusimoto right, and the user modifies their "working" copy
19:26:28 raptor yes
19:26:37 watusimoto so... that wouldn't change
19:26:44 raptor but physfs abstracts away the idea of a rootdatadir
19:26:55 watusimoto not exactly
19:26:57 raptor we would, presumably, mush them together
19:27:04 watusimoto we mush them together, yes
19:27:16 watusimoto but we have "working" and "system copy"
19:27:19 watusimoto in that order
19:27:27 watusimoto so the working version is always grabbed if it existss
19:27:46 watusimoto physfs lets you add folders in a search-priority order
19:27:51 raptor ahhh
19:27:54 raptor i wasn't sure about that
19:28:13 watusimoto but the levels aren't a good example
19:28:30 watusimoto because if I delete a bm.level from my levels folder, we won't go grab another copy
19:28:34 raptor so the only cases i'm really worried about are mushed system/user resources because only the user ones would be modifiable
19:28:37 watusimoto we just wouldn't want to host that level
19:28:44 watusimoto but the sfx might be better
19:28:53 watusimoto I have my modified sfx folder, then my system sfx
19:29:02 watusimoto sorry local and system
19:29:16 watusimoto if I have a phaser.wav in my local version, that gets used
19:29:23 watusimoto if I don't, then system copy gets used
19:29:33 raptor yes, that makes sense, and is good
19:29:35 watusimoto so if I want to modify the sfx, I modify my local copy
19:29:38 watusimoto and all is good
19:30:02 watusimoto so for some resources, we'd have two folders (perhaps) a user specifyable override, and the system default
19:30:04 raptor i'm thinking of a case taht is little different
19:30:08 watusimoto for levels, we'd just have one
19:30:13 raptor for levels...  ah
19:30:16 raptor just the user one?
19:30:35 watusimoto because you define which levels you want to host with by creating a folder and putting htme there, them poitning bf at that folder
19:30:43 watusimoto no overrides involved
19:30:52 raptor ok
19:30:53 watusimoto but I want to expand that to other mechanisms
19:30:57 raptor that's a better idea
19:31:02 watusimoto aim it at a zip file instead of a folder
19:31:05 raptor and what i wanted to figure out
19:31:23 watusimoto aim it at a playlist, in which case you might have multiple folders where those levels might live
19:31:34 watusimoto aim it at pleiades
19:31:38 watusimoto etc.
19:31:46 raptor which i think will be awesome
19:31:54 watusimoto indeed it would
19:32:03 raptor i had it in my mind that it was an all-or-nothing system/user mesh
19:32:03 watusimoto pleiades would become a level server
19:32:07 watusimoto no
19:32:17 watusimoto there is one problem, though
19:32:32 watusimoto and that is there is only one "instance" of physfs
19:32:46 watusimoto so you don't have one version for sfx and antoehr for levels
19:32:51 watusimoto you just have one
19:33:03 raptor one FS, right
19:33:13 watusimoto which complicates things a bit if we want to use it in different contexts
19:33:40 raptor like how?  a bitfighter instance doesn't use more than one 'FS' right now...
19:33:49 watusimoto for basic game resources, we can share a single instance -- point it at a user folder, and also a system folder, so it works like the sfx version I specified above
19:33:58 watusimoto except we'd point it at the rootdatadir
19:34:10 watusimoto and keep everything in its own subfolder, as we do now
19:34:20 watusimoto so you can have physfs fine sfx/phaser.wav
19:34:24 watusimoto *find*
19:34:57 watusimoto if it is pointed at the root resources folder, it will figure out that sfx is a subfolder, and phaser.wav is a file in that subfolder
19:35:09 watusimoto but we want to use it in a very different way for levels
19:35:17 watusimoto so we really need two instances
19:35:25 raptor i don't understand...  for levels
19:35:55 raptor i thought it wasn't all-or-nothing - so we could only load levels from one *real* folder
19:35:57 watusimoto ok, for all game resources except levels, we will point physfs at a user resource folder, and the system resource folder
19:36:16 watusimoto and there can be an sfx folder in each
19:36:22 watusimoto and a robots folder in each
19:36:23 watusimoto etc.
19:36:38 watusimoto and when the game wants to load a sfx, it will look in both folders to find one
19:36:43 watusimoto and everything works fine
19:36:47 watusimoto with me so far?
19:37:33 raptor yep
19:37:52 raptor this is more-or-less sounding like the original issue i had in my head...
19:38:52 watusimoto ok, so for all that it will work the way you described in the google case you made
19:38:59 watusimoto but for levels it will be different
19:39:02 watusimoto because
19:39:12 watusimoto if I say "play all levels in folder x"
19:39:27 watusimoto I don't want it looking at x in my local resources, and x in my system resources
19:39:39 watusimoto I want *only* the levels in my local folder x
19:40:01 watusimoto but if we are using physfs for resources, it will be pointed at two folders
19:40:22 raptor and that is exactly my original issue
19:40:31 raptor which i failed to articulate
19:40:34 watusimoto but we don't want that
19:40:39 raptor correct
19:40:43 watusimoto although...
19:40:45 watusimoto maybe...
19:41:38 watusimoto if we can enumerate all the files in the local copy of x, when we go to load them, maybe it will work, as it will always find a level in the local folder (because the list of stuff to load came from the contents of that folder)
19:41:53 watusimoto so it might never need to look elsewhere
19:42:24 watusimoto because it will only be looking for files that exist in the first search location
19:42:29 watusimoto because that is what we enumerated
19:42:44 watusimoto as long as the user doesn't try to delete levels in mid-game
19:42:52 watusimoto or some other stupid thing like that
19:42:56 raptor wait, how does that exclude the system levels?
19:43:11 watusimoto if I have a system folder with levels x,y,z
19:43:17 watusimoto and a local folder with levels a,b,c
19:43:28 watusimoto sorry
19:43:29 watusimoto start over
19:43:45 watusimoto system folder has x1,y1,z1,a1
19:43:55 watusimoto and local folder has a2,b2,c2
19:44:12 watusimoto where x1 and x2 are different copies of the same level
19:44:12 amgine123 use alt + #
19:44:23 watusimoto and I say play all levels in local folder
19:44:30 amgine123 on build 20 that you gave me it adds the teams but it doesnt change its color
19:44:48 watusimoto if we look in the local folder, we'll find a, b, c
19:44:49 amgine123 Why not jsut have poeple load levels from pleadies
19:45:05 watusimoto and when we load a, we'll get a1, and we'll never load x,y, or z
19:45:08 amgine123 that way they can play any level they want
19:45:17 watusimoto amgine123: that;s coming
19:45:18 amgine123 maybe imj thinking of somthing esle
19:45:44 amgine123 the idea is that you have people load levels from pleadies and people will be able to "search" for level instead of installing the entire server
19:46:01 watusimoto amgine123: yes
19:46:40 amgine123 dunno if its doable
19:47:09 watusimoto raptor: the key is in the enumeration; to grab only a,b,c and not x,y, or z
19:48:07 raptor how about just not enumeration the system levels dir?
19:48:12 raptor *enumerating
19:48:56 watusimoto yes, that's the solution
19:49:35 watusimoto I do not know what tools for enumeration that physfs provides
19:49:53 raptor ok, so to wrap up this topic -
19:50:01 raptor 1.  we will only load user levels
19:50:07 watusimoto probably what we need to do is to migrate from a folder based model to a playlist based model
19:50:08 raptor 2.  we hope phsyfs can accomodate
19:50:13 raptor 3.  physfs is the way to go
19:50:16 watusimoto and generate the playlists from the target folders
19:50:39 watusimoto I *think* physfs is the way to go
19:50:47 amgine123 Quit (Ping timeout: 246 seconds)
19:50:55 watusimoto well, yes, it probably is
19:51:02 raptor it looks really good, tried-and-true, stable-and-popular
19:51:24 watusimoto here is a weird possibility
19:51:33 watusimoto if we are playing levels in a zip file, for example
19:51:47 watusimoto that would mean that physfs would be pointed at that zipfile as a possibel source of data
19:52:04 watusimoto if the users places a sfx in that folder, that might get loaded instead of the intended version
19:52:29 raptor yep, but i place that in the realm of user-error
19:52:35 watusimoto not a deep concern, but there may be some weird side effects we haven't thought of
19:52:47 amgine123 has joined
19:52:55 raptor ok, do we need cdrom support for physfs?
19:53:01 watusimoto no
19:54:25 amgine123 100 free zaps for whoever figures out this captcha i got -_- http://imgur.com/8G5sCPK
19:54:50 amgine123 troll captcha XD
19:55:14 watusimoto I got it but I'm not telling!
19:55:29 watusimoto it is pretty ridiculous
19:56:05 amgine123 my guess its it just blank but i could be wrong
19:56:55 raptor that's nuts
19:57:16 amgine123 @raptor what does it mean if A build I created runs fine on one system but crashes on another -_-
19:57:28 raptor it could be dozens of things
19:57:48 raptor usually a problem with the bad system, and not the game - but it may be the game
19:58:44 amgine123 ok i may need to check my code again
20:07:34 amgine123 I think I vaugly make out DC FACL
20:10:23 raptor DOOM WAD support!
20:14:55 watusimoto awesome!
20:18:48 raptor win32 compiled dll at 142K
20:27:37 watusimoto do we actually need to manually copy the dlls, or can that be automated in cmake?
20:27:54 raptor already automated - we just need to drop them in the lib folder
20:28:21 watusimoto you mean manually copy them into the lib folder, no?
20:28:35 raptor just the once, into the repo
20:28:48 watusimoto or anytime they are subsequently updated
20:28:59 raptor if we really want to recompile, yet
20:29:01 raptor *yes
20:29:14 watusimoto so I guess then that I had it working, because when I copied the dll, my problems were fixed
20:29:30 raptor well...  but you had the whole source tree in the repo
20:29:39 watusimoto I expected to be able to run cmake, then compile in vcc, and have everything just work
20:29:42 raptor this is just one-time precompile like the rest of the libs
20:29:58 raptor yes, that will work after this one-time compile
20:30:20 watusimoto so if I download the project onto a fresh machine, I need to 1) run cmake  2) compile in vcc 3) copy dlls?
20:30:59 raptor ideally, when i'm done, you just compile bitfighter sources after running an updated cmake, and...  done
20:31:15 raptor no physfs source checked into our repo
20:31:51 watusimoto so we just store the dll in the repo?
20:32:15 raptor yes, like the others
20:32:20 watusimoto ah, I see
20:32:42 raptor so...  this brings up a point of conversation
20:32:42 watusimoto ok, that was not how I understood it to work
20:33:03 raptor there are 2 ways i handle dependent libraries:
20:33:48 raptor 1.  Include source in the repo, compile statically into bitfighter if not found already on the Linux/OSX system (always compile statically on Windows)
20:34:16 raptor like alure and poly2tri
20:34:48 watusimoto (that is what I was trying to do)
20:35:17 watusimoto (as I like having the source available to see how things work)
20:35:21 raptor 2.  Don't include source, precompile dynamic libs into the lib/ folder, include headers in the repo for windows/OSX (nothing needed on Linux because it is a standard package in most distros)
20:35:28 watusimoto (fewer black boxes and all that)
20:35:35 raptor like for SDL and zlib
20:35:41 raptor now
20:35:53 raptor i choose one over the other based on a number of factors:
20:36:11 raptor 1.  source size (sometimes it's in the 10s of MB)
20:36:33 watusimoto (like SDL)
20:36:35 raptor 2.  popularity and existence (usually I choose option 2 if it is a standard lib in most distros)
20:36:44 raptor like OpenGL
20:36:49 raptor no, bad example
20:36:54 watusimoto (ubiquitous)
20:37:18 raptor like vorbis or SDL
20:37:21 raptor yes
20:37:48 raptor now, there is room for me to change how i do things, but i've found that it's one of those 2 that seems to work best...  so far
20:38:12 watusimoto so for physfs, we have small source, unknown ubquity (esp. on OSX)
20:38:39 watusimoto and a need to look at the internals while we get this figured out
20:38:40 raptor however, I've never liked #2 (including DLLs, etc.) because it seems to dirty up the repo and add significant size.  I've toyed with the idea of providing an SDK that can be added on that will provide those
20:38:53 raptor ubiquity is high - it is everywhere on Linux
20:39:05 watusimoto I generally prefer #1
20:39:11 watusimoto but there is a 3rd possibility
20:39:21 raptor i prefer #1, too...   however, it still adds significant noise/size to th repo
20:39:30 watusimoto I don't care about that
20:39:35 watusimoto repos are cheap :-)
20:39:42 raptor physfs, for instance is about 4.5MB of mostly other projects sources (like zlib and 7zip)
20:40:04 watusimoto but possibility #3 is to script out the retieval and compilation to dlls of the various libs
20:40:12 watusimoto no source, no dlls
20:40:16 watusimoto (in the repo)
20:40:21 raptor explain
20:40:26 raptor is that like my SDK idea?
20:40:41 raptor i.e. ahve a zip file with all the DLL/LIB files in it so developers can just use them
20:41:08 watusimoto hg get physfs-source; msbuild compile physfs-source; move compiled dlls; cleanup
20:41:19 raptor maybe provide a bitfigter-windows-SDK download
20:41:46 watusimoto I didn't actually realize physfs was so big
20:41:47 raptor ah, that introduces a secondary layer into the build system (with needed complexity) that i'm not sure I'd want
20:42:19 watusimoto it does create some dependency on having certain tools available (hg, git, msbuild, etc.)
20:43:04 raptor yes
20:43:09 watusimoto do you think physfs is available on osx?
20:43:26 watusimoto (i.e. can we count on it?)
20:43:27 raptor not natively, i don't think, but i can easily build a framework...
20:43:37 raptor i.e. the precompile option
20:43:44 watusimoto right
20:44:38 raptor see here for something like the SDK idea:  http://www.freeorion.org/forum/viewtopic.php?f=9&t=1787
20:45:40 raptor the idea being that the freeorion source doens't have dependency source or binaries in the main repo, so they provide it/them as a separate download
20:48:58 watusimoto well, if I were doing it, I would just dump everything into the source tree... so it's good I am not doing it :-)
20:49:45 watusimoto but that's what comes of being windows-centric, when I can count on nothing
20:50:25 raptor yeah - i don't know what's best...
20:51:30 raptor i could dump in the physfs sources, if you think that's best - it'll be about 4.5 MB.  THe precompiled libraries for OSX/Windows will probably add up to about about 1MB or so
20:52:53 raptor i come from a very modular, keep-it-small mentality - probably due to my Linux exposure
20:53:38 watusimoto yeah, let's just build the dlls, like you did, and I'll purge the source from my commits before I push them
20:54:31 raptor huh...  no matter how hard i try, cd-rom support isn't disabled...
20:59:16 amgine123 Quit (Quit: Page closed)
21:11:12 amgine123 has joined
21:15:44 raptor ok watusimoto, here are the compiled libraries for windows - i haven't hooked them up to CMake yet, but maybe you already have that done:  http://sam6.25u.com/upload/lib.zip
21:15:57 raptor i need to do some circuits homework, so i'll see about OSX later
21:16:12 raptor those are compiled 'release' linked to our zlib1.dll
21:16:27 raptor later!
21:17:51 watusimoto ok, heading outmyself
21:17:52 watusimoto bye
21:17:57 raptor Quit ()
21:18:03 watusimoto Quit (Read error: Connection reset by peer)
21:26:59 amgine123 Quit (Quit: Page closed)
21:47:00 amgine123 has joined
22:11:04 fordcars has joined
22:18:00 amgine123 Quit (Quit: Page closed)
22:18:41 amgine123 has joined
22:35:35 amgine123 Quit (Quit: Page closed)
22:44:44 fordcars Quit (Ping timeout: 246 seconds)
23:03:49 empyrean has joined
23:05:21 empyrean Quit (Remote host closed the connection)
23:06:51 amgine123 has joined
23:22:18 amgine123 Quit (Quit: Page closed)
23:22:18 Raven67854 Quit (Remote host closed the connection)
23:25:53 Raven67854 has joined
23:31:17 amgine123 has joined
23:47:35 amgine123 Quit (Quit: Page closed)

Index Search ←Prev date Next date→

These logs were automatically created by BFLogBot on irc.freenode.net.

00:00:25		raptor Quit (Client Quit)
00:36:23		empyrean has joined
00:37:54		empyrean Quit (Remote host closed the connection)
00:52:27		empyrean has joined
00:57:08		empyrean Quit (Remote host closed the connection)
01:07:22		Flynnn has joined
05:12:51		Flynnn Quit (Quit: Leaving)
08:14:57		koda has joined
13:16:04		empyrean has joined
13:18:01		empyrean Quit (Remote host closed the connection)
13:25:31		watusimoto has joined
13:25:32		ChanServ sets mode +o
14:54:24		koda Quit (Ping timeout: 264 seconds)
14:55:07		raptor has joined
14:55:07		ChanServ sets mode +o
15:01:01	raptor	hello
15:08:14		molodoy has joined
15:08:24		molodoy Quit (Client Quit)
16:22:14	raptor	watusimoto: sorry i've been busy and haven't had much time to spend on physfs yet - however, before I precompile it; are we sure we want to use it? I think it's a good idea, but I honestly haven't thought of all the implications yet
18:53:55		raptor Quit (Ping timeout: 265 seconds)
19:15:21		raptor has joined
19:15:21		ChanServ sets mode +o
19:20:56	raptor	luajit updated - i should update our repo, too
19:21:03		amgine123 has joined
19:21:18	amgine123	hello anything new to test ?
19:22:38	watusimoto	hello
19:22:48	raptor	hi
19:22:58	watusimoto	raptor: I think so -- it solves a problem we will have
19:23:08	watusimoto	which is hosting out of zip files
19:23:15	watusimoto	which is something I'd like to support
19:23:24	watusimoto	though arguably not a critical feature
19:23:40	raptor	it also removes complexity with copying resources, etc.
19:23:48	raptor	which I wholeheartedly want to remove
19:23:59	raptor	however, i was htinking about one thing-
19:24:19	amgine123	wattsimo did you see my privite message
19:25:04	raptor	if we have a 'system' dir with sfx/music/levels/etc., and a user dir all meshed together, how would we allow editing of 'system' level files (assuming they would be the default stock levels)
19:25:07	raptor	?
19:25:14	watusimoto	amgine123: how do you add the teams?
19:25:43	watusimoto	raptor: how do we manage it now?
19:26:06	raptor	we copy all system resources into the user dir on first launch, then from thereafter onward the game is run out of the user dir
19:26:07	watusimoto	they normally would copy the stock levels to their "working" folder
19:26:13	amgine123	If you add prest teams they are not the correct color [17:22] <amgine123> they will all be red even though some teams should be blue ect [17:22] <amgine123> or yellow
19:26:24	watusimoto	right, and the user modifies their "working" copy
19:26:28	raptor	yes
19:26:37	watusimoto	so... that wouldn't change
19:26:44	raptor	but physfs abstracts away the idea of a rootdatadir
19:26:55	watusimoto	not exactly
19:26:57	raptor	we would, presumably, mush them together
19:27:04	watusimoto	we mush them together, yes
19:27:16	watusimoto	but we have "working" and "system copy"
19:27:19	watusimoto	in that order
19:27:27	watusimoto	so the working version is always grabbed if it existss
19:27:46	watusimoto	physfs lets you add folders in a search-priority order
19:27:51	raptor	ahhh
19:27:54	raptor	i wasn't sure about that
19:28:13	watusimoto	but the levels aren't a good example
19:28:30	watusimoto	because if I delete a bm.level from my levels folder, we won't go grab another copy
19:28:34	raptor	so the only cases i'm really worried about are mushed system/user resources because only the user ones would be modifiable
19:28:37	watusimoto	we just wouldn't want to host that level
19:28:44	watusimoto	but the sfx might be better
19:28:53	watusimoto	I have my modified sfx folder, then my system sfx
19:29:02	watusimoto	sorry local and system
19:29:16	watusimoto	if I have a phaser.wav in my local version, that gets used
19:29:23	watusimoto	if I don't, then system copy gets used
19:29:33	raptor	yes, that makes sense, and is good
19:29:35	watusimoto	so if I want to modify the sfx, I modify my local copy
19:29:38	watusimoto	and all is good
19:30:02	watusimoto	so for some resources, we'd have two folders (perhaps) a user specifyable override, and the system default
19:30:04	raptor	i'm thinking of a case taht is little different
19:30:08	watusimoto	for levels, we'd just have one
19:30:13	raptor	for levels... ah
19:30:16	raptor	just the user one?
19:30:35	watusimoto	because you define which levels you want to host with by creating a folder and putting htme there, them poitning bf at that folder
19:30:43	watusimoto	no overrides involved
19:30:52	raptor	ok
19:30:53	watusimoto	but I want to expand that to other mechanisms
19:30:57	raptor	that's a better idea
19:31:02	watusimoto	aim it at a zip file instead of a folder
19:31:05	raptor	and what i wanted to figure out
19:31:23	watusimoto	aim it at a playlist, in which case you might have multiple folders where those levels might live
19:31:34	watusimoto	aim it at pleiades
19:31:38	watusimoto	etc.
19:31:46	raptor	which i think will be awesome
19:31:54	watusimoto	indeed it would
19:32:03	raptor	i had it in my mind that it was an all-or-nothing system/user mesh
19:32:03	watusimoto	pleiades would become a level server
19:32:07	watusimoto	no
19:32:17	watusimoto	there is one problem, though
19:32:32	watusimoto	and that is there is only one "instance" of physfs
19:32:46	watusimoto	so you don't have one version for sfx and antoehr for levels
19:32:51	watusimoto	you just have one
19:33:03	raptor	one FS, right
19:33:13	watusimoto	which complicates things a bit if we want to use it in different contexts
19:33:40	raptor	like how? a bitfighter instance doesn't use more than one 'FS' right now...
19:33:49	watusimoto	for basic game resources, we can share a single instance -- point it at a user folder, and also a system folder, so it works like the sfx version I specified above
19:33:58	watusimoto	except we'd point it at the rootdatadir
19:34:10	watusimoto	and keep everything in its own subfolder, as we do now
19:34:20	watusimoto	so you can have physfs fine sfx/phaser.wav
19:34:24	watusimoto	find
19:34:57	watusimoto	if it is pointed at the root resources folder, it will figure out that sfx is a subfolder, and phaser.wav is a file in that subfolder
19:35:09	watusimoto	but we want to use it in a very different way for levels
19:35:17	watusimoto	so we really need two instances
19:35:25	raptor	i don't understand... for levels
19:35:55	raptor	i thought it wasn't all-or-nothing - so we could only load levels from one real folder
19:35:57	watusimoto	ok, for all game resources except levels, we will point physfs at a user resource folder, and the system resource folder
19:36:16	watusimoto	and there can be an sfx folder in each
19:36:22	watusimoto	and a robots folder in each
19:36:23	watusimoto	etc.
19:36:38	watusimoto	and when the game wants to load a sfx, it will look in both folders to find one
19:36:43	watusimoto	and everything works fine
19:36:47	watusimoto	with me so far?
19:37:33	raptor	yep
19:37:52	raptor	this is more-or-less sounding like the original issue i had in my head...
19:38:52	watusimoto	ok, so for all that it will work the way you described in the google case you made
19:38:59	watusimoto	but for levels it will be different
19:39:02	watusimoto	because
19:39:12	watusimoto	if I say "play all levels in folder x"
19:39:27	watusimoto	I don't want it looking at x in my local resources, and x in my system resources
19:39:39	watusimoto	I want only the levels in my local folder x
19:40:01	watusimoto	but if we are using physfs for resources, it will be pointed at two folders
19:40:22	raptor	and that is exactly my original issue
19:40:31	raptor	which i failed to articulate
19:40:34	watusimoto	but we don't want that
19:40:39	raptor	correct
19:40:43	watusimoto	although...
19:40:45	watusimoto	maybe...
19:41:38	watusimoto	if we can enumerate all the files in the local copy of x, when we go to load them, maybe it will work, as it will always find a level in the local folder (because the list of stuff to load came from the contents of that folder)
19:41:53	watusimoto	so it might never need to look elsewhere
19:42:24	watusimoto	because it will only be looking for files that exist in the first search location
19:42:29	watusimoto	because that is what we enumerated
19:42:44	watusimoto	as long as the user doesn't try to delete levels in mid-game
19:42:52	watusimoto	or some other stupid thing like that
19:42:56	raptor	wait, how does that exclude the system levels?
19:43:11	watusimoto	if I have a system folder with levels x,y,z
19:43:17	watusimoto	and a local folder with levels a,b,c
19:43:28	watusimoto	sorry
19:43:29	watusimoto	start over
19:43:45	watusimoto	system folder has x1,y1,z1,a1
19:43:55	watusimoto	and local folder has a2,b2,c2
19:44:12	watusimoto	where x1 and x2 are different copies of the same level
19:44:12	amgine123	use alt + #
19:44:23	watusimoto	and I say play all levels in local folder
19:44:30	amgine123	on build 20 that you gave me it adds the teams but it doesnt change its color
19:44:48	watusimoto	if we look in the local folder, we'll find a, b, c
19:44:49	amgine123	Why not jsut have poeple load levels from pleadies
19:45:05	watusimoto	and when we load a, we'll get a1, and we'll never load x,y, or z
19:45:08	amgine123	that way they can play any level they want
19:45:17	watusimoto	amgine123: that;s coming
19:45:18	amgine123	maybe imj thinking of somthing esle
19:45:44	amgine123	the idea is that you have people load levels from pleadies and people will be able to "search" for level instead of installing the entire server
19:46:01	watusimoto	amgine123: yes
19:46:40	amgine123	dunno if its doable
19:47:09	watusimoto	raptor: the key is in the enumeration; to grab only a,b,c and not x,y, or z
19:48:07	raptor	how about just not enumeration the system levels dir?
19:48:12	raptor	*enumerating
19:48:56	watusimoto	yes, that's the solution
19:49:35	watusimoto	I do not know what tools for enumeration that physfs provides
19:49:53	raptor	ok, so to wrap up this topic -
19:50:01	raptor	1. we will only load user levels
19:50:07	watusimoto	probably what we need to do is to migrate from a folder based model to a playlist based model
19:50:08	raptor	2. we hope phsyfs can accomodate
19:50:13	raptor	3. physfs is the way to go
19:50:16	watusimoto	and generate the playlists from the target folders
19:50:39	watusimoto	I think physfs is the way to go
19:50:47		amgine123 Quit (Ping timeout: 246 seconds)
19:50:55	watusimoto	well, yes, it probably is
19:51:02	raptor	it looks really good, tried-and-true, stable-and-popular
19:51:24	watusimoto	here is a weird possibility
19:51:33	watusimoto	if we are playing levels in a zip file, for example
19:51:47	watusimoto	that would mean that physfs would be pointed at that zipfile as a possibel source of data
19:52:04	watusimoto	if the users places a sfx in that folder, that might get loaded instead of the intended version
19:52:29	raptor	yep, but i place that in the realm of user-error
19:52:35	watusimoto	not a deep concern, but there may be some weird side effects we haven't thought of
19:52:47		amgine123 has joined
19:52:55	raptor	ok, do we need cdrom support for physfs?
19:53:01	watusimoto	no
19:54:25	amgine123	100 free zaps for whoever figures out this captcha i got -_- http://imgur.com/8G5sCPK
19:54:50	amgine123	troll captcha XD
19:55:14	watusimoto	I got it but I'm not telling!
19:55:29	watusimoto	it is pretty ridiculous
19:56:05	amgine123	my guess its it just blank but i could be wrong
19:56:55	raptor	that's nuts
19:57:16	amgine123	@raptor what does it mean if A build I created runs fine on one system but crashes on another -_-
19:57:28	raptor	it could be dozens of things
19:57:48	raptor	usually a problem with the bad system, and not the game - but it may be the game
19:58:44	amgine123	ok i may need to check my code again
20:07:34	amgine123	I think I vaugly make out DC FACL
20:10:23	raptor	DOOM WAD support!
20:14:55	watusimoto	awesome!
20:18:48	raptor	win32 compiled dll at 142K
20:27:37	watusimoto	do we actually need to manually copy the dlls, or can that be automated in cmake?
20:27:54	raptor	already automated - we just need to drop them in the lib folder
20:28:21	watusimoto	you mean manually copy them into the lib folder, no?
20:28:35	raptor	just the once, into the repo
20:28:48	watusimoto	or anytime they are subsequently updated
20:28:59	raptor	if we really want to recompile, yet
20:29:01	raptor	*yes
20:29:14	watusimoto	so I guess then that I had it working, because when I copied the dll, my problems were fixed
20:29:30	raptor	well... but you had the whole source tree in the repo
20:29:39	watusimoto	I expected to be able to run cmake, then compile in vcc, and have everything just work
20:29:42	raptor	this is just one-time precompile like the rest of the libs
20:29:58	raptor	yes, that will work after this one-time compile
20:30:20	watusimoto	so if I download the project onto a fresh machine, I need to 1) run cmake 2) compile in vcc 3) copy dlls?
20:30:59	raptor	ideally, when i'm done, you just compile bitfighter sources after running an updated cmake, and... done
20:31:15	raptor	no physfs source checked into our repo
20:31:51	watusimoto	so we just store the dll in the repo?
20:32:15	raptor	yes, like the others
20:32:20	watusimoto	ah, I see
20:32:42	raptor	so... this brings up a point of conversation
20:32:42	watusimoto	ok, that was not how I understood it to work
20:33:03	raptor	there are 2 ways i handle dependent libraries:
20:33:48	raptor	1. Include source in the repo, compile statically into bitfighter if not found already on the Linux/OSX system (always compile statically on Windows)
20:34:16	raptor	like alure and poly2tri
20:34:48	watusimoto	(that is what I was trying to do)
20:35:17	watusimoto	(as I like having the source available to see how things work)
20:35:21	raptor	2. Don't include source, precompile dynamic libs into the lib/ folder, include headers in the repo for windows/OSX (nothing needed on Linux because it is a standard package in most distros)
20:35:28	watusimoto	(fewer black boxes and all that)
20:35:35	raptor	like for SDL and zlib
20:35:41	raptor	now
20:35:53	raptor	i choose one over the other based on a number of factors:
20:36:11	raptor	1. source size (sometimes it's in the 10s of MB)
20:36:33	watusimoto	(like SDL)
20:36:35	raptor	2. popularity and existence (usually I choose option 2 if it is a standard lib in most distros)
20:36:44	raptor	like OpenGL
20:36:49	raptor	no, bad example
20:36:54	watusimoto	(ubiquitous)
20:37:18	raptor	like vorbis or SDL
20:37:21	raptor	yes
20:37:48	raptor	now, there is room for me to change how i do things, but i've found that it's one of those 2 that seems to work best... so far
20:38:12	watusimoto	so for physfs, we have small source, unknown ubquity (esp. on OSX)
20:38:39	watusimoto	and a need to look at the internals while we get this figured out
20:38:40	raptor	however, I've never liked #2 (including DLLs, etc.) because it seems to dirty up the repo and add significant size. I've toyed with the idea of providing an SDK that can be added on that will provide those
20:38:53	raptor	ubiquity is high - it is everywhere on Linux
20:39:05	watusimoto	I generally prefer #1
20:39:11	watusimoto	but there is a 3rd possibility
20:39:21	raptor	i prefer #1, too... however, it still adds significant noise/size to th repo
20:39:30	watusimoto	I don't care about that
20:39:35	watusimoto	repos are cheap :-)
20:39:42	raptor	physfs, for instance is about 4.5MB of mostly other projects sources (like zlib and 7zip)
20:40:04	watusimoto	but possibility #3 is to script out the retieval and compilation to dlls of the various libs
20:40:12	watusimoto	no source, no dlls
20:40:16	watusimoto	(in the repo)
20:40:21	raptor	explain
20:40:26	raptor	is that like my SDK idea?
20:40:41	raptor	i.e. ahve a zip file with all the DLL/LIB files in it so developers can just use them
20:41:08	watusimoto	hg get physfs-source; msbuild compile physfs-source; move compiled dlls; cleanup
20:41:19	raptor	maybe provide a bitfigter-windows-SDK download
20:41:46	watusimoto	I didn't actually realize physfs was so big
20:41:47	raptor	ah, that introduces a secondary layer into the build system (with needed complexity) that i'm not sure I'd want
20:42:19	watusimoto	it does create some dependency on having certain tools available (hg, git, msbuild, etc.)
20:43:04	raptor	yes
20:43:09	watusimoto	do you think physfs is available on osx?
20:43:26	watusimoto	(i.e. can we count on it?)
20:43:27	raptor	not natively, i don't think, but i can easily build a framework...
20:43:37	raptor	i.e. the precompile option
20:43:44	watusimoto	right
20:44:38	raptor	see here for something like the SDK idea: http://www.freeorion.org/forum/viewtopic.php?f=9&t=1787
20:45:40	raptor	the idea being that the freeorion source doens't have dependency source or binaries in the main repo, so they provide it/them as a separate download
20:48:58	watusimoto	well, if I were doing it, I would just dump everything into the source tree... so it's good I am not doing it :-)
20:49:45	watusimoto	but that's what comes of being windows-centric, when I can count on nothing
20:50:25	raptor	yeah - i don't know what's best...
20:51:30	raptor	i could dump in the physfs sources, if you think that's best - it'll be about 4.5 MB. THe precompiled libraries for OSX/Windows will probably add up to about about 1MB or so
20:52:53	raptor	i come from a very modular, keep-it-small mentality - probably due to my Linux exposure
20:53:38	watusimoto	yeah, let's just build the dlls, like you did, and I'll purge the source from my commits before I push them
20:54:31	raptor	huh... no matter how hard i try, cd-rom support isn't disabled...
20:59:16		amgine123 Quit (Quit: Page closed)
21:11:12		amgine123 has joined
21:15:44	raptor	ok watusimoto, here are the compiled libraries for windows - i haven't hooked them up to CMake yet, but maybe you already have that done: http://sam6.25u.com/upload/lib.zip
21:15:57	raptor	i need to do some circuits homework, so i'll see about OSX later
21:16:12	raptor	those are compiled 'release' linked to our zlib1.dll
21:16:27	raptor	later!
21:17:51	watusimoto	ok, heading outmyself
21:17:52	watusimoto	bye
21:17:57		raptor Quit ()
21:18:03		watusimoto Quit (Read error: Connection reset by peer)
21:26:59		amgine123 Quit (Quit: Page closed)
21:47:00		amgine123 has joined
22:11:04		fordcars has joined
22:18:00		amgine123 Quit (Quit: Page closed)
22:18:41		amgine123 has joined
22:35:35		amgine123 Quit (Quit: Page closed)
22:44:44		fordcars Quit (Ping timeout: 246 seconds)
23:03:49		empyrean has joined
23:05:21		empyrean Quit (Remote host closed the connection)
23:06:51		amgine123 has joined
23:22:18		amgine123 Quit (Quit: Page closed)
23:22:18		Raven67854 Quit (Remote host closed the connection)
23:25:53		Raven67854 has joined
23:31:17		amgine123 has joined
23:47:35		amgine123 Quit (Quit: Page closed)