I've been trying to narrow down the exact cause and symptoms of this bug for the last few days or so, so that I can provide more specific information, but unfortunately the bug seems to happen randomly and so I've had trouble deliberately replicating it.

My first experience with the bug was when I was wearing a backpack (gold) that contained a pickaxe and some other miscellaneous loot items that I can't recall exactly. I was out exploring, and pressed my hotkey to open the backpack, and found it empty.

The second time the bug occurred was similar, except it only contained a half-stack of cobble. I checked the backpack frequently while I travelled to try to narrow down what was causing the contents to disappear. Eventually I opened the pack to discover it empty again, but I couldn't identify anything in particular that had happened to cause this. (I hadn't logged off or used any commands, equipped or de-equipped the backpack, or done anything else of note except travel, kill mobs, break plants and pick up items.)

The third time I experienced the bug was a little different. I placed a stack of cobble in the pack, and then added a few tomatoes and bell peppers from Pam's Harvestcraft that I picked up from a garden. Not long after, I filled the pack with some more contents from some loot chests, and some more crop products. I checked on the items a few times over the course of the next ten minutes or so, but eventually, upon checking the pack, I discovered that the cobble, tomatoes and bell peppers were still in the pack, in the same place they were before, but all the other items were gone, as though the pack had reverted itself to a previous point in time.

I'm running the mod alongside quite a few other mods in a custom modpack, on an external server that I host myself.

I'm sorry I don't have any more information, and I know it's possible that this bug is not directly related to this mod, but due to the random and uncommon nature of the bug, my attempts to replicate the bug without any other mods installed have been inconclusive.

Edit: Sorry, I'm an idiot and I didn't tell you that I'm using version 1.2.15 for 1.7.10, on Forge version 1558.

I've been having the same issue and have removed the mod from my pack altogether. Did you ever find a solution?

Hey,

Sorry for the lack of any earlier response, I have been quite busy with classes and have been unable to mod for the last month or so.

This issue is a tricky one, as it is fuzzy and not directly replicatable. I suspected something like this might happen due to less than ideal coding practices, which was why I rewrote the entire mod for 1.8 (a version that, as far as I know, doesn't have this issue). I will try and look through the code to pin it down, but I can't promise I will find it, since the bug will take a lot of time to fix and I want to fix the ones I know I can mend first. However, the issue it causes is definitely one I would love to not have, so if you ever have more information on what exactly causes it, that would be more than welcome.

Also, I guess I should note, that it is possible that the issue isn't totally on my end, the forge mechanisms I am using for saving may not be entirely sound or misused by me (in 1.7), which was why I changed almost all of that in the rewrite for 1.8. If I have to do the same for the 1.7 I'm afraid the issue will likely remain, because I don't have the time nor energy to rewrite the entire saving mechanics for this 1.7 version as well. If it is a smaller fix then I will definitely do so though.

While I don't expect you to get back to 1.7 for any big rewrites, is it possible that you could make the hotkey open a backpack in the inventory, in the event that none is equipped?

That would regain most of the convenience of not needing a hotbar slot.

@Baughn Done! In version 1.2.18, which is already downloadable on CurseForge.

Everyone else, I have heard no mention of this on versions above 1.8, so I am closing this issue, as I unfortunately don't have the time to support multiple versions with a change as big as that which this would require.

I would have sworn this was due to the internal implementation in the code 1.7.10, but this bug has occurred in the rewritten version for 1.10. sighs

I will definitely devote some time and effort to track it down though.
So far we know this:

• It isn't an inter-mod issue, as it has happened with just Iron Backpacks.
• It only affects equipped backpacks.
• It seems to occur randomly (need to narrow that down).
• @TheCorvid In the bug for 1.10 it so happens that the equipped backpack stays on your player even after unequipping, saving and quitting, and reloading the game; it is impossible to change it (obviously that is not tolerable). Was this the case with the bug in 1.7?

Alright, looks like I am narrowing down on the possible cause for this.

@clawdude13 - I added a command so you can unequip that persistent backpack now.
'/ib forceRemoveEquippedBackpack [player]' will put the equipped backpack in your offhand. The player-name parameter is optional, if it is not selected it will target yourself.

@TheCorvid @Solace7 Do you recall if this error occurred with any relation to traveling through the end? Or even dying in general?

Alright, I believe I have fixed the issue, but I cannot be certain as I cannot replicate the error.
Edit: Yeah I just spent the last hour or so trying to replicate this issue to no avail, so I do think it is actually fixed now!

Leaving this issue up for an indeterminate length of time, until either no reports come in (means it is fixed) or new ones do that mean I still have to address the issue.

That looks like a simple fix... maybe!

Could it be ported to 1.7.10, or would that still be too much?

Yeah, I think so. I'll have to look back at my 1.7.10 code, but if it is anywhere as easy to fix (in terms of lines of code) as 1.10, then that should be very much doable.

Edit: Attempted a fix, but I'm slightly less optimistic about this one than the 1.10 version, as this specific section of code did change significantly between versions.

You're right, that does look less obvious. I'll test it once released and let you know if it seems to work, though.

Thank you! The new version just got approved on curseforge.
If you find any trends or patterns that lead to greater reproducibility of the issue I would love to hear them as well.

P.S. I also backported the new textures just for the heck of it. Enjoy!

So far, so good. I'm not willing to pronounce it 'fixed' yet, but I'm stress-testing as much as I can.

Fantastic! Just let me know if you need anything from my end and I will do what I can :)

