Fixing the Bark/Trireme Damage/OoS Bug

You know how sometimes it takes a while for the gears in your head to turn before you finally have a big realisation? Yeah well, that happened to me yesterday.

The Fix

Putting this here at the top for the other 3 people who actually do modding:

For the Bark and Trireme, swap each unit’s own <PREQ0> with their <PREQ1> in unitrules.xml. In my tests this reliably fixes the bug in both first session and non-first session in all tested circumstances for local, workshop, data, and non-data files.

And now: storytime again.

Expanding scope

When I first published the original article about the bug, I hadn’t tested for every trigger, which I decided afterwards that I probably should sort of do. I wanted a more complete picture of what I could and couldn’t get away with before triggering the bug.

So initially I thought it was only data files that triggered it – turns out it’s any file at all which is auto-loaded. What does “auto-loaded” mean? Basically any file which the game specifically uses or requests.

So if you replace, say, the game’s logo on a menu, that file will be auto-loaded and trigger the bug. But if you just throw in a file called “ajkgh.txt” into its own mod called “flkjslfk”, then the game will list the mod, but not actually load its files (and therefore not trigger the bug). Buuut then if you tell the game to pull that file, it will be auto-loaded, even though it’s a custom file.

During this testing I thought, hey, maybe I should just doublecheck whether it affects Workshop mods, because it would be, ya’ know, really inconvenient if it turns out that a huge number of mods consistently trigger this bug.

The answer is yes. Even just replacing a .tga art file in a loaded Workshop mod will trigger the bug.

That sucked, but the best thing I could do about it was to just continue my modifications to CBP and CBP Launcher to work around the bug and load CBP as a direct-mod (and hopefully others could convert their mods too). At least, that’s what I thought at the time.

Are they really the same though?

In the original article I wrote:

Affects specifically the Bark and Trireme, and no other units, not even ones that share traits such as other Ancient Age (I) units

And while taking a brief pause from slightly-too-complex files-loading-code for CBP Launcher, the fact that I wrote this line got me thinking and a thought occurred to me… maybe there was a unique trait about the units, and I had just missed it before now.

I also mentioned that I had spent some time working on an automated damage modifier, uh, modifier, but had decided it would be faster to complete the process manually instead so I’d stopped development on it. Well, one of the few parts of Unshitfuckeryfier which was completed in that time is a function which looks through unitrules.xml and collects the names of all the units and their <PREQ0>.1

Highlighted are some examples of units that don’t have an Age as their PREQ0.

Part of the unfinished part was creating a list of edge cases units which didn’t have an Age as their <PREQ0>, but did have something other than “none” for it. Citizens, for example, have “none” as their PREQ0, but Spies and Generals actually have Mathematics (Science 2) as their PREQ0.2

I won’t bore you with the full details of why this was needed, but there were a few cases where a unit had an unexpected PREQ0, so for each of these I went and manually verified that the data I was pulling was correct (and also had that “huh, now that’s mildly interesting” moment a few times). And I think doing this manual verification got me to recognise some patterns that were later the seed I needed to grow the thought that something was off about the properties of Barks and Triremes.

Notice a couple of the CtW generals which oddly *did* have an Age PREQ0, so had to be removed from this exception list.

Anyway, in short I decided mid-launcher-coding to go back and look through the game files one more time to see if I could notice anything unusual about the properties of the Bark and Trireme which I had missed before. For some reason the fact that the bug triggered on Workshop mods felt just slightly too bizarre. As if there had to be something more to it.

What I noticed was that the Bark and Trireme seem to have one unique trait: they have a PREQ1 but no PREQ0.3 I haven’t done a regex match to definitely-confirm this, but as someone reasonably familiar with the entire list of units and their properties, I’m like 80% sure they’re the only units in the list that have this combination.

So what if I swapped them?

What if I made sure that their only prerequisite was assigned to PREQ0 instead of PREQ1?

I did it.

I tested it.

It works.

It completely4 fixes the bug. Local mods can use art files, data files, and whatever else, and so can Workshop mods. First game and non-first games are the same. Dromons beat Barks in 1v1s, but never by a landslide. I had climbed the mountain and slain the dragon.

Why is it this way? Why does the bug exist? Why Modern A-

Stop. I don’t know. And at this point I’m not sure I really care. I got into this to just play some RoN without drowning in stupid fucking bullshit bugs. And now I’ve spent more time fixing bugs and making a replacement for the buggy mod distribution and loading/unloading system than playing actually the game. Go find the rest of the answers yourself ;~;

A twist too far

The timing of discovering the fix is approximately the worst possible, as I have at this point spent roughly 100 hours creating and testing the workaround for the bug under the assumption that there was no true fix available to us mere mortals without source code access (and without the SRE competence to make do without). The format conversion for CBP was like 80% completed when I found this fix.

CBP Launcher is in shambles, with the majority of its file-loading code converted to handle the direct-mod format instead of the local-mod format.

So now I have to spend even more time undoing almost all I’ve what I just did in order to de-convert things back to the local-mod format. I have persevered through many twists and turns on the CBP development / RoN modding journey, with many times there being asinine roadblocks like this slowing things down.

This one was one twist too many — and it broke me.

The majority of the hour after discovering the fix was spent restlessly pacing back and forth going through in my head a list of all the things I have to change in light of the bugfix (and weighing the option of even just not using the bugfix at all, because it might actually be less work at this point). It would be fair to say that right now I’m utterly exhausted of dealing with all of RoN’s bullshit.

So I’m going to take a break from CBP development for a bit and catch up on some of that rec time that I’ve been sacrificing to get CBP Alpha 7 done.

Expect the next pre-release of CBP to have RoN’s most absurd bug removed. If you’re willing to help contribute to testing it out, please do so. The discovery of as-of-yet undiscovered bugs is now the largest remaining bottleneck before full release, and the more people-that-aren’t-me checking for them, the faster we’ll be ready for full release. In reality undoing the mod format conversion isn’t unmanageably difficult, and should only take a few days tops — I just can’t bear the sight of any more carbs right now.

Don’t peer into the spaghetti vortex for too long or you’ll end up like me. I’m in too deep. I stared for too long. And you know what I saw? The spaghetti vortex — it stared back. (Spaghetti by Kulsum Siddique via Unsplash)

 


 

  1. (primary prerequisite – usually an age)
  2. Very few units have a PREQ0 that isn’t either an Age or “none”.
  3. i.e. “none” for their PREQ0
  4. about as much as one can hope for without source code access

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept the Privacy Policy

This site uses Akismet to reduce spam. Learn how your comment data is processed.