So I'm trying to help out the LFG system... first by giving users a way to strategize their LFG behavior by viewing all their options.

/lfgwho would iterate through all LFG queries visible to the user

On the firstiteration all is well, but following calls to LFGQuery (which originate from either UPDATE_LFG_LIST or an OnUpdate) are blocked. Additionally CanSendLFGQuery returns true in these cases.

I would very much like to build a better LFG UI and this is a big part of the solution.

Also it looks like LFGQuery() can be called by LFGFrame.lua LFMFrame_OnEvent so the Blizzard LFG UI doesn't even play by these rules ;)

---

Q u o t e:
B) Spamming of the service calls (which could cause performance issues on the server side)

---

Possible but unfortunate... I would think that CanSendLFGQuery and booting clients that disregard its returns and spam would be a fit solution.

I don't agree that (A) would be a problem. We don't have such restrictions on the /who system do we? (a la Census+)

I guess there's good news... SetLookingForGroup() is not restricted in this way so at least I'll have something to release on Jan 16

---

Q u o t e:
Players dont want to be put into groups with people who aren't actually there at their computers, similarly they dont want to be invited into groups led by players that aren't actually there either.

---

The only problem with this reason is that the SetLookingForGroup function is unrestricted... so any addon using that function is actually able to LFG unattended characters.

But I do completely agree with you that this would be undesirable. Which is why my mod clears your LFG by default when you go AFK/DND or you're ungrouped and LFM while AFK/DND.

Finally, since we can have addons perform unattended /who queries for us I'm still missing the point of being able to perform a similar data retrieval operation on the LFG system.


to be clear - in a well-behaved addon both LFGQuery and SetLookingForGroup have valid (and IMO necessary) use-cases that should be permitted without direct user action.

---

Q u o t e:
It all depends what you meant by 'Blocked' above -- was it an explicit "you can't do this" or just a failure for the function to do anything

---

no I mean "Blocked Addon" event firing ;)


[2006/12/28 16:27:48-266-x1]: <event>ADDON_ACTION_BLOCKED:AddOn 'SlashLFG' tried to call the protected function 'LFGQuery()'.
<in C code>: in function `LFGQuery'
SlashLFG\Core.lua:294: in function `ProcessQuery'
SlashLFG\Core.lua:329: in function <Interface\AddOns\SlashLFG\Core.lua:299>
<in C code>: ?
AceEvent-2.0-22135 (Ace2):319: in function `TriggerEvent'
AceEvent-2.0-22135 (Ace2):961: in function <Interface\AddOns\Ace2\AceEvent-2.0\AceEvent-2.0.lua:954>

---

(edit: and yes the first execution of LFGQuery succeeded producing a result count and results I can iterate over, but the followup LFGQuery that I fire in my UPDATE_LFG_LIST handler is the one which is blocked)

At any rate... whatever the official reason for the interactivity restriction on LFGQuery I'm hoping to get the issue noticed and someday changed.

If we get wide adoption of a fairly high quality LFG addon I think it would help adoption of the new system and reduce player frustration in the coming months.

Here's to upping the bar. Cheers.

what an LFG system that works.... NOOooo -- that'll never fly

...I only really understood about half of what was actualy said (not being a programer), seems to be that IMHO they should unProtect the entire LFG system, but Require AutoJoinng a group to follow the "Anti-AFK" idea and the Joing a queue for a perticular instance require a hardware event. :D

...and Basic ... how much of that bug sack report is the addon being blocked vs. ACE being tainted and thus blocked? ... :D try developing the addon w/o ace then see where u can Ace it as ive seen revisions of the Core Ace being rolled out daily

any way to leave them interactive but unProtected?

cuz quite frankly the UI sucks for the LFG system, and a reskinning is a must if doable :D

You are asking for this in order to support a feature you believe will be helpful... scanning all available groups.

I agree that this would be beneficial and forcing the user to make more (seemingly unnecessary) hardware interactions is generally bad... But in this case I believe that there is a solution.

Allow the user to indicate which instances/quests/zones they might be interested in. This could easily be done with checkboxes. This seems like something you could save between sessions and a lot of people would be happy just by being able to set the same 3 LFG that they always do. Heck if you wanted to get fancy, allow them to create LFG sets so they can save many different combinations of things they want to LFG for.

If Blizzard is worried about creating excess lag due to large numbers of LFG queries, maybe you could get some feedback on a limit to how many checkboxes can be chacked at once or how many seconds apart each query needs to be.

Once a user has indicated all the things they would like to find a group for... they click a search button which allows you to perform the first query. Then you can loop through all the rest of their selections and make them click an OK button to move on to the next one. A bit tedious for the user, but I believe that this might get the job done.

I would love to see some improvements to the LFG interface, especially the kind of improvements that don't depend on adoption rates of a 3rd party mod in order to become useful.

---

Q u o t e:
...and Basic ... how much of that bug sack report is the addon being blocked vs. ACE being tainted and thus blocked?

---

100% my addon

---

Q u o t e:
The LFG query functions are restricted to interactive action, because they are an expensive function on the server. If addons were able to query the LFG system in a non-interactive way, it would add additional load on the server, and increase lag.

---

Thanks for the official word Slouken.

What I'm hearing is that it's not an oversight that SetLookingForGroup is unrestricted. I hope that's the case because I'm going to do all that I can with what you've given me ;)

---

Q u o t e:
Allow the user to indicate which instances/quests/zones they might be interested in. This could easily be done with checkboxes.

---

That's actually the direction I'm headed... and it doesn't require a lot of calls to LFGQuery. However until I work out a way to easily browse the LFG system users will be relying on the Blizzard browser or the AutoJoin / AutoFill functions (which I am also going to take advantage of).

---

Q u o t e:
I would love to see some improvements to the LFG interface, especially the kind of improvements that don't depend on adoption rates of a 3rd party mod in order to become useful.

---

I hope to have a proof of concept up "soon" and will gladly donate the work for inclusion in the WoW Client UI. (tho it will depend on TouristLib I'm sure Blizz has access to that info on their side as well)

---

Q u o t e:
I'll look into it. I'm not sure if it's supposed to be restricted or not. If it results in an LFG query then it probably was supposed to be restricted.

---

I can probably work with the following restrictions:
SetLookingForGroup / SetLookingForMore turns AutoJoin / AutoFill off when called outside of user interaction contexts
Enabling AutoJoin / AutoFill are protected functions requiring user interaction

If that's not possible I'll have to prompt the user for interactivity whenever they do things like change zones (not when on a taxi) and level up. I suppose that's not the worst that could happen, but it will make my solution less than optimal.