How to listen for container events as client?

[GrowthMindset]

I've made a mod that tracks and saves the player's inventory state client side (which it then uses for its main functions). It contains this code:

local ENV = env
GLOBAL.setfenv(1, GLOBAL)

local previous_saved_inventory = {}
local previous_saved_equip_items = {}

local function OnEquip(inst, data)
    ...
end

local function OnUnequip(inst, data)
    ...
end

local function OnItemGet(inst, data)
    print(data.item, data.item.slot)
    ...
end

local function OnItemLose(inst, data)
    print(data.slot)
    ...
end

local function initialize_inventory_and_equips(inst)
    local inventory = inst.replica.inventory
    previous_saved_inventory = inventory:GetItems()
    previous_saved_equip_items = inventory:GetEquips()
end

local function patch_OnRemoveFromEntity(self)
    self.inst:RemoveEventCallback("equip", OnEquip)
    self.inst:RemoveEventCallback("unequip", OnUnequip)
    self.inst:RemoveEventCallback("itemget", OnItemGet)
    self.inst:RemoveEventCallback("itemlose", OnItemLose)
end

ENV.AddComponentPostInit("playercontroller", function(self)
    if self.inst ~= ThePlayer then return end
    self.inst:DoTaskInTime(0, initialize_inventory_and_equips)

    self.inst:ListenForEvent("equip", OnEquip)
    self.inst:ListenForEvent("unequip", OnUnequip)
    self.inst:ListenForEvent("itemget", OnItemGet)
    self.inst:ListenForEvent("itemlose", OnItemLose)

    local old_OnRemoveFromEntity = self.OnRemoveFromEntity
    self.OnRemoveFromEntity = function(self_local, ...)
        patch_OnRemoveFromEntity(self_local)
        return old_OnRemoveFromEntity(self_local, ...)
    end
end)

Picking, dropping, and moving items in my inventory has no problems whatsoever - every equip, lose, or get is registered. But when it comes to containers i.e. backpack, I receive no event whatsoever. How do I listen for container events as a client?

Edited July 24, 2022 by GrowthMindset

[w00tyd00d]

Declare this new variable at the top and then add this to your initialize_inventory_and_equips function

 previous_saved_backpack = inventory:GetOverflowContainer()

 

Edited July 26, 2022 by w00tyd00d

[GrowthMindset]

1 hour ago, w00tyd00d said:

Declare this new variable at the top and then add this to your initialize_inventory_and_equips function

 previous_saved_backpack = inventory:GetOverflowContainer()

 

Hi, it's been a while and I already solved the backpack issue, but thanks.

My mod seems to be working fine so far but there's something still bugging me - I have no idea how exactly env and GLOBAL.setfenv(1, GLOBAL) work. I found setfenv in utils.lua but I don't understand anything. I must admit, I just copied those 2 lines from another client only mod.

I want to understand why my mod crashes without those 2 lines. Without the GLOBAL.setfenv, (and using GLOBAL. instead on locally undefined stuff) nil values pop up everywhere, while without local ENV = env (and using env.AddComponentPostInit instead), the entire game crashes just by enabling my mod.

Here's the source code if it helps: https://github.com/kurozawa6/dst-auto-slot-switch-and-re-equip

Will you please enlighten me or show me related beginner-friendly guides?

[w00tyd00d]

You don't really wanna use setfenv since your modmain is supposed to be in its own environment (for safer/more stable API integration, think of it like its own scope), by doing that you're essentially putting your modmain into the GLOBAL scope and, while in most cases is pretty harmless, can lead to some crosstalk between variables or tables if you're not careful.

Instead, it looks like you're trying to call ThePlayer by itself when it should be called as GLOBAL.ThePlayer. Try removing the top couple lines, remove the "ENV" in front of AddComponentPostInit, and add the GLOBAL reference in front of ThePlayer and see if that works.

