Rime: November Progress Report – Preparing and Automation

It’s been a wild few months, and I would like to thank all of the testers of Rime that have been reporting bugs, suggestions and usability problems.

One main issue that I have with Rime is the lack of automation. It had gotten an auto-updater quite awhile back, but it was very primitive and needs an overhaul so I can push updates faster to the testers and eventually the entire community. With this documentation is key for such a complicated and large project and before hand-generating the documentation or even using a tool like DoxyGen wasn’t exactly up-to-par. I’ve spent the last few days creating DokuGen which takes the C# assemblies and XML documentation and creates a DokuWiki format output so you can just drop it in your dokuwiki/data/pages/ directory and have it reflect instantly online!

The next issue which was brought to my attention is the auto-updater. Currently it does not track any release information, or modules that need to be removed. This caused an issue when I deployed a new version of Rime that would crash on startup because an external plugin was linked against an old version of Rime. This means that I will be working on Deeploy to handle this case.

The last issue that needs to be tackled for deployment is setting up a Windows VM in order to automatically build, create the deployment package (with Deeploy) and the wiki documentation (with DokuGen).

Another side-thing that needs to be worked on is getting native Havok Physics support in Rime. Near the completion of the map editor, I noticed that many things (walls, grounds, certain buildings) were all missing. This is due to how the game loads physics objects (destruction and otherwise) and they are in Havok Physics containers which need to be reverse engineered. I have started the process, but there is no estimation on when completion will be.

There have been many things done on the web side of things as well. I recently moved the website, forums, and wiki all to a different server fully supporting SSL/HTTPS. This step is an extra layer of security to protect the community. It may be overkill, but I rather be more cautious. I will be having a few different parties do pen-testing as well as people looking over the web-sided implementation for Rime to ensure there are no obvious bugs.

With all of this being said, I think it’d be nice to have a tease at what has been in store for Rime in the last few months. There are designs being done for a community “pool” for modding. You can create various teams, projects and collaboratively work together using Rime. You will not need an external place to share, sync, or create team based mods. The plans are still being laid out but it’s something I’m excited to be working on.

As with most blog updates, here is a simplified change-log of everything so far.

Additions:

Added launching of a engine’s version bindings by auto-searching for “_bindings” as an extension

Added support for Medal of Honor: Warfighter compressed ebx files

Added a Virtual File System browser and removed BundleBrowser

Added ResourceRef Ebx type for Battlefield 4 support.

Added Request/ResponseProjectManagerMessage to allow the project manager handle to be used from within plugins

Changing the way the BundleBackend handles requests for data. Implemented the non-existent paths of /bundles/_res_ /bundles/_ebx_ and /bundles/_chunk(s?)_ for parsing generic non-bundle specific requests.

Entire level loading process was re-implemented.

Removals:

Removed StreamingPartitionReader as it was incomplete and replaced by EbxReader

Removed LookupTable class as it was deprecated and not used

Removed RimeEvents as it was deprecated and not used

GenericContainer and GenericContainerValue were deprecated and removed