[Testserver] Chesttools color button #4202

New Issue

JeCel · 2023-04-15T13:01:27Z

JeCel commented

2023-04-15 13:01:27 +00:00

Just tried the new chests from chesttools. Despite that I don't really like that the whole thing is colored instead of just the wooden part, coloring already existing chests is a bit buggy. Basically, in order to color a chest that was placed before the update, you have to click on the store button and then the color button will appear. But after closing the UI the color button disappears. This does not happen with newly placed chests.
Also, scrolling through the colors like that without seeing the result is a bit annoying (color picker would be better).

Regarding the colors in general: If I understand correctly, instead of changing the texture of the chest when changing colors, an overlay gets created instead, which is why the whole chest appears in a new tint. I suppose it is not so easy to make it that the whole texture gets changed instead, to avoid this overlay look? As far as I can tell there are only 8 colors to choose from anyways, so it wouldn't add that many new node IDs, right?

Just tried the new chests from chesttools. Despite that I don't really like that the whole thing is colored instead of just the wooden part, coloring already existing chests is a bit buggy. Basically, in order to color a chest that was placed before the update, you have to click on the store button and then the color button will appear. But after closing the UI the color button disappears. This does not happen with newly placed chests. Also, scrolling through the colors like that without seeing the result is a bit annoying (color picker would be better). Regarding the colors in general: If I understand correctly, instead of changing the texture of the chest when changing colors, an overlay gets created instead, which is why the whole chest appears in a new tint. I suppose it is not so easy to make it that the whole texture gets changed instead, to avoid this overlay look? As far as I can tell there are only 8 colors to choose from anyways, so it wouldn't add that many new node IDs, right?

Sokomine commented

2023-04-15 13:40:41 +00:00

Despite that I don't really like that the whole thing is colored instead of just the wooden part,

Please provide a better texture that is more suitable in that regard! I'm incapable of creating textures on my own.

Basically, in order to color a chest that was placed before the update, you have to click on the store button and then the color button will appear. But after closing the UI the color button disappears.

Thanks for the feedback. It can't be changed for the first click on such an old chest - because the formspec is stored directly so that the client can know it without having to ask the server. It has to be updated at least once. I ought to store the updated version on save.

Also, scrolling through the colors like that without seeing the result is a bit annoying (color picker would be better).

Hm, indeed. And we need a better texture and perhaps more suitable palette.

I suppose it is not so easy to make it that the whole texture gets changed instead, to avoid this overlay look? As far as I can tell there are only 8 colors to choose from anyways, so it wouldn't add that many new node IDs, right?

The very point is that we get those 8 new colors "for free". They don't cost extra node IDs.

Palette overlay can work very well with the right textures. The textures' colors are multiplied with the color value from the palette.

With 4 nodes (3 new ones), we could even cover 256 colors. Then the chest wouldn't be rotatable by the screwdriver anymore and we'd have a north-, south-, east- and westfacing chest (could be coosen automaticly when placing).

> Despite that I don't really like that the whole thing is colored instead of just the wooden part, Please provide a better texture that is more suitable in that regard! I'm incapable of creating textures on my own. > Basically, in order to color a chest that was placed before the update, you have to click on the store button and then the color button will appear. But after closing the UI the color button disappears. Thanks for the feedback. It can't be changed for the first click on such an old chest - because the formspec is stored directly so that the client can know it without having to ask the server. It has to be updated at least once. I ought to store the updated version on save. > Also, scrolling through the colors like that without seeing the result is a bit annoying (color picker would be better). Hm, indeed. And we need a better texture and perhaps more suitable palette. > I suppose it is not so easy to make it that the whole texture gets changed instead, to avoid this overlay look? As far as I can tell there are only 8 colors to choose from anyways, so it wouldn't add that many new node IDs, right? The very point is that we get those 8 new colors "for free". They don't cost extra node IDs. Palette overlay can work very well with the right textures. The textures' colors are multiplied with the color value from the palette. With 4 nodes (3 new ones), we could even cover 256 colors. Then the chest wouldn't be rotatable by the screwdriver anymore and we'd have a north-, south-, east- and westfacing chest (could be coosen automaticly when placing).

flux commented

2023-04-15 17:00:49 +00:00

