Multi-Hotbar mod v3.1-T85 allows many CarryOn items to be kept in inventory
MineCrak opened this issue · 27 comments
Expected Behavior
- Inventory selector should be frozen on CarryOn item slot.
- Only one CarryOn item to exist in a player inventory anywhere, and only in the selected slot. Any others should fall out.
Actual Behavior
With Multi-Hotbar v3.1-T85 and earlier it is possible to change toolbars and CarryOn items will remain in the prior bar, allowing new CarryOn items to be picked up in other slots. They can then select them when they want to place them down or put them into a chest, allowing baby mobs etc to be put n chests.
Steps to Reproduce
Using Multi-Hotbar v3.1-T85 and possibly earlier versions (which people on my server are doing because they figured out about this exploit),
then using the (double-tap on a number key) method to change active hotbars.
This bypasses CarryOn's selector freeze.
Version of Minecraft, Carry On, Forge
Minecraft 1.12.2
CarryOn v1.12.2
Forge 2838
Multi-Hotbar v3.1-T85
Screenshots encouraged
Here is a point in a video made by a member of my server which unwittingly shows him picking up several chests then going somewhere else and then placing them all there:
https://youtu.be/x87871aJzwo?t=2196
- I would greatly appreciate some kind of fix for the mc 1.12.2 version please. This is the Official Cubic Chunks server and will be running for possibly years, already gone 1 year so far. Thank you.
Well... I don't really know what I can do here... the selector freezer is a huge hack as it is, and if a mod modifies the hotbar system this drastically I don't know what I can do. I already cancel the number keys, If it doesn't work already I don't think I can cancel the double tap mechanic. Maybe report this to MultiHotbar as well? Try to see if we can get some kind of mod compat going. Adding support for carry on would be way easier on their side than on ours.
The thing is that I already don't have to worry about this happening with later versions of Multi-Hotbar, it's the fact that people can still use an older version of it to do this, and have their own copies of it.
Is there any way for CarryOn to insure that CarryOn "items" will only stay in inventory for so long as they are actively selected, and always drop if they aren't? Otherwise there will always be the potential for various other mods to do this.
The people on my server are telling me that the current v1.12.2 can also be exploited with Tweakaroo as well as by itself with no other mods. One guy has been able to manage to get a CO item out of his main hand without any other mods at all. Here is a video he made of doing it:
https://youtu.be/0trEeUWba78
The good news is that they are telling me that CO v1.12.1 did not allow any of this. That Multi-Hotbar and Tweakaroo and SSP were not able to exploit CO like this, as the item would automatically place instead of remaining in inventory.
So some change between 1.12.1 and 1.12.2 broke CO's protection from such exploitation.
I would revert the server to CO 1.12.1 except for the fact that we'd been waiting for that portal fix in 1.12.2.
Great news!! Looks like the bug that slipped into v1.12.2 has been found. Barteks2x, the dev for the Cubic Chunks mod took a look and found this:
7174a92#diff-a3f8d74f59457139a7846ef458811664R470
Currently "getPortalCooldown" is being used, but "timeUntilPortal" is what should be used.
"getPortalCooldown is the cooldown constant for entity, timeUntilPortal is the actual current cooldown timer".
I tested his test build of v1.12.2 that has that fixed and the original CO anti-exploit behavior is back! MHB is no longer able to jail-break CO items, and carrying through portals still works.
oops. Now the End portal Carrying is back to how it used to be before it was "fixed".
Apparently the End portal situation worked in v1.12.2 because:
"because getPortalCooldown returns the constant number 10
which obviously is never 0"
So something else will have to be done to fix End Portal Carrying if the anti-exploit code is fixed.
So, if an item is being carried in the first slot, far left, when going through an end portal then it gets through ok. But otherwise it disappears.
Carrying through Nether portals works fine though.
It looks like for some reason the slot focus may be moved to the first slot for just a tick or so then reset back to where it was when going through an end portal. Which is long enough to trigger to anti-exploit code and drop the item, which disappears into the ether in this case.
The reason it seemed like the End portal Carrying was completely fixed in v1.12.2 was because the anti-exploit code wasn't working anymore, so it wasn't being triggered.
It just dawned on me. This means that your anti-exploit code has been essentially deactivated in your mc 1.13 and mc 1.14.4 versions too.
Wow, you guys really sunk your time into this! I really appreciate it! Yes, the issue is definitely timing related. You said Barteks2x had a working version?
If he does have working code, would he mind making a pr for this?
Otherwise, since you guya have spent ao much time with it, I can try to get an update out today or tomorrow
Oh of course he will, but first he wants to look deeper into the End situation regarding the return from the End so that it's all fixed.
Yeah, the Cubic Chunks server community loves your mod, we've been using it non-stop for ages now. It's worth it to us all to see this mod working at it's best. :)
And thanks! That would be great. I'll let Barteks2x know.
Barteks2x has found a way to fix Carrying into the End. I've tested it and it works.
There is still strange behavior when returning from the End, instead of bouncing the slot focus to the first slot then back again it just leaves it on the first slot when returning. The item gets placed in world though and not in the ether, at least usually.
- I'll see what he can figure out for that side of the End equation.
Also; Barteks2x has the following explanation for what appears to be happening when entering the End:
And the reason for that one tick slot change: when changing dimension, on the client side, a new player entity is made. That causes the player to send selected slot change packet. The order of events:
server transfers entity to new dimension
server sends packet about changing player dimension
server sends packet with current inventory data to make sure the new client entity has it
client receives change dimension packet
client makes new player entity
client sends "change selected slot to 0" packet
client sends "player update" packet
client receives "inventory data packet" and sets slot to what it was
client sends "change selected slot" packet
server receives "change selected slot to 0" packet
server recieves "update player" packet, and in that runs CarryOn code for inventory check
server receives "change selected slot" that changes it back to what it was
there is also a server tick somewhere in between as the slot remains 0 for a whole server tick, and that is a part I just gave up trying to understand.
probably timing related
Thank you so much! It makes me really happy that you guys are enjoying the mod and that it’s used so frequently on your server!
I will add your suggestions to the default blacklist and release an update today!
Looks like Barteks2x may have found the final End bug:
"The end being handled wrong was a mistake on respawn event handling. Because returning from the ends is internally kind of but not completely killing the player, removing it from all worlds for the duration of the end screen, and then respawning the player from dead and restoring the inventory
The mod had the code to handle it, but had a true instead of false in one place
and yes I will make a PR"
Also; I've found it necessary to Blacklist the following mods in the server's CarryOn cfg Entities and Tile Entities blacklists. I don't know if you'd want to add them to the default blacklist?
architecturecraft:*
blockcraftery:*
dakimakuramod:*
astikorcarts:*
stackable:*
placeableitems:*
https://github.com/Tschipp/CarryOn/pull/203/files
The commit pull request on your fork
It shows much of what can be done with cc and it's addon CubicWorldGen, as well as cc's API.
The world is made up of many "Layers", each using separate Generation settings, within the same world. Providing content both deep underground and above ground. The world is a work in progress and being added to layer by layer.
Here is an invite to the Main Cubic Chunks Discord. I can give/show you more info from there and hook you up with access to the server from there if you want. Plus you will have a Mod Developer Role:
Sorry, I should have said that the Cubic Chunks Mod/Project is a Height Mod, depth too.
The original was made in 2011 and I was there then with it's creator Robinton.
Barteks2x resurrected it into modern CC and is continuing it's development.
The Test Server is just a part of the project.
Your mod happens to be a popular one that works fine with CC at all heights and depths. :)
Thanks! Here is a picture from your friends on the Cubic Chunks Test Server "The Crakked World" using CarryOn up in orbit on an Asteroid, with the y level of 1865 visible:
idk why it's not attaching. So here it is in another way: