Actual first-party plugin guidelines and rules

[philpax]

Right now, the guidelines are largely vibes-based. This has worked reasonably well so far, but there's only one @goaaats and many plugin developers. We need a long-term solution to this where we more clearly draw the line.

Here are some questions that come to mind that we might want to answer:

• How do we define automation? Does it include a plugin that thinks for you?
• Should solvers for minigame mechanics be allowed? They technically think for you.
• There are plugins that do things that bots do (like triggering actions), but have entirely legitimate uses (like providing alternate input surfaces). How do we allow for these?
• What are some plugins that we currently allow that we might not allow under a more rigorous set of future rules? (XIVCombo, AutoVisor?)
• Are there any hard lines we want to draw? PvP comes to mind
• Any technical concerns worth keeping in mind?
  • "you are only allowed to use these libraries"? potential overlap with Enforce the use of no custom signatures in first-party plugins #22

[NadyaNayme]

Again just here to share my $0.02. DIP's require input and discussion to actually work and so I'd like to encourage discussion by...well... discussing. I'm actually hoping people argue against me - even if it it's as a devil's advocate to possibly lead to better guidelines.

How do we define automation?

I personally like the Runescape definition of 1 input --> 1 output. It draws a very clear and well defined line between what is automation and what is not. Unfortunately FFXIV has a few areas where this line becomes blurred on what exactly an "output" should be. More on that later.

Should solvers for minigame mechanics be allowed? They technically think for you.

These largely exist as third-party websites anyway and could be loaded in with Browsingway. While they think for the player there's little reason to not including them for QoL purposes. Similar to how Alt1 for Runescape includes clue scroll solvers. It was initially a bit contentious but it turns out most people hate doing 15-slide puzzles and hyperbolically speaking but "literally everyone" used RSWiki for Anagram clues and map coordinate clues anyway. If it's something most people would go find in the wiki having it as a plugin isn't really giving anyone any advantages. The FFXIV Wiki(s) aren't nearly as good as the Runescape one but I don't think that changes the issue. "Saving someone from having to Google something they'd Google anyways" should be considered fine.

There are plugins that do things that bots do (like triggering actions), but have entirely legitimate uses (like providing alternate input surfaces). How do we allow for these?

See point one about 1 input-->1 output or maybe I don't understand the problem space/what this is referencing. I'm guessing it's stuff like /useitem to open Wonderous Tales and similar functionality that, though not kosher, is 1:1 but could be used as a step in automation. If it is 1:1 I don't personally care.

What are some plugins that we currently allow that we might not allow under a more rigorous set of future rules? (XIVCombo, AutoVisor?)

Better strap in because this is going to be a very long reply.

I'd have to go over the 1pp list but MacroChain could be considered a gray area under the "1 input -> 1 output" rule. Is the functionality treated as "more macro lines per macro" or "1 input --> 1-200 outputs"? Depending on the lens in which you're viewing it it is either allowed or not allowed per the 1:1 rule. And as a semi-AFK macro crafter oh boy does fitting that 16-17 line macro into a single button make a world of a difference compared to having to manually cast the last ability or having an /echo <se.1> Step 1 complete line in my macros.

Having put a lot of personal thought into this particular issue, due to my personal morals, I decided I view it as the former and not the latter. The difference is largely in minor implementation details and I don't think making the plugin less user-friendly and a bigger pain in the ass for the developer should change how I view it. It really is "more macro lines per macro but using the game UI instead of a custom UI". Maybe that's just me convincing myself it is OK to use but macros and how the game interacts with them are the source of pretty much all gray areas within FFXIV.

Following the 1:1 rule strictly - it would seem I'm against Attik in that a xivcombo that turns your entire rotation into mindlessly pressing 1 button should be considered OK. I think this is where a "spirit of the game" argument comes into play which is definitely more of a moral argument than a logically consistent argument. I agree with where Attik has set the line. I'd actually be even more strict and remove 1-2-3 combos (I can mess my combo up if I want to!) and keep it only to "you literally can't use X and Y at the same time ever" but that'd only encourage people to use 3pp forks. The cat is out of the bag already and so I think, with the spirit of the game in mind, the best scenario is to leave xivcombo implemented as it is with Attik's hardline stance. Something like this was bound to be created and I think it's better for game health to have a "blessed least-bad" version than the alternative of everyone using 3pp forks.

The 1:1 rule might also hit Gatherbuddy swapping classes when gathering from nodes but I think that's just a quirk in how FFXIV implements what would simply be "skill levels" in any other MMO. RE: "Spirit of the game" - I don't think this goes against the spirit of the game - honestly if you have the tool in your inventory the game should already be automatically swapping classes as a QoL measure.

