Update 4.0.0
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.
Changelog:
Thanks for using UniverseView and if you have any feedback don't hesitate to share it
Database change information
Greetz,
War
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.
Changelog:
- New => Replaced the old database system with a new system
- New => Added the TrashSim & OGotcha buttons to shared & favoured espionage messages/combat reports
- Fixed => Galaxy bug, everything went significantly slower after a while when going through the galaxy
- Fixed => Technology levels didn't get saved when a player enabled images in the espionage reports
- Fixed => It was not possible to delete the first coordinates in the favourite list
- Polishing => Removed the OGame API option for getting a players his planets
- Polishing => Refactored and updated a large portion of the codebase
- Polishing => Updated the menu, now you should be able to get a better overview of the possible features
- Polishing => The database now updates itself without ask for the user to update it
- Polishing => It's now possible to disable these features:
- Quick loot/raid links in the espionage reports
- Showing the ranks of players & alliances in the galaxy
- Showing the debris amount instead of the debris icon
- Quick loot/raid links in the espionage reports
Thanks for using UniverseView and if you have any feedback don't hesitate to share it
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
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
Greetz,
War