Bulk queuing item becomes individual crafts

[Shaderx]

Skillet 5.03 enUS

Whenever i bulk queue or create certain items like fated fortune cookies, it list it individually.

[b-morgan]

Unfortunately, this is the current behavior when a recipe contains modified reagents (a reagent with multiple qualities). It is the lesser of two evils. This is, of course, not the desired behavior but I've spent many hours trying to figure out how to make Skillet work. Note that recipes without modified reagents are not effected.

If Skillet creates or queues and then processes a single recipe with a count of 50, it will succeed on the first one and then fail on the second (and there is no "error message" to tell me why). Analysis of Blizzard's own use of its API shows that an input count of 50 will get internally split into 50 individual calls to C_TradeSkillUI.CraftRecipe but if Skillet tries to mimic that behavior, the second call fails because Blizzard requires a hardware event (mouse click or key press). By splitting the count of 50 into 50 individual queue entries, Skillet's other features like the shopping list, fetching items from the banks and/or merchants will still work and you can press the process button 50 times to get your items.

The behavior of the Blizzard UI makes sense. For example, this recipe requires 2 Silken Gemdust per execution or 100 total for the entire batch of 50 creates. This can be satisfied by 100 of any one of three qualities including any mix of the three qualitied that total 100. The call to C_TradeSkillUI.CraftRecipe wants to know EXACTLY what mix is being used in each call.

I am hampered by the lack of documentation, the lack of an error message, and a behavior by the Blizzard UI that I cannot duplicate. Would you prefer a single queue entry that will not process or the current behavior of splitting the request into individual queue entries that will process with the appropriate number of hardware events?

I have added to the Skillet UI a button that will open the Blizzard UI at the same recipe. In this case, I suggest using the Blizzard UI for the final execution. Skillet can be used to track and obtain the required reagents.

[b-morgan]

Skillet-5.04-alpha1 has some fixes to the processing of these "split" recipes.

[Shaderx]

The behavior of the Blizzard UI makes sense. For example, this recipe requires 2 Silken Gemdust per execution or 100 total for the entire batch of 50 creates. This can be satisfied by 100 of any one of three qualities including any mix of the three qualitied that total 100. The call to C_TradeSkillUI.CraftRecipe wants to know EXACTLY what mix is being used in each call.

I see, since skillet already have the use best quality reagent or worst quality reagent toggle, would it be better to split it in such a way that you can bulk process the majority of the queue?

Say for this example i have 61 R2 and 39 R1, 61 mod 2 checking if there is overflow.

So we would call splits C_TradeSkillUI.CraftRecipe 30 R2 C_TradeSkillUI.CraftRecipe 1 R1/2 C_TradeSkillUI.CraftRecipe 19 R1

I am just going out on a limb here, would this behavior be better?

[b-morgan]

Your suggestion would be better if I could get Skillet (or more specifically C_TradeSkillUI.CraftRecipe) to successfully execute a call when there are modified reagents and the count is greater than one.

Alternatively, I need to find an (undocumented) function that I can call instead of C_TradeSkillUI.CraftRecipe that does what the Blizzard UI does, convert the count into multiple calls of C_TradeSkillUI.CraftRecipe with counts of one that bypass the hardware event restriction.

I'm frustrated with the current behavior and I'd love to find a solution.

Your example shows what a colossal failure the current implementation is. It's not as bad with Engineering where many recipes use crafted reagents and those crafted reagents use modified reagents. Skillet can (as it always has) queue the crafted reagents to be created before the main recipe is created. This always took multiple hardware events but the number of them with the current implementation only goes up by a couple.

[Shaderx]

Alternatively, I need to find an (undocumented) function that I can call instead of C_TradeSkillUI.CraftRecipe that does what the Blizzard UI does, convert the count into multiple calls of C_TradeSkillUI.CraftRecipe with counts of one that bypass the hardware event restriction.

I see! This is why its being the way it is, there is no function that we know of that can call bulk craft with a modified reagents. Other than the one blizzard used internally.

[Shaderx]

Actually, a jankier way would be to use a mousewheel like how TSM does it in the good old days, whenever the window is open it will bind mousewheel to a macro that execute post/buy/craft ect. Skillet can just have a checkbox to activate mousewheel bind to "hardware event" to craft next in line. Unchecking that would revert it back to regular zoom out/in.

[b-morgan]

Hmmm... Using the mousewheel (scrollwheel) sounds like a hack but perhaps a keybind for the process button might be better.

I'll have to think about this one and maybe do some experiments.

[b-morgan]

I've thought about it and decided that this is how Skillet is going to be for the foreseeable future.