Nope, sorry. They're not fixed; they still sometimes revert to an earlier version in time if equipped.

I don't quite get how that can happen, to be honest.

Alright, well I do still want to fix this, which means getting a lot of information out of you.

• Minecraft Version
• Iron Backpacks Version
• Does this only happen on a dedicated server (i.e. not singleplayer)?
• What steps were you doing to replicate it?
• What happens after it reverts?
  • Does it work normally after reversion? If it reverts again a second time on the same world, is it the same backpack it reverts to as the 1st time?
• Time frame until reversion? Is it usually a long time (>30 minutes [gameplay time]) or a short time (<10 minutes), or if it is totally random, what is the timespan you have seen?
• Do you notice any trends about the reverted backpack's state? Any contents it may have that could tip you off as to when/why the reversion occurs?
• Are there any actions you take that may have a possibility of inducing reversion?
  • At this point even hunches would help; although exact constraints are ideal, having something to go off is better than nothing.
  • For example, is it world logging in/out, death, dimension travel, lots of unequipping and equipping, etc. ?
  • Essentially any indication of when this happens would help immensely.
• Does anything else in the world revert, or is it just the equipped backpack?

On my end, I will analyze my code and try and see how this could have happened.

If you're curious, here's my train of thought. I store the equipped backpack on two cases.

1. when pressing the hotkey to equip the backpack.
2. when the player dies and they have the eternity upgrade (to have it persist through death).
   My initial assumption was that case 2 was interfering with case 1, as the state of the backpack pre-death could very likely be different than the current state of the equipped backpack. However, I have no idea what action would cause the revert. That was what I tried to change the first time, but I will go back and see what else it could be.

Edit: Here's a thought, if you're willing. I could make a special build, where I disable the persistence through death code, and then give that to you. If we know for sure that the death code either causes an error or is not that cause, that would help immensely in narrowing it down. Let me know what you think of that.

Thanks a lot!

So I can't answer most of these, because I haven't had it happen to myself yet since the upgrade. It's another person on my server who reported the recurrence; I've asked him to try answering your questions. But for what it's worth:

• Minecraft version: 1.7.10, Forge 10.13.4.1566
• Iron Backpacks 1.2.19
• I don't play singleplayer. I've only seen it on a server so far, but...

Old information:

• I've often had it revert several times in a row, but don't recall if it always went back to the exact same state. I can't say for sure that it didn't.
• Short time. Seconds, not minutes.
• Only trend is that maybe the reverted backpack tends to have a smaller NBT state. I don't know for sure.
• Occasionally I found myself reverted to spawn, as if I'd just joined the server, but with my inventory otherwise intact. Very confusing. Sometimes I've also seen first-spawn mod information books pop into my inventory. Without reverting the rest of my playerdata.
• It doesn't revert to a consistent state, in any case. I've had items duped by removing them from my backpack.

If this sounds like a general player-data saving problem of some sort, then you're absolutely right and I have no idea if it's even a bug in your code; it may just be that you're stressing things a bit harder. On the other hand, I haven't observed any of these bugs without wearing a backpack.

