Conversation
| //MC_PRE_QUEUE_ITEM (1490) | ||
| HOOK_METHOD(Entity_Player, QueueItem, (ItemConfig_Item* itemConfig, int charge, bool touched, bool golden, int varData) -> void) { | ||
| const int callbackid = 1490; | ||
| ItemConfig_Item itemCopy; |
There was a problem hiding this comment.
Unused variable
I can see why you may have had here initially, but thankfully yeah, ItemConfig_Items should never be under lua ownership so pointers to them that we receive should be completely safe
| } | ||
| } | ||
| //MC_PRE_QUEUE_ITEM (1490) | ||
| HOOK_METHOD(Entity_Player, QueueItem, (ItemConfig_Item* itemConfig, int charge, bool touched, bool golden, int varData) -> void) { |
There was a problem hiding this comment.
I think that the def for this function is a bit off. This function was previously identified as having a unsigned char "flags" parameter in place of these booleans. Though I also believe that a new ItemPoolType param was added in rep+, like what happened with AddCollectible.
The fact that we do not currently have lua bindings to access the golden state nor the vardata of queued items are probably why this was overlooked. Your modification of "Touched" works, because that is the 1<<0 flag, while i think golden is 1<<1. Note that QueueItemData does not contain any boolean fields. In any case returning {Golden=true} does not work atm. Likely, modifying the vardata does not work either.
I think the function currently looks like this:
QueueItem(ItemConfig_Item* itemConfig, int charge, uint8_t flags, int varData, eItemPoolType pool)Relatedly, the QueueItemData struct grew by 4 bytes (added ItemPoolType field at the end)
For touched and golden, we could probably keep the format of passing booleans to the callback, and returning {Touched=true} etc from luaside as the support for it, and just set the appropriate bitflags on our end. We COULD pass the whole bitset flags and create an enum if you wanted to, but I legitimately think that touched and golden might be the only two flags. Plus, "Touched" is already treated as a boolean in the vanilla API in QueueItemData.
Side note that while rep+ added these new ItemPoolType params in places like AddCollectible and QueueItem, iirc it only stays tracked for active items (last I recall it did NOT get stored in the item history, as neat as that would have been), making its current usefulness a bit dubious. You could choose to exclude the pool from the callback for the time being as it might not be fully understood, and is not yet exposed in places like PRE_ADD_COLLECTIBLE yet either.
| lua_rawgeti(L, LUA_REGISTRYINDEX, g_LuaEngine->runCallbackRegistry->key); | ||
|
|
||
| lua::LuaResults result = lua::LuaCaller(L).push(callbackid) | ||
| .pushnil() |
There was a problem hiding this comment.
We should pass the player as the first parameter here.
2 participants
Adds
MC_PRE_QUEUE_ITEM, which fires before an item is added to the player's item queue. This is not to be mistaken withMC_PRE_ADD_COLLECTIBLE, which fires after an item is removed to the player's item queue.Return Type
This callback allows users to return a dictionary with the following fields: