| Time |
Nick |
Message |
| 02:25 |
|
queria^afk joined #minetest-dev |
| 02:45 |
|
olliy joined #minetest-dev |
| 04:08 |
celeron55 |
the SSSCM api has to be enabled right away and slowly grown |
| 04:08 |
celeron55 |
that's the only way it can work |
| 04:08 |
celeron55 |
SSCSM* |
| 04:09 |
celeron55 |
it could literally only support "hello world" at first |
| 04:10 |
celeron55 |
and actual security reviews will have to be done |
| 04:10 |
celeron55 |
it has to be compartmentalized in some such way that it can be dealt specially |
| 04:15 |
|
tekakutli joined #minetest-dev |
| 05:02 |
|
ShadowNinja joined #minetest-dev |
| 05:05 |
|
celeron55_ joined #minetest-dev |
| 05:12 |
|
Calinou joined #minetest-dev |
| 05:13 |
|
nrz joined #minetest-dev |
| 05:13 |
|
m42uko joined #minetest-dev |
| 06:03 |
|
tekakutli joined #minetest-dev |
| 09:08 |
|
entuland joined #minetest-dev |
| 09:25 |
|
specing_ joined #minetest-dev |
| 10:14 |
|
calcul0n_ joined #minetest-dev |
| 10:48 |
|
hecks joined #minetest-dev |
| 12:07 |
hecks |
about sscsm, there is a small feature set which could be handled first that would be immensely useful |
| 12:07 |
hecks |
and it would not be that difficult to secure |
| 12:07 |
hecks |
a scriptable render loop |
| 12:30 |
pgimeno |
[OT] hecks: you may be interested in this thread: https://love2d.org/forums/viewtopic.php?f=4&t=91198 |
| 12:31 |
hecks |
I've already explored everything there is to explore regarding GC lag in luajit |
| 12:32 |
pgimeno |
this is a different case, it's not that much about GC lag as it is about too many traces |
| 12:33 |
hecks |
yeah, you're not allowed to break traces; there's a dozen things that can cause this |
| 12:33 |
pgimeno |
he doesn't |
| 13:33 |
VanessaE |
[07-04 16:52] <rubenwardy> also c55 requires that connecting a server doesn't require any third party services |
| 13:33 |
VanessaE |
while I'd agree in general, there IS a reasonable exception: a server admin might want to use some kind of 2FA for initial sign-ups, which could for example require the client to reach out to a website via CURL to fetch a code or something. |
| 13:36 |
VanessaE |
redcrab had a thing back in his day that somehow sent you an email when you connected, which you had to reply to to get interact; these days that email might instead contain a one-time 2FA code the user has to type-in to the client, which it would match against the aforementioned fetched code. |
| 13:37 |
rubenwardy |
that was a server-side mod |
| 13:37 |
VanessaE |
yes |
| 13:37 |
VanessaE |
point is, clicking a link in such an email would only take the noob to some website, rather than triggering the client |
| 13:37 |
rubenwardy |
for initial signups like you mention there could be a link shown in a formspec that opens in a web browser |
| 13:38 |
VanessaE |
that's a similar limitation |
| 13:38 |
rubenwardy |
the website can be connected to the MT server and update the privs live |
| 13:38 |
VanessaE |
clicking a link in an application outside of MT has no real chance of taking the user back *into* MT to proceed. |
| 13:38 |
rubenwardy |
well you could use minetest:// links if those were added |
| 13:39 |
rubenwardy |
Client-side support for 2FA is super specialist and a bit weird |
| 13:39 |
VanessaE |
a minetest:// URI would perhaps be okay but you're still involving a web browser when something much simpler that stays entirely within MT (from the user's point of view) would do |
| 13:40 |
VanessaE |
but 2FA was merely the first thing that came to minf |
| 13:40 |
VanessaE |
mind* |
| 13:40 |
rubenwardy |
Minetest accounts really aren't privileged to justify 2fa |
| 13:40 |
rubenwardy |
email verification and password resets sure |
| 13:40 |
VanessaE |
it's just an example |
| 13:40 |
VanessaE |
don't read anything into it |
| 13:41 |
rubenwardy |
I'd like some OAuth-like central account system as an alternative authentication method, it would use either auth tokens or certificates to not rely on the central service being online |
| 13:42 |
VanessaE |
NOW THAT I can get behind |
| 13:42 |
rubenwardy |
if it used auth tokens or certificates, then the central account system would only need to be online for when the user first logs into a new device |
| 13:42 |
VanessaE |
when you run as many servers as I do, having a central account system would be nice, especially if it handles bans as well |
| 13:42 |
rubenwardy |
well, for certs at least |
| 13:43 |
rubenwardy |
dealing with cryptography is hard though, even with a library |
| 13:43 |
VanessaE |
(I can only imagine how much of a pain in the ass it can be for that minetest server hosting guy, or Monte48's team) |
| 13:44 |
VanessaE |
(by "handles bans" I mean only auto-synching bans between servers and then letting the servers handle them they way they usually do) |
| 13:49 |
specing |
Well |
| 13:50 |
specing |
it could support querying for bans and reasons for every connecting player |
| 13:50 |
VanessaE |
the big question is, how would you establish identity in the first place though, without making it trivial for the user to "reset" or "clear" it? |
| 13:50 |
specing |
then the local admin could decide whether to reject the player |
| 13:53 |
rubenwardy |
you can't |
| 13:53 |
rubenwardy |
unless you require submitting id cards, you can't establish identity |
| 13:53 |
VanessaE |
nah |
| 13:53 |
VanessaE |
I don't mean THAT degree of ID |
| 13:53 |
rubenwardy |
you can require email addresses, but those are easy to get |
| 13:53 |
VanessaE |
I mean simply ... "uniqueness" |
| 13:54 |
VanessaE |
in a normal setup, server and client exchange certs that only establish "you and me" without knowing "you" == "a specific person out of 8 billion" |
| 13:55 |
VanessaE |
but in a MT or other gaming setup I would imagine we'd at least want to localize "you" to "a specific computer" |
| 13:55 |
rubenwardy |
certificates would be signed by the CAS to verify that the holder successfully logged into the account |
| 13:55 |
VanessaE |
sure |
| 13:55 |
rubenwardy |
a central auth system could do IP grouping (like xban and sban) across more data, although you wouldn't want to expose this to the users or servers |
| 13:55 |
VanessaE |
but if the holder deletes that cert, how does the server know it's the same person when the auth system re-generates a new cert? |
| 13:56 |
rubenwardy |
the certificate contains the username/CAS user id |
| 13:56 |
rubenwardy |
To avoid exposing IP grouping, you would need to have CAS-level banning on server - where the server doesn't get any information unless they've banned that user, and they never get other IPs |
| 13:56 |
rubenwardy |
this is fairly dodgy though and IP-based bans suck |
| 13:56 |
VanessaE |
and if they delete the cert and use a new username and IP? |
| 13:57 |
rubenwardy |
then it's a different user |
| 13:57 |
VanessaE |
is it? |
| 13:57 |
rubenwardy |
for all intents and purposes, yes |
| 13:57 |
VanessaE |
this happens to xban from time to time, the same person signs in from two IPs and two usernames, |
| 13:57 |
VanessaE |
e.g. VPN or something alike |
| 13:58 |
VanessaE |
any centralized auth system (even if it's just central to a particular group of servers) has to defend against that |
| 13:58 |
rubenwardy |
we could use MAC addresses or other hardware IDs to group users, but this is straying into a bad area |
| 13:58 |
VanessaE |
well |
| 13:58 |
VanessaE |
I thought about that actually... |
| 13:58 |
rubenwardy |
there's no good way to defend against it without violating privacy |
| 13:59 |
rubenwardy |
although, idk, I suppose mac addresses don't have the same flaws as IP addresses despite still being changable |
| 13:59 |
VanessaE |
idk about Windows, but on Linux you can install `lshw`, which even if run as a non-priv user provides a lot of info. suppose you required installation of such a tool, hashed its output, and used that along with username and pw |
| 14:00 |
VanessaE |
that would be a fairly strong proof of ID with zero privacy worries |
| 14:00 |
rubenwardy |
an alternative to this would be to have more server-side protections (antispam, antigriefing) and moderators |
| 14:01 |
VanessaE |
which is infeasible in a lot of situations |
| 14:01 |
VanessaE |
sometimes there just aren't enough trustworthy people to go around |
| 14:01 |
rubenwardy |
antispam is something that shouldn't be too hard but Minetest doesn't have much of |
| 14:04 |
VanessaE |
true |
| 14:05 |
specing |
> you can require email addresses, but those are easy to get |
| 14:05 |
specing |
email addresses used by accounts being banned could end up on a blacklist |
| 14:06 |
specing |
The same could be done with subnets for which a lot of ban reports start coming in |
| 14:06 |
VanessaE |
link MT against spamassisssi... assisss.. assassis....... spam killer. (read this in the same way as the opening sequence in "Hot Shots: Part Deux") |
| 14:07 |
VanessaE |
specing: *cough* protonmail *cough* |
| 14:07 |
specing |
I think flux's (?) verbana does the subnet banning |
| 14:07 |
specing |
well, not banning, but everyone new from those subnets comes in with interact/tp removed and is placed in jail |
| 14:09 |
specing |
If e-mail verification is used, it could also delay sending the registration email |
| 14:21 |
|
Fixer joined #minetest-dev |
| 15:47 |
|
behalebabo joined #minetest-dev |
| 15:56 |
|
jonadab joined #minetest-dev |
| 16:02 |
|
hecks joined #minetest-dev |
| 16:53 |
|
lhofhansl joined #minetest-dev |
| 17:40 |
|
Extex joined #minetest-dev |
| 17:50 |
MTDiscord |
<Jordach> It sounds like you’re imagining a problem that has a chance of nearly never occurring |
| 17:51 |
MTDiscord |
<Jordach> It’s extremely rare for one person to be that well organised |
| 17:51 |
MTDiscord |
<Jordach> Even rarer in teams |
| 18:02 |
|
v-rob joined #minetest-dev |
| 18:07 |
|
hecks joined #minetest-dev |
| 18:12 |
|
longerstaff13 joined #minetest-dev |
| 18:13 |
v-rob |
/msg NickServ IDENTIFY v-rob rent-the-salad-today |
| 18:13 |
v-rob |
Shoot, I can't believe I did that |
| 18:14 |
|
Extex joined #minetest-dev |
| 18:15 |
v-rob |
hecks: "a scriptable render loop [for SSCSM]". How do you imagine this? I've been working on Lua interfaces for textures and will make interfaces for 3D rendering as well, but I don't know if what I think is similar to what you're thinking about. |
| 18:15 |
hecks |
I imagine this as a single Lua chunk with no goto or loops allowed |
| 18:15 |
hecks |
that only deals in opaque integer handles |
| 18:16 |
hecks |
the point is to have a set of commands like: push/pop render target, push/pop camera, set rendering "context" (utility pass to use), draw scene with a given context or shader |
| 18:16 |
hecks |
or draw a fullscreen quad with a given material |
| 18:17 |
hecks |
actual resources that this uses may be specified remotely and don't need sscsm api |
| 18:17 |
hecks |
the point is to generalize techniques like postprocessing or deferred rendering or shadow mapping into something that the game can override entirely - a completely scriptable render loop |
| 18:18 |
rubenwardy |
v-rob: XKCD 4 word passwords only work if randomly generated |
| 18:18 |
rubenwardy |
also if you don't paste them in a public chat |
| 18:18 |
rubenwardy |
hm, I guess it's a nonsense sentence so could be random |
| 18:18 |
v-rob |
I changed it already. I accidentally had a space before the slash. |
| 18:19 |
rubenwardy |
common mistake |
| 18:19 |
v-rob |
Still, I somewhat doubt people will try to steal my IRC password. It's not a lucrative position |
| 18:20 |
v-rob |
Anyhow, I have #10801, but it's a higher level API and has no JIT-oriented performance things |
| 18:21 |
hecks |
I imagine the scriptable render loop as its own completely isolated thing |
| 18:21 |
MTDiscord |
<Warr1024> That was still a pretty great password even if it wasn't really secure :-) |
| 18:21 |
VanessaE |
besides why would anyone rent a salad? |
| 18:21 |
rubenwardy |
sounds like a shader |
| 18:21 |
hecks |
just a handful of functions, basically no keywords except if then else local end |
| 18:22 |
v-rob |
So, what I do in the plain (SS)CSM Lua state won't have any bearing on what you want. |
| 18:22 |
hecks |
it's not a shader, it's the rendering loop, simple as that |
| 18:23 |
v-rob |
That's good, I don't want the stuff I'm working on be a potential limiting problem later on. |
| 18:23 |
hecks |
I'll take a look at your api anyway |
| 18:24 |
hecks |
cause I'm redoing materials right now and we might need to collab a bit |
| 18:24 |
v-rob |
Certainly, especially for the 3D rendering PR. I don't want it to be a direct reflection of Irrlicht's API. |
| 18:25 |
hecks |
you seem to have a Texture class for instance |
| 18:25 |
hecks |
and at one point or another I might actually create a Texture class on the engine's side that isn't irrlicht's texture class |
| 18:27 |
hecks |
but okay, in general this doesn't look like it collides with what I do at all |
| 18:27 |
v-rob |
What particular advantages would this non_Irrlicht texture class have? |
| 18:28 |
hecks |
not having to beg Irrlicht for the OpenGL texture handle, pretty much |
| 18:28 |
hecks |
I've got this problem with meshes right now |
| 18:28 |
v-rob |
Couldn't you just modify ITexture then? |
| 18:28 |
hecks |
might have to punch quite a few holes in irrlicht to get all the raw handles on everything to make this work |
| 18:28 |
hecks |
yeah, for now I'll settle for that |
| 18:29 |
hecks |
the end goal is to keep chipping away at irrlicht dependency until nothing remains, right now I'll have to do it for shaders and actually for drawcalls as well |
| 18:30 |
hecks |
but good news, this is an opportunity to do gpu skinning |
| 18:30 |
hecks |
since GLES2 is the target, this will have to live in the vertex shader - but we can do it |
| 18:30 |
hecks |
writing a linear blend skinner isn't a big deal anyhow |
| 18:33 |
sfan5 |
what do we need the OpenGL texture handle for? |
| 18:33 |
sfan5 |
to use it obviously but right now that goes back through irrlicht which then calls whatever gl method you would have called |
| 18:34 |
hecks |
to set the texture uniform my friend |
| 18:34 |
hecks |
when the material is being selected for rendering |
| 18:39 |
|
Extex joined #minetest-dev |
| 18:39 |
|
longerstaff13 joined #minetest-dev |
| 18:39 |
|
hecks joined #minetest-dev |
| 18:39 |
|
v-rob joined #minetest-dev |
| 18:39 |
|
lhofhansl joined #minetest-dev |
| 18:39 |
|
jonadab joined #minetest-dev |
| 18:39 |
|
behalebabo joined #minetest-dev |
| 18:39 |
|
Fixer joined #minetest-dev |
| 18:39 |
|
calcul0n_ joined #minetest-dev |
| 18:39 |
|
specing joined #minetest-dev |
| 18:39 |
|
entuland joined #minetest-dev |
| 18:39 |
|
m42uko joined #minetest-dev |
| 18:39 |
|
nrz joined #minetest-dev |
| 18:39 |
|
Calinou joined #minetest-dev |
| 18:39 |
|
ShadowNinja joined #minetest-dev |
| 18:39 |
|
queria^afk joined #minetest-dev |
| 18:39 |
|
Alias joined #minetest-dev |
| 18:39 |
|
Thomas-S joined #minetest-dev |
| 18:39 |
|
pgimeno joined #minetest-dev |
| 18:39 |
|
wsor4035 joined #minetest-dev |
| 18:39 |
|
freshreplicant[m joined #minetest-dev |
| 18:39 |
|
sfan5 joined #minetest-dev |
| 18:39 |
|
ssieb joined #minetest-dev |
| 18:39 |
|
ivanbu joined #minetest-dev |
| 18:39 |
|
basxto joined #minetest-dev |
| 18:39 |
|
beanzilla joined #minetest-dev |
| 18:39 |
|
Pexin joined #minetest-dev |
| 18:39 |
|
luk3yx joined #minetest-dev |
| 18:39 |
|
Krock joined #minetest-dev |
| 18:39 |
|
pmp-p joined #minetest-dev |
| 18:39 |
|
cheapie joined #minetest-dev |
| 18:39 |
|
\ joined #minetest-dev |
| 18:39 |
|
rubenwardy joined #minetest-dev |
| 18:39 |
|
BuckarooBanzai joined #minetest-dev |
| 18:39 |
|
clavi joined #minetest-dev |
| 18:39 |
|
nore joined #minetest-dev |
| 18:39 |
|
dzho joined #minetest-dev |
| 18:39 |
|
Shara joined #minetest-dev |
| 18:40 |
hecks |
there is the option of just moving this code into irr but i don't like it for two reasons |
| 18:40 |
hecks |
one is that it's contrary to the goal of getting rid of that thing |
| 18:41 |
hecks |
two is that irrlicht is a different license; i'd rather keep this code some flavor of copyleft |
| 18:43 |
sfan5 |
okay makes sense |
| 18:44 |
hecks |
irrmt needs a better gitignore |
| 18:48 |
sfan5 |
I believe you when you say Irrlicht sucks and it shouldn't be in the way of improving much needed parts but getting rid of every small bit of Irrlicht is such a mountainous task that's going to suck up lots of time for questionable benefit |
| 18:49 |
sfan5 |
so I think the mid-term goal looks somehat like "move some rendering and GUI out of irrmt" and not "move everything out of irrmt" |
| 18:49 |
sfan5 |
+w |
| 18:50 |
hecks |
let's re-evaluate this then |
| 18:50 |
hecks |
irrlicht is big but we use less than half of it |
| 18:51 |
sfan5 |
maybe half of classes but not half of "parts" (whatever that may mean) |
| 18:51 |
hecks |
irr has a ton of abstractions because it supports multiple (awful) renderers, but we just discarded those |
| 18:51 |
hecks |
and for wrangling OpenGL, it's actually presenting us an API more poor than GL itself |
| 18:52 |
sfan5 |
from the top of my head I see little value in rewriting these: OS API interactions for windowing and GL context setup, mesh/media file parsing, ZIP archiving stuff, primitives like vectors |
| 18:52 |
hecks |
it provides us with a lot of asset formats, but we use only a handful of those |
| 18:52 |
hecks |
it provides us with a skeletal mesh animator, but the most trivial one you could imagine |
| 18:52 |
hecks |
and skinning, but it's also trivial linear blend skinning, and CPU only |
| 18:53 |
hecks |
the parts that we sort of use, we can carve out and absorb |
| 18:53 |
hecks |
like the .x loader which is actually so non-compliant with directx it's almost a fork |
| 18:54 |
hecks |
(you can produce .x scenes that only work in irrlicht) |
| 18:55 |
hecks |
it wrangles GL proc addresses for us, but there's better tools for this |
| 18:55 |
hecks |
it provides events but it's so crappy at it that people are working to replace that too |
| 18:55 |
hecks |
and finally a scene graph which is also painfully naive and we barely use it |
| 18:56 |
hecks |
so in reality, irrlicht provides very few things of value that we can't just cut and paste into MT itself |
| 18:57 |
sfan5 |
that is true |
| 18:57 |
|
behalebabo joined #minetest-dev |
| 18:58 |
hecks |
deprecating non-GL paths and redoing shaders will already blow a huge chunk out of irr's reasons to exist |
| 18:59 |
hecks |
and |
| 18:59 |
hecks |
irrlicht is costing us a TON in maintenance that isn't noticeable on the surface |
| 18:59 |
hecks |
the headers are pretty poorly made and possibly at least double the compile times |
| 19:00 |
hecks |
we probably have a lot of questionably structured code just because of how irrlicht forces us to do things |
| 19:00 |
hecks |
because we're an engine using an engine |
| 19:02 |
|
Extex joined #minetest-dev |
| 19:02 |
sfan5 |
differently put: when you say "get rid of" it reads as "just let me rewrite this" to me, but there are parts where we don't want to do this |
| 19:02 |
hecks |
be specific |
| 19:03 |
sfan5 |
I gave examples above, just restating my point |
| 19:03 |
hecks |
those are the parts i have no plans on touching |
| 19:04 |
hecks |
except gl wrangling maybe, SDL would do this better |
| 19:04 |
sfan5 |
sure |
| 19:05 |
sfan5 |
just saying those parts exist |
| 19:05 |
hecks |
but asset importers are fine (they can be a little untangled but they're good otherwise) |
| 19:05 |
sfan5 |
so if we want to get rid of irrmt entirely there eventually needs to be consensus about what to do with the leftovers |
| 19:05 |
hecks |
pull them down to MT itself |
| 19:05 |
sfan5 |
importing a large chunk of foreign code feels bad |
| 19:05 |
sfan5 |
but I have no better idea |
| 19:05 |
hecks |
don't just blindly cut and paste of course |
| 19:06 |
hecks |
but things like asset importers don't sound that hairy to rework to me |
| 19:06 |
sfan5 |
you mean do code review on it like you'd do on fresh code? |
| 19:06 |
hecks |
yes |
| 19:07 |
hecks |
having it all in one repo would definitely help maintenance wise |
| 19:07 |
sfan5 |
definitely |
| 19:07 |
hecks |
one less thing to maintain, compile, port |
| 19:10 |
hecks |
just chip away one feature at a time and we can do it |
| 19:11 |
sfan5 |
gonna be a long process |
| 19:11 |
hecks |
long in actual time, not in man hours |
| 19:12 |
hecks |
but by 2023ish? it can be gone |
| 19:12 |
|
Extex joined #minetest-dev |
| 19:12 |
sfan5 |
mt is notoriously short on man hours |
| 19:12 |
hecks |
well, yeah |
| 19:13 |
hecks |
i pretty much tricked myself into doing this |
| 19:13 |
hecks |
would rather work on mibi |
| 19:13 |
sfan5 |
you did |
| 19:13 |
hecks |
https://paste.uguu.se/?c43265e2de5b4ab8#4fqNs8KYeHoZ5hGbgwBCcTsoGQvuP3kyMnUeRB5Prizz |
| 19:14 |
hecks |
the other stuff I'm also doing, on a slow burn |
| 19:14 |
hecks |
meshes, renderer, scene graph |
| 19:15 |
|
v-rob joined #minetest-dev |
| 19:16 |
hecks |
what makes this easier is that i've made an engine before and i can basically just port bits of it as needed |
| 19:32 |
v-rob |
On the GUI remake: I'm considering a change of plans. I think it probably would be best to implement the core GUI classes in C++, not Lua, like I previously wanted to. Although I think Lua would be a much nicer choice for a lot of reasons, I think I essentially have to do it in C++, ultimately because of security issues and code that isn't and can't be exposed to Lua. So, yeah, I think I'll be moving what code I have to the C++ side and expose it to |
| 19:32 |
v-rob |
Lua from there. |
| 19:34 |
v-rob |
One direct advantage, however, is that I can design the SSM API first, and the much less important but fancier [SS]CSM API can be done later. |
| 19:43 |
v-rob |
To clarify the security issues: mainly, this consists of functions that shouldn't be exposed to Lua that the GUI needs, and also things like the pause menu or other GUI globals being able to be overwritten, which can easily cause problems, especially if we got SSCSM. And a few other miscellaneous issues. |
| 19:44 |
v-rob |
Anyhow, just wanted to let people know, even though it probably doesn't mean much to anyone. |
| 20:18 |
|
behalebabo joined #minetest-dev |
| 20:22 |
|
Fixer_ joined #minetest-dev |
| 20:33 |
pgimeno |
#10801 |
| 20:35 |
pgimeno |
https://github.com/minetest/minetest/pull/10801 -- Add CSM 2D Drawing API by v-rob |
| 20:35 |
pgimeno |
#10801 |
| 20:36 |
|
kilbith joined #minetest-dev |
| 20:36 |
pgimeno |
that's until ShadowBot is back (poking @ShadowNinja) |
| 20:36 |
rubenwardy |
#10801 |
| 20:36 |
pgimeno |
https://github.com/minetest/minetest/pull/10801 -- Add CSM 2D Drawing API by v-rob |
| 20:55 |
|
Lone_Wolf joined #minetest-dev |
| 20:55 |
kilbith |
v-rob: https://github.com/minetest/minetest/pull/10265 why is still pending? |
| 21:26 |
|
specing_ joined #minetest-dev |
| 21:53 |
|
v-rob joined #minetest-dev |
| 21:54 |
|
Extex joined #minetest-dev |
| 21:59 |
|
kilbith joined #minetest-dev |
| 22:04 |
|
kilbith joined #minetest-dev |
| 22:19 |
|
longerstaff13 joined #minetest-dev |
| 22:53 |
Pexin |
/3/2 |
| 23:03 |
specing |
wooo drawing in CSMs |
| 23:04 |
specing |
v-rob: have you checked out SpringRTS's drawing API? |
| 23:46 |
|
AliasAlreadyTake joined #minetest-dev |
