| Time |
Nick |
Message |
| 00:02 |
kaeza |
I would like to be able to create yet another FPS based off minetest (a la AOS/OpenSpades), so crouching would be useful for e.g. taking cover from enemy fire |
| 00:04 |
paramat |
ah i see |
| 00:04 |
pitriss |
kaeza: it sounds good if you bind it to some new key..:) |
| 00:05 |
kaeza |
pitriss, currently, it adds a new "crouching" key (default is LCTRL), which BTW can also be used by mods in the same way `sneak` is used now |
| 00:05 |
proller |
and walking to 1x1 holes |
| 00:06 |
pitriss |
ahh ok.., then it sounds good.:) |
| 00:11 |
paramat |
on the subject of 1x1 holes, i discovered if you attach a player to a vehicle, and reduce the visual scale of the vehicle, it makes the player smaller too, so you can drive through 1x1 passages |
| 00:12 |
kaeza |
I recall that bug being reported, but didn't know it also affected the collision box |
| 00:13 |
kaeza |
https://github.com/minetest/minetest/issues/419 |
| 00:15 |
paramat |
lol that image mauvebic posted |
| 00:19 |
paramat |
hmmmm, celeron seems happy for someone else to finish the job of bringing mgv5 back, i might attempt this. it needs ores, biomes and trees added. so what biomes would you like to see in mgv5? i'm thinking mgv6 biomes plus a snow biome with snowy pinetrees. i would also like splizard's needles node, and my pinetree and pinewood nodes added to MTgame, to complete the default snow biome nodes. your opinions? |
| 00:21 |
proller |
paramat, you need port all your mapgent to core ;) |
| 00:23 |
paramat |
well i'm now getting my head around core mapgen code, you were right (!) c++ is not much more difficult than lua |
| 00:23 |
proller |
you got it! |
| 00:24 |
proller |
next point: its 100x faster |
| 00:25 |
paramat |
yes, lua mapgen is still too slow for some servers, okay for singleplayer though |
| 00:25 |
|
mos_basik_ joined #minetest-dev |
| 00:25 |
proller |
if you cant observe world - its not ok |
| 01:05 |
|
Zeno` joined #minetest-dev |
| 01:08 |
paramat |
wow mgv5 is much better than mgv6, especially the caves. it also uses eased 3D noise |
| 01:39 |
|
mos_basik_ joined #minetest-dev |
| 01:40 |
|
mos_basik_ joined #minetest-dev |
| 02:02 |
|
paramat left #minetest-dev |
| 02:13 |
|
prozacgod_ joined #minetest-dev |
| 02:14 |
|
prozacgod__ joined #minetest-dev |
| 02:46 |
Sokomine |
paramat: i'm not sure about that. some servers seem to work ok with plantlife in its fullness, and that's *slow* due to the huge amount of plants it spawns and the requirements thes plants have for spawning |
| 02:46 |
Sokomine |
i mean - if even that works ok, then most servers are probably on the faster side |
| 03:11 |
|
paramat joined #minetest-dev |
| 04:06 |
|
AnotherBrick joined #minetest-dev |
| 04:21 |
|
Miner_48er joined #minetest-dev |
| 04:22 |
|
Miner_48er joined #minetest-dev |
| 04:52 |
|
mos_basik joined #minetest-dev |
| 05:04 |
|
sol_invictus joined #minetest-dev |
| 05:14 |
|
paramat left #minetest-dev |
| 05:18 |
|
Hunterz joined #minetest-dev |
| 05:23 |
|
ImQ009 joined #minetest-dev |
| 05:44 |
RealBadAngel |
paramat, you could try those amplified biomes from mc |
| 05:45 |
RealBadAngel |
they look pretty neat |
| 06:00 |
|
AnotherBrick joined #minetest-dev |
| 06:29 |
|
Krock joined #minetest-dev |
| 06:29 |
|
Dragonop joined #minetest-dev |
| 06:36 |
|
ImQ009 joined #minetest-dev |
| 06:42 |
hmmmm |
https://www.shadertoy.com/view/Ms2SD1 |
| 06:42 |
hmmmm |
hue hue hue |
| 06:42 |
hmmmm |
shader perlin noise |
| 06:43 |
hmmmm |
paramat, going forward I'd like all new mapgens to use the biome infrastructure |
| 06:43 |
hmmmm |
biomes are supposed to be a thing that, going forward, mapgens all use |
| 06:43 |
hmmmm |
like they'd all share that piece of code |
| 06:44 |
RealBadAngel |
btw, if lua mapgens are slow, core are faster, why not make mapgens DLLs ? |
| 06:44 |
hmmmm |
because that's a windows-specific solution |
| 06:44 |
hmmmm |
in any case, zeno` wants that |
| 06:45 |
RealBadAngel |
i just used windows name |
| 06:45 |
RealBadAngel |
this way we could have fast mapgens and dont have to maintain them in mainstream |
| 06:47 |
hmmmm |
i think it would be better overall if lua mapgens could generate without an envlock |
| 06:48 |
Hunterz |
How many dedicated servers are hosted on windows? |
| 06:48 |
RealBadAngel |
http://luajit.org/ext_ffi.html |
| 06:48 |
Hunterz |
I think many server owners use linux for ther dedicated servers. |
| 06:49 |
RealBadAngel |
this could be the way to do that |
| 06:49 |
Zeno` |
? |
| 06:49 |
Zeno` |
What do I want? |
| 06:49 |
RealBadAngel |
drop our bundled lua, embeed stable luajit and start to use its features |
| 06:50 |
Zeno` |
Oh C mapgens? Yeah I already have those |
| 06:50 |
Zeno` |
Not ever (likely) to push the code though because nobody seems interested |
| 06:51 |
RealBadAngel |
Zeno`, i meant mapgen libs, which user can download and use with game |
| 06:51 |
RealBadAngel |
this way they can be way faster and flexible |
| 06:52 |
Zeno` |
RealBadAngel, I use on the server what I will "extensions"; the are .so files that are a hybrid of Lua and C |
| 06:52 |
Zeno` |
So, yes, a little bit different probably |
| 06:52 |
RealBadAngel |
technic computer is using libs since a long time already |
| 06:53 |
RealBadAngel |
libs are compiled for both linux and winows |
| 06:54 |
RealBadAngel |
https://github.com/minetest-technic/technic_game_2/tree/master/mods/forth_computer |
| 06:54 |
Zeno` |
I started off just extending Lua, but that was not nice. My current solution is a "hack"; If I was to push the code I'd really want to clean it up first |
| 06:55 |
Zeno` |
yeah that's basically one half of my hack |
| 06:56 |
Zeno` |
this is why my server version isn't up-to-date. I need to make the hack "nice" |
| 06:56 |
Zeno` |
one day |
| 06:57 |
Zeno` |
I could get rid of the whole hacky part altogether if there was a fast way to populate the Lua stack with node ids (and vice versa) |
| 06:58 |
Zeno` |
But they're not contiguous in memory, so... *shrug* |
| 06:58 |
Zeno` |
I did mean to add something (a light C pointer) but got sidetracked |
| 07:11 |
|
kaeza joined #minetest-dev |
| 07:16 |
RealBadAngel |
https://github.com/minetest/minetest/commit/f48f6869303ab331600efaf9ec5796c238180106 |
| 07:16 |
RealBadAngel |
this has to be changed |
| 07:16 |
RealBadAngel |
it breaks old clients |
| 07:17 |
RealBadAngel |
adding 3rd optional drawtype for two already existing ones is just wrong |
| 07:19 |
RealBadAngel |
setting for connected glass shall be read just in content_mapblock.cpp |
| 07:19 |
RealBadAngel |
without adding new drawtype for that |
| 07:22 |
RealBadAngel |
after case NDT_GLASSLIKE: check the setting and move to case NDT_GLASSLIKE_FRAMED: |
| 07:25 |
RealBadAngel |
atm thx to adding that new drawtype minetest_game is not useable with stable clients, only current dev |
| 07:27 |
|
kilbith joined #minetest-dev |
| 07:27 |
|
zat joined #minetest-dev |
| 07:46 |
|
VanessaE joined #minetest-dev |
| 08:08 |
|
darkrose joined #minetest-dev |
| 08:33 |
|
selat joined #minetest-dev |
| 08:42 |
|
proller joined #minetest-dev |
| 09:17 |
|
selat joined #minetest-dev |
| 10:11 |
|
kilbith joined #minetest-dev |
| 10:18 |
|
rubenwardy joined #minetest-dev |
| 10:20 |
|
Krock joined #minetest-dev |
| 10:27 |
|
PenguinDad joined #minetest-dev |
| 10:27 |
|
gravgun joined #minetest-dev |
| 10:44 |
|
jin_xi joined #minetest-dev |
| 11:08 |
jin_xi |
here is an idea: why not add a modifier to textures so dynamic ones can be deleted instead of leaked? like [dynamic:<name> , so whenever a dynamic texture with a name is created dynamic ones with the same name would be deleted. name could be modname+position hash or so |
| 11:21 |
Zeno` |
because it looks like a hack? |
| 11:21 |
Zeno` |
A hack that doesn't address the real problem |
| 11:24 |
Zeno` |
And I don't mean hack in the good sense of the word |
| 11:24 |
Zeno` |
What makes a texture "dynamic"? |
| 11:25 |
Zeno` |
And, why should a mod care what is dynamic and what is not (whatever dynamic means)? |
| 11:25 |
jin_xi |
lol, do you know what the problem is? |
| 11:26 |
Zeno` |
yeah... a leak |
| 11:27 |
Zeno` |
Do you? |
| 11:27 |
jin_xi |
ok, let me spell it out for you a bit: some mods need to change the appearance of a thing, by changing textures |
| 11:27 |
jin_xi |
screens and such |
| 11:28 |
jin_xi |
currently every frame of such screen is leaked |
| 11:29 |
sfan5 |
no |
| 11:29 |
sfan5 |
it's not leaked |
| 11:29 |
sfan5 |
just saved for later usage |
| 11:29 |
jin_xi |
it will probably not be used again and its a problem |
| 11:30 |
jin_xi |
also it currently can not be deleted at all |
| 11:31 |
Zeno` |
but adding a modifier? |
| 11:31 |
Zeno` |
That's not a solution :/ |
| 11:31 |
jin_xi |
would allow to delete textures if a mod wants to not keep them |
| 11:32 |
Zeno` |
When does the lifetime of the texture expire? |
| 11:32 |
jin_xi |
never |
| 11:32 |
Zeno` |
never? So it will never be released? |
| 11:32 |
Zeno` |
What's the point then? |
| 11:33 |
jin_xi |
the point is to allow use of mods that use texture combining for dynamic content without the need for quitting your client so often |
| 11:34 |
Zeno` |
How will minetest know when to release the memory for the texture? |
| 11:34 |
sfan5 |
it won't |
| 11:34 |
sfan5 |
minetest will cache every texture |
| 11:35 |
Zeno` |
Yes, but how will adding a modifier clarify that situation? |
| 11:35 |
jin_xi |
well, textures are created by name. by adding a name to a dynamic texture only one (current) could be kept |
| 11:38 |
Zeno` |
so why the need for a modifier? |
| 11:38 |
celeron55 |
the way to solve that is to add reference counting to every usage of textures in the client |
| 11:39 |
celeron55 |
which is a rather big task but possibly can be done assuming there are no irrlicht interfaces that actively fight against doing that |
| 11:41 |
jin_xi |
but has this to be done for all textures really? updating ones are a very specific thing. is the texture caching a problem somewhere else? |
| 11:42 |
jin_xi |
because ideally i still think there should be a drawtype which pastes a texture over a node, to allow for sings and such without extra entities |
| 11:43 |
gravgun |
in which way would it "pastes a texture over a node" ? |
| 11:44 |
jin_xi |
idk ;) but it seems silly to need an extra entity per sign just for holding a textures. in some cases it might be needed for interaction |
| 11:49 |
gravgun |
I already have thought about dynamic/custom(generated) textures, but what I can propose would be a big change in the Lua API and how we handle "textures" from there |
| 11:49 |
gravgun |
(cf http://irc.minetest.ru/minetest-dev/2014-10-03#i_3961920 ) |
| 11:49 |
gravgun |
BTW sfan5, still working on the VM thing |
| 11:50 |
jin_xi |
with pasting over i mean something similar to what firelike does |
| 11:54 |
Zeno` |
sfan5, why remove the bug fix tag for a fix that prevents uninitialised variables (objects) being used? |
| 11:55 |
sfan5 |
did I remove that tag? |
| 11:55 |
Zeno` |
looks like it |
| 11:55 |
sfan5 |
oops |
| 11:55 |
sfan5 |
I deleted that label because I didn't see it still has a bug |
| 11:56 |
sfan5 |
we don't even need a "bug" label |
| 11:56 |
sfan5 |
a "bug" label on a pull request automatically means it's a bug fix |
| 11:58 |
Zeno` |
yeah true |
| 11:59 |
Zeno` |
it's kind of a confusing tag if it's a PR :( |
| 11:59 |
Zeno` |
wait, the fix it now a bug? |
| 11:59 |
Zeno` |
this is confusing lol |
| 12:00 |
Zeno` |
sfan5 removed the Bug fix label 18 hours ago; sfan5 added the bug label 4 minutes ago maybe I just need sleep |
| 12:00 |
Zeno` |
o/ |
| 12:43 |
|
shadowzone joined #minetest-dev |
| 12:43 |
|
shadowzone joined #minetest-dev |
| 12:47 |
|
Dragonop_ joined #minetest-dev |
| 12:49 |
Krock |
any comments to 1731 ? |
| 12:50 |
Zeno` |
none further than I made last night |
| 12:51 |
Krock |
yes, I'm waiting for dev comments and (maybe) a +1 |
| 12:51 |
Zeno` |
I am a dec |
| 12:51 |
Zeno` |
dev |
| 12:52 |
Krock |
I mean those with merge privileges |
| 12:52 |
Zeno` |
pfft :p |
| 13:08 |
|
AnotherBrick joined #minetest-dev |
| 13:14 |
|
proller joined #minetest-dev |
| 13:34 |
|
Ritchie joined #minetest-dev |
| 13:40 |
|
ImQ009 joined #minetest-dev |
| 13:51 |
|
Ritchie joined #minetest-dev |
| 13:54 |
|
nore joined #minetest-dev |
| 13:54 |
OldCoder |
Any reason to use mapgen 7 vs 6 ? |
| 13:55 |
sfan5 |
no |
| 13:55 |
sfan5 |
there are some mapgens that use v7 |
| 13:55 |
sfan5 |
but those mods will enable it by themselves anyway |
| 14:11 |
Dragonop |
OldCoder, Ethereal mod uses v7, and makes a lot of biomes |
| 14:12 |
OldCoder |
shadowzone says buggy but Krock disagrees |
| 14:12 |
Dragonop |
is't buggy |
| 14:12 |
OldCoder |
kk |
| 14:12 |
Dragonop |
*isn't |
| 14:13 |
Dragonop |
It's a mapgen that can generate biomes |
| 14:13 |
OldCoder |
kk |
| 14:13 |
Dragonop |
but you have to mod it |
| 14:13 |
OldCoder |
Go on |
| 14:13 |
Dragonop |
Ethereal adds a lot of biomes |
| 14:14 |
Dragonop |
try it |
| 14:14 |
OldCoder |
Wait |
| 14:14 |
OldCoder |
So if I don't have a special mod is it useful? |
| 14:14 |
Dragonop |
You can use it to build stuff, but it's only stone |
| 14:14 |
OldCoder |
Got it |
| 14:14 |
OldCoder |
So if I use it |
| 14:15 |
OldCoder |
without knowing what to do with special mods, bad |
| 14:15 |
Dragonop |
yep |
| 14:15 |
OldCoder |
kk |
| 14:16 |
Dragonop |
Maybe for a creative server, but there are mods that creates a flat world |
| 14:16 |
OldCoder |
kk |
| 14:17 |
sfan5 |
OldCoder: v7 is not buggy but just not finished |
| 14:17 |
OldCoder |
kkty |
| 14:20 |
Zeno` |
It'd be hard for it to be buggy.... /me hides |
| 14:20 |
OldCoder |
kk |
| 14:27 |
|
alexxs joined #minetest-dev |
| 14:27 |
Zeno` |
stuff like float height_mod = (float)(y + 17) / 2.5; is a bit of a worry though |
| 14:29 |
Zeno` |
suggests that the programmer had NFI about implicit casts and promotion |
| 14:31 |
celeron55 |
or maybe 2.5 was 2 previously and it was needed then |
| 14:31 |
celeron55 |
there's nothing wrong explicitly casting stuff in places like that if you ask me |
| 14:32 |
Zeno` |
there is |
| 14:32 |
Zeno` |
it's as bad as doing a = (b * c) * d; |
| 14:32 |
Zeno` |
it calls into doubt the rest of the code |
| 14:33 |
Zeno` |
anyway 2.5 is not float |
| 14:34 |
OldCoder |
|
| 14:36 |
Dragonop |
|
| 14:39 |
celeron55 |
also, yes, probably most of minetest's contributors do not have a fucking idea about implicit casts and promotion |
| 14:40 |
celeron55 |
or at least some of them |
| 14:40 |
OldCoder |
Well, the code will stabilize over time |
| 14:40 |
OldCoder |
Simply curious about the current state for practical reasons |
| 14:52 |
gravgun |
celeron55, wiki's "code style guidelines" says "Use STL", does that mean I should avoid implementing custom conainers? |
| 14:53 |
celeron55 |
gravgun: unless actually needed, yes; it mostly refers to the fact that minetest originally used irrlicht's containers instead of STL |
| 14:53 |
celeron55 |
(which could be mentioned in there...) |
| 14:56 |
gravgun |
I ask cuz' I implemented a custom container that holds many structs of the same type, on top of C realloc'd arrays, because STL is sometimes darn slow and this is somehow performance-critical code (a VM aimed at generating vertices info for completely custom renderers) |
| 15:13 |
|
NakedFury joined #minetest-dev |
| 15:45 |
celeron55 |
well sounds like std::vector would work just fine |
| 15:46 |
celeron55 |
std::vector (and others) can be used without copying stuff by just using resize() and getting a reference to the new element, if that's what you were looking for |
| 15:46 |
celeron55 |
(altough, maybe it doesn't get rid of all of it) |
| 15:49 |
gravgun |
Yes, although std::vector is potentially slower at moving things given it's designed for C++ OOP, and the struct I use was made a POD struct specially to avoid that |
| 15:55 |
|
hmmmm joined #minetest-dev |
| 16:03 |
|
Megaf_ joined #minetest-dev |
| 16:04 |
|
zat joined #minetest-dev |
| 16:08 |
|
Anchakor_ joined #minetest-dev |
| 16:27 |
|
Calinou joined #minetest-dev |
| 16:36 |
|
kaeza joined #minetest-dev |
| 16:55 |
|
rubenwardy joined #minetest-dev |
| 17:39 |
|
paramat joined #minetest-dev |
| 17:42 |
paramat |
nore, please can my boats mod pull be merged? https://github.com/minetest/minetest_game/pull/328 tested and fine tuned for hours in my 'canyon' river mod |
| 17:55 |
paramat |
nore, sfan5, MTgame's new grass (of dirt-with-grass) texture is really bad, dark and miserable, this one is much better as an improved-tiling version of what we had before https://github.com/minetest/minetest_game/pull/181 |
| 17:56 |
paramat |
the new dirt texture is bad too =) |
| 18:05 |
Calinou |
>bad |
| 18:05 |
Calinou |
the new dirt texture we have is quite good |
| 18:05 |
Calinou |
the grass is not supposed to be super bright |
| 18:05 |
Calinou |
this was the problem of Minetest |
| 18:05 |
Calinou |
the new one has a good (not perfect) colour |
| 18:06 |
Calinou |
it would need a recolour to fit anyway |
| 18:06 |
Calinou |
grass is supposed to be quite smooth |
| 18:09 |
|
GrimKriegor joined #minetest-dev |
| 18:19 |
|
gravgun joined #minetest-dev |
| 18:20 |
paramat |
grass is the most visible texture of MTgame, and sets the mood, it used to be bright, fresh, with contrast and crisp detail, as if under a sunny sky. the new one is depressing, looks like grass under a dark sky |
| 18:21 |
kilbith |
well, the new one is a good balance between bright /dark |
| 18:22 |
paramat |
rich fertile dirt is dark brown, almost black, the new dirt is also depressingly lacking in contrast, and is a horrid light brown |
| 18:22 |
paramat |
*rah!* |
| 18:37 |
|
CraigyDavi joined #minetest-dev |
| 18:37 |
|
OldCoder joined #minetest-dev |
| 18:52 |
Calinou |
is the dirt of Minetest always wet though? |
| 18:52 |
paramat |
well ... good point |
| 18:53 |
VanessaE |
actually it is somewhat moist, otherwise the grass would be brown. |
| 18:53 |
VanessaE |
in theory anyway |
| 19:00 |
paramat |
there were actually complaints (quite rightly) about the new textures looking too dark and 'medieval' before they were merged. i wasn't too keen on the previous dirt (too light brown) but at least it had some contrast and detail |
| 19:00 |
VanessaE |
I don't have too much opinion on the textures one way or another. it's too subjective |
| 19:02 |
|
GrimKriegor joined #minetest-dev |
| 19:03 |
Calinou |
the new cobble is good actually |
| 19:04 |
Calinou |
you can spam it without penalty ;) unlike all the other old ones |
| 19:04 |
paramat |
yes i love the new cobble |
| 19:05 |
paramat |
i'm an artist and designer and have strong reactions to visual stuff ... subjectivity goes out the window =) |
| 19:08 |
Calinou |
everyone can callthemselves an artist, even programmers |
| 19:08 |
Calinou |
same goes for designers |
| 19:08 |
kilbith |
Calinou: the new cobble is too dark relative to the stone texture |
| 19:09 |
kilbith |
you can't have darker broken stone if you break the 'raw' stone |
| 19:09 |
kilbith |
(irl) |
| 19:09 |
Calinou |
https://cdn.mediacru.sh/9pt71Ybwkp4o.png |
| 19:09 |
Calinou |
looks fair to me |
| 19:10 |
Calinou |
almost the same |
| 19:10 |
kilbith |
you're not in exterior |
| 19:10 |
kilbith |
compare them under the sunlight |
| 19:14 |
|
Calinou joined #minetest-dev |
| 19:19 |
|
ImQ009 joined #minetest-dev |
| 19:25 |
|
mrtux joined #minetest-dev |
| 19:29 |
|
EvergreenTree joined #minetest-dev |
| 19:31 |
|
paramat left #minetest-dev |
| 20:47 |
|
cg72 joined #minetest-dev |
| 20:51 |
|
cg72 joined #minetest-dev |
| 20:52 |
Krock |
kilbith, I agree (2 hours later) |
| 20:53 |
kilbith |
the current grass is perfect |
| 20:53 |
kilbith |
same for the dirt |
| 20:54 |
kilbith |
sorry, you talked about the cobbles |
| 20:54 |
Krock |
Calinou, the dirt is dry by default (you can see that when using a hoe on dirt) |
| 20:55 |
PenguinDad |
kilbith: the current cobble looks really nice imo http://a.pomf.se/fyelaa.png |
| 20:56 |
Krock |
still, too dark. |
| 20:56 |
kilbith |
yes, unappropriatly dark |
| 20:57 |
Krock |
well, I prefer Cisoun's dirt and dirt_side textures |
| 20:57 |
PenguinDad |
Where is this cobble too dark? o_O |
| 20:57 |
kilbith |
I vomit when I see the Cisoun's dirt/grass |
| 20:58 |
kilbith |
hm, wait |
| 20:58 |
kilbith |
confused |
| 20:58 |
kilbith |
Cisoun textures = current ones ? |
| 20:58 |
Krock |
kilbith, you've got the wrong textures in your mind |
| 20:58 |
kilbith |
^ |
| 20:58 |
Krock |
https://github.com/SmallJoker/base_game/blob/master/mods/default/textures/default_dirt.png |
| 20:59 |
Krock |
https://github.com/SmallJoker/base_game/blob/master/mods/default/textures/default_grass_side.png |
| 21:02 |
|
chchjesus joined #minetest-dev |
| 21:29 |
|
DuDraig joined #minetest-dev |
| 21:30 |
|
gravgun left #minetest-dev |
| 21:58 |
|
paramat joined #minetest-dev |
| 22:02 |
|
Miner_48er joined #minetest-dev |
| 22:04 |
paramat |
'hmmmm: going forward I'd like all new mapgens to use the biome infrastructure'. i assume you mean the biome API of mgv7 (which you want to change), okay that's a relief, less work choosing and creating biomes myself |
| 22:18 |
paramat |
one thing lacking in register decoration is the way it fixes decoration density, i have found that forests only look good if noise is used to vary the density. this means my lua mapgens will always look just that little bit better than core mapgens =) |
| 22:19 |
paramat |
though i understand the API is meant to be simple to use, and noise variable density is probably to complex for it |
| 22:28 |
|
Dragonop joined #minetest-dev |
| 22:35 |
|
iqualfragile joined #minetest-dev |
| 22:39 |
|
mrtux joined #minetest-dev |
| 22:59 |
|
mrtux joined #minetest-dev |
| 23:05 |
|
DuDraig joined #minetest-dev |
| 23:10 |
|
mrtux joined #minetest-dev |
| 23:26 |
|
cg72 joined #minetest-dev |
| 23:31 |
|
cg72 left #minetest-dev |
| 23:32 |
|
cg72 joined #minetest-dev |
| 23:36 |
|
Miner_48er joined #minetest-dev |
