SteamWar/ProtocolLib
Archiviert
13
0
Fork 0
Code Issues Pull-Requests Releases Wiki Aktivität

CGlib must be in the compile scope, otherwise it's not included.

Quellcode durchsuchen 
In addition, updated the README with information about Maven.
Dieser Commit ist enthalten in:
Kristian S. Stangeland 2012-10-12 00:24:15 +02:00
Ursprung 28fc096740
Commit 8e70a56768
3 geänderte Dateien mit 141 neuen und 134 gelöschten Zeilen
Statistiken anzeigen Patch-Datei herunterladen Vergleichs-Datei herunterladen Alle Dateien ausklappen Alle Dateien einklappen

4
ProtocolLib/dependency-reduced-pom.xml
Datei anzeigen

@ -10,7 +10,7 @@
<groupId>com.comphenix.protocol</groupId> <groupId>com.comphenix.protocol</groupId>
<artifactId>ProtocolLib</artifactId> <artifactId>ProtocolLib</artifactId>
<name>ProtocolLib</name> <name>ProtocolLib</name>
<version>1.3.1</version> <version>1.3.2</version>
<description>Provides read/write access to the Minecraft protocol.</description> <description>Provides read/write access to the Minecraft protocol.</description>
<url>http://dev.bukkit.org/server-mods/protocollib/</url> <url>http://dev.bukkit.org/server-mods/protocollib/</url>
<developers> <developers>
@ -138,7 +138,7 @@
<groupId>org.bukkit</groupId> <groupId>org.bukkit</groupId>
<artifactId>craftbukkit</artifactId> <artifactId>craftbukkit</artifactId>
<version>1.3.2-R1.0</version> <version>1.3.2-R1.0</version>
<scope>compile</scope> <scope>provided</scope>
</dependency> </dependency>
<dependency> <dependency>
<groupId>junit</groupId> <groupId>junit</groupId>

1
ProtocolLib/pom.xml
Datei anzeigen

@ -165,7 +165,6 @@
<groupId>cglib</groupId> <groupId>cglib</groupId>
<artifactId>cglib-nodep</artifactId> <artifactId>cglib-nodep</artifactId>
<version>2.2.2</version> <version>2.2.2</version>
<scope>provided</scope>
</dependency> </dependency>
<dependency> <dependency>
<groupId>org.bukkit</groupId> <groupId>org.bukkit</groupId>

270
Readme.md
Datei anzeigen

