| Time |
Nick |
Message |
| 00:43 |
|
doserj joined #minetest-dev |
| 07:20 |
|
VanessaE joined #minetest-dev |
| 08:18 |
|
jin_xi joined #minetest-dev |
| 08:48 |
|
iqualfragile joined #minetest-dev |
| 09:07 |
|
rsiska joined #minetest-dev |
| 09:10 |
sfan5 |
i sometimes hate git |
| 09:11 |
VanessaE |
why now? |
| 09:12 |
sfan5 |
i did "git add ." but i was in the build directory |
| 09:12 |
VanessaE |
oops |
| 09:13 |
|
BackupCoder joined #minetest-dev |
| 09:13 |
sfan5 |
it wants to commit total junk, using "git reset --hard HEAD^" i would lose my build dir, "git reset --soft HEAD^" just resets the commit, it keeps the ile in the commit quene |
| 09:13 |
sfan5 |
*files |
| 09:16 |
sfan5 |
does this look useful? https://github.com/sfan5/minetest/commit/72283d6f7493869a766c472bd9f666a54b76bf4b |
| 09:18 |
|
BackupCoder joined #minetest-dev |
| 09:18 |
|
BackupCoder joined #minetest-dev |
| 09:19 |
|
BackupCoder joined #minetest-dev |
| 09:20 |
|
BackupCoder joined #minetest-dev |
| 09:22 |
|
BackupCoder joined #minetest-dev |
| 09:35 |
|
BackupCoder joined #minetest-dev |
| 09:50 |
|
Calinou joined #minetest-dev |
| 10:16 |
|
Penguin_ joined #minetest-dev |
| 10:16 |
|
Penguin_ left #minetest-dev |
| 10:24 |
kahrl |
sfan5: that's the server's locale, in a mod you're probably more interested in the clients' locales |
| 10:28 |
sfan5 |
oh, right didn't notice that one |
| 10:35 |
sfan5 |
the client links, for the server it outputs a bunch of: |
| 10:35 |
sfan5 |
CMakeFiles/minetestserver.dir/objects.a(main.cpp.obj):main.cpp:(.text+0x309f): undefined reference to `__imp__libintl_gettext' |
| 10:37 |
sfan5 |
seems to be related to: https://github.com/celeron55/minetest/pull/458 |
| 10:43 |
|
darkrose joined #minetest-dev |
| 10:43 |
|
darkrose joined #minetest-dev |
| 10:59 |
|
jyfl987 joined #minetest-dev |
| 12:06 |
|
PilzAdam joined #minetest-dev |
| 13:10 |
thexyz |
https://github.com/celeron55/minetest/pull/344 |
| 13:12 |
|
Jordach joined #minetest-dev |
| 13:28 |
|
iqualfragile joined #minetest-dev |
| 14:09 |
celeron55 |
there should be no way for a mod to get the locale of the server |
| 14:09 |
celeron55 |
it's completely irrelevant |
| 14:10 |
celeron55 |
localization of mods should work so that to strings that are sent to the client, a mod can, instead of a string, put a table like {en="foo", de="bar"} |
| 14:11 |
celeron55 |
and then the engine will do things in some way that results in the right stuff showing up on clients |
| 14:12 |
celeron55 |
either sends the full content of the table or knows the locale of each client |
| 14:13 |
celeron55 |
that is the only way i can see actually working; anything else is likely just dumb |
| 14:13 |
sfan5 |
ok, i closed the pull |
| 14:14 |
celeron55 |
then if somebody wishes to create some kind of a gettext-like thing, it's easy to implement completely in lua (instead of the table, use something like thegettextything("english text") |
| 14:15 |
sfan5 |
idea: mod can get locale of each client |
| 14:15 |
celeron55 |
if somebody has a better overall idea, i'm ready to judge it 8) |
| 14:16 |
sfan5 |
a gettext-thingy uses that to change the string accordingly |
| 14:16 |
sfan5 |
</idea> |
| 14:17 |
celeron55 |
won't work, because there are many situations when a mod must generate a text that will be sent to everyone |
| 14:17 |
thexyz |
sfan5: that won't work with initial node definition, for example |
| 14:17 |
celeron55 |
and remaking those so that a mod controls what ends up to each client is likely not a good idea |
| 14:17 |
sfan5 |
hook into minetest.send_chat_message, iterate over players and send in individual language |
| 14:18 |
thexyz |
inb4 c55 rage |
| 14:18 |
celeron55 |
...yeah, chat works, but how about all the 100000 other places? |
| 14:18 |
sfan5 |
hook into minetest.register_node? |
| 14:18 |
thexyz |
too hacky |
| 14:18 |
sfan5 |
but doable in lua |
| 14:19 |
sfan5 |
*do-able |
| 14:19 |
* celeron55 |
shakes his head and goes away |
| 14:19 |
thexyz |
it won't work anyway |
| 14:19 |
thexyz |
ok, fine |
| 14:19 |
thexyz |
I guess my freetype thing is ok them |
| 14:39 |
|
rubenwardy joined #minetest-dev |
| 15:16 |
PilzAdam |
thexyz, https://github.com/celeron55/minetest/pull/470 |
| 15:18 |
thexyz |
why've you altered treegen.h to include environment.h without changing anything else in treegen.h/cpp? |
| 15:19 |
PilzAdam |
because there were some errors while compiling |
| 15:19 |
RealBadAngel |
i havent noticed any, what was those errors? |
| 15:21 |
PilzAdam |
it works if I include it in mapgen_flat.cpp, but I dont need it there |
| 15:21 |
PilzAdam |
RealBadAngel, basically ServerEnvironment not defined |
| 15:22 |
RealBadAngel |
no such errors here |
| 15:23 |
PilzAdam |
it works if you include environment.h before treegen.h |
| 15:23 |
PilzAdam |
(wich is the case in the other mapgen files) |
| 15:25 |
PilzAdam |
I thought adding it to treegen.h makes more sence, so not every other file has to include environment.h when including treegen.h |
| 15:27 |
RealBadAngel |
as far as i remember c55 said somethin about including long files and being careful bout it |
| 15:27 |
RealBadAngel |
i may have it included before but decided not to |
| 15:28 |
RealBadAngel |
at least im sure i removed some headers |
| 15:29 |
celeron55 |
eh |
| 15:29 |
celeron55 |
just put class Environment; in there |
| 15:29 |
celeron55 |
or whatever it is |
| 15:29 |
celeron55 |
including headers in headers shouldn't be done when not necessary |
| 15:32 |
PilzAdam |
fixed. |
| 15:34 |
|
hmmmm joined #minetest-dev |
| 15:35 |
PilzAdam |
hmmmm, https://github.com/celeron55/minetest/pull/470 |
| 15:36 |
hmmmm |
hrmm i don't know if we actually want to do that |
| 15:36 |
hmmmm |
we can already get a map that's flat enough by setting both offset and height to 0 for v6 and disabling caves |
| 15:37 |
hmmmm |
(note that because steepness is bounded by 1.5 in the ground level code, that will never be 0) |
| 15:38 |
PilzAdam |
well, its easier to add mg_name = flat than doing all the other stuff in v6 |
| 15:38 |
hmmmm |
not if it's well documented |
| 15:38 |
PilzAdam |
and also in flat mapgen there are no deserts etc, |
| 15:38 |
hmmmm |
my way would require 2 lines in minetest.conf and eliminate all code |
| 15:38 |
hmmmm |
that would needed to be added |
| 15:39 |
PilzAdam |
if we have GUI config its a lot easier to select flat |
| 15:41 |
hmmmm |
oh, i'm sorry |
| 15:41 |
hmmmm |
b is limited to 0.5 at the lowest |
| 15:42 |
hmmmm |
a = 0.5 + 0.5 * (-.2 + noise_height_select), we can't eliminate the variance in noise_height_select either |
| 15:42 |
hmmmm |
because the offset/scale is not applied |
| 15:43 |
hmmmm |
alright, PlizAdam, if you want to add flat mapgen the right way, here's what you do... |
| 15:44 |
hmmmm |
after noise_height_select->perlinMap2D(); in makeChunk, add noise_height_select->transformNoiseMap(); |
| 15:45 |
hmmmm |
now on line 43, for some reason, i have 0.5 as the offset, but it didn't matter before because it was ignored. change the first number in that definition from 0.5 to 0.0 |
| 15:45 |
hmmmm |
and finally on line 358, change that call from NoisePerlin2DNoTxfmPosOffset to NoisePerlin2DPosOffset |
| 15:46 |
RealBadAngel |
celeron55, that stuff showin me tabs and spaces is indeed quite usable. im cleanin now Technic mod out of lots invisible stuff... |
| 15:46 |
hmmmm |
one more thing actually, in defaultsettings.cpp now on line 183, change the 0.5 in the first field there to 0.0 too |
| 15:47 |
hmmmm |
sorry PlizAdam, I know you probably wanted to add in more code, but our goal is to minimize the amount of redundant stuff added |
| 15:48 |
PilzAdam |
it is Pilz not Pliz |
| 15:48 |
PilzAdam |
:-) |
| 15:50 |
darkrose |
it's p<tab> |
| 16:02 |
PilzAdam |
hmmmm, there is still one thing: my flat mapgen is a lot faster than the modified v6 |
| 16:02 |
|
iqualfragile joined #minetest-dev |
| 16:03 |
hmmmm |
in terms of amount of code executed, sure. but it's not noticable |
| 16:03 |
hmmmm |
the majority of the cpu time is taken up by the lighting update |
| 16:29 |
|
Calinou joined #minetest-dev |
| 16:37 |
VanessaE |
hmmmm: maybe it isn't noticable, but remember that every cycle you save on something that can be optimized is a cycle you can put toward something else, perhaps that cannot be optimized further. |
| 16:37 |
VanessaE |
(not that a flat mapgen is in particularly high demand) |
| 17:01 |
hmmmm |
vanessa, about the whole emergethread freezing up thing, you do realize you're primarily having that problem because of the large amount of mods, right? |
| 17:02 |
hmmmm |
they are 1). poorly coded 2). extremely slow to execute thanks to lua 3). emergethread cannot run while the code in a mod is being run |
| 17:02 |
VanessaE |
I would have thought so, until I noticed it happening even in singleplayer with just one mod (moretrees) running. |
| 17:03 |
VanessaE |
(and as you know, that mod is *very* fast) |
| 17:03 |
VanessaE |
even worldedit is enough to kill the emergethread. |
| 17:03 |
hmmmm |
it's a problem that the majority of people don't have though |
| 17:03 |
VanessaE |
no other mods but that - just copy 100-200 thousand nodes from one place to another. Emergethread will choke. |
| 17:03 |
hmmmm |
100-200 nodes being copied? well, duh |
| 17:04 |
hmmmm |
what did you honestly expect |
| 17:04 |
VanessaE |
wait wait.. |
| 17:04 |
VanessaE |
I don't mean the Lua part - I mean the server 'catching up' after the copy is finished,. |
| 17:04 |
hmmmm |
yeah |
| 17:04 |
hmmmm |
that's normal |
| 17:04 |
VanessaE |
after 5 minutes? |
| 17:04 |
hmmmm |
what worldedit uses to accomplish its goal is extremely, EXTREMELY unsuitable |
| 17:05 |
VanessaE |
true, but I suppose that's the best that can be done at present |
| 17:06 |
RealBadAngel |
there was engine patch that speeded up emerge thread partially |
| 17:06 |
VanessaE |
but point is, the more content the map has, the easier it is to make emergethread choke -- even with no mods installed at all. even the unknown blocks leftover after removing moretrees on a well-populated map sometimes chokes it. |
| 17:06 |
hmmmm |
i'm gonna have to say, basically everything in minetest, especially before I started working on it, is as inefficient as possible |
| 17:06 |
RealBadAngel |
but it was mentioned there theres lotsa more to do about it |
| 17:06 |
hmmmm |
it was coded so that it runs, but it runs like shit |
| 17:07 |
hmmmm |
things that used to make me cringe before i started looking at this code were ubquitous |
| 17:08 |
hmmmm |
it's like gore |
| 17:08 |
hmmmm |
worldedit was one of those things. |
| 17:08 |
VanessaE |
heh |
| 17:08 |
VanessaE |
well like I said, even without any mods loaded at all. |
| 17:09 |
VanessaE |
try this: |
| 17:09 |
hmmmm |
you know i used to wonder how it was possible, on modern processors, for things to be slow |
| 17:09 |
hmmmm |
now i know exactly what's needed |
| 17:10 |
VanessaE |
Delete all mods. Install worldedit. Make a fresh map. Copy say 100x100x100 from anywhere to anywhere else. Time how long it takes to get from the Enter key to "xxxxxx nodes copied". Now time how long it takes from that moment until the map has redrawn to match the result of the copy. Now shut down, remove worldedit, restart. The map will still load slowly around the copied area. |
| 17:11 |
VanessaE |
it's the update step after worldedit has finished copying, and the subsequent reload of the map after a restart where the unexpectedly slow response is. |
| 17:12 |
VanessaE |
100k nodes should be nearly instantaneous to reload. That's only, what, a meg or two of map data? |
| 17:12 |
VanessaE |
(well that 100^3 is a million, but you get the point) |
| 17:13 |
hmmmm |
but 'slowly' is subjective, and i personally expect things to be slow |
| 17:13 |
hmmmm |
100^3 nodes is a lot though for lua |
| 17:13 |
VanessaE |
nononono |
| 17:13 |
VanessaE |
you're missing my point. |
| 17:14 |
hmmmm |
after shutting down and letting it reload though |
| 17:14 |
VanessaE |
yeah |
| 17:14 |
hmmmm |
it has to reload everything else too |
| 17:14 |
hmmmm |
all the other blocks |
| 17:14 |
hmmmm |
there are a whole lot of them |
| 17:14 |
VanessaE |
fresh map.... |
| 17:14 |
hmmmm |
doesn't matter |
| 17:14 |
VanessaE |
hrm |
| 17:14 |
hmmmm |
what you say is slow is actually perfectly normal |
| 17:16 |
VanessaE |
taking 5 minutes to reload less than a million nodes after a copy is *not* normal..... |
| 17:16 |
RealBadAngel |
https://github.com/celeron55/minetest/pull/432 |
| 17:16 |
VanessaE |
especially on a system with a good SSD and a hell of a fast video card |
| 17:16 |
hmmmm |
both irrelevant to block loading |
| 17:16 |
RealBadAngel |
when it is normal, why this code speeds up emerge thread? |
| 17:17 |
VanessaE |
hmmmm: a fast disk from which to load the map is not relevant? *confused* |
| 17:18 |
hmmmm |
it takes hardly any time at all to load the blocks from the disk |
| 17:18 |
hmmmm |
the problem is that all the other stuff is so CPU intensive |
| 17:18 |
VanessaE |
other stuff such as the lighting update? |
| 17:18 |
hmmmm |
you might be fooled into thinking that a good computer can play minetest well.. you'd be wrong |
| 17:18 |
hmmmm |
yes, for one |
| 17:18 |
VanessaE |
I see. |
| 17:18 |
hmmmm |
basically EVERYTHING takes at the very least 40ms to completely emerge a block |
| 17:19 |
hmmmm |
now multiply that by the number of blocks actually being loaded |
| 17:19 |
VanessaE |
that's horrible. |
| 17:19 |
hmmmm |
you can understand why things are slow now, can't you |
| 17:19 |
VanessaE |
mmhmm |
| 17:19 |
hmmmm |
man i want to nuke minetest sometimes and start all over from scratch and do everything right |
| 17:19 |
VanessaE |
I remember your commentary the other day about 40 vs 400 or something, emergethread just sitting there with its virtual thumb up its ass waiting :-) |
| 17:20 |
hmmmm |
but can't do that |
| 17:22 |
VanessaE |
well regarding efficiency in Lua, at least that can be taken care of with LuaJIT is put into use. |
| 17:22 |
VanessaE |
to a degree anyway |
| 17:22 |
hmmmm |
it's not a silver bullet |
| 17:22 |
VanessaE |
I know. |
| 17:22 |
VanessaE |
but executing CPU-specific machine code has to be faster than interpreting p-code ;) |
| 17:23 |
VanessaE |
(at least, it used to be in the old days) |
| 17:23 |
hmmmm |
there's still a lot of effort that should be put into making lua code fast |
| 17:23 |
VanessaE |
indeed |
| 17:23 |
VanessaE |
more API hooks to handle stuff that's always gonna be slow in Lua |
| 17:23 |
hmmmm |
you see, this really sucks.. if it were up to me, i'd leave lua completely out, because it opens the door wide for bottom-of-the-barrel scripters |
| 17:23 |
VanessaE |
(such as the aforementioned copy operation) |
| 17:24 |
hmmmm |
and they're going to write some really bad, slow code |
| 17:24 |
hmmmm |
in addition to an infrastructure that's already slow |
| 17:24 |
hmmmm |
and more slow code in the engine that has to wait for super-slow code in lua to finish |
| 17:25 |
VanessaE |
yeah |
| 17:25 |
hmmmm |
and here i am with an e3-1230v2, practically the king of CPUs, i can shred absolutely everything else, and here minetest is being completely choppy for no discernable reason |
| 17:26 |
VanessaE |
same here. |
| 17:26 |
VanessaE |
my Phenom 1055T may not be top of the line, but it isn't exactly a 6502 either. |
| 17:27 |
hmmmm |
but the worst part is that everything is so difficult to optimize because there's so much of it piled on top of eachother |
| 17:27 |
hmmmm |
so much more work |
| 17:32 |
|
Calinou joined #minetest-dev |
| 17:37 |
PilzAdam |
thexyz, add src/cguittfont/* to .gitignore in ttf branch |
| 17:48 |
thexyz |
PilzAdam: why? |
| 17:49 |
PilzAdam |
because jthread, lua etc. are there too |
| 17:49 |
thexyz |
nope |
| 17:51 |
PilzAdam |
oh, well, then add the build files of it |
| 17:54 |
PilzAdam |
thexyz, also: the win build is broken; it compile correctly (with -DENABLE_FREETYPE=0), but when running the .exe it crashes |
| 17:55 |
thexyz |
hm.. |
| 17:55 |
PilzAdam |
terminate called after throwing an instance of 'std::runtime_error' |
| 17:55 |
PilzAdam |
what(): locale::facet::_S_create_c_locale name not valid |
| 18:01 |
thexyz |
do you compile it with gettext enabled? |
| 18:01 |
PilzAdam |
yep |
| 18:03 |
thexyz |
does it reproduce with gettext disabled? |
| 18:06 |
PilzAdam |
yep |
| 18:08 |
thexyz |
ok, i'll look into it |
| 18:08 |
thexyz |
later |
| 18:08 |
thexyz |
some day |
| 18:21 |
celeron55 |
hmm so i hear the block loading crap is because of mods using all of the main server thread time with the environment locked? |
| 18:21 |
celeron55 |
sounds plausible |
| 18:22 |
celeron55 |
a simple workaround to keep everyone a bit happier and more knowledgeable would be to automatically measure it and drop some env steps if needed, and track those somewhere where they can be observed |
| 18:23 |
celeron55 |
so people can learn how usual a problem it is |
| 18:24 |
celeron55 |
as hmmmm said, it's inevitable that random mods are going to eat all CPU because of inexperienced coders try to do much things in a slow language |
| 18:24 |
celeron55 |
there isn't really any direct solution to it other than not having sucky mods 8) |
| 18:25 |
celeron55 |
or not having so many of them |
| 18:26 |
Exio |
i still think having small functions like the generate ore and things are something what should be done in "raw C++" without lua |
| 18:26 |
celeron55 |
of course |
| 18:27 |
hmmmm |
putting the ore generation back in C++ would shave 90ms off of block generation time (for me; probably more for other people) |
| 18:27 |
celeron55 |
it's how one is supposed to use an embedded scripting language |
| 18:27 |
Exio |
hmmmm: in what cpu? |
| 18:27 |
hmmmm |
e3-1230v2 |
| 18:27 |
Exio |
in this netbook (yes, i know) the ore generation takes... a bit |
| 18:28 |
celeron55 |
there isn't really any reason why it is in Lua other than me now wanting to implement stuff in C++ because it seemed like the mapgen is going to get a lot of rework in the future |
| 18:28 |
celeron55 |
but that ended up taking a full year before happening 8) |
| 18:28 |
celeron55 |
s/now/not/g |
| 18:28 |
celeron55 |
-g |
| 18:29 |
hmmmm |
on_generate is here to stay though. the only plausible way to fix that is to add LuaJIT, and the VoxelManipulator interface |
| 18:30 |
Exio |
VoxelManipulator? |
| 18:30 |
hmmmm |
it would probably be nice if we did the envlock in l_set_node() and what not. |
| 18:32 |
celeron55 |
it would be needed practically in every lua function whatsoever, (and also that will force the connection lock to be done so too) |
| 18:32 |
PilzAdam |
thexyz, the same error happens with ENABLE_FREETYPE=1 |
| 18:32 |
hmmmm |
that's fine, look at the alternative |
| 18:33 |
celeron55 |
i'm not saying it's not a good idea 8) |
| 18:34 |
celeron55 |
there is an overhead in mutexes too though |
| 18:35 |
celeron55 |
in one very early version of minetest, i tried locking the equivalent of some kind of an environment mutex on a basis of node accesses |
| 18:35 |
celeron55 |
all i can say about that is nope |
| 18:35 |
hmmmm |
it'd probably be a lot more on a server with many clients, but i noticed that the locks get acquired immediately, in 30ms, or 400ms |
| 18:36 |
hmmmm |
my response to that is... with VoxelManipulator in place, when would you ever need to do a tight loop to set blocks within Lua |
| 18:36 |
celeron55 |
sounds like how it probably goes (400ms being some on_generate delay and 30ms being an environment step) |
| 18:38 |
celeron55 |
by the way, the lua voxelmanipulator thing probably needs to be implemented so that it can be used (in addition to some other way) so that you just flip it on, use the regular env:set_node stuff and then flip it off (or return from lua) and it blits the stuff and updates lighting |
| 18:38 |
hmmmm |
another option might be to expose a "begin block setting" and "end block setting" api in lua, and we fix up everybody's mod to use that and instruct developers of more obscure mods and new folks to add that |
| 18:38 |
hmmmm |
as for the other stuff... |
| 18:38 |
hmmmm |
if that's not called as often, then it'd suffice to put the locking right in there |
| 18:39 |
hmmmm |
oh yeah that is a good idea, i didn't think of that. |
| 18:39 |
hmmmm |
env:set_node will actually call some builtin lua function to do that |
| 18:39 |
hmmmm |
and that'll maintain the buffer, or we'll maintain the buffer in the core |
| 18:40 |
celeron55 |
have you measured the general set_node overhead and what it consists of? |
| 18:40 |
hmmmm |
a lot |
| 18:40 |
hmmmm |
i haven't but i know it's a lot |
| 18:40 |
hmmmm |
too much |
| 18:40 |
celeron55 |
have some kcallgrind graph to show or something? |
| 18:40 |
celeron55 |
eh... kcachegrind |
| 18:40 |
celeron55 |
whatever |
| 18:41 |
hmmmm |
btw what did you think about using RCU for mapblocks |
| 18:42 |
celeron55 |
dunno |
| 18:43 |
celeron55 |
i'll try to take a quick callgrind run of this and see what set_node looks like |
| 18:44 |
celeron55 |
(ehm.... i mean, as quick as it gets) |
| 18:47 |
celeron55 |
yeah... not even in game yet |
| 18:48 |
celeron55 |
*imaginary whistling* |
| 18:48 |
thexyz |
PilzAdam: odd |
| 18:49 |
celeron55 |
*rocks on chair* |
| 18:49 |
PilzAdam |
thexyz, I added the build to http://forum.minetest.net/viewtopic.php?id=4547 so that real windows users can test it |
| 18:50 |
PilzAdam |
but i doubt that its wine only |
| 18:50 |
celeron55 |
ooh, the screen updated, to show that media is still at 0% in a local game... |
| 18:51 |
Exio |
valgrind + mt == between 0 to 0 FPS here :P |
| 18:51 |
celeron55 |
it's like wait for a day, and then see a frame once a minute |
| 18:52 |
celeron55 |
and this is --tool=callgrind, not the regular memory checker |
| 18:52 |
celeron55 |
this is slower than anything ever |
| 18:53 |
celeron55 |
yeah, then i spawn in a watery sand pit |
| 18:53 |
celeron55 |
at 1 frame per 30s |
| 18:54 |
|
rsiska joined #minetest-dev |
| 19:23 |
celeron55 |
hell, this is just useless |
| 19:23 |
celeron55 |
running only the server under callgrind might be a bit useful |
| 19:24 |
celeron55 |
somebody else can spend the time for that... if they feel the need for some torture |
| 19:24 |
celeron55 |
everybody needs some torture now and then, right? |
| 19:25 |
hmmmm |
no |
| 19:55 |
PilzAdam |
thexyz, the gettext win build works with export LC_ALL=C |
| 19:55 |
PilzAdam |
s/gettext/ttf |
| 20:11 |
|
SpeedProg joined #minetest-dev |
| 20:24 |
|
SpeedProg1 joined #minetest-dev |
| 20:57 |
|
iqualfragile1 joined #minetest-dev |
| 21:16 |
|
Exio joined #minetest-dev |
| 23:41 |
|
BackupCoder joined #minetest-dev |
| 23:52 |
|
jx8p joined #minetest-dev |
| 23:53 |
|
jx8p left #minetest-dev |
