Another error with the -o parameter of EDMC.exe getting exitcode 1

[Eventure-TCE]

We have another error with the -o parameter of EDMC.exe (v5.10.3), please take a look:
2024-04-13 21:11:29.827 UTC - DEBUG - 13888:21080:21080 EDMC.main:407: Writing Station Outfitting in CSV format to "C:\Users\xxxxx\AppData\Local\Temp\test.csv"
2024-04-13 21:11:29.829 UTC - ERROR - 13888:21080:21080 EDMC.main:493: "other" exception
Traceback (most recent call last):
File "EDMC.py", line 408, in main
File "outfitting.pyc", line 284, in export
File "outfitting.pyc", line 189, in lookup
KeyError: ('hyperdrive', 'class3')

[Athanasius]

Any context on this? I immediately wonder if something about the new SCO FSDs is causing issues, even if only due to FDevIDs only having partial data on them or somesuch ?

[Eventure-TCE]

TCE does a pre-start test with EDMC.exe to see whether the exit code is 0 and therefore everything is OK with EDMC.

Rixxan found a problem in the 5.10.2 version, which probably crashed the outfitting system regarding armor.

Here is his comment in the changelog:
Fixed a bug that crashed the outfitting system when encountering armor.

To test this, I run this command:
EDMC.exe --loglevel DEBUG -o %TEMP%\test.csv

[Rixxan]

My guess is that this is due to the new additions of the SCO FSDs. If I remember correctly this error is because someone's journal is telling EDMC it has a thing that EDMC doesn't know exists. I'll need to test this when I get off work today, if so it's an easy fix so long as FDEV ID's are updated. *KeyError: ('hyperdrive', 'class3')* as described looks weird. I don't believe I've ever seen that as an item before. Message ID: ***@***.***>

…

[Athanasius]

I think it would be worth at least adding a python EDMC.py ... unit test, assuming the same sort of error would show up outside of the windows 'compiled' version. Having a test as part of the GitHub windows build might also be an idea.

[Rixxan]

Seems to be confirmed. Check https://github.com/EDCD/FDevIDs/pull/88/files. As soon as that's pulled in to the FDEVIDs submodule, we should be able to push a patch update to EDMC. I'm not sure we can really do much in the way of pre-testing for this, as EDMC is processing things as intended - it is handed a name it doesn't know what to do with, and it kicks back to the requesting program saying it's unprocessable. As we're reliant on community sourcing the FDEVID content files (as in, we're not getting them from Frontier before they go live) there's always going to be a lag time between new modules/items being created and them being reflected in third party tools. Call it the early adopter tax. Probably could change how we respond to these type of errors, but that's a different question. So by rule this technically isn't an EDMC problem, nor is it a TCE problem, its simply a dependency update that needs to work its way through the systems.

[Eventure-TCE]

Yes, Frontier has always been bad at providing news to developers in advance over the years. It was always necessary to keep up with the changes and catch problems after the releases.

[Rixxan]

Update, it's not fully FDEVIDs we're waiting on! There's some places this is tracked that throw these things. Thank god for ShinDez!

Working on a PR will push it tomorrow after work.