As far as understanding why your mod crashes, the best thing you can learn to do is check your clientlog and serverlog files after a crash (on Windows is located in Documents/Klei/DoNotStarveTogether, the client log will be in the root directory and the server log will be in the respective cluster_# folder's master directory if you crashed in the overworld, or caves directory if you crashed in the caves) for any Lua errors that have been logged. There should always be some sort of error log in either of those files when the game crashes depending on if it was a crash on the server or the client (check near the bottom of the log or search for "lua error"), but it should directly tell you the type of error it was, in what file the error occurred in, and at what line the error occurred at. Then you're left up to tracing it back yourself and trying to find the discrepancy that caused the error, as the context can vary greatly depending on the error. This will be the same case for just about any program you ever write, so it's a good skill to learn asap lol

[GrowthMindset]

6 minutes ago, w00tyd00d said:

Instead, it looks like you're trying to call ThePlayer by itself when it should be called as GLOBAL.ThePlayer. Try removing the top couple lines, remove the "ENV" in front of AddComponentPostInit, and add the GLOBAL reference in front of ThePlayer and see if that works.

The thing is, I'm using Visual Studio Code and I can see whenever there's a ThePlayer that's undefined. So I'm pretty sure I've added "GLOBAL." in every ThePlayer in my code. Yet there are still nil value crashes.

6 minutes ago, w00tyd00d said:

As far as understanding why your mod crashes, the best thing you can learn to do is check your clientlog and serverlog files after a crash (on Windows is located in Documents/Klei/DoNotStarveTogether, the client log will be in the root directory and the server log will be in the respective cluster_# folder's master directory if you crashed in the overworld, or caves directory if you crashed in the caves)

Thanks but I already do this. The error that comes up whenever I use GLOBAL. 's instead of GLOBAL.setfenv is always something about shared local tables being nil, like the previous_saved inventory or the previous_saved_backpack. It's consistently the case.

Have you checked the source code yet? I'll try to fiddle around some more in the meantime.

[w00tyd00d]

4 minutes ago, GrowthMindset said:

The thing is, I'm using Visual Studio Code and I can see whenever there's a ThePlayer that's undefined. So I'm pretty sure I've added "GLOBAL." in every ThePlayer in my code. Yet there are still nil value crashes.

You have this at the bottom of your modmain, this is what I was referring to.

ENV.AddComponentPostInit("playercontroller", function(self)
    if self.inst ~= ThePlayer then return end
    self.inst:DoTaskInTime(0, initialize_player_and_backpack)

    local old_OnRemoveFromEntity = self.OnRemoveFromEntity
    self.OnRemoveFromEntity = function(self_local, ...)
        RemoveEventCallbacksPlayer(self_local.inst)
        return old_OnRemoveFromEntity(self_local, ...)
    end
end)

Since your modmain is currently in the GLOBAL scope due to setfenv, calling ThePlayer alone will work fine, but you shouldn't be in the GLOBAL scope in your modmain so you should get rid of setfenv and add the GLOBAL reference to ThePlayer instead. You also have another reference to ThePlayer on line 27 which should also have its own GLOBAL scope reference.
 

11 minutes ago, GrowthMindset said:

The error that comes up whenever I use GLOBAL. 's instead of GLOBAL.setfenv is always something about shared local tables being nil, like the previous_saved inventory or the previous_saved_backpack. It's consistently the case.

Well it should be noted that if you want to reference these values during runtime, the GLOBAL scope doesn't have reverse lookup capability of seeing your modmain scope, so data like that should probably be saved directly to an instance property or something instead of a local variable to your modmain. I would get rid of the local declarations up top and instead, just assign the values directly to your instance instead.

inst.previous_saved_inventory = inventory:GetItems()
inst.latest_equip_items = inventory:GetEquips()

Just make sure to pass a reference of the inst to the functions that set up your variables if they don't already have it. With this, you can actually serialize the data if you so wish as well to make sure it persists between game sessions and shards.

[GrowthMindset]

28 minutes ago, w00tyd00d said:

Since your modmain is currently in the GLOBAL scope due to setfenv,

Now I think I'm starting to understand that setfenv thing. Thank you

28 minutes ago, w00tyd00d said:

Well it should be noted that if you want to reference these values during runtime, the GLOBAL scope doesn't have reverse lookup capability of seeing your modmain scope

So that's why it's always the local variables declared at the top of modmain that are always returning nil. Thank you so much!

28 minutes ago, w00tyd00d said:

so data like that should probably be saved directly to an instance property or something instead of a local variable to your modmain. I would get rid of the local declarations up top and instead, just assign the values directly to your instance instead.

inst.previous_saved_inventory = inventory:GetItems()
inst.latest_equip_items = inventory:GetEquips()

Just make sure to pass a reference of the inst to the functions that set up your variables if they don't already have it. With this, you can actually serialize the data if you so wish as well to make sure it persists between game sessions and shards.

Thanks for the idea! I've done something similar in my farming QoL mod. But out of curiosity, how can we make sure the values we assign to inst do not have the same names with the ones in the vanilla game scripts (and perhaps some other mods')? Do we look them up in the scripts or should we just make sure to use unique names? Or maybe they wouldn't conflict at all for some reason?

 

Oh and I've another question. Are these RemoveEventCallbacks (that I patch into the playercontroller's OnRemoveFromEntity) actually necessary/useful?

