Chained Echoes ultrawide and wider solution

As you know, I was already familiar with Unity and had done a lot of research into it, some of which was carried over to third-party solutions via the authors having examined my patchers.

And yet my usual way of pure assembly was not really good for interacting with the game components or their instances in real time. Even modifying the game code in C# could go only as far as modifying it before runtime.

Seeing the more nuanced approaches by PhantomGamers and Lyall made this even clearer.

I knew and expressed that for a while, even personally to them, but for me to do the same would mean spending countless hours on coding rather than disassembling and understanding a game.

Dealing with an increased number of Unity games and not being able to address some of the seemingly small issues, like the always-on prompt in Tunic, was presenting itself is a letdown more and more often.

The turning point happened to be Chained Echoes after a request for a fix. The two users who asked in the thread said that they had no success via the usual approaches, so I had to take a look.

Indeed, the game was nothing like the others, with not just one but three functions keeping it pillarboxed. One was the hardcoded resolution, another was a view constraint function and then the last was its placing of texture-like elements. Each instance was from the game's native code rather than a more generic engine call, so it had to be tackled individually and uniquely.

After a while on it, I could manipulate those things in real time but had no way to make it into a fix I could distribute. For nearly a week of full days with barely any distractions or rest, I wrote code and ran the game countless times to test out the changes. Most of those days were also spent on dealing with the UI. You know how I say it's the worst thing to fix?

Although the game had proper UI scaling powered by the engine, many of its elements did not scale to width at all. There were also animated elements that would slide into the view when necessary, then be moved to the space covered by the pillarboxing rather than becoming deactivated, invisible or further away.

For much of those days, I had to come up with and test solutions to each of those elements, which felt like remaking the game. In this game I saw no grouping of the elements, so it was the only way.

So how do you solve the issue? You look for a function specific to each element and then use it as a condition to recalculate the placement of the element.

The calculation itself took some time to come up with, as it was anything but trivial in connection to the elements on the screen.

As it stands, here is a list of the additional functions I had to write for the solution:

- Resolution fix
- Texture-like pillarboxing removal
- Axis constraint fix
- Party states information UI fix
- Battle escape UI fix
- Character switch UI fix
- Craft menu UI fix
- Skills in battle UI fix
- Party info UI fix
- Skill upgrades menu UI fix
- Stats at the main menu UI fix

The bottom line is very important though. If I were to rate my level of knowledge of Unity and interfacing with it 4 or 5 before, it would definitely be above 8 now. I now have an easier way of finding the components responsible for behaviors and I can write solutions that deal with specific elements, no matter how minor. It's possible that, once again, I will be able to rely less on making trainers and more on the handcrafting. For the user, as with the typical DLL injections, this means simply dragging and dropping a bunch of files in the game folder, which should make things easier too.