| Time |
Nick |
Message |
| 00:05 |
|
turtleman joined #minetest-dev |
| 00:09 |
|
TC02 joined #minetest-dev |
| 00:13 |
red-001 |
I think I managed to create a client that avoids punch damage from other players |
| 00:23 |
rubenwardy |
#4806 #4966 #4969 |
| 00:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/4806 -- Add search to advanced settings by rubenwardy |
| 00:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/4966 -- Use tree to list mods rather than textlist by rubenwardy |
| 00:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/4969 -- Document registered_chatcommands, add def:run() by rubenwardy |
| 00:24 |
|
red-001 joined #minetest-dev |
| 00:27 |
|
red-001 joined #minetest-dev |
| 00:57 |
|
octacian_ joined #minetest-dev |
| 01:01 |
Fixer |
paramat: on heavy modpacks I've seen OOMs due to environment_OnGenerated() from technic-worldgen and darkage mod, any ways to improve this? |
| 01:01 |
Fixer |
lua OOM's |
| 01:03 |
paramat |
yeah probably |
| 01:03 |
paramat |
i now know the 3 memory optimisations for lua mapgens |
| 01:04 |
paramat |
anyway offtopic here |
| 01:04 |
Fixer |
sorry |
| 01:06 |
rubenwardy |
two_steps claims the damage hack is related to tools: https://forum.minetest.net/viewtopic.php?p=244617#p244617 |
| 01:09 |
Shara |
red-oo1's attempts failed. |
| 01:09 |
Shara |
001* |
| 01:09 |
Shara |
So whatever he tried wasn't it. |
| 01:27 |
|
troller joined #minetest-dev |
| 01:56 |
|
Player_2 joined #minetest-dev |
| 02:59 |
garywhite |
Is it just me, or is this two_steps guy trying to taunt the devs now? |
| 03:06 |
|
lhofhansl left #minetest-dev |
| 03:11 |
|
ssieb joined #minetest-dev |
| 03:12 |
sofar |
it's a very young kid I think |
| 03:12 |
sofar |
ignore him as a person, just focus on the technical issues |
| 03:12 |
|
turtleman joined #minetest-dev |
| 03:16 |
|
turtleman joined #minetest-dev |
| 04:03 |
hmmmm |
two_steps on the forums? |
| 04:03 |
hmmmm |
i take it he is the MineHacker guy? |
| 04:05 |
hmmmm |
why are people interested in cheating with minetest? do people actually play it as a competitive game or something? |
| 04:09 |
Shara |
The "kids" think it's "cool". |
| 04:10 |
Shara |
I was watched players actually begging for hacked clients on one of the servers where this thing was demonstrated. |
| 04:11 |
Shara |
I have* |
| 04:20 |
|
troller joined #minetest-dev |
| 04:22 |
|
Hunterz joined #minetest-dev |
| 04:26 |
hmmmm |
hmmm |
| 04:26 |
hmmmm |
people on the forum are saying that if you purchase a copy of minehacker, you are entitled to a copy of its source code |
| 04:28 |
hmmmm |
these are indeed one option of distribution according to the GNU GPL v3, but not so much the LGPL v2.1... |
| 04:28 |
hmmmm |
if you read here https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html you'll notice that Minehacker would need to comply with either term 1 or term 2 under Terms and Conditions for Copying, Distribution, and Modification |
| 04:29 |
hmmmm |
sorry, terms 2 or 3 |
| 04:29 |
hmmmm |
term 2 clause c mandates that the whole work must be licensed at no charge to all third parties |
| 04:30 |
hmmmm |
term 3 is an option to convert the source to GPL v2, but in order for this to apply, the author needs to supply the GPL license notification, not the LGPL license notification |
| 04:31 |
hmmmm |
i don't think he's smart enough to have read this so Minehacker is likely to be noncompliant |
| 04:36 |
hmmmm |
mmm nevermind that, term 4 overrides everything. he doesn't need to do anything special it seems, just distribute source at the same location as the object form at no extra charge. |
| 04:36 |
hmmmm |
disregard my rambling :p |
| 04:59 |
|
Tmanyo joined #minetest-dev |
| 05:13 |
|
lordfingle joined #minetest-dev |
| 06:01 |
|
Zeno` joined #minetest-dev |
| 06:12 |
|
nrzkt joined #minetest-dev |
| 06:12 |
|
Hunterz joined #minetest-dev |
| 06:29 |
Zeno` |
I see paramat is still on his campaign to break game mechanics |
| 06:41 |
|
nrzkt joined #minetest-dev |
| 06:44 |
|
lumidify joined #minetest-dev |
| 07:08 |
|
lhofhansl joined #minetest-dev |
| 07:30 |
hmmmm |
how so? |
| 07:31 |
Zeno` |
changing how saplings grow |
| 07:31 |
Zeno` |
(reduced light levels -- actual light levels, not display light levels) |
| 07:32 |
hmmmm |
well there's nothing necessarily wrong with that |
| 07:32 |
hmmmm |
it's just making it easier to grow underground |
| 07:32 |
Zeno` |
makes it harder |
| 07:32 |
hmmmm |
reduced light levels needed to grow saplings? |
| 07:33 |
Zeno` |
"normal" light levels are needed to grow sapling |
| 07:33 |
hmmmm |
really? |
| 07:33 |
hmmmm |
ugh |
| 07:33 |
hmmmm |
i thought you said reduced light levels tho |
| 07:33 |
Zeno` |
he wants to reduce them |
| 07:33 |
Zeno` |
make torches darker |
| 07:33 |
hmmmm |
torches darker!??! |
| 07:33 |
Zeno` |
yes |
| 07:33 |
hmmmm |
you mean they weren't dark enough |
| 07:34 |
hmmmm |
we already need 5000000000000000000000 torches to light up anything indoors |
| 07:34 |
Zeno` |
i know |
| 07:34 |
hmmmm |
i disapprove of that change whichever one it is |
| 07:34 |
Zeno` |
but by making torches darker all those underground forests that players make impossible (and there are a lot of them) |
| 07:34 |
Zeno` |
https://github.com/minetest/minetest_game/issues/1476 |
| 07:35 |
hmmmm |
yeah, i made them often to mine wood when i'm doing a deep underground mining operation |
| 07:35 |
hmmmm |
gotta make lotsa ladders yknow? |
| 07:35 |
Zeno` |
yes, that's what we used them for when we dug to the centre of the world |
| 07:35 |
Zeno` |
we *needed* them |
| 07:35 |
Zeno` |
for ladders, new torches etc etc |
| 07:35 |
Zeno` |
otherwise it would have been impossible |
| 07:35 |
Zeno` |
forgetting about the fact that underground forests look cool |
| 07:39 |
Zeno` |
I remember now why my original gamma changes had an "adjustment table" |
| 07:40 |
Zeno` |
it was to stop the exceedingly bright higher light levels and IIRC, and this is ironic, it may have been paramat who insisted upon it lol |
| 07:40 |
Zeno` |
I don't mind "display values" being changed |
| 07:41 |
Zeno` |
but changes that break game mechanics... hmm |
| 07:41 |
hmmmm |
sofar just did something with the gamma |
| 07:41 |
hmmmm |
he said your changes were stupid and made no sense |
| 07:42 |
Zeno` |
correct |
| 07:42 |
hmmmm |
correct about your changes being stupid and making no sense? :P |
| 07:42 |
Zeno` |
but those only change "display" levels not the 0-15 light level used internally |
| 07:43 |
Zeno` |
well, I had an adjustment table so that the display levels at the default gamma remained the same as before gamma was changed, because people asked for it |
| 07:43 |
Zeno` |
I also didn't invert gamma (which was stupid) |
| 07:44 |
Zeno` |
but the adjustment table was just to keep people happy... it was never really needed |
| 07:46 |
Zeno` |
I'd rather see the adjustment table put back to deal with things rather than breaking the game |
| 07:46 |
Zeno` |
sofar's other change is ok |
| 07:47 |
Zeno` |
basically it's inputLevel (0-15) --> linear --> apply gamma correction --> apply adjustment/tweaks == display light level |
| 07:47 |
Zeno` |
sofar removed the apply adjustment table |
| 07:48 |
Zeno` |
he also changed how gamma correction was calculated (but that doesn't matter) |
| 07:49 |
Zeno` |
linear is the linear light level of course |
| 07:51 |
Zeno` |
this generates a lookup table, so performance doesn't matter |
| 07:59 |
sofar |
the whole word gamma is irrelevant and wrongly used in that table :) |
| 07:59 |
sofar |
all that matters is the end result IMHO |
| 08:00 |
sofar |
I could care less how light is calculated as long as it's consistent |
| 08:01 |
Zeno` |
yes, that's right |
| 08:01 |
Zeno` |
I am suggesting now that the adjustment table be put back instead of breaking game mechanics |
| 08:01 |
Zeno` |
https://github.com/minetest/minetest_game/issues/1476 |
| 08:08 |
|
lhofhansl left #minetest-dev |
| 08:14 |
|
emptty joined #minetest-dev |
| 08:39 |
|
YuGiOhJCJ joined #minetest-dev |
| 08:41 |
|
lumidify joined #minetest-dev |
| 08:46 |
|
Ritchie_ joined #minetest-dev |
| 09:30 |
|
Thomas-S joined #minetest-dev |
| 09:37 |
|
DFeniks joined #minetest-dev |
| 09:50 |
|
proller__ joined #minetest-dev |
| 10:40 |
|
Krock joined #minetest-dev |
| 10:40 |
|
Krock joined #minetest-dev |
| 10:49 |
|
emptty joined #minetest-dev |
| 11:01 |
|
Darcidride joined #minetest-dev |
| 11:08 |
|
proller joined #minetest-dev |
| 11:10 |
|
proller__ joined #minetest-dev |
| 11:21 |
|
red-001 joined #minetest-dev |
| 11:33 |
|
red-001 joined #minetest-dev |
| 11:48 |
|
juhdanad joined #minetest-dev |
| 11:51 |
juhdanad |
Shara do you have access to the server where MineHacker was demonstrated? Debug.txt would be useful. |
| 11:51 |
juhdanad |
For example: did the player punch itself? |
| 11:52 |
|
emptty joined #minetest-dev |
| 11:59 |
|
troller joined #minetest-dev |
| 12:19 |
|
Fixer joined #minetest-dev |
| 12:22 |
|
troller joined #minetest-dev |
| 12:36 |
Shara |
juhdanad: The owner of ESP CTF dislikes keeping logs. I did ask him to make them while this is going on, so can check what he has. Problem is, I don't know if the no damage hack was tested there or elsewhere. |
| 12:37 |
juhdanad |
Okay, thanks anyways. |
| 12:37 |
Shara |
Could you confirm which server it was tested on? |
| 12:37 |
juhdanad |
No, I did not see this in action. |
| 12:37 |
Shara |
I know two_steps is back and fore that server, so it might be there. |
| 12:40 |
|
Fritigern joined #minetest-dev |
| 13:02 |
|
emptty joined #minetest-dev |
| 13:16 |
|
lumidify joined #minetest-dev |
| 13:28 |
|
troller joined #minetest-dev |
| 13:35 |
|
red-001 joined #minetest-dev |
| 13:38 |
|
Fritigern joined #minetest-dev |
| 13:39 |
|
zorman2000 joined #minetest-dev |
| 13:50 |
|
red-001 joined #minetest-dev |
| 14:15 |
|
STHGOM joined #minetest-dev |
| 14:33 |
|
turtleman joined #minetest-dev |
| 14:36 |
|
lumidify joined #minetest-dev |
| 14:41 |
|
emptty joined #minetest-dev |
| 15:06 |
|
Hunterz joined #minetest-dev |
| 15:18 |
|
octacian joined #minetest-dev |
| 15:37 |
|
STHGOM joined #minetest-dev |
| 15:41 |
|
Darcidride joined #minetest-dev |
| 15:51 |
|
red-001 joined #minetest-dev |
| 15:54 |
|
troller joined #minetest-dev |
| 15:56 |
|
rubenwardy joined #minetest-dev |
| 15:59 |
|
blaze joined #minetest-dev |
| 16:03 |
|
emptty joined #minetest-dev |
| 16:31 |
|
STHGOM joined #minetest-dev |
| 17:00 |
garywhite |
Hang on...did anyone notice that for this hacked client that he copyrighted the website? |
| 17:01 |
Calinou |
garywhite: copyright is something anyone can claim, there's no registration process most of the time |
| 17:01 |
garywhite |
ohh ok |
| 17:03 |
|
turtleman joined #minetest-dev |
| 17:06 |
|
KrimZon_2 joined #minetest-dev |
| 17:07 |
|
AcidNinjaFWHR joined #minetest-dev |
| 17:17 |
sfan5 |
garywhite: he made the website he can claim copyright |
| 17:17 |
sfan5 |
also keep non-dev related stuff to #minetest |
| 17:22 |
KrimZon_2 |
sfan5: does dev stuff include mods? |
| 17:23 |
|
paramat joined #minetest-dev |
| 17:25 |
|
emptty joined #minetest-dev |
| 17:26 |
|
KrimZon_2 left #minetest-dev |
| 17:29 |
|
red-001 joined #minetest-dev |
| 17:35 |
paramat |
~tell hmmmm everything zeno said to you last night about me and light levels was untrue, please read https://github.com/minetest/minetest/pull/4873#issuecomment-266915098 onwards. even with a lower light level value, torches will actually be visually brighter with my game PR because of recent engine lighting changes, the change will not affect growing stuff at all, torches have never been bright enough to grow any |
| 17:35 |
paramat |
thing |
| 17:35 |
ShadowBot |
paramat: O.K. |
| 17:43 |
paramat |
nore sfan5 ShadowNinja sofar any comments on game#1472 game#1475 ? |
| 17:43 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1472 -- Papyrus, Cactus: Only make them grow in bright places by SmallJoker |
| 17:43 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1475 -- Blob ore: Add sand blobs throughout underground by paramat |
| 17:45 |
paramat |
~tell hmmmm torches have been unable to grow saplings for over a year, i'm making no changes to that |
| 17:45 |
ShadowBot |
paramat: O.K. |
| 17:52 |
ShadowNinja |
paramat: First: fine, Second: do you find sand at great depths IRL? If so, good, otherwise maybe not. |
| 17:52 |
paramat |
sofar, problem is, if we keep torch light level unchanged it now looks too bright, as does fire and lava |
| 17:52 |
paramat |
ok. i'll research underground sand |
| 17:54 |
|
juhdanad joined #minetest-dev |
| 18:00 |
|
TC02 joined #minetest-dev |
| 18:01 |
|
hmmmm joined #minetest-dev |
| 18:07 |
Fixer |
paramat: could be interesting for you https://github.com/minetest-mods/moretrees/issues/32 |
| 18:09 |
|
blaze joined #minetest-dev |
| 18:10 |
|
Hunterz joined #minetest-dev |
| 18:10 |
paramat |
saw that :] |
| 18:12 |
juhdanad |
Oh, I have seen a bug with moretrees too, when a mapblock was erased from a tree. |
| 18:19 |
Fixer |
can you build official non-luajit build for heavy modpacks? For technic, dreambuilder, worldedit work? |
| 18:19 |
Calinou |
it should be hidden because most people won't benefit from a non-LuaJIT build, but rather will be hurt by it |
| 18:20 |
Fixer |
technic, dreambuilder, darkage is not usable with luajit right now :( |
| 18:20 |
Fixer |
on my setup |
| 18:27 |
sfan5 |
Fixer: https://kitsunemimi.pw/tmp/minetest-0.4.15-noluajit-win64.7z |
| 18:27 |
sfan5 |
built this earlier but you weren't here |
| 18:27 |
Fixer |
sfan5: oh, thanks a lot, please publish this link on your page, can I also post it in technic and dreambuilder topics? |
| 18:27 |
sfan5 |
except the updated gettext it (and obviously missing luajit) it is built identically to the release |
| 18:28 |
sfan5 |
sure |
| 18:28 |
paramat |
nice, lots of players are getting OOM errors |
| 18:28 |
|
red-003 joined #minetest-dev |
| 18:28 |
|
red-003 joined #minetest-dev |
| 18:28 |
Fixer |
paramat: i've posted your opimisation topic to darkage and technic githubs, maybe someone will look into it |
| 18:29 |
Fixer |
paramat: and it is this damn OnGenerated OOM :/ |
| 18:29 |
paramat |
ok, those mods could just use core oregen instead, another alternative |
| 18:30 |
Fixer |
why not? it is good alternative to me |
| 18:30 |
paramat |
we have a few new types now |
| 18:30 |
paramat |
well just for speed and less memory use |
| 18:30 |
paramat |
but those optimisations should be tried first |
| 18:31 |
Fixer |
most people use luajit one and they will have bad experience with darkage, technic, dreambuilder, etc |
| 18:31 |
Fixer |
i suspect |
| 18:35 |
|
octacian_ joined #minetest-dev |
| 18:35 |
hmmmm |
i like sofar's new light decay curve so much better |
| 18:40 |
hmmmm |
paramat: i just looked over the PR and it is exactly as Zeno said |
| 18:40 |
paramat |
nope |
| 18:40 |
hmmmm |
underground forests are broken |
| 18:40 |
paramat |
that was done over a year ago |
| 18:41 |
Fixer |
you can use MESE lamp |
| 18:41 |
hmmmm |
i haven't updated my minetest_game in over a year so i didn't notice |
| 18:41 |
hmmmm |
yes, now i see the dates |
| 18:41 |
hmmmm |
but that did break things when it happened, you cannot possibly deny that |
| 18:42 |
paramat |
saplings were missing a lighting check, all other plants have always required something brighter than a torch |
| 18:42 |
hmmmm |
okay, perhaps so |
| 18:43 |
paramat |
so yes, but it was a bug and an inconsistency |
| 18:43 |
hmmmm |
but are you saying that the game mechanics did not change? |
| 18:43 |
hmmmm |
because the game mechanics changed |
| 18:43 |
paramat |
yeah i agree |
| 18:43 |
hmmmm |
so you're going to upset at least some users |
| 18:43 |
paramat |
but bugfixees will always irritate those who got used to them |
| 18:44 |
paramat |
we made the sapling 'can grow' function global to be overridable |
| 18:44 |
hmmmm |
and what was your stance on the elevator issue? |
| 18:45 |
paramat |
and we added meselamp so that default game now has a growlamp |
| 18:45 |
paramat |
hm elevator? |
| 18:45 |
VanessaE |
an UGLY growlamp |
| 18:45 |
hmmmm |
you add the blocks in a spiral pattern upward and then to go up you crouch a certain way, i'm not sure what it's called |
| 18:46 |
paramat |
we could add a pretty mese torch |
| 18:46 |
VanessaE |
(sorry. it's a big, honking cube that just looks like shit when you're trying to use it for that kind of lighting) |
| 18:46 |
hmmmm |
pretty mese torch or not |
| 18:46 |
paramat |
ah sneak elevator |
| 18:46 |
hmmmm |
the requirement you use mese now just to grow a source of wood does break peoples gameplay |
| 18:46 |
hmmmm |
mese is much rarer than torches |
| 18:46 |
VanessaE |
hmmmm: you hold space and sneak at the same time, btw. |
| 18:47 |
paramat |
i don't really have an opinion yet on sneak elevator |
| 18:47 |
hmmmm |
now deep mining operations are basically impossible |
| 18:47 |
paramat |
mese ore is not rare, meseblock is |
| 18:47 |
hmmmm |
well, there's an example of something technically a bug that was used extensively now |
| 18:47 |
hmmmm |
but how deep does mese block start at? |
| 18:47 |
VanessaE |
1024, unless it changed. |
| 18:48 |
hmmmm |
exactly |
| 18:48 |
paramat |
mese ore 64, meseblock 1024 |
| 18:48 |
hmmmm |
oh |
| 18:48 |
hmmmm |
still a lot though |
| 18:48 |
paramat |
meselamp uses mese crystal |
| 18:48 |
hmmmm |
mese ore is rare at 64 |
| 18:48 |
hmmmm |
it's not like coal or something |
| 18:48 |
paramat |
a little yeah |
| 18:48 |
hmmmm |
so are you going to accept that your change did break gameplay? |
| 18:49 |
paramat |
we could make the meselamp recipe more generous |
| 18:49 |
VanessaE |
the mese lamp should have looked like some kind of actual lamp. that's all. |
| 18:50 |
paramat |
yes, not being able to (unreasonably and inconsistently) grow saplings in darkness did break gameplay |
| 18:50 |
hmmmm |
did you advertise that fact when you made the PR? |
| 18:50 |
hmmmm |
i'm willing to bet a lot of opinions would've changed |
| 18:51 |
paramat |
i have a PR in game to make sand blobs deep underground so that meselamps can be crafted easier |
| 18:51 |
paramat |
see the links i posted, i made an issue first asking if it was reasonable |
| 18:52 |
paramat |
https://github.com/minetest/minetest/pull/4873#issuecomment-269340876 |
| 18:53 |
paramat |
eventually 3 weeks later 2 pople complained |
| 18:54 |
hmmmm |
sigh |
| 18:54 |
hmmmm |
well if everybody likes it then so be it |
| 18:55 |
hmmmm |
but this does break something i personally liked to do |
| 18:55 |
VanessaE |
the problem with that, paramat, is that complaints that matter won't usually come through github |
| 18:55 |
VanessaE |
(by "that matter", I mean from your average Joe user) |
| 18:55 |
paramat |
anyway, i'm happy to make meselamps easier to craft, and to add new types of mese light |
| 18:56 |
Shara |
New types would be welcome, if they are not ugly cubes :) |
| 18:56 |
paramat |
hmmmmm you can use meselamps, torches have never been bright enough to grow anything |
| 18:56 |
paramat |
sure i can add a mese torch |
| 18:56 |
VanessaE |
except mushrooms. |
| 18:56 |
paramat |
heh |
| 18:57 |
hmmmm |
torches are going to be made darker |
| 18:57 |
garywhite |
hmmmm: I've actually built an underground farm with meselamps, it just doesn't grow too well |
| 18:57 |
paramat |
nope, they will be visually brighter |
| 18:57 |
hmmmm |
yeah paramat, i am sorry. everything that zeno said is 100% true |
| 18:57 |
hmmmm |
no matter how you try to spin it, these are the facts |
| 18:58 |
hmmmm |
now we're losing range on the torches |
| 18:58 |
paramat |
that's true |
| 18:58 |
hmmmm |
as if a spread of 14 wasn't bad enough |
| 18:58 |
paramat |
and a concern |
| 18:58 |
hmmmm |
the lighting model needs to be fundamentally improved |
| 18:58 |
VanessaE |
hmmmm: I doubt that'll be possible until the map format changes |
| 18:58 |
hmmmm |
right now gameplay decisions are being held hostage |
| 18:58 |
VanessaE |
4 bytes per node is...kinda limiting. |
| 18:59 |
hmmmm |
no... 4 bytes per node is not limiting |
| 18:59 |
paramat |
zeno gave the impression torches will be visually darker, which is the impression you got |
| 18:59 |
hmmmm |
4 bits per light level is horrible |
| 18:59 |
VanessaE |
yeah |
| 18:59 |
VanessaE |
and where will the extra bits come from? |
| 18:59 |
VanessaE |
there's nothing left to steal |
| 18:59 |
hmmmm |
nonsense |
| 18:59 |
hmmmm |
we can do without the night bank |
| 18:59 |
paramat |
"Zeno`:changing how saplings grow" not true |
| 18:59 |
hmmmm |
i've never seen a single mod actually make use of that |
| 19:00 |
VanessaE |
hm |
| 19:00 |
VanessaE |
I was under the impression that the night bank was more for rendering purposes |
| 19:00 |
VanessaE |
(after a fashion) |
| 19:01 |
VanessaE |
that still leaves the problem of interpreting the value - a new map format (well, new version) will be needed. |
| 19:01 |
hmmmm |
obviously |
| 19:01 |
hmmmm |
this bumps the mapblock serialization version |
| 19:01 |
paramat |
"Zeno`: but by making torches darker all those underground forests that players make impossible" not true, this was done a year ago |
| 19:01 |
VanessaE |
right |
| 19:02 |
hmmmm |
so |
| 19:02 |
hmmmm |
right off what you could do is modify the light bank concept |
| 19:02 |
hmmmm |
from 4-4 it could be 1-7 |
| 19:02 |
VanessaE |
1? |
| 19:03 |
hmmmm |
1 bit for the night bank, 7 for day |
| 19:03 |
VanessaE |
hm |
| 19:03 |
hmmmm |
the 1 bit will be a boolean meaning |
| 19:03 |
ShadowNinja |
Note that we'll also have to either break the Lua API or use 0-15 floating point light values if we add more bits to light. |
| 19:03 |
hmmmm |
"this light comes from a light source, keep the light value constant with daytime" |
| 19:03 |
hmmmm |
ShadowNinja an emulation mode can be added |
| 19:04 |
VanessaE |
hmmmm: that's not a bad idea. |
| 19:04 |
hmmmm |
in general this would be a huge gamechanger |
| 19:04 |
ShadowNinja |
(Or leave the API as is and only allow 15 values) |
| 19:04 |
hmmmm |
and again |
| 19:04 |
hmmmm |
that's only one option |
| 19:04 |
hmmmm |
having 128 possible light levels is very liberating |
| 19:04 |
hmmmm |
but we can go further |
| 19:04 |
hmmmm |
remember the meta get nodedef PR |
| 19:05 |
hmmmm |
it's not an unprecedented idea to use nodedef while rendering blocks |
| 19:05 |
hmmmm |
if it's fast enough, you can completely do without that 1 bit night bank |
| 19:06 |
hmmmm |
and keep comparing ndef->get(foobar).is_light_source |
| 19:06 |
paramat |
"Zeno` makes it harder" (to grow things underground) this was done a year ago |
| 19:06 |
ShadowNinja |
We could also do something like 0x1FF = 15 = 255 light, or have a separate field such as light_v2. I suppose that's a fairly minor point compared to everything else that will have to be done though. |
| 19:06 |
hmmmm |
0x1FF?? |
| 19:07 |
hmmmm |
i dunno |
| 19:07 |
paramat |
"Zeno`: he wants to reduce them, make torches darker" they will be visually brighter than in 0.4.15 |
| 19:07 |
VanessaE |
paramat: there's one other caveat to that ^^ |
| 19:07 |
hmmmm |
but anyway this is a change to lighting that helps a LOT and it's quite conceptually simple |
| 19:07 |
ShadowNinja |
hmmmm: Yeah, it's odd, plenty of other optios if we don't want that. |
| 19:07 |
hmmmm |
but there are tons of changes |
| 19:08 |
hmmmm |
there's going to be tons of changes no matter how you do this |
| 19:08 |
paramat |
hmmmmm zeno was talking about stuff done a year ago and confusing that with current changes, you misunderstand |
| 19:08 |
hmmmm |
the lighting model wasn't made very abstract |
| 19:08 |
hmmmm |
paramat: i've moved on from that topic |
| 19:08 |
VanessaE |
actually strike that last statement |
| 19:09 |
VanessaE |
(I was about to remind of an old trick that's no longer relevant) |
| 19:09 |
hmmmm |
i'd like to make it so that reducing the light level produced by a torch to 13 isn't horrible to begin with |
| 19:09 |
VanessaE |
hmmmm: I presume with 7-bit light values, we'd also get much wider spread? |
| 19:09 |
hmmmm |
vanessae: that's the primary benefit |
| 19:10 |
VanessaE |
just making sure. |
| 19:10 |
hmmmm |
so |
| 19:10 |
VanessaE |
a lot of people love to conflate range with resolution (not saying you do) |
| 19:10 |
hmmmm |
to summarize: |
| 19:10 |
hmmmm |
right now we're at 4:4 |
| 19:10 |
hmmmm |
we can reasonably change this to 7:1 or even 8:0 |
| 19:11 |
hmmmm |
further if i implement the model where light data is separated from mapblocks |
| 19:11 |
hmmmm |
we can do even better |
| 19:12 |
hmmmm |
i still want truecolor lighting, and we can realize a savings of ~3.5 KB per block at the same time by storing only light at the borders of the mapblocks |
| 19:12 |
|
lumidify joined #minetest-dev |
| 19:12 |
hmmmm |
in reality we'd be spending 488 bytes more per block, but have a totally free 8 bits to do something else with |
| 19:13 |
paramat |
is not light range limited by mapblock size? ie any light update only requires changes within 16 nodes, larger range means much more intensive light updates |
| 19:14 |
VanessaE |
I'd love to have truecolor lights; ilights mod, homedecor's lighting, stained glass mod, probably many others would benefit greatly. |
| 19:16 |
VanessaE |
paramat: if that were such a big deal, I'd be more concerned with the number of nodes that have to be updated (>51k versus ~800) rather than number of affected mapblocks. |
| 19:16 |
VanessaE |
but it's not like players are sitting there adding/removing lights a dozen times a second or something, so is that really that big a concern? |
| 19:16 |
paramat |
yeah that's what i mean |
| 19:17 |
paramat |
well processing grows by the cube of light range |
| 19:17 |
paramat |
and it's already quite heavy |
| 19:18 |
paramat |
even range 32 would be excellent |
| 19:19 |
sofar |
if you want to modify the light bank bits, don't put all 7 bits into (light+range) like it is now |
| 19:19 |
sofar |
since light level and range are the same thing, which is the core of the problem |
| 19:19 |
sofar |
what you want is some bits for range, and some for light level |
| 19:20 |
VanessaE |
hm, forgot to consider 3 dimensions. 6.5M versus 12.8k, though the worse-case would be half of that since you can't cast light through a solid, opaque object |
| 19:20 |
VanessaE |
worst* |
| 19:20 |
sofar |
e.g. keep 3 bits for light level, and add 4 bits for range |
| 19:20 |
hmmmm |
mapblock size and light range are coincidental |
| 19:21 |
VanessaE |
sofar: in reality, light level and range are synonymous anyway, assuming the same projection type |
| 19:21 |
hmmmm |
sofar, the problem is that you're describing a light by strength + range only works for defining light sources |
| 19:22 |
hmmmm |
i'm talking about the data stored in the mapnode that gets used *on render* |
| 19:22 |
|
octacian joined #minetest-dev |
| 19:22 |
hmmmm |
on render we don't have time to know all about that stuff, we just know that node XYZ gets rendered with shade W |
| 19:23 |
ShadowNinja |
If you're breaking the serialization format you might also want to look at #3946. |
| 19:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/3946 -- Improved block serialization format |
| 19:24 |
Fixer |
sneak elevator bug also has big problem - you avoid damage everywhere on any slopes, and you can avoid damage on flat ground too |
| 19:24 |
|
ssieb joined #minetest-dev |
| 19:25 |
VanessaE |
sneak elevators should be easy to keep support for while fixing the damage issue, if the engine were to check for the common sneak elevator node pattern while dealing witha jump action |
| 19:26 |
VanessaE |
(turn jump into 'climb up' if the pattern supports the notion) |
| 19:39 |
Fixer |
this is weird, Dreambuilder works nice for Vanessa on luajit + linux, but works like 10 min for me in windows before OOM crash |
| 19:40 |
Fixer |
i've started to google and found this: http://www.xsquawkbox.net/xpsdk/mediawiki/LuaJIT (xplane also uses luajit for plugin), it may be useful to you? |
| 19:47 |
hmmmm |
no this is just a far out there idea |
| 19:47 |
hmmmm |
if you want to actually improve lighting, this is how it's done |
| 19:47 |
hmmmm |
i gotta do biome shit first |
| 20:07 |
Fixer |
hmmmm: i have seen a guy on Just Test 1 and 2 that advertised and used his hacks on other people, he told me that he is doing this for fun, he ruined our fun though |
| 20:08 |
Fixer |
he said he had lots of hacks for the game |
| 20:08 |
Fixer |
he is from USA iirc |
| 20:08 |
garywhite |
Fixer: What's his name? |
| 20:08 |
Fixer |
gold_digger |
| 20:09 |
garywhite |
oh ok, I think I remember him |
| 20:14 |
|
juhdanad joined #minetest-dev |
| 20:15 |
hmmmm |
not too interesting on "seeing a guy" |
| 20:15 |
hmmmm |
unless it's an actual violation of the LGPL v2.1 |
| 20:16 |
juhdanad |
hmmmm: 7+1 bits for the lighting is not enough: imagine a mese lamp in a sunlit cave. |
| 20:16 |
hmmmm |
imagining it... |
| 20:17 |
VanessaE |
one thing to consider, by the way: |
| 20:17 |
juhdanad |
there is half sunlight and full night light. |
| 20:17 |
juhdanad |
When it is night, the mese lamp could only produce half of its light. |
| 20:17 |
VanessaE |
there are light sources in real life that appear brighter (locally) than the sun itself. I think magnesium does, for example. Might be worth considering. |
| 20:17 |
hmmmm |
what do you mean |
| 20:18 |
hmmmm |
why is the mese lamp not able to produce its full range any less than it can at the present |
| 20:18 |
juhdanad |
Because there's nowhere to store the lamp's light. There's only one bit. |
| 20:19 |
hmmmm |
vanessae, fair enough, when you have 128 levels it's not really a problem making the sun level 120 or something |
| 20:19 |
hmmmm |
what are you talking about? what about the 7 bits? |
| 20:19 |
juhdanad |
What would you like to store in the 7 bits? |
| 20:20 |
hmmmm |
light values |
| 20:20 |
juhdanad |
But you can store there either night or day light. |
| 20:20 |
hmmmm |
i already said the distinction between night and day light is dumb and is not needed |
| 20:20 |
juhdanad |
Oh, I see! |
| 20:21 |
hmmmm |
the whole idea is to steal 3 bits from the night light to give to the day light |
| 20:21 |
hmmmm |
the 4 bit night bank now becomes a 1 bit boolean "is artificial light source" |
| 20:21 |
hmmmm |
if true then it stays lit when rendering during night |
| 20:21 |
hmmmm |
and also gets rendered with the yellow tint |
| 20:22 |
|
DFeniks joined #minetest-dev |
| 20:22 |
juhdanad |
But then given an air node which has full day night and a dimmer artifical light source would be at max light level at night too! |
| 20:23 |
hmmmm |
yeah that's true |
| 20:23 |
hmmmm |
that's the hole in the theory i was looking for |
| 20:23 |
hmmmm |
i knew my idea was too good to be true |
| 20:23 |
juhdanad |
So the problem is that sunlight and artifical light are independent. |
| 20:24 |
juhdanad |
You have to know them both. |
| 20:24 |
juhdanad |
Same for color components. |
| 20:24 |
rubenwardy |
there;s still the idea of storing light levels at chunk borders then relighting during emerge |
| 20:24 |
hmmmm |
I mean |
| 20:24 |
hmmmm |
each light bank is logically its own light source |
| 20:25 |
juhdanad |
I think the problem here is not with disk space; but with RAM. |
| 20:25 |
hmmmm |
right now it's not configured as such |
| 20:25 |
hmmmm |
but you can think of the day bank being "the light produced from the sunlight source" |
| 20:25 |
hmmmm |
and the night bank is "the light produced from all other sources" |
| 20:26 |
hmmmm |
logically, you should be able to turn on or off each logical combination of these light sources |
| 20:26 |
juhdanad |
Yes, light is cached for each node to speed up mesh generation and lighting queries for mods. |
| 20:26 |
hmmmm |
day bank on, night bank off, night bank on, day bank off, night and day on |
| 20:26 |
hmmmm |
etc. |
| 20:26 |
hmmmm |
hmmm |
| 20:27 |
hmmmm |
maybe there might be a workaround for this problem, i have to think more |
| 20:29 |
juhdanad |
hmmm: what about another approach, where nodes store the direction they get their light from? |
| 20:29 |
juhdanad |
This would be recursive, but 3 bits are enough for a light bank. |
| 20:30 |
hmmmm |
which would require backtracking |
| 20:30 |
juhdanad |
And it would be slower, but the light sources' range would be unlimited. |
| 20:30 |
hmmmm |
due to the recursive algorithm the areas where light fades out wouldn't have a well defined light vector |
| 20:30 |
hmmmm |
well |
| 20:31 |
hmmmm |
rubenwardy mentioned my other idea |
| 20:31 |
hmmmm |
for the truecolor lighting |
| 20:31 |
hmmmm |
it's similar to that |
| 20:31 |
hmmmm |
stored separate from the mapnode would be a plane covering each border of a mapblock that contains lighting info |
| 20:31 |
hmmmm |
so say the edge of the block has light with a value of 14 |
| 20:32 |
hmmmm |
you just communicate that and no other lighting for the individual nodes |
| 20:32 |
hmmmm |
the effective per-node lighting would be computed at render time |
| 20:33 |
hmmmm |
like you're iterating downward when creating a mesh, you start with the +(x,z) of that border |
| 20:33 |
|
red-001 joined #minetest-dev |
| 20:33 |
|
red-001 joined #minetest-dev |
| 20:33 |
juhdanad |
And what is it good for? I mean this does not give different lighting from what we have now. |
| 20:33 |
hmmmm |
storage |
| 20:33 |
hmmmm |
you'd only need to store 88 bytes the way things are right now |
| 20:33 |
hmmmm |
per mapblock |
| 20:34 |
juhdanad |
That is true. |
| 20:34 |
hmmmm |
and you'd free up a byte per mapnode too |
| 20:34 |
hmmmm |
but the only issue there is blending |
| 20:34 |
hmmmm |
i have thought about all this but never made any proof of concept so there's still places where my ideas could fall short |
| 20:34 |
juhdanad |
But does minetest run out of memory? |
| 20:34 |
hmmmm |
all the time brotha |
| 20:35 |
hmmmm |
yeah okay |
| 20:35 |
hmmmm |
so this is how the algorithm works |
| 20:35 |
hmmmm |
let's say you're making the mesh |
| 20:36 |
hmmmm |
you iterate downward on a certain (x,z) column, so your light is mapblock_light_yplus_border[x + z * z_stride] |
| 20:36 |
hmmmm |
you decay this light by 1 |
| 20:36 |
hmmmm |
and then query each opposing column when computing the effective mapnode light |
| 20:36 |
VanessaE |
hmmmm: right, that (sun=120) is basically what I was thinking. |
| 20:37 |
juhdanad |
But light can spread in all directions! |
| 20:37 |
hmmmm |
so you have a loop where it'd go down and you fetch mapblock_light_xplus[y + z * zstride] and mapblock_light_xminus[y + z * zstride], subtract the distance away from the border relative to those coordinates it is and decay the light by that amount |
| 20:38 |
hmmmm |
yeah |
| 20:38 |
juhdanad |
And light can spread in an S shape in an S shaped tunnel. |
| 20:38 |
hmmmm |
the way this recursive algorithm works is a real bummer |
| 20:38 |
hmmmm |
makin things complicated |
| 20:38 |
juhdanad |
One more thing: minetest.get_node_light() returns blended day-night light for a node. |
| 20:38 |
hmmmm |
yes, i already accepted this would kill the performance for the light query API |
| 20:39 |
hmmmm |
if i can get this idea to fully work though i think that'd be a very acceptable sacrifice |
| 20:41 |
juhdanad |
And if a player places a node then would you recompute lighting for the whole block? |
| 20:41 |
hmmmm |
unfortunately yes |
| 20:42 |
hmmmm |
but that's not too bad, i mean a lot is already recomputed when nodes are modified |
| 20:42 |
juhdanad |
Currently if you dig a dirt node on the ground, only this node gets updated. |
| 20:43 |
juhdanad |
And if you hit a torch next to another one, only one half of the light is recomputed. |
| 20:51 |
hmmmm |
yeah, okay, nevermind about my whole idea |
| 20:53 |
hmmmm |
what i'm saying is equivalent to: given a specific X,Y,Z i can compute the L of a node with no other info |
| 20:53 |
juhdanad |
Sorry if I disappointed you :( |
| 20:53 |
hmmmm |
thanks for talking to me |
| 20:53 |
hmmmm |
you made me draw it in kolourpaint and try to figure out if what i'm saying has a chance of working in reality |
| 20:53 |
juhdanad |
To tell the truth, I have spent several nights thinking about new kinds of lighting. |
| 20:55 |
hmmmm |
well i haven't spent that much time on it, but this has always been an issue you can't help but wonder if there's a solution to |
| 20:55 |
juhdanad |
But the best idea was to store direction of incoming light. And it still has a drawback: you only know a block's lighting if the neighbor blocks are loaded. |
| 20:55 |
hmmmm |
you see i've come up with several half-assed solutions with flaws in each |
| 20:56 |
hmmmm |
again though |
| 20:56 |
hmmmm |
each node has several sources |
| 20:56 |
juhdanad |
Yes, but you have to store the one that gives maximal light. |
| 20:56 |
hmmmm |
how can you tell what the direction is for the fade-out of two lights |
| 20:57 |
hmmmm |
like say you have two beams crossing at X,Y,Z. but (X+1, Y+1, Z+1) gets lit as well |
| 20:57 |
hmmmm |
or is that relevant... hrmmm |
| 20:57 |
juhdanad |
In minetest light sources' lights are not added, but the maximum is chosen. |
| 20:57 |
juhdanad |
Currently it is a plain Dijkstra's algorithm. |
| 20:58 |
juhdanad |
So the air would point towards the nearest light source. |
| 21:00 |
hmmmm |
just so i know what you're talking about |
| 21:00 |
hmmmm |
http://i.imgur.com/0Wi14rV.png what direction would the periwinkle pixel in this diagram be? |
| 21:01 |
hmmmm |
+N or +E? |
| 21:01 |
juhdanad |
What do the colours mean? |
| 21:02 |
hmmmm |
errm |
| 21:02 |
hmmmm |
gray is the mapblock border |
| 21:02 |
hmmmm |
red is a node that blocks light |
| 21:02 |
hmmmm |
and the yellow is the fading light |
| 21:03 |
juhdanad |
Then it can be both left and down. The resulting distance (and so brightness) would be the same. |
| 21:03 |
hmmmm |
you mean either or |
| 21:03 |
juhdanad |
Oh, yes! |
| 21:03 |
hmmmm |
so lemme think about this... |
| 21:04 |
hmmmm |
this node has a direction of north |
| 21:04 |
hmmmm |
and where do you get the light *value* from? |
| 21:04 |
hmmmm |
mapblock border? |
| 21:04 |
juhdanad |
And each node points towards a brighter node. |
| 21:04 |
hmmmm |
oh so it's the opposite |
| 21:04 |
hmmmm |
so it points either W or S |
| 21:05 |
juhdanad |
If a node has no direction, it means that it is a light source. |
| 21:05 |
juhdanad |
We have to walk until we find such a node. |
| 21:05 |
hmmmm |
eww |
| 21:05 |
juhdanad |
Then node_light=light_source-distance |
| 21:05 |
hmmmm |
trying to figure out how that can be done efficiently inside of the makemesh |
| 21:06 |
hmmmm |
but i can understand why direction doesn't matter though |
| 21:06 |
juhdanad |
This is not for meshes! This is to replace the current meaning of param1. |
| 21:06 |
hmmmm |
you would need a plane for each mapblock border of light values though, no? |
| 21:06 |
hmmmm |
yes but you still need to compute the effective lighting for a single node when making the mesh |
| 21:07 |
juhdanad |
Yes, this is slower than caching the light for all nodes. |
| 21:07 |
hmmmm |
waaaaaay slower |
| 21:07 |
juhdanad |
This would only allow nodes with light_source>14. |
| 21:08 |
hmmmm |
but so would my version, if you accepted running the light algorithm just before mesh making |
| 21:08 |
hmmmm |
just one amendment to yours: |
| 21:08 |
hmmmm |
if you take the scenario laid out in my diagram i pasted |
| 21:08 |
hmmmm |
and the direction for the periwinkle node is either west or south |
| 21:09 |
hmmmm |
there would be no light source since it came from a spread light |
| 21:09 |
juhdanad |
The node with sunlight is the light source. |
| 21:09 |
hmmmm |
nevermind sunlight right now |
| 21:09 |
juhdanad |
There are three bits: 0-5 is direction, 6 is light source and 7 is sunlight. |
| 21:09 |
hmmmm |
i'm just talking about a single artificial light source |
| 21:10 |
juhdanad |
Oh, the node at the border would point out of the block. |
| 21:10 |
juhdanad |
This is why I wrote: "you only know a block's lighting if the neighbor blocks are loaded." |
| 21:11 |
hmmmm |
not at the border |
| 21:11 |
hmmmm |
inside of the room with a single hole that light shines through |
| 21:11 |
hmmmm |
the light radiates and so a node that's not directly in the path of the light gets lit |
| 21:12 |
hmmmm |
according to your definition, it points toward the brighest node neighbor |
| 21:12 |
hmmmm |
and that's the direction you trace back to find the light source |
| 21:12 |
juhdanad |
Oh, you misunderstood me! The node points to its neighbor, which points towards an other node and following this path you get to the light source. |
| 21:12 |
hmmmm |
but if you, say, the column at (X,Y) is the light source and you're considering the node at (X+1,Y+1,Z) |
| 21:13 |
hmmmm |
have the situation where* |
| 21:13 |
hmmmm |
it'd never trace back to a light source |
| 21:13 |
hmmmm |
ahhh |
| 21:13 |
hmmmm |
okay okay sorry |
| 21:13 |
hmmmm |
that makes total sense now |
| 21:13 |
hmmmm |
now watch this whole idea go to shit when you start adding RGB lights :) |
| 21:14 |
hmmmm |
yeah i'm on board with your direction idea now |
| 21:14 |
hmmmm |
the only problem is the unbounded time to compute a single light cell vs. a deterministic upper bound |
| 21:14 |
juhdanad |
The problem with colored lights is that an orange light's red component fades slower than a red light's. |
| 21:16 |
hmmmm |
yeah the direction idea is the best of the bunch so far, because it actually works unlike mine |
| 21:16 |
juhdanad |
If you maximize light_source to 32, then it is guaranteed that you get a node's light after 32 iterations. |
| 21:16 |
rubenwardy |
you could exit after X steps |
| 21:16 |
hmmmm |
but then there goes the sales pitch of having infinite lighting range! |
| 21:17 |
juhdanad |
Well, true. |
| 21:17 |
hmmmm |
at this point you step back and wonder if it's all worth it |
| 21:17 |
juhdanad |
I could rather say: brighter light sources with only 3 bits per light bank. |
| 21:17 |
hmmmm |
you could just double the size of a mapnode and get everything you ever wanted |
| 21:18 |
hmmmm |
just double the ram as if we aren't sucking up enough already |
| 21:18 |
hmmmm |
double the cache misses |
| 21:19 |
hmmmm |
another thing with the lighting idea: is it possible for a node to get stuck in a circle |
| 21:19 |
juhdanad |
Also currently placing a torch makes 6800 node's light recalculated. |
| 21:19 |
hmmmm |
i mean the directional lighting idea* |
| 21:20 |
juhdanad |
If you encouter a circle, it is a bug which would not happen. If you still encouter a circle, you set the node as a light source. |
| 21:21 |
juhdanad |
(if it is air, it will provide zero light) |
| 21:38 |
|
troller joined #minetest-dev |
| 21:53 |
hmmmm |
yeah so how does zero light get represented |
| 21:53 |
hmmmm |
don't you need an extra bit for that? |
| 21:53 |
hmmmm |
bringing the total to 9, which would mean 4 bits per light bank? |
| 21:54 |
juhdanad |
No. Zero light is a light source. Since nodedef.light_source is 0 there. |
| 21:54 |
hmmmm |
ahhhh |
| 21:55 |
hmmmm |
this is a tough problem |
| 21:55 |
juhdanad |
hmmmm: sorry to bother you with that, but are you still planning to expose biome information to not mapgen code? |
| 21:55 |
hmmmm |
i wonder if it'd be worth it trying to get hardware lighting working |
| 21:56 |
hmmmm |
or do this all from within shaders |
| 21:56 |
hmmmm |
yes |
| 21:56 |
hmmmm |
i guess i have to, now that the biome system isn't undocumented anymore |
| 21:57 |
juhdanad |
I would like to implement hardware-coloured node faces and the two together make biome-coloured grass and leaves. |
| 21:57 |
hmmmm |
who doesn't want that |
| 21:57 |
hmmmm |
it doesn't even need to be done in hardware though |
| 21:58 |
juhdanad |
If it is done with hardware, one texture is enough for a node type (eg. wool). |
| 21:58 |
juhdanad |
Less texture is faster graphics. |
| 21:59 |
hmmmm |
there's a lot of potential in shaders |
| 21:59 |
hmmmm |
it's just that none of us know how to use them well |
| 21:59 |
hmmmm |
:/ |
| 22:00 |
hmmmm |
and then there's the issue with irrlicht |
| 22:00 |
hmmmm |
ugh this whole thing is a giant can of worms |
| 22:00 |
hmmmm |
so much work |
| 22:00 |
juhdanad |
Maybe lhofhansl. He once tried to change shaders. |
| 22:00 |
hmmmm |
hah |
| 22:00 |
hmmmm |
i changed shaders a few time too |
| 22:01 |
hmmmm |
times* |
| 22:01 |
hmmmm |
it's not about knowing how to write a shader i suppose, it's more about being familiar with lots of specialized topics in computer graphics |
| 22:24 |
|
lhofhansl joined #minetest-dev |
| 22:26 |
|
Player_2 joined #minetest-dev |
| 22:37 |
|
DI3HARD139 joined #minetest-dev |
| 22:47 |
|
red-001 joined #minetest-dev |
| 22:54 |
|
lhofhansl left #minetest-dev |
| 23:00 |
|
Foz joined #minetest-dev |
| 23:01 |
|
turtleman joined #minetest-dev |
| 23:15 |
|
garywhite joined #minetest-dev |
| 23:23 |
|
YuGiOhJCJ joined #minetest-dev |
| 23:32 |
|
AntumDeluge joined #minetest-dev |
| 23:35 |
|
red-001 joined #minetest-dev |
