I noticed this am that WAU is not updating addons beyond Manufac in alphabetic order. If you try to select them individually it still does nothing. However if your reverse the order it updates the rest of the addons starting from the last addon upto where it left off. I have all the preferences set to false and I update without externals. I also unselect show groups. This is something new since earlier yesterday it was working fine.
Malfeus
Try skipping Manufac then, looks like it's hanging up on MAnufac and stopping, probably Manufac is missing a changefile
it's probably the new MCP fault
Works ok for me. But i dont have manufac installed, or mcp for that matter.
The problem is that when A only registers to CHAT_MSG_COMBAT_SELF_HITS and Parser_Hit, I think A shouldn't receive a Parser_Hit event at all when CHAT_MSG_COMBAT_HOSTILEPLAYER_HITS was fired. But I can't control who will receive the Parser_Hit event, or ca
IDs and counters only let me know who registered to what Blizzard events, it doesn't solve the problem.
If there isn't any better solution to this, then I think I can only pass Blizzard event as an arg to Parser_Hit, addons should expect to receive Parser events even when they didn't register to the that Blizzard event - that means they may optionally tell ParserLib what Blizzard events they're interested, but expect to receive Parser_Hit from all possible Blizzard events.
In that case the API may look something like this:
-- pass self to ParserLib so when you register to Parser_Hit, ParserLib knows that you have already suggested a Bz event and will not register to all hit-related Bz events.
AceLibrary("Parser-2.0"):SuggestEvent(self, "CHAT_MSG_COMBAT_SELF_HITS")
-- actually registers to Parser_Hit.
myAddon:RegisterEvent("Parser_Hit")
that looks weird to me, but at least it makes the suggestion part completely optional?
At the back of ParserLib it would just store a table of addon reference and their interested Bz events. ParserLib listens to AceEvent_EventRegistered for ParserLib events, when someone registers to ParserLib events, ParserLib registers to all related Bz events if the addon reference doesn't exist in the table, otherwise ParserLib registers to possible Bz events in the suggestion table.
Using a unique ID for each event allows the user of parserlib to solve the problem.
event -> parserlib
eventID = eventID+1 (=101)
event --------------------->client
self.eventID=parserlib:GetEventID(). returns 101
parse...
parserHit(eventID, ...) ------>client
if self.eventID != eventID then return end
... otherwise its from an event we want
Even better if the eventID was in AceEvent - since maybe its possible they could get parserHit before the bz event (at least that how i understand it events fired from event handlers create an event stack)
Letting the addons users store information for you prevents you having to maintain tables internally.
This is essentially the "Visitor" design pattern without the OO
How about telling us the exact version you use, and if you use !!!libs, or standalones or embedded libraries.
Dont assume everyone else is having this issue, i can say for a fact that I am not having this issue at all, nor did I ever have it. I had started looking into it, then realized its most likely a problem with your setup, maybe some out of date stuff, who knows.
sorry :)
i have tried every version of Prat starting from 11-29 to current.
i also use Prat_Fubar2 to help with the config.
i use the !!!StandaloneLibs mods and update those + Prat with the AceUpdater "without externals".
i've tried downloading & updating prat manually with the same results.
the version of Prat i'm using now (and is working!) is r15466.
tomorrow i will try leaving the libs folder inside prat to see what happens, and post the results.
thanks for tryin to help me narrow it down :)
edit: now that i look at it more, the version i'm using (that works) has the libs folder inside it. when i update via aceupdater i tell it to do it without externals so there is no libs folder. i bet that has something to do with it :) i'm definitely gonna try it out tomorrow.
Its something with your setup. Just install !!!StandaloneLibraries and Prat without externals = update to the latest with WAU, making sure you have set the "delete old version" option to true
Here are some better instructions - you want to do the stuff listed under Disembedding:
I just committed a big update for the TBC branch of Prat. This trues up the TBC branch with the current mainline trunk version of Prat only with funky 20000 interface adjustments so it should work on the PTR and in the TBC beta (which seems to be the case for me anyway). Please report any issues you have with the TBC branch. Thanks!
P.s. Let's also talk a little design shop if please. Which modules would you consider "core" and which modules would you consider "extras"? I would like to propose that we split the modules up a bit so that people new to Prat can get their feet wet with the "core" then they can rub a little funk on it with "extras". Please add your thoughts on this.
Just hide them on the menu using the "hidden" field in AceOptions - dont create addon directory spam with prat_extras. There is 0 need to create yet another addon which has to be managed by the end user - the modules themselves have such a small memory footprint - you cant even make a case that you would save memory by breaking out some modules (someone will try to im sure, and 20k of ram will be alot in their opinion too). The only reason i could see to to break out a module is if that module introduced a new library dependancy (like prat_fubar2), or if it had LOTS of textures and frame (none do).
EDIT- I'm not trying to flame or gripe actually. How about something like SCT does, and have some profiles that ship with prat. So you can choose from a few standard profiles. Everyone can submit their own personal profiles, and we can choose 3-4 to include as "read only" profiles.
What about an ace2 version of myAddons?
On the right side have an extra tab for options
with input fields in place of slide bars?
You can also create another section on the left side to control profiles and within
that you can enable/disable the various addons you have.
Malfeus
You want the addon manager to be able to run even if ace2 cant, we already have "DLL Hell", so you shouldnt make the tool that tries to remedy this dependant on the things its trying to manage.
Cosmos was stable enough that they could get away with it, since there was only 1 way to install the libraries that Khaos depends on, and there was a required dependancy on those libraries. With ace you never know where the library is, or even if its going to be there.
If you want an ace2 version - you need to require Ace2+any other library you use be installed standalone with a required dependancy on those standalones.
Ok, having all this Addon directory spam from everyone thinking that they need LoD on everything for some reason.
I came up with a couple concepts.
1) include batch files with the addon that will both unpack all the varios little LoD addons out of the addons directory and into the WoW addon directory AND can also move them out of the wow addon directory and back into the main addon folder.
2) The in game addon manager, should treat addons like SCT or Bigwigs as 1 addon. So I modified myAddons to #1 work, and #2 hide adddons like SCT_options, or BigWigs_*. To do this the toc file of each of the "sub addons" needs to have a new TOC metatag
At the moment, i just have myAddons placing a note in the parent addon's notes field which lists child addons, and then it does not include them in the list of addons.
This is just designed to be some working code, to generate interest and ideas.
How about telling us the exact version you use, and if you use !!!libs, or standalones or embedded libraries.
Dont assume everyone else is having this issue, i can say for a fact that I am not having this issue at all, nor did I ever have it. I had started looking into it, then realized its most likely a problem with your setup, maybe some out of date stuff, who knows.
Copy these folders into your WoW addon path, open WinAceUpdater and choose mark installed addons.
So yes, copy the folders into your Addons directory, and update the Libs like any other Addon.
I'm a fairly intelligent invdividual, and frankly, this readme is confusing as fuck. I've written a few Ace addons. (that you probably haven't seen, that I've only released it to friends)
spell it out in teh dumb letters. Step by step, for real.
I still think that using a sequence counter that increnments on each event will solve most if not all of these issues. Each source event CHAT_MSG - gets assigned an ID which can be queried when you get derivative events eg. Parser_Hit.
You can then use some logic to ignore the event based on this ID.
In your case, you would register for CHAT_MSG_COMBAT_SELF_HITS and Parser_Hit. In the CHAT_MSG you would save the ID, and process any subsequent event with that ID.
So if the event CHAT_MSG_COMBAT_HOSTILEPLAYER_HITS generates Parser_Hit, you will not have a matching ID when Parser_Hit fires...so you would ignore it.
Using an ID tied to the source event solves alot of ambiguity issues (with events that fire as a result of the original event) and is extremely cheap to implement.
yes it is. Its undergoing a rewrite at the moment and is waiting on several things in order to reach completion (partially is me to recode the back end of the zip system)
I started coding a 'package magangement' (for handling multiple mods as a single item) enhancement to WAU, but figuered i'd better talk to the developers first - would you like some assistance on this project? Can i help out in any way?
Right, done my best to attempt to get it working and stop throwing errors - and i think i did... unfortunately on PTR i get the message "rSelfCast has been blocked from an action only available to the Blizzard UI."
In other words, I probably farked up somewhere, so if someone has a version that works for them on PTR (confirmed working), please do let us all know, and if possible upload it. At the very least try to document the changes you made for it to work (seen the above changes, still no help).
I fear very much that right click selfcasting will fall under the "decursive nerf", as it allows the player to rapidly switch target and cast a spell with a single click.
Ok, i was under the impression that someone had it working. I have a beta key, so I'll start work on this.
0
Works ok for me. But i dont have manufac installed, or mcp for that matter.
0
Using a unique ID for each event allows the user of parserlib to solve the problem.
event -> parserlib
eventID = eventID+1 (=101)
event --------------------->client
self.eventID=parserlib:GetEventID(). returns 101
parse...
parserHit(eventID, ...) ------>client
if self.eventID != eventID then return end
... otherwise its from an event we want
Even better if the eventID was in AceEvent - since maybe its possible they could get parserHit before the bz event (at least that how i understand it events fired from event handlers create an event stack)
Letting the addons users store information for you prevents you having to maintain tables internally.
This is essentially the "Visitor" design pattern without the OO
0
Its in my own branch, and not in the trunk - its a bug in the zip script probably. myAddons is there as well. So lets kill 2 birds with one stone.
Do you actually have the addon? if you do put a folder inside it named ".svn". That should help i think.
0
Its something with your setup. Just install !!!StandaloneLibraries and Prat without externals = update to the latest with WAU, making sure you have set the "delete old version" option to true
Here are some better instructions - you want to do the stuff listed under Disembedding:
http://www.wowace.com/wiki/How_To_Update_Beta_Addons
0
Just hide them on the menu using the "hidden" field in AceOptions - dont create addon directory spam with prat_extras. There is 0 need to create yet another addon which has to be managed by the end user - the modules themselves have such a small memory footprint - you cant even make a case that you would save memory by breaking out some modules (someone will try to im sure, and 20k of ram will be alot in their opinion too). The only reason i could see to to break out a module is if that module introduced a new library dependancy (like prat_fubar2), or if it had LOTS of textures and frame (none do).
EDIT- I'm not trying to flame or gripe actually. How about something like SCT does, and have some profiles that ship with prat. So you can choose from a few standard profiles. Everyone can submit their own personal profiles, and we can choose 3-4 to include as "read only" profiles.
0
You want the addon manager to be able to run even if ace2 cant, we already have "DLL Hell", so you shouldnt make the tool that tries to remedy this dependant on the things its trying to manage.
Cosmos was stable enough that they could get away with it, since there was only 1 way to install the libraries that Khaos depends on, and there was a required dependancy on those libraries. With ace you never know where the library is, or even if its going to be there.
If you want an ace2 version - you need to require Ace2+any other library you use be installed standalone with a required dependancy on those standalones.
0
I came up with a couple concepts.
1) include batch files with the addon that will both unpack all the varios little LoD addons out of the addons directory and into the WoW addon directory AND can also move them out of the wow addon directory and back into the main addon folder.
You can see these batch files in:
http://svn.wowace.com/wowace/branches/!!!StandaloneLibraries/sylvanaar
They have about 1-2 lines in each one.
2) The in game addon manager, should treat addons like SCT or Bigwigs as 1 addon. So I modified myAddons to #1 work, and #2 hide adddons like SCT_options, or BigWigs_*. To do this the toc file of each of the "sub addons" needs to have a new TOC metatag
## X-PartOf: <parent mod>
like
## X-PartOf: sct
## X-PartOf: SSPVP
## X-PartOf: BigWigs
At the moment, i just have myAddons placing a note in the parent addon's notes field which lists child addons, and then it does not include them in the list of addons.
This is just designed to be some working code, to generate interest and ideas.
http://svn.wowace.com/wowace/branches/myAddons/sylvanaar/myAddons
side note: some of the code in Ace2 and myAddons is almost identical - which came first?
0
How about telling us the exact version you use, and if you use !!!libs, or standalones or embedded libraries.
Dont assume everyone else is having this issue, i can say for a fact that I am not having this issue at all, nor did I ever have it. I had started looking into it, then realized its most likely a problem with your setup, maybe some out of date stuff, who knows.
0
I added it for ya
0
Please grab it and try it out.
0
http://www.wowace.com/wiki/How_To_Update_Beta_Addons
0
You can then use some logic to ignore the event based on this ID.
In your case, you would register for CHAT_MSG_COMBAT_SELF_HITS and Parser_Hit. In the CHAT_MSG you would save the ID, and process any subsequent event with that ID.
So if the event CHAT_MSG_COMBAT_HOSTILEPLAYER_HITS generates Parser_Hit, you will not have a matching ID when Parser_Hit fires...so you would ignore it.
Using an ID tied to the source event solves alot of ambiguity issues (with events that fire as a result of the original event) and is extremely cheap to implement.
0
I started coding a 'package magangement' (for handling multiple mods as a single item) enhancement to WAU, but figuered i'd better talk to the developers first - would you like some assistance on this project? Can i help out in any way?
0
Ok, i was under the impression that someone had it working. I have a beta key, so I'll start work on this.
0
Thx, seems to be working ok now with !!!Libs (ugh) where i added a optional dependancy for ace2.
Did you make changes that would affect TargetOfTarget?