Edit: Here's a thought, if you're willing. I could make a special build, where I disable the persistence through death code, and then give that to you. If we know for sure that the death code either causes an error or is not that cause, that would help immensely in narrowing it down. Let me know what you think of that.

I'm perfectly okay with that. I don't think we have anyone using the Eternity upgrade, as we have gravestones enabled... actually, could that cause a conflict?

Anyway, go right ahead.

I've often had it revert several times in a row, but don't recall if it always went back to the exact same state. I can't say for sure that it didn't.

Okay, that's what I expected to hear.

Short time. Seconds, not minutes.

Erm I mean I know it's variable, but how long does it take to reproduce the reversion from a normal working backpack? i.e. new world -> how long until this happens? Or in your case, from the update, how many players do you have, how much do they play, and how long until one of them reported a bug? Just trying to gauge some timeframe for how long until the bug can be reproduced from a new starting state.

Only trend is that maybe the reverted backpack tends to have a smaller NBT state. I don't know for sure.

That makes sense, as a previous state is more likely to simply have less stuff. Doesn't help narrow it down too much though.

Occasionally I found myself reverted to spawn, as if I'd just joined the server, but with my inventory otherwise intact. Very confusing. Sometimes I've also seen first-spawn mod information books pop into my inventory. Without reverting the rest of my playerdata.

That is super interesting. And makes me think it isn't necessarily my mod's fault (although mine might be contributing). Can I get a modlist?

Also, when the books pop into your inventory, that only happens when the backpack resets as well, right? Or are they separate occurrences? Same question for the reversion to spawn.

It doesn't revert to a consistent state, in any case. I've had items duped by removing them from my backpack.

To clarify, the backpack it reverted to is buggy, correct? Does a re-log make different things happen when you have this bugged backpack on? (Thinking it may be a client-server desync issue).

If this sounds like a general player-data saving problem of some sort, then you're absolutely right and I have no idea if it's even a bug in your code; it may just be that you're stressing things a bit harder. On the other hand, I haven't observed any of these bugs without wearing a backpack.

Agreed.

I'm perfectly okay with that. I don't think we have anyone using the Eternity upgrade, as we have gravestones enabled... actually, could that cause a conflict?

It shouldn't, as I tested it with the two before releasing. That being said, I will look into the mod (this one, right?) to see if they do anything funky to save the info before the player dies.

Anyway, go right ahead.

Alright, that will be my next goal, I'll try to get it to you soon so y'all can see if that fixes it, and while that is going on I will do some code analysis in case it doesn't. I am a bit busy this week (the weekend ended, sad times), but you can expect this tweaked version hopefully by tomorrow.

Or in your case, from the update, how many players do you have, how much do they play, and how long until one of them reported a bug?

Ah. It took a couple of hours playtime, and--earlier--no-one reported trouble in the first place until we were well into midgame.

I'd assumed that was due to not having anything complicated in the backpack until then, but Lutillian pointed out that it could also be because of dimension-switching. We've got the TARDIS mod, so there's a lot of that. I'm about to check if that can cause it.

It shouldn't, as I tested it with the two before releasing. That being said, I will look into the mod (this one, right?) to see if they do anything funky to save the info before the player dies.

It's OpenBlocks, actually. I've generally found it far more reliable.

Also, when the books pop into your inventory, that only happens when the backpack resets as well, right? Or are they separate occurrences? Same question for the reversion to spawn.

I've never had it happen without the backpack also resetting to some earlier state.

I actually saved my player data-file from that occurrence. Don't know how much use it might be for you, but here: https://madoka.brage.info/bug-reports/

In that case, the trigger was looking at a ChromatiCraft crystal. There's a parallel bug-report going on over at Reika's place, but it's definitely not caused only by Iron Backpacks, as not all the people affected by his progress-resetting bug were using it. I think the same is also true in reverse.

To clarify, the backpack it reverted to is buggy, correct? Does a re-log make different things happen when you have this bugged backpack on? (Thinking it may be a client-server desync issue).

I'll have to check next time it happens, but it's not a simple desync. Relogging doesn't fix it.

Mod list

Will http://sprunge.us/LTRC do? It's a modified Modular Mayhem pack. If you wanted, you could build it from https://github.com/Erisia/builder.

Ah. It took a couple of hours playtime, and--earlier--no-one reported trouble in the first place until we were well into midgame.

