Now implementing such a change to an already existing program (TS2013) can lead to problems.
The best way of doing this is known as "shimming", i.e. inserting a logic module (shim) between the game engine and the file system.
In a well-built program using modular architecture, this shim should already exist anyway because game logic should never talk directly to the file system (1).
file logic.jpg
WIth this architecture, the game engine tells the file logic shim to fetch a file, wherever it is. The file logic determines which file to fetch and returns it to the game engine. This way, the game engine doesn't need to know about .ap files, and doesn't need to be modified at all.
I would encourage Mike Simpson to use the same concept for RW-Tools, getting rid of all the special .ap file functions in the menu and making all of this transparent to the user.
(1) Whether or not this is compiled into the same executable is not important
You do not have the required permissions to view the files attached to this post.