| Time |
Nick |
Message |
| 00:24 |
|
Cornelia joined #minetest-dev |
| 00:26 |
|
ANAND joined #minetest-dev |
| 00:33 |
|
Lia joined #minetest-dev |
| 02:11 |
|
TBSliver joined #minetest-dev |
| 02:23 |
|
ssieb joined #minetest-dev |
| 04:04 |
|
paramat joined #minetest-dev |
| 07:01 |
|
pyrollo joined #minetest-dev |
| 07:47 |
|
twoelk joined #minetest-dev |
| 07:55 |
|
celeron55 joined #minetest-dev |
| 07:56 |
|
celeron55 joined #minetest-dev |
| 08:20 |
|
Nigel joined #minetest-dev |
| 08:33 |
|
Lone-Star joined #minetest-dev |
| 09:17 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:03 |
|
Fixer joined #minetest-dev |
| 10:52 |
|
twoelk|2 joined #minetest-dev |
| 10:59 |
|
Beton joined #minetest-dev |
| 11:11 |
|
DI3HARD139 joined #minetest-dev |
| 12:43 |
sfan5 |
merging #8511 |
| 12:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/8511 -- minimal: Fix crash due to assertion fail by ClobberXD |
| 12:55 |
|
twoelk joined #minetest-dev |
| 13:08 |
|
Ruslan1 joined #minetest-dev |
| 13:33 |
|
ensonic joined #minetest-dev |
| 13:43 |
ANAND |
p_gimeno: OK, we can keep that patch separate |
| 13:44 |
p_gimeno |
makes sense to me |
| 13:46 |
p_gimeno |
but then, Krock's objection probably needs to be addressed, which is somewhat uncomfortable |
| 14:59 |
|
T4im joined #minetest-dev |
| 15:23 |
|
nerzhul joined #minetest-dev |
| 15:24 |
|
nerzhul joined #minetest-dev |
| 16:07 |
VanessaE |
suggestion: change mese lamp description to "Mese Lamp/Light" (or without the / ), so that a search for "light" brings up both it and the pole light (and all of homedecor's lighting, too) |
| 16:07 |
sfan5 |
perhaps unified_inventory should automatically find light-emitting nodes when you search for light |
| 16:09 |
p_gimeno |
that's a great idea; changing the description for MTG wouldn't fix third party mods |
| 16:13 |
VanessaE |
true, but that wouldn't help the default inv ;) |
| 16:15 |
|
calcul0n_ joined #minetest-dev |
| 16:18 |
p_gimeno |
here's another suggestion: make a paramtype2 that makes param2 select a texture. Imagine e.g. streets mod using an asphalt node; param2=0 means "streets_asphalt.png", param2=1 means streets_asphalt.png^(streets_solid_center_line.png) and so on |
| 16:19 |
p_gimeno |
that would allow making lots of node variations without exploding the number of nodes |
| 16:19 |
VanessaE |
I asked for that a while back |
| 16:19 |
VanessaE |
my idea was rejected. |
| 16:20 |
p_gimeno |
do you have a link? I'd like to see the reasoning behind the rejection |
| 16:21 |
VanessaE |
lemme look |
| 16:26 |
VanessaE |
I can't find the original comment.. |
| 16:27 |
VanessaE |
only found something that referred to it, "no practical use" was the rejection reason |
| 16:27 |
p_gimeno |
o.O |
| 16:28 |
VanessaE |
https://github.com/minetest/minetest/issues/6101#issuecomment-318029777 |
| 16:28 |
VanessaE |
still not the original, but that's the gist of it. |
| 16:29 |
p_gimeno |
thanks |
| 16:29 |
sfan5 |
the question is what is the advantage of this over just registering multiple nodes |
| 16:29 |
sfan5 |
less node IDs being used is one I can think of |
| 16:30 |
VanessaE |
same advantage hardware coloring gives us :) |
| 16:31 |
p_gimeno |
yes, avoiding exploding of node ids. Imagine also if there was a param2 for the mesh, then think circular saw. |
| 16:31 |
VanessaE |
really, we need a few more paramX to do this right :P |
| 16:32 |
VanessaE |
(one for a texture list, one for colors, and the existing one for facedir/rotation) |
| 16:32 |
sfan5 |
how big would you want the texture list to be? |
| 16:32 |
VanessaE |
one byte, so max 256 entries |
| 16:33 |
sfan5 |
do you actually need that many, though? |
| 16:33 |
VanessaE |
no, but you just know that the moment you set a limit, SOMEONE will want to exceed it :P |
| 16:33 |
p_gimeno |
or mixed colours/textures, e.g. 4 bits for each |
| 16:34 |
VanessaE |
no |
| 16:34 |
VanessaE |
lots of colors has uses |
| 16:34 |
VanessaE |
full byte for that,. |
| 16:35 |
VanessaE |
you could perhaps use the upper bits of param2 for a texture list index but then you get the same prob we have now, not enough range for that index. |
| 16:35 |
p_gimeno |
we don't have param3. We have colorfacedir which allows a few colors and a facedir. |
| 16:35 |
VanessaE |
exactly. |
| 16:35 |
VanessaE |
look at how Unified Dyes hacks around the problem |
| 16:36 |
p_gimeno |
what I was suggesting is paramtype2="colortexture" where colour uses 4 bits and texture uses 4 bits |
| 16:36 |
VanessaE |
so 16 textures, 16 colors... |
| 16:37 |
VanessaE |
versus UD's method: nodes that need no facedir get a straight 256 colors, nodes that need a simple X/Z direction exploit wallmounted mode to get 32, and nodes that need full facedir use split palette mode and define 25 copies of the node to get 197 colors |
| 16:39 |
VanessaE |
in other words, subdividing a one-byte field to cram in two features ....is a pain in the ass :) |
| 16:40 |
p_gimeno |
so what you suggest instead? just 256 textures and no colouring option? |
| 16:42 |
VanessaE |
the original proposal was just a texture-list-index equivalent to the three indexed color modes, sharing param2, since no one's willing to add a couple new "paramX" to the map database. So if a node need facedir, you'd have 3 bits of texture index, 5 of rotation. wallmounted would be 5 and 3. no facedir would be all 8 bits for the texture index. |
| 16:44 |
VanessaE |
that would avoid a map format update, at the cost of index range similar to what's now the case with color + rotation. |
| 16:44 |
p_gimeno |
thinking of asphalt in particular, you can have 4 rotations as texture modifiers, you don't need facedir/wallmount |
| 16:44 |
VanessaE |
yes, but we don't have a rotation mode for that. |
| 16:44 |
|
fwhcat joined #minetest-dev |
| 16:45 |
VanessaE |
and you DO need full facedir: asphalt can be cut on the table saw. |
| 16:45 |
VanessaE |
sorry I think we're getting a little confused here.. |
| 16:47 |
p_gimeno |
hm, yeah |
| 16:47 |
p_gimeno |
so 5 facedir + 3 texture bits |
| 16:47 |
VanessaE |
yeah,. |
| 16:47 |
VanessaE |
24 rotations (and some waste), 8 textures. |
| 16:48 |
VanessaE |
that wouldn't cut it, in a real setup :) |
| 16:48 |
p_gimeno |
up to 10 textures if it was not divided into bits, but using mod 24 and div 24 |
| 16:49 |
VanessaE |
think minetest_game + moreblocks, there are WAY more than 8 (or 10) materials (=textures) being cut in just that simple setup |
| 16:49 |
p_gimeno |
what blocks are you thinking about to make into one single node? |
| 16:49 |
VanessaE |
(if I had to guess, there are more like 30 or 40 distinct materials) |
| 16:51 |
VanessaE |
well I figures long term, one might use one base node for all of the different kinds of wood planks/blocks and wood tile patterns, another for stone and stone tiles, another for tree trunks, one for glass and glass-ish, ... |
| 16:51 |
VanessaE |
figured* |
| 16:51 |
VanessaE |
but that would need more than 3 (or 3½) texture index bits, it'd need a whole byte i.e. a param3 |
| 16:54 |
p_gimeno |
I'm not so sure. I think you'd need all those nodes as distinct. Paintable stuff is the main usage I foresee for this feature. |
| 16:55 |
p_gimeno |
I mean, you don't have generic "wood" planks in your inventory when you have acacia planks. It could get messy. |
| 16:59 |
|
Ruslan1 joined #minetest-dev |
| 17:09 |
p_gimeno |
If "dirt_with_grass" weren't in such wide use already, grassing dirt would be another potential use. |
| 18:02 |
VanessaE |
that's what I mean though |
| 18:03 |
VanessaE |
if you have a bunch of wood nodes of different kinds, that are all identical save for texture, wouldn't a texture list be the perfect? of course that does not address the problem of changing the description (but then, if you had a texture list, you could have a description list, too, taken from the same index) |
| 18:04 |
VanessaE |
(of course, then you're only a few steps removed from just having a 32-bit node ID :P ) |
| 18:17 |
p_gimeno |
yeah, I don't think it's really well suited for wood |
| 18:37 |
|
Exe_Virus joined #minetest-dev |
| 18:39 |
|
Owner_ joined #minetest-dev |
| 18:40 |
|
Just_Visiting joined #minetest-dev |
| 18:55 |
|
ssieb joined #minetest-dev |
| 19:03 |
|
ensonic joined #minetest-dev |
| 19:27 |
|
Fritigern joined #minetest-dev |
| 19:29 |
|
Cornelia joined #minetest-dev |
| 19:59 |
|
paramat joined #minetest-dev |
| 20:34 |
paramat |
please can anyone review my mapgen PRs? #8473 #8481 they're well tested so you don't have to. 8473 has a lot of simple and repeated changes so is not as big as it first seems |
| 20:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/8473 -- Dungeons: Settable density noise, move number calculation to mapgens by paramat |
| 20:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/8481 -- Allow multiple cave liquids in a biome definition by paramat |
| 20:48 |
VanessaE |
paramat: re: #6101, did our discussion jar something loose? ;) |
| 20:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/6101 -- Do not use signed integer for registering nodes to allow more than 32768 registered nodes |
| 20:50 |
paramat |
it did, thanks, that shouldn't have been closed |
| 20:51 |
VanessaE |
:) |
| 20:52 |
paramat |
will merge game#2361 later after testing |
| 20:52 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2361 -- Fix trapdoor side texture orientations by paramat |
| 21:40 |
|
Ritchie_ joined #minetest-dev |
| 21:42 |
|
Cornelia joined #minetest-dev |
| 22:07 |
|
ShadowNinja joined #minetest-dev |
| 22:08 |
|
nore joined #minetest-dev |
| 22:08 |
|
Edgy1 joined #minetest-dev |
| 22:23 |
|
Edgy1 joined #minetest-dev |
| 22:48 |
paramat |
merging game#2361 |
| 22:48 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2361 -- Fix trapdoor side texture orientations by paramat |
| 23:06 |
|
ANAND joined #minetest-dev |
| 23:14 |
|
paramat joined #minetest-dev |
| 23:42 |
|
Owner_ joined #minetest-dev |
| 23:55 |
|
AntumD joined #minetest-dev |
