Scaling the player leaves inconsistent state

[nihal111]

With #2511 that enables change in Height and eyeHeight. There are a few bugs and extras that need to be dealt with:

• Increase/decrease jump speed according to size. Giants should be able to jump higher and dwarfs lower.
• Increase/decrease runFactor
• Adjust interaction range
• gaze mount point is computed from height
• Increase/decrease step height

With the events introduced by #3907 it now becomes possible for modules to react on the OnScaleEvent(oldValue, newValue). Modules that are affected by this or could make good use of it are:

• Health: Increase/Decrease damage from fall. (30m giant should not die of a 15m fall). Define function/proportionality constant same as above.
• Potions: Should use a AffectHeightComponent instead of affecting the PlayerConfig settings. These should override the Default (config) values and should be serialized to the world save.

Further follow-ups:

• Remove player setting to adjust eye level is it is computed from the player height
• Decide on whether we want to keep the player height setting as it has an influence on the game play. Imho we should remove it (still keep the command to change the height) and let (game play) modules decide whether the player can change their character's height.
• Height too small, makes you fall through blocks. (The command only allows for values down to 0.5 for this reason). This is likely realted to changing the height but not the radius in CharacterMovementComponent
• play-test the adjustment functions and iterate until they feel "right"

From a more technical point of view, these components are related to height/scale and should be updated on scaling the character:

• CharacterMovement
• GazeMountPoint
• Health
• several rendering-related components, e.g., rendering the item held in hand (both first person and for other players)
• the player model in multiplayer (adjust floating cube size)
• potentially shapes and bounding boxes
• potentially "physical stats" defined by modules

[Cervator]

Throwing a bunch of assorted labels on this since it has multiple sub-items, and assigning @nihal111 to indicate work may be going on. It may be possible for additional contributors to work some of the items. Just be sure to coordinate if anybody else is interested as well :-)

[TheFlash98]

Hey, I'd like to contribute to this issue @nihal111 😄

[nihal111]

@TheFlash98 the crouch feature is buggy (not multiplayer ready) at this point. That needs to be changed first.
#2961 has some discussion.
Maybe you could start with that. But that would require you to learn how character prediction and other things work in multiplayer mode.

[TheFlash98]

Any help on where I could learn that?

[EaguaireSama]

This seems to be an old issue ,can I work on this?

[Cervator]

Hi @EaguaireSama - sure! Although just earlier today a user named Prince on Discord showed interest in it as well, unless that's just you under another name? In any case there are probably enough items here for several users, and some of them may take some digging first. Some items are fairly straight forward, others less so, may be ideal to discuss on chat and sort of (re)learn the current state of the relevant codebase together as parts are getting kind of dusty. I would also say some of our desires to refactor movement would tie into this.

Just be sure to dig around in the linked issues / PRs, maybe review and comment on #3644 specifically so we could see about merging that and continuing the items here on top :)

If you're here in part for Google Code-In we can also turn parts of issues into tasks if that would be handy. Just let us know on Discord 👍

[skaldarnar]

I think this issue should stay open until we have a proper event-based approach for it (made a comment in that direction in #3841 ).