-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pull up Canary methods as far as possible. #71
Comments
Would this work without plugins needing a recompile? If so that's pretty awesome. WWOL |
I'd need to check that, but I believe it would. |
Sounds awesome. WWOL |
I take it this is like how addPotionEffect was for Player instead of LivingEntity, despite it working just fine? |
Couldn't everything we currently have in Mob be in LivingEntity? |
Nope, setTarget for example, casts entity to OEntityCreature. |
So the constructor for Mob should really take OEntityCreature, not OEntityLiving, correct? |
Technically, it should, yeah. LivingEntity and Mob overlap, in that aspect. |
I would love getLocation() to be pulled up to BaseEntity. Pitch/Rot could be null for things that don't have such values? |
@14mRh4X0r OEntityGhast is not an instance of OEntityCreature. |
The only change that would affect plugins is that getItemInHand has been renamed to getItemStackInHand to be compatible with Player.java. Oh and none of this is tested.
I know, that's why I said they overlap. setTarget doesn't work for ghasts, either. |
I'll be doing that, h4X. I'm keeping pretty up-to-date on the dev builds. |
Plugins involving Mob.getItemInHand() have broken, as the method has changed to getItemStackInHand() |
This was expected. It was necessary for compatibility with the method in On Dec 3, 2012, at 10:41 AM, BluXDragon [email protected] wrote: Plugins involving Mob.getItemInHand() have broken, as the method has — |
Yup, I thought of all that, but I figure I'll mention every issue on this I find. |
That should be the only incompatibility... Unless someone used reflection On Dec 3, 2012, at 2:59 PM, BluXDragon [email protected] wrote: Yup, I thought of all that, but I figure I'll mention every issue on this I — |
Currently there are many methods in our classes that can be pulled up into superclasses. This would allow for more freedom for plugin developers while maintaining compatibility.
The text was updated successfully, but these errors were encountered: