Simple File System
Monkey Forums/Monkey Code/Simple File System
| ||
Edit 7/1/2012: A newer version of Monkey broke this code (I think). I haven't tried fixing it because I'm using Monkey JSON for my file system now. If it still works, great! If it doesn't, don't be surprised. Edit 4/5/2013: An even newer version of my JSON file system can be grabbed here. I had been working on some database specifications and realized that I couldn't use it in Monkey because it has multiple files have to be accessed and altered. So, I came up with this. It's kind of hacky at the moment because I wrote it extremely fast. It works nonetheless and is very, very simple to use. Documentation (Generated by JungleIDE): http://nrgs.org/skyknitters/docs/FileSystemS.monkey.html This is an example test file This will be updated with cleaner code when I have the time. If you get any errors, fix any problems, have criticisms, or whatever, please tell me. I'll attempt to deal with it when I can. EDIT 10/22/11: I'm working on a second version that will have iOS compatibility and cached reads, writes, edits, etc. It'll be a while longer though. |
| ||
looks nice, if i have a huge file.. say 500kb and a small file ...say 1kb can i access the small file quickly? or does the big file slow it down (loading and parsing) For example i could have a saved game of 500kb and an options file of 1kb |
| ||
Well, theoretically, with the way it's setup. The lower down on the file system it is, the slower it will be. If the 500kb file is first and the 1KB file is next. It should be able to access both files relatively fast. It works like Stored Index /500kb [stored length: 512000b] /1kb [stored length: 1024b] Data starts at: Data Index (After file index) To get to position of the file, it takes and adds all previous stored lengths of the files to find the slice location. So, the data for /500kb would be at: Data Index to stored length of /500kb For the /1kb file, it would be: Data Index + Length of /500kb file to stored length of /1kb |
| ||
interesting, i may use it later thanks |
| ||
You're welcome. By the way, here's the quick documentation on it if you want: http://skyknitters.com/docs/FileSystemS.monkey.html -- On this note, after getting some opinions from other people (around me), I'm going to rework how the directories and file index work. The new specifications will speed up file locating if directories are used to separate the data and if a lot of files are used. If very few files are used, it'll actually be a theoretical pinch slower. On the other hand, I'll be able to work some extra things into it easier, that I wanted to do with this one. E.g. A sort function, directory contents that read both files and directories, and data encryption and/or obfuscation. |
| ||
@Goodlookingguy Have you tested this using ios? As I suspect you may have issues when encoding ints/bytes. Gfk had a problem with his filing system and posted it as a bug, but as it turned out the native class that deals with strings (NSString) on apple devices doesn't like non standard strings. A bit of googling will show up other examples of problems when dealing with apple's own implementation of a string class. http://www.monkeycoder.co.nz/Community/posts.php?topic=1653 |
| ||
I don't have a Mac yet and can't test anything with iOS yet. As soon as I get one, in the following months, I'll look into writing a custom string handler if necessary. Or maybe the creator of Monkey can make just that platform act like the rest. Seeing as we're limited to modifying ONE file, it seems unfair to stop us from making these sorts of systems which require the null character in the strings. |
| ||
Or maybe the creator of Monkey can make just that platform act like the rest. From what Mark has posted I don't think it's on his list of priorities at the moment. So I would guess if any one is desperate they would have to implement their own solution either as a module or editing the monkey output file directly and then compiling their work. |
| ||
Yes indeed. By any chance, do you know if this problem also affects the LoadState() function in the iOS? If not, I don't think the intended use for this file manager will be a problem. Edit: Is it the actual string handling that can't handle null? If not, a simple base64 encode when saving and decode when opening would fix this, right? Just some thoughts in my head. |
| ||
By any chance, do you know if this problem also affects the LoadState() I believe it does as the state file is stored as a string. Edit: Is it the actual string handling that can't handle null? If not, a simple base64 encode when saving and decode when opening would fix this, right? Just some thoughts in my head. Well from what information I have seen so far NSString isn't capable of handling malformed strings. I believe the usual method is to use a NSData object and parse the data for the relevant information that your looking for. At the moment I'm still learning Objective-C and the Foundation Framework. So perhaps some who is familiar with the Foundation Framework may be able to explain it better. |
| ||
Okay, thank you very much. I think I'll make an alternative version of this for that platform for the sake of everyone's sanity. I'll just use Base 36 to save space when reading how many bytes. --- A bug fix for the DeleteFile method not changing the file count length updated. |