Skip to content
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

Open
14mRh4X0r opened this issue Nov 23, 2012 · 16 comments
Open

Pull up Canary methods as far as possible. #71

14mRh4X0r opened this issue Nov 23, 2012 · 16 comments

Comments

@14mRh4X0r
Copy link
Member

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.

@WWOL
Copy link
Member

WWOL commented Nov 23, 2012

Would this work without plugins needing a recompile? If so that's pretty awesome.

WWOL

@14mRh4X0r
Copy link
Member Author

I'd need to check that, but I believe it would.

@WWOL
Copy link
Member

WWOL commented Nov 23, 2012

Sounds awesome.

WWOL

@BluXDragon
Copy link

I take it this is like how addPotionEffect was for Player instead of LivingEntity, despite it working just fine?
I'm happy to report things like that when I find/remember them. I've seen quite a few.

@gregcarlin
Copy link
Member

Couldn't everything we currently have in Mob be in LivingEntity?

@14mRh4X0r
Copy link
Member Author

Nope, setTarget for example, casts entity to OEntityCreature.

@gregcarlin
Copy link
Member

So the constructor for Mob should really take OEntityCreature, not OEntityLiving, correct?

@14mRh4X0r
Copy link
Member Author

Technically, it should, yeah. LivingEntity and Mob overlap, in that aspect.

@BluXDragon
Copy link

I would love getLocation() to be pulled up to BaseEntity. Pitch/Rot could be null for things that don't have such values?

@gregcarlin
Copy link
Member

@14mRh4X0r OEntityGhast is not an instance of OEntityCreature.

gregcarlin added a commit that referenced this issue Nov 28, 2012
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.
@14mRh4X0r
Copy link
Member Author

I know, that's why I said they overlap. setTarget doesn't work for ghasts, either.
On another note, testing needs to be done to verify that this doesn't break plugins.

@BluXDragon
Copy link

I'll be doing that, h4X. I'm keeping pretty up-to-date on the dev builds.

@BluXDragon
Copy link

Plugins involving Mob.getItemInHand() have broken, as the method has changed to getItemStackInHand()

@gregcarlin
Copy link
Member

This was expected. It was necessary for compatibility with the method in
Player, and the only plugins it would break would be no more than a couple
weeks old and likely still under active development.

On Dec 3, 2012, at 10:41 AM, BluXDragon [email protected] wrote:

Plugins involving Mob.getItemInHand() have broken, as the method has
changed to getItemStackInHand()


Reply to this email directly or view it on
GitHubhttps://github.com//issues/71#issuecomment-10957890.

@BluXDragon
Copy link

Yup, I thought of all that, but I figure I'll mention every issue on this I find.

@gregcarlin
Copy link
Member

That should be the only incompatibility... Unless someone used reflection
for some reason. So if you find anything else, we don't know about it.

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
find.


Reply to this email directly or view it on
GitHubhttps://github.com//issues/71#issuecomment-10968853.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants