AuroraMarvin, helper android for Aurora 4x C#

[TMaekler]

Is there a way for you to track how many MSPs have been used by individual ships in the field and how much maintenance ships in port have consumed? It also might be interesting to be able to see this per ship class... .

[skoormit]

Feature request: Hide low MSP warnings for craft that have 0 MSP by design.
(I design fighters without engineering spaces all the time.)

[Scnaeg (OP)]

Feature request: Hide low MSP warnings for craft that have 0 MSP by design.
(I design fighters without engineering spaces all the time.)

Good one, I'll check this on the weekend. Thanks!

[Migi]

If you're still willing to update this, would it be possible to have 'human readable' values for the graph X axis?
At the moment I think they are in seconds, if you divide by 31536000 (i.e. 60x60x24x365) you should get the value in years (or close enough, I don't know what Aurora does about leap years) which is much easier to understand.
I also find some of the colours quite difficult to see against the white background, specifically Boronide and Mercassium, and to a lesser extent Sorium. If you could make them a bit darker that would be great.

[Scnaeg (OP)]

If you're still willing to update this, would it be possible to have 'human readable' values for the graph X axis?
At the moment I think they are in seconds, if you divide by 31536000 (i.e. 60x60x24x365) you should get the value in years (or close enough, I don't know what Aurora does about leap years) which is much easier to understand.
I also find some of the colours quite difficult to see against the white background, specifically Boronide and Mercassium, and to a lesser extent Sorium. If you could make them a bit darker that would be great.

Unfortunately it took longer then expected. What about the colour and X axis values like in the attached picture?

[Scnaeg (OP)]

Feature request: Hide low MSP warnings for craft that have 0 MSP by design.
(I design fighters without engineering spaces all the time.)

Fixed, will be part of the next release. Thanks a lot for the report!

[Migi]

If you're still willing to update this, would it be possible to have 'human readable' values for the graph X axis?
At the moment I think they are in seconds, if you divide by 31536000 (i.e. 60x60x24x365) you should get the value in years (or close enough, I don't know what Aurora does about leap years) which is much easier to understand.
I also find some of the colours quite difficult to see against the white background, specifically Boronide and Mercassium, and to a lesser extent Sorium. If you could make them a bit darker that would be great.

Unfortunately it took longer then expected. What about the colour and X axis values like in the attached picture?

That's great, thanks!

[Scnaeg (OP)]

To be able to have proper dates on the resource graph X axis I did some refactoring how historical resource data is stored. This refactoring was already planed for the release with support for Aurora 4x 2.0 as already saved historical resource data will be lost. So update to the version only if you don't want to keep your resource graph data.

Changes:

• Prevent showing inactive ancient constrict multiple times in case system body has multiple populations
• Rework and deduplicate resource data. Resource data will no longer be kept in different tables. Also save resources for all races to be able to display graphs for all player races. Please note all saved resource data will be deleted.
• X axis of resource charts are labelled with a proper date instead of seconds since the game starts as requested by Migi
• Do not display MSP warnings for craft that have 0 MSP by design as reported by skoormit
• Another attempt to make charts colours more readable as requested by Migi

Download link: https://gitlab.com/Scnaeg/auroramarvin/-/jobs/artifacts/v1.99.0.1/download?job=build

Checksum:

Code: [Select]

SHA512 (artifacts.zip) = 963be57c4b907f46415fd376c8cf3aa8252bf86a3cd005bc295f55f89f5e68e388b3894413c85030711ba838aeaa58dcee7eb1afd027d854b306a6139880b4b2

Please make a backup of your AuroraMarvin.db prior to updating to this new version.

[Migi]

Thanks for the update, I'll have a think about whether the old mineral data is worth keeping.

[skoormit]

I just noticed that if I save my game twice without advancing time, Marvin records those data points twice in the database.
Which gives the graphs inaccurate peaks.

Not sure the best way to handle it.
Maybe check if a record with the same GameTime exists before inserting, and if so, update that record instead. Or delete the existing and insert the new one.

[Scnaeg (OP)]

I just noticed that if I save my game twice without advancing time, Marvin records those data points twice in the database.
Which gives the graphs inaccurate peaks.

Not sure the best way to handle it.
Maybe check if a record with the same GameTime exists before inserting, and if so, update that record instead. Or delete the existing and insert the new one.

Fixed, thanks for the report! I'll release a new version in a couple of minutes.

[Scnaeg (OP)]

A new preview release has been released:

Changes:

• Do not save duplicate resource data for identical timestamps as reported by skoormit

Download link: https://gitlab.com/Scnaeg/auroramarvin/-/jobs/artifacts/v1.99.0.2/download?job=build

Checksum:

Code: [Select]

SHA512 (artifacts.zip) = 4bcc2f917bc4b6faafc1e2438c1598e8c8ea25adc0bd20f97f5695cb2782a0e93e057e2b7b13dd761c382b7c464c951d5d0ad21a419ecdfd7f4bba380e3f2b72

Please make a backup of your AuroraMarvin.db prior to updating to this new version as this version tries to delete duplicate resource data.

[skoormit]

A new preview release has been released:

Changes:

• Do not save duplicate resource data for identical timestamps as reported by skoormit

Awesome! Looks like this did the trick!

Minor note:
After posting about the duplication, I noticed that it was happening every time I saved--not just when I saved twice with the same timestamp.
This version fixes the problem. By checking for duplicate timestamps, the second save is apparently averted.
I mention it just so that you are fully aware of the behavior.

Maybe it's a mechanical problem with how you are polling the db file for changes?
Maybe it's catching the change twice for each save, if Aurora takes a certain amount of time to complete the save?
At this point, though, it doesn't matter to the end user, since duplication is no longer occurring.

Thanks for the fix! (And for making this awesome tool in the first place.)

[Scnaeg (OP)]

Minor note:
After posting about the duplication, I noticed that it was happening every time I saved--not just when I saved twice with the same timestamp.
This version fixes the problem. By checking for duplicate timestamps, the second save is apparently averted.
I mention it just so that you are fully aware of the behavior.

Maybe it's a mechanical problem with how you are polling the db file for changes?

Marvin uses a FileSystemWatcher to detect changes of the AuroraDB.db and then reads the values into the Marvin database. While trying to reproduce the bug I founds several cases where the data could be read twice. So I added an UNIQUE INDEX over "GameID", "PopulationID", "GameTime" and "RaceID". So if already existing data is stored again it will generate an exception which is caught and silenced in the background but the data is not stored twice. Not the cleanest/best/textbook solution but is seems to work for now until I have time to introduce a proper check prior to saving the data.

Thank you very much for the report, much appreciated!

[skoormit]

...So I added an UNIQUE INDEX over "GameID", "PopulationID", "GameTime" and "RaceID". So if already existing data is stored again it will generate an exception which is caught and silenced in the background but the data is not stored twice. Not the cleanest/best/textbook solution but is seems to work for now until I have time to introduce a proper check prior to saving the data.

I can imagine a senior dev calling you out for using exceptions to handle normal-use code paths.

But I'm a pragmatist.
Why write another query and make another db call when you can just add a simple (and useful) index and add an empty catch block?

Possibly there's a relative db performance penalty when making a dupe insert (vs checking for dupe first), but at this program's scale we're talking about extra milliseconds (maybe).