local function RemoveEventCallbacksPlayer(inst)
    inst:RemoveEventCallback("itemget", InventoryOnItemGet)
    inst:RemoveEventCallback("itemlose", InventoryOnItemLose)
    inst:RemoveEventCallback("equip", OnEquip)
    inst:RemoveEventCallback("unequip", OnUnequip)
end

ENV.AddComponentPostInit("playercontroller", function(self)
    if self.inst ~= ThePlayer then return end
    self.inst:DoTaskInTime(0, initialize_player_and_backpack)

    local old_OnRemoveFromEntity = self.OnRemoveFromEntity
    self.OnRemoveFromEntity = function(self_local, ...)
        RemoveEventCallbacksPlayer(self_local.inst)
        return old_OnRemoveFromEntity(self_local, ...)
    end
end)

 

Edited July 26, 2022 by GrowthMindset

[w00tyd00d]

5 minutes ago, GrowthMindset said:

Just to clarify, I add GLOBAL. on every ThePlayer only when I remove the GLOBAL.setfenv at the top. So the current code doesn't have any GLOBAL. before ThePlayer because it's working just fine with GLOBAL.setfenv(1, GLOBAL). Anyways,

Haha I figured as much, just wanted to make sure you were aware
 

6 minutes ago, GrowthMindset said:

But out of curiosity, how can we make sure the values we assign to inst do not have the same names with the ones in the vanilla game scripts (and perhaps some other mods')?

Usually just a unique name will suffice, I tend to just prefix any I add with something relating to the mod itself, something like "NameOfYourMod_" followed by the property name
 

9 minutes ago, GrowthMindset said:

Oh and I've another question. Are these RemoveEventCallbacks (that I patch into the playercontroller's OnRemoveFromEntity) actually necessary/useful?

I'm not fully certain because I don't have the entire context behind your mod, but I can at least say that as long as you don't need to change the functionality of how the inventories work, then you most likely don't need to touch those event callbacks either. The game will automatically add/remove the necessary events it needs to function as normal.

Try removing them and see what happens lol the worst thing that'll happen is it crashes or doesn't work as intended.

[GrowthMindset]

16 minutes ago, w00tyd00d said:

Usually just a unique name will suffice, I tend to just prefix any I add with something relating to the mod itself, something like "NameOfYourMod_" followed by the property name

Thanks. I was adding to the values' names as we speak. I guess my convention would be _mod_modinitials for now. There can really be name conflicts, I see. This made me really curious. I hope there weren't too many conflicts between mods just because they used the same names of values within the same instances.

16 minutes ago, w00tyd00d said:

I'm not fully certain because I don't have the entire context behind your mod, but I can at least say that as long as you don't need to change the functionality of how the inventories work, then you most likely don't need to touch those event callbacks either. The game will automatically add/remove the necessary events it needs to function as normal.

Try removing them and see what happens lol the worst thing that'll happen is it crashes or doesn't work as intended.

Well I don't know if it was just confirmation bias because I haven't done enough rigorous tests, but I've noticed not having those remove event callbacks caused some functions to occasionally stop working (mostly how items are auto moved). But maybe it was something else, like the saved inventories being messed up when moving items around while the game is paused, going in and out of caves, or something...

I hope binding the old local variables into inst would fix those mysterious crash-less occasional malfunctioning somehow. Detective work with print spams and lots of c_reset() can get pretty tiring lol

Edited July 26, 2022 by GrowthMindset

[GrowthMindset]

Ok so this is harder than I thought.

1 hour ago, w00tyd00d said:

inst.previous_saved_inventory = inventory:GetItems()
inst.latest_equip_items = inventory:GetEquips()

Just make sure to pass a reference of the inst to the functions that set up your variables if they don't already have it. With this, you can actually serialize the data if you so wish as well to make sure it persists between game sessions and shards.

I have these functions for backpack's container's inst events...

local function update_backpack_on_get_fn_to_delay(_, get_slot, item)
    previous_saved_backpack[get_slot] = item
end

local function BackpackOnItemGet(inst, data)
    local item = data.item
    local get_slot = data.slot
    local equippable = item.replica.equippable
    if equippable ~= nil then
        local eslot = equippable:EquipSlot()
        latest_get_item_per_eslot[eslot] = item
        latest_get_slot_per_eslot[eslot] = get_slot
        latest_get_item_is_inbackpack_per_eslot[eslot] = true
    end
    inst:DoTaskInTime(0, update_backpack_on_get_fn_to_delay, get_slot, item)
    --print("InventoryOnItemGet data:", item, get_slot, eslot, "Finished Updating Saved Backpack")
end

As you can see, BackpackOnItemGet uses latest_get_item_per_eslot... which similar event functions (but for the player inventory) also use. And

local function ListenForEventsBackpack(inst)
    inst:ListenForEvent("itemget", BackpackOnItemGet)
    inst:ListenForEvent("itemlose", BackpackOnItemLose)
end

seem to only allow (inst, data) as args to those event functions.
Perhaps they actually don't? Or should I start thinking of other ways?

[w00tyd00d]

So what exactly are you trying to accomplish, you want to record something to the player's instance whenever the backpack hears the itemget and itemlose events? You could always just record it to the backpack's instance, then relay that information back to the player's instance and vice-versa?

Again, I'm not entirely sure what the goal of your mod is so it's hard for me to pinpoint the exact right answer for you, but I can at least try to help you with general tips.

[GrowthMindset]

Pardon me for lacking specifics with the previous error. But I figured it out. This is actually crazy.

Turns out previous_saved_backpack or any local table whatsoever weren't the ones that were returning nil. It was "next"!

[to edit for more details, i just want to let you know asap]

Edit:

local function OnEquip(inst, data)
    if not (type(data) == "table" and data.eslot and data.item) then
        return
    end
    local latest_equipped_item = data.item
    local eslot = data.eslot
    local previous_equipped_item = nil
    local removed_slot = nil
    local is_from_backpack = false
    if latest_equip_items[eslot] then
        previous_equipped_item = latest_equip_items[eslot]
    end
    latest_equip_items[eslot] = latest_equipped_item

    if eslot == GLOBAL.EQUIPSLOTS.HANDS then
        saved_handequip_is_projectile = latest_equipped_item:HasTag("projectile")
    end

    for slot, item in pairs(previous_saved_inventory) do
        --print(slot, item) --verbose, for debugging only
        if item == latest_equipped_item then -- if the latest equipped item is found on the previous saved inventory, then get its slot as destination slot
            removed_slot = slot
            break
        end
    end
    if removed_slot == nil then --and next(previous_saved_backpack) ~= nil then

It's that last line that always yielded an error. And I'm so sorry for misunderstanding the error in the logs. It's been a tiring day. So this was always the error whenever I remove GLOBAL.setfenv(1, GLOBAL):

Spoiler

[00:02:53]: Server Unpaused    
[00:02:54]: [string "../mods/Project2/modmain.lua"]:247: attempt to call global 'next' (a nil value)
LUA ERROR stack traceback:
../mods/Project2/modmain.lua:247 in (local) fn (Lua) <222-272>
   inst = 100183 - wolfgang (valid:true)
   data = table: 0x52feda0
   latest_equipped_item = 101742 - nightsword (valid:true)
   eslot = hands
   previous_equipped_item = 101758 - cane (valid:true)
   removed_slot = nil
   is_from_backpack = false
scripts/entityscript.lua:1150 in (method) PushEvent (Lua) <1137-1164>

      DetachClassified = function - script
[00:02:54]: [string "../mods/Project2/modmain.lua"]:247: attempt to call global 'next' (a nil value)
LUA ERROR stack traceback:
    ../mods/Project2/modmain.lua:247 in (local) fn (Lua) <222-272>
    scripts/entityscript.lua:1150 in (method) PushEvent (Lua) <1137-1164>
    scripts/prefabs/inventory_classified.lua:358 in (field) fn (Lua) <351-362>
    scripts/scheduler.lua:186 in (method) OnTick (Lua) <164-216>
    scripts/scheduler.lua:419 in (global) RunStaticScheduler (Lua) <417-425>
    scripts/update.lua:172 in () ? (Lua) <163-214>
 

My brain just auto assumed it was the table inside the next() function that was returning nil. But upon further investigation, it was actually the function itself, next! This seems so crazy to me. I've always known next to be a common LUA utility I often use for checking if tables are empty. But apparently, when called by a function invoked with ListenForEvent, such as what happens with OnEquip, the common LUA utility, next, is defined as something else!

This really seems to be the case as my usage of next in other local functions in my modmain are doing fine. So I guess OnEquip is in the GLOBAL scope when called by ListenForEvent, and "next" is defined as something else in the GLOBAL scope? If true, then why would the devs redefine something as common in LUA as "next" as something else?

Anyways so I commented out "next(previous_saved_backpack)" and my mod is now working fine, which just reinforces my assumptions. Nevertheless, I would rather be more certain:

1. Does a function called by ListenForEvent such as OnEquip above have a GLOBAL scope?
2. Is next really defined as something else other than as a common LUA utility in the game's GLOBAL scope?
3. Why would the devs do that and what did they set next into?

28 minutes ago, w00tyd00d said:

Again, I'm not entirely sure what the goal of your mod is so it's hard for me to pinpoint the exact right answer for you, but I can at least try to help you with general tips.

Thanks. As you can see from the source code's readme, my mod attempts to automatically switch the slot of your equipped item replaced by another equipment to the latter's previous slot, as well as auto equips/reloads weapons/projectiles upon breaking or running out of ammo.

Anyway, please read my edited reply above. I'm still in disbelief that next is actually defined as something else and I really need some answers o_o

Edited July 26, 2022 by GrowthMindset

[w00tyd00d]

It's not that I don't think next is written differently in the global scope, it's that I don't think it exists in the modmain environment. I'm still a bit naïve to how Lua environments work myself, but it could be like the case with require in modmain where you have to declare it from the global scope. So you could try this and see if it works

local next = GLOBAL.next

 

1 hour ago, GrowthMindset said:

Does a function called by ListenForEvent such as OnEquip above have a GLOBAL scope?

No, those are just callback functions that are usually just defined locally to wherever the ListenForEvent call is made.

[GrowthMindset]

13 minutes ago, w00tyd00d said:

It's not that I don't think next is written differently in the global scope, it's that I don't think it exists in the modmain environment. I'm still a bit naïve to how Lua environments work myself, but it could be like the case with require in modmain where you have to declare it from the global scope. ..

