TrailMyx's Filesystem for OEUO

[TrailMyx]

Code: [Select]

Script Name: TrailMyx's Filesystem for OEUO
 Author: TrailMyx
 Version: v5
 Shard OSI / FS: sure, why not?
 Revision Date: 9/10/2010
 Purpose: Collection of routines to simulate the namespace functions found in
          the original EasyUO

 Functions:
      New(o) - creates a new namespace object.  You will only need one.
          OEUO example:  myns = TM_NS:New() -- create TM_NS object
          EUO example: none
      RegisterVar(nstype_in, nsname_in,kind_in, var_in) - registers a user specified variable with the filesystem
          nstype_in - "local", "global" or "lua".  "local" & "global" are used for interfacing with existing EUO namespaces as well
                as the TM_namespace manager for Lua. "lua" is used for lua-specific variables.
      Load(filename_in) - loads a specified saved file name.
      Save(filename_out) - saves a specified set of registered variables to a file.

 Special Thanks:

 Beta testers:
 Bug testers:
 
=================================================================
So after a burst of energy on the CLAw for OEUO, I decided I needed to take a few days to work on a good file saving mechanism for OEUO.  If you've used either of my advanced file system or the unpublished TM_NGFS, you'll know there exists a way to save and recall things easily in EUO.

I started to port my advanced file system directly to OEUO, but I thought it would be nice to have a couple features of the NGFS (like registration).  But after working on that a bit, I decided to move it more toward something more generally useful for Lua.

So the new file system will have the best of the worlds of both my file systems, will be able to save/recall information to and from my namespace subroutines (for maximum compatibility) and will allow you to remember data types of the data stored.  Also, you will be able to remember shallow tables to help the saving process.

[TrailMyx]

I actually had a burst of energy coupled with a bit of bordom today, so I whipped up the file system.  It's pretty nice actually, plus you can load files created in the EUO version.  Items are managed much like they were in the NGFS, so registration is similar.  However, you have a flat-file to move things around with. 

I'll do a bit more testing and then put up for you to play with and so I can continue with the CLAw.  BTW, old CLAw save files are also compatible, so you should be able to move your previous loot profiles directly into CLAw for OEUO.

[TrailMyx]

Anyone in the position to try this out?  I haven't posted it yet because there really hasn't been much interest in OEUO so far.

The file format is similar to EUO, and I'll be changing it just a little bit so it'll be the same.  So you can take a file saved in EUO and open it in a OEUO script.  Kinda handy.  Also, the idea behind this is based on my original filesystem - i.e. information saved in files and not registry.  The variable registration process is much more like the NG_FS however.

Also, since I heavily rely on namespaces in OEUO, this also interfaces flawlessly with my namespace subs, so that namespace-related save files from EUO (i.e. CLAw saves) interface directly into OEUO and populate much the same. 

Anyhow, if there's any interest, I'll polish and post.  If not, then I'll just keep to myself for now until there is more interest.

[TrailMyx]

ok, it's OEUO release night apparently.  These routines allow you to manage loading and saving variables very easily.  Also, these are compatible with the the original EUO routines I wrote.

Please see the first post for the attachment.

Enjoy!

I may add another set of subs that will allow you to visualize variables stored within a filesystem and managed through the global variable routines.  Look for that sometime soon.

[Endless Night]

Nice work TM .. ive downloaded it ..

[TrailMyx]

Nice work TM .. ive downloaded it ..

There's better ways to do it.  You can make a save so that it loads directly into lua without parsing.  If I didn't have all the scripts from EUO, I would have probably gone that way.  But since I want to keep some compatibility between the two, this works best.