For whatever reason, 488 isn't checking externals and updating them at ALL. It's caused some seriously odd things to occur too.
Going to fall back to 483 until Lejordet gets less busy and can take a look at it.
It was the in-game Threat-1.0 version reporting that brought me here as well. After a bit of experimentation for the SF bug report I wrote, I found that the individual WoWAce addons have a new "ignore the No Embedded Libraries setting" option in their details screen. Once I set that for Omen, the embedded library versions started being checked again. I tried a few other mods with embedded libraries, and got the same result - so somewhere in the code is only checking the new per-mod option, and ignoring the old global default setting.
(The easiest way to tell if you have this problem is that you will have a mod with an embedded library version number like 52025.19 installed, but the online version is showing up as a bare noext version like 52025).
Sorry about the lack of updates, I?m on (a much needed) vacation until the 31st ;) (I ordered it only 3 days before I left, hence the sudden silence :P)
I know there?s an issue with externals in 488, and there will be a fix to that when I get back (I have no internet on my laptop here, but I have a copy of the xml file from WoWAce saved from earlier :)) - I?ve already improved the identification of unknown addons a bit, so I think I?m back on track with WUU code now - it helped not having to touch work (work-work) for a week.
I don?t have time to address all the specific issues mentioned here right now (damn ?8/hour internet and locked-down computers :(), but if 483 works better than 488 for you, stick with that until the next release.
Sorry about the lack of updates, I?m on (a much needed) vacation until the 31st ;) (I ordered it only 3 days before I left, hence the sudden silence :P)
I know there?s an issue with externals in 488, and there will be a fix to that when I get back (I have no internet on my laptop here, but I have a copy of the xml file from WoWAce saved from earlier :)) - I?ve already improved the identification of unknown addons a bit, so I think I?m back on track with WUU code now - it helped not having to touch work (work-work) for a week.
I don?t have time to address all the specific issues mentioned here right now (damn ?8/hour internet and locked-down computers :(), but if 483 works better than 488 for you, stick with that until the next release.
Thanks for the update! Enjoy your vacation and have a Merry Christmas!
Not sure why this happens but every time I auto update Reagent Restocker from WowInterface. When I load the game it is listed in RED as unavailable. If I download it manually and toss it in it works fine.
Sounds like you're missing a library. WUU must be set up to download with no externals, however, downloading manually downloads -with- externals unless you futz around with the website..
Some considerate burglars thought it'd be nice to break in and relieve me of my Macbook on my vacation (it was in the room safe - they took the entire safe), so I lost everything I'd coded since I left. Everything from before the vacation is backed up with Time Machine (I hope...no way of checking that before I can buy a new Mac).
Jon's committed some no-ext fixes, and I have to re-code what I did on the vacation (should take shorter this time around, since I've already done it once) - hoping to release a new version on Friday or so. I'll also read whatever I missed in this thread to make sure all bugs are covered :)
And maybe WUU is one of the lesser important stuff you lost (thinking of all the data on mine), so I hope it turns out fine for you and take your time. Feeling with you.
Oh...sorry to hear this...check with Apple; there is something they do or can tell you what to do if you have the serial no and/or Applecare so if that machine turns up anywhere it will be detected.
That sucks :/. Did you get insurance on the safe? It usually only costs like 1$ a day. A lot of hotels will stick it on there without asking.
Yes, I had both safe insurance and travel insurance, so I'm fully covered, "but [the manager of the hotel] thinks
that one month at least is necessary" for them to do whatever they do for me to get money.
I can't afford to buy a new Mac before then, so I guess I'll throw Fedora on some old laptop and concentrate on the Linux version for a bit ;)
* Updated [Unknown] addon identification (uses WoWAce before anything else)
for me it even puts WoWAce in, in case it is unknown to the masterdb.
e.g: "Armory" seems to be not known, but it switches to WoWAce instead of stick to unknown.
for me it even puts WoWAce in, in case it is unknown to the masterdb.
e.g: "Armory" seems to be not known, but it switches to WoWAce instead of stick to unknown.
Hm, strange :(
I'll investigate that later today, that's not what was intended by that code :P
EDIT: I found it; the problem wasn't the new code, but wrongly tagged entries in the online db: check this link
I'm adding a new feature that more or less ignores stuff tagged as WoWAce in the online DB (since we have the 100% correct list straight from here anyhow).
Apologies if these questions are answered elsewhere -- I've read the faq, scanned the wiki and this thread, and experimented, but haven't found the answer.
What's the correct way to deal with grouped/bundled addons, such as DeadlyBossMods or LightHeaded? That is, mods which, in a single zip, include several addons? In my brief experimentation with WUU, it seems that some DBM subdirectories identified curse (http://www.curse.com/downloads/details/4940/) as a source, and some did not. However, updating any or all of the sub-mods required WUU to go download the entire grouped zip for each one. (I didn't verify what actually got upgraded when I did that -- at the very least it's really inefficient.)
DeadlyBossMods is a good example because they further complicate the issue: There are two separate downloads on the curse page. Higher level sub-mods are in one, and lower level ones are in the other. I didn't find a way to have WUU download the mods which are in the "additional" zip, though pointing WUU to the above curse link convinced it to download the main zip (which does actually not contain the additional subdirectories). To further complicate the matter, both zips contain the DBM_Other submod with different capabilities, although you could always safely install the lower level one and get full options.
Hopefully my question makes sense -- let me know if it doesn't, and if I'm missing how to set this up effectively. If I can get WUU working right, it will eliminate a fairly complex set of scripts I've had to write to keep my custom collection of wowace/svn, dbm, lh, wowui, and cosmos mods running smoothly. Thanks!
well lets this about this logically.. is 1.0 > 3.0 ?
now.. realize this is just a programmatically-controlled computer application, it doesnt have reasoning abilities such as you and I. It can only work with the information it is given, and the googlecode stuff translates "Alpha 3.0" into a 'date-style' number, stripping any alpha characters, so that it only sees the numerics.. for most other addons this is fine..
It cannot, however, interpret "Alpha" and "Beta" and considering that Combuctor is, so far, the only addon I've seen that does it this way.. It's probably unrealistic to expect lejordet to make fundamental code changes just to support 1 addon that decided to give version info in a strange (to a binary system) way.
EDIT: However, I -have- noticed a bug.. If you change "Alpha" to "Beta" in your WUU addon preferences, instead of finding the new one, like it should, it says it cannot find the Addon..
Apologies if these questions are answered elsewhere -- I've read the faq, scanned the wiki and this thread, and experimented, but haven't found the answer.
What's the correct way to deal with grouped/bundled addons, such as DeadlyBossMods or LightHeaded? That is, mods which, in a single zip, include several addons? In my brief experimentation with WUU, it seems that some DBM subdirectories identified curse (http://www.curse.com/downloads/details/4940/) as a source, and some did not. However, updating any or all of the sub-mods required WUU to go download the entire grouped zip for each one. (I didn't verify what actually got upgraded when I did that -- at the very least it's really inefficient.)
DeadlyBossMods is a good example because they further complicate the issue: There are two separate downloads on the curse page. Higher level sub-mods are in one, and lower level ones are in the other. I didn't find a way to have WUU download the mods which are in the "additional" zip, though pointing WUU to the above curse link convinced it to download the main zip (which does actually not contain the additional subdirectories). To further complicate the matter, both zips contain the DBM_Other submod with different capabilities, although you could always safely install the lower level one and get full options.
Hopefully my question makes sense -- let me know if it doesn't, and if I'm missing how to set this up effectively. If I can get WUU working right, it will eliminate a fairly complex set of scripts I've had to write to keep my custom collection of wowace/svn, dbm, lh, wowui, and cosmos mods running smoothly. Thanks!
-cb
Ooops, I didn't get an email notice (or I missed it :P) for this reply; will answer it "quickly" now :)
1) Bundled addons should be handled automatically; what you're seeing is the result of identifying addons against the online DB, which contains (only) user-submitted data...which often is wrong. Just looking at the database (no time to fix it right now, sadly), I can see that many users have set every directory of an addon to the same site, while in a correct setting, only the main directory (if the addon has one) or "any directory guaranteed to be in every release of the addon" (if it's a bundle with no logical master-addon) should be set to the site/site ID in question, while the rest should be set to [Related], with the site ID named after the main addon directory. I'm going to experiment a bit with this in upcoming versions, hopefully finding a way to ditch the entire online database*.
The easiest way to fix this (especially if you have no customizations in your addons), is to delete LightHeaded (for example), and use Addon -> Install... -> from URL and just drop in http://www.wowinterface.com/downloads/info7017-LightHeaded.html to reinstall it - all [Related] settings should be handled automatically :)
*) Which brings me to my idea: After checking against WoWAce to identify addons (as .492 does), and downloading these (if the user wants) to make sure all relations are set correctly, the user is asked to provide the URL for each unidentified addon to simplify setup - would that be an acceptable way of making sure that the initial setup is as correct as possible?
2) DBM is the first addon I've seen with two "variants" on the addon page, so I can safely(?) say that WUUs behavior in this case is "undefined" (I'm guessing, however, that it downloads the first addon in the list). I'll look into it, maybe we have to add some special-casing to the curse code (bad), or a way of specifying "if there's two addons on the page, I want the second one" (better).
Relating to my footnote (or whatever you call it when it's in the middle of the post) above; if you have a lot of complex settings for your addons, I'd suggest you take the ones that WUU can't identify correctly, and install them from URL if possible :)
well lets this about this logically.. is 1.0 > 3.0 ?
now.. realize this is just a programmatically-controlled computer application, it doesnt have reasoning abilities such as you and I. It can only work with the information it is given, and the googlecode stuff translates "Alpha 3.0" into a 'date-style' number, stripping any alpha characters, so that it only sees the numerics.. for most other addons this is fine..
It cannot, however, interpret "Alpha" and "Beta" and considering that Combuctor is, so far, the only addon I've seen that does it this way.. It's probably unrealistic to expect lejordet to make fundamental code changes just to support 1 addon that decided to give version info in a strange (to a binary system) way.
EDIT: However, I -have- noticed a bug.. If you change "Alpha" to "Beta" in your WUU addon preferences, instead of finding the new one, like it should, it says it cannot find the Addon..
I haven't tried the tullamods settings, but I think you're on to something with the 3.0 > 1.0 thing :) Also, judging from the URLs, the alpha had a dot between "Alpha" and "3.0", while the "Beta" doesn't - does this affect anything?
_________________________________________________
I've finally found a temporary laptop, and after struggling with Fedora 8 (the ATi drivers just wouldn't work at all :(), I ended up installing Ubuntu today; hopefully I'll get back in the code again now :P (as everyone knows, it's a bad idea to buy a new laptop of any kind right before a Apple keynote)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
It was the in-game Threat-1.0 version reporting that brought me here as well. After a bit of experimentation for the SF bug report I wrote, I found that the individual WoWAce addons have a new "ignore the No Embedded Libraries setting" option in their details screen. Once I set that for Omen, the embedded library versions started being checked again. I tried a few other mods with embedded libraries, and got the same result - so somewhere in the code is only checking the new per-mod option, and ignoring the old global default setting.
(The easiest way to tell if you have this problem is that you will have a mod with an embedded library version number like 52025.19 installed, but the online version is showing up as a bare noext version like 52025).
I know there?s an issue with externals in 488, and there will be a fix to that when I get back (I have no internet on my laptop here, but I have a copy of the xml file from WoWAce saved from earlier :)) - I?ve already improved the identification of unknown addons a bit, so I think I?m back on track with WUU code now - it helped not having to touch work (work-work) for a week.
I don?t have time to address all the specific issues mentioned here right now (damn ?8/hour internet and locked-down computers :(), but if 483 works better than 488 for you, stick with that until the next release.
Thanks for the update! Enjoy your vacation and have a Merry Christmas!
Happy Ramahanukwanzmas.
http://www.wowinterface.com/downloads/info7569-ReagentRestocker.html
Is there something causing this?
Jon's committed some no-ext fixes, and I have to re-code what I did on the vacation (should take shorter this time around, since I've already done it once) - hoping to release a new version on Friday or so. I'll also read whatever I missed in this thread to make sure all bugs are covered :)
And maybe WUU is one of the lesser important stuff you lost (thinking of all the data on mine), so I hope it turns out fine for you and take your time. Feeling with you.
Barracuda
Good Luck
Yes, I had both safe insurance and travel insurance, so I'm fully covered, "but [the manager of the hotel] thinks
that one month at least is necessary" for them to do whatever they do for me to get money.
I can't afford to buy a new Mac before then, so I guess I'll throw Fedora on some old laptop and concentrate on the Linux version for a bit ;)
WUU 1.6.492 source/linux
MD5 sums:
1.6.492 (we'll never get out of 1.6 version) (2008.01.06):
* Bugfix: Fix for the ignore-no-ext issue
* Updated [Unknown] addon identification (uses WoWAce before anything else)
* Improved installFromURL main addon identification
No .dmg version here, due to me not having a Mac :( .488 should auto-update to .492 nicely, though - but again, I have no way of testing that.
I do. Worked fine. New version seemed to load a bit faster, too, but maybe that's just me. :-)
for me it even puts WoWAce in, in case it is unknown to the masterdb.
e.g: "Armory" seems to be not known, but it switches to WoWAce instead of stick to unknown.
Hm, strange :(
I'll investigate that later today, that's not what was intended by that code :P
EDIT: I found it; the problem wasn't the new code, but wrongly tagged entries in the online db: check this link
I'm adding a new feature that more or less ignores stuff tagged as WoWAce in the online DB (since we have the 100% correct list straight from here anyhow).
What's the correct way to deal with grouped/bundled addons, such as DeadlyBossMods or LightHeaded? That is, mods which, in a single zip, include several addons? In my brief experimentation with WUU, it seems that some DBM subdirectories identified curse (http://www.curse.com/downloads/details/4940/) as a source, and some did not. However, updating any or all of the sub-mods required WUU to go download the entire grouped zip for each one. (I didn't verify what actually got upgraded when I did that -- at the very least it's really inefficient.)
DeadlyBossMods is a good example because they further complicate the issue: There are two separate downloads on the curse page. Higher level sub-mods are in one, and lower level ones are in the other. I didn't find a way to have WUU download the mods which are in the "additional" zip, though pointing WUU to the above curse link convinced it to download the main zip (which does actually not contain the additional subdirectories). To further complicate the matter, both zips contain the DBM_Other submod with different capabilities, although you could always safely install the lower level one and get full options.
Hopefully my question makes sense -- let me know if it doesn't, and if I'm missing how to set this up effectively. If I can get WUU working right, it will eliminate a fairly complex set of scripts I've had to write to keep my custom collection of wowace/svn, dbm, lh, wowui, and cosmos mods running smoothly. Thanks!
-cb
old: http://tullamods.googlecode.com/files/Combuctor Alpha.3.0.zip
new: http://tullamods.googlecode.com/files/Combuctor Beta 1.0.zip
now.. realize this is just a programmatically-controlled computer application, it doesnt have reasoning abilities such as you and I. It can only work with the information it is given, and the googlecode stuff translates "Alpha 3.0" into a 'date-style' number, stripping any alpha characters, so that it only sees the numerics.. for most other addons this is fine..
It cannot, however, interpret "Alpha" and "Beta" and considering that Combuctor is, so far, the only addon I've seen that does it this way.. It's probably unrealistic to expect lejordet to make fundamental code changes just to support 1 addon that decided to give version info in a strange (to a binary system) way.
EDIT: However, I -have- noticed a bug.. If you change "Alpha" to "Beta" in your WUU addon preferences, instead of finding the new one, like it should, it says it cannot find the Addon..
Ooops, I didn't get an email notice (or I missed it :P) for this reply; will answer it "quickly" now :)
1) Bundled addons should be handled automatically; what you're seeing is the result of identifying addons against the online DB, which contains (only) user-submitted data...which often is wrong. Just looking at the database (no time to fix it right now, sadly), I can see that many users have set every directory of an addon to the same site, while in a correct setting, only the main directory (if the addon has one) or "any directory guaranteed to be in every release of the addon" (if it's a bundle with no logical master-addon) should be set to the site/site ID in question, while the rest should be set to [Related], with the site ID named after the main addon directory. I'm going to experiment a bit with this in upcoming versions, hopefully finding a way to ditch the entire online database*.
The easiest way to fix this (especially if you have no customizations in your addons), is to delete LightHeaded (for example), and use Addon -> Install... -> from URL and just drop in http://www.wowinterface.com/downloads/info7017-LightHeaded.html to reinstall it - all [Related] settings should be handled automatically :)
*) Which brings me to my idea: After checking against WoWAce to identify addons (as .492 does), and downloading these (if the user wants) to make sure all relations are set correctly, the user is asked to provide the URL for each unidentified addon to simplify setup - would that be an acceptable way of making sure that the initial setup is as correct as possible?
2) DBM is the first addon I've seen with two "variants" on the addon page, so I can safely(?) say that WUUs behavior in this case is "undefined" (I'm guessing, however, that it downloads the first addon in the list). I'll look into it, maybe we have to add some special-casing to the curse code (bad), or a way of specifying "if there's two addons on the page, I want the second one" (better).
Relating to my footnote (or whatever you call it when it's in the middle of the post) above; if you have a lot of complex settings for your addons, I'd suggest you take the ones that WUU can't identify correctly, and install them from URL if possible :)
I haven't tried the tullamods settings, but I think you're on to something with the 3.0 > 1.0 thing :) Also, judging from the URLs, the alpha had a dot between "Alpha" and "3.0", while the "Beta" doesn't - does this affect anything?
_________________________________________________
I've finally found a temporary laptop, and after struggling with Fedora 8 (the ATi drivers just wouldn't work at all :(), I ended up installing Ubuntu today; hopefully I'll get back in the code again now :P (as everyone knows, it's a bad idea to buy a new laptop of any kind right before a Apple keynote)