-
Notifications
You must be signed in to change notification settings - Fork 39
MC_PRE_QUEUE_ITEM #646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
MC_PRE_QUEUE_ITEM #646
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5126,3 +5126,64 @@ HOOK_METHOD(Room, SpawnGreedModeWave, (bool unusedBool) -> void) { | |
| .call(1); | ||
| } | ||
| } | ||
| //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; | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 |
||
|
|
||
| if (CallbackState.test(callbackid - 1000)) { | ||
| lua_State* L = g_LuaEngine->_state; | ||
| lua::LuaStackProtector protector(L); | ||
|
|
||
| lua_rawgeti(L, LUA_REGISTRYINDEX, g_LuaEngine->runCallbackRegistry->key); | ||
|
|
||
| lua::LuaResults result = lua::LuaCaller(L).push(callbackid) | ||
| .pushnil() | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should pass the player as the first parameter here. |
||
| .push(itemConfig, lua::Metatables::ITEM) | ||
| .push(charge) | ||
| .push(touched) | ||
| .push(golden) | ||
| .push(varData) | ||
| .call(1); | ||
|
|
||
| if (!result) { | ||
| if (lua_istable(L, -1)) { | ||
| lua_pushnil(L); | ||
| while (lua_next(L, -2) != 0) { | ||
| if (lua_isstring(L, -2) && lua_isuserdata(L, -1)) { | ||
| const std::string key = lua_tostring(L, -2); | ||
| if (key == "ItemConfig") { | ||
| auto* retItem = lua::UserdataToData<ItemConfig_Item*>(lua_touserdata(L, -1)); | ||
| if (retItem) { | ||
| itemConfig = retItem; | ||
| } | ||
| } | ||
| } | ||
| else if (lua_isstring(L, -2) && lua_isinteger(L, -1)) { | ||
| const std::string key = lua_tostring(L, -2); | ||
| if (key == "Charge") { | ||
| charge = (int)lua_tointeger(L, -1); | ||
| } | ||
| else if (key == "VarData") { | ||
| varData = (int)lua_tointeger(L, -1); | ||
| } | ||
| } | ||
| else if (lua_isstring(L, -2) && lua_isboolean(L, -1)) { | ||
| const std::string key = lua_tostring(L, -2); | ||
| if (key == "Golden") { | ||
| golden = lua_toboolean(L, -1); | ||
| } | ||
| else if (key == "Touched") { | ||
| touched = lua_toboolean(L, -1); | ||
| } | ||
| } | ||
|
|
||
| lua_pop(L, 1); | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| super(itemConfig, charge, touched, golden, varData); | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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<<0flag, while i think golden is1<<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:
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.