Which takes us finally to "0 input -> 1 output". Things like triggers that change in-game settings for QoL purposes. I think the vibes-based "Is it within the spirit of the game?" is a fine definition for these. Locking the hotbar during combat or toggling between Legacy/Standard movement and other QoL measures are improving the game on mostly a user-experience or cosmetic level and it's a tough sell to say "Pressing L and locking the hotbar when in combat if it was unlocked" is botting. I think this level of automation is fine and a consensus rule of "OK, most of us agree that doing that is too far and not within the spirit of the game" is fine. (Falling back to the "passes the vibes check"....)

If the 1:1 definition is taken then what an "output" is in FFXIV would need to be defined.

• Is it a single button press?
• Is it something the player character does/interacts with? (eg: non-UI related)
• Is it something that results in a server action? (eg: auto-rolling on loot)

Are there any hard lines we want to draw? PvP comes to mind

I think disabling plugins, or plugins disabling specific functionality themselves, will mostly result in extremely trivial forks that simply re-enable the plugin or plugin features for PvP. I'd encourage ones that are obviously advantageous to disable themselves anyways but I don't think anything we do here actually matters at all. The most draconian measure would be for Dalamud to unload all plugins when it detects it is in PvP and if cheaters really wanna cheat give them the headache of maintaining a Dalamud fork. But I'm sure they would and then it becomes even harder to police if the fork gains any level of popularity.

I don't have a good answer for this and I'm not happy with either situation of "just allow them" vs "draconian ban".

[MKhayle]

Should solvers for minigame mechanics be allowed? They technically think for you.

About this : Globetrotter is a non-combat application of this that goes beyond removing the need of thinking from the player and even flags the location of the treasure. It's very handful for veterans as to not waste time during maps time, but it also removes the whole minigame part of it for newcomers who might just install it because they're afraid of social pressure and/or of wasting other players' time.
I'm not asking for Globetrotter's removal, and I really enjoy using it, but we should keep in mind that abstracting the players' thinking process is something that we have accepted on the main repo and that may also be accounted as okay-ish for a dull, repeated content or interaction that you would end up memorizing by heart anyway and just saves time for you. Of course, this is a non-combat plugin, but we may argue that UCOB lines are similar as you will end up memorizing them by heart too and they will quickly become a dull, repeated interaction.

So we gotta draw a strict line over combat plugins and non-combat plugins if we're not going to accept combat plugins which think for you while retaining non-combat plugins which would do the same, as Globetrotters and Dae's Ez Solvers currently do.

[Critical-Impact]

It's very handful for veterans as to not waste time during maps time, but it also removes the whole minigame part of it for newcomers who might just install it because they're afraid of social pressure and/or of wasting other players' time.

If a player decides to ruin his own experience(doing something for themselves for the first time) then that's on them. I think a hard line has to be drawn when it starts to effect other players. Now that comes with lots of caveats as you could say pennypincher helps you be more competitive at the market but a large portion of plugins give you a benefit that you might not otherwise have so I feel whatever line gets drawn is going to have a lot of "buts" attached.

MKhayle's last point actually feels like a good direction, maybe 1 set of rules for combat plugins and 1 set of rules for non-combat plugins makes the most sense?

Now to actually answer the questions posed

How do we define automation? Does it include a plugin that thinks for you?
I don't think that the definition of automation really matters in the context of this discussion because it's more about what the "automation" does that seems to be at issue.

• Gatherbuddy can swap gear sets + teleport you which is more than 1 action from an input
• Glamaholic can apply multiple pieces of glamour to gear with 1 action

I think both the above actions are fine and if we did go with the 1 input = 1 action rule you could make it 2+ clicks but it feels like adding a rule that doesn't really stop anything and makes the plugins worse.

I would say generally speaking most plugins do anywhere between a small amount of thinking to a large amount of thinking for the player. These do benefit the player directly but in limited cases are a detriment to other players.

Should solvers for minigame mechanics be allowed? They technically think for you.

Yes, as long as plugins don't work when playing against human players this seems fine.

There are plugins that do things that bots do (like triggering actions), but have entirely legitimate uses (like providing alternate input surfaces). How do we allow for these?

Honestly I'm not sure I have an answer for this, I feel like if a bot developer wants to use parts of dalamud and then bring in their own code to handle action triggers they'd be able to do it. We should focus our limited time on making sure plugins that exploit these for competitive advantage don't get into the main plugin list.

What are some plugins that we currently allow that we might not allow under a more rigorous set of future rules? (XIVCombo, AutoVisor?)

"It depends" is probably the best answer I can give
Anything that gives an advantage: GatherBuddy, Compass, Easyeyes, ell the ez plugins, Globetrotter, Quest map, Sonar, Teleporter
Not sure about PvP advantage as I don't really use any plugins that could effect PvP

Are there any hard lines we want to draw? PvP comes to mind

Basically see above, anything that gives a competitive advantage against other players should not be allowed in the context of PvP, I think the rules need to be slightly different for PvE.

[anna-is-cute]

re: @MKhayle

Globetrotter is a non-combat application of this that goes beyond removing the need of thinking from the player and even flags the location of the treasure. It's very handful for veterans as to not waste time during maps time, but it also removes the whole minigame part of it for newcomers who might just install it because they're afraid of social pressure and/or of wasting other players' time.

Globetrotter simply does what third-party websites already do. There are 8 possible locations for a map, and you just have to compare the hint you get to find exactly where your map is. I have a bookmark in my browser called "map cheats", which is just that website. At some point, you end up memorising the locations anyway. I don't really consider this to be automation or even removal of a minigame. No one I know actually searches the map for the hint; they just use the website (or Globetrotter).

So in terms of minigame solvers, outside of combat, I think if it's trivial to visit a website and have it solved for you, there's nothing wrong with putting that website's functionality in the game. Especially if it doesn't provide you an advantage over other players.

[MidoriKami]

See point one about 1 input-->1 output or maybe I don't understand the problem space/what this is referencing. I'm guessing it's stuff like /useitem to open Wonderous Tales and similar functionality that, though not kosher, is 1:1 but could be used as a step in automation. If it is 1:1 I don't personally care.

I was really rather nervous about implementing useitem to open the wondrous tails book. The intent from the start was 1:1, it only saves the user a hotbar slot where they would put the book.

I definitely agree that if a dev did start using that as a gateway to multiple automation then that's definitely bad. I'm in favor of a strict adherence to 1:1

In the case of gatherbuddy's gearchange followed by teleport, this isn't really something that is feasible for a casual player to do. It would require generating several macros and a lot of pre-effort and planning to pull off. So I am personally against this automation. I'd be more in favor of something that would gearset change immediately, and then prompt the user for the teleport. (This would also address that weird vanilla bug where macro'd gs + teleport happen out of order).

Should solvers for minigame mechanics be allowed? They technically think for you.

As others have mentioned, if the tool is already available in the form of a widely accessible web applet like the Mini Cactpot solver, then allowing this as a plugin is just QoL and I think this kind of QoL is really what Plugins are about.

---

Something else of note, DailyDuty has a feature to show you the next target for your daily hunts, and provides an option to teleport to that map. I have intentionally designed this feature to not do the thinking for the user by just teleporting you to the first aetheryte in the map even though the hunt data could be accessed to figure out which aetheryte is closest. This teleport is still a 1:1 interaction.

[philpax]

We've had a few plugins held up for a while due to this, with the most severely affected being combat plugins. @goatcorp/plugin-approval can we hear your thoughts on what we should and shouldn't allow, and we can start drafting up proper guidelines?

[Caraxi]

On combat related plugins, and all plugins really, whatever we decide should be retroactively applied. If we let plugins remain on the repo that break the guidelines we define, then it just looks bad to anyone who sees them. If a plugin that just displays cooldowns is not allowed, even though it makes no actual change to how someone plays the game, then something like XIVCombo being in when it has a direct effect on the gameplay (even if it is a minor difference in the grand scheme) is a a bad look.

[PunishedPineapple]

I'm not trying to be deliberately contrary, since I agree in principle, but not having existing things be grandfathered is 100% going to drive people to use third party repos that otherwise might not. If that's something that Dalamud is trying to discourage (as it seems from other DIPs), grandfathering existing combat plugins might be the "lesser evil".

[Limiana]

You can only get so much interest by doing ui modifications, combat is a major part of game, people are interested in combat plugins, people are coming for combat plugins. Allowing combat plugins in main repo might make developers of them more restrained about adding too extensive features to them, while in 3rd party zone they would have no limits on what they can do.

[rootdarkarchon]

I don't know if this is going to be any help or not, I compiled a (probably incomplete) list of current combat related plugins in the mainline repository and I tried classifying it in informational/gameplay changing with a brief description.

