WowAce

What is your character class? Mage

Were you in Solo, Party or Raid? Raid

What is your localization language? (en, de, fr, etc...) En

What steps will reproduce the problem?
1. Only being able to Cast Poly on Charmed Units (Worshipping) during Cho'gal encouter when Counterspell if off CD is prefered.
2.
3.

What is the expected behavior? What do you see instead?

I'm still hoping you'll give us the option in addition to being able to edit the macro to modify which spells are used for which effects. With this encounter it would be preferable to be able to cast Counterspell when available on the charmed units instead of Polymorph. Ideally it would be good if all classes had the option to specify up to the 6 spells that can be bound to and their corresponding effect colour/type.

After rereading the documentation I'm still unsure if by editing the macro I could use it and the MuFs to achieve the desired results or if a third party addon such as clique could be used to to achieve this.

What version of the product are you using (give the version string)?

Do you have an error log of what happened?

Please provide any additional information below.

PLEASE: AFTER POSTING YOUR TICKET, YOU MUST ABSOLUTELY GO TO THE SUBSCRIPTION TAB ABOVE AND SUBSCRIBE TO 'TICKETS' ELSE YOU WON'T GET NOTIFIED ABOUT YOUR TICKET'S UPDATES.
IF YOU DON'T PLAN TO ANSWER FURTHER QUESTIONS AFTER POSTING THEN SAVE US BOTH SOME TIME AND JUST DON'T POST.
THANKS

Something I have noticed for helping out with this problem and if you are glyphed for it, Dragons Breath is far superior and faster response to using decursive to break the MC.

I had skipped the answer to "I have set my hot key. When I push it though I don't cure anything." in the Faq. Reading that it says the Decursive Macro can be used in conjunction with the MuFs however I still think it would be nice to have the optional configuration for which spells are to be used for which effect/color instead of only having the automatic configuration.

Yes you can use the macro for that or create another mouse-over macro and bind it to a key using http://www.wowace.com/addons/spell-binder (use the alpha package only).

http://www.wowace.com/addons/decursive/pages/main/macro/

I'm not very keen on implementing the possibility to alter the default mapping, this could lead to a ton of issues and confusion...

My idea is that by default decursive would remain as is and automatically configured but that either manually through some instructions given by you or via the interface it would be possible to change which spell is associated with which number assignment. Via the interface this would be done by letting the users input the spell associated with numbers 1-6 under Curing Options. The rest of the choices already exist in the interface, Mouse Buttons and Colors Tabs under Micro Unit Frames. The only area I can think of which might need further changes is tooltips.

Is it possible given the way the addon is structured to edit some configuration file to manually add/change which spells are assigned to numbers 1-6? The rest of the configuration already seems to be in place since you can change the color/buttons for 1-6 even if the automatic configuration detects only one type of cure available.

I don't know what confusion you foresee it leading to but if it's complicated to implement I can understand your reservation.

The confusion would be for users who don't read the documentation and will try to modify default spells... and then for me when those users will have issues because of what they did.

Anyway, it can easily be done, I just need a way to limit the confusion it could create.

I would hope if the default configuartion remained as is that would prevent most confusion. Further to that and without having to add in a lot of idiot proofing and/or sanity checks you could make the change hidden and only visable though some flag or switch. For example you could require a some variable to be changed at the top of the dcr_opt.lua and which is only documented in the readme.txt.

I noticed in the 2.6.1 Todo.txt that you are already planning to give the option to choose from available spells which I would think would require you deciding on a class by class basis what those spells are and what they can "cure". That is I bit more limiting than what I had in mind though it is valid way of idiot proofing. Is that something else you already had in mind or is that how you have decided to make this work?

it's implemented in the latest alpha. Please, test :)

Sorry missed the update till now and the servers are currently down so can't test immediately. I had been tracking the alpha changes and have now had a look at the latest changes.

Nice Work.

I'll rope in some other decursive users to try out the latest alpha too but I'm fairly confident you've done this well. Is cmdhidden going to be a flag that needs to be set for this to show under Curing Options or will this now be part of the the options by default.

Thanks again.

I have played around with changes for a few hours now and it all seems to work but 2 things might cause some novice users problems.

If a user adds in a spell and enables it so that it is assigned a click but then removes the spell, the click is not reassigned until the session is restarted by logging out/in, reload ui etc. This could cause a novice user a problem if they enable an added in spell and have assigned it to cure type the automated configuration gives them anyway.

