New modules as of 2023-10

[mgrzegor]

Hello taleden, this pull request is to update EDSY to support the latest additions to the game: the Azimuth pre-engineered Enhanced AX Multi-Cannons, the new Sub-surface Extraction Missile Launchers, and the Decorative Pink blueprint for Remote Release Flak Launchers (from a recent CG). With respect to the Sub-surface Extraction Missiles, I tried to pick a module ID that appears to fit your overall scheme of module IDs (not that the scheme is documented anywhere, it seems 😉). Also, I have no idea how to determine the fdid value of that module, or what it is actually used for.

As for the other changes I have made, see the full commit descriptions.

Best regards MG

[taleden]

Thanks for this patch! Just wanted to let you know I did see it come in and it's on my radar, I just haven't had time yet to go through it (and think about how best to integrate it with my local dev branch, which has some large changes I haven't been able to push and deploy yet).

I can give some quick feedback to your questions/comments though:

The module IDs (mid, or keys in the eddb.module dict) do indeed follow an undocumented internal pattern:

• the first of five digits (or implied 0) is roughly an area of the ship (hardpoints, utility, internal, optional) with some spanning a few digits
• the first two together are more or less an outfitting group as categorized in-game (i.e. all Cargo Racks, or all Multicannons)
• the third is the module rating (counting up from A=1)
• the fourth is the module class size (0-8)
• the fifth is a subtype; for weapons it's usually fixed/gimballed/turreted, missiles dumbfire/seeker, but for atypical categories like AX weapons it ends up being just whatever number is still available after the first four are set (and I've probably had to break that pattern once or twice too, when a category got too many variants with the same rating/class)

The fdid dates back to when we only had the CAPI endpoint to import in-game loadouts from; it's an FDev-defined internal numeric code for the module, but I'm not sure it's exposed anywhere else. Modern Journal-based imports use the fdname which is a similarly FDev-defined string token resembling the English name of the module. So for practical purposes it's not a big deal to be missing the fdid since imports will still work via Journal objects which is the most common route.

Apologies for my slow responses; if I haven't gotten back to this in another week or two feel free to ping me a reminder. :)

[mgrzegor]

Thanks for the reply! As you can see I’ve just pushed a fix to a bug I had made earlier 😅

Looks like I guessed most of the module ID scheme correctly. :) I actually considered giving the new fixed Sub-surface Extraction Missiles a mid of 81229, but that would break badly if turreted SSEMs were introduced, so instead I added 4 to the module class size — hardpoints cannot have a class larger than 4 anyway. [Edit: actually now I see I changed the wrong digit… correcting it right now 😅]

I considered hacking a bit more at the code (e.g. I’d like to enhance the experimental mode so it can be used to modify stats of modules with no blueprints at all), but if you’re making large changes locally then I will wait and see :)

[taleden]

I’d like to enhance the experimental mode so it can be used to modify stats of modules with no blueprints at all

This should already be possible, actually, at least in a limited fashion. With Experimental Mode enabled, even with (No Blueprint) on a module you should still be able to edit all of the attribute values that can ever be modified by any existing blueprints on that module.

I realize it'd be even nicer to be able to edit each and every attribute, but I made a tradeoff there in how EDSY encodes modified modules in the URL hash; each mtype of module is limited to a defined list of no more than 15 modifiable attributes (4 bits, including 0="nothing"). Expanding that list (and then actually setting modifiers on all those attributes) could greatly increase the total length of the URL hash for large ships with lots of modules having lots of total attributes, and those hashes are already close to long enough to cause problems in some browsers. So, for now, that limitation remains.

[mgrzegor]

I’d like to enhance the experimental mode so it can be used to modify stats of modules with no blueprints at all

This should already be possible, actually, at least in a limited fashion. With Experimental Mode enabled, even with (No Blueprint) on a module you should still be able to edit all of the attribute values that can ever be modified by any existing blueprints on that module.

Yes, but it if no blueprints exist then it is not possible. For example, before my patch, mtype = 'hexxc'did not even have a modifiable key, and even after the patch, only the enhanced gimballed ones are modifiable (because the noblueprints:{'*':1} in others prevents modifications even in experimental mode).

I realize it'd be even nicer to be able to edit each and every attribute, but I made a tradeoff there in how EDSY encodes modified modules in the URL hash; each mtype of module is limited to a defined list of no more than 15 modifiable attributes (4 bits, including 0="nothing").

I see. So without at least a partial redesign of the URL scheme, we’re stuck with at most 15 modifiable attributes per mtype… Still, it is enough to cover most of the attributes; most module types have far fewer than 15.

(As for any potential extension of the URL scheme, one that comes to my mind immediately is to use value 15 as an escape to attributes 15…30, encoded in the following nibble — I believe no module is close to having 30 independent attributes.)

[taleden]

Hi @mgrzegor ! I'm finally getting the next EDSY update ready which will include all these changes, however I've had to base it on some extensive local changes (to support localization) that weren't previously pushed to github for you to be able to fork from, and that created a lot of conflicts with your branch.

I'm hand-picking your edits to integrate them into my new base, so I'll eventually just close this PR rather than auto-merge it, but rest assured your contributions will be up on EDSY very soon. :)

edit: Nevermind all that below, it was already posted on the forum thread months ago and I just plain forgot. Sorry!

~There are three things that would help, though, if possible for you:~

1. ~Could you send me a screenshot of the in-game module attribute details of one of your Azimuth EAXMCs? There are two places to find them, and a shot of one is great but both is even better: when looking at it on your ship in outfitting, at the top center are two tabs "Module Stats" and "Modifications", and the latter shows the modified attributes along with the percentage modifications; also, while equipped, if you open the right-hand panel Modules tab, select the cannon, and then "Show Info ^", it gives attribute values with extra decimals.~
2. ~Could you remove and re-equip an Azimuth EAXMC, exit outfitting, and then look in your Journal file (${home}/Saved Games/Frontier Developments/Elite Dangerous/Journal.*.log, the most recently modified) for the last line including "event":"Loadout", which should give details of your loadout and modules including the EAXMC modifications?~
3. ~Could you send me your Loadout journal event snippet for the built-in "2A/F Grd Shard, LR+Foc, Pen"? One of your commit messages mentions it's been tested, so I'd love to have a copy to add to my collection. :)~

~Those would be great to have to confirm we've got the modifiers all correct.~

Thanks so much for your work on this! And apologies for my delay in getting around to it.

[taleden]

EDSY v3.8.17.1 is live now and includes all of your changes. Thanks again for your help! Let me know if I've missed anything, otherwise I'll go ahead and close this out.