Living has unimplementable methods

[N0odlez]

When trying to implement ArmorStand I came across a issue that may also affect other entities down the line.
In minecraft EntityArmorStand extends EntityLivingBase where as in Sponge it extends EntityLiving. By having this you get methods that cannot possibly be implemented (https://imgur.com/phk3r1x).
Leashes cannot be used on ArmorStands, nor can it pickup items and nor does it need to be persistent.

One way around this would be to add an extra level in the interfaces between Entity and Living, effectively what minecraft has EntityLivingBase. This would also solve other issues that I have had to work around.

Input would be greaty appreciated.

[Kobata]

EntityLivingBase = Living, EntityLiving = Agent

[N0odlez]

Can I say Agent is hideous for the name :P but if that is so then isLeashed, setLeashed, getCanPickupItems, setCanPickupItems, isPersistent and setPersistent need to be moved from Living to Agent.

[gabizou]

I can see why picking up items can be moved to Agent, however the persistence is something we've discussed in IRC. Forcing persistence to remain in Living instead of Agent means we can force not just "AI-enabled" entities, but all living entities to become persistent or not. It's much more valuable to developers to decide whether any Living entity can be persisted or not vs any Agent that specifically conforms to Minecraft's AI enabled entities.

Of course, @bloodmc and I went back and forth between it for a while whether to force persistence for all Entities or just Living entities.

[Kobata]

@gabizou AI-enabled entities are the only ones for which 'persistence' in that sense is variable -- all other entities are always persistent

[N0odlez]

@gabizou @Kobata I can confirm this aswell.

[maxov]

Only commenting because @AzureusNation wants input(I don't mean this in a bad way though, I just have other stuff to work on 😄):

When AI eventually comes, it should be good enough that in any foreseeable use case a plugin developer will want to use Agent. Persistence, in this case, refers to mobs that have a name tag on them if I understand correctly. Therefore, entities that cannot have name tags put on them(Living but not Agent) simply don't have these persistence methods defined, so implementing them would require changing vanilla behavior.

[gabizou]

@gratimax right about the persistence requiring to change some vanilla behavior, but that's what I'm referring to in an IRC convo some of us had, specifically when I was determining whether to house Entity or Living with persistence.

@Kobata I can see many reasons why we wouldn't want other entities to persist (all those arrows shot by players that can't be picked up, never getting removed from the world etc.).

[N0odlez]

@gabizou The fact of the matter is, its all well thinking that this might work but when it comes to implementation it's got to work. If this is to stay how do you suggest that we change the vanilla behaviour. Bare in mind how the clients are going to react to this aswell.

[ryantheleach]

If it were up to me I would strip these out into separate interfaces.

ILeashable, IPersistent, IPickupable

[Mumfrey]

IPickupable

Or maybe ICollectable/ICollector lol, IPickupable just sounds kind of hilarious :)

[N0odlez]

@ryantheleach these dont even need to be seperated, just moved from Living to Agent as what ive done in my pr.

[ryantheleach]

I feel calling this persistence is doing the users of the API a dis-service. Persistence seems to imply whether they will be saved in the world as opposed to whether they can despawn.

Reading the minecraft wiki, it implies that the only entities that can either be persistent or not are monsters, (including angry wolves)

Seems more of a property of a hostile mob then that of a general entity.

[nightpool]

I agree with separating these out in to separate interfaces. Putting them
under Agent is just weird IMO.

On Sun Jan 11 2015 at 6:30:10 PM Ryan Leach notifications@github.com
wrote:

I feel calling this persistence is doing the users of the API a great
dis-service as well persistence seems to imply whether they will be saved
in the world as opposed to whether they can despawn.

—
Reply to this email directly or view it on GitHub
#382 (comment)
.