the issue w/ the updated formspec not showing up could be fixed w/ a run-once LBM that just updates the formspec.

in order to only color the "wooden" parts of the chest, you could use overlay_tiles

also, given that these are chests and probably never upside down or on their sides, perhaps using paramtype2="color4dir" would make sense? you'd be able to get 64 colors that way. (EDIT: oh, i see you already mentioned this).

@Sokomine if you can't do the graphics work, i can probably create overlay textures by copying the current ones and then making the "wood" parts transparent.

the issue w/ the updated formspec not showing up could be fixed w/ a run-once LBM that just updates the formspec. in order to only color the "wooden" parts of the chest, you could use [overlay_tiles](https://github.com/minetest/minetest/blob/f9b1176fa9652cd0188c44cbb9416b0668bf55ff/doc/lua_api.txt#L829-L870) also, given that these are chests and probably never upside down or on their sides, perhaps using [paramtype2="color4dir"](https://github.com/minetest/minetest/blob/f9b1176fa9652cd0188c44cbb9416b0668bf55ff/doc/lua_api.txt#L765-L775) would make sense? you'd be able to get 64 colors that way. (EDIT: oh, i see you already mentioned this). @Sokomine if you can't do the graphics work, i can probably create overlay textures by copying the current ones and then making the "wood" parts transparent.

👍 2

flux added the

3. source/mod upstream

1. kind/other

labels 2023-04-15 17:01:12 +00:00

flux commented

2023-04-15 17:49:58 +00:00

![image](/attachments/4503162d-6457-4ed4-a4a0-d7db18e16b74)

image.png

83 KiB

👍 1 ❤️ 1

JeCel commented

2023-04-15 18:14:14 +00:00

That looks way better! Though I personally would prefer a bit lighter colors. I really enjoyed the old texture of the shared chest so colors that are in brightness similar to that would make more sense imo, and that way the old texture could also be kept for the blue chest?

flux commented

2023-04-15 19:37:26 +00:00

![image](/attachments/ba839fe7-d66a-4fbe-91ef-9daf511cf45d)

image.png

97 KiB

flux commented

2023-04-15 19:55:12 +00:00

64 colors, using 4dir:

64 colors, using 4dir: ![image](/attachments/92bf8b7c-66af-4f8e-af90-b2ff8409919d)

image.png

206 KiB

image.png

182 KiB

AliasAlreadyTaken commented

2023-04-16 03:41:53 +00:00

This issue needs to be resolved for 1.1.118

AliasAlreadyTaken added this to the 1.1.118 milestone 2023-04-16 03:41:57 +00:00

flux commented

2023-04-16 04:21:47 +00:00

the palettes have been free things off the internet that i've done minor modifications to. i'm not happy w/ them, i'm working on creating a new one programmatically

flux commented

2023-04-16 04:46:10 +00:00

new palate proposal: 8 shades of gray between #000000 and #ffffff, the other 56 colors evenly distributed in HSV w/ S and V set to max. working on a python/PIL script to generate that. i'll rotate the colors so that index 0 corresponds to the color closest to the old chest color.

new palate proposal: 8 shades of gray between `#000000` and `#ffffff`, the other 56 colors evenly distributed in HSV w/ S and V set to max. working on a python/PIL script to generate that. i'll rotate the colors so that index 0 corresponds to the color closest to the old chest color.

flux commented

2023-04-16 04:49:08 +00:00

alternate: 8 shades of gray as above, then, 14 hues evenly distributed, 2 S values (50% and 100%) and 2 V values (50% and 100%). tomorrow, or soon, i'll build the palettes and create example images from them

niceride commented

2023-04-16 06:17:20 +00:00

having a bright version each colour... if you cover these colours I'd be happy about it.

Feature creep: Have one of the colours be invisible as a chameleon colour where it takes on the texture of the block below it; if air is below it, then it is invisible.

![ANSI colours](https://i.stack.imgur.com/9UVnC.png) having a bright version each colour... if you cover these colours I'd be happy about it. Feature creep: Have one of the colours be invisible as a chameleon colour where it takes on the texture of the block below it; if air is below it, then it is invisible.

Bla commented

2023-04-16 06:49:13 +00:00

If you need color palettes -> https://lospec.com/palette-list

flux commented

2023-04-16 19:51:17 +00:00

palette a:

palette b:

palette c:

which do people prefer?

palette a: ![image](/attachments/5efc626b-2a2d-4952-aaba-96ee310daa8e) palette b: ![image](/attachments/b45b7533-8c1c-46fb-a44e-8833a1d8a01f) palette c: ![image](/attachments/347bcff6-331b-4ddd-9eda-0ff54c580894) which do people prefer?

image.png

144 KiB

image.png

144 KiB

image.png

126 KiB

JeCel commented

2023-04-16 22:59:23 +00:00

From the looks I prefer palette a BUT the colors are very similar so I suppose palette b or c make more sense. Of those I think I prefer palette b more because the low saturation colors on palette b look rather similar, too.

I wonder how these would look with the whitish border we are used to from the shared chest? That really gave it a unique look and I think I'm gonna miss it. But I suppose with the brownish border it makes more sense if people want to use them together with the default chest.

From the looks I prefer palette a BUT the colors are very similar so I suppose palette b or c make more sense. Of those I think I prefer palette b more because the low saturation colors on palette b look rather similar, too. I wonder how these would look with the whitish border we are used to from the shared chest? That really gave it a unique look and I think I'm gonna miss it. But I suppose with the brownish border it makes more sense if people want to use them together with the default chest.

flux commented

2023-04-17 03:41:59 +00:00

I wonder how these would look with the whitish border we are used to from the shared chest? That really gave it a unique look and I think I'm gonna miss it. But I suppose with the brownish border it makes more sense if people want to use them together with the default chest.

i could redo these w/ the white-ish border of the current chests, but my senses are telling me that the border taken from the minetest_game chests make these fit better into existing builds. so far as i control the "default" color of the fill so that it's like the old textures, i think the objections will be minimal. but @JeCel, as someone who makes use of a color scheme similar to my own, i certainly give your opinion a lot of deference.

of the current options, my personal preference is c, then a, then b. b should never have existed, c was the "correct" way to generate it.

the intention is to make them look better when placed near default chests.

the downside is that people might be confused occasionally that they're not looking at a default locked chest. but i am near certain that won't be a problem in practice, for reasons i hope are obvious.

> I wonder how these would look with the whitish border we are used to from the shared chest? That really gave it a unique look and I think I'm gonna miss it. But I suppose with the brownish border it makes more sense if people want to use them together with the default chest. i could redo these w/ the white-ish border of the current chests, but my senses are telling me that the border taken from the minetest_game chests make these fit better into existing builds. so far as i control the "default" color of the fill so that it's like the old textures, i think the objections will be minimal. but @JeCel, as someone who makes use of a color scheme similar to my own, i certainly give your opinion a lot of deference. of the current options, my personal preference is c, then a, then b. b should never have existed, c was the "correct" way to generate it. the intention is to make them look better when placed near default chests. the downside is that people might be confused occasionally that they're not looking at a default locked chest. but i am near certain that won't be a problem in practice, for reasons i hope are obvious.

👍 1

niceride commented

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

FYI when wielding a chesttool chest to upgrade an existing chest, the options for "shared" (graphic of standard chesttools chest) and "shared" (graphic of wallmounted chesttools chest) are transposed on test server as of 2023-04-18, selecting one does the action of the other.

which do people prefer?

Too many colour options. 4x4 is enough, eight base colours and eight bright versions of those colours.

FYI when wielding a chesttool chest to upgrade an existing chest, the options for "shared" (graphic of standard chesttools chest) and "shared" (graphic of wallmounted chesttools chest) are transposed on test server as of 2023-04-18, selecting one does the action of the other. > which do people prefer? Too many colour options. 4x4 is enough, eight base colours and eight bright versions of those colours.

flux commented

2023-04-18 21:15:13 +00:00

upstream PR

AliasAlreadyTaken modified the milestone from 1.1.118 to 1.1.119

2023-04-25 08:03:17 +00:00

AliasAlreadyTaken modified the milestone from 1.1.119 to 1.1.120

2023-05-07 19:24:25 +00:00

AliasAlreadyTaken removed this from the 1.1.120 milestone 2023-05-07 19:24:34 +00:00

Sign in to join this conversation.