I notice that on Curse.com that each time I force a new tagged release of Ovale, that its idea of what is the latest release keeps incrementing to the next tag newer than the previous one. So, when I accidentally pushed the old tags, it thought 3.0.0 was the latest. When I pushed 5.4.25, it thought 3.0.1 was the latest, and now that I've pushed 5.4.26 it now thinks 3.0.2 is the latest.
Is there somewhere in the packager that caches what's considered the "latest" tag that can just be changed to point to 5.4.26?
- Registered User
Member for 11 years, 10 months, and 21 days
Last active Wed, Aug, 12 2020 13:31:52
- 0 Followers
- 148 Total Posts
- 0 Thanks
Jul 15, 2014 Posted in: General Chat
Jul 15, 2014I just tagged 5.4.26 and the packager listed all of the old tags again as needing to be handled, so it's going through the same "explosion" again and packaging up all of the old tags again.Posted in: General Chat
Jul 15, 2014I accidentally pushed all of my old tags to the CurseForge Git repository for Ovale and now the packager and Curse.com list the 3.0.1 tag as the latest release and not the actual 5.4.25 tag. How can this be fixed?Posted in: General Chat
Jul 14, 2014Ovale Spell Priority is a rotation-helper addon with a feature to show the keybinding associated with the spell that it suggests and display it as a hint for the user.Posted in: General AddOns
Basically, it hooks ACTIONBAR_SLOT_CHANGED to use GetActionInfo(slot) on the changed slot, and maps that slot number to a name, e.g. ACTIONBUTTON9, and uses GetBindingKey(name) to get the current keybinding for that spell. This works fine with the default action bars, but does not currently work for people using Bartender4. What's the right way to get this same information from Bartender4?
Jul 14, 2014Ovale was recently migrated from SVN to GIT on CurseForge. I'd like to re-tag the repository so that I can see which commit points are for which old releases. I'm worried that if I add the tags now, even if I use GIT_COMMITTER_DATE to set the backdate the tags, that the packager will pick them up and try to make new packages for these old tags. Is this something I should be worried about? What's the best way for me to restore some of the tag/branch history?Posted in: General Chat
Dec 13, 2013For what it's worth, there was a Grid status module that had these types of display options: GridStatusHots. It's not maintained anymore, but it started out as a fairly simple HoT duration/stack tracker. Its problem was that along the way, it exploded in needless complexity by offering so many different display options and tracking so many hard-coded auras that its codebase size increased by an order of magnitude (or two!).Posted in: Grid & Grid2
Looking at the GridStatusHots codebase was the reason I was motivated to contribute a much smaller, focused extension to Grid to show only duration and stacks, only in text or color, and still allow users to dynamically add additional auras to track -- that covers the needs of most users.
Dec 9, 2013Posted in: Grid & Grid2Quote from Winney1907You also have multiple ways to refresh lifebloom now. If you colour based on time left you wont know for sure if you have time left to renew it via regrowth or nourish.
Why can't you choose your color thresholds so that you can tell the difference? Make the colors red/yellow/green for low/medium/high, then set low color threshold to 1.5s for refresh with Lifebloom, high color threshold to 2.5s for refresh with Nourish. Then you know what you need to cast to refresh the stack -- red = LB, yellow = Regrowth, green = Nourish, and you can still set the status text to show stack count if you want.
We're talking about a tracking a single stack of Lifebloom most of the time, with the exception being when you cast Tree of Life and can actually start spamming Lifebloom on many, many people. But when you're in ToL form, are you actually trying to refresh LB stacks using anything but LB or mana-free Regrowth?
I'm trying to see your use-case here as a druid healer in 25-mans, but I guess I'm not really getting it.
Dec 5, 2013Posted in: Grid & Grid2Quote from PhanxAs I see it, there is no reason you ever need to see both the duration and the count as text. Most auras do not actually require 100% uptime. The only one I can think of off the top of my head is Lifebloom since you lose your whole stack if you let it drop. In the rare case where the exact duration actually matters and you want to show the aura as text (rather than on the center icon) I believe you should do just fine using the text to show the duration, and the color to show the stack count (eg. green = 3, yellow = 2, red = 1) or vice versa.
Dealing with Lifebloom in the manner you describe was one of the examples for using the advanced aura options when they were added.
I've healed on every single class using Grid and I don't see any need to show both stack count and duration as text simultaneously. The reasoning is that the only property of an aura that changes continuously is the time remaining; every other property is discrete. The text indicator is the only one that can truly show a continuously changing quantity, but everything else can be done with color indicators. Even time remaining isn't truly necessary to show in a text indicator because of the way that HoTs refresh -- refreshing within the last tick of a HoT will extend the HoT after the end of the final tick so it doesn't matter when you refresh the HoT within the final 2-3 seconds of the final tick (depending on your haste). For most situations, you just need to know that a HoT within 2-3 seconds of ending really needs to be refreshed, but otherwise, you don't really care. In that case, you can show the time remaining using color and set the color thresholds appropriately, e.g., red is less than 3 seconds, green is more than 6 seconds, and yellow in-between.
The only case I really needed to see time remaining as text was on my druid in Tree of Life form and trying to keep up Lifebloom on everyone in the raid. With multiple Lifebloom stacks that needed to be refreshed before expiration, I needed to prioritize which stack to refresh.
Aug 9, 2013Do all events only fire in response to a reply from the WoW servers?Posted in: Lua Code Discussion
For example, does UNIT_SPELLCAST_SENT fire when the client initially sends a spellcast request to the server, or does it fire when the client receives an acknowledgement from the server that a spellcast request has been received?
If some events can fire without any server message being received, is there a list of those events?
Jun 28, 2013How does one take a snapshot of player stats that applies to a player's DoTs when they are applied? For instance, suppose I'm tracking a moonkin's Moonfire DoT to figure out whether I should overwrite an existing DoT. I would need to store the player's stats at the time a Moonfire DoT was applied and then compare that damage to the damage of a current Moonfire.Posted in: Lua Code Discussion
Druids can spec into a talent, Dream of Cenarius, that increases the damage of their next Moonfire by 50% after casting a healing spell. This is implemented as a buff gained by the druid that is consumed by the next Moonfire cast.
A naive implementation would hook into UNIT_AURA and when I see that Moonfire is applied on the target, I take a snapshot of the current relevant stats for that Moonfire DoT using:
- UnitAura (to check for the DoC buff)
Mar 30, 2013Is there some extra step that needs to be done to ensure that my addon update gets pushed through the Curse Client? Ovale 5.2.25 is up on Curse.com, but the Curse Client still only shows 5.2.24.Posted in: General Chat
Mar 14, 2013I've noticed that when I have this problem, that if I delete the tag that I pushed and re-tag, it'll get re-noticed by the packager and placed into its queue again.Posted in: General Chat
It's not guaranteed to get packaged the second time either, but at least it gives me a chance to force the packager to run again without needing to hassle a moderator.
- To post a comment, please login or register a new account.