[INACTIVE][DEV] BukkitContrib Alpha 0.1.7 [1000]

Exact, I'll try.

Edition: Solved, thanks!

No, I expect this is more likely because WorldEdit is doing something with funny Obfuscated code. I just got back from work and have not had a chance to look since my first post this morning.

Edit:

It seems OpenInv may be the problem. @fourgotten what plugins are you using?

I'm pretty sure I know what the issue is already, and it's a negative interaction between something open Inv and BukkitContrib, not the out of sync issue. The out of sync issue is due to bad code in your custom NSH. I'll beat the dead horse, but my NSH is the only custom one that works the way you want flawlessly. You guys could just bundle BC in your Heroes download, I know LogBlock does that.

Update:

I can actually reproduce the OpenInv problem without BukkitContrib at all.

So the issue persists despite BukkitContrib is there or not? or am I lost.. hah

The issues we're having are with BC, I haven't even bothered to revamp ours and integrate ours back in.

I'm going along the basis that you claim yours to be the best and such so if yours cant handle the task we wan't it for then ours won't... These are your words though not ours.

Btw you seem to of combined two replies into one... or misread some posts. As you're mentioning LogBlock/OpenInv along with Heroes...

I didnt know there was an Issue with OpenInv - it doesn't matter to me at this point - I just want a working inventory restriction system - but I'm getting mixed responses. In order for Heroes to be 'complete' it MUST have these restrictions - otherwise its only half complete.

Yes, I managed to reproduce it. OpenInv is replacing the players inventory with a custom one. For a reason currently unknown to me, the custom inventory is not accurately reporting the inventory contents.

It's no claim - there simply aren't any out there. When/If you get yours to work, then there will be 2. It's a fact, not a claim.

Ok maybe best if we start from the beginning and keep it seperate from other talk...

I'm trying to implement BukkitContrib into Heroes to give us Inventory Hooks. I am monitoring the onInventoryClick event and I am Cancelling/Not Allowing the click to happen if they are trying to equip a piece of armor or weapon they cant use.

When this happens the server knows this and acts accordingly however the client isn't informed of this behaviour and still thinks they have the item equipped so the inventories become out of sync. This is on servers with just Heroes and BukkitContrib, no other plugins present that touch the inventory or the events.

perhaps we need more testing on both sides to see if the issues persist or not.

OMFG, LOL, I never tested that half of the code. It will currently allow you to cancel removing an item from a slot, but not from placing an item into a slot. It's a simple fix. (Already have it fixed on my machine...) I'll have BukkitContrib 0.0.3 up tonight!


Switching Subjects:

@lishid

I have discovered the cause of the clash between OpenInv & BukkitContrib. BukkitContrib caches the bukkit inventory wrapper to save memory, but when you replaced the inventory on the entityplayer, the cache becomes out of date. I've added checks to ensure the cache is up to date with each .getInventory() call on players, and it should fix the problem. So really, neither party is to blame, just an unfortunate combination of code. It will also be fixed in 0.0.3

Glad to hear, looking forward to the update so Kainzo can finally rest and have his Inv hooks .

Honestly - If I dont get inventory restrictions soon - I'll kill everyone around me with tweezers

Likewise. Just double checking that my small change did not blow anything else up with it.

Your sister first, right?

jk.

Edit: ha, it didn't break anything. Thank you for being persistent @Rigby90 - I often do not get the point unless you bash it into my skull.

Edit2: @Rigby90 - you can test my fix here: http://dl.dropbox.com/u/49805/BukkitContrib_Test.jar

Let me know if it still doesn't work.

I'll provide the noose and or hammer!

I can't pick up any item at all within inventory anymore, as soon as I click it it changes it to another space in the inventory. This is with Heroes enabled and BukkitContrib on its own.

Just out of curiosity... I hope that 'welcome message' is toggleable and can be turned off by admins.

Really? I'm using it fine - my inventory acts normally. With just BukkitContrib does it work? What events are you cancelling in heroes?

Yeah - I'm hoping to find a less intrusive way around that. I agree, it is not ideal. I'm developing a BukkitContrib SP mod, with extra packets. I need a way to tell the SP mod that the Server is using BukkitContrib and can receive the new packets (sending unsupported packets kicks the player), and so right now, I'm intercepting that login chat message. The login message does not appear if you are using the BukkitContrib SP mod. But I want to look at other packets, and see if I can take advantage of one of them instead of using the chat packet.

Can we have an option to disable the onJoin message? I'd rather have the login msg for MOTD updates as they can get pretty hefty.\

heh - I just now saw that it was addressed.

Ok first of all... Ignore that error... Turns out the client mod I installed a few hours ago decided it wanted to play silly buggers after I updated BukkitContrib. Will get straight to testing it properly.

If you just want the intro message there to tell the Client version of the Mod it is enabled then send a combination of color codes, these dont show up on the client but can be detected by your client side mod.

WorldEdit etc use this to communicate with their clientside mods, same as FlyHack mods use this for servers to turn off Flying.

