Solved Importing CraftPlayer and Packet205ClientCommand

I don't know the imports for these. I just need what imports to use because everything I try comes up with "The import org.bukkit.craftbukkit cannot be resolved" when I try to import CraftPlayer, and I get "The import net cannot be resolved" when I try to import Packet205ClientCommand.

My imports.

Code:java

import net.minecraft.server.Packet205ClientCommand;
import org.bukkit.craftbukkit.CraftPlayer;
 

ALL I NEED: The correct imports. I cannot find them for the life of me.

 

Do you have Craftbukkit as a dependency?

 

Incomprehendable Are you using craftbukkit or bukkit as your dependency?

 

Just the Bukkit 1.6.4 R2 API. Do I need to refer to the R2 craftbukkit.jar as well?

 

Incomprehendable No use craftbukkit as a dependency instead of Bukkit. craftbukkit supports NMS and Packets

 

Ah, it works fine. Thanks!

 

You can do this with reflection so you don't need to import those and have to update the plugin every update. Take a look at this and use the third method (the one with a try catch in it).

[EDIT] this is if you're trying to use these 2 imports for auto respawning.

 

Don't. You have to use both.
Incomprehendable
Bukkit is the real, recommended API, if you plan on using NMS and want to update EVERY VERSION, build against both. It is NOT recommended to build against on or the other in this situation, unless you are using reflection...

 

And just as importantly, you need to specify Bukkit as a dependency before CraftBukkit.

But if you really want to do stuff with packets, use ProtocolLib and save yourself a lot of pain.

Using reflection, especially on obfuscated method names, is not very wise (unfortunately it seems to be the favoured approach lately). You're just storing up trouble for yourself for if & when the method name changes in a later CB version. At best you'll get some unexpected NoSuchMethod exceptions or similar. At worst your plugin will appear to work, but could be causing unexpected side-effects up to and including world corruption.

 

desht The reflection used to send packets however (I use tons of reflection specially for sending packets) has not been changed since 1.4.5 I guess? Well now with 1.7 comming out there will be changes again so I will probably add some kind of protocol-mc version detection thingy which disables the plugin when it appears to be outdated. I also know bergerkiller has some kind of system he uses that avoids by checking if all the classes he uses in reflection are there. (Well I guess bergerkiller better explains it himself since I have the feeling I'm being wrong here :s )

 

CaptainBern the method names in any OBC/NMS class could change at any time. Using reflection to access them is a gamble, which so far you haven't lost

It's not simply matter of checking if all the classes are there; there's no way of knowing what a particular method does without inspecting the code and verifying that the method called, say "a", actually does the same thing in CraftBukkit version X and version X+1. That's why reflection is so dangerous - everyone's just back to the situation before the OBC/NMS classes were given versioned package names. Yeah, I know that change infuriated many, but it was done for a good reason.

The correct approach when using OBC/NMS is to write an abstract layer, as mbaxter does here: https://forums.bukkit.org/threads/support-multiple-minecraft-versions-with-abstraction-maven.115810/ or as I do here: https://github.com/desht/dhutils/blob/master/Lib/src/main/java/me/desht/dhutils/nms/NMSHelper.java. Yep, it's (a lot) more work, but has the advantage of being entirely safe.

 

desht True, however the reason that I don't use the abstraction is because I simply use nms related code to send packets. The method to send a packet is simply "sendPacket", I'm not going to use abstraction just for this, if people want a working version for their server then they have to download the right one. However I'm thinking of a system that checks the server version and checks if it's in a list which contains all the versions of minecraf supported for that specific plugin. If this system is ready then my plugin will simply disable upon server start when it's outdated. I always liked the idea of abstraction tho, the only reason I'm not using it is because I do not believe I use enough nms to make my file bigger and bigger each new version of minecraft. (I'm talking about my AnimationLib here). Also one (offtopic) question, I saw you have one of your projects hosted on the genesis-mc jenkins server, but is it down or what?

 

CaptainBern yeah, genesis-mc is gone forever, I'm afraid.

 

You are not simply calling sendPacket, you're also calling methods for acquiring networking objects and constructors on packets, which change. You should not be risking stability just to be lazy and not write a couple extra lines of abstraction. That's negligent behavior.

 

mbaxter It's not being lazy, I really do have time to do those things. Thing is, I already find my animationlib too big, it's around 90 kb now. By adding abstraction it will only grow bigger and bigger which I want to avoid. Like I said I'm also creating a tool to check if the server version is supported, if not > plugin get's disabled. About the changing packet fields (since I never invoke any packet method nor constructor) and the networking classes, yes they do change but that brings us back to the tool I'm working on.

EDIT: Well, almost forgot, I do invoke packet constructors but since every packet contains a dummy/empty constructor this shouldn't be a problem. The biggest risk of break of my lib is in this class: https://github.com/CaptainBern/Anim...rn/animationlib/protocol/PacketType.java#L118, which returns the inthashmap https://github.com/CaptainBern/Anim...rn/animationlib/utils/refs/PacketRef.java#L19. You're right here this is very likely to break.

If I read the conversation again and take a look at how other handled abstraction I'm conviced I should probably use it too, instead I will just release 2 versions of the lib, server owners can choose what they want; portability or safety.

Double Edit: We should probably continue this somewhere else because we're going very off-topic here.

 

desht
Which is why you check and update every release

 

Easy to say. Sure, you as the plugin author will check and update every release and have a new release out as soon as the CB update arrives... except perhaps when personal circumstances intervene. But how many people will still be running older releases of your plugin on the latest CB release? You're not the only one who needs to be doing the checking.

 

Thanks for all of your input, I don't like messing around with packets and you helped me stay in the safe areas. Anyway, this thread is getting off-topic so if a staff member sees this, may you set the title to [SOLVED] and lock the thread?

Thanks again!

 

Yes, writing an abstraction layer is the best way to go. In my case with BKCommonLib, however, there is simply too much of it, and often times features come and go as versions change. I have server version checks for each BKCommonLib version, causing BKCommonLib to only work on the Server software it was built for. v1.50 does NOT work on 1.6.4, it will tell you so and stop enabling further.

If you want to mess around with packets, I recommend you use ProtocolLib for this (no advertisement intended). I use it too in BKCommonLib if it is detected, and it keeps the general system stable. Writing your own 'protocollib' implementation means something like THIS. It is by far not as stable as ProtocolLib and will definitely conflict with others doing the same. I recommend installing ProtocolLib with BKCommonLib precisely because of this.

For external reflection use by other plugins I expose Field instances (well, my own wrapper thereof) so they can access stuff without requiring try-catches and/or error handling. It adds a lot of error reporting and warnings with it so IF something goes wrong, it is instantly detected in the console. This helps secure everything in general.

One issue still is that fields can 'swap'. For example, 'int a' becomes 'int g' and 'int b' becomes 'int a'. Now you get very random, unpredictable behaviour. It forces me to go through the entire changelog after each CraftBukkit version. To make this easier, I keep a separate git repository with all the source code, with commits merged into one commit for each version change. For instance, you can see it here.

 

Incomprehendable You can mark it solved yourself..
Thread settings -> edit thread --> prefix -> solved or something