Author: kiwidog

Good news, Rime is becoming more and more functional every day that it gets worked on (busy with school primarily). The last month has been both productive and a ton of work has gone into the project. Here are some of the changes from the git history.

Implementations:

• Implemented “-cleanup” option for the auto-updater in order to clean up old files on next launch.

Additions:

• Added more editing abilities to the PartitionBrowserControl.
• Added logging of version on startup (the UI is currently broken and doesn’t show it)
• Added “Dashes” member to GUID in order to get the dashes format as well.
• Added checking of instances on CtrRef ToString in order to show “*null*” if the partition or instance is null. (may change to partition only)
• Also made it where if you double click on an CtrRef it will automatically open up a new editor with that instance loaded.

Bug Fixes:

• Fixed bug with the PluginManager in where multiple instances would be removed due to old-style name checks. This was resolved by properly removing that one instance.
• Fixed crash in the OutputPlugin due to the parameters being null.
• Fixed threading related crash on updating the UI when a new update was made available.
• Fixed crash in the logger when parameters were null.

Changes and Corrections:

• Corrected List DataTemplate, by changing the member type from TreeView to ItemsControl.
• Refactored update system.
• Major refactoring to allow plugins to load properly. Also disabled the Theme in order to properly see what is going on in the ebx editor.

Thanks to all of the testers we have, and special shoutouts to Powback for assisting with the documentation and preparation for the public build.

Hello there, I know it’s been awhile since I’ve updated this and a few people thought the project was dead (I don’t know why, but they did lol).  Here’s a quick update of what has happened over the last few months. Most of the work has been done by the other member of Venice Unleashed NoFaTe!

Fixes:

• Fixed a crash that would occur due to plugins without UI’s being added as UI elements.
• Fixed various threading issues and collection changed issues due to the asynchronous nature of Rime.
• Fixed a ton of issues dealing with the UI and how they interface with plugins.

Updates:

• Updated WebLink security (cross communication to modders link to prepare for the community)
• Updated the BinaryReader/Writer with more efficient versions.

Refactoring:

• Removal of a lot of deprecated, unused, commented out code.
• Deprecated all previous (semi-functional) mounting code (due to the new readers/virtual file system).
• Moved a TON of shared code (used between Lib/Rime itself) to the RimeCommon and restructured it.
• Moved a TON of Frostbite specific utilities and classes to RimeLib.
• Refactored the plugin system again (Will have to update the RimeExamplePlugin github soon).
• Refactored the handling for Frostbite Guid class.

Features:

• Added the ability to auto-start certain plugins on launch
• Added all available plugins to be launched from a menu if you are unsure how to launch them (only ones with UI).
• Added auto-detection of game builds and information.
• Added BuildInfoProxy for x86 and x64 versions of Frostbite to read out the engine’s build info natively.
• Added detection for Frostbite2014.4 (Star Wars Battlefront Alpha Trial).
• Implemented a new Virtual File System.
• Loading of patch files and patched superbundles completed.

Changes:

• Added Rime to a CI solution to prepare for testing builds for those who have already been selected for testing.

Sup,

Just a few updates. As read in my previous post, security is something I take very seriously as a developer, and I was going to allow plugins to run unrestricted until the beta. Luckily with enough debugging and trial and error, I finally got proper locked down sandboxed plugins that can be loaded from any directory! With that being said as well, I have resolved issues with the internal messaging structure for Rime as well as changed the way that plugins function. I also will be updating the example plugin git repository.

Fixes:

• Overhauled and fixed internal communication of all parts of Rime
• Fixed loading of plugins
• Implemented plugin security sandbox
• Cleanup of old code, refactored entire plugin system

Removals:

• Removal of SharpDX and all DirectX 11 related mesh rendering
• Removal of IPlugin interface.

Implementations:

• Moved all plugin logic and abstract classes to a common module (RimeCommon)
• Moved most message logic and listeners to a common module.
• Setup an OpenGL based renderer to replace SharpDX. Proof of concept finished.

Also I’m moving, so there may not be any work done until I find a place to live. Peace.