TYVM, genius idea. I was thinking of changing the text white, but I was unsure how effective that would be.

Ok good news, looks like with that Client Mod out the Window it works perfectly and the client is informed of the restriction. We'll chuck this on the Heroes test server and see if it keeps up.

During one of the /reload's the following stack trace popped up, not sure if it is of any value to you.

http://pastie.org/private/gcsmen39tgiso4eqjyiwq

Ok came across something.

My character has a DIAMOND_CHESTPLATE equipped... he can wear it fine. He cannot wear a LEATHER_CHESTPLATE. When I go to replace the DIAMOND with the LEATHER I get told I can't use the armor which is correct... However the LEATHER_CHESTPLATE is then lost into oblivion as the mouse clears its item and the DIAMOND_CHESTPLATE stays equipped.

The part which is the problem is losing the LEATHER_CHESTPLATE everything else works fine. Not sure if this is intentional or not, if it is we can resolve it within Heroes by creating a new item and attaching it to ther Cursor.

Thanks! That'll be convenient for me...

Yeah, I need to unregister my new packets. Thanks for reminding me.

The cursor should not be lost (I attempt to save the cursor), but I have noticed instances where it get's lost despite that not being possible from my end. I expect Notch's client packets are to blame. So if you want to ensure that the cursor it correct, set the cursor slot.

Progress! Lovely

Ok got more on the issue...

When placing an item into an empty slot then cancelling it... the item is reattached to your cursor. However when placing an item in a slot which already contains an item (so replacing the item in slot with the one in hand) the item in hand is lost upon cancelling the event.

Also using the method of assigning the item back to the cursor is causing duplication of items for some reason. So the only real solution I can think of is to try to fix the issue as to why it is lost in the first place.

@Afforess - sleep is for the weak!

Well, I do correctly initialize both stacks after the event:

Code:

        //clicked on bottom player inventory
        if (!(this.player.activeContainer instanceof ContainerPlayer) && this.player.defaultContainer instanceof ContainerPlayer && packet.b >= inventory.getSize()) {
            int activeSlot = packet.b - inventory.getSize() + 9;
            if (activeSlot > this.getPlayer().getInventory().getSize()) {
                activeSlot -= this.getPlayer().getInventory().getSize();
            }
            type = getInventorySlotType(activeSlot);
            event = new InventoryPlayerClickEvent(this.getPlayer(), this.getPlayer().getInventory(), type, slot, cursor, activeSlot, activeLocation);
        }
        else {
            event = new InventoryClickEvent(this.getPlayer(), inventory, type, slot, cursor, packet.b, activeLocation);
        }

        if (event != null) {
             Bukkit.getServer().getPluginManager().callEvent(event);
             result = event.getResult();
             cursor = ContribCraftItemStack.getContribCraftItemStack(event.getCursor());
             slot = ContribCraftItemStack.getContribCraftItemStack(event.getItem());
        }

        //initialize setup
        ItemStack itemstack = slot != null ? slot.getHandle() : null;
        ItemStack cursorstack = cursor != null ? cursor.getHandle() : null;

The //initialize setup part creates MC item stacks based on the items set in the event.

Anyway, when I first wrote the BukkitContrib code, I had like 15 lines of debug text for each window click, so I knew the slot, item, packet info, etc, and there were times were the packets were simply missed. I think the client pre-processing can just assume that if a player clicks an item into a slot (and the client allows it) that it should happen - and if it happens quickly enough (same tick), the cursor item is lost (the first packet is not sent with the valid cursor, the newer packet takes over, with the cursor empty after the first 'succcessful' packet) and so the server is not told about it. At least, something like that. Because I know the server is not being sent all the info in about 2% cases (the lost cursor only happened to me when I rapidly tried to place an item when it blocked me)

If your cursor is being lost more than 2 times in 100, then something else is amiss. I only have 1 loose cannon idea, and I'll post an alpha 2 here for you to test. I need sleep. Sorry @Kainzo .

http://dl.dropbox.com/u/49805/BukkitContrib_test2.jar

Also, to tantalize others, what to expect in future BukkitContrib releases:

BukkitContrib 0.0.3
-Fully functional Inventory Hooks
-Fix for inventory cache bug experienced with InvOpen

BukkitContrib 0.0.4
Chunk/Block state cache view (see Bukkit pull request for general idea) for concurrent thread processing
Keyboard Events/Keyboard Manager
Custom Skin Manager (per Player & global)
Custom Name for players/entities (per Player & global)
Fix for various MC SP

BukkitContrib will be launching an optional client mod that will provide plugin developers even more events and a broader API to improve the player experience. I'd like to get as many players using it, since the more players, the better the experience. I also want to make it more than just my personal project, so I will encourage pull requests for both the SMP and SP client mod. The SP client mod will not negatively interact with servers w/o the BukkitContrib plugin. In the long term, I'd like to add custom packet management for other plugins & a way for clients to download new items/entities to from servers, but that will be post Alpha. I want to add new features incrementally, and be sure they all work before focusing on others.