| Time |
Nick |
Message |
| 00:03 |
MTDiscord |
<savilli> sad but expected |
| 00:53 |
|
calcul0n_ joined #minetest-dev |
| 00:53 |
|
Alias2 joined #minetest-dev |
| 01:39 |
|
fluxionary joined #minetest-dev |
| 03:29 |
|
queria^clone joined #minetest-dev |
| 03:33 |
|
queria^clone joined #minetest-dev |
| 04:15 |
|
olliy1or joined #minetest-dev |
| 04:16 |
|
olliy joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:13 |
|
v-rob joined #minetest-dev |
| 06:35 |
|
tekakutli joined #minetest-dev |
| 07:47 |
|
jonadab joined #minetest-dev |
| 08:04 |
|
Yad joined #minetest-dev |
| 09:02 |
|
calcul0n_ joined #minetest-dev |
| 10:44 |
|
appguru joined #minetest-dev |
| 10:44 |
|
Fixer joined #minetest-dev |
| 11:24 |
|
hlqkj joined #minetest-dev |
| 14:45 |
|
Taoki joined #minetest-dev |
| 16:39 |
|
tech_exorcist joined #minetest-dev |
| 16:40 |
|
fluxionary joined #minetest-dev |
| 17:14 |
|
kilbith joined #minetest-dev |
| 17:16 |
|
Yad joined #minetest-dev |
| 17:16 |
kilbith |
fucking hell |
| 17:17 |
kilbith |
there are some regressions on formspec |
| 17:17 |
kilbith |
https://i.imgur.com/vsaV0WA.png |
| 17:17 |
kilbith |
https://github.com/minetest-mods/i3/issues/49 |
| 17:18 |
kilbith |
I highly suspect this commit: https://github.com/minetest/minetest/commit/14c7fae378 |
| 17:19 |
kilbith |
NEW RULE: anyone who is involved with formspecs *must* test their commits with i3 |
| 17:21 |
kilbith |
^ Krock |
| 17:22 |
|
Yad joined #minetest-dev |
| 17:32 |
sfan5 |
merging #11924 in 10m |
| 17:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/11924 -- Restore pass-through of direction keys by sfan5 |
| 17:34 |
Krock |
kilbith: https://krock-works.uk.to/u/patches/0001-Formspec-Fix-bgcolor-and-set_focus-checks.patch Is there anything more to fix? |
| 17:35 |
sfan5 |
hard to say since we don't have a comprehensive test suite |
| 17:35 |
sfan5 |
might be worth having a formspec in devtest that contains the minimal and maximal form of every formspec element |
| 17:37 |
Krock |
yes, for this specific issue. however, there's elements that change their behaviour slightly depending on the count |
| 17:37 |
Krock |
this results in quite many possible formspec element combinations |
| 17:37 |
Krock |
namely textarea[] and tabheader[] are such special cases |
| 17:46 |
Krock |
sfan5: 10 minutes elapsed. shall I merge in your stead and push the fix afterwards? |
| 17:46 |
sfan5 |
done now |
| 17:47 |
Krock |
alright. will push the formspec patch now |
| 17:48 |
MTDiscord |
<Jonathon> what are opinions on https://github.com/minetest/minetest/pull/11944 (api) vs https://github.com/minetest/minetest/pull/11699 (hard disabled) |
| 17:48 |
kilbith |
Krock: I don't have a linux setup right now so I can't try your patch |
| 17:48 |
Krock |
I don't see a necessity at all to make this configurable |
| 17:48 |
kilbith |
I still wonder how come that you didn't even test on i3 before pushing that large commit |
| 17:48 |
Krock |
nor to remove. I just made a PR in case. |
| 17:49 |
Krock |
kilbith: because devtest exists and I cannot care about each and every cool mod |
| 17:49 |
kilbith |
I would call that a malpractice in my professional environment |
| 17:49 |
kilbith |
really |
| 17:49 |
sfan5 |
better demand a refund then |
| 17:49 |
Krock |
right |
| 17:49 |
kilbith |
Krock: yet you do care about that enormous turd called unified_inventory |
| 17:50 |
|
Yad joined #minetest-dev |
| 17:50 |
MTDiscord |
<Jonathon> relevant https://github.com/minetest-mods/unified_inventory/commit/aeb9841e3ab4fab5fa5457ddf101122a4408c710 |
| 17:51 |
MTDiscord |
<Jonathon> >Remove default hard dependency for use in devtest |
| 17:51 |
MTDiscord |
<luatic> sfan5: this is very weird |
| 17:51 |
MTDiscord |
<luatic> at the time I'm calling dynamic_add_media, no player is connected |
| 17:51 |
MTDiscord |
<luatic> Yet the callback is called for singleplayer |
| 17:51 |
sfan5 |
reproducer please |
| 17:52 |
MTDiscord |
<luatic> Sure |
| 17:52 |
MTDiscord |
<luatic> Try starting https://content.minetest.net/packages/LMD/epidermis/ |
| 17:52 |
MTDiscord |
<luatic> There should be a Heisenbug |
| 17:52 |
MTDiscord |
<luatic> If it crashes with "singleplayer", something's wrong |
| 17:53 |
sfan5 |
I would prefer a smaller reproducer |
| 17:53 |
MTDiscord |
<luatic> Alright |
| 17:56 |
|
Fleckenstein joined #minetest-dev |
| 18:02 |
MTDiscord |
<luatic> sfan5: Try to reproduce it with this: https://gist.github.com/appgurueu/95c65eee3b33bdeae3710c573d5dd4c9 |
| 18:02 |
MTDiscord |
<luatic> I can't reproduce it myself unfortunately |
| 18:03 |
MTDiscord |
<luatic> (not on this device) |
| 18:26 |
|
Yad joined #minetest-dev |
| 18:32 |
|
Yad joined #minetest-dev |
| 18:34 |
celeron55 |
i like #11944 but the api needs some quick thought |
| 18:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/11944 -- Proposal: API to control shadow intensity from the game/mod by x2048 |
| 18:36 |
celeron55 |
something like player:set_lighting() to combine that and #11499? |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/11499 -- Night vision by x2048 |
| 18:36 |
sfan5 |
reminder that #11753 still needs someone to actually confirm it |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/11753 -- Images in formspecs use "smooth" linear instead of nearest neighbor filtering |
| 18:36 |
celeron55 |
or they could be separate |
| 18:36 |
sfan5 |
also reviews please for #11857 and #11866 |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/11857 -- Raise minimum compiler versions by sfan5 |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/11866 -- Raise max mapgen limit constant to align with MapBlock by sfan5 |
| 18:36 |
MTDiscord |
<luatic> sfan5: the issue still persists for me |
| 18:37 |
MTDiscord |
<luatic> Fresh master |
| 18:37 |
MTDiscord |
<luatic> https://cdn.discordapp.com/attachments/747163566800633906/929806094749040700/Bildschirmfoto_von_2022-01-09_19-37-12.png |
| 18:37 |
sfan5 |
it's not that I don't believe you but it needs to be someone who can figure out and fix it (that is usually a coredev) |
| 18:37 |
MTDiscord |
<luatic> Indeed |
| 18:37 |
celeron55 |
(the api design doesn't really have any effect on the network protocol, these all are just added to the player/client parameters there) |
| 18:37 |
MTDiscord |
<luatic> The only hint I can give you is that it is most likely related to draw2DImageFilteredScaled |
| 18:38 |
MTDiscord |
<luatic> But IIRC I already gave that hint |
| 18:38 |
sfan5 |
"the problem with drawing images is related to the call that draws images" well..... |
| 18:38 |
MTDiscord |
<luatic> I'll have another look |
| 18:39 |
sfan5 |
you can try to take a look inside irrlichtmt if you want |
| 18:42 |
MTDiscord |
<luatic> Alright, it seems to be gui_scaling_filter |
| 18:42 |
MTDiscord |
<luatic> If I disable that setting, everything is back to normal |
| 18:43 |
sfan5 |
uh |
| 18:43 |
sfan5 |
that's literally what it's meant to do |
| 18:44 |
MTDiscord |
<luatic> sfan5: But it didn't do this on 5.4 |
| 18:45 |
sfan5 |
items were always rendered as 3d models in 5.4, wasting lots of perf |
| 18:45 |
MTDiscord |
<luatic> Also the description doesn't say anything about smooth vs. hard scaling |
| 18:45 |
MTDiscord |
<luatic> https://cdn.discordapp.com/attachments/747163566800633906/929808157537083492/Bildschirmfoto_von_2022-01-09_19-45-08.png |
| 18:46 |
MTDiscord |
<luatic> It only says hardware vs. software, not smooth vs. hard. |
| 18:46 |
sfan5 |
not my fault |
| 18:46 |
MTDiscord |
<luatic> consider fixing the setting description ¯_(ツ)_/¯ |
| 18:56 |
sfan5 |
@luatic can't get anything to break with your reproducer |
| 18:56 |
sfan5 |
could very well be a race condition |
| 18:57 |
sfan5 |
though actually, no |
| 18:59 |
sfan5 |
well I guess it does satisfy the definition |
| 19:00 |
sfan5 |
http://sprunge.us/tE2pJQ?lua this reproduces it for me |
| 19:02 |
|
Yad joined #minetest-dev |
| 19:11 |
sfan5 |
@luatic what do you want to happen when it's too late to send media the load-at-join way but it's also not possible to reasonably notify lua because the player was not fully joined at the time of media add? |
| 19:14 |
sfan5 |
I'm considering "tell the client to fetch the media anyway, don't notify Lua and hope for the best" |
| 19:15 |
rubenwardy |
if it's non-epheremal, shouldn't it behave like load time sending? So no callback |
| 19:15 |
MTDiscord |
<luatic> sfan5: well well, what I was implementing is a simple "on_all_received" callback |
| 19:15 |
rubenwardy |
if it's epheremal, then idk |
| 19:15 |
MTDiscord |
<luatic> This is all non-ephemeral |
| 19:16 |
sfan5 |
non-ephemeral still has callbacks |
| 19:16 |
rubenwardy |
even for players that join a while after and load it as part of sending? |
| 19:16 |
MTDiscord |
<luatic> https://github.com/appgurueu/epidermis/blob/master/dynamic_add_media.lua basically I'm filling a table with players who haven't received the media yet (theoretically a counter would suffice, but the table is less error-prone) |
| 19:16 |
sfan5 |
not those |
| 19:16 |
rubenwardy |
s/sending/joining |
| 19:17 |
MTDiscord |
<luatic> perhaps a second parameter that notes that the player wasn't connected at the time the media sending process was started? |
| 19:17 |
sfan5 |
that feels like burdening modders with engine issues |
| 19:18 |
rubenwardy |
it would make sense to either 1) pretend it was sent as part of joining (no callback) or 2) delay the callback until `player` is available |
| 19:18 |
MTDiscord |
<luatic> well, the neatest solution would be a callback that is called when all players have received the media |
| 19:18 |
rubenwardy |
I've not used or reviewed this code so feel free to ignore me |
| 19:18 |
MTDiscord |
<luatic> this is required for everything that all players will see like entity textures |
| 19:19 |
sfan5 |
the idea was that mods could easily build it themselves |
| 19:19 |
sfan5 |
but this synchronization issue makes it tricky |
| 19:24 |
sfan5 |
ah |
| 19:24 |
sfan5 |
a client can't accept a media push while joining anyway |
| 19:24 |
sfan5 |
so this is not fixable |
| 19:25 |
rubenwardy |
so you have clients that can completely mess a texture by being too late to load via push, and too early to load via media loading |
| 19:26 |
rubenwardy |
*miss |
| 19:26 |
sfan5 |
swap "too late" and "too early" and you're on point |
| 19:27 |
rubenwardy |
no, it's the right way around |
| 19:27 |
sfan5 |
no it's not |
| 19:27 |
rubenwardy |
it's too late because it's not yet joined the world, so misses the push |
| 19:27 |
rubenwardy |
and too early because when it did media loading, the texture wasn't added |
| 19:28 |
sfan5 |
media loading happens first, the client is too late for that; media push would happen when the client is joined, but isn't -> too early |
| 19:28 |
sfan5 |
+it |
| 19:28 |
sfan5 |
maybe you just have a weird definition of early/late |
| 19:29 |
rubenwardy |
if it joined earlier, then it would have received the media push. So late. If it joined at a later point, then the media would have been part of the media loading. So early |
| 19:29 |
rubenwardy |
not that this matters |
| 19:31 |
rubenwardy |
you get the idea anyway |
| 19:35 |
|
Yad joined #minetest-dev |
| 19:36 |
sfan5 |
http://sprunge.us/76yucC?diff so how about this |
| 19:37 |
rubenwardy |
is there a queue for sending dynamic media? |
| 19:37 |
sfan5 |
no |
| 19:39 |
rubenwardy |
I was going to suggest queueing the send and then pretending to mods that it was loaded in media load, but then you'd have clients joining without the media |
| 19:39 |
rubenwardy |
so you would need to delay the join |
| 19:39 |
sfan5 |
yeah |
| 19:40 |
rubenwardy |
is there a final TOCLIENT_READY before the client joins the world? Could the dynamic media be sent before doing that? I suppose you potentially could end up delaying the client for a while if mods keep adding dynamic media |
| 19:41 |
sfan5 |
the 'delay join' solution is possible but it's awful and I don't want to write it |
| 19:41 |
sfan5 |
(emphasis on is) |
| 19:43 |
|
Yad joined #minetest-dev |
| 19:43 |
rubenwardy |
What about giving the callback extra information about the pending sends, and then sending the media _after_ join. You'd take the non-emerged clients into account, which would allow mods to check if all clients have the media without using `player` objects. Argh, this is messy |
| 19:44 |
rubenwardy |
there's the case where clients disconnect during loading |
| 19:44 |
MTDiscord |
<luatic> warningstream is dirty |
| 19:44 |
rubenwardy |
or if they're already connected |
| 19:44 |
MTDiscord |
<luatic> it doesn't even give mod authors an option to implement the "delayed send" themselves |
| 19:44 |
rubenwardy |
but the callback says it's only called when a player receives the media |
| 19:44 |
sfan5 |
warningstream is definitely okay for the engine admitting it messed up |
| 19:45 |
MTDiscord |
<luatic> the thing is |
| 19:45 |
rubenwardy |
has this been in a major release? |
| 19:45 |
MTDiscord |
<luatic> dynamic_add_media doesn't like being called on load time, which sucks |
| 19:45 |
rubenwardy |
err, -major |
| 19:45 |
MTDiscord |
<luatic> so I call it during the first globalsteps |
| 19:45 |
MTDiscord |
<luatic> would be nice if load time was an option |
| 19:45 |
rubenwardy |
damn, it has |
| 19:45 |
MTDiscord |
<luatic> especially if it's ephemeral=false, meaning just pushing to the media list sent to clients |
| 19:46 |
sfan5 |
the idea is that at load time you can instead move/write to the normal get_modpath() .. "/textures" folder |
| 19:46 |
sfan5 |
rubenwardy: what would have been your suggestion if it wasn't? |
| 19:46 |
rubenwardy |
changing the callback to be about update events, rather than players receiving |
| 19:47 |
MTDiscord |
<luatic> writing to mod folders is dirty, my textures are stored in the world folder |
| 19:47 |
sfan5 |
true I guess |
| 19:47 |
MTDiscord |
<luatic> and I can't write to the worldmods folder due to modsec BTW |
| 19:47 |
rubenwardy |
so it would receive a table with things like { all_received = false, players_loaded = {}, players_awaiting = { "rubenwardy", "luatic" } } |
| 19:47 |
sfan5 |
that wouldn't save us from implementing a solution that delays the media sending |
| 19:48 |
sfan5 |
(aka a queue) |
| 19:48 |
rubenwardy |
you could send the media after they join in that case |
| 19:48 |
rubenwardy |
I was working around delaying the join, rather than delaying media sending |
| 19:52 |
sfan5 |
IMO we can have the engine log a warning for now and then see if/how often people complain about this issue |
| 19:55 |
rubenwardy |
it'll happen eventually, and there's no way for the mod to work around it |
| 19:56 |
rubenwardy |
also your patch is missing a space after the name |
| 19:57 |
sfan5 |
https://0x0.st/oiSS.txt current suggestion |
| 19:59 |
sfan5 |
if anyone wonders where the "improvement" is: the callback is no longer called for players that don't exist yet |
| 20:01 |
|
Yad joined #minetest-dev |
| 20:03 |
sfan5 |
merging #11887 in 10m |
| 20:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/11887 -- Mainmenu game-related changes by sfan5 |
| 20:04 |
sfan5 |
plus #11948 |
| 20:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/11948 -- Copy smoothing note to gui_scaling_filter description by appgurueu |
| 20:09 |
|
x2048 joined #minetest-dev |
| 20:10 |
|
Yad joined #minetest-dev |
| 20:16 |
|
v-rob joined #minetest-dev |
| 20:20 |
sfan5 |
that leaves #11437, #10632 plus some minor fixes in the milestone |
| 20:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/11437 -- `3d_mode` is broken |
| 20:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/10632 -- Retrieve DPI from get_player_information |
| 20:20 |
sfan5 |
I'm inclined to remove the second again because I don't have time to implement it and it doesn't look like anyone else will |
| 20:22 |
|
appguru joined #minetest-dev |
| 20:23 |
MTDiscord |
<luatic> Doesn't the engine know DPI already? |
| 20:24 |
sfan5 |
sure it does |
| 20:24 |
sfan5 |
but mods don't |
| 20:24 |
sfan5 |
and formspec sucks bad but you can make it less terrible if you know the final scale factor |
| 20:24 |
MTDiscord |
<luatic> So wouldn't this be as simple as exposing the information? |
| 20:25 |
sfan5 |
are you volunteering? |
| 20:25 |
sfan5 |
it's not hard but I just do not have the time |
| 20:25 |
MTDiscord |
<luatic> I am |
| 20:25 |
sfan5 |
okay |
| 20:26 |
sfan5 |
make sure to call it "gui_scaling_factor" not "dpi" and note in the docs that it may disappear in the future if formspecs get a feature to fix dpi |
| 20:26 |
MTDiscord |
<luatic> Huh? |
| 20:26 |
MTDiscord |
<luatic> So should I expose the gui_scaling_factor, because that's a setting - a different thing? |
| 20:28 |
sfan5 |
no |
| 20:28 |
sfan5 |
afaik the final scaling value is g_settings->getFloat("gui_scaling") * RenderingEngine::getDisplayDensity() |
| 20:28 |
sfan5 |
and this is the value that matters |
| 20:28 |
MTDiscord |
<luatic> Does it apply to HUDs too? |
| 20:29 |
sfan5 |
it has a setting called `hud_scaling` |
| 20:29 |
sfan5 |
makes sense I guess but means you can't use this for them too |
| 20:29 |
MTDiscord |
<luatic> I should expose that too then |
| 20:31 |
Yad |
So if I understand GitHub correctly, I'm supposed to fork a repository, make edits to my fork, then submit a pull request suggesting the maintainer of the repository I forked, pull my changes into the main version? |
| 20:32 |
MTDiscord |
<luatic> The maintainer "pulls" the changes |
| 20:32 |
Yad |
luatic: I'll take that as a "yes." :D |
| 20:32 |
sfan5 |
yes |
| 20:34 |
celeron55 |
preferably make an new branch in your fork for the changes so that you don't make the PR from your master branch |
| 20:34 |
sfan5 |
rubenwardy: yes / no / maybe? (to https://0x0.st/oiSS.txt) |
| 20:35 |
|
asdflkj_sh joined #minetest-dev |
| 20:36 |
rubenwardy |
Haha, I was so confused - my client included the ) in the URL, which then causes a traceback on the site that looked like code |
| 20:36 |
rubenwardy |
It's a maybe |
| 20:36 |
rubenwardy |
I don't like how there's no workaround for mods |
| 20:36 |
sfan5 |
me neither |
| 20:37 |
MTDiscord |
<luatic> There seem to be some very ugly hacks regarding gui scale on Android |
| 20:37 |
sfan5 |
possibly |
| 20:37 |
MTDiscord |
<luatic> float d = RenderingEngine::getDisplayDensity(); m_gui_scale *= 1.1 - 0.3 * d + 0.2 * d * d; for instance |
| 20:37 |
sfan5 |
judging from another comment I saw pretending density = 1 (from mod POV) is correct on Android |
| 20:38 |
sfan5 |
¯\_(ツ)_/¯ |
| 20:41 |
|
kilbith_ joined #minetest-dev |
| 20:46 |
|
Yad joined #minetest-dev |
| 20:48 |
erlehmann |
luatic sfan5 regarding the DPI thing, didn't v-rob figure out that the engine internal DPI handling was wrong anyway? |
| 20:49 |
erlehmann |
i mean the dpi vs font dpi thing is already pretty bad |
| 20:49 |
erlehmann |
if you expose the wrong info to mods you are digging the hole deeper |
| 20:49 |
erlehmann |
and can not ever switch to the correct thing |
| 20:49 |
erlehmann |
bc then that breaks those mods |
| 20:50 |
erlehmann |
i think a situation of “we figured out a way to handle dpi correctly but now all mods that have workarounds have tiny/giant fonts” is worse than what exists now |
| 20:53 |
v-rob |
If I had known there were so many things to take into account with GUIs, I would never have touched anything beyond formspecs :) |
| 20:53 |
|
Yad joined #minetest-dev |
| 20:54 |
sfan5 |
"dpi vs font dpi" is an X11-specific issue and a minor one at that |
| 20:54 |
sfan5 |
regardless: <+sfan5> make sure to [...] note in the docs that it may disappear in the future if formspecs get a feature to fix dpi |
| 20:55 |
v-rob |
After I finish the GUI, maybe I'll go become a hermit and only program for devices with a single screen resolution, DPI, and ASCII-only. |
| 20:55 |
sfan5 |
that's called being an embedded developer |
| 20:56 |
v-rob |
Heh |
| 20:56 |
x2048 |
erlehmann: can this be solved with a new formspec version? |
| 20:57 |
erlehmann |
x2048 unclear to me |
| 20:58 |
MTDiscord |
<Jonathon> the point of it isnt really font as it is scaling the element sizes |
| 20:58 |
erlehmann |
sfan5 the problem is that at least in my tests all apps except minetest used font dpi for font scaling. so if you now expose dpi, you may expose the hardcoded 96 or whatever it was and not the actual value used by the OS. at least on linux. am i wrong? |
| 20:59 |
x2048 |
erlehmann: if we bump the formspec version when we figure out the dpi/element sizing, the mods with workarounds will not be broken |
| 20:59 |
erlehmann |
v-rob if you make TUIs, urwid is a nice python interface library |
| 20:59 |
erlehmann |
x2048 i see |
| 21:00 |
sfan5 |
erlehmann: Minetest reads the screen DPI on Linux |
| 21:00 |
sfan5 |
it just doesn't support the font dpi setting as people might expect |
| 21:02 |
|
calcul0n__ joined #minetest-dev |
| 21:03 |
sfan5 |
x2048: if you register on IRC and configure your client to sign in everytime I can give you automatic voice |
| 21:04 |
x2048 |
sfan5: x2048 is a protected name here already. |
| 21:05 |
sfan5 |
guess they don't use their nick then because it would not allow you otherwise(?) |
| 21:06 |
sfan5 |
you can obviously pick a slightly different one |
| 21:09 |
x2048 |
sfan5: I mean, I already registered :) |
| 21:09 |
sfan5 |
oh |
| 21:09 |
sfan5 |
I didn't see your nick signed in, must've missed that |
| 21:10 |
v-rob |
TBH, I don't sign in myself most of the time, since I haven't found a way for my IRC client to automatically do it for me |
| 21:11 |
sfan5 |
client? |
| 21:12 |
|
Yad_ joined #minetest-dev |
| 21:13 |
erlehmann |
v-rob x2048 i suggest to configure your accounts to require login, otherwise anyway can fake being you |
| 21:13 |
erlehmann |
with required login after 1 min without login the new person gets renamed |
| 21:13 |
erlehmann |
to guest_456 or something |
| 21:13 |
v-rob |
I use HexChat |
| 21:14 |
sfan5 |
https://libera.chat/guides/hexchat oh hey |
| 21:15 |
|
x2048 joined #minetest-dev |
| 21:16 |
rubenwardy |
yeah, SASL is the way to go |
| 21:17 |
|
x2048 joined #minetest-dev |
| 21:18 |
|
v-rob joined #minetest-dev |
| 21:18 |
v-rob |
Cool, done |
| 21:19 |
|
x2048 joined #minetest-dev |
| 21:21 |
|
Yad joined #minetest-dev |
| 21:24 |
x2048 |
erlehmann: NickServ is already telling me that my nick is registered to my account. Is that enough? |
| 21:25 |
v-rob |
I think the idea is that people can sign in when you're signed out |
| 21:25 |
sfan5 |
he's referring to `/ns help set`, the part about 'enforce' |
| 21:27 |
x2048 |
erlehmann: sfan5: flag set, thanks for the pointer |
| 21:35 |
sfan5 |
okay time for me to use model[] for the first time ever |
| 21:46 |
sfan5 |
that was easy |
| 21:48 |
|
Yad joined #minetest-dev |
| 21:56 |
sfan5 |
pushing a commit to MTG (not that anyone cares at this point) |
| 21:57 |
MTDiscord |
<Jonathon> lol |
| 22:08 |
MTDiscord |
<GreenXenith> So we now have a 1024 dev and a 2048 dev. Just need one more to have a pattern. |
| 22:20 |
MTDiscord |
<savilli> Make sure to not overflow |
| 22:32 |
|
Yad joined #minetest-dev |
| 23:04 |
|
Fixer_ joined #minetest-dev |
| 23:21 |
MTDiscord |
<exe_virus> I should aim for 512 |
