Originally Posted by
ColdBlooded
thanks for putting in the time into explaining this well. it makes a lot more sense now. it would still be nice to have a dev client and a release client, where the dev client has everything in raw format for easy editing, including the landscape and object maps, as well as, sprites and other compressed data, then the release client would contain the compressed form. but i'm aware that's the reason why cache editors exist lol.
You're welcome, I GUESS the intention of R-S was originally supposed to be a place where people can come to share ideas, collaborate, and learn. Someone like you, who is making an honest effort to find+address+innovate+discuss problems, deserves to be treated well.
I don't think their tools use different formats. I'd say that good developers focus on reducing complexity, only introducing it for justifiable reasons. Sure, the content of the game is questionable, but the game code is very well crafted.
I just can't help but question: why make an intermediate format? Nobody is going to be editing the files, the editor will be doing that saving. The file formats are VERY good. Afaik the client they use for editing uses the same core as the game so it could go a few ways, but I don't think any of them would involve an intermediate format.
Speculation:
Maybe they work on the data as actual files and only use the cache system for the client. That would mean the ONDEMAND/JAGGRAB servers dish out real files and the client receives them, then stores them into the archive format. There's no way to really know, but it's plausible.
The cache is like a stripped down, proprietary archive format. It can be thought of like a zip, tar, etc. except it has been purpose-built for RS. Decompressing the files every time you need to serve them seems inefficient for Jagex to do... I admit I don't know how big the cache is when it has been expanded into real directories and files.
A sort of relevant idea:
I've always wanted to implement was a file protocol implementation for the game files to make server configuration and client editing easier.
If you decouple the editor from the storage medium then you have the freedom to use real files or files within the archive (cache).
So something like a handler for cache://cache_dir/index/file so you can specify exactly what directory to use and the protocol handler can automatically say:
A solution like this also means that your protocol does not change, so you can swap out for support of higher or lower revision caches without the protocol changing, and without requiring the editing code to care about what version format the archive is. All your tools can use this format and you can add support for more archive format versions.
If you want to detect the version of the cache you would be able to do something like cache://cache_dir/info to receive some structured data (yaml, json, xml, whatever) of all the information you could possibly want to know about it
Indices w/ counts, checksums, format version, etc. so your editor can know what the format of the files you're editing automatically
I'd really love to innovate in the tools department, if you couldn't tell already
Oh, and also creating a standalone solution for OnDemand/JAGGRAB and adding support for encryption into the protocols while still being backwards compatible with clients that don't support the encryption. E-Z