I created this due to a player needing a way to use CraftPlayer on diff versions of Bukkit. How to create a ReflectedCraftPlayer Code: ReflectedCraftPlayer reflectedCraftPlayer = new ReflectedCraftPlayer(Player); But some functions returns objects. Yes, some functions due to it sending some versioned stuff returns an Object like getHandle(). I thought about this and added the ReflectedCraftPlayer#sendPacket(Packet) to the class. How do i send the packet again? Its easy just do something like. Code: ReflectedCraftPlayer reflectedCraftPlayer = new ReflectedCraftPlayer( (Player) commandSender ); Class<?> packetPlayOutChatClass = ReflectionUtil.getNMSClass("PacketPlayOutChat"); Constructor<?> packetPlayOutChatConstructor = ReflectionUtil.getConstructor(packetPlayOutChatClass, ReflectionUtil.ICHAT_BASE_COMPONENT_CLASS); Object IChatBaseComponent_Serializer = ReflectionUtil.invokeMethodReturnObject(ReflectionUtil.ICHAT_BASE_COMPONENT__SERIALIZER_CLASS, null, "a", "{\"text\":\""+ ChatColor.GREEN +"This is a example!\"}"); Object packetPlayOutChat = ReflectionUtil.getObjectFromConstructor(packetPlayOutChatConstructor, IChatBaseComponent_Serializer); reflectedCraftPlayer.sendPacket(packetPlayOutChat); Class: https://github.com/JanSTuck/Utils/b...k/utils/Reflections/ReflectedCraftPlayer.java Dependency: https://github.com/JanSTuck/Utils/blob/master/src/me/jantuck/utils/Reflections/ReflectionUtil.java There we go @Zombie_Striker anything else i can do to reduce line count?
@JanTuck Follow naming conventions! "final Class<?> CraftPlayer_Class" does not. Correct would be "CRAFT_PLAYER_CLASS". "handle.getClass().getField("playerConnection")" Finding the fields and methods is what takes time. Cache these as "private static final" variables "(Boolean)", "(Float)", "(Integer)" You can actually cast to the primitives (e.g. "(boolean)"). Looks a bit nicer IMHO. "// Had some trouble passing the array so just rewrote the method." Care to explain the trouble? "getDisplayName" and many other You do realize there are API methods for that? I do not understand why you try to invoke those using Reflection. It makes no sense. "Entity player" You take an "Entity" as parameter, call it player and think it is of the class "CraftPlayer"? Take a "Player" and store it as such! "this.craftPlayer = player;" What should this do? Why do you store the Player as "Object", if you know it will be of type "Player"? Honestly, 90% of the methods can be done via the API. You can instruct your IDE to create delegate methods, so things like RefletedPlayer#getDisplayName are just passed to the wrapped Player object. I do not know why you would need this though. ReflectionUtil: "getClassName" Does the same as Class#getSimpleName. No need for it at all. "Class" For the love of god, stop dealing with raw types. "getMethod(Class<?> superClass" Why is that parameter called superClass? "Object toInvokeOn" That is generally called "handle" "catch (Exception e) {" You shouldn't catch any exception. Catch what you need only, let the rest bubble up. Why should that method swallow every error there might be? You just take the exception and print it. Rethrowing as a RuntimeException may be nicer. Or provide a mechanism to differentiate a method returning null from a method which returns null. Over on PerceiveCore, I wrote a dedicated ReflectResponse class, taking this job. "classes = getType(parameters);" Nice idea but inherently flawed. What if my method is "public void foo(Integer integer);"? Your code would not find it, as it looks for a method with the parameters "int", not the wrapper class. Your methods give no feedback. They can throw a few hundred NPEs insid (which your catch with "Exception" catches), and the caller will never know if the operation succeeded. DRY. Seriously, DRY. Have a look at these two methods: "invokeMethodReturnObject(Method method, Object toInvokeOn, Object... parameters) {" "invokeMethodReturnObject(Class<?> superClass, Object toInvokeOn, String method, Object... parameters)" What would be a sensible strategy for the second one? Correct, you obtain the "Method" and invoke the other method, already designed to do the job of actually invoking it. What you currently do is writing the same code over and over. "getContructer" That thing is called a "Constructor", as it constructs a class. Probably a typo, still funny "String version = Bukkit.getServer().getClass().getPackage().getName().split("\\.")[3];" Something, something caching as "private static final String" These were the things that I saw after skimming over the code. As always, there are probably more.
What's the point of it if you are still importing nms packages (packet), making it version dependant... ?
You could remove the lines that can be accessed through the Player object, or can be used without needing to import any NMS classes. The next step after this, if you wish to add onto what you currently have, would be to make new methods to send out custom packets. Instead of having to do all the reflection by hand, it would be nice to just to have to input a few variables. Here is a list of all the packets: http://wiki.vg/Protocol These are ones where it would be nice if they had their own methods: http://wiki.vg/Protocol#Block_Break_Animation http://wiki.vg/Protocol#Block_Action http://wiki.vg/Protocol#Block_Change http://wiki.vg/Protocol#Boss_Bar http://wiki.vg/Protocol#Disconnect_.28play.29 http://wiki.vg/Protocol#Explosion http://wiki.vg/Protocol#Unload_Chunk http://wiki.vg/Protocol#Effect http://wiki.vg/Protocol#Particle http://wiki.vg/Protocol#Open_Sign_Editor http://wiki.vg/Protocol#Use_Bed http://wiki.vg/Protocol#Destroy_Entities http://wiki.vg/Protocol#Resource_Pack_Send http://wiki.vg/Protocol#Respawn http://wiki.vg/Protocol#World_Border http://wiki.vg/Protocol#Camera http://wiki.vg/Protocol#Held_Item_Change_.28clientbound.29 http://wiki.vg/Protocol#Player_List_Header_And_Footer http://wiki.vg/Protocol#Spawn_Player
