Jump to content

[SOLVED] Deleting files in the data folder at runtime


photo

Recommended Posts

Hello,

 

I've recently experienced some problems with my project, although these have been going unoticed for some time. The issue regards deleting files from the data folder from previously loaded worlds and the filesystem still thinks they should be there. To further describe this problem I shall briefly go over our use case. (see pic).

 

post-386-0-55515700-1358951082_thumb.png

 

Our data folder consists of a working directory. It is here where we unpack our scene files using external code. Our scene files are essentially a zip file which contains the world file, world script and all assets contained in that world (.node, .mesh, .dds, .mat, etc). Every world file in a scene shares the same name (i.e. "TheWorld.world"), although the contents of the world file and all assets will be unique to that scene.

 

The first scene file we unpack and load the world of will behave itself. But the quitting that world, clearing the working directory, unpacking a new scene and then loading the new world causes problems. The world itself will run fine after a short loading stall. Opening the log file reveals why the stall happened.:

 

[Prior log file entries omitted (Note that this is the second world to be loaded)]

12:09:04 Loading "WorkingDir/TheWorld.world" 5249ms
12:09:04 Unigine~# render_restart
12:09:05 FileSystem::getFile(): can't open "../data/WorkingDir/objects/Door/Door.mesh" file
12:09:05 Mesh::info_mesh(): can't open "WorkingDir/objects/Door/Door.mesh" file
12:09:05 FileSystem::getFile(): can't open "../data/WorkingDir/objects/Poster/Poster.mesh" file
12:09:05 Mesh::info_mesh(): can't open "WorkingDir/objects/Poster/Poster.mesh" file
12:09:05 FileSystem::getFile(): can't open "../data/WorkingDir/objects/Window A/Window A.mesh" file
12:09:05 Mesh::info_mesh(): can't open "WorkingDir/objects/Window A/Window A.mesh" file
...
 
and a little farther down...
 
...
12:09:05 FileSystem::addCacheFile(): can't open "WorkingDir/Roof_diffuse.png" file
12:09:05 FileSystem::getFile(): can't open "../data/WorkingDir/Roof_diffuse.png" file
12:09:05 ImageFilePNG::load(): can't open "WorkingDir/Roof_diffuse.png" file
12:09:05 FileSystem::getMTime(): can't stat "../data/WorkingDir/Roof_diffuse.png" file
12:09:05 FileSystem::addCacheFile(): can't open "WorkingDir\Roof_normal.png" file
12:09:05 FileSystem::addCacheFile(): can't open "WorkingDir\Roof_normal.png" file
12:09:05 ImageFilePNG::load(): can't open "WorkingDir\Roof_normal.png" file
...
 
We tend to get hundreds of lines like this depending on how much content previously opened worlds contained. All errors are in reference to assets that were in the previously loaded world. The console function "filesystem_reload" is not doing the job of detecing deleted files from the data folder and I am unable to make use of any engine.filesystem functions.
 
I do find it strange that I havn't come across this sooner as I believe the application will slowly become more and more unstable the more worlds you load. So is there a solution to perhaps clear the FileSystem of files that no loner exist?
 
Thanks
Link to comment

Can you provide a small test scene so we can check non-working filesystem_reload command?

 

Upon further investigation it seems that the filesystem_reload command may not be to blame. Using filesystem_info before and after the filesystem_reload and the wipe of the working directory, the removed files are no longer listed as expected. Loading a new unpacked world afterwards is somehow looking for meshes and textures that were loaded into the previous world. After an error for each mesh/texture has been made in the log the issue is no longer present (until you open a new world by the smae means), as if whatever was looking for the files in the first place has now come to terms with the fact they no longer exist. Furthermore I can force the engine to log these errors before loading a new world by calling the render_manager_reload command. This command works for modified files, but will log errors when the file no longer exists. I think the issue is that I expected the engine to recognise missing files as having been deleted. So basically, it would be nice if this could be handled without logging lists of errors.

 

As for a test scene, that'll have to be on hold as were busy with other things and a simple script won't suffice as some c++ code will be required to delete the working directory files and to unpack the zips.

 

 

It there any reason to unpack the world? You can add your archive via Unigine::FileSystem::addPackage() and that should eliminate the errors.

 

Yes there is a reason. All files we unpack are subject to being modified or deleted, in addition to extra files being added, so that we can repack the scene into a new zip. For example asset changes do not conflict with scenes which share the same asset. This also makes the files easy to share within our application as all non-core dependancies are in one file. We also handle a lot of the content in other non-Unigine parts of the application on our interfaces and such.

Link to comment

Carl,

 

Errors are logged since render manager cache is not yet updated. For example, loading an empty world in between will do the trick. We'll see if we can improve this situation, but I'm afraid it's not on the high priority list right now. We'll keep you posted.

Link to comment

OK thanks Manguste. Just to clarify, won't loading an empty world still log these errors as the cache gets updated? I don't understand how loading an empty world will have a different effect than just loading the world we want to run, except logging the errors in a different place in the log file. Am I missing the point here?

Link to comment
  • 4 weeks later...
  • 4 months later...

The only logged errors that have gone are the FileSystem::getFile() errors. I still get Mesh::info_mesh(), ImageFilePNG:info() and FileSystem::addCacheFile() errors.

 

Was the fix intended to remove all these errors from the log? Have you got any further suggestions?

 

Thanks 

Link to comment

I played around with the code a bit, and after removing the console call to filesystem_reload and render_manager_reload after quitting a world the errors stopped appearing :)

I think this matter is solved. Thanks Unigine team.

Link to comment
×
×
  • Create New...