InventoryTweaks duplication bug (Heads up to server owners)

[nzminecraftDOTcom]

Modpack Information

• Current Pack Version: 1.4.5

• [x ] I am running FoolCraft via Curse/Twitch Launcher
• [x] I can reproduce this issue consistently
  • [ ] In single player
  • [x ] In multiplayer
• [x ] I have searched for this issue previously and it was either (1) not previously reported, or (2) previously fixed and I'm having the same problem.
• [ ] I am crashing and can provide my crash report(s)
• [ ] I have not altered the modpack [if you have, note the removed mods/added mods/changes in Additional Information]

Issue Description

Reproduce Steps

Requires a server running additional mods that have display-type inventories e.g Cratekeys or an inventory viewer etc for letting other players view inventories of other players.

Using the "Take all" key shortcut, brings items into your inventory and lets you keep them, while restoring them into the inventory viewed. See https://github.com/Inventory-Tweaks/inventory-tweaks/issues/552

A simple fix for this, remove the inventorytweaks.jar mod file from the server mods folder

Additional Information

[nzminecraftDOTcom]

https://github.com/Inventory-Tweaks/inventory-tweaks/issues/552

[Brycey92]

This issue was previously reported by me, but I'm not sure whether we can call "removing the mod from the server" a fix or just a stopgap measure, since the mod operates better with the server-side copy installed.

[nzminecraftDOTcom]

I'd have thought it wouldn't matter if it wasn't server side, as it's for the players inventory on their end. It hasn't really got any features that the server-side could use, the config file is not configurable for a server, turning off the shortcuts in it's config file still allowed them to be used.

[Brycey92]

The server-side version allows better sorting and other functionality, since without it, the client-side mod has to simulate all the clicks that would normally be involved. In some situations, this can result in missed clicks as packets are lost or not listened to. On extremely rare occasions, a server-side anti-spam mod or plugin could cause users to be kicked for clicking too quickly.

[Mrbysco]

If you're using SpongeForge the issue isn't valid as we are not responsible for Spongeforge breaking mods.

Especially as you're adding additional bukkit mods which ofc are not gonna work properly with forge mods.

[nzminecraftDOTcom]

Well considering they aren't bukkit mods i have no idea where that one came from All of the customisation and protection mods require sponge I thought it a good idea to give people here a heads up who run fc3 servers who may be looking in on the same problem.

[Mrbysco]

Hmmm ok then. But still Sponge isn't really supported

[nzminecraftDOTcom]

Well aware it's not supported however I'm aware that people use it on fc3 servers, the main idea for this issue is to save them time looking for an answer

[Brycey92]

This issue being here is basically just for a heads-up and a way to log that it exists with FC3 if used in this way with SpongeForge, not a ticket that needs fixing by the pack devs. The real place this issue needs fixing is on the aforementioned InvTweaks issue. If/when that's fixed by the dev of the mod, this issue can be closed here with no action from pack devs except updating the mod in the pack.

[Mrbysco]

is it InvTweaks fault for a user using SpongeForge? When SpongeForge is known to break mods? For InvTweaks to fix it would probably require writing workarounds JUST for sponge.

[Brycey92]

I believe that since InvTweaks is one of the most widely used mods in modpacks, yes, it's their responsibility to make sure this dupe doesn't happen, because people are undoubtedly going to be using it on SpongeForge, and it's going to wreak havoc on their servers. Nothing exists in a vacuum, and that includes Minecraft mods. You can't pretend SF doesn't exist any more than you can pretend that throwing the latest version of every mod together will produce a working pack free of issues. As much as we'd like this to be the case, and as little as we want to support things which may not be directly our faults, such is unfortunately the way things work. Both you and I will have to go through our packs of other people's mods and fix issues we didn't create, in order to give our users a good experience they'll enjoy and want to repeat, and the same goes for extremely popular mods. Now, if the dev chooses to simply detect SF and completely disable the mod server-side, that would be their choice and their way of communicating that they don't truly support SF. It would be a minimal amount of effort (probably wrapping all the event-called functions in a check to see if the SF mod is loaded), but effective in carrying out their responsibility to make sure their mod is a boon servers rather than a plague. The dev could also choose to go the extra mile and fix the issue at the source, allowing the mod to be run server-side with SF, and I'm sure that all the users of the mod would be delighted, but that's their choice, and certainly not their responsibility.

As an aside, this bug hasn't been tested with mod-based "read-only" inventories, since it's only been recently discovered and such inventories are rarer from mods than from plugins. This issue may very well be with all read-only inventories, in which case it couldn't be the fault of SF. Until we figure that out, though, my previous argument stands .