Is there a way to support the vehicle frame / Healing guid suggestion ? I am not familiar how blizzard handles those internally.
I'm going to answer the question I think you're asking. Let me know if this is not the case.
The WoW client has the information, it just needs to be made available to the interface. There currently isn't a reliable way for the interface (and addons) to determine the exact target of a spell being cast if there are multiple units with the same name because only the name is provided.
I'm going to answer the question I think you're asking. Let me know if this is not the case.
The WoW client has the information, it just needs to be made available to the interface. There currently isn't a reliable way for the interface (and addons) to determine the exact target of a spell being cast if there are multiple units with the same name because only the name is provided.
I meant something completely different.
I would love to see the support for both in grid, but the current API does not support it. You have already posted a suggestion. Per forum rules post for signs / petitions are not allowed.
Do you know of a way to make the (blizzard API) developers aware that this might be usefull in a non-obtrusive manner ?
I would love to see the support for both in grid, but the current API does not support it. You have already posted a suggestion. Per forum rules post for signs / petitions are not allowed.
Do you know of a way to make the (blizzard API) developers aware that this might be usefull in a non-obtrusive manner ?
I've been doing some searching among the settings and the available addon modules out there but can't find the answer to this.
Is there a way to make it so that your own unit frame always shows up in the same position? For example, I'd like mine to always show up bottom-right or bottom-left so it's easier to keep an eye on myself in battlegrounds.
I've been doing some searching among the settings and the available addon modules out there but can't find the answer to this.
Is there a way to make it so that your own unit frame always shows up in the same position? For example, I'd like mine to always show up bottom-right or bottom-left so it's easier to keep an eye on myself in battlegrounds.
You could create a custom layout that showed yourself in a separate column (or row depending on your settings). You'd still be duplicated in the main group though.
Another approach is a custom sorting with your class being first / last. This would give you a vaguely stable column that you are in (depending on duplicate classes in your group). I have been toying with sorting tank classes to one end as well to minimize my mouse travel distance while rotating hots.
Perhaps there should be (already is?) a status for various unitid's? That way you can put a glowing border around yourself or something. GridStatusParty could also add this in addition to the other party statuses it provides.
As I am running around ninja updating various statuses for the coming of Guid Grid, I am puzzled about the intended behavior for disabled / enabled statuses vs them being used / not used.
There are 4 cases:
*Enabled and used. Fully functioning, so it should work.
*Enabled and not used. In theory it may as well be disabled.
*Disabled and not used. Should be completely shut down and not use any overhead / processing time. All callbacks unregistered.
*Disabled and used. Should be completely shut down, and only activate if enabled again.
The code dealing with these situations varies wildly. Many times a status lost is sent both if it is actually lost and if the status is disabled. This means there is a lot of useless signaling going on for disabled statuses.
Ideally working statuses do their thing based on actual conditions, and a separate mechanism causes a particular status to disable and universally shut down.
So finally in a nutshell is the intended behavior as follows:
*Grid calls OnEnable() if a status is both enabled and being used.
*Grid calls OnDisable() if a status is not both enabled and being used.
*Based on these two calls a status is either enabled and processing whatever it needs to, or disabled since its callbacks are shut down.
*OnDisable() includes code to send status lost as well as shutting down callbacks.
All right, GridStatusParty got the initial guid ninja-alpha-checkin treatment. It has no forum of its own that I could detect so I am announcing it here.
I guess at this point I may as well do GridStatusRes, GridStatusAFK and GridStatusPvP at which point all the statuses I actually use currently will be done.
So thats more than a Druid needs in Grid.
I kind of want it all ready to go for Priests, Paladins and Shamans as well though, so if there are Status modules you guys use that need updating let me know. I will not be able to test those (if any) so if someone else could volunteer for that it would probably be better.
Good thinking, however this is now incorporated into Grid (and thus obsolete). Also, the guid branch is merged into the main branch as the alpha at the moment, so you can get a jump on things and start testing for your set of Grid modules.
So finally in a nutshell is the intended behavior as follows:
*Grid calls OnEnable() if a status is both enabled and being used.
*Grid calls OnDisable() if a status is not both enabled and being used.
*Based on these two calls a status is either enabled and processing whatever it needs to, or disabled since its callbacks are shut down.
*OnDisable() includes code to send status lost as well as shutting down callbacks.
Disabled statuses need to be handled better.
Grid only knows when a status is registered or unregistered. It's up to the status module to do the right thing when a status is disabled. Since a status module can register multiple statuses, Grid can't just call OnEnable/OnDisable.
An unused status will still do its thing since things other than GridFrame (notably GridAlert) can listen for status events.
Disabling a status should send status lost and the status module should unregister any events it was using.
All right, lets pick some status to use as a best practices example and fix it. If it requires core changes then that can wait till after the coming of the Guid. If it just needs better coding in the statuses then we can fix the sample anytime and then start spreading it around.
My gut feeling without looking at it is that a callback to the module after clicking on the "enable" checkbox would be helpful. It could pass the registered status back or just let the module figure it out from the db:
function GridStatusXXX:OnEnableChanged(status)
if (db[status].enabled) then
self:UpdateAllUnits()
else
self:DisableAllUnits(status)
end
end
That looks pretty reasonable. I'll give it a go tomorrow.
r1120 adds OnStatusEnable(status) and OnStatusDisable(status)
function GridStatusMana:OnInitialize()
self.super.OnInitialize(self)
self:RegisterStatus("alert_lowMana", L["Low Mana warning"], low_manaOptions, true)
end
function GridStatusMana:OnStatusEnable(status)
if status == "alert_lowMana" then
self:RegisterEvent("Grid_UnitJoined")
self:RegisterEvent("UNIT_MANA", "UpdateUnit")
self:UpdateAllUnits()
end
end
function GridStatusMana:OnStatusDisable(status)
if status == "alert_lowMana" then
self:UnregisterEvent("Grid_UnitJoined")
self:UnregisterEvent("UNIT_MANA")
self.core:SendStatusLostAllUnits("alert_lowMana")
end
end
All right, GridStatusParty got the initial guid ninja-alpha-checkin treatment. It has no forum of its own that I could detect so I am announcing it here.
I guess at this point I may as well do GridStatusRes, GridStatusAFK and GridStatusPvP at which point all the statuses I actually use currently will be done.
So thats more than a Druid needs in Grid.
I kind of want it all ready to go for Priests, Paladins and Shamans as well though, so if there are Status modules you guys use that need updating let me know. I will not be able to test those (if any) so if someone else could volunteer for that it would probably be better.
Can you do GridIndicatorText3 and GridStatusMTs?
I think you have covered all the others that are heavily used that I know of.
Can you do GridIndicatorText3 and GridStatusMTs?...
Kunda already did GridStatusMT, and GridIndicatorText3 needs no changes as it is an indicator, not a status.
At this point the only wowace hosted ones left to do are:
GridStatusHostileUnit
GridStatusShield
GridStatusMending
GridStatusGrace
GridStatusKalecgos
GridStatusControlPipes
I am going to start using GridStatusHostileUnit and convert it as well. I have code for GridStatusRes, I need to test it in raid tonite (assuming we wipe) before checking it in though..
I do not have a priest so I could not test any changes made to Shield / Mending or Grace. If people are in fact using Shield I am happy to check in dry code and debug it via forum posts or tickets. It looks like Mending and Grace are clones of GridStatusLifeBloom, so I am going to upgrade both of them.
Kalecgos is probably not needed as it is an obsolete fight.
I'm going to answer the question I think you're asking. Let me know if this is not the case.
The WoW client has the information, it just needs to be made available to the interface. There currently isn't a reliable way for the interface (and addons) to determine the exact target of a spell being cast if there are multiple units with the same name because only the name is provided.
I meant something completely different.
I would love to see the support for both in grid, but the current API does not support it. You have already posted a suggestion. Per forum rules post for signs / petitions are not allowed.
Do you know of a way to make the (blizzard API) developers aware that this might be usefull in a non-obtrusive manner ?
They know.
Is there a way to make it so that your own unit frame always shows up in the same position? For example, I'd like mine to always show up bottom-right or bottom-left so it's easier to keep an eye on myself in battlegrounds.
Not really.
Perhaps there should be (already is?) a status for various unitid's? That way you can put a glowing border around yourself or something. GridStatusParty could also add this in addition to the other party statuses it provides.
Mmm, I sense another guid branch ninja-commit.
There are 4 cases:
*Enabled and used. Fully functioning, so it should work.
*Enabled and not used. In theory it may as well be disabled.
*Disabled and not used. Should be completely shut down and not use any overhead / processing time. All callbacks unregistered.
*Disabled and used. Should be completely shut down, and only activate if enabled again.
The code dealing with these situations varies wildly. Many times a status lost is sent both if it is actually lost and if the status is disabled. This means there is a lot of useless signaling going on for disabled statuses.
Ideally working statuses do their thing based on actual conditions, and a separate mechanism causes a particular status to disable and universally shut down.
So finally in a nutshell is the intended behavior as follows:
*Grid calls OnEnable() if a status is both enabled and being used.
*Grid calls OnDisable() if a status is not both enabled and being used.
*Based on these two calls a status is either enabled and processing whatever it needs to, or disabled since its callbacks are shut down.
*OnDisable() includes code to send status lost as well as shutting down callbacks.
I guess at this point I may as well do GridStatusRes, GridStatusAFK and GridStatusPvP at which point all the statuses I actually use currently will be done.
So thats more than a Druid needs in Grid.
I kind of want it all ready to go for Priests, Paladins and Shamans as well though, so if there are Status modules you guys use that need updating let me know. I will not be able to test those (if any) so if someone else could volunteer for that it would probably be better.
Good thinking, however this is now incorporated into Grid (and thus obsolete). Also, the guid branch is merged into the main branch as the alpha at the moment, so you can get a jump on things and start testing for your set of Grid modules.
Disabled statuses need to be handled better.
Grid only knows when a status is registered or unregistered. It's up to the status module to do the right thing when a status is disabled. Since a status module can register multiple statuses, Grid can't just call OnEnable/OnDisable.
An unused status will still do its thing since things other than GridFrame (notably GridAlert) can listen for status events.
Disabling a status should send status lost and the status module should unregister any events it was using.
All right, lets pick some status to use as a best practices example and fix it. If it requires core changes then that can wait till after the coming of the Guid. If it just needs better coding in the statuses then we can fix the sample anytime and then start spreading it around.
My gut feeling without looking at it is that a callback to the module after clicking on the "enable" checkbox would be helpful. It could pass the registered status back or just let the module figure it out from the db:
or something like that.
That looks pretty reasonable. I'll give it a go tomorrow.
r1120 adds OnStatusEnable(status) and OnStatusDisable(status)
nice
are more separate status modules added to the core? if so, which modules will be added?
I can't think of anything else I'd want to add.
Can you do GridIndicatorText3 and GridStatusMTs?
I think you have covered all the others that are heavily used that I know of.
Kunda already did GridStatusMT, and GridIndicatorText3 needs no changes as it is an indicator, not a status.
At this point the only wowace hosted ones left to do are:
GridStatusHostileUnit
GridStatusShield
GridStatusMending
GridStatusGrace
GridStatusKalecgos
GridStatusControlPipes
I am going to start using GridStatusHostileUnit and convert it as well. I have code for GridStatusRes, I need to test it in raid tonite (assuming we wipe) before checking it in though..
I do not have a priest so I could not test any changes made to Shield / Mending or Grace. If people are in fact using Shield I am happy to check in dry code and debug it via forum posts or tickets. It looks like Mending and Grace are clones of GridStatusLifeBloom, so I am going to upgrade both of them.
Kalecgos is probably not needed as it is an obsolete fight.
Is anyone using GridStatusControlPipes?