Updated EFT format

[debessparre]

Hello,

I've been brainstorming in the 3rd party dev channel for the last couple weeks around an updated, standardized EFT format that's easier to parse, but remains backwards compatible. I am going around to various community projects gauging interest in making a switch tot his format, even if just offering it as an extra "export" option. I've tested my format against Pyfa's importer, and Pyfa imports a basic fit just fine. In order to improve compatibility, I do make changes to most of the Pyfa extensions, which I understand is annoying, but it leads to better compatibility with the parser in EVE.

Is there any interest in adding support for this, even if it starts as just an additional export option? If not, what would it take to make support something worth adding? I'd be happy to add at least export support myself to Pyfa.

https://github.com/debessparre/EFTH

[DarkFenX]

I think that sole reason for EFT format to exist is to provide user-readable interop. Anything which hurts it is a questionable addition.

A few notes on your spec:

• pyfa adopted EFT format pretty much as-is. IIRC, the only change was order of racks (H-M-L in pyfa vs L-M-H in EFT). Maybe some spacing changes (double blank lines between some sections). This includes the /OFFLINE tag, it was a thing EFT added. It was extended later to include abyssal modules, the format which pyfa uses is my "invention".
• i find single-line mutated module export harder to read
• i think adding more state info (like overheated tag) is unnecessary. Offline might be necessary because it affects CPU/PG, and it is natural for some modules to be togglable (e.g. ships might have to offline multispec shield hardener to get expanded probe launcher online), and upon fit import it might be not obvious what needs to be offlined for the fit to work

Parsing fits is somewhat complex and can be ambiguous at times (e.g. fighter section vs cargo which has fighters only), but is doable task, and in my experience I've never found a fit where pyfa's implementation failed me. So, the only reason to extend format with headers imo is simulation of extra cargo bays (which pyfa ignores partially deliberately - since ingame fits can't have that data - and partially out of laziness). If I were to add support for those, then I'd indeed have to extend format somehow. Unsure how I'd prefer to extend it, extra headers, or some kind of stackable separators with implied cargo order, or something else. That's not today's problem.

I don't mind someone implementing it in pyfa as an extra option to EFT format. Personally, I am busy getting nextgen fitting engine up to speed (https://github.com/DarkFenX/reefast) and then building something on top of it later.