Added backwards compatibility for 1.2.5 to 1.8 #5
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
basically, all the v1_7_R3 imports were taken out of VirtualPlayers.class dynamically registering the proper listeners + executors based on the Minecraft version has NOT been added yet.
Will be replaced with the backward compatible classes.
Tested against craftbukkit 1.2.5 to 1.7.9
All v1_X_RY imports and the corresponding code was moved out of the
VirtualPlayers JavaPlugin class.
Most methods were moved into
mc.alk.virtualplayers.nms.v1_X_RY.VirtualPlayer.java
The listener methods were moved into
mc.alk.virtualplayers.nms.v1_X_RY.PlayerListener.java
API methods implemented:
setEventMessages(boolean enable);
setPlayerMessages(boolean show);
onDisable() functionality:
mc.alk.virtualplayers.nms.{version}.VirtualPlayer.deleteVirtualPlayers();
Finally, some classes still need to be refactored out of the nms packages
and converted into version independent classes.
Added backwards compatibility.
Tested against craftbukkit 1.2.5 to 1.7.9
All v1_X_RY imports and the corresponding code was moved out of the
VirtualPlayers JavaPlugin class.
Most methods were moved into
mc.alk.virtualplayers.nms.v1_X_RY.VirtualPlayer.java
The listener methods were moved into
mc.alk.virtualplayers.nms.v1_X_RY.PlayerListener.java
API methods implemented:
setEventMessages(boolean enable);
setPlayerMessages(boolean show);
onDisable() functionality:
mc.alk.virtualplayers.nms.{version}.VirtualPlayer.deleteVirtualPlayers();
Finally, some classes still need to be refactored out of the nms packages
and converted into version independent classes.
Conflicts:
VirtualPlayers/pom.xml
VirtualPlayers/src/java/mc/alk/virtualPlayer/Executors/CustomCommandExecutor.java
VirtualPlayers/src/java/mc/alk/virtualPlayer/Executors/PlayerExecutor.java
VirtualPlayers/src/java/mc/alk/virtualPlayer/Executors/VPBaseExecutor.java
VirtualPlayers/src/java/mc/alk/virtualPlayer/Executors/VPExecutor.java
VirtualPlayers/src/java/mc/alk/virtualPlayer/Util/Util.java
VirtualPlayers/src/java/mc/alk/virtualPlayer/VirtualPlayers.java
VirtualPlayers/src/java/mc/alk/virtualplayers/nms/v1_7_R3/CustomCommandExecutor.java
VirtualPlayers/src/java/mc/alk/virtualplayers/nms/v1_7_R3/PlayerExecutor.java
VirtualPlayers/src/java/mc/alk/virtualplayers/nms/v1_7_R3/Util.java
VirtualPlayers/src/java/mc/alk/virtualplayers/nms/v1_7_R3/VPBaseExecutor.java
VirtualPlayers/src/java/mc/alk/virtualplayers/nms/v1_7_R3/VPExecutor.java
modules/v1_4_5/src/main/java/mc/alk/virtualplayers/nms/v1_4_5/Util.java
modules/v1_4_5/src/main/java/mc/alk/virtualplayers/nms/v1_4_5/VPBaseExecutor.java
modules/v1_4_5/src/main/java/mc/alk/virtualplayers/nms/v1_4_5/VPExecutor.java
modules/v1_7_R2/src/main/java/mc/alk/virtualplayers/nms/v1_7_R2/PlayerExecutor.java
modules/vpre/src/main/java/mc/alk/virtualplayers/nms/vpre/CustomCommandExecutor.java
Originally, I created a new branch to play around with changes... Then later, I decided to make a new repository to make changes. Went back to original repo and I accidentally commited the changes to branch '175' instead of the master branch. Tried to merge the two branches, but didn't work out.
Tested against craftbukkit 1.2.5 to 1.7.9
All v1_X_RY imports and the corresponding code was moved out of the
VirtualPlayers JavaPlugin class.
Most methods were moved into
mc.alk.virtualplayers.nms.v1_X_RY.VirtualPlayer.java
The listener methods were moved into
mc.alk.virtualplayers.nms.v1_X_RY.PlayerListener.java
API methods implemented and tested:
setEventMessages(boolean enable);
setPlayerMessages(boolean show);
onDisable() functionality:
mc.alk.virtualplayers.nms.{version}.VirtualPlayer.deleteVirtualPlayers();
Finally, some classes still need to be refactored out of the nms packages
and converted into version independent classes.
VirtualPlayers v1.5.10 refactored mc.alk.virtualplayers.Util to lowercase Added util/Version.java Plugin now automatically disables itself for unsupported versions of Minecraft: So that it doesn't spam the console/logs with errors. Admins are alerted of the problem.
Author
|
I see why Github recommends using a different branch now... I was trying to create a new Pull Request for the recent commit I made that adds support for v1_7_R4, but I see it's already in the old pull request. Alkarin, if you have any questions about the changes, just lemme know. |
Eclipse does not like changing the Maven target directory to ../../target So the target was changed to the default: ./target Consequently, the ant task that copies the target/JAR to the /server/plugins folder was updated to reflect the new directory locations.
Author
|
I use Netbeans... but I finally got the time to test the build process in Eclipse. I changed a couple lines in modules/VirtualPlayers/pom.xml to make Eclipse happy. |
Todo: Add a method() to change the regular expression that splits the version string into its parts. The default behavior is to split the version up by periods and dashes.
The VirtualPlayers plugin class was also effected by this change. Renamed factory methods .getPlugin(String) and .getPlugin(Plugin) to .getVersion(String) and .getVersion(Plugin) Added: private Version(Version) constructor public Version(Server) constructor .getServerVersion() factory .getNmsVersion() factory .setSeparator() .getPlugin() returns a Plugin. Added: Several methods were added to support weird versioning systems that broke compatibility checking: int length() boolean equals(String) - this method ignores case boolean contains(String) boolean search(String regex) Version getSubVersion(String regex) - factory private Version setVersion(String) The getSubVersion() method returns a completely new Version object (if a match is found) and uses the private method .setVersion() to change it. Primarily used if you're checking for Dev versions, etc.
Version NMS; to String NMS; To-Do: Fix BlockPlaceEvent() works in v1.5.3 breaks in v1.5.6
Europia79
changed the title
The Ant script now copies the JAR the correct directory: ~/projects/server/plugins/VirtualPlayers.jar This is a Test Server that is shared by all projects.
./dc <vp> bpe <block> <location> Fixed the BlockPlaceEvent command. This cmd works in v1.5.3 But it breaks in v1.5.6 Fixed in v1.5.10
Author
|
Alkarin, i fixed the blockPlaceEvent() command in this last commit 4f8b493 |
also, the implementation for mc.alk.virtualplayers.nms.v1_7_R4.VirtualPlayer:getOnlinePlayers() has changed because Bukkit.getOnlinePlayers() no longer returns an array.
The package structure has changed to a more standarized syntax/notation of all lowercase, and the project name. The new package structure also contains versioned packages. old: mc.alk.virtualPlayer; new: mc.alk.virtualplayers; Any static method calls made to mc.alk.virtualPlayer.VirtualPlayers:* is forwarded to the new class at mc.alk.virtualplayers.VirtualPlayers:* Originally, when I made the change, I didn't realize that other plugins were hooking into the VirtualPlayers code base. I noticed that mc.alk.arena.util.ServerUtil is making such calls. Not sure if anyone else is hooking into VirtualPlayers. But this mapping of the old class to the new class will allow plugins to use newer versions of VirtualPlayers without breaking and without recompiling.
These methods were originally moved to
mc.alk.virtualplayers.nms.{version}.VirtualPlayer
because they contained version dependent code.
The methods were re-added because mc.alk.arena.util.ServerUtil uses them.
These new methods simply use reflection to call the correct VirtualPlayer
class depending on what Minecraft version the server is running:
mc.alk.virtualplayers.nms.{version}.VirtualPlayer.class
This was not tested, but it should work. A unit test was written for the
invoke(String methodName, Object param) method.
The test simply ensures that the correct type of the Object param can be
obtained by the JVM.
Also, some of these methods contained references to
{version}.VirtualPlayer.
All VirtualPlayer types were changed to Object.
Ultimately, references should be made via some kind of VirtualPlayer
interace. But the problem is that getHeatlh() returns an int for older
Minecraft versions. And getHealth() returns float/double for newer
Minecraft versions.
All these static methods were so difficult to test because it requires a
lot of other objects to be present (like a running server) that I just
copied the code over and verified the output.
public static void invoker(String methodName, Object... params)
Basically, the test just checks that the type of Object params can be
deduced at runtime. This type is used and passed to the reflection API in
order to invoke() methodName from
mc.alk.virtualplayers.nms.{version}.VirtualPlayer.class
invoke() only calls static methods.
All of this reflection and forwarding of calls was never tested, so please
report any bugs by opening a New Issue ticket. Thanks!
Bug fix:
Padding with zeros fixes a rare bug where the server is running (for
example) a plugin with version "1.2.0", and you ask isCompatible("1.2").
In this situation, the compatibility check would fail eventho is
shouldn't.
I thought of this because BombArena version 1.2.0 is about to be released.
Got Permission from DSH105 to use some of his ideas from:
com.dsh105.commodus.Version;
The article that I read on Comparator/Comparable said to return one,
negative one, and zero... But I really like how DSH105 simply returns the
difference: very elegent.
compareTo():
Also, someone in IRC told me that I should compareTo() other Version
objects instead of String objects. Initially, I didn't understand the
use-case-scenario, but then I figured out that it could be used for
sorting. Eventho, I'll probably never use this particular functionality, I
changed it... just in case anyone else wants to use it, (or even me in the
future).
Technically, I don't think the Version object should know about Plugins or
Bukkit Servers, but it is a little convenient for isCompatible() and
isSupported() to check for me if a plugin is even enabled.
So I might change this in the future... along with the factory methods...
Those should probably be in their own class, where the Version object
knows nothing about Plugins or Servers, but the VersionFactory does know
about them and how to use them to conveniently construct a Version object
for the user.
Finally, I have several of these Version.class files in different projects
that need to be moved to it's own util project. That way, I can declare a
dependency on this and other utility classes, and any changes will
propagate to other projects. It's on my To-Do List.
battleplugins-repo is down. moved everything to the rainbowcraft-repo
The battleplugins-repo server went down so I moved everything to the rainbowcraft-repo. The ssh wagon has the connector that allows deployments to be made to the repo. Instructions here: http://maven.apache.org/guides/mini/guide-encryption.html Basically, just use maven commands to make an encrypted master password: mvn --encrypt-master-password $> ********* Put this encrypted password into ~/.m2/settings-security.xml <settingsSecurity> <master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master> </settingsSecurity> Then do mvn --encrypt-password $> ******* Put it into your settings.xml on your computer. There's 3 of them: - one on the remote server reposity (not on your computer) - a global one inside the maven installation directory /conf/ folder - a per user one inside HOME/.m2/settings.xml Put your encrypted password and username into your settings.xml : <settings> <servers> <server> <id>rainbowcraft-repo</id> <username>root</username> <password>{COQLCE6DU6GtcS5P=}</password> </server> </servers> </settings> And now, distributionManagement and the ssh wagon will use the information contained in your settings.xml to connect to the server and deploy your build to the rainbowcraft-repo
BattleBukkitLib abstracts away the implementations details for
DamageUtil.damage() which uses an interface handler behind the scenes.
These are the details that need to be hidden: (because they're version
dependent):
EntityPlayer ep = ((CraftPlayer) damagee).getHandle();
ep.damageEntity(DamageSource.GENERIC, (float) damage);
which uses
import org.bukkit.craftbukkit.{version}.entity.CraftPlayer;
import net.minecraft.server.{version}.EntityPlayer;
import net.minecraft.server.{version}.DamageSource;
DamageUtil.damage() is used in PlayerExecutor for the "hit" cmd.
Using DamageUtil makes PlayerExecutor version independent.
Added:
- CustomCommandExecutor.java
- PlayerExecutor.java
- VPBaseExecutor.java
- VPExecutor.java
- VirtualPlayerListener.java
Previously, these were located in the nms.{version} packages/modules.
By design, it was necessary to have these classes duplicated per module
because they contained version dependent code.
The problem with having them duplicated in each module is that it was
tedious to make changes, or make additions because each module would have
to be modified & updated. But with the introduction of the VirtualPlayer
interface, they have now been made version independent.
Now, any changes or additions to these classes will be propagated to each
version of Minecraft... As long as there is an implementation module that
implements the VirtualPlayer interface and the VirtualPlayerFactory
abstraction.
This is a temporary, intermediate version just before the release of v2.0 which will contain backwards-incompatible changes. v1.6.6 adds the VirtualPlayer interface while hopefully maintaing backwards compatibility. This commit also contains a method generateErrorOnPurose() which is a self reminder, in the form of a compile-time error that cannot be ignored: The reminder is to fix VirtualPlayers.getOnlinePlayers() First, the implementation details must change. Right now, the problem is that it uses Bukkit.getOnlinePlayers() which returns a Collection<Player>: This cannot be used on older versions of Minecraft. So it breaks backwards compatibility. Planned for v1.6.7 Next, the return value should probably changed from an array of Player[] to a Collection<Player>. Planned for v2.0
- replaces mc.euro:Version dependency, because BattleBukkitLib includes it - adds BukkitInterface.getOnlinePlayers()
Added modules: - v1_2_5 - v1_3_2 - v1_4_2 - fixed VirtualPlayers.getOnlinePlayers() to be backwards compatible: This is achieved using the BukkitInterface from BattleBukkitLib.
- Changed the start-up logic that determines if the server is compatible with VirtualPlayers or not. - Added rainbowcraft-repo - Removed SNAPSHOT designation so that local repositories would not get over-written by the remote rainbowcraft-repo
in order to NOT over-write someone's local repository
- adds support for Minecraft 1.9
We don't want to over-write someone's local maven repository here, so we're using craftbukkit 1.9-R0.1 instead of the proper version which is 1.9-R0.1-SNAPSHOT
- for Minecraft 1.9.4
- Added modules/v1_10_R1 implementation
- not tested - CraftVirtualPlayer.java line 167 added net.minecraft.server.V1_11_R1.EnumMoveType
- CraftVirtualPlayer.java line 167 added net.minecraft.server.v1_11_R1.EnumMoveType
- several methods in CraftVirtualPlayer are NOT implemented. - untested
- not tested - several methods in CraftVirtualPlayer are NOT implemented
replaced outdated link to ci server with maven repo
- updated & stream-lined POMs. - New, fully separated VirtualPlayersAPI v1.0. - Added debugging utilities for chunk entities. - Removed SNAPSHOT designation for Bukkit & Craftbukkit. Next update: - modules/v1_13_R1 - modules/v1_13_R2 - Also, the next update will exactly match all Bukkit & Craftbukkit versions which will change the interfaces & hopefully fix the JVM chiral-diamond bug.
Added: - modules/v1_13_R1 - modules/v1_13_R2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
VirtualPlayers version 1.5.9