I'd assumed that was due to not having anything complicated in the backpack until then, but Lutillian pointed out that it could also be because of dimension-switching. We've got the TARDIS mod, so there's a lot of that. I'm about to check if that can cause it.

Yeah that is my guess. Either normal dimensions, or the End. Actually, do you know if you encountered these errors before anyone went through the end? (Vanilla has some dumb code to handle coming back from the end, so that could be the source). Or other mods not doing the correct calls when handling dimension transfers. Now that you mention it, this would be a likely cause of errors, I'll look into dimension stuff more.

It's OpenBlocks, actually. I've generally found it far more reliable.

That's fine, as long as it is open source. I did test it with OpenBlocks though as well.

I've never had it happen without the backpack also resetting to some earlier state.

Okay, that's what I thought, but wanted to make sure.

I actually saved my player data-file from that occurrence. Don't know how much use it might be for you, but here: https://madoka.brage.info/bug-reports/

That's super helpful actually! I'll try and analyze it.
/me wistfully wishes it was 1.10 so that looking at the stored data would be 10x easier

In that case, the trigger was looking at a ChromatiCraft crystal. There's a parallel bug-report going on over at Reika's place, but it's definitely not caused only by Iron Backpacks, as not all the people affected by his progress-resetting bug were using it. I think the same is also true in reverse.

I'll go check out the issue tracker for Reika's as well and see if I can learn from that.

I'll have to check next time it happens, but it's not a simple desync. Relogging doesn't fix it.

Sorry, I should have been clearer. Not that a desync fixes it, but what happens when you log out/in? My guess is the data saved on the client side may be different than that stored on the server, causing issues.

Oh, also, can you remove the bugged backpack okay eventually? I assume so, but I know for the 1.10 version I had to add a command to forcefully remove it. I could do the same for the 1.7 version possibly too, if it needed.

(Note to myself: triple check that the logging code syncs data from the server before requesting anything clientside).

Will http://sprunge.us/LTRC do?

That works, thanks.

P.S. Thanks for your dedication and replies, I think with some effort we might track down this slippery issue eventually!

Yeah that is my guess. Either normal dimensions, or the End. Actually, do you know if you encountered these errors before anyone went through the end? (Vanilla has some dumb code to handle coming back from the end, so that could be the source). Or other mods not doing the correct calls when handling dimension transfers. Now that you mention it, this would be a likely cause of errors, I'll look into dimension stuff more.

Well, I still haven't been able to replicate the error since the upgrade at all. Going to the nether didn't do it, going to a tardis didn't do it. Next up, I'll try that while filling my backpack with Lost Books' books.

The players on my server killed the ender dragon the day after this instance started. No help there, I'm afraid, and I still haven't been to the End myself.

I'll go check out the issue tracker for Reika's as well and see if I can learn from that.

Here's the exact bug: ReikaKalseki/Reika_Mods_Issues#1113

Sorry, I should have been clearer. Not that a desync fixes it, but what happens when you log out/in? My guess is the data saved on the client side may be different than that stored on the server, causing issues.

But there shouldn't be any data client-side, surely? Um, let me check... no, reconnecting doesn't trigger it, whether in the overworld or the nether.

Oh, also, can you remove the bugged backpack okay eventually?

Doing so causes an exception and logs me out, but it'll be in my inventory when I log back in. Sorry, didn't save the message.

(Note to myself: triple check that the logging code syncs data from the server before requesting anything clientside).

What if it changes in-between the sync and the request?

Going to the end and back didn't seem to make a difference, though it did dump me back at spawn. But that's normal. Hmm, though... hmm.

Reading that chromaticraft report was super helpful.

I had the idea of saving inventory to a file, but it wasn't very high up on my list; perhaps I should implement it, as it seems that it may just be NBT data corruption with too large of a file.

The players on my server killed the ender dragon the day after this instance started. No help there, I'm afraid, and I still haven't been to the End myself.

That's impressive haha. So most likely not the end, good to know.

But there shouldn't be any data client-side, surely?

No there shouldn't. I was just hoping for some obvious fix , I didn't think about it enough; you are correct.

Doing so causes an exception and logs me out, but it'll be in my inventory when I log back in. Sorry, didn't save the message.

Yes, getting that error message would be very helpful I think.

Aha!

