You do need to enter a URL. The directory is what I'm talking about, it's the URL, and it requires some memory or looking up to find.
For those using the command-line SVN client (v1.6 or later), the proper one-liner incantation for tagging the current trunk revision for the repository corresponding to your current working directory looks like this:
The "^" syntax allows you to create a server-side tag, without the need for remembering/providing a full URL. It also avoids the need for a separate push operation.
#@no-lib-strip@ in TOC files is also being ignored, breaking no-lib creation.
Is there a new syntax for no-lib exclusion? (it does not appear in the new packager docs)
I am adding a ticket for this now, should still be the same.
The problem here appears to be that the new packager is not correctly handling svn's built-in externals - ie any libs pulled in by the svn:externals property are being pulled into the -nolib package, even if they should not be.
Most likely the fix is to add the --ignore-externals option to any svn checkout/update command used to fetch the repository before packaging. This should mimic the behavior of the old packager and avoid sucking svn:externals into -nolib packages, whilst still allowing developers the use of svn:externals for their convenience in their local working directory.
We've been having intermittent problems with the task worker that starts the packager since our server migration this past Thursday. I'm hoping it will be resolved later this morning (Tuesday). Either way, once the task worker is restarted, the packager will continue to work on the projects in its queue - your project will be packaged.
I cannot overstate how much the packager downtimes are interfering with my ability to develop addon content. It seems like it's been down several times a day for the past two weeks or so, and on at least 5 separate occasions it has directly hampered my ability to push updates and test code to users, often for multiple hour stretches. The fact these problems also coincided with a major client patch has magnified the problem enormously.
I understand this issue is out of Torhal's direct control, but this is a major problem for addon devs that really needs to be fixed ASAP. Who should we be bothering about this? What can we do to expedite this?
For what it's worth, the problematic Blizzard code is inside the C-code implementation of ItemRefTooltip:SetHyperlink(), as called by SetItemRef() in FrameXML/ItemRef.lua.
Does this change affect the professions display of the guild frame somehow? Or are the GUIDs of all guild members automatically in the cache?
The guild tradeskill window appears to be unaffected, but only because that window never uses a hyperlink of any kind (nor does it offer one for linking into chat). Guild tradeskills use the same TradeSkillFrame, but are opened via a different code path thru lua/C (GUILD_TRADESKILL_UPDATE), and the displayed data is fetched using an independent API (ie GetGuildTradeSkillInfo() and friends). So basically it avoids the trouble by never touching the new problematic hyperlink encoding/implementation.
Note that being in the same guild with someone does not mean their GUID is cached, even if they are logged in and you are looking at the roster. You still cannot open the tradeskill hyperlinks of that character unless you've "encountered" them during the current login session (eg if they speak in guild chat, whispers or join a group with you). This means that for example, having all your alts in the same guild still does not allow you to open the tradeskill hyperlinks for your alts (or whisper a working link to other players), but you can still manually navigate thru the professions pane of the guild roster to open their tradeskill.
I don't think it's an intentional throttling measure, because it's still possible to flood the server with requests for any cached GUID (which you encounter in large quantity while standing in town or sitting in a 40-man raid). So it would be a very ineffectual throttle.
I suspect it's a consequence of how GUID caching is handled in the C code - the code that activates the hyperlink is dropping dead when it encounters a cache miss, instead of initiating a cache fetch as it should (as it does in 5.3 when you open a link with an uncached GUID and it has to fetch the player name).
In any case I agree it's unlikely to change again this late in the patch cycle, which means live users will probably be stuck with the negative implications of this new behavior for awhile. For whatever it's worth I've created a thread on the Blizzard bug report forum to complain about the issue. Feel free to add your voice:
So it appears the situation is actually significantly worse than I originally realized (as of PTR build 5.4.0 17337).
Not only is all the tradeskill data fetched dynamically from the server, but it furthermore appears that this fetching will ONLY take place if the character GUID in the link has already been encountered by the client during the current session. Stated differently, you can only open links from characters that you are grouped with, chatting with or standing near in the game world. Any attempt to open links obtained via other means will silently fail.
This means that in particular, you cannot open tradeskill links for your alts. It also means that if player A whispers his tradeskill link to player B, and player B whispers it to player C, then player C will be unable to open that link unless he has "encountered" player A during the current session.
I don't know if this behavior is intentional (some kind of misguided security measure?), but it seems more likely to be a design flaw in the new tradeskill hyperlink implementation. Either way this is a major departure from previous behavior and will play havoc with some addons (anything with a feature to link your alt's profession).
Most notably, the <databits>, <rank> and <rankmax> fields are being removed entirely and all data is being fetched dynamically from the server based on player GUID in the link. The new <pid> field is technically redundant with spellid, and is the Profession ID as returned by GetProfessionInfo().
The implications of this change are that most addons that parse the contents of the tradeskill hyperlink in any way will likely need fixes for 5.4. Addons that try to parse the databits field will likely need major changes (mine is in this category).
It also appears that as a result of this change, it's no longer possible to forge an "all recipes" tradeskill hyperlink for the user that can be clicked to open a tradeskill window containing every available spell (eg ProfessionsDatabase). Many addons have embedded this handy quality-of-life feature in one way or another, however I believe it's no longer possible to implement such a link-generation facility (unless there is some kind of backdoor or other trick I'm unaware of). Addons which totally replace the tradeskill window could potentially still offer a display of every spell, but would need to bypass the Blizzard GetTradeSkill* API's to provide the data (and could not provide an "all recipes" link for use in chat, etc). The inability to forge arbitrary trade hyperlinks may also hinder TradeSkill data-mining code.
I'm curious to hear from other TradeSkill addon authors regarding these changes and how you plan to handle them..
As is this section of code has some issues, like trying to add an item after 12 attachments are already present (Alt-Click to add) and going through everything in the bags and trying to attach it like a bull in a china shop (Control-Click). These changes rein in the latter more dramatically than the former. (Think 160 stacks of item X.)
I'm the author of the original control-click to add code, and your proposed change demonstrates a lack of understanding of the algorithm, breaking it in several important ways.
It doesn't really matter that the current code ignores the 12 item limit - attempting to attach additional items is completely harmless, and the error generated informs the user that more matching items are available than could fit in this message.
Regarding terminology, "coalesce" is a very well-established term in computer science (especially networking), and is exactly the right term for the situation where it is used (terms like merge, on the other hand, also have a specific, but different CS connotation). In any case it should be relatively clear from context what it means.
"Annulus sector" was not my contribution, but is nevertheless the correct mathematical term for the geometric shape in question.
I can see the argument for "dumbing down" terminology to accommodate the layman, but I prefer to use more precise phraseology when it's not too obscure. There's no harm in learning something new while playing a video game...
0
0
0
Really need this feature back in the interests of sane bug reporting and handling.
Giving the average user a blank text box pretty much guarantees a useless bug report.
0
#@no-lib-strip@ in TOC files is also being ignored, breaking no-lib creation.
Is there a new syntax for no-lib exclusion? (it does not appear in the new packager docs)
0
I cannot overstate how much the packager downtimes are interfering with my ability to develop addon content. It seems like it's been down several times a day for the past two weeks or so, and on at least 5 separate occasions it has directly hampered my ability to push updates and test code to users, often for multiple hour stretches. The fact these problems also coincided with a major client patch has magnified the problem enormously.
I understand this issue is out of Torhal's direct control, but this is a major problem for addon devs that really needs to be fixed ASAP. Who should we be bothering about this? What can we do to expedite this?
0
Please add your voices in complaint on the new thread:
http://us.battle.net/wow/en/forum/topic/9948634812
0
0
The guild tradeskill window appears to be unaffected, but only because that window never uses a hyperlink of any kind (nor does it offer one for linking into chat). Guild tradeskills use the same TradeSkillFrame, but are opened via a different code path thru lua/C (GUILD_TRADESKILL_UPDATE), and the displayed data is fetched using an independent API (ie GetGuildTradeSkillInfo() and friends). So basically it avoids the trouble by never touching the new problematic hyperlink encoding/implementation.
Note that being in the same guild with someone does not mean their GUID is cached, even if they are logged in and you are looking at the roster. You still cannot open the tradeskill hyperlinks of that character unless you've "encountered" them during the current login session (eg if they speak in guild chat, whispers or join a group with you). This means that for example, having all your alts in the same guild still does not allow you to open the tradeskill hyperlinks for your alts (or whisper a working link to other players), but you can still manually navigate thru the professions pane of the guild roster to open their tradeskill.
0
I suspect it's a consequence of how GUID caching is handled in the C code - the code that activates the hyperlink is dropping dead when it encounters a cache miss, instead of initiating a cache fetch as it should (as it does in 5.3 when you open a link with an uncached GUID and it has to fetch the player name).
In any case I agree it's unlikely to change again this late in the patch cycle, which means live users will probably be stuck with the negative implications of this new behavior for awhile. For whatever it's worth I've created a thread on the Blizzard bug report forum to complain about the issue. Feel free to add your voice:
http://us.battle.net/wow/en/forum/topic/10025372561
0
Not only is all the tradeskill data fetched dynamically from the server, but it furthermore appears that this fetching will ONLY take place if the character GUID in the link has already been encountered by the client during the current session. Stated differently, you can only open links from characters that you are grouped with, chatting with or standing near in the game world. Any attempt to open links obtained via other means will silently fail.
This means that in particular, you cannot open tradeskill links for your alts. It also means that if player A whispers his tradeskill link to player B, and player B whispers it to player C, then player C will be unable to open that link unless he has "encountered" player A during the current session.
I don't know if this behavior is intentional (some kind of misguided security measure?), but it seems more likely to be a design flaw in the new tradeskill hyperlink implementation. Either way this is a major departure from previous behavior and will play havoc with some addons (anything with a feature to link your alt's profession).
0
Most notably, the <databits>, <rank> and <rankmax> fields are being removed entirely and all data is being fetched dynamically from the server based on player GUID in the link. The new <pid> field is technically redundant with spellid, and is the Profession ID as returned by GetProfessionInfo().
The implications of this change are that most addons that parse the contents of the tradeskill hyperlink in any way will likely need fixes for 5.4. Addons that try to parse the databits field will likely need major changes (mine is in this category).
It also appears that as a result of this change, it's no longer possible to forge an "all recipes" tradeskill hyperlink for the user that can be clicked to open a tradeskill window containing every available spell (eg ProfessionsDatabase). Many addons have embedded this handy quality-of-life feature in one way or another, however I believe it's no longer possible to implement such a link-generation facility (unless there is some kind of backdoor or other trick I'm unaware of). Addons which totally replace the tradeskill window could potentially still offer a display of every spell, but would need to bypass the Blizzard GetTradeSkill* API's to provide the data (and could not provide an "all recipes" link for use in chat, etc). The inability to forge arbitrary trade hyperlinks may also hinder TradeSkill data-mining code.
I'm curious to hear from other TradeSkill addon authors regarding these changes and how you plan to handle them..
0
I'm the author of the original control-click to add code, and your proposed change demonstrates a lack of understanding of the algorithm, breaking it in several important ways.
It doesn't really matter that the current code ignores the 12 item limit - attempting to attach additional items is completely harmless, and the error generated informs the user that more matching items are available than could fit in this message.
0
0
Recent versions of SavedInstances include tracking of world boss kills, including Sha, Galleon, Nalak and Oondasta.
0
Regarding terminology, "coalesce" is a very well-established term in computer science (especially networking), and is exactly the right term for the situation where it is used (terms like merge, on the other hand, also have a specific, but different CS connotation). In any case it should be relatively clear from context what it means.
"Annulus sector" was not my contribution, but is nevertheless the correct mathematical term for the geometric shape in question.
I can see the argument for "dumbing down" terminology to accommodate the layman, but I prefer to use more precise phraseology when it's not too obscure. There's no harm in learning something new while playing a video game...