[Rework] XIVCombo Expanded

[MKhayle]

Summary: XIVCombo hasn't evolved much while the game did evolve a lot. From the initial 12-ish jobs that XIVCombo initially supported, we have now reached a total 24 jobs including ADV/DoL. The current design is far from being efficient, and thus, I initiated a rework of it, while rethinking the features, and accessibility entries of the plugin.

That means that from now on, each combo will belong to a category among those:

Vanilla XIVCombo

• Basic 1-2-3 into 1
• XIVCombo features or equivalent

[ExpandedCustomCombos]

• Avoiding overcapping resources
• Improved vanilla XIVCombo features
• Actually whatever can remove button bloating without falling under the Accessibility or Secret features

[AccessibilityCustomCombos] (formerly SecretCombos, available to all)

Enabling better performance for unskilled players while keeping it fair because it can be non-optimal or non-intuitive:

• Monk's 1-button rotation
• Dance steps
• Reawakening all-in-one
• DNC auto-Saber Dance or auto-Feathers
• PCT auto-substraction
• Buffs into buffs
• Whatever prevents you from tracking cooldowns because of how it works

[SecretCustomCombo] (newly secrets, still require /pcombo secrets)

Optimization routes where the plugin thinks for you when it shouldn't necessarily or gives little benefits:

• IsMelee
• Buff duration remaining
• Debuff duration remaining
• Balance optimization path nerding
• Opener-specific options

[MKhayle]

@kaedys hi

[MKhayle]

There's probably a lot of stuff to think about still and narrower lines to draw but that's just a quick draft and I think we can make it better also "Nerd" can be replaced by "Hardcore" if that's offensive but I like offending nerds

[kaedys]

I would also add logical follow-ups or buttons that are strictly mutually exclusive to the no-attributes section. Basically, anything that would probably be fine by the relatively strict standards of the original mod. Good examples would be Ingress -> Regress, Blizzard IV/Fire IV (SquEnix even advertised this as something they were adding in DT, but then pulled back on it, I guess), Iajutsu/Tsubame, and Devilment -> Starfall Dance.

[MKhayle]

That's what I meant by

Actually whatever can remove button bloating without falling under the Secret or Nerd features

[kaedys]

So, overcap avoidance seems like it might fall into either Secret or Nerd. They're resource-reliant replacements, but they're also directly in line with the PCT auto-Subtractive (assuming you mean the overcap protection version of this).

[kaedys]

I would tend to argue that most resource-reliant features are actually just Secret combos, excepting ones that do very specific behavior or conditional resource thresholds based on things like, for example, The Balance recommending Saber Dance be used at 50+ Esprit rather than 85%+ specifically when within Technical Step.

[MKhayle]

Overcapping avoidance may be better told as "overcapping protection" for standard indeed as it would be rather fit for players who have trouble managing their resources (adhd, forgetful, stressed, etc)

[MKhayle]

When I wrote "resource-reliant features" I had SGE Ritomaza and SCH/SMN Energy Drain in mind though

Edit : I mixed everything up when reading your message

[kaedys]

Wait, don't those fall under Resource-generation when resource is lacking (ie. under no-attribute combos)? I assumed that was referring to things like Serpent's Ire if you don't have any Rattling Coil Stacks, Rhizomata if you lack Addersgall, Bloodfest if you lack Powder Gauge, etc. Those are all distinctly non-optimal, since basically all of those cooldowns (Rhizomata excepted) are intended to be used during cooldown windows now, so simply using them when out of resources is almost always a bad idea. Placing those under NerdCombos feels wrong from that perspective, and I'm not sure they really rise to the level of Secret, either.

[MKhayle]

Yes, you are correct, I misread your message there and mixed things up

[MKhayle]

For an example of resource-reliant features, I meant things like a no checkmate/double check overcap feature which would replace ST skills by a charge if it would overcap in the next 2.5sec so that you only use them when appropriate to keep most charges up for burst phase

That would be nerd resource-reliant I guess ?

[MKhayle]

Also, quick thought ; we could also be rebranding current SecretCombos into EasyCombos and reintroduce actual secrets/nerdcombos as actual SecretCombos. The idea there would be to enable EasyCombos by default and mark them with an icon to indicate their purpose and the fact they're non-optimal, while getting to keep actual "secrets" combo secret-er.

[MKhayle]

I consider the EasyCombos, would be the training wheels people would need to gain confidence and learn a job with less stress

[kaedys]

Ya, but not all of them are actually non-optimal, they just don't cater to optimization.

[MKhayle]

Yeah, there would just be a need to downgrade some SecretCombos to EasyCombos, but not all of the current SecretCombos

[MKhayle]

