Question - Script conflicts (easy for example)

[EEPJR24]

So I know that Easy Lua is not being maintained and that the CWTN plugins unload it. I was wondering if there existed somewhere a set of guidelines one could use to NOT interfere with CTWN like plugins in a Lua or macro scripts?

- E

 

[Kilroy03]

I'm pretty sure that the CWTN plugins disable anything that conflicts with them

 

[Hylander]

like the movie Highlander, "there can only be one" .... tool for automation (or at least as few as possible). there aren't two steering wheels in a car, for a reason. conflicts will arise, fuckery will and does ensue if you use more, LEM, events and reacts are specially coded (for example( to pause one the automation, do something else and then unpause to resume.

 

[Darkwynd3]

I’m sure someone may have a better answer, but anything that functions as automation can conflict. If you run a plug-in or a macro, and want to use a Lua to meet some condition, or a react or event, that Lua react or event should pause your other running plugin/macro. Does this mean things won’t more or less work together? No, but as a best practice you should be planning for conflicting interaction.

 

[Sic]

So I know that Easy Lua is not being maintained and that the CWTN plugins unload it. I was wondering if there existed somewhere a set of guidelines one could use to NOT interfere with CTWN like plugins in a lua or macro scripts?

- E

it is pretty straight forward

if a resource is going to fight for things the plugins do - burns, ability usage, movement, etc - things that the plugin relies on - it is something in conflict, and we're going to unload it --- we don't unload/end kiss or rgmercs, but should there be future issues that arrise because of it, we will.

mq2melee, mq2afnuke, mq2combat, mq2heals - these all do abilities/burns/combat type stuff and are "conflicting"

easy, lerogue, and autotoon are examples of luas that conflict, and thus we unload them.

I'm pretty sure that the CWTN plugins disable anything that conflicts with them

we don't - we really try not to. we assume if someone is doing something, they're doing it for a reason. unfortunately this isn't always the case, and causes support issues and user experience issues and then we add them to things that we unload.

An example is how many times we have to address to folks that it isn't any of the cwtn class plugins pressing their Origin button - and sometimes we get a lot of pushback about it - but it simply isn't us doing it.

 

[EEPJR24]

it is pretty straight forward

if a resource is going to fight for things the plugins do - burns, ability usage, movement, etc - things that the plugin relies on - it is something in conflict, and we're going to unload it --- we don't unload/end kiss or rgmercs, but should there be future issues that arrise because of it, we will.

mq2melee, mq2afnuke, mq2combat, mq2heals - these all do abilities/burns/combat type stuff and are "conflicting"

easy, lerogue, and autotoon are examples of luas that conflict, and thus we unload them.


we don't - we really try not to. we assume if someone is doing something, they're doing it for a reason. unfortunately this isn't always the case, and causes support issues and user experience issues and then we add them to things that we unload.

An example is how many times we have to address to folks that it isn't any of the cwtn class plugins pressing their Origin button - and sometimes we get a lot of pushback about it - but it simply isn't us doing it.

Okay, so just for instance, having a window open like easy did would not, in and of itself, cause any issues that the necessitated unloading it. I don't run CTWN myself, although several friends do an they like a lot of the features it has.

Big things that come to mind that would cause issues:
1. Moving the player or pet.
2. Triggering AA that might throw off timers.
3. Combat actions (spells, targeting, attack on or off, sitting, ducking)

Things that come to mind as likely to NOT cause issues:
1. Displaying of information (countdowns, time of day, thirst, zone information, other player information, etc.)
2. Deleting things from inventory?
3. Clearing the cursor.
4. Using non-combat related clicky (summon food, etc.)

Sound close?

 

[Sic]

Okay, so just for instance, having a window open like easy did would not, in and of itself, cause any issues that the necessitated unloading it. I don't run CTWN myself, although several friends do an they like a lot of the features it has.

