| Time |
Nick |
Message |
| 00:01 |
|
ShadowBot` joined #minetest-dev |
| 00:02 |
|
troller joined #minetest-dev |
| 00:05 |
|
ShadowNinja joined #minetest-dev |
| 00:05 |
|
ShadowNinja joined #minetest-dev |
| 00:11 |
|
rom1504 joined #minetest-dev |
| 00:36 |
|
ircSparky joined #minetest-dev |
| 00:36 |
|
ircSparky joined #minetest-dev |
| 00:37 |
|
TC04 joined #minetest-dev |
| 00:52 |
|
AnotherBrick joined #minetest-dev |
| 01:01 |
|
Warr1024 joined #minetest-dev |
| 01:21 |
octacian |
#1592 |
| 01:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/1592 -- ConnectionReceiveThread::Thread(): Assertion '0' failed. |
| 01:22 |
octacian |
sofar, nore, paramat, anyone else xD ^ |
| 01:22 |
octacian |
* game#1592 |
| 01:22 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1592 -- Add workbench and nametag to rename items by octacian |
| 01:22 |
octacian |
I keep forgetting to put "game" first lol |
| 01:30 |
|
octacian_ joined #minetest-dev |
| 01:30 |
paramat |
ok |
| 01:33 |
|
octacian joined #minetest-dev |
| 01:34 |
octacian |
Also, game#1589 and game#1590 are ready to be merged from my testing. |
| 01:34 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1589 -- Keys: Show owner in description by octacian |
| 01:34 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1590 -- Books: Show title in description by octacian |
| 02:03 |
|
octacian joined #minetest-dev |
| 03:03 |
sofar |
octacian: merged one of them |
| 03:03 |
octacian |
sofar: ok. Adding screenshot to workbench PR |
| 03:04 |
sofar |
I'm gonna be honest with you - I really don't like the workbench as is |
| 03:06 |
octacian |
sofar: Added formspec screenshot. |
| 03:06 |
octacian |
And what do you not like about it? |
| 03:07 |
sofar |
in due time |
| 03:07 |
sofar |
but, almost all of it, lol |
| 03:07 |
octacian |
Specifics? |
| 03:07 |
sofar |
the need for a workbench entirely |
| 03:07 |
sofar |
the fact that it's a nodebox |
| 03:07 |
octacian |
Ah, I see. |
| 03:07 |
octacian |
You'd prefer a model? |
| 03:07 |
sofar |
the fact that one of the slots just always contains a nametag |
| 03:08 |
sofar |
for mtg, I'd prefer a normal node, just like a chest or a furnace |
| 03:08 |
octacian |
IDK, it'd be much harder to create a nice texture for a normal node. |
| 03:09 |
sofar |
plenty of workbench textures around that are usable |
| 03:09 |
octacian |
Also, the basic reason is that doing it with just a nametag using the method that books use for copying books would require that I register recipes with nametags for every single item in the game |
| 03:09 |
octacian |
True. |
| 03:09 |
octacian |
Could you give me a link. |
| 03:10 |
sofar |
xdecor has one from originally pixelbox I think |
| 03:10 |
sofar |
plus there's a few cc-by-sa MC texture packs around that are very usable as well |
| 03:10 |
octacian |
OK, I'll take a look. I'd be willing to change it. |
| 03:10 |
sofar |
e.g. pixelperfection, isabellaII |
| 03:10 |
sofar |
etc. |
| 03:11 |
octacian |
Now, IMO having a workbench is the best way to do it. |
| 03:12 |
octacian |
As you mentioned, something should be consumed in the renaming process as it should not be "free" to rename an item |
| 03:12 |
kaeza |
just a minor thing: should it be named "workbench"? |
| 03:12 |
kaeza |
may cause confusion for people who come from MC |
| 03:12 |
kaeza |
I'm fine with it in any case |
| 03:13 |
octacian |
So, I thought that keeping the nametag and requiring that it be in the workbench almost as "fuel" would be a good way to add cost |
| 03:13 |
sofar |
I think you can do it without all the recipes, and do it on the crafting grid |
| 03:13 |
octacian |
kaeza: I thought about that. I didn't have any better ideas though, aside from directly using anvil which doesn't even make sense anyways |
| 03:13 |
octacian |
sofar: it's true that you can, however, I personally think that the workbench is more, IDK, "elegant" maybe |
| 03:14 |
sofar |
MC solves the issue with the anvil, but the anvil has many purposes |
| 03:14 |
sofar |
the problem is that we've implemented tool repair without an anvil |
| 03:14 |
sofar |
otherwise I'd say, make an anvil instead |
| 03:15 |
octacian |
Yes, that's why I introduced the workbench. I was going to open a PR after this allowing you to repair tools only inside the workbench |
| 03:16 |
kaeza |
meh. I say leave it as-is |
| 03:16 |
octacian |
Though I guess an anvil is a "block with a hard surface on which another object is stuck" so it would kinda make sense to use an anvil |
| 03:20 |
octacian |
sofar: anyways, about the slot for nametags, I didn't really have a better idea as to how to require fuel |
| 03:26 |
sofar |
seriously though, I think we need to try a little harder to do this on the craftgrid |
| 03:26 |
octacian |
We could. |
| 03:27 |
octacian |
I'm open to giving it another try. |
| 03:27 |
octacian |
I still have the old code for the nametag on_use formspec. |
| 03:27 |
octacian |
Though I still think that overall a workbench would be better that would be used both for this and for repairing tools |
| 03:28 |
octacian |
Thought it would probably be actually easier to do it in the craftgrid. |
| 03:28 |
octacian |
If you've got any ideas as to how to do it, I'll try and implement it. Prob in a new PR. |
| 03:28 |
octacian |
That way both options are available for review. |
| 03:33 |
sofar |
my idea would be to make a craft recipe for the nametag and then use a group for renameable items |
| 03:33 |
sofar |
groups = { renamable = 1 }, |
| 03:33 |
sofar |
then the recipe for naming can refer to "group:renamable" |
| 03:34 |
octacian |
Yes, you could. However, chances are we'd want to make all items renamable. It'd be better to automatically assume renamable unless group = {renamable = 0} |
| 03:34 |
sofar |
and then we can selectively using groups mark items that are safe to rename |
| 03:34 |
octacian |
Yes. I think that that should be implemented either way. |
| 03:34 |
sofar |
nobody is going to make stone renamable |
| 03:34 |
sofar |
keys are the main thing imo |
| 03:35 |
sofar |
"front door key" |
| 03:35 |
octacian |
Yes, somebody will in a custom map. |
| 03:35 |
sofar |
well sure, but in a custom map they can toss a worldmod that marks special items renamable and actually names them too |
| 03:35 |
octacian |
With the ability to rename anything, you could do some pretty interesting stuff |
| 03:35 |
sofar |
so we don't need to worry about that much |
| 03:35 |
octacian |
It's preferable if map creators don't have to use worldmods though |
| 03:36 |
octacian |
However, I agree at this point with renaming in the craftgrid. |
| 03:36 |
|
Fritigern joined #minetest-dev |
| 03:36 |
sofar |
why? they're highly convenient and can ship with the map in one location |
| 03:36 |
octacian |
It wouldn't make sense unless repair was done in the workbench as well, which should definitely be left for later. |
| 03:37 |
octacian |
Yes, but IMO, if I was making a map and specifically wanted to prevent renaming items, there would only be a small amount of items that I'd want to prevent |
| 03:37 |
sofar |
well, it's moot anyway since you can just make named items irregardless |
| 03:38 |
octacian |
Why, well because when making maps I'd personally prefer not having to restart the world every time I wanted to change something |
| 03:38 |
octacian |
Which is why I think we should also have a utilities mod with stuff like a command block |
| 03:38 |
sofar |
you're argueing the wrong way |
| 03:38 |
octacian |
That's probably true :rotfl: |
| 03:38 |
sofar |
map creators want to use special tools to make special items |
| 03:38 |
sofar |
and then remove those so the map is "adventure mode" |
| 03:39 |
octacian |
True. Still though, I think stuff should be automatically renamable. |
| 03:39 |
sofar |
can't see why we couldn't have an admin-only command |
| 03:40 |
octacian |
What do you mean? to do what? rename items? |
| 03:40 |
octacian |
Oh. I understand. |
| 03:40 |
octacian |
I don't see an issue with that either, but it just doesn't make since to not be able to rename items. |
| 03:41 |
sofar |
well, here's what I think |
| 03:41 |
sofar |
I think we should have a relatively small basic set of items that can always be renamed |
| 03:41 |
sofar |
things like craftitems and some tools |
| 03:41 |
sofar |
but probably not nodes |
| 03:41 |
sofar |
leave those not nameable for now |
| 03:42 |
sofar |
it's easy enough to generate named nodes irregardless |
| 03:42 |
sofar |
any 2 lines of lua can make them |
| 03:42 |
sofar |
books are already solved |
| 03:42 |
sofar |
keys are badly needed |
| 03:43 |
sofar |
but I could care less if people named a mushroom or a loaf of breakd |
| 03:43 |
sofar |
bread* |
| 03:43 |
sofar |
but weapons, no |
| 03:43 |
sofar |
I don't see why we would allow so by default |
| 03:43 |
octacian |
Yes, I agree. However I still see no reason why we should prevent people from naming nodes or weapons. |
| 03:43 |
sofar |
it's only going to conflict with mods |
| 03:43 |
* sofar |
ponders |
| 03:43 |
sofar |
well, maybe not |
| 03:44 |
sofar |
do we have a group:tool ? |
| 03:44 |
octacian |
I'm not sure. |
| 03:44 |
octacian |
No. |
| 03:44 |
octacian |
we do have minetest.registered_tools don't we though? |
| 03:44 |
octacian |
Yes, we do. |
| 03:45 |
sofar |
the craft stuff works for us if we use groups |
| 03:45 |
octacian |
Could use a simple loop to iterate through and add renamable though I still don't like preventing renaming some stuff. |
| 03:45 |
octacian |
But again, that's true, it only works if we use groups. |
| 03:45 |
sofar |
I'm sure we can compromise on that |
| 03:46 |
octacian |
Meaning that the only way to allow renaming everything would be to iterate through registered_items adding renamable = 1 to the groups if it wasn't already equal to 0 |
| 03:46 |
sofar |
we'd just add it to every node reg |
| 03:47 |
sofar |
override_item makes no sense inside default |
| 03:47 |
octacian |
True. |
| 03:47 |
sofar |
sadly, some parts do :/ |
| 03:47 |
octacian |
But what about other mods outside MTG. |
| 03:47 |
octacian |
For example, the books in homedecor. |
| 03:48 |
octacian |
Defaulting to renamable would allow players using homedecor to take advantage of the new features and rename books even before homedecor is updated |
| 03:48 |
octacian |
(the same goes for other mods that introduce like items) |
| 03:48 |
sofar |
ah see |
| 03:48 |
sofar |
I don't think we should allow books to be renamed |
| 03:49 |
sofar |
that'd be a copyright violation |
| 03:49 |
octacian |
rly.. :rotfl: |
| 03:49 |
sofar |
besuides, the persson writing can already give a title |
| 03:49 |
sofar |
and even change it |
| 03:51 |
octacian |
True. But they can't change the description tooltip |
| 03:51 |
octacian |
It would be appreciated for organization, just as the new functionality in default will be. |
| 03:52 |
octacian |
This, IMO, leaves two options: implement using craftgrid and groups and iterate through registered_items setting groups.renamable = 1 |
| 03:52 |
octacian |
or use workbench approach |
| 03:52 |
octacian |
^^ only if groups.renamable ~= 0 ofc |
| 03:52 |
octacian |
That's what I see anyway. |
| 03:53 |
sofar |
separate mechanism from nodes/items |
| 03:53 |
octacian |
What do you mean? |
| 03:54 |
octacian |
registered_items contains a table of all nodes, craftitems, and tools |
| 03:54 |
octacian |
* list, not table |
| 03:54 |
sofar |
iterating and modifying every registration == bad |
| 03:54 |
octacian |
Yes, I agree. |
| 03:54 |
sofar |
so, dont |
| 03:54 |
octacian |
I just don't see a better way to do it aside from limiting the items which I personally do not like either. |
| 03:54 |
sofar |
just implement naming based on groups |
| 03:55 |
sofar |
then we can argue the second part |
| 03:55 |
octacian |
Will do. I'll open a second PR tomorrow. |
| 03:55 |
sofar |
ppl will disagree with me as well, lol |
| 03:55 |
octacian |
Leave them both open ofc though. |
| 03:55 |
octacian |
somebody will ALWAYS disagree with you xD |
| 03:56 |
paramat |
sofar are you ok with game#1587 ? |
| 03:56 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1587 -- Biomes: New surface node for rainforest by paramat |
| 03:57 |
sofar |
paramat: do it, :+1: |
| 03:59 |
octacian |
I've gtg though. https://github.com/minetest/minetest_game/pull/1592#issuecomment-282935503 |
| 04:11 |
paramat |
ok |
| 04:16 |
|
Hunterz joined #minetest-dev |
| 04:26 |
paramat |
hm 'litter' seems to be a more suitable term than 'debris' |
| 04:28 |
paramat |
there's 'detritus' and 'duff' but those are less clear language |
| 04:28 |
octacian |
paramat: that font is just installed locally |
| 04:28 |
octacian |
I didn't hardcode it, in fact, is that even possible? |
| 04:29 |
octacian |
https://github.com/minetest/minetest_game/pull/1592#issuecomment-282939018 |
| 04:30 |
paramat |
ok |
| 04:30 |
paramat |
no problem |
| 04:31 |
paramat |
i'm going to use 'rainforest litter'. i get anxious when naming nodes, it has to be right otherwise we have to use dreaded aliases to support old worlds |
| 04:32 |
octacian |
paramat: BTW, do you prefer the crafting grid approach to renaming items, or the workbench (which easily allows renaming anything but nametags)? |
| 04:45 |
paramat |
i'll think on that |
| 04:46 |
octacian |
OK |
| 04:55 |
|
Hunterz joined #minetest-dev |
| 05:30 |
paramat |
merging game#1587 in a moment |
| 05:30 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1587 -- Biomes: New surface node for rainforest by paramat |
| 05:32 |
paramat |
merging .. |
| 05:35 |
paramat |
.. complete |
| 05:53 |
|
lhofhansl joined #minetest-dev |
| 05:56 |
lhofhansl |
How can I determine whether a piece of code (say in Map or MapBlock) is run on the server or the client? #ifdef SERVER does not work when the client is starting the server. |
| 05:57 |
lhofhansl |
(and I do not want to use virtual methods between ClientMap and ServerMap because this is hot path and the dispatch might slow things) |
| 06:05 |
|
Hunterz joined #minetest-dev |
| 06:47 |
lhofhansl |
NM. Found another way. |
| 07:14 |
lhofhansl |
#5320 |
| 07:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/5320 -- [For Testing] Allow server side occlusion culling. by lhofhansl |
| 07:14 |
|
lhofhansl left #minetest-dev |
| 07:16 |
|
lhofhansl joined #minetest-dev |
| 07:16 |
|
lhofhansl left #minetest-dev |
| 08:08 |
|
lumidify joined #minetest-dev |
| 08:29 |
|
ssieb joined #minetest-dev |
| 09:25 |
|
ID joined #minetest-dev |
| 09:26 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:59 |
|
troller joined #minetest-dev |
| 10:19 |
|
shymega joined #minetest-dev |
| 10:29 |
|
Fixer joined #minetest-dev |
| 10:38 |
|
silwol joined #minetest-dev |
| 12:29 |
|
eeew joined #minetest-dev |
| 12:33 |
|
Karazhan joined #minetest-dev |
| 12:34 |
|
nerzhul joined #minetest-dev |
| 12:42 |
|
proller joined #minetest-dev |
| 12:52 |
|
proller joined #minetest-dev |
| 13:13 |
|
xerox123 joined #minetest-dev |
| 13:14 |
|
eeew joined #minetest-dev |
| 13:31 |
|
Fixer joined #minetest-dev |
| 13:41 |
|
ircSparky joined #minetest-dev |
| 13:48 |
|
xerox123 joined #minetest-dev |
| 13:53 |
|
proller joined #minetest-dev |
| 13:55 |
|
Fixer_ joined #minetest-dev |
| 13:59 |
|
xerox123 joined #minetest-dev |
| 14:44 |
|
Taoki joined #minetest-dev |
| 14:47 |
|
ircSparky joined #minetest-dev |
| 14:47 |
|
ircSparky joined #minetest-dev |
| 14:57 |
|
proller joined #minetest-dev |
| 15:04 |
|
octacian joined #minetest-dev |
| 15:05 |
octacian |
sofar: I believe the books PR is ready to merge (rubenwardy gave it a thumbs up) |
| 15:08 |
|
ircSparky joined #minetest-dev |
| 15:11 |
|
Hunterz joined #minetest-dev |
| 15:12 |
|
ircSparky joined #minetest-dev |
| 15:19 |
|
ircSparky_ joined #minetest-dev |
| 15:39 |
|
proller joined #minetest-dev |
| 15:53 |
|
twoelk joined #minetest-dev |
| 16:14 |
|
YuGiOhJCJ joined #minetest-dev |
| 16:29 |
|
ircSparky joined #minetest-dev |
| 16:29 |
|
ircSparky joined #minetest-dev |
| 16:42 |
|
silwol joined #minetest-dev |
| 16:58 |
|
twoelk|2 joined #minetest-dev |
| 17:00 |
|
Krock joined #minetest-dev |
| 17:30 |
|
kaeza joined #minetest-dev |
| 17:33 |
|
ircSparky joined #minetest-dev |
| 17:33 |
|
ircSparky joined #minetest-dev |
| 17:37 |
|
ircSparky_ joined #minetest-dev |
| 17:43 |
|
ircSparky joined #minetest-dev |
| 17:54 |
|
silwol joined #minetest-dev |
| 17:58 |
|
betterthanyou710 joined #minetest-dev |
| 17:59 |
|
est31 joined #minetest-dev |
| 17:59 |
Thomas-S |
Can someone please review #5302? This is very much needed, I think this would solve the mining drill problem with the technic mod, too. |
| 17:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/5302 -- Store legacy metadata separate from new item meta data by rubenwardy |
| 18:00 |
|
betterthanyou711 joined #minetest-dev |
| 18:03 |
|
blaze joined #minetest-dev |
| 18:05 |
|
ircSparky_ joined #minetest-dev |
| 18:16 |
|
xerox123 joined #minetest-dev |
| 18:20 |
Krock |
Thomas-S, would be more helpful to know why numberZero downvoted on it |
| 18:21 |
Krock |
sofar, FYI. I'm keen to fix the issues in #4304 and open a new pull for it - but I guess this won't happen before this weekend |
| 18:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/4304 -- Add fading sounds by Bremaweb |
| 18:22 |
sofar |
Krock: neat, I can wait |
| 18:23 |
Krock |
^^ |
| 18:33 |
|
nerzhul joined #minetest-dev |
| 18:37 |
|
paramat joined #minetest-dev |
| 18:46 |
|
Fixer joined #minetest-dev |
| 18:54 |
VanessaE |
paramat, sofar: will param2 or hardware coloring ever be applied to default wool? (need to know for a future plan) |
| 18:54 |
VanessaE |
s/ or /\// |
| 18:54 |
sofar |
my position is |
| 18:54 |
sofar |
it's contingent on getting coloring of itemstacks |
| 18:55 |
sofar |
if we can get itemstack meta coloring |
| 18:55 |
sofar |
then we can have colored wool |
| 18:55 |
paramat |
indeed |
| 18:55 |
sofar |
and even handle digging and placing with a simple API |
| 18:55 |
VanessaE |
I ask because I want to pipe wool through Unified Dyes, given the extensive color range it has. |
| 18:55 |
VanessaE |
UD has those, btw. |
| 18:56 |
VanessaE |
I tried to cover everything that could be wanted with this sorta thing (colored itemstacks aside) |
| 18:56 |
sofar |
without colored itemstacks, we can't have red wool in the inventory next to blue wool |
| 18:57 |
paramat |
but also some are concerned about how this limits texture packs ability to choose their own exact hues and use individual textures instead of colourising a single texture |
| 18:57 |
|
ircSparky joined #minetest-dev |
| 18:57 |
sofar |
and I absolutely dislike the "drop item+dye" mantra |
| 18:57 |
sofar |
paramat: they can replace the colormap too |
| 18:57 |
VanessaE |
sofar: only sane way to do it without colored itemstacks |
| 18:57 |
sofar |
paramat: so that solves that problem entirely |
| 18:57 |
paramat |
oh yeah oops |
| 18:58 |
sofar |
VanessaE: I can't politely say how bad I find that method |
| 18:58 |
sofar |
so I would have never done it |
| 18:58 |
sofar |
colored itemstacks, problem solved |
| 19:00 |
VanessaE |
sofar: ok so how would you have done it? |
| 19:00 |
VanessaE |
assume no colored itemstacks |
| 19:00 |
sofar |
not |
| 19:00 |
sofar |
that's what I said |
| 19:00 |
sofar |
<sofar> so I would have never done it |
| 19:00 |
VanessaE |
nono I mean, |
| 19:01 |
VanessaE |
how would you have done colorized ... anything ... without managing the dyes etc? |
| 19:01 |
sofar |
I would have *not* done it, and instead solve the colored itemstack problem first |
| 19:01 |
VanessaE |
I see. |
| 19:01 |
paramat |
^ indeed |
| 19:01 |
sofar |
now you have everyone learning a weird new way |
| 19:02 |
sofar |
I just want a red wool block in my inventory when i dig a red wool block |
| 19:02 |
sofar |
I mean, I didn't see the problem beforehand either :) |
| 19:02 |
VanessaE |
and then I presume colored itemstacks, you would import the param2 value to the itemstack, expl... yes, that. |
| 19:02 |
sofar |
the only exception is landscape coloring |
| 19:02 |
sofar |
that doesn't need colored itemstacks imho |
| 19:02 |
VanessaE |
I'm fine with that idea, and as soon as it becomes possible, I'll implement it. |
| 19:03 |
VanessaE |
or rather, use it |
| 19:03 |
sofar |
afk a bit |
| 19:03 |
paramat |
a minor issue is that colourising a single base texture is less flexible in appearence than tuning individual textures in Gimp |
| 19:03 |
VanessaE |
paramat: true enough, and default wool would have some difficulty there because yellow wool is more of a yellow-with-gold-highlights |
| 19:04 |
VanessaE |
the others, I was able to get reasonably close (look at castles++ mod's tapestries for an example) |
| 19:04 |
paramat |
and there are only 14 wools, so i don't see much need to use hardware colouring |
| 19:04 |
VanessaE |
14 wools, hardware coloring, suddenly you have the equivalent of 256. |
| 19:04 |
VanessaE |
since they'd all be reduced to a single node. |
| 19:04 |
VanessaE |
(node def that is) |
| 19:05 |
paramat |
you mean add new colours? |
| 19:06 |
VanessaE |
well you could, but "new colors" comes with the territory |
| 19:06 |
VanessaE |
no one says the extra colors have to be in the inventory |
| 19:06 |
VanessaE |
I do that with UD for example. the default 15 dyes are there, but the 240 others added by UD are not. |
| 19:06 |
paramat |
ah the palette .. |
| 19:06 |
VanessaE |
yes. |
| 19:06 |
VanessaE |
it's just a side effect, one you'd be advised to take advantage of ;) |
| 19:08 |
|
juhdanad joined #minetest-dev |
| 19:10 |
cheapie |
OK, so param2-ize the wool, then make it work with colored itemstacks as well once that's possible. I don't see the issue here. |
| 19:11 |
VanessaE |
point is, I'm going to write a mod, or maybe cheapie will, that's gonna param2-ize the wool, one way or another. |
| 19:11 |
VanessaE |
and it'll run through UD |
| 19:11 |
cheapie |
VanessaE: I already failed miserably at that. You do it :P |
| 19:11 |
VanessaE |
the whole point of that mod is a central API and way of doing things. one change there and everything that uses it follows. |
| 19:11 |
VanessaE |
cheapie: no worries, I'll figure it out. |
| 19:12 |
|
juhdanad joined #minetest-dev |
| 19:12 |
juhdanad |
Hi all! |
| 19:13 |
VanessaE |
hey |
| 19:13 |
juhdanad |
Finally I could connect... |
| 19:15 |
juhdanad |
So, I don't know how itemstack metadata works. Is it possible to return an itemstack with a field 'param2' set when a node is dug? |
| 19:15 |
VanessaE |
no idea, though if there's meta then I don't see why not |
| 19:16 |
paramat |
not sure |
| 19:16 |
juhdanad |
And if you have two items with the same metadata values, can you merge them? |
| 19:19 |
Krock |
I'm not aware of such a check |
| 19:19 |
paramat |
Krock if core devs agree to this, would you be interested in being a mtgame dev? |
| 19:20 |
Krock |
paramat, well, I'm not sure. Either I'd want to join both or none |
| 19:20 |
paramat |
ah it could be both |
| 19:20 |
paramat |
normally it would be actually |
| 19:20 |
Krock |
just because Zeno also already talked to me a while back |
| 19:21 |
Krock |
I'm not sure what's to expect from a dev and the instructions on the wiki are quite vague |
| 19:22 |
paramat |
your blood |
| 19:22 |
VanessaE |
heh |
| 19:22 |
Krock |
doing a blood brother ritual xD |
| 19:23 |
|
ircSparky_ joined #minetest-dev |
| 19:23 |
paramat |
there's no obligation to work when you don't feel like it, many devs disappear often. it's mostly code review and approvals |
| 19:25 |
Krock |
ah, good to know that. Well, for me this doesn't have any priority at all but if you think there should be a voting then I wouldn't say no :) |
| 19:26 |
paramat |
we'll see what devs think |
| 19:26 |
Krock |
juhdanad, AFAIK the metadata is cleared when two items are merged, thus all of these specific items have a stack max of 1 or use wear |
| 19:29 |
juhdanad |
Then metadata is not a good solution for storing colors... |
| 19:29 |
VanessaE |
well my vote means exactly bupkis but I'm okay with Krock being added as a dev. |
| 19:29 |
Krock |
VanessaE, but you're also quite long into this game and surely have got plenty of knowledge ;) |
| 19:30 |
paramat |
i would be +1 for engine and game dev |
| 19:31 |
|
ircSparky_ joined #minetest-dev |
| 19:31 |
sofar |
juhdanad: itemstacks with different meta don't merge |
| 19:31 |
sofar |
juhdanad: yes, you can (in lua already) make an itemstack contain a param2 when digging that reflects the node param2 |
| 19:31 |
sofar |
as a matter of fact, we could retain the digging param2 for certain nodes |
| 19:31 |
sofar |
but, easy enough to do in lua |
| 19:32 |
juhdanad |
Great! Then it is easy to render the item according to its metadata (I think so...) |
| 19:32 |
VanessaE |
fwiw, UD stores the color in the node's metadata as well as its param2 |
| 19:32 |
sofar |
but remember, items ~= nodes |
| 19:33 |
sofar |
craftitem properties do not have tiles |
| 19:33 |
sofar |
instead, inventory_image |
| 19:33 |
VanessaE |
(easier to reference the stored dye name then to look up the color from the param2 value) |
| 19:33 |
sofar |
you may have to add a color = property |
| 19:33 |
sofar |
as well, to make it symmetric with nodes |
| 19:34 |
sofar |
VanessaE: that's a mod choice, though |
| 19:34 |
VanessaE |
yes. |
| 19:34 |
VanessaE |
just pointing it out for reference. |
| 19:34 |
sofar |
if we're reserving itemstack meta names we should be consistent |
| 19:34 |
sofar |
description is now already used officially |
| 19:34 |
juhdanad |
No, param2 is needed. This ensures that mods can replace palettes. |
| 19:34 |
sofar |
we can do param2, it seems the best |
| 19:34 |
sofar |
but are we going to do paramtype2 for craftitems? |
| 19:34 |
sofar |
it would be most logical |
| 19:36 |
sofar |
also, you need to provide a palette |
| 19:36 |
juhdanad |
There would be two fields, I suppose: 'param2', which is effective for nodes, and 'color', which overrides everything. |
| 19:37 |
sofar |
so a palette = param is needed |
| 19:37 |
juhdanad |
That way you can also rotate facedir nodes in the inventory. |
| 19:37 |
sofar |
yup |
| 19:37 |
sofar |
well nodes should be simpler |
| 19:37 |
|
DI3HARD139 joined #minetest-dev |
| 19:37 |
sofar |
since they already have palette, paramtype2 properties |
| 19:38 |
juhdanad |
The problem is that palettes are only loaded if a node requests them. |
| 19:42 |
sofar |
so that would have to be added for craftitems then |
| 19:42 |
VanessaE |
all I care about is that whatever is in the inventory, it looks exactly the same as it does in the world (drops/forced inventory colors aside). :) |
| 19:44 |
juhdanad |
Well, I think I can do that, but then item definitions will also have palettes. |
| 19:45 |
|
betterthanyou710 joined #minetest-dev |
| 19:46 |
juhdanad |
BTW when do you plan to release the next version of Minetest? |
| 19:46 |
paramat |
perhaps may-june |
| 19:47 |
juhdanad |
Then I'll have a plenty of time. |
| 19:51 |
juhdanad |
paramat: did you notice that your 'chambers' mod does not always manage to generate the full chamber if you fly around fast? |
| 19:52 |
sofar |
juhdanad: that's acceptable |
| 19:53 |
sofar |
juhdanad: wanted, even, I think |
| 19:54 |
juhdanad |
It is because the map generator copies some blocks, then the mod generates the chamber, finally the mapgen blits back the unchanged data. |
| 19:54 |
|
diemartin joined #minetest-dev |
| 19:54 |
juhdanad |
This also causes the 'moretrees' mod's partially generated trees. |
| 20:00 |
|
blaze joined #minetest-dev |
| 20:03 |
diemartin |
#1596 |
| 20:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/1596 -- Wrong letters shown in Czech translation (V0.4.8)- Mageia, GNU/Linux |
| 20:03 |
diemartin |
game#1596 |
| 20:03 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1596 -- Add desert/silver sandstone-related blocks. by kaeza |
| 20:06 |
Fixer |
i really waiting for coloured baked clay in default, i miss it so much (very popular building block in minecraft btw, wool texture is not good for buildings and nature materials are limiting) |
| 20:06 |
VanessaE |
unifiedbricks has that. |
| 20:08 |
VanessaE |
(it isn't baked, but it is clay blocks and looks good) |
| 20:09 |
Fixer |
hardened/backed/whatever - texture is important |
| 20:10 |
VanessaE |
there's a mod for that, too |
| 20:10 |
VanessaE |
(I should fork it and convert it to use UD) |
| 20:11 |
VanessaE |
https://forum.minetest.net/viewtopic.php?id=8232 or https://forum.minetest.net/viewtopic.php?id=8890 |
| 20:18 |
paramat |
my 'catacomb' mod? |
| 20:18 |
paramat |
that mod doesn't work in 'on generated though' |
| 20:20 |
paramat |
oh you mean when a nearby mapchunk is generated |
| 20:21 |
paramat |
hm i think i noticed a few chambers missing a wall |
| 20:23 |
|
ircSparky joined #minetest-dev |
| 20:36 |
|
ircSparky joined #minetest-dev |
| 20:37 |
paramat |
well nevermind seems too difficult and complex to fix |
| 20:37 |
|
ircSparky joined #minetest-dev |
| 20:48 |
|
ircSparky joined #minetest-dev |
| 20:58 |
|
ircSparky joined #minetest-dev |
| 21:36 |
|
Tmanyo joined #minetest-dev |
| 21:52 |
|
proller joined #minetest-dev |
| 22:03 |
|
YuGiOhJCJ joined #minetest-dev |
| 22:05 |
octacian |
sofar: FYI, I think the books PR is ready to merge, rubenwardy approved. |
| 22:08 |
|
xerox123 joined #minetest-dev |
| 22:22 |
|
kaeza joined #minetest-dev |
| 22:26 |
|
diemartin joined #minetest-dev |
| 22:38 |
|
AnotherBrick joined #minetest-dev |
| 22:47 |
|
paramat joined #minetest-dev |
| 23:16 |
|
proller joined #minetest-dev |
| 23:39 |
diemartin |
paramat, should I also change the "normal" sandstonebrick? |
| 23:40 |
paramat |
no, that would need an alias and we want to avoid those |
| 23:41 |
paramat |
trees have inconsistent naming too for old and new tree types |
| 23:44 |
diemartin |
I can use a simple alias, duplicated code, or an unreadable mess |
| 23:45 |
paramat |
hm yes looks like old sandstone would have to be separate from your register functions |
| 23:45 |
paramat |
well, for crafting at least |
| 23:46 |
diemartin |
no, because I also register the nodes, and I must make a special exception for the normal one |
| 23:46 |
paramat |
for nodedefs you can expand the prefix to become the whole name? |
| 23:47 |
diemartin |
I can do that. don't have to like it though :( |
| 23:48 |
diemartin |
uh, actually, you'd need to pass three names or at least just the "stone" name which will quickly get a mess |
| 23:48 |
diemartin |
what's bad about aliases? |
| 23:50 |
paramat |
yes i can see this would affect your clean code, however i think some code duplication is fine, i would suggest splitting off the old sandstone and using your code for the 2 new ones |
| 23:51 |
paramat |
well, i personally don't like them unless essential, and here we are doing it just for name consistency (non essential) and your registering method (nice but non essential) |
| 23:53 |
diemartin |
so, just opinion, no technical reasons? |
| 23:53 |
paramat |
for just a few new nodes i would have been fine with duplicated code |
| 23:53 |
paramat |
well technical too yes |
| 23:55 |
paramat |
duplicated code for nodes is actually a little clearer to read and understand |
| 23:55 |
paramat |
sorry btw |
| 23:56 |
diemartin |
I'm just trying to get some comments before I change it and somebody complains "why not create a function for this" or something :) |
| 23:57 |
|
Tmanyo joined #minetest-dev |
| 23:58 |
diemartin |
I disagree. I find it perfectly readable. also, duplicating code makes it harder to change things (like groups or whatever) if needed in the future as you need to change it N times instead of just once |