For example if I enable Counterspell as charmed cure, by default has a priority of 10 and will replace Polymorph as the mouse click for charmed. If I then removed counterspell using the remove button but do not reload the ui, the click for charmed will still be counterspell and not revert to Polymorph till the session is restarted. By the way you seem to have hard coded counterspell as an added in spell for Mages, it can not be permanently removed using the remove button as it is restored after a session restart.

Secondly, there is no plain language error if a user tries to add a spell that won't work for some reason. For example, if a user tries to Add in a different version of Polymorph then all that will happen is the Error OPT_INPUT_SPELL_BAD_INPUT and possible a LUA Error.

I think the documentation could give some better instructions. For example how you can use either Mouse Buttons or Curing Options to change which button is assigned to what. In particular it should be pointed out to users that they can under Curing Options change the order of the cures types by deselecting all cures and then clicking the cure types in the order they wish to have them assigned to the mouse buttons.

I'll update again if I come across anything else but I think some documentation changes/additions would "fix" any of the current problems as they can easily be worked around if you know how to configure decursive. I'd be happy to do the English Language changes if you want a hand.

For users who are not novices it should all be working fine and I think is a great change to the addon.

Thanks :) It's fixed in the latest alpha (see the change log)
I'll make the changes to the documentation tomorrow.

Ok in latest alpha, I've updated descriptions and names in various concerned option panels, tell me what you think.

Hi,

Yes the new instructions are much better but some minor changes might make them crystal clear.

You seem to use the term priority and order with reference to the same thing. It would be better to use one term consistently to avoid possible confusion. In addition to the consistent use of labels I feel some descriptions might lead to some confusion.

Here are the changes I'm suggesting be made to the enUS localisation file.

L["OPT_CURINGOPTIONS"] = "Curing Options"

L["OPT_CURINGOPTIONS_DESC"] = "Curing options including options to change the Priority # and spells for each affliction type"

