Depending on how you classify things, there are three or four different forms for RoN mods:
- Workshop mods
- Local mods
- Direct mods
- Dropdown mods (which can be Workshop or Local mods, but not Direct mods)
While pursuing improvements for CBP Alpha 7, I’ve explored many ideas to improve the usability of the mod. In doing so, I got this close to creating another mod format that would’ve combined the stability advantages of Direct mods with the file separation that Local mods have, and the distribution and ease-of-use benefits that Workshop mods have.1 Here’s what went wrong.
They all suck
First, a brief recap of why each of the current formats suck:
Workshop mods are extremely fussy about how they work, I guess just because they’ve been poorly implemented in RoN:EE. In short, if you modify certain files they aren’t loaded or unloaded correctly by the mod manager, making the mod essentially unusably unreliable. Relatively easy to distribute and update though, and they can even be distributed in game lobbies if they’re lobby-selectable mods (like Dropdown mods).
Local mods resolve the issue of unreliability that Workshop mods have, and you can therefore change any file and never worry if it will be loaded. They are extremely strict about changes to these files though, which is a problem because RoN actually modifies some of its core data files on the fly, instead of using separate files for everything. For example, when you use Dropdown mods, help.xml makes note of the mods you have available – so if you use help.xml in a Local mod the game will OoS2 if one player has Dropdown mods available (even if they’re not using them!).
They’re also much less convenient compared to Workshop mods, since they’re more difficult to both distribute (with correct installation) and update.
Direct mods are the most robust, having the same reliability advantages of Local mod files, but with a lot more leeway over whether files are allowed to be modified without causing OoS issues (although it still gets upset if you want to change the title animations, for example, even though those should have no bearing on multiplayer gameplay sync).
Of course, directly modifying game files comes at the cost of exactly that; if the game files are ever updated (such as if verifying game files via Steam) you lose all the modified files. Mods which change the same files also can’t co-exist, requiring even more work on the user’s part to load/unload everything whenever they want to swap mods.
Dropdown mods, as mentioned, can be a subset of either Local or Workshop mods. They are essentially minor variants of each of those, just using an info.xml file to tell the game that it’s a Dropdown mod, some basic info (e.g. author), and what files to load/unload when a game is being loaded with the mod selected. They’re named this because you select them from the dropdown menu.
These have substantial advantages in theory, but in multiplayer they are approximately as stable as a clown riding a unicycle on a tightrope. It’s not too bad in 1v1 games, but instability seems to balloon as each additional player is added into the mix; in our testing during CBP Alpha 2-6, our success rate on 2v2 (4 player) lobbies was a rounding error above 0%.3
In one control test, a Dropdown mod with no files at all other than its info.xml file was tested to isolate what files were causing the problem. I couldn’t help but laugh in dismay when we found out it was just as unstable; the main problem wasn’t the modded files, it was the mod format itself. RoN:EE v1.10 isn’t quite as bad with this, but still isn’t flawlessly stable with dropdown mods (and would require accepting other issues with using v1.10).
A new approach
One thing I’ve been doing as sort of the basis of FoN (and then porting to everywhere else, like CBP) is understanding how all the parts of RoN work. I’m at a point where I have the gist of most of it,4 plausibly more than anyone I know of except for Vugi and maybe motter and a few other “old school” modders.5 For CBP, this means I can sometimes offer novel ideas to circumvent accepted limitations with RoN modding, as well as obviously do more mundane things like discover that over 20,000 damage modifiers are bugged in EE. You know, small things like that.
riseofnations.exe (v1.20) and rise.exe (v1.10 and earlier, including pre-EE I think) are hardcoded to access internal_strings.xml, which contains a list of all the data files (and other things) to load such as rules.xml and help.xml. Through the wonders of reverse engineering, it’s possible to patch6 the game exe to tell it to load a different file instead.
The new file has to have the same format (unless you’re a l33t h4x0r and actually extremely competent at reverse engineering, unlike me), but it means you can list different versions of any core game files you want to change. This means you get essentially all the benefits of direct mods, but with none of the file-conflict problems. You can have two (or more) sets of game files living in parallel. By combining this with an external mod manager (which is what CBP Launcher is on its way to doing as of when this was written), you can essentially have your cake and eat it too.
You might be thinking that it was just theory, and that that was why this is an article documenting the new format being theoretical only. Thing is: it does work. I have, multiple times, used a patched exe to load a modified internal_strings.xml to redirect to modified core data files, all while leaving the originals completely alone. And you can play the game completely normally, including even loading mods on top of the already-modded files if you wanted to. This was why I was initially so jazzed+optimistic about the new format.
The reason I abandoned it is because it has a 100% OoS rate in multiplayer games, even with every combination of settings and file changes and patches that I tested. So it’s the same clown riding a unicycle on a tightrope, but now we’re throwing in an earthquake and gale-force winds too for good measure. At least now Dropdown mods can officially say they are not the least stable multiplayer mod format available.
The cause
I don’t know.
I can speculate on the two possible reasons that seem plausible to me though:
internal_strings.xmlmaintains hashes for each of the files it lists to load (that part isn’t speculation). It’s possible that you would need to provide a new hash for modified files that uses the same hashing algorithm when you tell it load different files. One issue with this explanation is why Direct mods are possible at all if file hashes must match to load files (and if there are simply exceptions to which files must match, why could I never find any files that could be used in multiplayer without OoS issues?).riseofnations.exe/rise.exehas some record of itself (such as a hash) and (whether intentionally or as a side effect of some other function) will not allow any modifications to itself to sync in multiplayer games. For the record my patches did not alter the binary length, so it seems quite strange that two identically-patched exe with identically-modified files couldn’t sync with one another. In support of this idea, a patched commerce-cap exe (and no other OoS-ing changes) also causes OoS issues in multiplayer.
I very much doubt it’s a Steam-related issue (there appears to be very little integration of Steam DRM), but I suppose there’s a sliver of possibility that that could be the cause as well.
Another possibility is that I’m on the right track but made some kind of mistake which I didn’t notice across dozens of tests and multiple do-overs.
What now?
Well, I’ve already abandoned using the new format for CBP, at least for the foreseeable future. So for now it joins the pile of indefinitely shelved ideas.
I do dig up things from that pile sometimes so this isn’t a straight up death sentence, but I usually wait for a new idea or approach when the reason something is in the pile is “not sure what to do next”.
To get the format usable would require investigating what actually causes the OoS, probably either by digging through an enormous amount of game logs or by doing another deep dive into the exe with reverse engineering. Both options are simultaneously pretty tedious yet complex (the worst combination of interesting vs attention required) and extremely time-consuming. In other words.. there’s a good chance this one won’t make it out of the pile without a breakthrough. So probably RIP new mod format outside of singleplayer usage. I didn’t even get the chance to give the format a name, but I’m open to suggestions.
- Although technically this would be achieved by nature of using a custom mod manager, not so much the mod format itself as such.
- Out of Sync
- With success defined as all players successfully loading in. It was common to get ~2 players in.
- It referring more to anything that we’d want to mod, not necessarily a lot of other things which we don’t really care about.
- Plus like, some of the devs and such, probably.
- I’m using this term to describe both patching on disk and patching in memory, since they’re equivalent for our purposes here