Discussion: User Created UI Addons?

[Wolfie]

I'm still not sure what you are saying. I'm not taking about anything being automated by the API. I'm talking about using the API to create automation. For example if you allow your API to see player health which has plenty of legitimate uses, then allow your scripting language to perform conditionals/iteratives/comparisons which again has legitimate uses then allow for execution of commands, none of these three in themselves are automation or arguably malicious.

But when you put the three together, then you start running into problems. Give the user the three controls above in FF14 and you can make a White Mage play itself other than executing the macro similar to what HealBot does in WoW.

This is the kind of risk you run by opening your interface up. The more information and controls you expose the higher the risk that people will just further automate tasks in the game to the point that they are just running complex scripts rather than playing the game. Sure you can just argue that good people won't use them but that really doesn't solve the problem.

http://www.wowwiki.com/World_of_Warcraft_API

Here, read through that and why such things can be restricted via PROTECTED and NOCOMBAT classes.

Decursive has, or had, an option to auto-heal you, but only while out of combat.

[Ladon]

http://www.wowwiki.com/World_of_Warcraft_API

Here, read through that and why such things can be restricted via PROTECTED and NOCOMBAT classes.

Decursive has, or had, an option to auto-heal you, but only while out of combat.

Again, still not addressing my point. The three examples of controls I gave cannot be restricted to NOCOMBAT extensions because there is legitimate use of them in combat. Also for WoW they use NOCOMBAT to specific actions that normally cannot be used in combat. This is simply in place to prevent someone from circumventing a normal restriction in the game via API call. They can't be used to be like "while in combat you can't read player HP, run a comparative then cast a heal spell."

[Wolfie]

Again, still not addressing my point. The three examples of controls I gave cannot be restricted to NOCOMBAT extensions because there is legitimate use of them in combat. Also for WoW they use NOCOMBAT to specific actions that normally cannot be used in combat. This is simply in place to prevent someone from circumventing a normal restriction in the game via API call. They can't be used to be like "while in combat your can't read player HP, run a comparative then cast a heal spell."

I don't think you understand what the NOCOMBAT thing can be used to break your scenario very easily.

For your scenario to work, there are three requirements:

1. Performing a health check.
2. Creating a target.
3. Performing an action.

Adding the NOCOMBAT clause to any of the 3 will break this automation. But generally, finding a target is an API that does not exist in any game. When you can automate target creation is when you can automate everything else.

[Ladon]

I don't think you understand what the NOCOMBAT thing can be used to break your scenario very easily.

For your scenario to work, there are three requirements:

1. Performing a health check.
2. Creating a target.
3. Performing an action.

Adding the NOCOMBAT clause to any of the 3 will break this automation. But generally, finding a target is an API that does not exist in any game. When you can automate target creation is when you can automate everything else.

You don't need to create a target. As will HealBot you have the user do that part and the script does the rest. You click the target, it reads the health information/buff/debuff information, runs the results through some scripting logic and selects and casts the spell for you. So now you're just playing Wack-a-Mole rather than Final Fantasy.

And you can't throw these in NOCOMBAT because there are plenty of legitimate uses of these calls in combat situations. This is exactly why WoW does not do this. NOCOMBAT is restricted specifically for actions that you normally cannot perform in combat. It's not around to try and break scripting.

[Wolfie]

OnClick and OnHover events create a target object that is passed around to the other function, dude.

You are talking out of your ass.

[Wolfie]

And before you ask me why that's relevant, it's because I can create a Whack-a-mole board with in-game macros and raid frames, because macros implement OnHover events in the form of mouseover targets.

[Ladon]

OnClick and OnHover events create a target object that is passed around to the other function, dude.

You are talking out of your ass.

Yeah an object, not a function "dude". NOCOMBAT is a FUNCTION restriction, not an OBJECT restriction.

[Wolfie]

Yeah an object, not a function "dude". NOCOMBAT is a FUNCTION restriction, not an OBJECT restriction.

Objects are created with multiple functions. NOCOMBAT restrictions can restrict which of these functions can be used in combat (i.e. the ones that don't require any player input).

Click or hover events require player input.

Please, please stop talking, because you are out of your element.

[Ladon]

Objects are created with multiple functions. NOCOMBAT restrictions can restrict which of these functions can be used in combat (i.e. the ones that don't require any player input).

Click or hover events require player input.

Please, please stop talking, because you are out of your element.

Sorry man you already tried to use that one on someone else. You are wrong in this case though.

Yes you can create objects within functions by calling on them which in turn the function can return that object if that is it's function.

NOCOMBAT is a function call restriction, it does not prevent you from passing a returned object, or variable when calling another function. All it does is prevent you from calling that function in order to pass in an object in order to get the return.

So in your case, since the OnHover or OnClick function can be called in combat then you can get the target returned during combat. You can then pass in that object to any other function that is not restricted by NOCOMBAT if you are in combat. So unless GetPlayerHP() is NOCOMBAT restricted then there is no reason you can't get the HP returned by passing in your already acquired target object. And then from there you can pass your HP value into a Lua script, have the script spit out a command object then pass that to CastAbility(). Again all functions that aren't restricted by NOCOMBAT.

It seems like you are under the impression that you can somehow strip out an object or variable. This isn't possible as long as you can call the function and get the return.

[Great-Saladin]

gear changer
a longer macro for gear swap