Occasional wacky behaviour

SuperLlama88888 commented 1 month ago

This is a collection of all the funky stuff happening with HoloPrint I've observed which, if unpatched, can make using HoloPrint packs an unpleasant experience. I hope that these issues are related and can be easily fixed, but they require further testing.

When testing a large structure that was causing much lag in a normal world, I tried moving it (with a stick) in third person. This worked; however, when switching back to first person, it had moved back to its original position.
When holding a spyglass, bow, or wearing armour, the hologram disappears and the bounding box outline particles are centered on the origin. I think this is for all attachables.
Sometimes the hologram will disappear for a second or two, and I'll get Molang content errors saying that variables are undefined. This does not happen in my testing world (superflat, hardly any entities apart from armour stands).
Sometimes the hologram movement directions are messed up, whereas other times they work completely fine.

I have a few hypotheses:

(1) could be be due to different registries of temp. variables that update each other usually, but in lag may fail to do so. These different registries are supposed to manage different scopes, but are implemented in a flawed manner which also permits global access (magic method). The registries used are dependent on either camera type or render controller (most likely the latter), which explains why changing perspective moved the hologram back to its original position. More testing is required.
- This could also cause (2).
- (3) could be also caused by this; perhaps the abundance of entities causes temp registries to be messed up? Another explanation would be that temp variables are cleared/g, but this would be BAAAD. I have some ideas of how to fix this but hopefully it never comes to that.
Another explanation for (3) is that too many entities limit Molang variable access and hence the armour stand can't retrieve them.
(4) could be caused by the initialize scripts in the armour stand entity file not reading an accurate q.body_y_rotation causing the internal v.hologram_dir to be wrong.

If anyone has any idea that could help solve this, please let me know.

SuperLlama88888 commented 1 month ago

(4) was fixed in 1630c62.

SuperLlama88888 commented 1 month ago

To add on (2), this behaviour occurs when a paper doll is rendered with an attachable (e.g. wearing armour, holding a bow/spyglass). This can either be the regular paper doll in the top-left or the one in the UI. When the paper doll disappears the hologram once again displays. The bounding box particles are unaffected. Here's the content log from showing a paper doll with an attachable after placing an armour stand:

[Molang][error]-particles/bounding_box_outline_0.json | !t.render_hologram | Error: unhandled request for unknown variable 'temp.render_hologram'

(Same error for particles 1-11)

[Molang][error]-minecraft:armor_stand | entity/armor_stand.entity.json | v.last_pose=v.last_pose??v.armor_stand.pose_index;v.armor_stand.pose_index!=v.last_pose?{t.render_hologram?{t.armor_stand_interaction=true;};v.last_pose=v.armor_stand.pose_index;};return t.render_hologram; | Error: unhandled request for unknown variable 'temp.render_hologram'

[Molang][error]-minecraft:armor_stand | entity/armor_stand.entity.json | t.show_wrong_block_overlay | Error: unhandled request for unknown variable 'temp.show_wrong_block_overlay'

[Molang][error]-minecraft:armor_stand | entity/armor_stand.entity.json | t.validate_hologram && t.wrong_blocks == 0 | Error: unhandled request for unknown variable 'temp.validate_hologram'

[Molang][error]-minecraft:armor_stand | C:/Users/.../AppData/Local/Packages/Microsoft.MinecraftWindowsBeta_8wekyb3d8bbwe/LocalState/games/com.mojang/resource_packs/HoloPrints(1)/animation_controllers/armor_stand.hologram.animation_controllers.json | animation_controllers | controller.animation.armor_stand.hologram.layers | states | default | transitions | l_0 | t.hologram_layer > -1 && t.hologram_layer != 41 | Error: unhandled request for unknown variable 'temp.hologram_layer'

[Molang][error]-minecraft:armor_stand | C:/Users/.../AppData/Local/Packages/Microsoft.MinecraftWindowsBeta_8wekyb3d8bbwe/LocalState/games/com.mojang/resource_packs/HoloPrints(1)/animation_controllers/armor_stand.hologram.animation_controllers.json | animation_controllers | controller.animation.armor_stand.hologram.layers | states | default | transitions | l_41 | t.hologram_layer == 41 | Error: unhandled request for unknown variable 'temp.hologram_layer'

[Molang][error]-minecraft:armor_stand | C:/Users/.../AppData/Local/Packages/Microsoft.MinecraftWindowsBeta_8wekyb3d8bbwe/LocalState/games/com.mojang/resource_packs/HoloPrints(1)/animation_controllers/armor_stand.hologram.animation_controllers.json | animation_controllers | controller.animation.armor_stand.hologram.bounding_box | states | default | transitions | hidden | !t.render_hologram | Error: unhandled request for unknown variable 'temp.render_hologram'

