LE3 file system

[Josh]

Here's what I have planned for the LE3 file system:

 

-Editor displays paths in a tree structure. Objects are categorized by folder hierarchy instead_of_names_like_this.

-Abstract file system is gone.

-Pak files are treated as folders. All file commands work on both real files and pak files, except pak files are read-only. I thought about making pak files writable so WriteFile() would actually work, but do you really want to have to periodically defragment your pak files? I don't.

 

So if you have a pak file called "Models.pak" and a file in it called "house.gmf" you can call this command to load it:

LoadMesh("Models\house.gmf")

 

If a real file exists at the path "Models\house.gmf" it is loaded preferentially. In other words, pak files act just like folders, but if a real file exists in the specified path, it will be loaded instead of the pak file.

 

A method of registering either a single pak file or all pak files in a directory will still be needed, so that file names can be retrieved quickly.

 

The hierarchy shown in the editor will display pak file folders and files just like regular folders and files. If a pak file is updated, it will reload the directory structure the same way directories get dynamically reloaded.

 

Any thoughts on this?

[Canardia]

Sounds good. Just make sure we can use forward slash as directory seperator, like in LE 2 (and Lotus Notes/Domino), so the same game source works on all platforms.

[Ywa]

Why are you dropping the abstract file system? I'm using it quite often and it works great.

 

Anyways. I like how you will prioritize normal & PAK files. This allows modifications and such while still keeping the original ones when some files are broken.

[macklebee]

So basically with abstract path gone, we are going to have hardcode the paths for everything... even for shaders... hmmm... it will work, I guess... still liked the abstract path, personally... What will take the place of RegisterAbstractPath for setting the working directory? Are you keeping that command where it just sets the base folder? RegisterBaseFolder?

[Josh]

So basically with abstract path gone, we are going to have hardcode the paths for everything... even for shaders...

When was the last time you renamed your shaders folder?

 

My take on the abstract file system is this:

-It creates ambiguity, which in general is bad.

-The LE3 editor displays the directory hierarchy, so we have a new focus on that.

-It was mostly good for grabbing pak files, but I have proposed an alternative way of handling that.

 

The command would probably be something like RegisterPackFile(path) or RegisterPackFiles(folderpath) to just recursively register any pack files in a directory.

 

Materials would still load textures first from the path relative to the material file, then from the root path.

[Canardia]

You could use volume system, like amiga has. Then you can assign any name to any directory or device, like texture0="textures:ground1.png". You could have a command like RegisterVolume("textures","data/textures.pak");

[macklebee]

When was the last time you renamed your shaders folder?

 

My take on the abstract file system is this:

-It creates ambiguity, which in general is bad.

-The LE3 editor displays the directory hierarchy, so we have a new focus on that.

-It was mostly good for grabbing pak files, but I have proposed an alternative way of handling that.

 

The command would probably be something like RegisterPackFile(path) or RegisterPackFiles(folderpath) to just recursively register any pack files in a directory.

 

Materials would still load textures first from the path relative to the material file, then from the root path.

 

good point... once its hardcoded, dont need to do it again...

 

 

 

You could use volume system, like amiga has. Then you can assign any name to any directory or device, like texture0="textures:ground1.png". You could have a command like RegisterVolume("textures","data/textures.pak");

 

actually like that idea lumooja...

 

damn... you get me used to the abstract path and make me wonder why i ever had to hardcode a path and convince me it works great, and now you got me thinking that hardcoded paths are nice again... stop playing with my emotions!

[Pancakes]

The way Blade3d handled things was wonderful. Basically the editor was smart enough to see what you were importing. Then if you apply the imported item into your project it would save it to the appropriate place automatically. In this way it created it's own file structure for you which was just great.

[Rick]

That's basically the way Unity works too. When you import something to your project it copies it to a location for the project. The issue is that not everything with Leadwerks has to even go through the editor though so still need a way to load stuff from code.

 

I really like Lumooja's suggestion. Giving names to paths is a pretty cool idea. The editor could give us the ability to add as many of these named paths as we want in it, and the LE library would handle the replacements of these named paths when it loads something.

[Josh]

You can just drag an .obj or whatever onto the editor window, and if the file isn't already in the game path somewhere, the editor will copy the file to the Models folder, convert it to GMF, and create an instance of it in the scene.

[Canardia]

The volume feature has one more candy (also what amiga has): When you label a media, like a floppy disk, CD, DVD, USB stick, etc... and then you reference that media in your application, it will ask you to insert that media, and it will continue automatically with the code when the media is inserted (no pressing of OK, Retry, etc.. buttons needed). So you can have all your assets on CDs/DVDs and whenever your application needs them, it will ask for the right media and copy them to its own game folder (if you tell it to do so).

 

If you previously already registered the volume to be a directory on your HD, then it won't ask for the media as it already found the volume name, but you can still copy the files to your game folder and give it a local volume name, so it will look in your game folder instead of your HD's folder. So there needs to be a text file which holds the permanent volume names in either your current directory, and/or in the current drive's root directory.

 

So your code could look like:

if( !IsVolumeRegistered("JapaneseFlowers") )
{
CopyFile("JapaneseFlowers:","data/models/japaneseflowers/", COPYFILE_RECURSIVE );
RegisterVolume("JapaneseFlowers","data/models/japaneseflowers");
}
TModel flower1 = LoadModel("JapaneseFlowers:Lotus.gmf");

[L B]

Love this new system, only got 1 question: is it relative to the executable path or absolute?

 

i.e. C:\x\y\z.gmf

or (considering your executable is in C:\x),

y\z.gmf

[Canardia]

Obviously both is possible, since the OS takes care of that. On Windows you can say "c:/x/y/z.gmf" and on Linux you can say "/x/y/z.gmf", and both are absolute paths. When you say "x/y/z.gmf", it's relative, which is actually a short form of "./x/y/z.gmf". But in any case, the OS takes care of that, so there is no additional logic needed in LE.