I came up with some unorthodox solutions.
The first was to manipulate the map file (on disk) in-game. This didn't work with my tests as it appears to load it up into memory when the game starts & doesn't read it each time it needs to locate a resource.
If it is a script, perhaps calling a large string from a global variable to populate a basic script?
This is similar to what I tried next: manipulating the actual resource package in game. You can actually do this:
FlushResources() // blast out any resources in memory
(if( <> NULL (= hFile FOpen("resource.001" fCREATE)) )
FPuts(hFile "Hello World!") // need populate the file with contents from another res package
FClose(hFile)
)
// load a text resource from our newly created resource.001 file.
FormatPrint("text resource:%s" 000 0)
The above code successfully nukes the resource file. The next step would be to slurp the contents of a surrogate resource file into a string & replace the existing one, then load the resource from that file that I want. But there isn't nearly enough memory to do this. I suppose I could try to store the entire contents of a resource file into a text resource entry so that *maybe* I wouldn't have to load the contents into an in-memory string. Either way, this solution is ugly and probably slow. This is pretty close to emulating 'disk-swapping'.
EDIT: Wait, this won't work. The map file wouldn't be updated (and reloaded into memory) to reflect the correct sizes/locations of the resources in the resource package. Extremely unlikely that the sizes of all the resources within the package would be the same.
However, this idea might work reasonably well with patch resources. Using the same technique above, we could dynamically create/replace patches in-game. Perhaps put different patch files in a sub directory, then use the file operation commands to create the patches into the root directory of the game.