Hey,

There have been a few things that have been going on in the last few months. I just wanted to give everyone an update on the current status of Rime and the Venice Unleashed interop. First things first, plugin’s are hard, if you have checked the previous post on plugins and open source, I am making use of a plugin system for all external and internal plugins. That way you, the hobby modder can look at what we have to offer, and the functionality of it and be able to write your own code to interact with the Frostbite engine. That’s all fine and dandy, but I am a security-oriented coder. I have been working on for the last week a system to overlay the plugin interface’s to allow the code to be sandboxed, only allowing read/write access to the folder where the plugin resides. This will lessen the chance of someone writing a malicious plugin to steal sensitive information, or execute code that could potentially be harmful.

The way that I was going to get around these issues, is force the sandbox to run as lower-level privileges than Rime itself. (Even though Rime does not require to be ran as administrator, some people will anyway). That a malicious plugin writer won’t be able to gain privileges via Rime. And all of this is where the problem comes in, I have been debugging and researching the best approach to this in C#, and there just isn’t one (publicly at least). So I am making the decision to scrap the secure plugin system for the closed/open alpha of Rime until we get a functional system for the beta. With that being said, I highly recommend that any plugin creator open source their plugins so people can compile it from scratch. If you download a pre-built executable, use caution and only download from trustworthy people.

Fixes:

• Fixed incorrect TextureHeader structure
• Fixed DXT1-3 native C# processing.
• Fixed EBX reading code
• Entire application structure refactoring for prep for release (removing unused/old code etc, that’s why we have source control ain’t it?)
• Abstracted multiple classes to prepare for multi-game Frostbite support.

Broke:

• Internal communication of all parts of Rime. (Yeah… I fudged up bad)
• Plugins in their entirety (which means all the built-in editors for Rime have been disabled as well, Rime’s internals uses the same plugin system)
• DirectX 11 Mesh Renderer (Instead of using laggy WPF for everything)

Additions:

• Battlefield 4 Resource Types
• Proper loading of all game files and resources. (Just like how it gets done in-engine, no longer needs to decompile the entire map/game to mod resources)
• Retrieving encryption information, and real time modding via Venice Unleashed.

Hello all,

Just an update to give some progress on Rime, what’s determined to be the worlds greatest Frostbite tool other than DICE’s internal FrostEd. (endrant.)

There has been some confusion on when, or where Rime will be released. Currently the answers are both, “Soon”. But as a step forward to speed up development certain parts of Rime will be Open Source. This is the first open source project that I will be hosting and hopefully people will be contributing. Now back to that word “certain”… As it stands now, Rime itself will NOT be open sourced, that way there can be tight control over builds, coding style, and management. What is currently open source as of a few minutes ago is the Plugin System, and eventually the RimeLib will be open sourced.

The plugin system will allow anyone to write plugins to interact with new content, or just write better editors than the built in ones if you are so inclined. But the plugins will be called upon each time a certain style of content is requested to be opened. All of Rime’s internal editors, content loaders are all just built-in plugins, so the system has been tested so far as working. With the exception of IPlugin (which is included in the repository) you will not need ANY other source from Rime to get started writing awesome plugins. You have full reign over C# at this moment with plugins so you can load external files etc, just as you would any other C# application.

Now, what is this RimeLib? Well RimeLib is currently the native C# library that was designed to handle all of Frostbite’s various classes and formats. Pretty much RimeLib does all of the hard work for you, so you don’t have to worry about alignment, hex editors, or any of that. For example, loading a mesh into a nice C# class with formatting is only 1 line of code with RimeLib. The library is still in early development phases and has not undergone a huge re-write since it’s first inception in IceEditor Alpha, this will all need to change along with proper documentation for all of the classes and a separation between release and debug builds (release will only have FINALIZED and 100% confirmed structures, methods, classes; while debug has everything including experimental code). You will be able to find RimeLib’s source code sooner than later (Hopefully a few releases into Rime’s Closed Alpha testing).

What are you waiting for? Go check out the awesomeness of Open Source!