Update on AO2 development

Hi,

I know some of you have been wondering where the work has been going for the last five months. I’ve been hit pretty hard by school, and things are not going to improve next semester, although I do have a somewhat brief period of rest this summer (despite being occupied by a job - and that says something about how stressful things might get next semester).

Since I am basically the project’s lone developer, I needed to spread development across numerous parts.

January

I started a major refactoring operation on the AO2 client. The reason is that the client code is a complete mess, preventing any substantial feature additions that do not involve carefully placing new code without stepping on a tangle of existing code.

February

I consolidated my to-do list with a dependency graph of tasks needed to release a specific version. To hasten release times, I wrote a continuous integration pipeline, which basically automated builds that can then be automatically published and pushed to the launcher.

I still have not placed the launcher on the website, though, and while I had finished 2.6.1 in February, I had never released it due to a plan to bundle 2.6.1 with the launcher.

March

No real work was done.

April

I decided to check in Vanilla to version control so that I could safely make changes and revert them if they went awry. It, too, has a CI pipeline that automatically pushes new updates to the launcher.

image

Due to various incidents in the Official Unofficial Vanilla Server, I switched gears and decided to work on tsuserver3, otherwise known as “the dumpster fire” by nobody except myself. A major refactoring was done, and all bans and logs were moved to a SQLite database. Server commands can also be hot-reloaded without restarting the server. However, evidence has not been fixed in this branch yet.

May

I continued work on extinguishing the dumpster fire and switched back to refactoring and redesigning the client.

image
image

The UI can be modified using Qt Designer. It’s quick, easy, powerful, and does not require trial and error, so you can still make your own themes.

Future

You may have noticed that I have made little mention of webAO. The reason for this is that it is very difficult to coordinate protocol changes between the desktop client, the server, and webAO. I know that many of you use webAO, but it is really stretching me!

A question you might have is why not make webAO as the primary desktop client, and then focus future development on webAO. The reason is mainly technical: the browser does not make guarantees about the timing of events. This means that animations may load too late or play long enough for them to loop when they should not loop. In contrast, a native version is smooth and allows for more powerful features that cannot be done in the browser. However, I must concede that the browser makes for a good target, despite these limitations.

What I will probably do in the immediate future (in some order) is the following:

  • Release 2.6.1.
  • Publish the launcher on the website.
  • Release the new version of tsuserver. :white_check_mark:
  • Finish the refactoring branch to bring AO2 in the home stretch.

That’s good, would’ve helped a lot when adjusting/fixing certain commands.

Definitely sounds easier than it is now, but how would that work with current themes? Like, would they need to be remade after this?

Unfortunately, yes. Current themes use absolute positioning and all operate on the same widget. However, I decided to split the UI up into multiple widgets to modularize the code, which would make automatic conversion very difficult. I am removing all of that old theme code.

Seems reasonable.

I don’t think it’ll be that big a problem switching over, just re-creating the old themes with the designer should be doable.
And I’m assuming you’d still be able to switch between multiple themes.
I’m wondering about a minor thing though, would you still be able to adjust colours for the OOC chat?

Yes. Most widgets can be customized with a subset of CSS.