| Time |
Nick |
Message |
| 00:00 |
|
Ardonel joined #minetest-dev |
| 00:47 |
OldCoder |
hmmmm, thank you. That answers something I was wondering about; //deleteblocks did not seem to affect entities that I could see. |
| 00:48 |
OldCoder |
|
| 00:48 |
OldCoder |
Say, I'll mention something funny I've noticed. VE says she may have seen it too. Probably nobody can comment yet... |
| 00:49 |
OldCoder |
But VE's remarks about creatures falling to the bottom of the universe reminds me, I often see mobs skyrocketing straight up without explanation |
| 00:49 |
OldCoder |
Santa, animals, whoose, they shoot straight up and out of site |
| 00:49 |
OldCoder |
whoosh! * |
| 00:49 |
OldCoder |
Perhaps traveling to the stars. If Rocket Mobs is not an intentional feature, perhaps this should be noted. |
| 00:49 |
OldCoder |
|
| 01:47 |
|
everamzah joined #minetest-dev |
| 02:18 |
|
AnotherBrick joined #minetest-dev |
| 03:50 |
|
Fritigern joined #minetest-dev |
| 03:56 |
|
asl97 joined #minetest-dev |
| 05:43 |
|
Hunterz joined #minetest-dev |
| 06:07 |
|
nrzkt joined #minetest-dev |
| 06:35 |
|
asl97 joined #minetest-dev |
| 07:13 |
|
cvtsx joined #minetest-dev |
| 07:26 |
|
nrzkt joined #minetest-dev |
| 07:43 |
|
werwerwer joined #minetest-dev |
| 08:08 |
|
T4im joined #minetest-dev |
| 08:08 |
|
Darcidride joined #minetest-dev |
| 08:38 |
|
Ardonel joined #minetest-dev |
| 08:49 |
|
H-H-H joined #minetest-dev |
| 09:13 |
|
FR^2 joined #minetest-dev |
| 10:04 |
|
Darcidride_ joined #minetest-dev |
| 11:45 |
|
lisacvuk joined #minetest-dev |
| 11:52 |
|
Darcidride joined #minetest-dev |
| 11:59 |
|
RealBadAngel joined #minetest-dev |
| 11:59 |
Megaf |
T4im: I see, here I'm running GNOME (ON) Wayland |
| 11:59 |
Megaf |
Mutter is the compositor itself, I think |
| 12:38 |
|
DFeniks joined #minetest-dev |
| 13:03 |
|
rickmcfarley joined #minetest-dev |
| 13:03 |
|
rickmcfarley joined #minetest-dev |
| 13:06 |
|
Megaf_ joined #minetest-dev |
| 13:34 |
|
numZero joined #minetest-dev |
| 13:59 |
|
Megaf joined #minetest-dev |
| 14:18 |
|
nrzkt joined #minetest-dev |
| 14:29 |
|
lisacvuk joined #minetest-dev |
| 14:42 |
|
CraigyDavi joined #minetest-dev |
| 14:47 |
|
leat1 joined #minetest-dev |
| 15:05 |
|
Siva joined #minetest-dev |
| 15:16 |
Sokomine |
OldCoder: i think those mobs where heading upwards and didn't receive an update of their trajectory in time. it was very fun in earlier implementations of sapiers mobf (which used to need heavy ressources to spawn the mobs) to see fish take off and head up into the sky |
| 15:25 |
DFeniks |
i might have seen mobs jump up in sky too , not sure. but it reminds me i frequently see unknown entities flying slowly over water , i encountered them on Xanadu and VanessaE's Survival . too bad i can barely reach f12 even when i remembered about screenshot feature . sorry no screenshots yet |
| 15:25 |
|
Calinou joined #minetest-dev |
| 15:26 |
|
red1 joined #minetest-dev |
| 15:33 |
|
leat1 joined #minetest-dev |
| 15:39 |
|
red1 joined #minetest-dev |
| 15:46 |
Sokomine |
DFeniks: that's normal behaviour. unkown entities come from entities that once existed but got renamed or removed afterwards. these entities continue to move on |
| 15:47 |
DFeniks |
great , afterlife for entities , ghosts of mobs ... |
| 15:48 |
Megaf |
a /clearobjects should wipe them out |
| 16:02 |
|
est31 joined #minetest-dev |
| 16:10 |
|
blaze joined #minetest-dev |
| 16:11 |
|
hmmmm joined #minetest-dev |
| 16:12 |
|
Hunterz joined #minetest-dev |
| 16:19 |
|
Amaz joined #minetest-dev |
| 16:26 |
|
Siva joined #minetest-dev |
| 16:32 |
|
H-H-H joined #minetest-dev |
| 16:32 |
|
Robert_Zenz joined #minetest-dev |
| 16:36 |
|
Krock joined #minetest-dev |
| 16:37 |
|
Taoki[mobile] joined #minetest-dev |
| 16:38 |
est31 |
nanepiwo, fixing the error you pointed out |
| 16:38 |
est31 |
what is your github handle nanepiwo ? |
| 16:40 |
nanepiwo |
what's a handle? |
| 16:41 |
est31 |
user name |
| 16:41 |
nanepiwo |
nanepiwo |
| 16:41 |
nanepiwo |
the issue is #2825 if you're looking |
| 16:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/2825 -- Entities outside of map borders. |
| 16:45 |
est31 |
hmmmm, can you have a look at https://github.com/est31/minetest/commit/d2ea4a23c167db19fc166991f2c508472ba22b46 |
| 16:51 |
VanessaE |
est31: that looks workable for spawning an entity, but what about entities that wander out of bounds after spawning in-bounds? |
| 16:52 |
est31 |
VanessaE, that's for later when I've read that code |
| 16:53 |
VanessaE |
ok. |
| 16:53 |
VanessaE |
just making sure it doesn't get forgotten. |
| 16:53 |
est31 |
also, note that this patch needs modder interactions |
| 16:54 |
est31 |
e.g. with the example command provided by nanepiwo you can still crash the server just now its a problem of the mod xD |
| 16:54 |
est31 |
because minetest.add_entity returns nil ::) |
| 16:54 |
est31 |
perhaps I should point that out |
| 16:54 |
hmmmm |
est31, couple things here... |
| 16:55 |
hmmmm |
the name. isInsideF1000 |
| 16:55 |
hmmmm |
that isn't very intuitive... I'm not sure what else to say |
| 16:55 |
est31 |
ideas for better names? |
| 16:55 |
est31 |
I dont like it either |
| 16:55 |
|
Niebieski joined #minetest-dev |
| 16:56 |
est31 |
isLegalF1000? |
| 16:56 |
hmmmm |
no |
| 16:56 |
hmmmm |
something with bounds |
| 16:56 |
hmmmm |
CanFitWithinF1000Bounds()? |
| 16:56 |
hmmmm |
but the thing is |
| 16:56 |
est31 |
isInsideF1000bounds() is shorter |
| 16:56 |
VanessaE |
IsInBoundsF1000 ? |
| 16:56 |
hmmmm |
it's not about whether an object should be within the bounds or not |
| 16:56 |
hmmmm |
an object should always be within the map |
| 16:57 |
hmmmm |
third, memory leak where you do the checking |
| 16:57 |
hmmmm |
you need to if (object->environmentDeletes()) delete object; |
| 16:58 |
est31 |
ah |
| 16:58 |
hmmmm |
fourth, this does not cover all the cases |
| 16:58 |
VanessaE |
I noticed that, wasn't sure if I was right. |
| 16:58 |
hmmmm |
what about object movement |
| 16:58 |
hmmmm |
etc. etc. |
| 16:58 |
est31 |
hmmmm, this is only about adding |
| 16:58 |
|
nrzkt joined #minetest-dev |
| 16:58 |
hmmmm |
so what do you think about checking against the map limits |
| 16:58 |
est31 |
hmmmm, right now you can crash many servers with a simple command because you have added an assert |
| 16:59 |
est31 |
and I now try to fix the largest bug |
| 16:59 |
est31 |
and you say "this is not enough" |
| 16:59 |
est31 |
ofc it is not enough |
| 16:59 |
hmmmm |
many servers are NOT running as debug |
| 16:59 |
est31 |
but right now I want to provide the immediate patch |
| 16:59 |
hmmmm |
this 'crash' only happens with debug builds |
| 16:59 |
nrzkt |
assert is not run in release mode |
| 16:59 |
est31 |
like those from the ppa |
| 16:59 |
nrzkt |
and permit to find bugs :) |
| 16:59 |
est31 |
the ppa is built in debug mode |
| 16:59 |
nrzkt |
if the PPA maintainer does shit, tell him |
| 17:00 |
hmmmm |
well that's kind of boneheaded |
| 17:00 |
hmmmm |
sounds like the PPA maintainer's problem, not ours |
| 17:00 |
est31 |
hmmmm, there is none :) |
| 17:00 |
hmmmm |
the whole reason why the assert is there is to help us discover places where objects go out-of-bounds and fix them |
| 17:00 |
hmmmm |
this is way better than failing silently |
| 17:00 |
est31 |
why did it have to be a crashing message? |
| 17:01 |
est31 |
why not just log to errorstream |
| 17:01 |
est31 |
and done |
| 17:01 |
hmmmm |
nobody listens to errorstream unless something visible happens |
| 17:01 |
hmmmm |
I guess you could log to errorstream, it's just that you don't normally want to add logging.h to util/serialize.h |
| 17:01 |
hmmmm |
that's a fairly hefty include |
| 17:01 |
est31 |
well, then put it in serialize.cpp |
| 17:01 |
hmmmm |
also, every single call will have that inlined |
| 17:02 |
hmmmm |
that's such a slowdown |
| 17:02 |
est31 |
shrug |
| 17:02 |
est31 |
meh no |
| 17:02 |
est31 |
the cpu will learn to predict the other case |
| 17:02 |
est31 |
and not load the instructions |
| 17:02 |
est31 |
so no slowdown |
| 17:03 |
hmmmm |
that doesn't matter, the fact is the call to errorstream operator << |
| 17:03 |
hmmmm |
is still there |
| 17:03 |
hmmmm |
along with all the arguments |
| 17:03 |
hmmmm |
this will trash the icache where it normally shouldn't be |
| 17:03 |
est31 |
but yeah I guess once an object gets inside dangerous territorry it will spam errorstream |
| 17:03 |
hmmmm |
thrash rather |
| 17:03 |
hmmmm |
there are a lot of problems here |
| 17:03 |
hmmmm |
but the main problem is that before I made that change, F1000s silently failed to serialize and objects would seemingly warp to other parts of the map |
| 17:04 |
hmmmm |
honestly I'd rather fix that and be able to remove the assert |
| 17:04 |
est31 |
thats better than providing people with the opportunity to do /area_pos1 99999999,0,0 and crash the server |
| 17:04 |
hmmmm |
again, they shouldn't be running a debug build |
| 17:04 |
hmmmm |
that's THEIR problem, not ours |
| 17:04 |
hmmmm |
and I am totally against "fast" fixes |
| 17:04 |
hmmmm |
i want things done right |
| 17:05 |
T4im |
but once you fix the issue, wouldn't the assert finally be reasonable? :P as in, asserting that it can't happen anymore? |
| 17:05 |
hmmmm |
i suppose so |
| 17:05 |
hmmmm |
ugh |
| 17:05 |
hmmmm |
fine |
| 17:05 |
est31 |
hmmmm, you always want things perfect |
| 17:05 |
hmmmm |
we'll put writeF1000 into serialize.cpp, make it not inlineable, and spit out an errorstream message |
| 17:05 |
nrzkt |
i think coordinates should be tested in EVERY lua call |
| 17:05 |
nrzkt |
this is the solution :) |
| 17:05 |
hmmmm |
honestly yeah ^ |
| 17:05 |
nrzkt |
and trigger an exception if shit is done |
| 17:06 |
hmmmm |
but this error condition can happen purely within the core I believe |
| 17:06 |
est31 |
lua is only an interface |
| 17:06 |
est31 |
yea |
| 17:06 |
est31 |
imagine falling object |
| 17:06 |
nrzkt |
yes but lua permit to do those things. |
| 17:06 |
nrzkt |
falling object is lua |
| 17:06 |
nrzkt |
adding a out of bound check in the luaentitysao is the solution here. |
| 17:06 |
est31 |
wtf object physics are lua?! |
| 17:06 |
VanessaE |
a falling entity is exactly the thing here. |
| 17:06 |
hmmmm |
if an object tries to move outside the map I think it should simply not move any further |
| 17:06 |
est31 |
yea |
| 17:07 |
VanessaE |
spawns in a normal area,. falls down a deep hole, finds its way to the map border, boom |
| 17:07 |
hmmmm |
adding objects outside of map boundaries should fail |
| 17:07 |
hmmmm |
forget the serialization limits for F1000 for now |
| 17:07 |
est31 |
but hmmmm this is not what my patch is about |
| 17:07 |
T4im |
coordinate min/max? :) |
| 17:07 |
hmmmm |
ell |
| 17:07 |
hmmmm |
wlel |
| 17:07 |
est31 |
my patch is about ADDING objects to the map |
| 17:07 |
est31 |
not about moving objects |
| 17:07 |
est31 |
they are statically |
| 17:07 |
est31 |
floating |
| 17:07 |
est31 |
not moving |
| 17:07 |
hmmmm |
scrap the patch, and just change the assert to an error logging thing |
| 17:07 |
est31 |
no, you conviced me now, no error logging |
| 17:07 |
hmmmm |
that's a "quick fix" albeit one that's sort of gross |
| 17:07 |
est31 |
it will spam everything |
| 17:08 |
hmmmm |
eh |
| 17:08 |
est31 |
hmmmm, is there a generic method for checking world bounds? |
| 17:08 |
hmmmm |
yes |
| 17:09 |
hmmmm |
blockpos_over_limit() |
| 17:09 |
|
rubenwardy joined #minetest-dev |
| 17:10 |
est31 |
but that doesn't really fit actually |
| 17:10 |
kahrl |
oh wow, does this really read the setting every time? |
| 17:10 |
est31 |
I mean its mostly about mapgen |
| 17:10 |
est31 |
no |
| 17:10 |
kahrl |
it's called in the inner loop of RemoteClient::GetNextBlocks |
| 17:10 |
est31 |
const static |
| 17:11 |
kahrl |
oh, yeah |
| 17:14 |
|
ElectronLibre joined #minetest-dev |
| 17:24 |
|
Krock joined #minetest-dev |
| 17:26 |
est31 |
ok new version https://github.com/est31/minetest/commit/3bd6885b605189ef2f07910c8f93664e3eea7898 |
| 17:27 |
est31 |
even newer one https://github.com/est31/minetest/commit/c0b5324e929c56e9dc09a6a531716624e2d0875e |
| 17:29 |
VanessaE |
est31: that won't work |
| 17:29 |
nrzkt |
seems good for newer objects |
| 17:29 |
VanessaE |
the mapgen limits are different at each end/on each axis |
| 17:30 |
nrzkt |
i use a similar patch to remove unneeded saved entities :) |
| 17:31 |
est31 |
VanessaE, but they are inside F1000 bounds, right? |
| 17:32 |
VanessaE |
that I can't be sure of |
| 17:32 |
est31 |
I'm very sure of that its much more than 31k |
| 17:32 |
est31 |
much much more |
| 17:33 |
VanessaE |
I'm just saying that at the negative end (of a full map) it's -30912, but at the positive ends it's 30927 or some such |
| 17:36 |
VanessaE |
and MAX_MAP_GENERATION_LIMIT is greater than either of those, by default (31000 even) |
| 17:37 |
hmmmm |
eh |
| 17:37 |
hmmmm |
instead of objectpos, what's wrong with nodepos |
| 17:37 |
hmmmm |
blockpos checks block coordinates |
| 17:37 |
hmmmm |
oh i see, it compares a v3f |
| 17:37 |
est31 |
yea |
| 17:37 |
hmmmm |
yeah, looks fine to me. |
| 17:38 |
est31 |
but what VanessaE is likely true though, its not perfectly aligned to the border (a bit farther) is that ok? |
| 17:39 |
hmmmm |
in an ideal world we'd never get objects trapped in areas outside the map |
| 17:39 |
hmmmm |
MAP_GENERATION_LIMIT is a decent compromise imo |
| 17:40 |
est31 |
well, lua would have to check |
| 17:40 |
est31 |
but I don't think this is how we should do things |
| 17:40 |
est31 |
providing unsafe API to lua |
| 17:40 |
est31 |
rather we should make it a nice sandbox |
| 17:41 |
est31 |
s/things/this/ |
| 17:45 |
est31 |
pushed |
| 17:45 |
est31 |
now the areas mod only has to check for add_entity to return nil |
| 17:45 |
est31 |
nanepiwo, wanna file a bug? |
| 17:46 |
est31 |
I'm gone |
| 17:46 |
est31 |
bye |
| 17:48 |
kahrl |
wait a second, isn't there a * BS missing |
| 18:06 |
nrzkt |
kahrl, exact, object->getBasePOsition() / BS should be |
| 18:06 |
nrzkt |
else this will remove many many objects :p |
| 18:06 |
nrzkt |
because limit will be 3200 not 32k :) |
| 18:08 |
nrzkt |
sorry 320k |
| 18:09 |
nrzkt |
then the fix has no effect |
| 18:11 |
|
AnotherBrick joined #minetest-dev |
| 18:17 |
|
leat1 joined #minetest-dev |
| 18:20 |
|
domtron joined #minetest-dev |
| 18:30 |
|
leat1 joined #minetest-dev |
| 18:40 |
|
ShadowBot joined #minetest-dev |
| 18:40 |
OldCoder |
Sokomine, does this mean I have sheep collected on the roof of the Universe? |
| 18:54 |
|
leat1 joined #minetest-dev |
| 18:54 |
Sokomine |
OldCoder: they just appear to shoot upwards forever on the client's side. i have no idea what happens server-side. the server didn't have enough time to correct their movement...no idea where the entities end up. old mapblock? the one where they happened to be in by chance? the topmost loaded one? |
| 18:56 |
Sokomine |
but...if you find any flying sheep...take a screenshot :) |
| 18:57 |
OldCoder |
They whoosh up too quickly |
| 18:57 |
OldCoder |
Zoom! |
| 18:57 |
OldCoder |
To the Moon! |
| 18:57 |
OldCoder |
Sometimes in groups |
| 18:57 |
OldCoder |
Flying crocs are a sight to see |
| 18:58 |
OldCoder |
It is unnerving :P |
| 18:58 |
OldCoder |
Fortunately it is not all the time. I am more concerned about a random number issue. |
| 18:58 |
OldCoder |
Scroll up a day and see the discussion between C55 and myself on the issue. |
| 18:58 |
OldCoder |
I think the RNG in MT is fundamentally broken. |
| 18:58 |
OldCoder |
|
| 18:59 |
OldCoder |
Mobs created by totally different mods, even those with different APIs, and with low-probably spawning... |
| 18:59 |
OldCoder |
spawn in clumps on exactly the same nodes |
| 18:59 |
OldCoder |
Try increasing active_object_count to 32 and see what happens |
| 18:59 |
OldCoder |
The primary requirement is that mobs need to have the same interval and chance |
| 19:00 |
OldCoder |
That chance often triggers at exactly the same time for a dozen mods |
| 19:00 |
OldCoder |
Even though I have looked closely at the C++ code and it should not |
| 19:00 |
OldCoder |
|
| 19:03 |
Sokomine |
OldCoder: oh. i thought that was deliberate, that spawning in groups. at least for sandmobs and the like. but i might be wrong |
| 19:03 |
|
leat1 joined #minetest-dev |
| 19:03 |
Sokomine |
as to the problem of not enough time to update mob spawning...it only happens when the server is too busy due to something |
| 19:03 |
OldCoder |
Sokomine, nope; Santa, sheep, cows, snowmen |
| 19:04 |
OldCoder |
Try increasing active_object_count to 32, set interval to 30, set chance to 30000 |
| 19:04 |
OldCoder |
Set spawn_near to dirt_on_grass |
| 19:04 |
OldCoder |
Do this for different mods using both mobs and mobs redo |
| 19:04 |
OldCoder |
Then fly around |
| 19:05 |
OldCoder |
and witness 10 to 20 things stuck together |
| 19:05 |
OldCoder |
If you trace the code down, the issue seems to be in the engine |
| 19:05 |
OldCoder |
Which C55 says is not possible |
| 19:05 |
OldCoder |
But the fact is that it goes right to heart of what an ABM does |
| 19:05 |
OldCoder |
The ABMs are triggering in some cases at exactly the same time |
| 19:05 |
OldCoder |
|
| 19:06 |
* OldCoder |
thinks myrand in the core code is broken and will try replacing it |
| 19:06 |
OldCoder |
As a related note: |
| 19:06 |
OldCoder |
This is core dev BTW the RNG is broken: |
| 19:07 |
OldCoder |
I set chance for mantises to 80000 |
| 19:07 |
OldCoder |
No, there is not supposed to be a 16 bit rollover for this |
| 19:07 |
OldCoder |
And got 1000s of mantises roaming the countryside |
| 19:07 |
OldCoder |
Hungry for human victims |
| 19:07 |
OldCoder |
|
| 19:07 |
OldCoder |
There does seem to be a problem with ABM triggering |
| 19:07 |
OldCoder |
|
| 19:12 |
|
nanepiwo joined #minetest-dev |
| 19:16 |
Sokomine |
maybe it's a bug in the mod. i've only seen the nice models it has plus a few screenshots but never took a look at the code behind it |
| 19:17 |
Sokomine |
it would be great to have some variation of the mobs mod in minetest_game, builtin or a new general library. the mobs code i've seen isn't suitable for that yet |
| 19:24 |
OldCoder |
Sokomine, again, read up; different mods, different APIs |
| 19:24 |
OldCoder |
And the code goes directly to minetest.register_abm |
| 19:24 |
OldCoder |
The code can be simply calls to minetest.register_abm |
| 19:25 |
OldCoder |
It appears that chance = chance is simply ignored or that chance often goes haywire |
| 19:25 |
OldCoder |
below that level is simply built-in and C++ code |
| 19:25 |
OldCoder |
|
| 19:25 |
OldCoder |
minetest.register_abm is not mobs code. It is core. |
| 19:25 |
Sokomine |
many mob mods are forks of pilzadams original version or forks of forks from that; if there's an error, it's possible that they all inherited id |
| 19:25 |
* OldCoder |
sighs |
| 19:25 |
OldCoder |
Read what I just typed, please |
| 19:26 |
OldCoder |
<OldCoder> The code can be simply calls to minetest.register_abm |
| 19:26 |
OldCoder |
<OldCoder> It appears that chance = chance is simply ignored or that chance often goes haywire |
| 19:26 |
OldCoder |
<OldCoder> below that level is simply built-in and C++ code |
| 19:26 |
OldCoder |
There is no mobs code at issue |
| 19:26 |
OldCoder |
This is core |
| 19:26 |
OldCoder |
|
| 19:26 |
* OldCoder |
will double-check all of this of course |
| 19:26 |
Sokomine |
i havn't looked deep enough into it to be able to say much about those abms the mobs mod use. i havn't heared about strange behaviour from other mods using abs - but maybe that's less obvious |
| 19:27 |
OldCoder |
active_object_count needs to be high |
| 19:27 |
OldCoder |
for the issue to manifest |
| 19:27 |
OldCoder |
usually it is set to 1 to 3 |
| 19:27 |
OldCoder |
For the issue to manifest, these conditions must be met: |
| 19:27 |
OldCoder |
|
| 19:28 |
OldCoder |
identical node, neighbors, interval, chance, active_object_count parameters |
| 19:28 |
OldCoder |
interval of 30 is good |
| 19:28 |
OldCoder |
chance of perhaps 20000 |
| 19:28 |
OldCoder |
active_object_count of 32 or 64 |
| 19:28 |
OldCoder |
^ the parameters |
| 19:28 |
OldCoder |
Few have tested this, I think |
| 19:28 |
OldCoder |
|
| 19:29 |
OldCoder |
Try it yourself sometimes and see. Not necessarily mobs code. Just different register_abm calls with these parameters |
| 19:29 |
OldCoder |
Perhaps ABMs that just log a message |
| 19:30 |
OldCoder |
Then fly over terrain and see if you get clumps of messages on the same nodes |
| 19:30 |
OldCoder |
I will do this myself |
| 19:30 |
OldCoder |
|
| 19:31 |
|
leat1 joined #minetest-dev |
| 20:04 |
|
ShadowBot joined #minetest-dev |
| 20:04 |
|
ShadowBot joined #minetest-dev |
| 20:08 |
|
everamzah joined #minetest-dev |
| 20:09 |
|
Amaz joined #minetest-dev |
| 20:23 |
celeron55 |
Subject: Stuck in air! |
| 20:23 |
celeron55 |
I'm stuck niggah help >°.0 house craft |
| 20:23 |
celeron55 |
^ this here is a complete email |
| 20:24 |
celeron55 |
enjoy |
| 20:26 |
|
leat1 joined #minetest-dev |
| 20:33 |
|
leat1 joined #minetest-dev |
| 20:51 |
|
zat joined #minetest-dev |
| 20:57 |
|
ElectronLibre left #minetest-dev |
| 21:04 |
|
zat joined #minetest-dev |
| 21:31 |
|
eye_mine joined #minetest-dev |
| 21:35 |
|
twoelk joined #minetest-dev |
| 21:41 |
|
proller joined #minetest-dev |
| 21:42 |
|
proller joined #minetest-dev |
| 21:50 |
|
domtron joined #minetest-dev |
| 21:55 |
|
OldCoder joined #minetest-dev |
| 22:14 |
|
leat1 joined #minetest-dev |
| 22:35 |
|
H-H-H joined #minetest-dev |
| 22:52 |
|
zat joined #minetest-dev |
| 23:04 |
|
werwerwer joined #minetest-dev |
| 23:28 |
|
Player_2 joined #minetest-dev |
| 23:55 |
|
HulkSmash joined #minetest-dev |
