Retrieving currently loaded archives?

[Cheesecan]

Why are there no lua calls to retrieve currently loaded archives?

For example if I am playing BA7.19.sd7 on the map XYZ.sd7, then those archives should have already been loaded into the main memory by Spring. Why is there no lua function that allows me to retrieve them?

Right now it seems to me I have to actually load the archive a second time using VFS to work with them. Unnecessary and slow.

I also want a function retrieveLoadedFile(String filename) which checks for and retrieves a file that is already in main memory. For instance if XYZ.sd7 map was loaded then it might have a XYZ.sd7/maps/XYZ.smf. I want to be able to do retrieveLoadedFile("XYZ.smf") to read(only) it quickly without any fuss.

Did I miss these functions somewhere in the lua wiki pages? The wiki sucks balls to be blunt and SpringLuaScripting.pdf is incomplete so there is little guarantee that one finds a particular thing which one is looking for(unless you are not looking for it, in which case you usually find it inadvertently).
Thoughts on my suggestion? Is it a horrible idea? If so then how come etc.

[Kloot]

If you need to know archive filenames, you're doing it wrong.

http://springrts.com/wiki/Lua_ConstGame#Map
http://springrts.com/wiki/Lua_ConstGame#Mod

I want to be able to do retrieveLoadedFile("XYZ.smf") to read(only) it quickly without any fuss.

Code: Select all

smfFileName = "maps/" .. Game.mapName .. ".smf"
if (VFS.FileExists(smfFileName) then
    smfFileData = VFS.LoadFile(smfFileName)
end

The wiki sucks balls to be blunt

Criticize yourself before you criticize others.

[Cheesecan]

What I want is to read files that have already been loaded by the engine, such as the map archive of an ongoing game. Is it necessary to have to read them all over again? Seems very inefficient.

Well maybe I have been spoiled by javadocs and doxygen generated documents but this wiki doesn't have descriptions for most functions so searching fails unless you already know what the function is called. That is my main gripe with the wiki. Another one is that in some cases for instance with VFS.MapArchive, it's unclear if all signatures give a return value or if only one signature does. It also appears to search in a different path than VFS.LoadFile?

[Niobium]

I think it would help if you gave us an idea of what you are trying to achieve, and why double-retrieval inefficiency is such an obstacle.

[Cheesecan]

It's for a widget that places metal spots on maps. I already have most of it worked out with display lists to speed up drawing.

The very first a map is loaded though it would have to load the map archive to see if it has a file inside of it that contains some information for the widget such as the type of metal spots(forest, desert, mars etc).

I don't really like the idea of loading such a big archive twice? So I was wondering if there was a way to get direct access to what might still be in memory (unless the engine just loads the map into its own data structures and then frees up the file buffer immediately).

[knorke]

The very first a map is loaded though it would have to load the map archive to see if it has a file inside of it that contains some information for the widget such as the type of metal spots(forest, desert, mars etc).

You have a map that includes a non-default file with some informations and what to read that file?

[Cheesecan]

No, it's just about reading the map already in main memory. Nothing else. Sorry it's my bad I was really unclear about what I meant in the first post & topic.

[Argh]

Just read that information at startup, build your lists, and you're done. If you're planning a whole suite of Widgets that would use this information, you can cache it in a second Widget and pass it to whatever needs it.

What you're talking about will be fairly expensive no matter how you go about it- the IO cost of fetching the file is a pretty small part of the speed at initialization, I'd think.

[aegis]

I don't really like the idea of loading such a big archive twice?

unless it's compressed as solid (which makes maps/mods load really slowly already), you only need to read the headers/dictionary to extract one file, not the whole archive.

"premature optimization"