API for handling fake player entities

[Romindous]

Is your feature request related to a problem?

The issue right now, is that there's no acknowledgement in the Spigot or Paper API, of the fact that player entities can be actually created, in NMS (direct server code).

As of now, the only way to create a player entity is to make a new EntityPlayer, either directly or through super() in an extending class. Afterwards, an efficient way to display said entity to other players on the server is to use packets, including ClientboundPlayerInfoUpdatePacket, PacketPlayOutNamedEntitySpawn, PacketPlayOutRelEntity..., and PacketPlayOutEntityEquipment.

However, if you want to make it move, interact with other entities, etc..... This is where the fun begins.... since EntityPlayer does not and cannot have pathfinder goals, as the entity is meant to be controlled by a player.

Describe the solution you'd like.

There are several ways to go about this. First of all, It would be nice if you could World.spawn(Location, EntityHuman.class), which would create said EntityPlayer and return it's CraftBukkit copy.

However, I think it would be worth to think about making a new entity class that implements Mob and HumanEntity. If there would be a way to assign pathfinder goals (as Paper already has an API for that) to this new entity, the fun part of the problem would be solved.

I haven't dug too deep into Craft(Entity) stuff, so im not sure which option would be more viable.

Describe alternatives you've considered.

The alternative I am using right now is pretty interesting. To get a player entity, that "looks to be" moving, have a custom ai, etc, I would:

1. Create a new instance of EntityPlayer, lets call it the "Human" entity.
2. Spawn a second entity (i use a Husk, its pretty comfortable).
3. Set the bot entity's position to the Husk.
4. Assign whatever pathfinder goals you want to the Husk, such as movement, damage, etc.
5. When a player gets into the world, or loads the chunk with the Husk, intercept packets thru io.netty.channel.ChannelPipeline, and stop any outgoing packets from the Husk, such as PacketPlayOutSpawnEntity, PacketPlayOutEntityMetadata, etc.
6. At the same time, send the player the Human entity packets, mentioned in the issue description.
7. Send Entity Move packets whenever the Husk moves, so the Human entity keeps up, and then remove the Human entity, if something happens to the Husk (unloaded, killed, etc)

If you have any questions, pls ask, I can share code or elaborate further if needed!

Other

[yannicklamprecht]

Do you want a fake player that is static only or one that can have pathfinding and mobgoals?

[Romindous]

One that can have mobgoals and such

[XxGoldenbluexX]

That would be awesome

[gepron1x]

Is this really a papermc scope?

[PlayerSchark]

Is this really a papermc scope?

I think it's kinda hard to say. For spigot it would definetly out of scope, but probably not for Paper.

Spawning an NPC with AI isnt as hard as it seems to be. Just two packages, add the Entity to the World, implement a few Controllers and done. You have your mob.

It would make sense, because developers can do all this stuff without NMS. Except the two packets you can do everything with CraftBukkit only. And here is the problem. It is CraftBukkit not an actual API.

Another point is that Human Entities are become more and more important. And by implementing such an API into paper we would give them more stability.

I already have a working POC for this topic so I could make real API within short time and do a PR.

But maybe all of this is just a nice to have, but I don't think so.

I would like to hear the view from paper staff. If they agree I would start such a project.

[electronicboy]

I just have no idea if theres a desire for us to maintain something as internal as this, especially when plugins with libraries already exist which achieve this and much more, and wouldn't rely on us having to maintain what are essentially a hack for a niche number of users

[yannicklamprecht]

Probably a good start #10478 need to address Javadoc and other todos.

[yannicklamprecht]

Addressed theses.

[PlayerSchark]

I wouldn't name it Bot that would be to vage and out of scope. "Human" inherited by HumanEntity makes more sense here.

It can't extend Player. That would be a break with the inheritance.

[Romindous]

True, "Human" seems more fitting, i just based it off my previous applications. But it could have way more. Also it would be nice to address the pathfinding issue, since only non-player "Mob" entity types can pathfind.

[ghost]

If you want packet players we should have packet entities aswell, but imo its out of paper scope.

[PlayerSchark]

I wouldn't use magic packet based ghostlike entities. There are better options to spawn a human. Even out of scope i don't like them. Because you need to do unnecessary sync stuff.

[lynxplay]

Closing this after long long discussions and the nice POC work of yannik, which ultimately did show that maintaining something like this will be too much in upkeep / api development when existing third party projects are already more powerful and have more fleshed out API.