Big things that come to mind that would cause issues:
1. Moving the player or pet.
2. Triggering AA that might throw off timers.
3. Combat actions (spells, targeting, attack on or off, sitting, ducking)

Things that come to mind as likely to NOT cause issues:
1. Displaying of information (countdowns, time of day, thirst, zone information, other player information, etc.)
2. Deleting things from inventory?
3. Clearing the cursor.
4. Using non-combat related clicky (summon food, etc.)

Sound close?

yeah pet/player abilities/actions definitely can be
aa/ability usage can be
combat stuff definitely can be
targeting is a definite problem

yes, cursor interaction can be a problem.
doing anything that makes you cast stuff can be a problem.

I'm not going to give you a "this definitive list here is the end all be all if it isn't on this list sic said it is cool"

we have addclickys - so clickies elsewhere - potential for conflict
inventory management - potential conflict
clearing cursor - potential conflict
putting stuff on cursor - potential conflict
displaying information - no conflict here

many of those are obviously fine if you pause or unload the plugin, but things that have conflict shouldn't be run concurrently to avoid potential problems

sometimes personal interference is "conflict" and sometimes that is

 

[EEPJR24]

yeah pet/player abilities/actions definitely can be
aa/ability usage can be
combat stuff definitely can be
targeting is a definite problem

yes, cursor interaction can be a problem.
doing anything that makes you cast stuff can be a problem.

I'm not going to give you a "this definitive list here is the end all be all if it isn't on this list sic said it is cool"

we have addclickys - so clickies elsewhere - potential for conflict
inventory management - potential conflict
clearing cursor - potential conflict
putting stuff on cursor - potential conflict
displaying information - no conflict here

many of those are obviously fine if you pause or unload the plugin, but things that have conflict shouldn't be run concurrently to avoid potential problems

sometimes personal interference is "conflict" and sometimes that is

heh. I code for a living, so I know there is no "end all be all". Just looking to avoid obvious conflicts and identify other potentials. This may not go anywhere, I have a bit of time right now but that can change so who knows. If anything I would just start out with some of the display items and see what happens.

Thank you for the replies, that helps.

- E

 

[ChatWithThisName]

heh. I code for a living, so I know there is no "end all be all". Just looking to avoid obvious conflicts and identify other potentials. This may not go anywhere, I have a bit of time right now but that can change so who knows. If anything I would just start out with some of the display items and see what happens.

Thank you for the replies, that helps.

- E

I think more importantly is that if there are issues and we contact you regarding the conflicting nature of them, that they are address so as not to conflict. Such as if it's intended not to be run with cwtn plugins, then there is logic that can be added to look for the use of them for that class and disable those features as well.

We tried to discuss an option like this with easy Lua and the developer did not want to change the logic to avoid the conflict, which is why it resulted in being added. If the core focus is not to conflict (as it started out with easy), then we'll just leave it alone. But as long as you're receptive to communication about the issue and working towards eliminating the logic that conflicts while the plugins are in use, there is no reason we can't co-exist!

 

[EEPJR24]

I think more importantly is that if there are issues and we contact you regarding the conflicting nature of them, that they are address so as not to conflict. Such as if it's intended not to be run with cwtn plugins, then there is logic that can be added to look for the use of them for that class and disable those features as well.

We tried to discuss an option like this with easy lua and the developer did not want to change the logic to avoid the conflict, which is why it resulted in being added. If the core focus is not to conflict (as it started out with easy), then we'll just leave it alone. But as long as you're receptive to communication about the issue and working towards eliminating the logic that conflicts while the plugins are in use, there is no reason we can't co-exist!

In the long run that is best for everyone, I was just not sure how flexible the Lua would be in ceding control to outside events. If that functionality exists, so much the better, especially if I can detect what is running and just disable functions by class or group of classes (melee, hybrid, caster, whatever). Given that I see any plugin in that is driving combat or movement type operations as having priority (who wants dead players???), just being able to test for conditions and not interfere during them would be grand.

- E