(Can't wait for the first time we'll make a Secret AND Easy combo because we just can't decide)

[kaedys]

We'll need to invert the dependency on some, if we do that. Example, the two Subtractive auto-uses. Using immediately is the easy one

[kaedys]

In fact, basically all of the avoid-overcap ones are secret under that logic, because that's nearly always the optimal approach, rather than immediate usage.

[MKhayle]

I will tackle this in a temporarily branch I think so I can draft a first approach and let you tell me any changes you'd apply to those

[kaedys]

We should probably tag some of the others, too

[MKhayle]

I honestly think it won't take long but maybe I'll regret this sentence in 2 or 3 days but, sure, I'll mention people soon

[MKhayle]

325 would definitely fit in the [EasyCombo] category, as it's an non-optimal way to use cards, methinks

[kaedys]

Definitely. How would the targeting on that even work? All 3 base spells requested are hostile target, but all 3 Plays are friendly target, casting them on yourself is almost never a good idea o.O

Edit: I'll ask over there.

[MKhayle]

Well, that's counterintuitive so I can understand part of it but the whole request is weird, but overall whichever way it gets implemented would fall under the EasyCombos

[kaedys]

Yep, perfect example of an EasyCombo.

So with swapping to EasyCombo instead of NerdCombo, is the intent to basically keep most attributes as they are, and only change ones that really should be classified as EasyCombos? And possibly invert some dependencies? Or do we want to make the EasyCombos conflict with the SecretCombos (thinking of Subtractive here), so users don't have to select the EasyCombo one first to get to the SecretCombo one, they just can't have both active at once? Personally, I'm kinda feeling the latter.

[MKhayle]

@aldros-ffxi @masanbol @lhn1703 pinging you to join the discussion and give your opinion about that since you recently contributed

[aldros-ffxi]

So, part of the goal for my secret combos on VPR were because I'm trying out controller, and there's extremely limited space for stuff x_x, so a lot of condensing is helpful to not have to do the multiple set swapping thing

Other than that, I think the distinction is useful there between removing bloat and stuff that handles more complex logic for the user

[lhn1703]

The issue with making easy and secret combos mutually exclusive is that some secret logic combo are built on easy combos. I think secret combos should be the "upgrades" of easy combos to handle optimization cases. If someone really cares about optimization then they shouldn't be using an easy combo feature that hinders it (e.g. I never use RPR shadow of death -> gallows/reaping feature since it prohibits proper double shroud burst sequence), or make a request for a secret combo that bakes the optimization logic on top of the easy combo.

Attribute-less combos should be all the supported combos on attickdoor's vanilla repo (they will never hinder optimization either), I consider almost everything else on this fork is an easy combo tier or higher. Doing this also highlights to users how superior the fork is to the original :).

[MKhayle]

I do think attick's vanilla xivcombo is a very valid base for standard combos, although an incomplete one. Also, many combos differ between the vanilla one and Expanded because of how things evolved over time, but adding differenciation/tagging with pretty colored stars & some on hovering tooltip to explain what the color means may be a good thing indeed. The "upgrade" part being more appropriate for Secrets also sounds correct to me.

[MKhayle]

I edited the draft from the issue and added another tag I do think it'd be better to rework attributes so that they are more intuitive for users

[MKhayle]

pros: @kaedys & @lhn1703 could go ham on the secret combos, while I could focus on the vanilla support & expanded/easy combos + requests cons: having to review the 200+ existing combos

[lhn1703]

Yea I like this classification. It also lets users "ease" upwards or downwards when they are ready to "graduate" from xivcombos lol. As for hierarchy, combos should never require any tiers higher than its current tier (e.g. ExpandedCustomCombos should never require easy or secret, but can require vanilla or other expanded).

As for the the curating current combos, I think that we're gonna have to do it sooner or later. If we divide up work, I can take RPR and BLM since those two are my mains.

[kaedys]

The issue with making easy and secret combos mutually exclusive is that some secret logic combo are built on easy combos. I think secret combos should be the "upgrades" of easy combos to handle optimization cases. If someone really cares about optimization then they shouldn't be using an easy combo feature that hinders it (e.g. I never use RPR shadow of death -> gallows/reaping feature since it prohibits proper double shroud burst sequence), or make a request for a secret combo that bakes the optimization logic on top of the easy combo.

Valid point. I think some should probably be exclusive, others could be follow-ups. Alternatively, the SecretCombo version could just also include the EasyCombo version, with modification for optimization. The Saber Dance one is a good example. EasyCombo avoids overcapping by using it at >= 85 Esprit. SecretCombo does the same thing, except it lowers the threshold to 50+ when inside Tech Step, as an additional optimization.

Also @MKhayle a thought from the recent Paladin Royal Authority one: especially for the SecretCombos, it may be useful to have a tooltip (or just use a longer description) so we can put a short blurb in there about why it does it that way. Like the Royal Authority Atonement feature for the SecretCombo version might look like:

Royal Authority Atonement Optimized Replace Royal Authority with Atonement et al when under the effects of the corresponding buffs and they would be overwritten by another Royal Authority cast. Reasoning: Using the Atonement combo when it would be overwritten, rather than immediately when available, potentially permits it being delayed into Fight or Flight, which can be a significant potency gain.

Edit: The reasoning here could be a tooltip when moused over, or we could just establish a standard format for the Secret ones where we add the reasoning, if we want to add it for the combo, on a secondary line in the description with a standard prefix like \nReasoning:

[kaedys]

The one modification I would make to the draft is I would put Avoiding overcapping resources under EasyCombos, imo. Most of the time, including them purely to avoid overcapping is going to be non-optimal, but certainly simplifies the job over having to directly manage the resource. Then we can have SecretCombo versions (or upgrades) that add a bit more intelligence to how it's done, like the Saber Dance one.

Edit: TBH, I'm not sure we really need a separate ExpandedCustomCombo category. I think most of the things that would fit in it would justify either being in the standard vanilla attributeless category, or EasyCombos. A good example is the automatic usage of Storm's Eye to maintain the buff on Warrior, or the automatic usage of Dread Fangs to maintain the debuff on Viper. Both, imo, are EasyCombos because they remove something you'd otherwise have to think about managing, but can result in less optimal play, such as overcapping Surging Tempest on Warrior when you use Inner Release right after Storm's Eye, or use Dreadwinder right after refreshing Noxious on Viper. That also avoids the need for us to reference what the root mod is doing.

[MKhayle]

yeah, the tooltip part of this rework is one of the main feature I want to add so that it makes sense to people can also be useful for situations like https://github.com/MKhayle/XIVComboExpanded/issues/317

I will either add an override or a tooltip attribute depending on how I feel like it, but for now, bed time

re: @ExpandedCustomCombo, I think it's good to let people know what differs from vanilla, and it can be both an ExpandedCustomCombo as an improved vanilla combo, AND an EasyCustomCombo because of the nature of how it handles it

[kaedys]

Ya, I just don't like the idea of having to check the base mod to see what it's doing. And especially around expansion releases, this mod gets updated wildly faster than the base mod, so we don't really know what they're going to add yet, which means some things could end up changing as they add stuff. Would be weird, imo >.<

[lhn1703]

As Attick is VERY conservative on what is allowed in vanilla, so I don't think this will be a big issue. It's rather easy to anticipate which ones will be blacklisted by Attick (almost all of them), even so any unexpected change should theoretically be a simple reclassification in CustomComboPreset.cs on our end.

[masanbol]

Apologies, it's my wife's birthday so I've been out all day. The line to me would feel like if a decision is being made for the player to either predict something (a buff or debuff's expiration time) or avoid something (overcapping a resource) - in those circumstances making those secret would make sense. Otherwise I think collapsed combos and especially suboptimal "easy buttons" like monke mode don't really need to be secret because they have their own drawbacks that players should be taking into account when using them. For me, everything in that category exists to help people who aren't interested in perfect play, have accessibility needs, or different control setups, so making those open to all feels like the right call.

