Closed Fixer-007 closed 6 years ago
:+1: but without giving the dye back on dig (may be an option)
@numberZero I'm not sure that's even possible, without using the node's on_dig(). Also, @Fixer-007 I don't think coloring works on nodeboxes yet. (Although, knowing how badly I keep up with MT news, I could be dead wrong.)
@C1ffisme Coloring should work for everything, including meshes, firelike, etc.
without using the node's on_dig()
on_dig
is needed, but that’s not a problem.
Actually, there should be an option to give the dye back as most things in MTG may be placed and dug without any loss, player might complain otherwise.
Giving back the dye doesn't make sense. Give back the colored block ...
Giving back the dye doesn't make sense. Give back the colored block ...
That is not possible at this point, as coloured blocks do not show as they should in the inventory but only when placed down.
IMO, the best way to do this is to store the wool used in a meta value, and then on_dig
drop both the original item and the wool itemstring stored in the meta.
I think someone should definitely go ahead and open a PR with this. I'd do it myself, but I've already compiled a list of over 12 things I need to do for MT, each of them would in the end result in a PR of their own.
@octacian wool?
I'm not keen on this in MTG, painting individual nodes will be slow and uses a large number of dyes, better to mass-craft coloured blocks in a recipe if we are going to have coloured nodes.
Digging painted blocks gives back original blocks and original dye.
I think players will want the coloured nodes returned, but this can't be done yet as hardware-coloured nodes are not distinct in inventory, hardware colouring needs more development. Painting like this seems quite specialised so i feel should be in a separate mod. :-1:
Someone just needs to bribe @juhdanad to implement colored itemstack items based on itemstack metadata, and then this can be implemented without the silly painting interfacing of punching a node with dye, and work exactly as it does now: mix an item with dye on the craftgrid.
I suppose a new metadata field: 'param2'. The item is drawn according to that param2
and if it is placed, the placed node will have the same param2
.
With that a new nodedef property would be introduced: keep_param2
. If it is true, digging a node yields an item with param2
set.
How does that sound?
Well, that would require some refining: colorfacedir nodes will appear rotated in the inventory. Does anyone have a better idea?
I'm not keen on this in MTG, painting individual nodes will be slow and uses a large number of dyes, better to mass-craft coloured blocks in a recipe if we are going to have coloured nodes.
So you say better add thousands of new nodes instead of implement proper "painting" of placed nodes?
We're not talking thousands of nodes, in fact, only one. With the ability to see the colored nodes in the inventory, we could simply register one base node, which when combined with dye would set the new param2
meta field (somewhat like a paint tool, just more consistent with existing mechanics).
Thousands as in 14 yes. But seriously, hardware colouring means only 1 base node is needed, i'm just saying it's better to mass-craft these instead of paint one at a time, which would be tedious if building a house out of coloured nodes.
Paints wooden planks, fences, white baked clay blocks, glass and glass panes, same for slabs/stairs (at least).
Too complex for MTG, should be a mod.
i'm just saying it's better to mass-craft these instead of paint one at a time, which would be tedious if building a house out of coloured nodes.
You don't play the game you develop, right?
I do play it, dev is impossible otherwise.
Do you do anything other than write grumpy comments about my dev work?
There will always be a disconnect between dedicated players, and people who develop the game.
@dsohler Expecting us to play the game more, is asking us to develop it less
@sofar Valid point, yes :+1: Developing a whole game + engine is way more complex than developing several mods and maintaining them in a modpack.
But if you don’t have time to develop AND play then the devs should listen more to the players (suggestions, pull requests, forums) instead of simply stating (some do this frequently) that no-one needs or wants this or that feature or that it is too boring/complex/inconvenient/etc. when added to the game.
Note, I've created this topic for brainstorming, it is not necessarily a best option, another alternative is dyeing everything in crafting grid.
devs should listen more to the players (suggestions, pull requests, forums) instead of simply stating (some do this frequently) that no-one needs or wants this or that feature or that it is too boring/complex/inconvenient/etc. when added to the game.
All MTG devs play the game, lthough it may be a different type of playing to the usual. We do listen a lot, it's important to not listen too much though, dev by democracy would be a disaster.
simply stating (some do this frequently) that no-one needs or wants this or that feature or that it is too boring/complex/inconvenient/etc. when added to the game.
You are obviously referring to me here, if i seem highly opinionated that is because i'm highly active and comment a lot. We listen and also state our opinions.
dsohler it is very noticeable that you make many comments that are simply negative and sarcastic without being constructive arguments at all (very often these are related to my dev work).
dev by democracy would be a disaster.
Yes, there always has to be one “dictator” who finally decides if a feature will be added or not. But I think all features should be discussed and accepted or denied in a well-founded way. “I don’t like/want/need this” is not a good thing. Same is “it is too complex to add” because all devs dedicate their hobby time to it it is kind of “your job” to code things into the game or engine. (Before answering please make sure you noticed the quotation mamarks that add further meaning to the words/phrases).
negative and sarcastic
I’d rather say realistic and frustrated.
very often these are related to my dev work
Because for unknown reason you’re the dev whose decisions I mostly disagree with. This is nothing personal.
I would like to add my opinion (how I would like paint system to be implemented):
I'm quite partial to the way Unified Dyes does it - place a node, punch it with dye to color it, then when you place more of that node, they turn the same color (until you run out of dye or cancel the feature with a shift-punch or placing a different colorable node).
Whether a node can be colored depends on the mod that supplies that node having the appropriate items in its node definition, of course.
there always has to be one “dictator” who finally decides if a feature will be added or not
That's not how we work, we decide by team approvals. No one dev has more power than any other. It may a kind of listening, caring, benign group-dictatorship.
“I don’t like/want/need this” is not a good thing
It's only bad if in a completely self-centred way. It's fine to say 'i don't like/want this because i believe it is wrong for the game and players'. This is what devs mean when they say 'i don't like/want this'. 'I don't need this' is of course unreasonable, the game is not for 1 person, devs obviously know this.
“it is too complex to add”
It is completely reasonable to consider something overly complex for MT, or a solution overly complex for the issue. MT is very much about simplicity and being lightweight.
it is kind of “your job” to code things into the game or engine
The complexity argument is not about dev laziness to code something, but is about what is suitable.
So first off, I'd like to stress that "dying of nodes" is already something that can be done, and we've never obstructed it.
We just haven't pulled it into minetest_game
.
Now, second, @juhdanad has been so kind to code up all sorts of cool node and itemstack coloring code.
I want to use these improvements, but they are not without work. And they also have some bugs right now.
But while I'd love to use this new code right now, I want to first do this without inventing a new user interface, and just plainly replace the old things colorable in minetest_game
with these new colored nodes (in other words: wool, and wool only).
Anything else, please keep doing this in mods. Once we have minetest_game
converted to use colored nodes/itemstacks, then a painting API makes much more sense. But I'm not going to add a painting API until we have colored nodes working exactly like the wool nodes work now.
small steps. There is likely still more engine work needed to get it right.
No core dev support for it now, maybe later if certain things happen in MTG, seems specialised and more for optional mods.
Paint tool:
This is opened for brainstorming