Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add useful-only-in-out-of-spec-scenarios plugins to the plugin restrictions #28

Open
philpax opened this issue May 1, 2024 · 5 comments

Comments

@philpax
Copy link
Contributor

philpax commented May 1, 2024

The current plugin guidelines don't explicitly disallow plugins that are only useful in out-of-spec (e.g. OOB, etc) scenarios. We should mention this and the reason why they're not allowed - a plugin that only works in service of illegal behaviour tacitly encourages said behaviour, which we can't support or discuss within this community.

@reiichi001
Copy link

We can/should probably include some of the other common cases (or come to formal conclusion on them) that are pinned in discord too, copied with some minor edits for tone below. https://discord.com/channels/581875019861328007/685275026156683280/929071629550645248

Common suggestions that won't happen:

  • Emote/Expression Looping
    This violates our rule on automation. While this seems harmless, it's one of the easiest things for another user to notice, as the game tells you whether an emote is persistent.
  • Skip cutscenes
    This violates our rule on automation. Especially in the case of unskippable cutscenes.
  • Skip dialog boxes
    This violates our rule on automation.
  • Automated crafting
    This violates our rule on automation.
  • Autoroll on loot
    This violates our rule on automation.
  • Friend list login/out alerts
    This is impossible. FFXIV only sends friendslist data when you actively open the friendslist. It cannot be refreshed otherwise. A plugin would have to implement some form of external server to do this (like GoodFriend)
  • Visible AOE markers for mechanics that aren't normally telegraphed in advance
    This is cheating. We don't do that here.
  • Camera zoom adjustments
    This violates our plugin guidelines, can give game-breaking advantages in battle content, and can break cutscenes. Plugins that stay within the game bounds are still allowed.
  • FFLogs integration
    Just use ACT instead. We prefer to keep our distance from this aspect of FFXIV.
  • Avoiding fantasia
    This violates our plugin guidelines. Please do not use a plugin as a means to bypass the MogStation.
  • More XIV Combos
    No. See Attick's other pinned comments and stances about this. Also read I have an idea for a combo MKhayle/XIVComboPlugin#119
  • Damage parser / ACT as a plugin
    Just use ACT (or alternatives) instead. Similar to FFLogs, we'd also like to distance ourselves from this aspect of FFXIV.

@MidoriKami
Copy link
Contributor

MidoriKami commented May 1, 2024

It might be worth mentioning versions that are rule compliant, because people will always go "well XYZ does (something similar but not quite)". Such as "Select Next Loot Item Tweak", it's not auto loot but it achieves a similar thing.

@MidoriKami
Copy link
Contributor

Might also mention re-coloring aoe's due to the can of worms that opens.

@KazWolfe
Copy link
Member

KazWolfe commented May 2, 2024

Is this not already covered? The precise wording in the docs is: (emphasis mine)

  • your plugin does not interact with the game servers in a way that is:
    • automatic, as in polling data or making requests without direct interaction from the user
    • outside of specification, as in allowing the player to do or submit things to the server that would not be possible by normal means

Unless there's something more direct that you're thinking of? e.g. a plugin that would be allowed if it weren't useful only in circumstances that were out of spec?

@reiichi001
Copy link

The plugin submission that prompted this did not strictly break anything but was only useful if the player had already done something to reach that point. This is to improve those cases, as modification to the local client won't result in -more- invalid data, but we can't endorse the steps/tools needed to get to that point.

We also have several instances of plugins that don't directly go against guildeines, but would still be rejected. (Parsing, Modding, Posing, etc plugins). It would be better to have those "won't pass even if fine" concepts documented outside of discord or suggestion channels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants