Discussion: User Created UI Addons?

[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.

[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.

[Wolfie]

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.

If the function for creating that object has the NOCOMBAT restriction, then you will not have that object to pass it.

If you think creating a target without player input is possible, then you're wrong. Creating a target object would require a function which is restricted from combat use. OnHover and OnClick events do require player input, and are therefore not restricted from in-combat use.

Moreover, WOW has protected classes and 'tainting', which makes your example of LUA comparisons moot, because action calls refuse to run if scripts are ran or it receives any data from a tainted source. It is for this reason that HealBot does not have conditional statements in it, such as canceling a heal action of the target's HP is too low/high.

http://www.wowwiki.com/Secure_Execution_and_Tainting

[Ladon]

If the function for creating that object has the NOCOMBAT restriction, then you will not have that object to pass it.

If you think creating a target without player input is possible, then you're wrong. Creating a target object would require a function which is restricted from combat use. OnHover and OnClick events do require player input, and are therefore not restricted from in-combat use.

Moreover, WOW has protected classes and 'tainting', which makes your example of LUA comparisons moot, because action calls refuse to run if scripts are ran or it receives any data from a tainted source. It is for this reason that HealBot does not have conditional statements in it, such as canceling a heal action of the target's HP is too low/high.

http://www.wowwiki.com/Secure_Execution_and_Tainting

Maybe you aren't reading my posts thoroughly? I never stated you wouldn't need user input. That is a given and acknowledged by me in every one of my posts. It's what is done after the user input that is the problem hence the Wack-a-Mole comparison. The user simply clicks on the target and THEN the script takes over as with HealBot.

As for protected classes, I'm not sure why these are brought up. Protected classes are simply classes that cannot be called by an unverified source...aka insecure code in this case. None of my examples address this because the calls are being made legitimately to the API from within the application, not through some kind of 3rd party hook.

As for script tainting...I'm starting to wonder if your knowledge is just gathered from reading the Wiki. Script tainting only occurs if you are attempting to manipulate the variables in memory being used by the LUA script via an outside hook. My example in no way requires any of this as it works with in the API, passes the objects and variables to a LUA script that isn't being manipulated externally. This is in fact exactly what HealBot does a lot of at a high level and last time I checked it works just fine in the current version of WoW. Your statement that HealBot has no conditional statements in it is 100% false. It for example performs a conditional on current target HP versus max target HP then chooses a spell from an array list which contains information about how much the spell heals, cast speed and mana cost. It also uses conditionals left and right for its "smart cast" feature.

So we can continue to have this argument but it still fails to address the point when it is a fact that HealBot exists, works and replaces much of the gameplay in WoW exactly as I have described. Somehow it has come down to you to somehow attempt to disprove this reality by bringing up silly things such as script tainting, protected procedures and objects. The real argument is that flexible UIs can bring about things like HealBot and it is questionable if a highly customizable UI with full add-on support is worth it.

I say it is not worth it. Developers are more than capable of making good UIs without the need for add-ons. It is not worth it for a developer to have to maintain API security so people don't break shit with add-ons. It is not worth developers having to worry about if certain add-ons are going to completely trivialize the content they had been working on the past couple months. You simply cannot create both a flexible yet restrictive API like you seem to be suggesting. It's either one or the other. Open it up and accept that there will be add-ons that trivialize your game or lock it down and do your best to take user feedback and implement it yourself.