L["OPT_CURINGOPTIONS_EXPLANATION"] = [=[Select the types of affliction you want to cure, unchecked types will be completely ignored by Decursive.

The green numbers are the Priority # associated with each affliction type. This Priority # determines the following options:

- Which affliction type Decursive shows you first if a player has several afflictions types.

- The color and binding associated with each affliction type.

(To change the order of the Priority #s, uncheck all the Curing Priority check boxes and then check them in order of the priority you want.)]=]

L["OPT_CURINGORDEROPTIONS"] = "Cure Priority"

L["OPT_MUFSCOLORS_DESC"] = "Options to change the color for each Priority # and various MFU Info.

Each Priority # represents a different affliction type as specified in the 'Cure Priority Options' tab of the '|cFFFF5533Cure Options|r' panel. "

I would suggest you edit dcr_opt.lua so that this desc appears at the top of the OPT_MFUSCOLORS Tab like you have the desc OPT_MUFMOUSEBUTTONS_DESC appearing at the top of the OPT_MUFMOUSEBUTTONS Tab. Currently it only shows as a tooltip on mouseover of the tab.

L["OPT_CREATE_VIRTUAL_DEBUFF_DESC"] = "Lets you see how Decursive looks when an affliction is found."

L["OPT_MFSETTINGS"] = "Micro Unit Frame Options"

L["OPT_MFSETTINGS_DESC"] = "Set various MFU and Priority # options"

L["OPT_MUFMOUSEBUTTONS"] = "Bindings"

L["OPT_MUFMOUSEBUTTONS_DESC"] = [=[Change the bindings used to cure, target or focus group members via the MFUs.

Each Priority # represents a different affliction type as specified in the 'Cure Priority Options' tab of the '|cFFFF5533Cure Options|r' panel.

The cure for each affliction type is set by default but can be changed using the Custom Spells Tab of the '|cFFFF5533Cure Options|r' panel.]=]

I have made some other small corrections along with these changes to enUS.lua and can email that if you want. If I get a chance I'll see if I can suggest more improvements to the enUS localisation and revise the documentation a bit.

I still need to do more testing on the Spell Priority, I think the Spell Priority of the default/pre configured spells should be listed and any limitations on setting spell priority should be documented. I have not checked but I think it is impossible to add a new spell that would have a lower priority than the default/pre configured spells.

Ok, I've implemented your changes but with a different wording. Tell me if it's OK, (English is not my native language).

Send me your modifications to enUS.lua.

thanks for your time :)

Hi,

Thanks again for all your hard work up to date. I have not yet sent you the localisation file since I've been busy doing further testing and getting more familiar with the inner workings of Decursive. I hope to send it later today or tomorrow at latest after I have had a chance to update it with the changes you have already made. As it stands I think the changes you have already made should be enough to avoid confusion in most cases.

I do have some minor concerns though to report.

1. Default/Example Spells I don't know if your aware that although Counterspell can now be removed from the user added spell list doing so stops you from being able to add it back in at a later stage. Now after removel it no longer reappears in the list of user added spells after a session reload/restart but if a user tries to add it back in at a later stage they get a "spell is already on the list error". This is a problem since it means users can't enable/disable it or change the prioity. This can only be worked around by deleting the decursive.lua variables file or manually editing that file to remove the counterspell entry from it.

For the moment I think it would be much better to return to the previous behaviour by setting IsDefault = false for it or commenting that line out. This way the spell will still reappear on the added spells list after a session restart, but will be disabled even if the user did not disable it before they attempted to remove it.

If you want to "fix" this behaviour then I would suggest that instead of letting the spell be removed from the list, any default/example spells should generate an error if you try to remove them, saying they cannot be removed.

For my own personal preference I moved the default mage spells (Remove Curse and Polymorph) from dcr_init.lua to dcr_opt.lua. I entered them in a similar manner to the Counterspell example but with a value of 0 for Priority/Better and with their IsDisabled and IsDefault flags set to false.

This modification appears to work without any problems. No initial configuration is required from the user and if they choose to add in another spell with an affliction type matching one of the default spells, then the new spell will still replace the default spell. The priority/Better value of the default spell will not change unless the user changes it, even if that value is outside the range allowed by the slider.

Unless there is some reason why you need to have the defaults in dcr_init.lua such such as backwards compatibility for Chinese or Private Realm users then I think it is better to have them this way, especially if the IsDefault behaviour is changed so that default/example spells give and "spell cannot be removed" error when the user tries to remove them. Even without any change to the is IsDefault behaviour, by setting that flag to false (or commenting the line out) there is no risk of a novice foobaring the configuration since the spells will not be permanently removed from the User Spell List.

2. One other slight problem with adding/removing spells only happens if the user chooses to add a new spell by typing it's name instead of using the spellbook or spellID to add it. In this case the user can enter the same spell multiple times.

The "The Spell is already on the List" error will only be generated if the exact same characters as an existing spell are entered, in other words the name check is not case sensitive at the moment. This isn't a major problem since users are unlikely to add the same spell more than once and if they do it by accident then as long as the newest entry has a Priority/Better value >= the existing copy, the newest entry takes precedence. The only area where it might cause real problems is if the user adds the spell again but with a lower priority, forgetting that they already have it listed or because they don't realise they can change any of the variables by clicking on the the existing list entry and changing it's variables.

This can be fixed by removing the spell priority slider as it is only needed to let users retain a large list of redundant spells. Since there can only be one active spell per affliction type this functionality is not required at the moment, though it could be more useful at some stage. The Priority/Better value of new spells can be set to a fixed value thus ensuring the newest addition for that type always take precedence.

Alternatively you could modify the duplicate spell error check so that when the user attempts to add a new spell by typing it's name, the new entry is checked to see if it's spellID matches any existing SpellID on the list or by using any other method where new entries are checked against the existing entries in a case sensitive way.

3. This question and answer maybe should be included in the FAQ. How can I have 2 or more cures for an affliction type. The short answer is you can't but there is a simple work around. You can achieve the desired result by adding the new spell with a "dummy" affliction, by using an affliction type than is not already in use. You can determine which affliction types are already in use by looking at Curing Options. Any of the unchecked affliction types can be used and by adding the second spell as a cure for that type you will be able to keep your existing or default spell in addition to the second spell. Note you will have to remember that you now have 2 binds which can cure the same affliction. The cure spell that uses the "dummy" affliction type will say there was nothing to cure even though it is correctly curing.

I need to test this one a bit more and It should be obvious if anyone thinks about it but I know people often tend not to think and go looking for help straight away instead.

Sorry this has taken a lot longer to type than I planned so I doubt I'll get much more done tonight but I'll get back onto it tomorrow. Unfortunately I have to type very very slowly.

I fixed 1 and 2 in the latest alpha

I prefer to let users delete default custom spells if they want to, there is a confirmation warning and they can add them back if they want.

Original spells will remain in Dcr_init.lua, I do not want users to be able to alter them because this will lead to issues such as "Decursive is not showing debuff for XXX", in this case I will have to make sure they didn't damage default settings, this would make support really tricky and annoying for me.
Moreover users get no benefit by having access to the default configuration, this would only create confusion. One of the most important feature of Decursive is its automatic configuration.

The spell priority slider is useful for non permanent spells (such as spells from pet or talent spec related spells). This slider allows the possibility to set fall-back spells.

about 3, your solution has a problem: Decursive will alert you whenever someone is afflicted with the dummy affliction type that you can't cure.
The existing solution to this is to modify the mouseover macro generated by Decursive (if you have many buttons on your mouse you can bind one to this macro)

The latest Alpha looks good, tested it on Cho'gall tonight and worked a like a charm (pun intended).

Re 1 & 2. I've beening testing the latest alpha and so far no problems.

The solution I provided to you also keeps the automatic configuration intact, but does let the users change the priority and the affliction type association of the default spells. While it could lead to the specific problem you mentioned that can only happen if the user changes the settings, you could easily give them a nice big scary message warning them they are about to do so and asking for confirmation. On top of that you can require as the initial step when logging a problem that users take a copy of their decursive.lua variables file and then delete it in order to make sure that the problems are not part of some configuration change they have made. That's pretty normal these days.

I would suggest that given all the options that users will have with the various changes you are making it would be a good way to go and is the approach used by many others. The trickiest part of that is finding out where that file is located since the location is different with different versions of operating systems. I can give you the list of locations for the various current flavours of Windows if if you don't know them already.

I have 2 reasons why I suggested the solution.

a) I hate only only pointing out problems, I'd like if I can at least offer some kind of solution to them at the same time. b) I have in mind some things I want to do with Decursive when you implement your other planned changes that may require me to be able to change the priority and affliction type of the default spells and I'd prefer if that ability was built in.

Re: why the Spell Priority slider is needed now that has reminded me I have yet to do any testing with Pet Spells. It makes sense know but I should point out that out the default custom spell takes priority over user added spells if the user does not set the added spell to have a higher priority. Other wise if priorities are the same then the active spell will be the one which appears highest in the list with is seems to be sorted alphabetically Z-A descending. A warning that 2 or more spells have the same priority would be a nice if you get the chance at some stage but I wouldn't view it as a priority.

Re: 3, Yes I was aware of that behaviour, it will also mean that when the Spell is used on Target that does not have an affliction of the dummy type will generate a there is nothing be be cured error. I see it as a small price to pay atm. Maybe it is just me but I prefer not to have to use the macro as I already have enough key bindings without have to use another for the marco. Ideally I'd like to figure out a way to have 2 or more spells active with one affliction type and/or to leave a spell not associated with any affliction. In my case for example I want to use counterspell and polymorph on the Cho'gall encounter (a Mage with Impact, Deep Freeze or Dragon's Breath might want to use them, (Warlocks, Priests and others also have multiple spells that can work there).

Quote:

I have in mind some things I want to do with Decursive when you implement your other planned changes that may require me to be able to change the priority and affliction type of the default spells and I'd prefer if that ability was built in.

Why would users need to change the priority or the affliction types associations of the default spells?

Quote:

On top of that you can require as the initial step when logging a problem that users take a copy of their decursive.lua variables file and then delete it in order to make sure that the problems are not part of some configuration change they have made. That's pretty normal these days.

65% of users reporting issues never replies to inquiries... The less report I have due to PBKAC issues the better I feel :)
I'm sure you're familiar with Murphy's law: If something can be used the wrong way, it certainly will.

Quote:

I would suggest that given all the options that users will have with the various changes you are making it would be a good way to go and is the approach used by many others.

I've been developing Decursive for more than 5 years now.

Quote:

It makes sense know but I should point out that out the default custom spell takes priority over user added spells if the user does not set the added spell to have a higher priority. Other wise if priorities are the same then the active spell will be the one which appears highest in the list with is seems to be sorted alphabetically Z-A descending. A warning that 2 or more spells have the same priority would be a nice if you get the chance at some stage but I wouldn't view it as a priority.

User added spells always have a higher priority than the hard coded ones.

It may be that you want user added spells to have a higher Priority than the Hard Coded spells BUT in the case of the Custom Added spell the testing I did today showed me that if you get a silly user enabling Counterspell for Charmed and then adding in another Spell to say for Example Polymorph(Pig) for Charmed then Counterspell will still have priority if the User did not adjust the Default priority of either.

In the case the same kind of silly user adds any 2 of more spells for the same affliction type the priority will be down to which spell is nearest the top of the list which seems to be sorted in the manner I describe.

As to why users might need to change the affliction type associations of the Default Spells, because Murphys Law says there may be a situation where it is needed and then we will not be able to use Decursive without resorting to a macro or unless their is a multiple ranks situation like with Polymorph. It may also be that with future changes having the ability to change the affliction type and priority of the default spells might bring functionality benefits. On top of these reasons it's my personal preference to have the ability to modify the configuration as much as possible because it lets me then see what might be possible. For example if one of the default spells becomes unavailable is it possible to have a fallback. I can give senario's where default spells would be temporarily unavailable but an alternative solution is available. I don't know what the behaviour is in such a case at the moment because I've never had the option prior to now to test and see. It is up to you, I can understand why your reluctant to let the defaults be changed, the only real benefit at the moment is that through the workaround I mentioned before it will enable users to configure multiple active spells for use with a specific affliction type, something which would be nice to have. You'd prefer that for that situation people create a macro but not all of us like having yet another key to press.

The testing I'm doing is because I'm all too aware of Murphy and his Law or versions there of.

As I said I can understand why you feel that way I have previously worked in techincal support roles and as a developer for many years but maybe one of the reasons why 65% of issues reported never reply to enquires is because those users are advised by other users to reset to defaults, upgrade versions or how to otherwise "fix" the problem they have? It's no surprise they then drop the enquiry if it turns out they were able to rectify the "problem" or have the query answered.

A quick glance over at the Curse page for the latest release of Decursive shows me that your not the only one offering advise to users and it is entirely possible many users reporting problems are advised to reset or try other things. Even if no one tells them they should try x,y,z many users will look to see if anyone else has described the issue they are having or if the question they have has been asked before. It is not unusual at all that they do this having first posted a request so they too are unlikely to reply to enquires.

I'm not casting aspersions on your abilities I'm offering unsolicited advice along with bug testing results, your free to take one or neither.

Quote:

It may be that you want user added spells to have a higher Priority than the Hard Coded spells BUT in the case of the Custom Added spell the testing I did today showed me that if you get a silly user enabling Counterspell for Charmed and then adding in another Spell to say for Example Polymorph(Pig) for Charmed then Counterspell will still have priority if the User did not adjust the Default priority of either.

I know that but users should be able to understand this by themselves (the color of the spell is also a hint).

Quote:

In the case the same kind of silly user adds any 2 of more spells for the same affliction type the priority will be down to which spell is nearest the top of the list which seems to be sorted in the manner I describe.

Actually the list is displayed in alphabetical order but it's not parsed in any order in particular.

Quote:

As to why users might need to change the affliction type associations of the Default Spells, because Murphys Law says there may be a situation where it is needed and then we will not be able to use Decursive without resorting to a macro or unless their is a multiple ranks situation like with Polymorph. It may also be that with future changes having the ability to change the affliction type and priority of the default spells might bring functionality benefits.

Murphy's law should never be used in reverse, using it that way is like amplifying the odds to get unexpected and terrible problems...

It's better to keep things simple whenever possible. Right now letting users change default spells only give them the possibility to break Decursive... I don't see the point!

If this feature really becomes necessary, it's not difficult to implement (as you already know).

Quote:

On top of these reasons it's my personal preference to have the ability to modify the configuration as much as possible because it lets me then see what might be possible. For example if one of the default spells becomes unavailable is it possible to have a fallback. I can give senario's where default spells would be temporarily unavailable but an alternative solution is available. I don't know what the behaviour is in such a case at the moment because I've never had the option prior to now to test and see.

I understand but you should already know what spells you can use to dispel, and you should expect Decursive to do its job and select the correct spells, if doesn't then this is a bug and you should report it.

Now there are also more complex things that are difficult to implement in a user configurable way: talent enhanced spells (such as 'Cleanse Spirit' which can also cure magical afflictions if you have the 'Improved Cleanse Spirit' talent)

So I prefer to keep things simple for now and see how people will react to this new feature before doing too much.

Quote:

As I said I can understand why you feel that way I have previously worked in techincal support roles and as a developer for many years but maybe one of the reasons why 65% of issues reported never reply to enquires is because those users are advised by other users to reset to defaults, upgrade versions or how to otherwise "fix" the problem they have? It's no surprise they then drop the enquiry if it turns out they were able to rectify the "problem" or have the query answered.

Maybe but for me it's just very frustrating, and most of the time it's just because they don't care... I've lost tens of hours looking into issues for nothing, just because I didn't have enough information.

@Nerdling: I'm not sure if you'll read that but I've made an important change in the latest alphas: it's now possible to edit the internal macro used by Decursive. Moreover, if you choose to use this option you can also edit the macro used by each default spell (with the possibility to add different spells using modifiers).