* WIP: Grid export and plugin extraction
* Tweak export process
* Check for recursion of the same assembly load.
* Individual screens aren't always primary?
* Wait for cache to be writable
* Export selection only.
* Update built xml docs
* Ignore invalid archives.
* Need to ensure task is started.
* Expose core error logger to plugins and report custom criteria errors
Fixes#77
This adds an error logging method on the IObservatoryCore interface that writes the exception details to ObservatoryCore's central error log (found in `${Documents}/ObservatoryErrorLog.txt`). In addition, added a timestamp to each error log.
Also updates the Explorer to report Custom Criteria file load errors and execution errors to the log. Also updates HeraldNotifier to report CacheIndex.json parse failures to the error log as well.
* Expand debugging/error logging in Herald; cleanup empty mp3 files
Herald crashes if attempting to play 0-byte mp3s so if detected, delete, re-request (empty files can occur in some azure failure cases (ie. out of quota). Trap and log errors in other places in HeraldQueue to avoid hard crashes due to weird and wonderful unexpected stuff.
* Add speech rate setting
* Add volume slider
* New speech manager skeleton
* User API key from resx
* Implement voice list retrieve via new api
* Rewrite to use ObAPI, remove all dependancies
* Use volume setting
* Clean up using statements
* Volume and timing adjustments
* Lookup rate value
* Use numeric rates for tighter spread
* Manage plugin data folder via core interface
* Add check that nullable settings are not null.
* Get file size before it's deleted.
* Improve old settings migration.
* Ignore cache sizes below 1MB
* Re-index orphaned files in cache, purge legacy wav files.
* Call top level error logging for native voice exception.
* Async title and detail requests to remove pause
* Remove NetCoreAudio use of temp files.
* Remove orphan using.
Random occurrence triggered by a plugin's grid update. It's either fairly rare (related to something I was doing in-app) or new with a recent update to the plugin that caused it (just updated it last night).
Fixes Xjph/ObservatoryCore/67.
Tested via read-all and realtime while collecting a sample.
Required a bit of refactoring to use discrete classes for the main data structure vs. tuples. I think worked out nicely though.
* Fix file ordering assumptions which were broken by U11
With U11's new filename format for journal files, files don't sort right anymore and so the incorrect context was read during pre-reading, journals were read out-of-order during read-all or the wrong file was poked by JournalPoke for real-time. It seems that real-time still worked well enough (presumably the game client flushes journals semi reliably?)
Either way, ordering can be better guaranteed now.
* Update ObservatoryCore/LogMonitor.cs
Co-authored-by: Jonathan Miller <jmiller@xjph.net>
The order that listeners get notified isn't deterministic and as a result plugins which read the current state from PluginCore during the handling of a state change event may read a stale state resulting in unexpected results. PluginCore now reads a property directly from LogMonitor to avoid such inconsistencies.
* Add event-based LogMonitor state changes to better handle batch reads
Pre-reading hackily used read-all to suppress notifications. But that broke some assumptions about what read-all meant. Furthermore, the Core UI told plugins about read-all rather than the log monitor telling them -- which is really what should be telling them.
To address these concerns, LogMonitor now provides an event that both the PluginCore and PluginEventHandler listens to or tracking logging state allowing more granular information about the activities of LogMonitor, including distinguishing between ReadAll and Pre-read batches. Plugins no longer need to track if LogMonitor is in batch-read mode or not -- PluginCore now provides it.
I've also converted all built-in plugins to use the new event-based system. The old system is marked deprecated and will go away once other known contributed plugins have converted to the new system.
* Change LogMonitorState enum to [Flags], drop 'None' state
As requested, and did associated simplifications and cleanup that followed.
When first sample is taken, the notification is displayed showing what was sampled and number of samples taken. Number of samples taken is updated on the second sample. Notification is removed when the final sample is taken.
* Show notification with genetic sampling status while in progress
When first sample is taken, the notification is displayed showing what was sampled and number of samples taken. Number of samples taken is updated on the second sample. Notification is removed when the final sample is taken.
* Add setting and additional notification cleanup conditions
As requested:
- Added a setting to control the genetic sampler overlay.
- Added a few more conditions (FSDJump, LeaveBody, Shutdown) to clean up the notification.
Plugins authors can now optionally specify what ways their notifications are rendered (subject, of course, to user preferences/settings). The default is to render notifications in all available channels. Examples:
- Show native pop-up window only (ie. no voice/plugin notifiers)
- Disallow other plugin notifiers
This does not support selection of notifier plugins.
Furthermore, persistent notification updates were not previously being forwarded to anything but the native popup notifier. Now plugins and native voice are also supported (subject to user preferences) and respect the new rendering controls added here. There is currently no concept of closing notifications for the native voice or plugin-based notifiers.
System context pre-reading logic previously assumed the player jumped into the current system in their own ship as a pilot. Arriving docked on their carrier was thus missed and may have resulted in processing more than one systems worth of context (or simply failing to pre-read context).
Manipulating active notifications must be done on the Avalonia UI thread. UpdateNotification and CloseNotification were not properly doing this.
Any plugin attempting to use persistent notifications would have encountered these errors.
NOTE: There is not yet hooks for cleaning up persistent/infinite timeout notifications when the APP is closed.
