[1.10.2] Change Player model and hitbox for different stances

[Guest]

I am recreating the FPS Tom Clancy's Rainbow Six Siege as a Minecraft mod. In this game you can stand upright, sneak or go prone. This means that I need to make the player's head be much lower while sneaking (in vanilla MC the head is not really lower than while standing up) and I need to kind of rotate the player hitbox when the player goes prone. While the player is prone, his legs need to go in front of him if he moves backwards and behind him if he goes forward. I also need to make it impossible for the player to look straight up and down but rather with a certain angle and if the player's feet are behind him while he is prone, he should only be able to look upward at a very small angle. My question now is: Is this doable without ASM (I have absolutely no knowledge of that stuff) and which compatibility problems would this have (although I don't really care about compatibility because I don't expect this mod to be used with other mods as it features a complete arena setup including automatic match management and effectively turns MC into a shooter)? If it is not doable without ASM, does someone have enough knowledge of PlayerAPI and RenderPlayerAPI to explain me how to achieve this kind of stuff?

[Ernio]

Okay, well - look: What you described is just an idea, now as to designing it to work properly - I can tell you that aside from rotating hitbox (I haven't checked that one so idk), everything you need it pretty much doable with just Forge.

 

As far as RenderPlayerAPI goes - I am absolutely sure that there is noone who will help you there more than SmartMoving's source (but to understand it you will need to spend some time on in-depth reading/understanding source).

 

Note: As mentioned - Forge allows you to edit entity's data, hitboxes and rendering. RenderPlayerAPI is just an API - it is literally layer over what forge might be able to do and provides more compatibility (not functionality). If you want to go for simple - go with Forge. If you want to somehow get along with other RenderPlayerAPI mods - use that.

 

Now to actual things:

1. Minecraft threads (sides), COMPLETE understanding.

2. Forge events (usage).

3. Rendering and client events, partialTicks, client-only classes.

4. Rendering with GL and models + whole vanilla Render.class system.

5. @Capability (storing player states).

6. SimpleNetworkWrapper (network designs)

7. Network-related events (tracking, dynamic syncing).

8. Understanding hitboxes AABB and OBB if you want (idk if they are possible to implement without ASM, there was a thread about it).

9. Some other stuff such as NBT (saving data) and overall vanilla/forge systems + pretty advanced math (rotating and doing stuff like animation properly).

 

Do tell me - how much do you think you are prepared (considering mentioned above required knowledge)?

 

What do you know nothing about? What you are not sure you know enough?

[Guest]

[*]I have the complete understanding of the difference and separation of the server and client thread.

[*]I know how to create an event handler and manipulate the game with it.

[*]I know what partialTicks are, I know the usage of some client events but never worked with most of them, especially those that I might need for this project. In terms of rendering, I have experience with the model system and can do some crazy stuff with it, I already worked with TESRs and animations (the old way) in TESRs, with entity renderers I still have problems, they don't really work for me.

[*]I know how to work with normal models (used in a TESR) but I have little knowledge over the extra functionality a ModelBiped has. I have a basic knowledge of GL but refreshing this wouldn't be bad at all . I would have to take another look at the render.class system to tell you if I understand it or not.

[*]I know how capabilities work and I am already using them in this mod on an item and the player.

[*]I know how to do networking with thread safety although I am always pretty lazy in terms of cheat safety. Refreshing that would also not be bad.

[*]I don't know what you mean with that.

[*]I have some knowledge of AABBs, I am using them for the hitbix of a block in another mod but it gets highlighted even though I am looking at a part if the block where no hitbox is (don't know if this is directly connected to AABBs) but I do not know what OBBs are.

[*]I am working excessively with NBT already. If you mean the animation and rotation of parts of a ModelBiped, I never worked with that functionality but I know how to rotate parts of those models but I am missing the knowledge as to how to make good animation that don't stutter. As for the vanilla and forge systems, it depends what you mean with that.

 

Thank you that you already gave me such an in depth answer.

[Guest]

Ernio?

[Guest]

Getting an answer would be really helpful.

[jabelar]

Regarding hitbox, the main hitbox of an entity always has a square base -- at least that was a limitation up until 1.8 when I last tried changing the hitbox. Also, it doesn't rotate but is always square to the world. This is a problem for most interestingly-shaped mobs, since it means there will either be parts of the entity which won't count as a hit, or there will be parts outside the entity which will count as a hit. I believe this limitation is in place to help with path-finding as it would it would cause performance to slow down a lot if Minecraft had to find paths for irregular, rotated hitboxes.

 

So most mods that want more irregular or precise hitboxes tend to make a "multi-part" entity. Basically you can add additional hitboxes by creating invisible entities that follow around the associated entity (in your case the player). If those hitboxes get hit, then you call the same actions as if the main entity got hit.  Look at the ender dragon code to understand what I mean if it is still unclear.

[Guest]

That makes sense to me. Would it be possible to just add fake entities for the legs, the arms, the body and the head and shrink the player hitbox a bit so that a raytrace won't hit the player's hitbox? Damaging the player is not a problem because I have a custom health system in place to support certain actions from the game I am recreating with this mod.

[jabelar]

Yes, you can add fake entities for all those parts and adjust. Just beware that the hitboxes are still each limited to being square in X, Z, and they can't be rotated. So you wont get a perfect match to your actual model which might be rectangular and rotated. But it should still be much better. And it is important to remember that this is Minecraft after all -- so it isn't a game about precise headshots really. So don't have too high of expectations for making a fully accurate first person shooter.

[Guest]

I am aware that rotation of hitboxes is not possible. Can I manipulate the size of the player's own hitbox in the entity constructing event?

[jabelar]

Yes, the hitbox is publicly accessible and I'm pretty sure it is changeable dynamically -- for example I think this happens when an age-able entity grows bigger.

[Guest]

Ok, thanks. To get those additional entities to work, I would just create an Entity and mount it onto the player, right? How can I make sure, that the head entity is really at the player's head level?

[jabelar]

You'll need to use math to keep the positions arranged properly. So let's say that the master entity has hit box that is positions where the main body (torso) is. Then depending on how you're crouching and rotated you would move the other hitbox entities into the right places.

 

Note that for debugging it is very useful to use the F3+B hotkey combo which will display all the entity bounding boxes on the screen.

 

But anyway, you'll have to do some trigonometry. Have fun!

[Guest]

That sounds doable, I think I'll have a lot of fun with that. F3 + B is useful for that, indeed.