Implement per-name effect associations for customizability/third-party support

[Ilysen]

purpose

due to the way it's set up, the module doesn't really account for third-party content in a clean way. big popular third-party supplements like Field Guide to Suldan can have many different features, and setting up a macro for each individual one could be a lot of overhead to manage, especially for custom stuff that multiple PCs have. we certainly can't account for the infinite breadth of possible homebrews, but we can make it easier to extend!

details

this modifies the module's system to first attempt to find an appropriate effect macro by searching using a feature's Foundry name; only if it doesn't find anything will it use the item's ID instead. users can manually edit weaponEffects.js (in a specially designated section for cleanliness) to add effect associations by simply using the name of the feature and the associated effect they want. for instance, if I had my gun Big Gun and I wanted to give it the LHAC effect, adding it would be as simple as:

    "Big Gun": "Leviathan",

there are a few main use cases for this:

• accounting for third-party content that many players might have at once without having to manage a macro for every feature/weapon
• accounting for items made in Foundry directly (i.e. not from an lcp/compendium), whose IDs can be a bit painstaking to get
• character-specific overrides on their weapons

---

key back-end changes:

• weaponIdentifier variable can now be an Object reference as well as a string
• revamped macro selection: weaponIdentifier is first checked if it's an Object: if so, it checks weaponIdentifier.system.name for name-specific entries, and if that fails, it checks weaponIdentifier.system.lid (mirroring the existing functionality)
  • if it isn't an object, it searches weaponEffects[weaponIdentifier] directly, since if it's not an Object then it must be a string. we do this to maintain functionality for itemless effects such as stabilizing and tech attacks, which pass a relevant effect ID directly

my javascript knowledge is sorely lacking and this is, as far as I can tell, some of my first work with it in an open source project. it might be pretty messy -- please feel free to let me know what problems there with the code or with the approach itself. I think it'd be ideal to have this doable from in-game through a settings menu, but this is unfortunately currently beyond my skillset to pull off

[Ilysen]

fairly sure I can't get a PR name for this that I'm happy with, but ah well. blaugh

[Z3nner]

I'm deferring to dodgepong on this, but I think my preference, if we went in this direction, would be a method that persists for the user. Like, the module looks for a file or folder containing the custom assignments outside of the module folder.

[dodgepong]

My ideal solution:

• Save weapon macro assignments to settings instead of referencing the file every time
• Use the file to seed animations into the settings on first load
• Add a button to the title bar of each Item that opens a UI that lets the user select which animation plays when that Item is fired (similar to AA's UI button)
• Include a set of heuristics to auto-assign animations that don't have an explicit mapping (based on weapon type, mount, range, and name, in some combination)

I don't want perfect to be the enemy of good here, so at the very least, I can support the idea of including a search for animations by item name (which eventually would be part of the heuristic search).

To that end, I think this PR could be simplified by completely removing weaponIdentifier from MessageInfo and just relying on weaponObject to fetch the lid when we need it in the createChatMessage hook. At some point, it will probably be worth it to extract the macro fetching logic into its own function, but we can leave it as-is for now.

[Ilysen]

aaaalright. still not super familiar with js, so let me know if it's bad code here. the new back-end changes are as follows:

• weaponIdentifier variable can now be an Object reference as well as a string
• revamped macro selection: weaponIdentifier is first checked if it's an Object: if so, it checks weaponIdentifier.system.name for name-specific entries, and if that fails, it checks weaponIdentifier.system.lid (mirroring the existing functionality)
  • if it isn't an object, it searches weaponEffects[weaponIdentifier] directly, since if it's not an Object then it must be a string. we do this to maintain functionality for itemless effects such as stabilizing and tech attacks, which pass a relevant effect ID directly

since merging the two here means there's no need for a new variable, I kept the name weaponIdentifier for cleanliness reasons. as always, I'm open to correction (perhaps significantly) and also variable semantics -- I could see it making sense to keep this new iteration named as weaponObject, for instance, but it's definitely up to y'all

I do definitely want to have a user-persistent method at some point. I might try to work on that in future. my javascript skills are, really lacking right now, though, so I'm not sure I could pull off the ideal solution even though I'd like to. need more practice

[Z3nner]

I'm not in favor of this method of implementation and the v11 upgrade has rendered most of it out of date. I'd love to add customization, but I have a requirement that the user's work must not be entirely overwritten if the module updates.

[Ilysen]

right! if I get back to cracking on this I'll see what I can do.