| Time |
Nick |
Message |
| 00:01 |
|
FavoritoHJS joined #minetest |
| 00:02 |
|
FavoritoHJS joined #minetest |
| 00:07 |
Sokomine |
hi. i pulled latest git and compiled. it does seem a bit bright now (before, mt used to be a bit dark). is there any way to get it slightly darker again? preferably something inbetween :-) |
| 00:19 |
FavoritoHJS |
I'm guessing tone mapping got enabled/disabled/changed/whatever between your previous install and your latest commit one. |
| 00:22 |
Sokomine |
thanks! do you have any idea what i might change? |
| 00:25 |
FavoritoHJS |
tone mapping is (afaik) kinda wip, for example, there isn't anything in the settings other than an enable/disable toggle |
| 00:26 |
FavoritoHJS |
actually, what does tone mapping even do? |
| 00:27 |
FavoritoHJS |
I recall darks being black when I enabled it, so I guess it's some gamma correction thing, but how does it work exactly |
| 00:29 |
|
aryak joined #minetest |
| 00:29 |
|
imi joined #minetest |
| 00:29 |
FavoritoHJS |
interesting, the advanced settings say it's "Filmic tone mapping", so I guess that's exactly what it does |
| 00:33 |
|
Verticen_ joined #minetest |
| 00:33 |
FavoritoHJS |
yup, seems like it affects stuff from 364 onwards in client/shaders/object_shader/opengl_fragment.glsl |
| 00:37 |
FavoritoHJS |
interestingly though fog doesn't seem affected, as it's added after the tone map... bug or artistic decision? |
| 00:44 |
MTDiscord |
<Warr1024> IIRC tone mapping stretches contrast at the mid range, while compressing it at the extremes. It basically creates the impression of stretched contrast but without the "clipping" problem that more linear methods have. |
| 00:52 |
|
sparky4 joined #minetest |
| 01:18 |
|
smk joined #minetest |
| 01:24 |
|
lemonzest joined #minetest |
| 01:35 |
Sokomine |
aah. thanks for explaining |
| 02:00 |
|
Lesha_Vel joined #minetest |
| 02:01 |
|
sfhdslkjdshfhdfs joined #minetest |
| 02:25 |
|
rudzik8 joined #minetest |
| 02:33 |
|
rudzik8 joined #minetest |
| 02:36 |
|
rudzik8 joined #minetest |
| 03:26 |
|
Verticen_ joined #minetest |
| 03:49 |
|
stormchaser3000 joined #minetest |
| 03:56 |
|
dridron joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:27 |
|
dridron_ joined #minetest |
| 04:34 |
|
calcul0n_ joined #minetest |
| 04:40 |
|
stormchaser3000 joined #minetest |
| 06:01 |
|
Verticen_ joined #minetest |
| 07:08 |
|
vampirefrog joined #minetest |
| 07:08 |
|
definitelya joined #minetest |
| 07:36 |
|
Talkless joined #minetest |
| 07:50 |
|
jaca122 joined #minetest |
| 07:57 |
|
skunky3 joined #minetest |
| 08:22 |
|
Warr10248 joined #minetest |
| 08:27 |
|
Fixer joined #minetest |
| 08:32 |
|
Fixer joined #minetest |
| 08:40 |
|
YuGiOhJCJ joined #minetest |
| 08:42 |
|
orwell96_ joined #minetest |
| 08:44 |
|
lemonzest joined #minetest |
| 08:53 |
|
dridron joined #minetest |
| 09:03 |
|
Warr1024 joined #minetest |
| 09:17 |
|
appguru joined #minetest |
| 09:18 |
|
Fixer_ joined #minetest |
| 09:57 |
|
robyn joined #minetest |
| 10:06 |
|
Wuzzy joined #minetest |
| 10:17 |
robyn |
ls |
| 10:22 |
|
YuGiOhJCJ joined #minetest |
| 10:36 |
|
robyn joined #minetest |
| 10:41 |
ROllerozxa |
cd ~/.minetest |
| 10:42 |
robyn |
sorry about that, and hello |
| 10:43 |
ROllerozxa |
hi there |
| 10:47 |
ROllerozxa |
Sokomine: From what I can tell, tonemapping has changed slightly now with the postprocessing pipeline |
| 10:51 |
|
Shorp_Tr joined #minetest |
| 11:04 |
|
Shorp_Tr joined #minetest |
| 11:07 |
|
Shorp_Tr3 joined #minetest |
| 11:08 |
|
Shorp_Tr joined #minetest |
| 11:46 |
|
jwmhjwmh joined #minetest |
| 12:07 |
MinetestBot |
[git] Wuzzy2 -> minetest/minetest: DevTest: Explain purpose of most items in tooltips (#12833) c1c6877 https://github.com/minetest/minetest/commit/c1c68775b25314b566a2aae9a304d1b470f5794d (2022-10-09T12:05:22Z) |
| 12:07 |
MinetestBot |
[git] Wuzzy2 -> minetest/minetest: Improve documentation for `liquid_alternative_*` (#12810) b2a3f53 https://github.com/minetest/minetest/commit/b2a3f53b297d4aec37f8272992f8e9b465d43a43 (2022-10-09T12:05:40Z) |
| 12:07 |
MinetestBot |
[git] fluxionary -> minetest/minetest: add an 'equals' method to ItemStack and compatibility w/ lua '==' (#1… 440d966 https://github.com/minetest/minetest/commit/440d966b939059dfa51604eb68d61eecb12baeb4 (2022-10-09T12:06:09Z) |
| 12:13 |
|
kilbith joined #minetest |
| 12:43 |
|
proller joined #minetest |
| 12:59 |
|
Shorp_Tr joined #minetest |
| 13:03 |
|
sagax joined #minetest |
| 13:08 |
|
Thermoriax joined #minetest |
| 13:13 |
|
mrkubax10 joined #minetest |
| 13:21 |
Sokomine |
ROllerozxa: hm. do you have any idea how i may change it to more reasonable lighting? |
| 13:23 |
rubenwardy |
gamma |
| 13:26 |
|
proller joined #minetest |
| 13:31 |
|
___nick___ joined #minetest |
| 13:31 |
|
appguru joined #minetest |
| 13:34 |
|
stormchaser3000 joined #minetest |
| 13:36 |
|
Rafi591 joined #minetest |
| 13:37 |
* Sokomine |
greets rubenwardy and looks puzzled |
| 13:51 |
|
sparky4 joined #minetest |
| 14:03 |
|
Shorp_Tr joined #minetest |
| 14:24 |
|
orwell96 joined #minetest |
| 14:35 |
|
jwmhjwmh joined #minetest |
| 14:41 |
|
kilbith joined #minetest |
| 14:50 |
MinetestBot |
[git] TurkeyMcMac -> minetest/minetest: Optimize lighting calculation (#12797) 9676364 https://github.com/minetest/minetest/commit/9676364c1fe5fe5eae69c55e7d7a45392decfb2d (2022-10-09T14:50:26Z) |
| 14:58 |
sfan5 |
oh hey there's a new one of those crypto servers |
| 15:00 |
ROllerozxa |
that's... quite the amount of players they've got |
| 15:19 |
|
FavoritoHJS joined #minetest |
| 15:20 |
FavoritoHJS |
oh, you mean one of those play to earn servers that _totally_ isn't botting their playercount? |
| 15:23 |
FavoritoHJS |
(for best results, say play to earn with a highly distorted voice a la J. Sterling) |
| 15:26 |
ROllerozxa |
it's almost like a server that pays you in ""cash"" for playtime will end up being filled with players AFKing to game the system |
| 15:45 |
|
bodiccea joined #minetest |
| 15:50 |
|
Desour joined #minetest |
| 16:18 |
|
appguru joined #minetest |
| 16:41 |
|
stormchaser3000 joined #minetest |
| 17:08 |
|
jaca122 joined #minetest |
| 17:09 |
|
sparky4 joined #minetest |
| 17:12 |
sfan5 |
Sokomine: the brightness issue has been fixed |
| 17:13 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Fix tone mapping being always enabled 7a28f2c https://github.com/minetest/minetest/commit/7a28f2c4fa50957a019a8d44856b7aa0cea306eb (2022-10-09T17:11:04Z) |
| 17:13 |
|
Fixer joined #minetest |
| 17:19 |
|
Thermoriax joined #minetest |
| 17:29 |
|
wallabra_ joined #minetest |
| 17:31 |
|
mazes_83 joined #minetest |
| 17:44 |
MinetestBot |
[git] TurkeyMcMac -> minetest/minetest: Remove unused MapBlock functionality 8f996e4 https://github.com/minetest/minetest/commit/8f996e4a7cf7b1fa1ca683cbc37327a790e09ddc (2022-10-09T17:43:48Z) |
| 17:44 |
MinetestBot |
[git] TurkeyMcMac -> minetest/minetest: Embed data directly in mapblocks b3503e7 https://github.com/minetest/minetest/commit/b3503e7853a52a8c16431f6b983e30c9d25951bc (2022-10-09T17:43:48Z) |
| 17:46 |
Sokomine |
sfan5: thanks! |
| 17:49 |
|
Desour joined #minetest |
| 17:50 |
MTDiscord |
<Warr1024> "embed data directly in mapblocks" ... cache hit rate optimization? |
| 17:53 |
Krock |
more like removing a level of indirection |
| 17:54 |
Krock |
could be that it's easier to cache, not sure what's happening with CPU-side optimizations |
| 17:54 |
MTDiscord |
<Warr1024> I guess less indirection is nicer conceptually too, though I figured that you'd save a little cache noise that way too. |
| 17:55 |
MTDiscord |
<Warr1024> it'd be weird if it were like a HUGE improvement, but hopefully it all adds up anyway |
| 17:55 |
jwmhjwmh |
I believe I noticed a small improvement in the lighting benchmark's time with data embedded directly in mapblocks. |
| 17:55 |
MTDiscord |
<Warr1024> Nice. In a mature project, pretty much the only way to make big improvements is to add up small ones. |
| 17:56 |
Desour |
most parts of minetest aren't mature in that regard |
| 18:00 |
Desour |
for caching, shouldn't you have moved that one mapblock on the stack into a unique_ptr, jwmhjwmh? I kinda doubt that pushing 16ki node data on the hot part of the stack is good for caching |
| 18:01 |
Krock |
which stack? |
| 18:02 |
Krock |
can we move this to #- dev? |
| 18:02 |
Desour |
the call stack |
| 18:02 |
Desour |
:O move discussion from #minetest to #minetest-dev ? |
| 18:02 |
Krock |
it's development after all |
| 18:03 |
Krock |
or whatever... I guess it does not matter |
| 18:03 |
Desour |
well, it's just µcro concerns |
| 18:08 |
|
Shorp_Tr joined #minetest |
| 18:15 |
|
Shorp_Tr joined #minetest |
| 18:17 |
MTDiscord |
<luatic> microcro concerns? |
| 18:17 |
Desour |
µ is mü |
| 18:17 |
Desour |
my |
| 18:17 |
Desour |
so µcro is mycro |
| 18:18 |
Desour |
oh, mu in english https://en.wikipedia.org/wiki/Mu_(letter) |
| 18:27 |
|
FavoritoHJS joined #minetest |
| 18:28 |
|
appguru joined #minetest |
| 18:34 |
FavoritoHJS |
why is this shite crypto server at 52 players? that isn't afk numbers, that screams botting |
| 18:37 |
FavoritoHJS |
W00HOO!? ET TU, MY FRIEND!? |
| 18:39 |
FavoritoHJS |
I can only hope he's being impersonated... |
| 18:40 |
MTDiscord |
<luatic> I'm joining to take a look at the player activity |
| 18:42 |
FavoritoHJS |
Are there any rules on the server list? |
| 18:43 |
sfan5 |
no formal ones |
| 18:43 |
MTDiscord |
<luatic> First observation: There do indeed seem to be 52 players on the server. Most are idling (not moving). It's hard to tell whether they are bots or "legit" AFKing players motivated to AFK by fictitious laughable crypto "rewards" which Minetest busywaiting in the background will make up for by driving up their parent's energy bill. |
| 18:43 |
MTDiscord |
<luatic> parents'* |
| 18:44 |
FavoritoHJS |
> no formal ones |
| 18:44 |
FavoritoHJS |
that can't end well... |
| 18:44 |
FavoritoHJS |
goshdarnit I thought that would be sent as one multiline message... DARN YOU KIWIIRC |
| 18:45 |
MTDiscord |
<luatic> FavoritoHJS: propose a rule, sfan5 is on here |
| 18:45 |
MTDiscord |
<luatic> I don't think you could reasonably whack this server with a rule due to what I have outlined above |
| 18:46 |
FavoritoHJS |
I'm not a moderator, I don't know how to make a rule that is useful, general yet not exploitable |
| 18:46 |
MTDiscord |
<luatic> Unless the admins admit to botting you can't tell whether it is botting |
| 18:46 |
MTDiscord |
<luatic> esp. whether it's botting by the admins - otherwise I could have servers penalized simply by botting |
| 18:47 |
ROllerozxa |
I wouldn't be surprised if it's actually real players, just ones who are afking to get free PAWcoins or whatever they're called |
| 18:47 |
FavoritoHJS |
yea, it would make sence it's the whole crypto clown car, that doesn't count as botting |
| 18:48 |
sfan5 |
unrelated to the crypto thing it would be useful if someone spent some time to write down a sane ruleset for the server list |
| 18:57 |
FavoritoHJS |
As obvious as it is, I suggest something like "Servers on the list shall not be meant to hurt others, lest they be delisted"... but to define "be meant" and "hurt others" in a sufficiently clear way, while ensuring that legitimate mistakes don't mean a delist (or worse...) is probably quite complex. |
| 19:00 |
FavoritoHJS |
I do not want rules arbitrary or obscure enough that a 1.19.84-style revolt is even close to a possiblity... then again, having no rules at all will blow up one day, so... |
| 19:11 |
FavoritoHJS |
bug report: fog affects your hand, so if you lower it all the way down to 20 your hand gets covered in fog |
| 19:12 |
Desour |
that's intended, afaik. |
| 19:12 |
Desour |
back when a viewing range of 5 was still possible, I saw this all the time, but stronger |
| 19:14 |
MTDiscord |
<Warr1024> sorta makes sense after all |
| 19:18 |
Oblomov |
yeah, anybody who's been in thick fog knows that's really the case |
| 19:25 |
MTDiscord |
<Warr1024> Re server list rules, the simplest thing to do is start with the empty set, and add rules as problems are discovered. "Attempting to game the system to promote your server may result in demotion, delisting, or other countermeasures." Keep it pretty simple, because you're going to have to use judgement on it anyway. |
| 19:33 |
FavoritoHJS |
the strange thing is that your hand can be in fog, but nodes that are (presumebly) further away aren't. |
| 19:45 |
FavoritoHJS |
can't craft an axe "backwards", and it's screwing with my muscle memory, send help |
| 19:46 |
MTDiscord |
<Jonathon> visit contentdb, there is a mod for that |
| 19:46 |
MTDiscord |
<Jonathon> https://content.minetest.net/packages/Hugues%20Ross/mtg_craft_reverser/ |
| 19:48 |
Desour |
if you craft the axe the wrong way, the sharp side is aimed at you, and you'll hurt yourself when using it |
| 19:49 |
|
dabbill joined #minetest |
| 19:49 |
Desour |
luatic: > I don't like the style of it; I want my doc comments to be at the appropriate places (e.g. param comments next to params, return comments next to return statements, function description next to function definitions) |
| 19:49 |
Desour |
you were referring to ldoc, right? |
| 19:49 |
MTDiscord |
<luatic> yes |
| 19:49 |
Desour |
doc comments in ldoc are next to their functions |
| 19:50 |
Desour |
what exactly do you mean with the places? |
| 19:50 |
MTDiscord |
<luatic> https://github.com/TheAlgorithms/Lua/blob/main/src/sorting/insertionsort.lua f.E. |
| 19:51 |
MTDiscord |
<luatic> you can put comments in the parameter list of a function |
| 19:51 |
Desour |
O_o |
| 19:51 |
MTDiscord |
<luatic> and you can put comments in the explist of a return statement |
| 19:51 |
Desour |
that style looks a bit weird to me |
| 19:52 |
MTDiscord |
<luatic> well, I'm probably the only one using it because I'm yet to write a doc generator that recognizes it |
| 19:53 |
Desour |
do you have a tool for converting it to html or similar? |
| 19:53 |
Desour |
ah |
| 19:53 |
Desour |
an advantage of ldoc is that the function doesn't need to actually exist |
| 19:54 |
Desour |
also the doxygen-like style is more common |
| 19:54 |
MTDiscord |
<luatic> it may be, but it reminds me of Java |
| 19:54 |
Desour |
haha |
| 19:54 |
Desour |
that downside |
| 19:55 |
MTDiscord |
<luatic> anyways, gtg |
| 19:56 |
Desour |
bb |
| 19:59 |
|
___nick___ joined #minetest |
| 20:27 |
|
Shorp_Tr joined #minetest |
| 20:37 |
|
ensayia joined #minetest |
| 20:37 |
ensayia |
Is it possible to swap the textures of a node in the world? |
| 20:38 |
MTDiscord |
<Jonathon> no |
| 20:39 |
ensayia |
Is it a planned feature or just something not possible in the engine? Any insight? |
| 20:40 |
|
Shorp_Tr joined #minetest |
| 20:47 |
|
Shorp_Tr joined #minetest |
| 20:48 |
rubenwardy |
ensayia: what are you trying to do? |
| 20:48 |
ensayia |
a simple texture swap on action, like if I want a furnace texture to change when I light it, for example |
| 20:48 |
rubenwardy |
ok, that's done with multiple nodes |
| 20:48 |
rubenwardy |
in MTG, I believe it's default:furnace and default:furnace_on |
| 20:49 |
ensayia |
that's what I currently do, it's just annoying managing the metadata because the furnace is a player-facing object and you have to preserve that metadata across swaps |
| 20:49 |
rubenwardy |
swap_node won't delete meta |
| 20:50 |
MTDiscord |
<Warr1024> IIRC swap_node was originally created specifically because of the furnace :-) |
| 20:51 |
ensayia |
facing is stored in the param2, which 'defaults' to player facing when the item is place down by a player but swap_node does not preserve that behavior as far as I can see |
| 20:51 |
MTDiscord |
<Warr1024> swap node probably swaps the whole node, not just the name |
| 20:51 |
MTDiscord |
<Warr1024> so you take the original node, change the name, and pass that to swap_node |
| 20:52 |
rubenwardy |
local node = minetest.get_node(pos) |
| 20:52 |
rubenwardy |
node.name = newname |
| 20:52 |
rubenwardy |
minetest.swap_node(node) |
| 20:52 |
rubenwardy |
* swap_node(pos, node) |
| 20:53 |
ensayia |
indeed, but the player placing the node does not write the facing value to param2 when it happens, therefore if the node you are swapping it for has "parameter2" set to "facedir" and it placed by swap_node and not a player it doesn't keep the direction it was originally placed in, because the param2 is not written to on player placement |
| 20:54 |
ensayia |
sorry, that last bit was redundant |
| 20:54 |
rubenwardy |
you should make sure that the before and after both use the same param2type |
| 20:54 |
MTDiscord |
<Warr1024> paramtype2 |
| 20:54 |
MTDiscord |
<Warr1024> consistency yay |
| 20:55 |
ensayia |
they do |
| 20:55 |
rubenwardy |
then the param2 will be kept and the rotation won't be changed |
| 20:55 |
rubenwardy |
param2 is how the rotation is stored |
| 20:56 |
rubenwardy |
in order for the player to place and rotate a node, it needs to change param2 |
| 20:56 |
ensayia |
but when 'facedir' rotates the node to face the player that direction isn't saved, it's a function of the property, therefore a node with 'facedir' that was not placed by the player obviously can't face a player and doesn't have the param2 to reference |
| 20:56 |
rubenwardy |
it will be saved - facedir is stored in `node.param2` |
| 20:56 |
rubenwardy |
there's no other way to rotate a node |
| 20:58 |
rubenwardy |
the MTG furnace does the code I wrote: https://github.com/minetest/minetest_game/blob/master/mods/default/furnace.lua#L115 |
| 20:59 |
ensayia |
if swap_node preserves metadata, why is localizing the node table and swapping out the name needed? |
| 20:59 |
rubenwardy |
because metadata is data about the node, not the node itself |
| 21:00 |
rubenwardy |
node contains name, param1, and param2 |
| 21:00 |
rubenwardy |
so getting the node table and only changing name means that you keep param1 and param2 the same |
| 21:00 |
rubenwardy |
swap node is documented as " Set node at position, but don't remove metadata" |
| 21:01 |
ensayia |
Well, that's the way I'm doing things now I was just seeking to understand. What's the hangup with just swapping a texture? |
| 21:01 |
rubenwardy |
the problem with that is where do you store that texture? |
| 21:01 |
rubenwardy |
there's no space in the node data |
| 21:01 |
rubenwardy |
it would need to be in the meta data, but that impacts performance |
| 21:02 |
rubenwardy |
there are long term plans to do something like this, it's called meta set def |
| 21:02 |
ensayia |
I see. I use a texture atlas for most everything so it might be worth it to define mutable atlas coords? |
| 21:06 |
FavoritoHJS |
a friendly reminder that having 64x64 textures in a world where 16x16 textures are the norm just looks weird. |
| 21:54 |
|
YuGiOhJCJ joined #minetest |
| 21:59 |
|
Markow joined #minetest |
| 22:02 |
|
ejm_ joined #minetest |
| 22:17 |
|
Verticen_ joined #minetest |
| 22:37 |
|
panwolfram joined #minetest |
| 23:46 |
|
Lesha_Vel joined #minetest |
| 23:47 |
|
Lesha_Vel joined #minetest |
