Avoid losing super energy when swapping in-game loadouts

[DHager]

Proposed change

I'm willing to try my hand at a PR for this, but I'd like to get buy-in on the concept first.

The ultimate purpose of this change is to minimize cases where an aspect/fragment socket is modified and the player loses all their super/ability-energy as a gameplay penalty. This also includes indirect triggering when a user picks an in-game loadout modeled on a DIM loadout.

Requirements

• When applying a DIM loadout to the character, continue to avoid changing subclass aspect/fragment sockets unless absolutely necessary. [I believe that was implemented by Loadout Subclass Aspects+Fragments improvements #8750.]
• Desired subclass aspects/fragments should be consistently sorted among the sockets, regardless of what actions the user took to select/deselect them, enforced when:
  • The user clicks Save Changes or Save as New on a loadout
  • A draft loadout is created via Create Loadout from the current character state
  • The Sync from Equipped command is used for the Subclass section
  • The Loadout Optimizer's Compare Loadout drawer is being used to either Save As onto an existing named loadout.
• When exporting a DIM loadout to an in-game loadout with Save As In-Game Loadout ensure that the DIM ordering is imposed.

Out of scope

• A UI option to force canonical order when doing general "click an already-saved loadout to apply it" flow. This would only be important if a user was casually applying a DIM loadout to a character with the intent to save the character-state as an in-game loadout using in-game controls. (As opposed to a similar outcome from Save As In-Game Loadout.)
  • For this rare user, it would be best to convince them to use Save As In-Game Loadout instead.
  • If they really need a workaround, manually empty all the elemental subclass' sockets before click-applying the loadout in DIM.

How does this fit into your workflow?

Imagine that a player is doing some tougher PVE activities and designs two similar loadouts so they can quickly toggle things in reaction to changing circumstances. (Often either weapon-choice or exotic armor usage or both.) For example:

• Hunter Golden-Gun with Celestial Nighthawk, for extra damage when about to fire the super.
• Hunter Golden-Gun with Lucky Pants, for when the super is not ready to use.

There are multiple ways these DIM loadouts can become saved as in-game loadouts, however if the aspects/fragments are not identical between both in-game loadouts, then switching to first one will erase all the super energy the user just intended to use. Uh oh!

With this change, that kind of problem won't happen due to otherwise-unimportant ordering of subclass socket contents.

Potential issues

Some players may already be micromanaging the precise order of their fragments, so that ones at the tail at "less important", in order to minimize the impact of if slots at the tail-end are disabled when changing aspects in-game. This behavior may interfere with their workflow. That said, I don't expect a big overlap between this behavior and users of DIM loadouts.

[bhollis]

Linking #9469

[robojumper]

Just going to note one thing:

• When exporting a DIM loadout to an in-game loadout, ensure the in-game loadout should also be set to the same canonical order

Out of scope

• A mechanism to override Loadout Subclass Aspects+Fragments improvements #8750 behavior so that the canonical order forced. This would only be important if someone were to apply a DIM loadout and then use the current state of the character to write an in-game loadout. A workaround is to manually blank all the character's aspects/fragments for that subclass first.

These are essentially conflicting requirements because the only way to export a DIM Loadout to an in-game loadout is equipping that loadout first, so at least implementation-wise this override mechanism would be needed.

[DHager]

@robojumper Just to restate things so make sure I understand, you mean that the workflow Character Emblem > Manage Loadouts > Save As In-Game Loadout is (on a Bungie API level) doing the same process as generally applying a DIM loadout to a character, plus a command like "Exact current character state to in-game loadout".

[robojumper]

The only in-game-loadout-creating operation Bungie.net allows is "snapshot the current equipment to an in-game loadout", and DIM currently only allows saving the currently equipped loadout to an in-game loadout - the "Save as In-Game Loadout" button doesn't exist for DIM Loadouts and adding a workflow for those is tracked by #9469, which bhollis linked.

[DHager]

OK, so it's really two different settings for the same basic process, depending on what we believe about the intent:

1. Avoid unnecessary subclass socket changes, so that changes are faster and to possibly avoid an immediate ability-reset penalty.
2. Sync the exact permutation even if it causes a ability-reset now, so that future use of in-game loadouts won't trigger penalties.

[bhollis]

If I can rephrase this:

When transferring a DIM loadout to an in-game loadout #9469 and only then, we should sort subclass aspects and fragments in a predictable way so that the in-game snapshot is consistent across loadouts.

There would be no user-visible option, this is a background optimization for avoiding losing super energy between loadouts.

All that said, I'm not sure how useful this would be since users can still directly save loadouts as in-game loadouts (either through the in-game UI or by snapshotting their equipped laodout in DIM) with abilities/fragments in any order. In that case, if we sorted the sockets we'd be introducing more variation, vs. the current behavior which would retain the existing sockets based on what's already there.

[bhollis]

Do we still think this is worth implementing, or are the difficulties of keeping order stable taking into account manually created in-game loadouts too much to bother with?

[DHager]

I think the agile-y minimum-viable-product here would be a single button for advanced users (e.g. people relying on in-game loadout swaps to handle hard content) that they would use when prepping their loadouts. The button would basically be: "Take this character's current aspects/fragments and auto-order them in a canonical way."

• Pro: Fairly independent feature, minimal changes to existing code
• Con: New button somewhere, not clear where it ought to live
• Pro: Does something that it's hard/annoying for humans to fix manually
• Con: Niche usage

Another alternative would be to impose a fixed order all the time:

• Pro: DIM loadouts turned into in-game loadouts (either with a 1- or 2-step process, as long as user doesn't tinker too much manually) will all consistent, so in-game swaps during combat usually won't cause unintended power-punishments.
• Con: When the user is asking DIM to switch their active equipment/powers, it may take longer/more-API calls. (This scenario may incur a power-punishment but people won't care sine they'll already be in orbit or a social zone.)

[bhollis]

Remember, we strive to avoid adding options, especially niche options, as a design principle.