Putting a lot of extra books in the backpack triggered it. At least, I got kicked while attempting to take it off. Here's that error: Internal Exception: io.netty.handler.codec.DecoderException: java.io.IOException: Packet was larger than I expected, found 32856 extra bytes whilst reading packet 47.

Okay awesome, it looks like it is just a simple case of vanilla mechanics not accounting for all that data stored in one place.

I guess my next task is to implement some file I/O saving and then get a build out to you. That might be a bit tricky, so don't expect it immediately xD

Now I can't log back in. Server rollback time. ^^;

ZFS is awesome.

Did that reset the ChromatiCraft data (or Blood Magic LP data or gave you any books or anything else stored in NBT) as well?

It kicked me out and wouldn't let me back in, so this time I can't tell.

Just let me know when you get back in if it reverts your inventory and give you books, because then we would know for sure that it is the cause.

Edit: derp, you are rolling back so we can't tell. Hmm, well I guess we could assume...

No, I mean, it wouldn't let me back in at all. Playerdata totally corrupt. (So I rolled back the filesystem.)

If you wouldn't mind, could you try to partially corrupt it? So not fill it with books, but maybe only halfway and then try it? So it gets corrupted but causes some reset.

"Found 32857 extra bytes", this time. I suspect they're using a 16-bit length field somewhere. Bad mojo; should be a varint.

No luck getting to a partially-broken state.

EDIT: Come to think of it, IIRC I got ChromatiCraft to trigger it by looking at a crystal, with a massive number of books in my backpack, without unequipping it. But server suddenly got busy. I'll try that later.

Okay thanks for trying, it was worth a shot.

Silly other devs not using compact data. I guess I should write up file I/O stuff for this, but in the meantime could you just make sure your players know to watch the size of the items in their bags? (Think it's the same issue as nesting storage drives with AE)

From what I can tell, the root cause is the loss of Forge's death-persistent NBT tag. This is borne out by players also respawning with new handbooks from various mods.

The one on my end at least does not appear to be caused by this; it has happened when the entire player NBT file was only a few KB, much less than the 32KB limit, unless the compression hit 8x or more.

Huh, I'm kind of at a loss then, I really don't know what could be causing it. Possibly an error in Forge (as I don't think this happens in Vanilla)?

Whatever tag this is, it might be affected by the Sync mod as well. I don't know if Sync is opensource, but if so, it might be worth taking a look at.

When I made a shell and synced to it, on the next world load, I still have my Chroma progress and my inventory (which was empty) appears to be fine. But I got a new Tinkers' Construct book.

I can confirm as the original reporter of this bug that I did have Chroma crystals in my backpack at some points while experiencing this bug, but I'm afraid since it was so long ago and I no longer have that server, I don't remember many more details than that.

They have no data on them, so they would do nothing.

I have my mod on a server for testing this sort of thing, I'm playing through myself with it, and I have heard of no more occurrence of this bug.

However, in both of those cases, none of your mods @ReikaKalseki (most notably Chromaticraft) are included in the modpack. While the Chroma crystals themselves do nothing, I can't help but wonder if you are doing some something somewhere in CC that could mess with the data, as the only time I think people have experienced the error is when CC is in the modpack as well.

I would check it out myself by digging through your source code, but I don't have time for that at the moment. So Reika, if you want to investigate that then maybe it will lead to some sort of understanding of this troublesome bug.

CC adds a great deal to the player data.

It's been over a month, and I have had thousands of downloads of my mod in 1.10 and no known occurrences of this bug. Therefore I have to conclude it is an issue on Chormaticraft's side. @ReikaKalseki I wish you the best of luck, and if you port to 1.10 I will reopen and reexamine this issue. For now though, I am closing it.

P.S. Ignore the issue pipeline spam, I'm trying out a new method of organizing issues.

I didn't find a solution to this, no, but I did find a workaround. The bug doesn't seem to happen as long as you don't actually equip the pack. Thanks for looking into it, gr8pefish. Solace7, I know it's been a while now but could you give me details on the pack you were using so that I can maybe narrow it down to a compatibility issue? I'll try playing with only Iron Backpacks installed later, so that I can also rule that out. It'd be helpful if you could give me a list of all the mods you were using, including any custom jars you were using and any plugins. Thanks.

@TheCorvid Was using a gold backpack with the following mods
Modlist