[kaedys]

Ya, the idea is that, instead of just having 2 categories, we'd have 3 or potentially 4. That lets us further differentiate between things that make decisions in a potentially sub-optimal but distinctly simplifying way, versus things specifically tailored for optimization, versus things that aren't really either of those buy still go above what Attick permits in his root mod.

[aldros-ffxi]

It seems to me that at least taxonomy-wise, it may be better to have things with label classes that can be shown/hidden/filtered/etc

[MKhayle]

We currently have Green stars for secret combos, and I guess we can just either color swap it or find a better UI. I have some ideas and will try a PoC today

[MKhayle]

(imgui is a pain tho.)

[aldros-ffxi]

One other thing that occurred to me, it might be good to have a configurable base button for some things

[MKhayle]

well, UI rewrite incoming anyway

[MKhayle]

okay, branching off on for now on #AttributesRework and I'll start adding stuff on it today

[aldros-ffxi]

Yeah, just a thing that came to mind the other day when examining GNB, it'd be useful to have some composable option, like we write some replacement logic, and make the base button for that replacement configurable or something

[MKhayle]

I would love to find a simple way to improve the current configuration bloating (ironic, isn't it) and improve the UI but for now, Attributes is the priority

[kaedys]

My biggest beef, and I'm not sure how easily this could be solved, is having to number the features by hand, and ensure they are all unique. Too easy to accidentally use a duplicate, too annoying to find what the current highest number for a job is, and it doesn't even fail to compile with duplicates, it just fails to actually load the plugin in in-game.

[MKhayle]

I am currently in the process of reworking the UI with imgui and this is very painful and I would like the whole world to know that I hate imgui

[kaedys]

GUIs in general are something I avoid >.<