[notabug] Possible bug in crafting
 

I think I might have found a bug, though it might be intended behaviour.

So the following code will reproduce the bug (assuming it is one) if bag and slot are replaced with some bagID and slotID of an item that can be researched.

EVENT_MANAGER:RegisterForEvent("A", EVENT_CRAFT_COMPLETED, function() WC = true end)
ResearchSmithingTrait( bag, slot ) WC = false
for i = 1, 10 do zo_callLater(function() if not IsPerformingCraftProcess() and not WC then d(i*30)CraftSmithingItem(1,1, 5, 2, 2, false) end end, i*30) end

Theoretically, this code should never actually craft anything. While the research request is being acted upon, IsPerformingCraftProcess() will return false, and when the research request is finished being acted upon, EVENT_CRAFT_COMPLETED should fire, and set WC to true. However, running the code shows that that is not the case. It seems there is a small window where IsPerformingCraftProcess returns false, but EVENT_CRAFT_COMPLETED has not actually fired yet. It's possible that it might have to do with latency.

My best guess is that it is due to the frame delay on events. When an event is fired from the client it enters a queue. On the next frame that queue is emptied and the events are sent to Lua. So if the crafting processing state is set in the client and the event is sent on the next line then you will experience what you described.

zo_calllater uses RegisterForUpdate.
What callbacks are called first? The update callbacks or the events? Or do they shared the same queue?

Dolgubon, haven't you had enough bugs fixed by now? Let some of us also get some bugs that need fixing! :p

Wait a second, does that sound like a volunteer? I have some bugs you can fix riiiight over here.


@votan this issue also appears without using zo_callater. I just used zo_callater to create a quick way to show the bug.


@chip so would players with lower FPS encounter this more often? I would assume then that there isn't much that can be done about it though? Or could possibly the craft state be changed closer to the event sending? (Though I think that might not work)

FPS is not related. It is always one frame after, regardless of how long a frame is. If you want to use the event, then query it when the event arrives. If you want to use update then use that. I wouldn't mix both approaches.