Bukkit

Quick question, when you said in the changelog, "no longer needs protocollib or NMS", would that be considered an improvement or a compromise/workaround? I would think that because of changes in code for 1.6, you'd have to rely on ProtocolLib even more now. (e.g. spawn an entity for the player to sit on, but make the entity invisible via ProtocolLib).

IMO, I'd rather have reliance on ProtocolLib or MC code than having to compromise for a "suckier" solution (like using an arrow), assuming that usage of those will result in a better solution.

I think this is all tied with Mojang "changing" how sitting works in that you no longer right click the entity (be it a pig or a horse or a minecart) to get off, but rather, you have to sneak to get off. This change sounds small and trivial, but it could actually have required quite a bit of change in code: a change that Bukkit would have to adapt to.

As a note for what I'm about to say, I don't know any code and this is all speculation, so please forgive me if I sound stupid. I'm also likely to use incorrect terminology, so bear with me.

I'm not very familiar with 1.6 as I haven't played it much, but during my playthroughs, I was thorough in testing mechanics. One such mechanic I've noticed was that the "rider-ridee relationship" was changed from 1.5. If you ride a horse, you will notice the horse you ride has no hitbox for the entity riding it (in this case, you). It does have a hitbox, however, for entities that aren't its rider, for instance arrows and other mobs. Hence why you can kill the horse you're riding with a bow, but not a sword.

What does this change in relationship mean? Well, the information pertaining to the "rider" status has changed. No longer is Minecraft content with knowing that an entity is in the ride status; it also has to know what the rider is riding upon. At 1.5 and before, a rider and a ridee was two entities and nothing much more than that (they only shared velocity). But 1.6 changes that and has to know what the rider is riding so as to know what two entities to "connect". If it can "connect" these two entities, it can cancel out that hitbox for that relationship only.

In other words, the method of communication (code-wise) between the rider (e.g. the player) and the ridee (e.g. the horse) has changed so as to accomodate accidental dismounts and melee hits; in turn, the "sneak to get off" option was used to accomodate that.

What does this mean for this plugin? From my guess, a "rider stance" needs "ridee information" to make the "connection" because that "connection" is mandatory to make. This means we can blame Mojang for yet another one of our problems.

If nothing I said made sense, I'll try to use "flowcharts" comparing how the "1.5 and before" system worked, and how the "1.6 and after" system works. Again, this is speculation for how it worked. I don't know if this is how it was actually done.

How entering the riding stance works: 1.5 and before system

• Player entity has right-clicked a rideable entity.
• Put player in riding stance.
• Put player on top of entity (which means they'll share the same velocity/position).
• Player entity has right-clicked a rideable entity.
• Is the rideable entity they right-clicked the one they were riding? If yes, dismount.
• Upon player-dismount event, revert player back to a standing position.

Notice how "riding stance" and "actually riding the entity" are disjoint. One does not check for the other (so from this logic, you could also be riding an entity without being in riding stance and vice versa).

How entering the riding stance works: 1.6 and after system

• Player entity has right-clicked a rideable entity.
• Have the player ride the entity.
• Is the player riding the entity? If yes, connect the player and the rideable entity.
• Are the player and rideable entity connected? If yes, have the player go into a riding stance.
• If at anytime, the player-entity is not connected to another rideable entity, have the player revert into a normal stance.

So in this scenario, the riding stance is dependent on whether the player is connected to an entity or not.

14:46:20 [SEVERE] Could not load 'plugins/Chairs.jar' in folder 'plugins'
org.bukkit.plugin.InvalidPluginException java.lang.NoClassDefFoundError net/minecraft/server/v1_5_R3/DataWatcher
    at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:184)
    at org.bukkit.plugin.SimplePluginManager.loadPlugin(SimplePluginManager.java:306)
    at org.bukkit.plugin.SimplePluginManager.loadPlugins(SimplePluginManager.java:230)
    at org.bukkit.craftbukkit.v1_6_R2.CraftServer.loadPlugins(CraftServer.java:243)
    at net.minecraft.server.v1_6_R2.DedicatedServer.init(DedicatedServer.java:117)
    at net.minecraft.server.v1_6_R2.MinecraftServer.run(MinecraftServer.java:397)
    at net.minecraft.server.v1_6_R2.ThreadServerApplication.run(SourceFile:582)
Caused by: java.lang.NoClassDefFoundError net/minecraft/server/v1_5_R3/DataWatcher
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:266)
    at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:173)
    ... 6 more
Caused by: java.lang.ClassNotFoundException net.minecraft.server.v1_5_R3.DataWatcher
    at org.bukkit.plugin.java.PluginClassLoader.findClass0(PluginClassLoader.java:70)
    at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:53)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
    ... 9 more

@cnaude

Yeah.. Make sure you don't allow players to get on a chair whilst sneaking, it causes some players to crash.

@cnaude

Yeah, the new Minecraft code for dismounting is shifting.

That might be why the current code/builds aren't working even after being updated :/

@cnaude

So you're now using an arrow entity to tie folks to seats. Way back when, it was an item drop that tied folks to seats.

@cnaude

I've managed to get CraftBooks chairs working using the old arrow technique. I tried putting a 0x20 metadata on the arrow to make it invisible, but that doesn't work. If you want some reference to assist you in converting to this method heres CraftBooks chair mechanic, https://github.com/sk89q/craftbook/blob/master/src/main/java/com/sk89q/craftbook/mech/Chair.java

If you find another way to do this, can you please let me know? Thanks :)

@cnaude

Would it be possible to make an Entity, have the player sit on it, then remove it? Or would it update the player and have them be standing up? All I know is there has to be a way to do it... And it shouldn't be this complicated.

@cnaude

I tried to take a look... A bit confusing to me.. But.. you could probably do something similar to what @ItsHarry said. Just spawn a falling block and set the player as their passenger. Probably the easiest way to do it now. Really it would be good if it worked better. Now, using NMS rather than ProtocolLib, does that work? Anyway, good luck! Love the plugin!