...No, those are just callback functions that are usually just defined locally to wherever the ListenForEvent call is made.

Dang. I've made so many wrong assumptions from next returning nil. And turns out all my next calls in my modmain actually return nil, so you're definitely right. Hmm... It's weird how a common utility function wouldn't exist in an environment. I would love to understand how these environment things work. Did the devs intentionally exclude out some functions like next in modmain for optimization or something?

15 minutes ago, w00tyd00d said:

So you could try this and see if it works

local next = GLOBAL.next

 

Well I realized just now that I actually don't need to use next for checking empty tables. My mod is working perfectly fine now without them. But out of curiosity, would local next = GLOBAL.next the "proper" way to do it, even if it works? I'll try that now regardless.

[w00tyd00d]

Well I'm glad to hear you at least got it working my friend! haha

2 minutes ago, GrowthMindset said:

But out of curiosity, would local next = GLOBAL.next the "proper" way to do it, even if it works?

Yeah, from my understanding when working in a separate Lua environment, unless a function that's declared in the global scope is made explicitly available to you, you have to reference it from the global scope when you want to call it. They may have had a reason to not include next and require, or it could have been an oversight lol I've no idea tbh

[GrowthMindset]

Pardon me for an unrelated question, but there's something bothering me regarding git workflow. So I have this test branch which I use to aggressively test new code. I treat it as a different mod with its name in modinfo.lua as "[ModName] Test Branch".

Now the problem is, whenever I feel satisfied and safe with my update in this test branch, I merge it into main, and now main's name in modinfo becomes "[ModName] Test Branch]" as well, which is annoying.

So what I do is I just edit modinfo in main after merging and then commit that. But it feels off. I thought of adding modinfo.lua in gitignore but it failed and I learned from Google gitignore doesn't work like that and stopping to track modinfo doesn't make any sense anyway as I might add configuration features there.

Is there a way to be able to merge the mod's test branch into my main without affecting main's name in modinfo and vice versa?

1 minute ago, w00tyd00d said:

Yeah, from my understanding when working in a separate Lua environment, unless a function that's declared in the global scope is made explicitly available to you, you have to reference it from the global scope when you want to call it. They may have had a reason to not include next and require, or it could have been an oversight lol I've no idea tbh

OHH!! I roughly remember just now from a modding guide somewhere that functions such as pairs, ipairs, print, and many other stuff are in something's environment, but I was a bit confused because I couldn't find next in there!!! It's all starting to make sense now! Thank you!!

Would really love to know why they didn't include next hmm... But I guess it's another mystery for another day. I've to clean up my code from all this bugtesting... and to solve this annoying modinfo mod name problem as well.

[w00tyd00d]

25 minutes ago, GrowthMindset said:

Is there a way to be able to merge the mod's test branch into my main without affecting main's name in modinfo and vice versa?

I'm gunna be totally honest, I have no idea haha I've been putting off learning git for years now, maybe someone else with more insight on it can chime in to help but you're SOL with me lol

Anyways, best of luck on the mod o/

[GrowthMindset]

26 minutes ago, w00tyd00d said:

I'm gunna be totally honest, I have no idea haha I've been putting off learning git for years now, maybe someone else with more insight on it can chime in to help but you're SOL with me lol

Anyways, best of luck on the mod o/

Thanks! Well for when you ever start learning git, I hope you'd find this useful:

The solution I found is to use the same modinfo name and version in the test branch as the main's (no more merge conflicts), and to just use a folder named local that is ignored (via gitignore) in which I would copy test branch's modmain.lua and the contents of modinfo.lua excluding the name and version whenever I want to test. And then I would copy those 2 files into the "production folder" and proceed to test the test branch mod.

This way, there would be no merge conflicts and I wouldn't have to correct the modinfo name and version every single time I want to test.

Anyways, thank you again for all the help and enlightenment! Have a nice day~

Edited July 26, 2022 by GrowthMindset
corrected an oopsie