On 9/8/08, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > On Monday 08 September 2008 06:03:08 bugs buggy wrote: > > If you want to add all the files/directories in base, one by one, then > > remove them one by one, checking no file handle is open, that seems to be > a > > overly complex way to handle this. > > I just assumed PhysFS could tell us... I didnt try to think of some crazy > way > of hacking it.
Nope. At least, I couldn't find any call in physfs to do this. > least one file handle is open, (in this case, it happens to be the music > > one) and physfs won't allow it to be removed from the search path (which > is > > correct behavior IMO) so it fails. > > If PhysFS rejects removing that directory, it seems pretty much fine to > me... > The whole search path thingy (on our end) needs to be revised anyway. > Now with the knowledge that we cannot just purge it and recreate it > whenever > we want. > The current behaviour (reject unmounting a dir, and mount other dirs on top > of > it) seems fine to me and we should make use of it, rather than hack around > it > in weird ways... For what it is worth, we do read in all the other files in one pass. We use that big buffer for everything but the music ones, which we read ~4k at a time (I think), then play, then read the next 4K, and play... and only at the end of that do we close the file handle. > I was thinking of something along the lines of: > > Warzone > > Warzone/data > > Warzone/data/base > > Warzone/data/mods > > Warzone/data/mp > > Warzone/data/music > > Warzone/data/music/music* > > You'd have to do that for several more directories, and it would not really > be > clean imo... Which other directories do we need? Unless your thinking of splitting campaign related stuff out of base, but that would make things in base pretty sparse. > There is also a configdir/music directory (which overrides the other > music > > folder) which needs to be removed, unless, we will allow sharing of music > > tracks between people? AFAIK, this is left over behaviour from before, > and > > not really needed. > > userdir/music is not "left over" "from before" or "not really needed"... > What > is in userdir is what the user chooses over the system installation... And > that needs to stay... Remember, there exist so called "multi user operating > systems"... Sorry, I misspoke. It was late. :o I was thinking of something else completely different. > *since the source has 'music' hardcoded (static const char UserMusicPath[] > > = "music";), rather than changing allot of things around, I did it the > > simplest way to prove this is the problem. > > I dont think we should change that hardcoding. Maybe just move it somewhere > where it is obvious it is not something to choose or a config setting, but > a > constant, a name for a magic value. (In case it is used more than once. > Otherwise a string by itself should be pretty selfexplanatory.) Ok, in that case, we could add /data to the search path, and then the music will be /data/music/*.ogg. Or leave it the way it is now with the search path pointing to /data/music, and then we access the music files the way I talked about before. (/data/music/music/*.ogg) Question: This is the cause for the PhysFS crashes we are experiencing, > right? > > --Devu The crash doesn't happen in physFS, it happens because warzone is reading in the wrong data (base instead of mp) which resulted in this: "error : [scrv_error] VLO parse error: Construct component CyborgSpade not found at line 86, text: 'CyborgSpade' error : [dataScriptLoadVals] Script rules.vlo did not compile error : [resLoadFile] resLoadFile: The load function for resource type "SCRIPTVAL" failed for file "rules.vlo" error : [resLoad] resLoad: failed to parse wrf/multi/skirmish8.wrf error : [startGameLoop] Shutting down after failure"
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