@ -1,131 +1,139 @@
ProtocolLib ProtocolLib
=========== ===========
Certain tasks are impossible to perform with the standard Bukkit API, and may require Certain tasks are impossible to perform with the standard Bukkit API, and may require
working with and even modify Minecraft directly. A common technique is to modify incoming working with and even modify Minecraft directly. A common technique is to modify incoming
and outgoing [packets](http://www.wiki.vg/Protocol), or inject custom packets into the and outgoing [packets](http://www.wiki.vg/Protocol), or inject custom packets into the
stream. This is quite cumbersome to do, however, and most implementations will break stream. This is quite cumbersome to do, however, and most implementations will break
as soon as a new version of Minecraft has been released, mostly due to obfuscation. as soon as a new version of Minecraft has been released, mostly due to obfuscation.
Critically, different plugins that use this approach may _hook_ into the same classes, Critically, different plugins that use this approach may _hook_ into the same classes,
with unpredictable outcomes. More than often this causes plugins to crash, but it may also with unpredictable outcomes. More than often this causes plugins to crash, but it may also
lead to more subtle bugs. lead to more subtle bugs.
### Resources ### Resources
* [JavaDoc](http://aadnk.github.com/ProtocolLib/Javadoc/) * [JavaDoc](http://aadnk.github.com/ProtocolLib/Javadoc/)
A new API Building
--------- --------
You can compile this project yourself by using the latest version of Maven.
__ProtocolLib__ attempts to solve this problem by providing a event API, much like Bukkit,
that allow plugins to monitor, modify or cancel packets sent and received. But more importantly,
the API also hides all the gritty, obfuscated classes with a simple index based read/write system. A new API
You no longer have to reference CraftBukkit! ---------
__ProtocolLib__ attempts to solve this problem by providing a event API, much like Bukkit,
### Using ProtocolLib that allow plugins to monitor, modify or cancel packets sent and received. But more importantly,
the API also hides all the gritty, obfuscated classes with a simple index based read/write system.
To use the library, first add ProtocolLib.jar to your Java build path. Then, add ProtocolLib You no longer have to reference CraftBukkit!
as a dependency (or soft-dependency, if you can live without it) to your plugin.yml file:
depends: [ProtocolLib] ### Using ProtocolLib
Then get a reference to ProtocolManager in onLoad() and you're good to go. To use the library, first add ProtocolLib.jar to your Java build path. Then, add ProtocolLib
as a dependency (or soft-dependency, if you can live without it) to your plugin.yml file:
private ProtocolManager protocolManager;
depends: [ProtocolLib]
public void onLoad() {
protocolManager = ProtocolLibrary.getProtocolManager(); Future versions will be available in a public Maven repository, possibly on Maven central. But it
} will always be possible to reference ProtocolLib manually.
To listen for packets sent by the server to a client, add a server-side listener: Then get a reference to ProtocolManager in onLoad() and you're good to go.
// Disable all sound effects private ProtocolManager protocolManager;
protocolManager.addPacketListener(
new PacketAdapter(this, ConnectionSide.SERVER_SIDE, ListenerPriority.NORMAL, 0x3E) { public void onLoad() {
@Override protocolManager = ProtocolLibrary.getProtocolManager();
public void onPacketSending(PacketEvent event) { }
// Item packets
switch (event.getPacketID()) { To listen for packets sent by the server to a client, add a server-side listener:
case 0x3E: // Sound effect
event.setCancelled(true); // Disable all sound effects
break; protocolManager.addPacketListener(
} new PacketAdapter(this, ConnectionSide.SERVER_SIDE, ListenerPriority.NORMAL, 0x3E) {
} @Override
}); public void onPacketSending(PacketEvent event) {
// Item packets
switch (event.getPacketID()) {
It's also possible to read and modify the content of these packets. For instance, you can create a global case 0x3E: // Sound effect
censor by listening for Packet3Chat events: event.setCancelled(true);
break;
// Censor }
protocolManager.addPacketListener( }
new PacketAdapter(this, ConnectionSide.CLIENT_SIDE, ListenerPriority.NORMAL, 0x03) { });
@Override
public void onPacketReceiving(PacketEvent event) {
if (event.getPacketID() == 0x03) { It's also possible to read and modify the content of these packets. For instance, you can create a global
try { censor by listening for Packet3Chat events:
PacketContainer packet = event.getPacket();
String message = packet.getSpecificModifier(String.class).read(0); // Censor
protocolManager.addPacketListener(
if (message.contains("shit") || message.contains("damn")) { new PacketAdapter(this, ConnectionSide.CLIENT_SIDE, ListenerPriority.NORMAL, 0x03) {
event.setCancelled(true); @Override
event.getPlayer().sendMessage("Bad manners!"); public void onPacketReceiving(PacketEvent event) {
} if (event.getPacketID() == 0x03) {
try {
} catch (FieldAccessException e) { PacketContainer packet = event.getPacket();
getLogger().log(Level.SEVERE, "Couldn't access field.", e); String message = packet.getSpecificModifier(String.class).read(0);
}
} if (message.contains("shit") || message.contains("damn")) {
} event.setCancelled(true);
}); event.getPlayer().sendMessage("Bad manners!");
}
### Sending packets } catch (FieldAccessException e) {
getLogger().log(Level.SEVERE, "Couldn't access field.", e);
Normally, you might have to do something ugly like the following: }
}
Packet60Explosion fakeExplosion = new Packet60Explosion(); }
});
fakeExplosion.a = player.getLocation().getX();
fakeExplosion.b = player.getLocation().getY();
fakeExplosion.c = player.getLocation().getZ(); ### Sending packets
fakeExplosion.d = 3.0F;
fakeExplosion.e = new ArrayList<Object>(); Normally, you might have to do something ugly like the following:
((CraftPlayer) player).getHandle().netServerHandler.sendPacket(fakeExplosion); Packet60Explosion fakeExplosion = new Packet60Explosion();
But with ProtocolLib, you can turn that into something more manageable. Notice that fakeExplosion.a = player.getLocation().getX();
you don't have to create an ArrayList this version: fakeExplosion.b = player.getLocation().getY();
fakeExplosion.c = player.getLocation().getZ();
PacketContainer fakeExplosion = protocolManager.createPacket(60); fakeExplosion.d = 3.0F;
fakeExplosion.e = new ArrayList<Object>();
fakeExplosion.getSpecificModifier(double.class).
write(0, player.getLocation().getX()). ((CraftPlayer) player).getHandle().netServerHandler.sendPacket(fakeExplosion);
write(1, player.getLocation().getY()).
write(2, player.getLocation().getZ()); But with ProtocolLib, you can turn that into something more manageable. Notice that
fakeExplosion.getSpecificModifier(float.class). you don't have to create an ArrayList this version:
write(0, 3.0F);
PacketContainer fakeExplosion = protocolManager.createPacket(60);
protocolManager.sendServerPacket(player, fakeExplosion);
fakeExplosion.getSpecificModifier(double.class).
write(0, player.getLocation().getX()).
Compatiblity write(1, player.getLocation().getY()).
------------ write(2, player.getLocation().getZ());
fakeExplosion.getSpecificModifier(float.class).
One of the main goals of this project was to achive maximum compatibility with craftBukkit. And the end write(0, 3.0F);
result is quite flexible - in tests I successfully ran an unmodified ProtocolLib on CraftBukkit 1.8.0, and
it should be resiliant against future changes. It's likely that I won't have to update ProtocolLib for protocolManager.sendServerPacket(player, fakeExplosion);
anything but bug and performance fixes.
How is this possible? It all comes down to reflection in the end. Essentially, no name is hard coded - Compatiblity
every field, method and class is deduced by looking at field types, package names or parameter ------------
types. It's remarkably consistent across different versions.
One of the main goals of this project was to achieve maximum compatibility with CraftBukkit. And the end
result is quite flexible - in tests I successfully ran an unmodified ProtocolLib on CraftBukkit 1.8.0, and
### Incompatiblity it should be resiliant against future changes. It's likely that I won't have to update ProtocolLib for
anything but bug and performance fixes.
The following plugins (to be expanded) are not compatible with ProtocolLib:
How is this possible? It all comes down to reflection in the end. Essentially, no name is hard coded -
every field, method and class is deduced by looking at field types, package names or parameter
types. It's remarkably consistent across different versions.
### Incompatiblity
The following plugins (to be expanded) are not compatible with ProtocolLib: