So first of, this is a better answer than expected, so good job on that. These guidelines are mostly what is currently implemented in the standard ruleset (1&2: no "hard cheating" by for example targetting minipets or dialogs), no automation (3: for example /useskill) while texture modification is allowed (4: texmod). As this ruleset is derived from the last vote, it seems that people mostly followed this same or a similar train of thought for voting.Sylars wrote: ↑Sat Apr 10, 2021 1:27 pmThere are plenty objective measures that could be used without a need to re-evaluate every new feature addition.
Example 1: No memory write. All and any externally drawn info is allowed, anything that writes to main thread memory isn't.
Example 2: Anything achievable (outcome based) in the game without tool assistance is allowed. Ok: Hotkey to swap armour out of fight. Not ok: target minipet.
Example 3: Single-action single-outcome restriction. Ok: Hotkey to swap 1 armour piece, move-to hotkey. Not ok: Hotkey to use rezz scroll and skeleton trap in the same press. Auto pcons.
Example 4: no retexturing. Ok: any kind of overlay drawn info. Not ok: changing health bar colour, texmod.
Or anything else the community could decide on. What this has as an advantage is automatic classification and unambiguity about new tool usage. The rules stay simple and easy to enforce. Special cases may or may not be handled with a blacklist (e.g. no sblj to skip 30 star door in 16 star due to historical reasons).
The problem is, that there are always edge cases, I will name a couple (and YES, these are extremely nitpicky):
-Movement macros: Is a movement macro the same thing as moving via toolbox minimap? If yes, are both of these a "memory write"? What if I write a script that moves my camera to a specific position and clicks on the ground, which is basically the same thing as the player clicking himself? Would this be considered 1 action per button press?
-Target macros: Can I use a target hotkey to target the closest enemy of a specific kind? Is this "overlay drawn info"? Technically if I can see enemy names on my screen, I can infer which enemy is which and could target them. What if I am looking to a different way though? The distance around a spirit can be infered from it's position, but can we infer which direction an enemy is facing? Can I click on the minimap to target something? If yes, am I allowed to incorporate additional conditions like current enemy health in % into my targeting? What if the enemy has abilities that change their absolute maximum health which changes FH/EoE thresholds, is that allowed? Can I add all allies in my range to my party list and target them thereby?
-Ruptbots: Can I setup a script that rupts the next ability an enemy uses? Technically it is just "1 action per button press". But then my programm is kinda monitoring my environment and acting reactively. What if I write the script that tracks every skill usage by every enemy and while targeting them it shows me their cooldown, allowing me to make a prediction when they are gonna use their next skill? Is this info you can usally infer?
Which of the mentioned categories do each of these discussion points comply with?
This is a rethoric question, I do not expect an answer. But I can gurantee that some people would answer this differently than you and I would. So what you are effectively doing is replace the discussion about whether a individual tool should be allowed with the discussion which set of tools this new tools should be assigned to. Which I guess... has some advantages, but some disadvantages as well because arguably some aspects of such a category are more problematic than others or are more or less gamebreaking. (By the way, just saying: This is very close to what we are already doing. When a new tool is introduced, the first step is to compare it against the existing rools that are allowed and forbidden. If it is very similar to other allowed tools it is likely being allowed, whereas when it is similar to tools that are forbidden it is likely being forbidden itself. If it is completely new or somewhere in between, the moderation team (aka me) had to make a decision based on comparability to already existing tools, which was extensively criticized.). To summarize: "What this has as an advantage is automatic classification and unambiguity about new tool usage. The rules stay simple and easy to enforce." is not a statement that will hold, it is just slightly moving the discussion. Then we would need a vote to figure out which category something belongs to, which means we would have gone full circle.
My own voting strategy for the standard category could be pretty much simplified to a couple of things: I will be voting to forbid any "hard cheating" and things where I feel like a normal human does not have the ability (movement macros, targeting, ruptbots) or attention (enemy counters, auto rezzscrolls), while at the same time considering whether the convenience factor outweights the competitive advantage (autopcons, hotkeys for individual items). These are of course my personal opinions and I am sure you have your own. I am confident the community as a whole will come to a reasonable solution, while still allowing the flexibility voting on individual tools provides to remove especially toxic things and allow especially convenient things, even though they by your personal definition might belong to a different "set of tools".
If the majority of people share your opinion, we will see this be reflected in the rules either way, because we would see some set of tools get a huge amount of yes votes while another set of tools would get no votes.