[3d_armor/wieldview] does not handle "color" meta correctly #4881

New Issue

whosit · 2023-07-02T17:18:05Z

whosit commented

2023-07-02 17:18:05 +00:00

Problem can be seen when using this:
#4878 (comment)
or holding colored waypoint_compass.

The code that should handle color meta is here:
1d8509e75b/wieldview/get_texture.lua (L177)
But turns out it's a dead code, because only strings get passed to this function (and therefore no meta).
Code will be executed if we pass ItemStack here:

diff --git a/wieldview/init.lua b/wieldview/init.lua
index ecdece9..dc9f28a 100644
--- a/wieldview/init.lua
+++ b/wieldview/init.lua
@@ -49,7 +49,7 @@ wieldview.update_wielded_item = function(self, player)
                if self.wielded_item[name] == item then
                        return
                end
-               armor.textures[name].wielditem = self:get_item_texture(item)
+               armor.textures[name].wielditem = self:get_item_texture(stack)
                armor:update_player_visuals(player)
        end
        self.wielded_item[name] = item

But wielded item will still look different from inventory item.
This change can bring back some of the underlying texture color back, but still does not look same:

diff --git a/wieldview/get_texture.lua b/wieldview/get_texture.lua
index ccbd149..e14e570 100644
--- a/wieldview/get_texture.lua
+++ b/wieldview/get_texture.lua
@@ -174,7 +174,7 @@ armor.get_wield_image = memoize(function(item)
        if def.wield_image and def.wield_image ~= "" then
                local parts = {def.wield_image}
                if color then
-                       parts[#parts + 1] = f("[colorize:%s:alpha", escape_texture(color))
+                       parts[#parts + 1] = f("[colorize:%s:180", escape_texture(color))
                end
                if def.wield_overlay then
                        parts[#parts + 1] = def.wield_overlay

I'm not sure if this will break something else, or how it will affect memoization (probably should only pass meta that get_texture can understand). I tested this only on 10 random items I had in my inventory - they looked ok. And compass got color too.

Problem can be seen when using this: https://gitea.your-land.de/your-land/bugtracker/issues/4878#issuecomment-56344 or holding colored `waypoint_compass`. The code that should handle `color` meta is here: https://gitea.your-land.de/your-land/3d_armor/src/commit/1d8509e75b23331072ec1fd9eef82d595d2a0ae7/wieldview/get_texture.lua#L177 But turns out it's a _dead code_, because only strings get passed to this function (and therefore no meta). Code will be executed if we pass ItemStack here: ```diff diff --git a/wieldview/init.lua b/wieldview/init.lua index ecdece9..dc9f28a 100644 --- a/wieldview/init.lua +++ b/wieldview/init.lua @@ -49,7 +49,7 @@ wieldview.update_wielded_item = function(self, player) if self.wielded_item[name] == item then return end - armor.textures[name].wielditem = self:get_item_texture(item) + armor.textures[name].wielditem = self:get_item_texture(stack) armor:update_player_visuals(player) end self.wielded_item[name] = item ``` But wielded item will still look different from inventory item. This change can bring back some of the underlying texture color back, but still does not look same: ```diff diff --git a/wieldview/get_texture.lua b/wieldview/get_texture.lua index ccbd149..e14e570 100644 --- a/wieldview/get_texture.lua +++ b/wieldview/get_texture.lua @@ -174,7 +174,7 @@ armor.get_wield_image = memoize(function(item) if def.wield_image and def.wield_image ~= "" then local parts = {def.wield_image} if color then - parts[#parts + 1] = f("[colorize:%s:alpha", escape_texture(color)) + parts[#parts + 1] = f("[colorize:%s:180", escape_texture(color)) end if def.wield_overlay then parts[#parts + 1] = def.wield_overlay ``` I'm not sure if this will break something else, or how it will affect memoization (probably should only pass meta that `get_texture` can understand). I tested this only on 10 random items I had in my inventory - they looked ok. And compass got color too.

whosit added the

1. kind/bug

3. source/mod upstream

labels 2023-07-02 17:19:52 +00:00

flux commented

2023-07-04 00:45:06 +00:00

right. i bumped my head up against this exact problem when i was trying to optimize (for FPS reasons) smartshop displays (and haven't yet fixed it). the solution is to use a wielditem drawtype.

a version of 3d_armor exists, where instead of the wielded item being part of your player model, it's an entity w/ a wieldview drawtype that's attached to one of your model's bones. this would also allow e.g. displaying stairs if you're holding stairs, or display your giant skeleton hammer:

i'm not sure where the code for that version of 3d armor exists, though, or if it differs in other important ways.

right. i bumped my head up against this exact problem when i was trying to optimize (for FPS reasons) smartshop displays (and haven't yet fixed it). the solution is to use a wielditem drawtype. a version of 3d_armor exists, where instead of the wielded item being part of your player model, it's an entity w/ a wieldview drawtype that's attached to one of your model's bones. this would also allow e.g. displaying stairs if you're holding stairs, or display your giant skeleton hammer: ![image](/attachments/6c18fc5d-e2e8-4dde-94d9-410fa950abc6) i'm not sure where the code for that version of 3d armor exists, though, or if it differs in other important ways.

image.png

70 KiB

flux added the

2. prio/interesting

label 2023-07-04 01:18:04 +00:00

flux added this to the flux's TODO list project 2023-07-04 01:18:21 +00:00

Sign in to join this conversation.