[Molang][error]-minecraft:armor_stand | C:/Users/.../AppData/Local/Packages/Microsoft.MinecraftWindowsBeta_8wekyb3d8bbwe/LocalState/games/com.mojang/resource_packs/HoloPrints(1)/animation_controllers/armor_stand.hologram.animation_controllers.json | animation_controllers | controller.animation.armor_stand.hologram.block_validation | states | default | transitions | validate | t.validate_hologram | Error: unhandled request for unknown variable 'temp.validate_hologram'

Moreover, after this happens, using stone to toggle hologram rendering causes more issues. Hiding the hologram works fine, but unhiding it causes the bounding box particles to give the following errors (1-11 are hidden):

[Molang][error]-particles/bounding_box_outline_0.json | v.size=t.structure_w/2;v.dir=0;v.r=1;v.g=0;v.b=0; | Error: unhandled request for unknown variable 'temp.structure_w'

[Molang][error]-particles/bounding_box_outline_0.json | -(v.x ?? (v.dir == 0? v.size : 0)) + 0.5 | Error: unhandled request for unknown variable 'variable.dir'

[Molang][error]-particles/bounding_box_outline_0.json | -(v.y ?? v.dir == 1? v.size : 0) | Error: unhandled request for unknown variable 'variable.dir'

[Molang][error]-particles/bounding_box_outline_0.json | (v.z ?? (v.dir == 2? v.size : 0)) - 0.5 | Error: unhandled request for unknown variable 'variable.dir'

The latter 3 would be caused by the first. Hence, it seems that temp variables aren't accessible sometimes...

SuperLlama88888 commented 1 month ago

The inventory player renderer is a live_player_renderer in the JSON UI. The regular paper doll uses hud_player_renderer. All other player renderers use paper_doll_renderer which doesn't show attachables and hence doesn't cause this issue.

SuperLlama88888 commented 4 weeks ago

When the local player is in third person, everything renders fine regardless of paper doll attachables, except if the world was loaded in in third person, in which it has no effect on this and the bounding box particles are hidden. Other players in the world do not impact anything. q.is_in_ui is true only on the HUD paper doll and inventory paper doll. Furthermore, I've managed to glitch the player into states where interacting with items/blocks changes the hologram for a frame, then reverts back. For now, the best option is to hide the paper doll... if I can't find out how to fix it I'll have to store backup v. variables in the player and then restore t. variables to them when the temp registry is cleared (or whatever's happening)...

SuperLlama88888 commented 4 weeks ago

Other entities in the world wearing attachables (e.g. piglin with crossbow, armour stands themselves) also trigger this issue. Putting "enable_attachables": false in the .entity.json file for armour stands made the attachables hide (as expected) and also removes this interference.

SuperLlama88888 commented 3 weeks ago

It seems like ANY attachables, even ones that don't render at all (and give errors), clear the temp. registry (which I suspect is an entt::basic_storage).

Here's a sample attachable file for bones which demonstrates this clearly:

{
    "format_version": "1.10.0",
    "minecraft:attachable": {
        "description": {
            "identifier": "minecraft:bone",
            "materials": {
                "default": ""
            },
            "textures": {
                "default": ""
            },
            "geometry": {
                "default": ""
            },
            "render_controllers": [
                { "idk": false }
            ]
        }
    }
}

Content errors are thrown for the material not being defined, and for the geometry not being found, but the attachable is still recognised by MC, making bones invisible when held.

SuperLlama88888 commented 3 weeks ago

I think I'll have to make a backup in v. variables which are stored on entities and should never be cleared (according to the docs). Every time we change a t. variable we must update v. as well. Then, if we detect that t. has been cleared, we load in the backup from v..

The problem is that attachables clear t. variables every frame, so IDK how it'll work exactly...

I'm guessing we'd store everything in a struct on the player for persistence.

:(

SuperLlama88888 commented 3 weeks ago

I've tested storing stuff in v. on the player and setting t. to it. v. isn't cleared, so your actions (even when attachables are on frame) are remembered; however, armour stands still seem unable to use this.

I then tested using v. on the armour stands as well. The pre_animation script I used was: (t.var ?? -5) == -5? {t.var = v.var;} : {v.var = t.var;};

This removed all content log Molang errors, and kept the state of the armour stand when attachables were rendered; however, most of the time, they are then unable to update the state if the player does something, until no attachables are being rendered. This is obviously still a huge issue still since it is very common to encounter attachables in everyday gameplay and not having your actions registered by the armour stands would feel very janky.

I only see two possible full solutions now:

Removing all attachable definitions (somehow...)
Disabling attachables on all entities

Neither sound good to me, but I have no clue what else we could do until client-side scripting comes...

SuperLlama88888 commented 2 weeks ago

I believe (1), (2) and (3) are the same bug, which will be "fixed" soon with armour stand-driven controls. Not the best...

SuperLlama88888 / holoprint

Occasional wacky behaviour #1