[1.7.10][IMPOSSIBLE] Converting EntityPlayer to EntityMultiPart

[Ernio]

This is more of a debate.

 

Considering that EntityPlayer is probably everywhere in code, how hard would it be to convert it to MutiPart object (you know - like dragon)?

And by that I mean - player's body has 2 legs, 2 arms, torso and head.

 

Obviously new renderer would be needed, but how about implementing whole part-build.

 

Reason:

http://d24w6bsrhbeh9d.cloudfront.net/photo/adNbrdZ_460sa.gif

 

But seriously, thats would be awesome to have critical hits formed not by random but by players accuracy.

Next step is ofc converting armour system, but that is quite easy if you ask me.

 

Anyone would like to work on this maybe? As some separate mod-API.

 

 

Idea I:

If editing EntityPlayer itself is ridiculus (which it is) I was thinking - maybe to leave it be, cancel players renderer, set collision box to -> 0 and then using events spawn 6 body parts around this EntityPlayer "dot" in world that would move and act based on what this EntityPlayer does (we have motion, rotation, literally everything). Applying damage would be quite like normal Entity (body parts are EntityLivingBase) that would transfer damage to EntityPlayer they belong to with some changes (like head = x2 dmg).

 

The question is - can something go wrong here? I have bad experience when it comes to coordinate glitching (like jumping/lagged entities) and i am worried that this might cause my MultiPart to fall apart

[TheGreyGhost]

Hi

 

I'd suggest that you do a two-step collision process

1) Have a cuboid collision box exactly like the normal entity, that encloses the entire entity parts

2) When the entity is hit, do a more detailed check on each body part to see if any / which one is hit. 

 

One thing though; Minecraft isn't designed for this kind of multiplayer FPS, no lag compensation or motion prediction etc, so you might be disappointed with the results when your target is moving around because  it will often look like a crit when there isn't one, and vica versa, due to the game and network lag.

 

-TGG

[jabelar]

I'd go with your idea that the player would actually have a collection of body part entities around it.  But I would render the player normally and just have invisible entities for the additional collision boxes.

 

However, besides the issue of lag that both you and TheGreyGhost mentioned, the collision boxes for entities in Minecraft don't rotate with the models and in fact the collision box is always aligned with the x, y, z axes, so I'm not sure how satisfactory the result would be.  I mean you might have a swinging arm, but what collision box would you really put for that? 

 

I feel the combination of lag plus imprecise alignment of collision boxes with rendered body parts would make it seem a lot less precise, and possibly frustrating, which is sort of the opposite of what you want (i.e. critical hits being a precise thing).

 

I think it works for the dragon because it is so big that the issues of imprecision and lag are sort of lessened.

[Ernio]

Two-step collision process and 6 entityies connected to EntityPlayer seemed to be good idea until I logged in with 2 players on dev. server.

Done this:

Making entity act exacly as other entity (e.g EntityPlayerHand follow hand rotation of EntityPlayer) not only looks bad, but is totally buggy.

 

So this "idea" is closed until MC devs. rewrite most of game engine.

 

P.S.: I was trying use easing functions that would move all 6 body parts. MC is just not designed for this.