This is a weird issue, that doesn't all players at the same time.

Sometimes a player can't open their backpacks with the command or if they bind is to a key with: bind key "backpack.open"
It weird because one player can't open it, and other players can using the bind. But then when i issue "o.reload Backpacks" the player can open the backpack again.

This one is hard to explain for me, but it's a weird issue, because if there is for example 25 players online, everyone except 1 person can open the backpack, but after a plugin reload all can. and sometimes multiple people can't open the backpack while others can.

I'm not sure if you understand what i mean.

Thanks for your hard work!

Which version of Backpacks are you using? When did this start happening? Are you using Event Manager or any other plugin that blocks backpack usage at certain times?

There used to be a bug like 6 months ago where players dying while offline could prevent their backpack from being opened for a while, but that was fixed.

There was also an unreported bug that was fixed recently where if a player had their backpack blocked from opening due to being in an event, it would get stuck unable to open, but this was fixed in v3.4.0.

If you are already using v3.4.0 and weren't seeing this issue before, then it may be related to the new functionality to toggle the backpack closed if already open, though I haven't seen any issues with it myself.

Hello, thank you for the swift response.

I'm using the latest available version, which is: 'v3.4.0'
Not sure when it started happening, i've had a couple reports from players that it happens to them. But sporadically. Like i explained it happens sometimes, and when it happens it only affects 1 or 2 players instead of all players online.

I'm not using Event Manager. or anything that alters anything looting or backpacks related.
I might setup for the time being a timer to reload the backpack plugin at a certain interval. to prevent it.

It's happens rarely, usually gets fixed with a reload of the plugin.
So i'm not sure when it started happening, What i do know is that this has not been reported before the current version.
So perhaps it might be related to what you said. But i personally don't know if it is related.

I'll keep an eye on the progress of the reports i get, and i'll try to see if i can figure out whether something else happens the moment people can't open the backpack. Maybe a conflict with a different plugin.

I'll try to update the post when and if i find out something of importance.
Thank you for your time!

Instead of applying hacks like timed reloads which won't help me fix the plugin, I would ask that you try some recommendations to help narrow down the root cause.

First, when a player is having issues, ask them to loot a random container, close it, and then try to open their backpack again. If this works, it means the _openBackpacks state was stale for some reason. I don't know what could cause that, but the old version of Backpacks had some code that would automatically clean up that issue, so that might be why it wasn't noticed before. The feature in v3.4.0 for allowing the backpack to be toggled closed will actually prevent the automatic cleanup. The only thing that doesn't make sense about this hypothesis is that the cleanup only happens in the console/keybind/button variation, so presumably players could have encountered this before when using the /backpack command and just not reported it.

After testing that, you can try changing the following code starting at line 380 in Backpacks.cs.

if (_openBackpacks.ContainsKey(player))
{
    // HACK: Send empty respawn information to fully close the player inventory (toggle backpack closed)
    player.ClientRPCPlayer(null, player, "OnRespawnInformation");
    return;
}

player.EndLooting();
timer.Once(0.1f, () => Backpack.Get(player.userID).Open(player));

to:

var backpackIsOpen = _openBackpacks.ContainsKey(player);
player.EndLooting();

if (backpackIsOpen)
{
    // HACK: Send empty respawn information to fully close the player inventory (toggle backpack closed)
    player.ClientRPCPlayer(null, player, "OnRespawnInformation");
    return;
}

timer.Once(0.1f, () => Backpack.Get(player.userID).Open(player));​

Ok, next time when i get such report, i'll see if i can follow your steps, and i will report back to this thread.
And try your solution in the process.

WhiteThunder

Instead of applying hacks like timed reloads which won't help me fix the plugin, I would ask that you try some recommendations to help narrow down the root cause.

First, when a player is having issues, ask them to loot a random container, close it, and then try to open their backpack again. If this works, it means the _openBackpacks state was stale for some reason. I don't know what could cause that, but the old version of Backpacks had some code that would automatically clean up that issue, so that might be why it wasn't noticed before. The feature in v3.4.0 for allowing the backpack to be toggled closed will actually prevent the automatic cleanup. The only thing that doesn't make sense about this hypothesis is that the cleanup only happens in the console/keybind/button variation, so presumably players could have encountered this before when using the /backpack command and just not reported it.

After testing that, you can try changing the following code starting at line 380 in Backpacks.cs.

