When the extension is updated, it can happen that chrome will disable the extension because the permissions have changed.
This is for the management API, it's needed to see if AGO is installed so that UniverseView doesn't conflict with it.
You need to manually enable UniverseView again, you can do this by following these 3 steps: (Google support)

On your browser, click menu

Select More tools > Extensions.

Search for "UniverseView Extension", check the box to turn it on.

The Firefox users will, again, have to wait a little bit.
As the add-on signing process & support for WebExtension is very slow.
I'm aiming at the beginning of February.

This is a major version update, the decision for this was because of the new database system.
The database is considered to be the core of UniverseView, so changing it means changing the way UniverseView works.
More technical information about the change can be found below.

It update also fixes one of the older/more annoying bugs in UniverseView, the slowing down of the galaxy when navigating through it.

The technology levels that you've saved from other players will also be reset, migrating the old database data was not possible.

Note: this is a technical explanation about the new database system. Knowledge about browsers might be a plus when reading it.

In previous versions of UniverseView it was possible to select different ways to fetch the planets of certain players.
The only option now is the new database system, the OGame API option has been removed.

The old database option was based on IDB, a database API for browsers.
Updating/expanding this database seemed to be a challenge, also getting an overview of the data/db structure isn't that convenient and I'm not a fan of the API design.

So I decided to go for another idea!
The new database system is based on a in-memory XML document, which is basically a DOM tree.
Now, why would anyone go for this weird solution and not use an available database API like IDB?
Well, getting data from the in-memory XML is 2 to 3 times faster, which, for me, is already a reason to change it.
The reason why it's faster is because browsers offer a fast way to select/create/update DOM trees.

Another advantage of this the parent/child relation in a DOM tree & attributes.
This allows me to store all the data for my extension together and not in seperate tables like with IDB.
Example:
The XML consists of "player" elements with several attributes like ID, name, alliance, technologie levels, ...
The players element contains planet elements as its childeren and these planet elements also have attributes like ID, name, ...
This way of structuring the data makes it easy for me to select certain data and get all the data in relation to an element.
Also for future use this is favourable, adding attributes/elements like found defences or buildings would be easy and without the need to change any existing data/structure.

But, every implementation also has its downsides.
For this XML solution it's saving the data to persistent storage as it's in-memory.
The in-memory part means that the updated data would disappear when you'd close your browser.
Luckily browsers offer something like local storage, this API enables me to periodically save the XML if any changes took place.
So this is something I had to implement myself, IDB takes care of this itself.

I hope this was useful and if you want more info about this, just let me know