Added monitor state TypedDict definitions

[A-UNDERSCORE-D]

These don't actually change types or make anything more safe. What they
WILL do is make mypy and co complain loudly if we make mistakes.

Im looking for comments on this, as there are a few issues currently

For one, as it stands we None a lot of things that "will" exist always at runtime, which while we know are safe, the type checker cannot, thus a large number of errors appear.

There are two ways to fix this:

• do None checks everywhere (which is probably what we SHOULD do but given the shape of monitors interactions with this, will be messy and create a lot more confusing code)
• lie to the type checkers -- By telling them the real type of $thing, setting None anyway and telling them to ignore that we set None

Im not sure which to go with, but either way this will prevent typo issues in future and do some type checking.

[Athanasius]

I definitely like the general idea of this. I think I'll need to delve into the code for some of those Optional[None] to get a feel for how much work it would be to do the extra None checking.

[Athanasius]

This gets compared to the CAPI data ship->id so we'd need to be sure the CAPI never brainfarts and returns that.

Might be a wrinkle with EDO starting on foot in a new account ?

[A-UNDERSCORE-D]

Im using -1 as a default value, should be a decent enough sentinel I think. its ints on both sides otherwise (and if it wasnt we'd have issues anyway) -- comparisons looked fine where I checked them (searched the codebase for ShipID

[Athanasius]

The one thing about all my comments re: changing from None to '', 0, or other type-appropriate falsey value is that whilst we can be sure core code will work with it, we don't know what plugins are doing with the state values.

All it takes is one plugin dev doing if state['ShipName'] is not None or similar and we're obligated to bump our major version number if we make those changes.

I'm inclined to just do that.

[A-UNDERSCORE-D]

Something that I want to add, a heavy mode that checks types on monitor.state after each journal line, to ensure that things are okay

[Athanasius]

I assume this is the change of behaviour you mentioned on Discord.

Before this if CAPI says no suit loadouts we'll None our copy. With this, it won't.

So now the question is do we really distrust CAPI that much ? I'm inclined to allow this change as the Journal is in much better shape and we should always be picking things up properly from it now.

[A-UNDERSCORE-D]

yeah Im undecided here. The other option is to blank our loadouts and return?

[Athanasius]

Without checking the code that uses this, I am wondering if we can't default this to {} and lose the Optional. Same for SuitLoadoutCurrent below.

[A-UNDERSCORE-D]

specifically because the "default" cannot be {}, it must be a dict that matches SuitDict, so the minimum default is:

{
'name': '',
'locName': '',
'weaponrackId': 0,
'id': None,
'suitId': 0,
'mods': [],
}

which is not going to be falsy

[A-UNDERSCORE-D]

Something that I want to add, a heavy mode that checks types on monitor.state after each journal line, to ensure that things are okay

This isnt going to happen, the introspection required isnt there, half of the types will be strings

[A-UNDERSCORE-D]

This probably is going to wholly need a rewrite at this point.

[Rixxan]

@A-UNDERSCORE-D you mentioned above this will need a rewrite, should I close this PR at this point then?

[A-UNDERSCORE-D]

Likely yeah. It was intended to bring safety to the main loop, but we were changing a lot at the time so we left it. It may be salvageable in some places

[Athanasius]

It was kept around as easy reference for maybe completing the work at some point.

The issue it was designed to address is that the monitor state dictionary is just that, a dictionary, and as such it's all too easy to mis-type/capitalise a member of it and thus introduce a bug. We can't just wholesale change it to an object without huge impact on plugin developers, so this was an attempt at a way to move towards that whilst still supporting dictionary key access.