if (_openBackpacks.ContainsKey(player))
{
    // HACK: Send empty respawn information to fully close the player inventory (toggle backpack closed)
    player.ClientRPCPlayer(null, player, "OnRespawnInformation");
    return;
}

player.EndLooting();
timer.Once(0.1f, () => Backpack.Get(player.userID).Open(player));

to:

var backpackIsOpen = _openBackpacks.ContainsKey(player);
player.EndLooting();

if (backpackIsOpen)
{
    // HACK: Send empty respawn information to fully close the player inventory (toggle backpack closed)
    player.ClientRPCPlayer(null, player, "OnRespawnInformation");
    return;
}

timer.Once(0.1f, () => Backpack.Get(player.userID).Open(player));​

 

Then let me know if the issue persists.

So i had a report again, and i made the player do what you said, for them to open a different container and close it and trying to open the backpack again. And that did indeed work that way.

They werent able to open the backpack, but where after they opened a random container.

Hope to have you informed.
I will apply the code example and see if they that fixes it.

Skillz

So i had a report again, and i made the player do what you said, for them to open a different container and close it and trying to open the backpack again. And that did indeed work that way.

They werent able to open the backpack, but where after they opened a random container.

Hope to have you informed.
I will apply the code example and see if they that fixes it.

Players on the server I help run, have started to experience this as well. (My self included)

Plugin version 3.5.0

Tried the code change, still doesn't correct the issue along with opening supply drops and and then checking.

Vortox14

Players on the server I help run, have started to experience this as well. (My self included)

Plugin version 3.5.0

Tried the code change, still doesn't correct the issue along with opening supply drops and and then checking.

1. Did this only start happening after upgrading to v3.5.0? Were you using v3.4.0 for a bit with no issues?
2. Are the players who experience this issue using the chat command, console command or UI button to open their backpacks?
3. When you experienced the issue yourself, does it happen consistently or only some of the time? For example, when it doesn't work, if you keep retrying several times shortly after does it work any of those times?
4. Can you clarify if the opening and closing another container works? Not sure if that's what you meant by opening a supply drop and checking.

NextTick(() => Backpack.Get(player.userID).Open(player));​

change to:

timer.Once(0.5f, () => Backpack.Get(player.userID).Open(player));

Line 393:

NextTick(() => Backpack.Get(player.userID).Open(player));

change to:

timer.Once(0.1f, () => Backpack.Get(player.userID).Open(player));

<code>[Oxide] 22:45 [Info] Backpacks was compiled successfully in 2344ms
[Oxide] 22:45 [Info] Unloaded plugin Backpacks v3.5.0 by LaserHydra
[Oxide] 22:45 [Info] Loaded plugin Backpacks v3.5.0 by LaserHydra</code>

oof that compile time.

---

Anyways, It's working for me as of right now with the 'revert', but I'd have to give it some time, for checks and balances.

Vortox14

<code>[Oxide] 22:45 [Info] Backpacks was compiled successfully in 2344ms
[Oxide] 22:45 [Info] Unloaded plugin Backpacks v3.5.0 by LaserHydra
[Oxide] 22:45 [Info] Loaded plugin Backpacks v3.5.0 by LaserHydra</code>

oof that compile time.

---

Anyways, It's working for me as of right now with the 'revert', but I'd have to give it some time, for checks and balances.

Plugins often take a few seconds to compile. It's irrelevant since it is done in a separate process so it doesn't stall the server.

I managed to reproduce the issue consistently where the chat command could not open the backpack. I noticed that it did in fact open but closed instantly, as a corresponding UI button appeared very briefly. Not sure why it didn't happen in my previous testing, or why nobody reported it during the v3.5.0 beta. While adding back the delay in small increments, I noticed it seemed related to client FPS, where lower FPS meant the backpack would be more likely to close instantly, probably because the chat window was still closing.

I've released Backpacks v3.5.1 which re-introduces the delay for the chat command (0.5 seconds). I also increased the delay from 0.1 second to 0.5 seconds when clicking the GUI button since the chat can be open for that case. I did not re-introduce the delay when the console command is used via key bind, since I didn't see any issues with that, even when running at 5fps.

Alright, thanks.

WhiteThunder

Have your players complained about this issue since making those code changes?

I've also released Backpacks v3.5.0 which should fix this issue.

After i initiated the fix to the code changes like 3 weeks ago, i haven't gotten any further reports.
So i'll consider it resolved.

Haven't however updated to v3.5.0 yet. Will do when i get home later.