BigPlayerDebuffs: informational; shows your debuffs larger on the enemy bar
Damage Info: informational; adjustments to visibility of damage floating text
Death Recap: informational; a full better visible combat log until death of player in party
Distance: informational; distance display to the enemy
EnemyListDebuffs: informational; shows debuffs on the enemy list
Engage Timer: informational; more precise countdown
JobBars: informational; adds more gauges for the current job with cooldowns, audio information, adds important cooldowns of other players to the party list
Mouseover Action: gameplay changing; allows using the mouse to target, apply skills on mouse over of ingame objects, very configurable
NoTankYou: informational; shows you information on role status, food, etc.
PartyIcons: informational; replaces the ingame player icons with something larger/better visible or variants of it
Pixel Perfect: informational; allows you to stand perfectly next to aoe and know where you are precisely ingame
Redirect: gameplay changing; similar as Mouseover Action, in addition allows queueing of non-queueable skills
RezPls: informational; shows who rezzes who, which debuffs are applied that can be removed, who needs rez etc.
SkillDisplay: informational; shows you your rotation of the past used skills
Simple Tweaks: informational, only some tweaks are related to combat, i.e. combo timer
XIV Combo: gameplay changing; allows single button presses for 1-2-3 combos that require following each other

[Caraxi]

not having existing things be grandfathered is 100% going to drive people to use third party repos that otherwise might not.

Same can easily be said for blacklisting informational displays

[MidoriKami]

What are the implications one way or the other with regards to XIVCombo?

If it isn't grandfathered:

  What portion of users will seek it out via third party?
  Is that potion significant?
  Is it our responsibility?

If it is grandfathered:

  What are the consequences?
  "Why is XIVCombo allowed when XYZ is not" What's the response to this?

[attickdoor]

If it isn't grandfathered:

  What portion of users will seek it out via third party?

A lot. I'd be interested to know the true demographics but I wouldn't be surprised if it's about 50/50 between first and third party. It's also very easy to find forks. For example, people use Dae's 3P repo for other things, and guess what's sitting right there. I did a quick search for "xivcombo" and a very distasteful repo was the second hit. So if it gets yanked, SEO will easily guide people to the right (wrong) place.

  Is that potion significant?

Seems like a redundant question. Yes.

  Is it our responsibility?

Yes.

If it is grandfathered:

  What are the consequences?

Brainrot continues, people continue to make one-button rotation plugins for WAR and other jobs. People keep trying to ask the following question.

  "Why is XIVCombo allowed when XYZ is not" What's the response to this?

"We peeked into Pandora's box and we don't want to open it any further."

[goaaats]

There has to be some kind of conclusion regarding combat plugins, so we talked about this today. In the end, we decided that there should be a way for combat plugins to exist on the main repo. The hard part was deciding what is "too much" information or assistance, and what goes beyond quality of life.

In the end, we decided on this for now: combat-related plugins that provide information about your own party or alliance members that is otherwise available, but represented in a different way, are now preliminarily acceptable. This isn't a full on "go ahead", and we want to encourage people to reach out before they plan to make a plugin that would fall under this preliminary guideline so that we can talk about what they are planning to do - the final decision is up to the approval team, which we are planning to expand soon.

In the past, plugins were made by few developers that we knew personally - we were able to make case-by-case decisions about these plugins and their effect on the game without a strict set of rules. Now, with the community growing, this isn't possible anymore and we need actual guidelines as the need for accountability grows. This means that there are some existing plugins that don't meet the current guideline, and these will stay in the main plugin repository for now. This doesn't mean that they would be accepted nowadays - we are human and we gained experience while running this repo for the last 3 years - but we don't feel like we should be taking them away.

I hope this can clear up the discussion about combat plugins a little bit. If you have questions, feel free to reach out privately.

[KazWolfe]

Because this came up in a couple places, it seems that a certain set of "first-party forbidden" plugins are additionally governed by the potential impact/ramifications of supporting said plugins (e.g. Penumbra). A fair bit of this guidance in the past has been through Word of Goat, which would need to be codified at some point as well. Just from memory:

• Plugins that interfere with Square Enix's monetary interests (granting access to Mog Station items) (in Discord)
• Plugins that provide parsing, raid logging, DPS meters, or similar (in Discord)
• Plugins that allow the use/loading of game mods (Penumbra)
• Any plugins with a hard dependency on any plugin that violates the Plugin Guidelines

[philpax]

I've integrated what we've discussed above (thanks Kaz!) into the FAQ. I left out Penumbra because I'm still hoping for #4.

If we run into another plugin that skirts the guidelines, we can deal with it then. I think we want to avoid being too prescriptive, so I'll close this for now and we can reopen it if things get spicy.