| Time |
Nick |
Message |
| 00:24 |
|
Lesha_Vel joined #minetest |
| 00:25 |
|
Lesha_Vel joined #minetest |
| 00:27 |
|
YuGiOhJCJ joined #minetest |
| 00:34 |
|
mckayshirou joined #minetest |
| 01:00 |
|
FavoritoHJS joined #minetest |
| 01:06 |
|
Blockhead256 joined #minetest |
| 01:07 |
|
smk joined #minetest |
| 01:28 |
|
mckayshirou joined #minetest |
| 01:29 |
|
mckaygerhard left #minetest |
| 01:32 |
|
mckaygerhard1 joined #minetest |
| 01:33 |
|
mckaygerhard1 joined #minetest |
| 02:14 |
|
lemonzest joined #minetest |
| 02:32 |
|
mckaygerhard1 left #minetest |
| 02:42 |
|
Verticen joined #minetest |
| 02:45 |
|
YuGiOhJCJ joined #minetest |
| 02:50 |
|
olliy joined #minetest |
| 04:13 |
|
Lesha_Vel_ joined #minetest |
| 04:17 |
|
yyy joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:25 |
|
illwieckz joined #minetest |
| 05:54 |
|
diceLibrarian joined #minetest |
| 07:03 |
|
appguru joined #minetest |
| 07:13 |
lissobone |
Minetest lore. |
| 07:21 |
|
diceLibrarian joined #minetest |
| 07:43 |
|
calcul0n_ joined #minetest |
| 07:54 |
MTDiscord |
<jordan4ibanez> Well if you want to get the full minetest lore from the very beginning, you'll have to talk to c55 about that part |
| 07:55 |
MTDiscord |
<ROllerozxa> in the beginning, there was Mese... |
| 07:58 |
muurkha |
in the beginning, there was Infiniminer... |
| 07:59 |
MTDiscord |
<jordan4ibanez> Commit 1: https://github.com/minetest/minetest/commit/4e249fb3fbf75f0359758760d88e22aa5b14533c |
| 08:00 |
MTDiscord |
<jordan4ibanez> I can't believe there were no comments on that commit |
| 08:03 |
lissobone |
They even embedded 'tf.jpg'. |
| 08:05 |
lissobone |
THE LORE |
| 08:06 |
lissobone |
The lore is not only the beginning. |
| 08:06 |
lissobone |
The lore includes the Way, the Path, the Goal... and the End. |
| 08:06 |
lissobone |
Abbreviated as "BWPGE". |
| 08:07 |
lissobone |
Map size hasn't changed much since then, as I see. |
| 08:08 |
MTDiscord |
<jordan4ibanez> That's because 32 bit is still supported I think |
| 08:08 |
MTDiscord |
<jordan4ibanez> Once that is dropped, it will have an absolutely tremendous map size |
| 08:09 |
lissobone |
Minetest wasn't as free then, I also noticed. |
| 08:09 |
lissobone |
(Free as in freedom). |
| 08:11 |
lissobone |
And any Lore must include a War. |
| 08:11 |
lissobone |
No, not Warr. |
| 08:11 |
lissobone |
What is the War of Minetest? |
| 08:12 |
MTDiscord |
<ROllerozxa> war of minetest? OC I guess |
| 08:12 |
Blockhead256 |
your lore should include a reason why minetest_game split into just one of many subgames |
| 08:13 |
lissobone |
OC? |
| 08:13 |
lissobone |
The Name one must not pronounce? |
| 08:20 |
MTDiscord |
<jordan4ibanez> I just realized c55 started making this game when I started playing MC, incredible |
| 08:21 |
lissobone |
I am too young. |
| 08:24 |
lissobone |
I discovered free software too late. |
| 08:37 |
|
TomTom joined #minetest |
| 08:48 |
lissobone |
I am sfrduffgloinjfg rfp fyup[we in fl;ocsw |
| 08:48 |
lissobone |
I am struggling to type in gloves. |
| 09:38 |
|
est31 joined #minetest |
| 10:38 |
lissobone |
Greetings. |
| 10:38 |
lissobone |
Hello. |
| 11:18 |
|
Lesha_Vel joined #minetest |
| 11:49 |
|
kilbith joined #minetest |
| 12:28 |
|
specu joined #minetest |
| 12:31 |
specu |
Hi guys/girls. |
| 12:32 |
specu |
I'm creating for personaluse docker with minetest server binary. I fully not understand how creation of new worlds work |
| 12:32 |
specu |
when I pass mkdir worlds/anotherworld && bin/minetestserver --worldname anotherworld |
| 12:33 |
specu |
binary outputs only list already created worlds but not populate new one |
| 12:33 |
specu |
do I need any configuration files inside worlds/anotherworld ? |
| 12:34 |
MTDiscord |
<Warr1024> IIRC there is an officialish MT docker image built by CI, and the ls.io one, and I think Buckaroo makes one and then there's mine. Each of those could be a basis or give you examples of how they work. |
| 12:35 |
MTDiscord |
<Warr1024> I think to use world name, it looks by name in the world.mt file, so it it doesn't find that it won't find a world path. I think world by path might create it. |
| 12:35 |
MTDiscord |
<Warr1024> But it's easiest to just use the default and bind-mount a world dir to worlds/world |
| 12:38 |
specu |
yea I know about existed dockers (one from here https://forum.minetest.net/viewtopic.php?t=18527 but its outdated, second by linuxserver, based on alpine). But for mine needs (ubuntu base and learning minetest :o) I want to create for personal registry;) |
| 12:39 |
specu |
I tried to touch empty world.mt not works unfortunatelly |
| 12:39 |
|
definitelya joined #minetest |
| 12:40 |
MTDiscord |
<Warr1024> Touching it empty won't add a name= to it. Any particular reason you want to use --worldname instead of --world anyway? |
| 12:41 |
MTDiscord |
<Warr1024> Ubuntu base is a bit of an odd choice for a docker image but I guess if you're focusing on learning stuff you don't need an excuse for doing unusual things. |
| 12:42 |
MTDiscord |
<Warr1024> I usually see a little debian and a lot of alpine. |
| 12:43 |
specu |
got it working if I pass gameid and world_name it runs ok; Do i have any reason for --worldname hmm I think not |
| 12:45 |
specu |
thanks anyway ;) |
| 12:46 |
|
Leopold joined #minetest |
| 13:07 |
specu |
Yea another question, where shoudl I load mods - in minetest.conf or world.mt ? |
| 13:08 |
|
jwmhjwmh joined #minetest |
| 13:08 |
specu |
I assume that loading them in minetest.conf makes it globally and in world.mt per world right? |
| 13:10 |
|
kabou joined #minetest |
| 13:12 |
|
proller joined #minetest |
| 13:13 |
MTDiscord |
<Warr1024> I'm not aware of it being possible to enable mods loading via minetest.conf; I've only ever done it through world.mt. |
| 13:14 |
MTDiscord |
<Warr1024> I hear that some people use worldmods, but that does have the drawback of requiring you to physically break up modpacks if you want to select specific mods from them and not the whole thing. |
| 13:16 |
specu |
so I shoudl only put them in world.mt |
| 13:16 |
specu |
well I did it wrong if so :D |
| 13:17 |
MTDiscord |
<Warr1024> https://hub.docker.com/r/warr1024/minetestserver (git link is in the description) |
| 13:17 |
MTDiscord |
<Warr1024> As you can see, I include a bunch of stuff like builtin with the engine in the image |
| 13:17 |
MTDiscord |
<Warr1024> but I expect to find minetest.conf, games, mods, and worlds bind-mounted in. |
| 13:17 |
specu |
thanks I will look into it |
| 13:18 |
MTDiscord |
<Warr1024> Minetest generally requires a bunch of stuff, and you'll want to be able to customize a lot of things, so you do kind of have to mix together a bunch of different configgy stuff into the minetest base dir. |
| 13:19 |
MTDiscord |
<Warr1024> I ended up with my image using some wrapper scripts, including ones that merge together various things into a temp dir and run them from there, so that users can "override" stuff that's baked in, but there are sane defaults in most cases. |
| 13:20 |
specu |
I started with creation of on image for build process and make package, and second image that is used as a server |
| 13:21 |
MTDiscord |
<Warr1024> I'm actually somewhat proud of that image, as it (1) has judicious layering, a parallelizable staged build, and a small image size, (2) support for all the backends, and (3) decent customizability and flexibility built in, without being as complex as the ls.io one. |
| 13:21 |
specu |
second one is small and have only dependencies for running binary nothing else but for now is very simple with entrypoint as ENTRYPOINT exec bin/minetestserver --world worlds/${WORLDNAME} :D |
| 13:22 |
specu |
its for me so I dont need lot of stuff |
| 13:23 |
MTDiscord |
<Warr1024> You shouldn't need multiple separate images now for build process; Docker supports those directly using "stages" within a single build. You can install the build dependencies and run the build in one stage, then setup the runtime dependencies in a second stage, copy over just the build output into the second stage, and then the last stage is the only one that gets published as an image. |
| 13:24 |
MTDiscord |
<Warr1024> Stages are also parallelizable up to the point where they depend on another stage, so I take advantage of this pretty extensively in my own dockerfile to do like the MT and irrlicht downloads while the build and runtime dependencies are being installed, all in parallel in separate stages. |
| 13:25 |
MTDiscord |
<Warr1024> I've done the "multiple images" thing in the past and am very glad they finally made it usually not necessary. |
| 13:26 |
MTDiscord |
<Warr1024> Direct link: https://gitlab.com/sztest/minetestserver/-/blob/master/Dockerfile |
| 13:34 |
specu |
I'll check it out;) thanks |
| 13:52 |
|
Specu joined #minetest |
| 13:56 |
|
ytterbium joined #minetest |
| 14:02 |
Specu |
discord or this channel is more popular? :D |
| 14:06 |
MTDiscord |
<Warr1024> It's hard to say exactly. Discord, IRC, and Matrix all have somewhat different but overlapping segments of the community. I'm connected to all of them, to be sure I don't miss something useful, but they all have certain advantages and disadvantages. |
| 14:09 |
Specu |
(y) I see |
| 14:11 |
MTDiscord |
<ROllerozxa> discord is significantly more active, but also can tend to be more shitpost-y |
| 14:17 |
Specu |
btw this multibuild image build is great (why I miss it IDK lol), previous I had to manually copy build package from build image to server image lol |
| 14:17 |
Specu |
just life and time saver :D |
| 14:21 |
|
Leopold joined #minetest |
| 14:21 |
MTDiscord |
<Warr1024> Discord has specific places for shitpostiness, and specific places that are meant to stay more on-topic. Topic discipline always breaks down somewhat on any multi-channel medium, but it's not all that bad. |
| 14:26 |
MTDiscord |
<Warr1024> If you already have a Discord account, definitely join the MT discord. If you're considering whether to join Discord, keep considering 😄. It'd be kind of ironic if MT, a FOSS project (and sometimes rabidly so) were to be the thing to cause you to sign up for Discord. |
| 14:30 |
Nolt |
Yea I have, and I joined already and changed nickname here to use same as Discord |
| 14:31 |
MTDiscord |
<Warr1024> Ah, well then hi to both of you 😄 |
| 14:33 |
Nolt |
:) hi hehe |
| 14:35 |
lissobone |
I don't have discord, luckily. |
| 14:37 |
MTDiscord |
<Warr1024> "Modern" chat platforms like Discord have nicer UX with synced multi-device support and good mobile performance ... IRC clients like TheLounge really help nullify this advantage though, especially if you can self-host an instance. |
| 14:37 |
lissobone |
Hosting a free software project's community chat on discord is like being straight and hanging out daily in a gay bar like nothing's wrong. |
| 14:37 |
lissobone |
It doesn't matter what the UI is or how good it performs. |
| 14:38 |
lissobone |
It's nonfree software. |
| 14:38 |
MTDiscord |
<ROllerozxa> LOL |
| 14:38 |
MTDiscord |
<ROllerozxa> you implying we all on the discord server are gay? |
| 14:39 |
lissobone |
No, it's an analogy. This doesn't mean that you're straight or gay. |
| 14:39 |
lissobone |
Well, maybe not. |
| 14:39 |
MTDiscord |
<Warr1024> I'd have zero qualms about hanging out in a gay bar. I've got enough gay friends. I'm not interested in personally participating in some of the things going on in there, but it's not like it's hard to opt out. |
| 14:40 |
lissobone |
OK, I have to find a better analogy. |
| 14:41 |
MTDiscord |
<Warr1024> Haha, yeah 😄 |
| 14:42 |
lissobone |
Hosting such a chat on discord is like hosting GNU packages on mailru servers. |
| 14:43 |
definitelya |
I think you'd be the biggest alpha in the whole club if u were straight ahah. |
| 14:44 |
MTDiscord |
<Warr1024> Discord is more like a prison that is open to the public for tours, but they put a shackle around you, and very slowly add weight to it each time you pass through. If you're not careful, you can end up dependent on the platform, and then they've got you locked in and you're not a tourist anymore, you're an inmate. It's a really popular tour, though, and you have a lot of friends in there who are doing hard time already, so it's a |
| 14:44 |
MTDiscord |
tricky balancing act to try to shave the weight down, and maybe every now and then smuggle a nail file in. |
| 14:44 |
lissobone |
I used to have a discord account. |
| 14:45 |
Bombo |
hey is there a way to list the currentlyx connected users? like /who |
| 14:45 |
lissobone |
But I broke the chains, no matter the weight. |
| 14:45 |
lissobone |
It is /status. |
| 14:45 |
lissobone |
You mean here or in minetest? |
| 14:46 |
Bombo |
in minetest ;) |
| 14:46 |
Bombo |
ok status is too much ;( |
| 14:46 |
lissobone |
It's "/names" to list users in an IRC channel. |
| 14:46 |
Bombo |
only clients connected |
| 14:46 |
lissobone |
Well, you can register a custom command. |
| 14:46 |
lissobone |
for _, name in pairs(minetest.get_connected_players()) do |
| 14:47 |
lissobone |
Then concatenate the names in specific ways. |
| 14:47 |
lissobone |
Then write it out in your chat. |
| 14:47 |
MTDiscord |
<Warr1024> MT generally won't provide you with EXACTLY what you want, but it will provide you with tools that make it feasible to make it. You have to decide whether it's easier for you to just compromise and use /status, or write your own custom /names command. |
| 14:48 |
Bombo |
i hoped there was something ready to go, i found https://content.minetest.net/packages/Fleckenstein/playerlist/ but it doesn't do anything |
| 14:48 |
lissobone |
I can assemble such a command for you right off the bat. |
| 14:48 |
lissobone |
It's, like, 7 lines. |
| 14:48 |
lissobone |
No dependencies. |
| 14:48 |
lissobone |
I will do it. Be prepared. |
| 14:48 |
lissobone |
function listall() |
| 14:49 |
Bombo |
plus all the learning lua and minetest api stuff ;) |
| 14:49 |
lissobone |
local result = "" |
| 14:49 |
Nolt |
Honestly I always say selfhosted thing is FTW. I remember last year Discord has a issue, and suddenly lot of projects even opensource had a big problem = no chat at all :D |
| 14:49 |
|
DeepThot joined #minetest |
| 14:49 |
lissobone |
local players = minetest.get_connected_players() |
| 14:49 |
lissobone |
for n, i in pairs(players) do |
| 14:50 |
lissobone |
--[[ Do you want them to be comma-separated or just spaces? ]] |
| 14:50 |
|
Blockhead256 joined #minetest |
| 14:50 |
Bombo |
or maybe tabs ;) |
| 14:50 |
lissobone |
result = result .. i |
| 14:51 |
lissobone |
end |
| 14:51 |
lissobone |
return result |
| 14:51 |
lissobone |
end |
| 14:51 |
lissobone |
Done. |
| 14:51 |
Bombo |
ok where to put that? |
| 14:51 |
lissobone |
This function returns you the list of current players in a cozy string. |
| 14:51 |
lissobone |
Well, first open up Emacs. |
| 14:51 |
lissobone |
Or whatever text editor you have. |
| 14:51 |
Bombo |
lol |
| 14:51 |
lissobone |
Any will fit. |
| 14:51 |
Bombo |
ok |
| 14:51 |
Bombo |
who.lua |
| 14:52 |
lissobone |
Ok, create a directory in ".minetest/mods/". Choose a name for your mod. |
| 14:52 |
lissobone |
You can also write "asdfasdf". |
| 14:52 |
lissobone |
.minetest/mods/asdfasdf |
| 14:52 |
lissobone |
Assuming you know where .minetest is. |
| 14:52 |
lissobone |
Done? |
| 14:52 |
Bombo |
.minetest/mods/who/who.lua |
| 14:53 |
lissobone |
Alright, write down that function in the file. |
| 14:53 |
lissobone |
Line by line. |
| 14:53 |
lissobone |
Indenting doesn't matter much. |
| 14:53 |
Nolt |
Warr1024 just checked your Docker. Im not developer so can't tell anything about it but seen some warrnings at the beginning of MT build (/build/lib/jsoncpp/jsoncpp.cpp). Docker works like a charm ;) |
| 14:53 |
Bombo |
lissobone: done |
| 14:54 |
lissobone |
Make 2 empty lines at the end. |
| 14:54 |
lissobone |
Now next step. |
| 14:54 |
lissobone |
minetest.register_chatcommand("listallplayers", |
| 14:54 |
Blockhead256 |
lissobone: you know, pastebin sites exist for a reason, it's much easier than sending many messages |
| 14:55 |
lissobone |
{privs = {}, |
| 14:55 |
lissobone |
description = "List all players.", |
| 14:55 |
MTDiscord |
<Warr1024> All of my warnings are warrnings, as I am warr 😄 |
| 14:55 |
lissobone |
func = function(name, params) |
| 14:55 |
MTDiscord |
<Warr1024> I have never managed to build MT without SOME warnings, I've mostly just learned to ignore them as long as the build completes and the final product works as expected. |
| 14:55 |
Bombo |
Blockhead256: its only 7 lines ;) |
| 14:56 |
lissobone |
minetest.chat_send_player(name, listall()) |
| 14:56 |
lissobone |
return |
| 14:56 |
lissobone |
end}) |
| 14:56 |
Blockhead256 |
if we're going to talk about how whitespace isn't important, you could just put all of that on one line too... |
| 14:56 |
lissobone |
Not actually 7, but not 700 either. |
| 14:56 |
MTDiscord |
<Warr1024> https://wiki.minetest.net/IRC#Rules <-- the "use a pastebin instead" threshold here is 4+ lines. |
| 14:57 |
lissobone |
So I could just dump all of that in a single line and avoid the threshold? |
| 14:57 |
lissobone |
Bombo: last step. |
| 14:57 |
MTDiscord |
<Warr1024> ngl I was tempted to try to golf it myself. |
| 14:57 |
|
Fixer joined #minetest |
| 14:57 |
lissobone |
Put this: "dofile(minetest.get_modpath("who") .. DIR_DELIM .. "who.lua")" in init.lua. |
| 14:58 |
MTDiscord |
<Warr1024> IRC itself has a per-line length limit. If you can fit all of it, then it's probably good enough. |
| 14:58 |
MTDiscord |
<Warr1024> There is a reason why it's based on number of lines, not bytes. |
| 14:58 |
MTDiscord |
<Warr1024> (i.e. the rule is) |
| 14:58 |
Blockhead256 |
A GitHub Gist would also work for a tiny succinct mod |
| 14:58 |
lissobone |
No. |
| 14:59 |
lissobone |
Alright, Bombo, done? |
| 15:00 |
lissobone |
I should've written this on my computer and hosted the files on my web server. |
| 15:00 |
MTDiscord |
<Warr1024> That works well too |
| 15:00 |
Bombo |
lissobone: ok done, let's try it |
| 15:00 |
lissobone |
Don't forget to enable "who". |
| 15:00 |
Nolt |
Warr1024 on alpine or overall? |
| 15:00 |
Nolt |
i mean those warrning thing |
| 15:02 |
MTDiscord |
<Warr1024> I never noticed any warnings specific to alpine. I just notice warnings related to MT, scattered around the MT build process, generally speaking. I've learned to tune them out, so I don't e.g. pay much attention to which ones I get building the client on debian vs. building the server on alpine. |
| 15:03 |
MTDiscord |
<Warr1024> If warnings were meant to be taken seriously, then a project does after all generally have the option to enable an "escalate warnings to errors" option to MAKE them be taken seriously. |
| 15:03 |
Nolt |
Oh I see. Well I never build client so cant say much but if we talking about server (on ubuntu) I had no warrnings at all. |
| 15:04 |
MTDiscord |
<Warr1024> That could just mean that most of the people who do engine dev and actually care about warnings themselves run Ubuntu, so they only see and fix the warnings that crop up there 😄 |
| 15:05 |
MTDiscord |
<Warr1024> Next time I get a minute I'll try running it myself and seeing what kind of warnings show up |
| 15:05 |
Blockhead256 |
CI does run on Ubuntu.. |
| 15:05 |
MTDiscord |
<Warr1024> but the idea behind docker is supposed to be platform-independence, i.e. you should get the same results running the same build process on different environments, so whatever warnings you see in my image should be the same ones I see ... and since I run production servers on that image, the warnings must not be actual breakages... |
| 15:06 |
Bombo |
lissobone: http://ix.io/4kZI something went wrong |
| 15:06 |
MTDiscord |
<Warr1024> It's very difficult, probably infeasible, really, for any large project with significant cross-distro and even cross-platform support, like MT, to ensure that there are no warnings on ALL platforms. |
| 15:07 |
Bombo |
who.lua:10: 'end' expected (to close 'function' at line 1) near 'minetest' |
| 15:07 |
Blockhead256 |
Does anyone still have a copy of Sqauresville (https://forum.minetest.net/viewtopic.php?f=9&t=15410) with the git history intact? There's the zip release post-GitHub deletion but I'd really hate to throw git history away. There is a version from TumeniNodes on GitHub, but is that out of date? |
| 15:07 |
MTDiscord |
<Warr1024> in a chatcommand, you don't have to minetest.chat_send_player; it does that automatically for you with the second return value. |
| 15:07 |
MTDiscord |
<Warr1024> so like return true, listall() works nicely too. |
| 15:09 |
Kimapr |
<deept> "hello, so I have a minetest..." <- i have a mod that (among other things) completely removes the forceload limit: https://content.minetest.net/packages/Kimapr/advfload/ |
| 15:09 |
Bombo |
ok i forgot an end |
| 15:10 |
Bombo |
now the error is who.lua:6: attempt to concatenate local 'i' (a userdata value) |
| 15:11 |
Nolt |
Yea I think it's rather alpine thing about those warring rather than MT. I maybe said incorrectly "on ubuntu" I had in mind that I build MT using ubuntu images instead alpine. Yea its larger but I hate looking packages and spending 2x more time what package else is missing:D ofc for mine personal stuff 120mb image is not that large :d but yours |
| 15:11 |
Nolt |
21 for productions yea its a game changer :) |
| 15:13 |
Kimapr |
btw, my mod has a easy-to-use API to forceload entire areas at once which technic could actually use to simplify world anchor logic |
| 15:15 |
lissobone |
Oh, wait. |
| 15:15 |
lissobone |
Sorry. |
| 15:15 |
lissobone |
I forgot to "i:get_player_name()". |
| 15:16 |
lissobone |
Should be before "result = result .. i". |
| 15:16 |
lissobone |
Insert that line. |
| 15:16 |
lissobone |
Note: right before. |
| 15:16 |
lissobone |
Bombo. |
| 15:19 |
Bombo |
lissobone: who/who.lua:7: attempt to concatenate local 'i' (a userdata value) |
| 15:19 |
lissobone |
Yea, exactly this. |
| 15:20 |
lissobone |
Make a newline before the result .. i line. |
| 15:20 |
lissobone |
Insert "i:get_player_name()" there. |
| 15:20 |
lissobone |
Now it should work. |
| 15:21 |
lissobone |
Wait. |
| 15:21 |
lissobone |
Alright, I'll just host a file. |
| 15:21 |
Bombo |
http://ix.io/4kZQ |
| 15:22 |
Bombo |
after all this? we are almost done! ;) |
| 15:24 |
lissobone |
http://115.137.94.44/who.lua |
| 15:26 |
MTDiscord |
<Warr1024> 2023 and not having a dynamic DNS...? 😅 |
| 15:26 |
MTDiscord |
<luatic> You should be using table.concat for this as follows: lua local function listall() local names = {} for i, player in ipairs(minetest.get_connected_players()) do names[i] = player:get_player_name() end return table.concat(names, ", ") end |
| 15:26 |
MTDiscord |
<luatic> Using string concatenation in a loop is an absolute antipattern in Lua 99% of the time. |
| 15:27 |
MTDiscord |
<Warr1024> table.concat vs .. is very unlikely to make a meaningful difference for this kind of usecase. |
| 15:27 |
MTDiscord |
<luatic> it's not only about the performance |
| 15:27 |
lissobone |
What is dynamic DNS? |
| 15:27 |
Blockhead256 |
that's a nice functional programming paradigm you have there but does it *really* help in Lua? |
| 15:27 |
MTDiscord |
<luatic> Blockhead256: Yeah, it helps both performance and readability. Also it's hardly functional... |
| 15:28 |
MTDiscord |
<luatic> Readability because now you don't need to worry about whether you're already at the first/last item which don't need a delimiter before/after them. |
| 15:28 |
MTDiscord |
<Warr1024> dynamic DNS = some DNS provider that lets you sign up for a hostname that points to your IP, with an API to update it, and a short TTL so that your IP doesn't stay cached for long after you push a change. |
| 15:28 |
lissobone |
There's no delimiter. |
| 15:28 |
lissobone |
It's just a space. |
| 15:28 |
MTDiscord |
<luatic> lissobone: a space is a delimiter |
| 15:28 |
Blockhead256 |
turning your loops into potentially-parallelisable-function-calls is a path in that direction |
| 15:28 |
MTDiscord |
<luatic> granted, you can hope that nobody sees the trailing space |
| 15:28 |
MTDiscord |
<Warr1024> There are paid options like dyn.com that I use, which is good quality, but paid ... and there are others that are free; minetest.land in particular is nice for MT-related stuff. |
| 15:29 |
lissobone |
No one'll see the trailing space. |
| 15:29 |
MTDiscord |
<luatic> People on IRC clients might. |
| 15:29 |
MTDiscord |
<luatic> It might also get output to the logs. |
| 15:29 |
lissobone |
So? |
| 15:29 |
Blockhead256 |
luatic: but anyway are you saying the table.concat is better because it's avoiding many intermediate string states. I suppose that's what the C does. |
| 15:30 |
MTDiscord |
<luatic> Yes, that's the performance part of why it's better |
| 15:30 |
lissobone |
Will this trailing space get the axolotl population killed? |
| 15:30 |
lissobone |
Will an Uj appear in my room 85 years later? |
| 15:30 |
MTDiscord |
<luatic> lissobone: Suddenly you switch the delimiter to a comma, and boom you get a trailing comma. |
| 15:30 |
lissobone |
You can just shrink the function by one symbol. |
| 15:30 |
lissobone |
I mean not the function. |
| 15:30 |
lissobone |
The string! |
| 15:31 |
lissobone |
I derived that function from my command that outputted the list of current nucleotest participants. |
| 15:31 |
lissobone |
It used commas as delimiters, and a full stop at the end. |
| 15:31 |
lissobone |
And I won't suddenly switch my delimiter to a comma. |
| 15:32 |
lissobone |
Commas plus spaces as delimiters! |
| 15:33 |
MTDiscord |
<luatic> Blockhead256: The functional programming style would be modlib.iterator.treeduce(modlib.func.concat, modlib.iterator.map(function(player) return player:get_player_name() end, ipairs(minetest.get_connected_players()))). This gives you O(n) time complexity despite still doing string concatenations as it will concatenate the strings in a tree-like manner ;) |
| 15:33 |
MTDiscord |
<luatic> (modlib.iterator.treeduce has not been pushed yet though) |
| 15:34 |
MTDiscord |
<Warr1024> The whole .. vs table.concat argument has already wasted way more energy than the difference in performance, readability, maintainability, etc. over the life of this code would have (though not as much energy as adding a modlib dependency would have). |
| 15:35 |
MTDiscord |
<luatic> table.concat must be preached. It is a shame that there is no Luacheck warning for string concatenations in a loop. |
| 15:35 |
MTDiscord |
<luatic> Very rarely will string concatenation turn out to be more readable and/or more performant. |
| 15:35 |
MTDiscord |
<Warr1024> Preaching is itself a worse antipattern than ..-in-a-loop. |
| 15:36 |
MTDiscord |
<Warr1024> Too bad there's no luacheck warning for that. |
| 15:36 |
Blockhead256 |
luatic: you see, I am reading the LuaJIT source, and truth be told, though I can't right ascertain what its doing, it looks like its doing the same as the .. operator in a loop would in Lua.. |
| 15:36 |
muurkha |
Blockhead256: it preallocates the result string, so it's linear-time instead of quadratic time |
| 15:36 |
MTDiscord |
<luatic> muurkha: No. |
| 15:36 |
muurkha |
no |
| 15:36 |
muurkha |
? |
| 15:36 |
MTDiscord |
<Warr1024> JITs are a bit of a special case, in that they're somewhat more likely to detect this kind of thing and translate it under the hood into table.concat for you. |
| 15:36 |
MTDiscord |
<luatic> In a loop it's still quadratic time unless the compiler is very smart. |
| 15:37 |
muurkha |
No, I meant table.concat. |
| 15:37 |
MTDiscord |
<luatic> ahh sorry then |
| 15:37 |
MTDiscord |
<luatic> a .. b .. c .. d will be optimized by both Lua and LuaJIT however |
| 15:37 |
muurkha |
Oh, sure. |
| 15:37 |
lissobone |
Quadratic time? Come on, he's not going to run this command for 74 years every 0.001 seconds. |
| 15:37 |
Blockhead256 |
muurkha: citation needed, because how can it know what size to allocate without first iterating the table? In fact the code apparently only goes through the table once |
| 15:38 |
MTDiscord |
<luatic> lissobone: focusing on performance is a straw man fallacy here |
| 15:38 |
MTDiscord |
<Warr1024> Calling table.concat MAY just convert it into .. internally, and then pass it on to the next layer for RE-optimization back into a linear-time preallocated string native implementation. |
| 15:38 |
muurkha |
He probably also doesn't have thousands of participants |
| 15:38 |
Blockhead256 |
sure, it's O(2n) which is usually considered O(n), but.. |
| 15:38 |
MTDiscord |
<luatic> Blockhead256: It might as well grow a buffer exponentially. Same thing, linear time complexity. |
| 15:38 |
MTDiscord |
<Warr1024> Indeed, performance is not the problem here. The problem is that this entire argument was not worth starting in the first place. |
| 15:39 |
lissobone |
Why doesn't minetest use lisp?? |
| 15:39 |
MTDiscord |
<luatic> lissobone: There are like 10 lisp preprocessors for Lua |
| 15:39 |
MTDiscord |
<luatic> Pick one |
| 15:39 |
muurkha |
because the similar projects that used lisp weren't successful ;) |
| 15:39 |
MTDiscord |
<Warr1024> lissobone: check out Loria (game for MT): it's written in a dialect of Lisp that compiles into Lua. |
| 15:39 |
MTDiscord |
<luatic> I still maintain that in this case the looped string concatenations are worse because (1) they are less readable (2) they are less maintainable (3) they are less performant |
| 15:40 |
MTDiscord |
<luatic> They are strictly inferior. |
| 15:40 |
MTDiscord |
<luatic> (in this case) |
| 15:40 |
muurkha |
wrt performance and JITs, in general you probably don't want a function in your mod to take possibly linear time or possibly quadratic time depending on how much the JIT has decided to optimize it |
| 15:40 |
muurkha |
or whether there's a debug log line in the loop, or something |
| 15:40 |
lissobone |
How are they less readable? |
| 15:41 |
Blockhead256 |
(1) readability is not appreciably affected in my opinion (2) it's what 7 lines of code? It's nothing to maintain, you throw it away at a whim (3) is correct iff the C code does it right, which is unproven but we'll take it in good faith |
| 15:41 |
MTDiscord |
<Warr1024> lissobone: they are equally readable unless you have an irrationally strong negative reaction to seeing them that causes you to be unable to read past them without raising a big fuss 🙄 |
| 15:42 |
Blockhead256 |
and (4) like Warr1024 it's not worth caring about lul |
| 15:42 |
Blockhead256 |
*like Warr *said*.. Warr as a person is worth caring about I'm sure |
| 15:43 |
Blockhead256 |
Still: Thank you for reminding us all to use what's in the standard library instead of homebrewed solutions.. |
| 15:43 |
MTDiscord |
<luatic> I've seen supposedly fast JSON readers/writers do this. |
| 15:44 |
MTDiscord |
<Warr1024> minetest.register_chatcommand("who",{func=function()local t=minetest.get_connected_players()for k,v in ipairs(t)do t[k]=v:get_player_name()end return false,table.concat(t," ")end}) All the performance, none of the readability. |
| 15:44 |
MTDiscord |
<luatic> I'll raise the fuss any time I get the chance to |
| 15:44 |
MTDiscord |
<Warr1024> (I'm banking on get_connected_players() returning a COPY; if it doesn't, then frankly MT has bigger problems than my code) |
| 15:44 |
MTDiscord |
<luatic> Straw man. Lack of indentation and poor naming of the t variable is responsible for reduced readability here. |
| 15:45 |
lissobone |
I find the table.concat solution unnecessarily complicated and too implicit. |
| 15:45 |
* muurkha |
also cares about Warr1024 as a person |
| 15:45 |
MTDiscord |
<Warr1024> Actually it's the complete lack of whitespace. The variable names are fine; they're all short enough scoped that a single-letter is fine. |
| 15:45 |
MTDiscord |
<luatic> Well while I like to reuse tables, I did explicitly not do it in my code, both because (1) the API docs don't guarantee it (2) it's less readable, because t becomes a mix of names and players |
| 15:46 |
MTDiscord |
<Warr1024> In this case I find table.concat and .. pretty much equally readable, so it's not much of a factor in choosing one over the other. |
| 15:46 |
Blockhead256 |
here is my favourite most useless thing in Lua that I deleted: function push(t, x) t[#t+1] = x |
| 15:47 |
Blockhead256 |
replaced all calls to it with table.insert(t,x) |
| 15:47 |
MTDiscord |
<Warr1024> local push = table.insert 😄 |
| 15:48 |
Blockhead256 |
and yes that was just written into the global namespace too |
| 15:48 |
MTDiscord |
<Warr1024> IIRC t[#t + 1] = x is slightly faster in PUC lua because it avoids a function call, but it's probably inlined in JIT anyway, so that's probably mostly a non-issue. It'd be nice if the language had syntactic sugar for it though that we knew consistently got the inline-like performance across interpreters. |
| 15:49 |
muurkha |
I thought #t was slow in PUC Lua |
| 15:49 |
Blockhead256 |
Ah: Now I thought using # operator cost more than doing it in C. But of course, either way it's going to use the array-part-length that's recorded into the array-part of the table I think, not do a linear search |
| 15:50 |
MTDiscord |
<luatic> Blockhead256: It never does a linear search. |
| 15:50 |
MTDiscord |
<luatic> It does a binary search. |
| 15:50 |
Blockhead256 |
exactly, but at one time I believe that :\ |
| 15:51 |
muurkha |
Well, an exponential search |
| 15:51 |
muurkha |
followed by a binary search |
| 15:51 |
Blockhead256 |
how can it do a binary search when there may be discontinuities? |
| 15:51 |
MTDiscord |
<luatic> muurkha: not quite |
| 15:51 |
muurkha |
it gives the wrong answer at random when there are discontinuities |
| 15:51 |
MTDiscord |
<luatic> in my Lua-only implementation, I do indeed use exponential "ramping up" at the beginning |
| 15:51 |
MTDiscord |
<luatic> Lua does not have to do this |
| 15:51 |
muurkha |
oh, thanks for the correction |
| 15:51 |
MTDiscord |
<luatic> Lua can use the size of the hash part plus the size of the array part as an upper bound |
| 15:51 |
MTDiscord |
<Warr1024> Hmm, I thought # was supposed to be fast on tables, because it just references an internal length-tracking variable... |
| 15:52 |
MTDiscord |
<luatic> Warr1024: It does for tables used only as lists. |
| 15:52 |
Blockhead256 |
that what I was saying warr.. |
| 15:52 |
MTDiscord |
<luatic> Most likely there is a "fast path" for this even |
| 15:52 |
Blockhead256 |
luatic: but I thought # only applied to numeric indices, and so to the array-part not the hash-part? |
| 15:52 |
MTDiscord |
<Warr1024> 99% of the time when you're doing t[#t+1] we ARE talking about tables that are only being constructed sequentially. |
| 15:53 |
MTDiscord |
<luatic> Blockhead256: Numeric indices might as well appear in the hash part. |
| 15:53 |
muurkha |
you mean, they might also appear? |
| 15:53 |
Blockhead256 |
because of discontinuities? |
| 15:53 |
MTDiscord |
<luatic> not only that |
| 15:53 |
MTDiscord |
<luatic> a sequence with keys 1...n can be stored in the hash part |
| 15:53 |
MTDiscord |
<Warr1024> If you're appending to an "array" table after having made other arbitrary random-access changes to it, then you're probably doing too much with a single table already and the speed of t[#t+1] is not your biggest problem anymore. |
| 15:53 |
MTDiscord |
<luatic> if it is built in the wrong order for example |
| 15:54 |
MTDiscord |
<Warr1024> WDDTT |
| 15:54 |
Blockhead256 |
"The length of a table t is defined to be any integer index n such that t[n] is not nil and t[n+1] is nil; moreover, if t[1] is nil, n can be zero. For a regular array, with non-nil values from 1 to a given n, its length is exactly that n, the index of its last value. If the array has "holes" (that is, nil values between other non-nil values), then #t can be any of the indices that directly precedes a nil value (that is, it may consider any such |
| 15:54 |
Blockhead256 |
nil value as the end of the array)." <- so you're right, if there are discontinuities, abandon all hope |
| 15:55 |
MTDiscord |
<luatic> basically yes |
| 15:55 |
MTDiscord |
<luatic> Lua fun fact: This implies that for i = 1, #t do ... end may be slower than for i in ipairs(t) do ... end ;) |
| 15:56 |
Blockhead256 |
ipairs is always a good idea (unless you need pairs of course) |
| 15:57 |
Blockhead256 |
it's just that to my average estimation of a Lua programmer ( :( sorry), iterators may as well be a magic language function and not something you can write yourself |
| 15:58 |
Blockhead256 |
Now I would like to share an interesting blog post with you all, which some of you may have seen. I know the authorship may be more controversial than some (but certainly less than others), since it discusses Minetest forks as well |
| 15:58 |
Blockhead256 |
https://poikilos.org/2020/05/09/minetest-scope-issue/ |
| 15:58 |
MTDiscord |
<luatic> Well, this is the wrong attitude to programming IMO - you always need to be prepared to dig into something further down your stack - and in particular the wrong attitude to Lua, a minimalistic language that can very well be fully learned. |
| 15:59 |
Blockhead256 |
Which I think makes an important point (my takeaway at least) that the Minetest project as a whole benefits much more greatly by having backing behind common mods, and so can I ask, can we do better with minetest-mods as an organisation? I'll of course put my hand up to help with that. |
| 16:00 |
MTDiscord |
<Warr1024> "can be fully learned" is a pretty bold claim to make when a new interpreter with new nuances could come out any day and invalidate all your assumptions about total mastery. |
| 16:00 |
|
jwmhjwmh joined #minetest |
| 16:00 |
MTDiscord |
<luatic> Warr1024: Fine, but for MT at least it's practically pinned to 5.1 |
| 16:01 |
Blockhead256 |
luatic: Of course, I believe strongly in the "dig down the stack" approach myself and have been known to do it often enough. Dig down the stack, get tooled up, read some docs, and so on. I just wish all who code were so dedicated to their learning |
| 16:01 |
MTDiscord |
<luatic> 5.1 / LuaJIT* |
| 16:02 |
Blockhead256 |
Let's distinguish language library features, syntax and so on from interpreter-specific knowledge. Yes, you could technically make flashcards for every library function and about every operator and syntax element and learn Lua completely.. much faster than say, C, C++, Rust, Golang, Java etc. |
| 16:03 |
|
est31 joined #minetest |
| 16:03 |
MTDiscord |
<Warr1024> That whole article seems to be based around the assumption that MTG is the "official" game for Minetest, which is actively becoming less true over time. |
| 16:03 |
MTDiscord |
<Warr1024> It basically sounds like it's suggesting that mediocrity should be enforced as a standard. |
| 16:04 |
Blockhead256 |
Language knowledge is knowing how to use the I/O library. Interpreter knowledge is peppering the start of every file with local this local that so it will run faster in LuaJIT xD |
| 16:04 |
MTDiscord |
<Warr1024> I mean, if you're manually peppering locals instead of having a script that automatically does it across your entire codebase, what are you even doing with your life XD |
| 16:05 |
Bombo |
lissobone: what have we done? ;) |
| 16:05 |
Bombo |
lissobone: btw it worked, thx |
| 16:05 |
Blockhead256 |
Warr1024: I mean I know full well the Minetest wants to be an engine, not a game. However, one really good game for Minetest engine makes the whole thing shine. |
| 16:06 |
MTDiscord |
<Warr1024> Right. We're still working on that. |
| 16:06 |
MTDiscord |
<Warr1024> There are now actually a number of pretty good games. |
| 16:07 |
MTDiscord |
<Warr1024> There are even multiple projects trying to turn MTG into a good game, and hopefully one of them starts to really get traction (mesecraft sounds promising, maybe?) |
| 16:07 |
Blockhead256 |
Also the article has made me think about the 'compatibility breakage' debate in a new way. Upgrading clients is trivial. I'll spare no thoughts for bootleg iOS versions. But keeping server owners on-side by having a strong minetest-mods organisation could help with the the constant complaints about breakage |
| 16:08 |
Blockhead256 |
And better yet, I guess, is that this can be done entirely without requiring more than a passing thought from core devs I would say. Also just the normal call to improve testing that we should all follow.. |
| 16:08 |
MTDiscord |
<luatic> The only part I somewhat agree with is the observation that our current testing sucks |
| 16:09 |
MTDiscord |
<luatic> I always love it when someone tells others how they should use their resources |
| 16:09 |
MTDiscord |
<luatic> (not you, but poikilos in this case) |
| 16:09 |
muurkha |
I keep misinterpreting MTG as "Magic the Gathering" |
| 16:09 |
MTDiscord |
<luatic> e.g. "the core devs ought to provide 0.4 support because I CBA to update my shit" |
| 16:09 |
Blockhead256 |
it's called consulting :) done outside and for free however... |
| 16:10 |
MTDiscord |
<Warr1024> Yeah, I see MTG as minetest_game, magic the gathering, AND the initials of a rather controversial political figure, all at the same time. I have to pay attention to which channel I'm seeing it in to know how to read it 😄 |
| 16:10 |
Blockhead256 |
yes, the overring message that I get from detractors is "we're going to make sure everything keeps working.. forever!".. sure.. sure.. |
| 16:10 |
MTDiscord |
<luatic> The whole article comes across as pretty whiney to me - "the core devs are not doing enough unpaid work for me! how dare they!" |
| 16:11 |
muurkha |
fortunately I spend very little times reading about controversial political figures so it took me a while to figure out who you meant :) |
| 16:11 |
MTDiscord |
<Warr1024> I mean, if you want compatibility forever, then feel free to do the work forever, I guess. You'll get no complaints from me about it. I think that the work that the "archivists" do to keep pieces of history alive as long as they can are quite laudable, actually. |
| 16:12 |
Blockhead256 |
0.4.x servers strike me much more as museum pieces than bastions of progress to be honest |
| 16:12 |
|
Trifton joined #minetest |
| 16:13 |
MTDiscord |
<Warr1024> Museums are nice too. They, and innovation, are neither substitutes for one another. |
| 16:13 |
Blockhead256 |
at best something like Old School RuneScape where they have decided to keep the old school vibes going.. at worst, it makes you wonder "why do they keep this place running?" |
| 16:15 |
muurkha |
Warr1024: agreed |
| 16:17 |
MTDiscord |
<Warr1024> Making new things is great. Preserving our past is great. If those things could be made to work together smoothly, that's also great, but if not, i.e. if we don't have the resources for it, or if the people involved in each side can't find enough common ground, that's okay, I'll still appreciate each of the things on their own. |
| 16:20 |
muurkha |
A problem in the Python community is that to overcome the inertia of the move to Python 3, advocates have resorted to deprecating not just Python 2 but users of Python 2 |
| 16:21 |
muurkha |
And this has sort of grown into a general contempt for backward-compatibility |
| 16:22 |
lissobone |
Why not just carefully plan everything before making a project, thus avoiding almost all version hops and deprecations? |
| 16:23 |
MTDiscord |
<MarkTheSmeagol> What, a programmer? Plan something? What do you think this is, a critical part of modern infrastructure? |
| 16:23 |
lissobone |
You're a coder if you're not planning. |
| 16:23 |
Blockhead256 |
that's called a big design up front, and it results in projects that never get anywhere because you have to decide exactly where to go before making any progress |
| 16:24 |
MTDiscord |
<luatic> That's called "forward compatibility" and it's like 10x the effort. |
| 16:25 |
Blockhead256 |
As best I can gather, Minetest has had a policy of deprecating things that were just badly design in the first place, and replacing them with better things. |
| 16:25 |
MTDiscord |
<MarkTheSmeagol> Unless you just decide to leave space for extra flags and then never use that space (looking at you, x86 architecture) |
| 16:27 |
Blockhead256 |
At the risk of sounding like a Rustacean: we wouldn't seriously ask people to keep compatibility with drivers who don't want to drive with a seatbelt on after passing a law requiring them in vehicles, now would we? |
| 16:28 |
celeron55 |
the answer to that 2020 post by poikilos is basically content.minetest.net. it's impossible to move forward with a contributor based open project like this if you insist having absolute compatibility, testing and such. besides, even fields like automotive are moving away from the waterfall development model where you first make a perfect specification and only then implement, and end development once |
| 16:29 |
celeron55 |
you're done |
| 16:29 |
Blockhead256 |
in part automative has to do it that way because there's so so many computer systems in a modern car that you have to keep fixing the bugs will into the lifecycle.. |
| 16:30 |
Blockhead256 |
but no you're right. The article is not new and ContentDB has been good. Sometimes they even make hotfixes for abandoned/mostly abandoned mods |
| 16:31 |
celeron55 |
this doesn't mean no thought shouldn't be spent on compatibility. but you can't spend all your thought on it. at some point you have to get stuff done too |
| 16:31 |
MTDiscord |
<Jonathon> there is one instance of that, usually mods are replaced rather than hotfixed |
| 16:32 |
|
DeepThot joined #minetest |
| 16:32 |
muurkha |
maintaining a stable interface doesn't mean never changing anything behind the interface, but mods can reach pretty deeply into the Lua codebase |
| 16:33 |
lissobone |
Greetings. |
| 16:34 |
celeron55 |
the idea of a centralized official engine-external api authority of sorts seems quite extreme to me |
| 16:34 |
celeron55 |
but as anything, if someone makes it and it seems to work well and promote both compatbility and new development, then whatever, it can be made official |
| 16:35 |
MTDiscord |
<Warr1024> They can have an authority if they want, as long as they can handle people not listening to it. |
| 16:35 |
rubenwardy |
Blockhead256: poikilos is biased |
| 16:36 |
Blockhead256 |
rubenwardy: well yes, that much is clear if you read his blog widely or even just read between the lines in that article. |
| 16:36 |
celeron55 |
you can pick up the facts and leave the opinions aside |
| 16:37 |
Blockhead256 |
now I think the last thing we want is an elite clique of 'official mod maintainers' or something that get to veto any engine changes 'because I'd have to update too many mods' |
| 16:37 |
celeron55 |
but, the post is 27 months old |
| 16:39 |
Blockhead256 |
still I think we need strong modding organisations. And we do. mt-mods is going quite strong. Even minetest-mods is, when you consider it covers 196 repositories.. |
| 16:39 |
celeron55 |
the thing is, if you don't allow changing any apis, then you essentially give a huge barrier to creating any new ones, as they have to be perfect right from the start |
| 16:39 |
celeron55 |
which results in developers being scared of creating new apis |
| 16:39 |
celeron55 |
which results in no new apis |
| 16:40 |
MTDiscord |
<Warr1024> Veto power, no. It'd be nice to have a steering committee or something, to allow engine changes to take into account the actual potential for downstream impacts, e.g. possibly even getting game devs to commit to supporting certain things if the upstream changes needed are made. But I imagine a real-world group like that would have at least as many innovation-pushers as museum-curators. |
| 16:40 |
celeron55 |
the best you can do is design the api in such a way that it's easy to improve without breaking compatibility in a major way |
| 16:40 |
Blockhead256 |
So we have it much better than poikilos' estimation of course. But as with any open source thing - forks and conflicting visions are just bound to happen, and can't be helped. I stand by Minetest's vision though. |
| 16:40 |
muurkha |
celeron55: agreed |
| 16:40 |
rubenwardy |
"design the api in such a way that it's easy to improve without breaking compatibility" |
| 16:40 |
rubenwardy |
yeah, this is the way to do it |
| 16:40 |
rubenwardy |
that and API testing |
| 16:40 |
MTDiscord |
<Warr1024> The whole "never break compat" thing is sort of demanding that some other group deal with all the frustrations of development and you never have to. There's frustration to go around and everyone needs to shoulder their own share. |
| 16:40 |
celeron55 |
this also means designing the related network protocols in such a way |
| 16:41 |
celeron55 |
that's often harder than the lua part |
| 16:41 |
celeron55 |
disk formats are less often needed but those are even more annoying |
| 16:41 |
MTDiscord |
<Warr1024> It's important to remember that you learn as you go, so you can't design everything with perfect knowledge at the start, and you need to be prepared to fix your mistakes and apply what you've learned later on. This includes the meta-problems, like designing an API so that it can be extended: it takes time to learn how to do even that. |
| 16:41 |
celeron55 |
Warr1024: that's a good way to put it too |
| 16:42 |
Blockhead256 |
if we had a core suite of mods with strong regression/unit/integration testing that could be run in CI with every Minetest version, that would probably help |
| 16:43 |
MTDiscord |
<Warr1024> Yes, having our tests factor in a real-world sample of what's expected from the engine would be great. But good tests also take work to create and maintain, so it's unsurprising that they haven't already happened. |
| 16:44 |
MTDiscord |
<Warr1024> Frankly the lack of real-world-like-ness of tests is one of the biggest criticisms I have for tests that I see (besides of course the obvious "not having tests in the first place" problem which dominates) |
| 16:44 |
MTDiscord |
<luatic> The problem is that scripting in-game tests isn't really possible. |
| 16:44 |
Blockhead256 |
the thing that irks me is when certain people upgrade to a new stable branch, go "x, y and z are now mildy broken from last stable, never upgrading again". No, what you should be saying is.. "but here's how exactly I got things to break, now please fix them in a .1, release" |
| 16:45 |
lissobone |
Breakage is the result of complexity. |
| 16:45 |
MTDiscord |
<luatic> You can trivially script Lua-only unit tests that pertain to Lua-only interfaces, but testing interactions isn't really possible. |
| 16:45 |
MTDiscord |
<luatic> Apart from manual testing of course. |
| 16:46 |
MTDiscord |
<Warr1024> I mean, when I talk about "testing" I'm not exclusively talking about "automated tests", though those are sort of the ideal standard. Sometimes the best you can do is just pushing out a beta release and getting people to try lots of stuff on it. Ideally, you try to come up with ways to encourage actual testing to happen with it, at least. |
| 16:46 |
MTDiscord |
<luatic> We need a fully scriptable Minetest client basically. |
| 16:46 |
MTDiscord |
<luatic> There have been some attempts in Go, but none got to a state of completion unfortunately. |
| 16:46 |
MTDiscord |
<Warr1024> Breakage is the result of complexity. Complexity is the result of theory colliding with reality. |
| 16:46 |
Blockhead256 |
we need to keep cranking out new eyecandy in every stable release so that people will install -dev clients to get the features early xD |
| 16:47 |
MTDiscord |
<luatic> hehe yes |
| 16:47 |
MTDiscord |
<Warr1024> I personally don't use much eyecandy but it's nice that it's helping 😄 |
| 16:47 |
MTDiscord |
<luatic> it's a shame how few modders use -dev versions |
| 16:47 |
MTDiscord |
<luatic> and then of course their mods suddenly get broken |
| 16:47 |
MTDiscord |
<luatic> and all of this could've usually been caught months earlier |
| 16:47 |
MTDiscord |
<Warr1024> Modders never running dev versions is just ASKING to have an emergency scramble to fix sudden compatibility issues the day the next MT version is released. |
| 16:47 |
MTDiscord |
<luatic> and if not then, at least in the feature freeze |
| 16:48 |
MTDiscord |
<Warr1024> I actually tend to do a worse job maintaining meeting my target for backward compatibility than forward, but 🤷 |
| 16:48 |
MTDiscord |
<Warr1024> Part of the problem with old versions is that it's so painful going back to one after a significant bugfix has been merged into master 😄 |
| 16:48 |
Blockhead256 |
there's the other sort of modders though. When we're still months from a stable release and they already *require* a -dev client just to get the new hotness |
| 16:49 |
MTDiscord |
<luatic> hehe |
| 16:49 |
MTDiscord |
<luatic> that's fair though |
| 16:49 |
MTDiscord |
<luatic> sometimes you need the new hotness |
| 16:49 |
Blockhead256 |
it's also impossible to go back once your map is zstd compressed.. |
| 16:49 |
MTDiscord |
<Warr1024> Requiring a -dev version is okay if your mod hasn't been "officially released" yet, but stopping support for an existing release when the new one isn't ready yet would be pretty nasty. |
| 16:49 |
|
DeepThot joined #minetest |
| 16:50 |
MTDiscord |
<Warr1024> Yeah, zstd was a big flag day for me. It actually forced me to hold back on updating my server and use a workaround for a bug instead of the actual fix for a while. |
| 16:51 |
MTDiscord |
<Warr1024> My backward compat standards for my game vs. my server world snapshots are different though. I support current + 1 old for my game, but I don't stricly support any old versions for the server. |
| 16:51 |
MTDiscord |
<Warr1024> I'm already using sqlite mod_storage after all. |
| 16:53 |
sfan5 |
> <Warr1024> Part of the problem with old versions is that it's so painful going back to one after a significant bugfix has been merged into master 😄 |
| 16:53 |
sfan5 |
slight offtopic but: this is why I'm so baffled when people voluntarily keep using 0.4 |
| 16:54 |
sfan5 |
I have seen many many bugfixes merged where you think "wow this is seriously bad, how was that even usable?" and then imagine bringing all of them back in one version |
| 16:55 |
Blockhead256 |
yeah I have enjoyed JT2 for instance but needing to use a 0.4.17.1 client just to play is really terrible |
| 16:55 |
DeepThot |
ok, i've got a strange issue.... I am running the flatpak version of minetest as a server on debian 11. Last night, minetest got a sigterm ~10 sec after i ran sudo zzz on my local machine, while it was SSHed into the server |
| 16:55 |
DeepThot |
i cannot figure out what caused the sigterm |
| 16:56 |
MTDiscord |
<Warr1024> broken pipe? |
| 16:56 |
MTDiscord |
<Warr1024> normally I'd expect a SIGPIPE in that case, but shenanigans can be involved in signal handling. |
| 16:56 |
DeepThot |
ya i dont get why it would cause sigterm. i guess the real answer is "dont do that" |
| 16:57 |
MTDiscord |
<luatic> anyways Blockhead256, yes Lua 5.1 and LuaJIT only iterate once over the interval, but it's still linear time because they presumably use an exponentially growing string buffer (the same string.gsub uses - it's a shame this buffer was never exposed without the gsub) |
| 16:59 |
|
DeepThot joined #minetest |
| 17:00 |
|
appguru joined #minetest |
| 17:09 |
muurkha |
if you got sigterm there was some process sending the sigterm |
| 17:09 |
DeepThot |
ya no clue what it would have been |
| 17:09 |
muurkha |
I'm guessing something flatpak-related |
| 17:09 |
DeepThot |
that was my suspicion as well |
| 17:10 |
MTDiscord |
<Warr1024> That process COULD be some kind of "supervising" process which is itself reacting to a SIGPIPE. |
| 17:10 |
muurkha |
is zzz a command I don't know about or is it a placeholder for some command that doesn't matter? |
| 17:11 |
DeepThot |
suspend/sleep/hybernate is handled by zzz on void |
| 17:11 |
DeepThot |
https://pastebin.com/raw/Dq3tJ5Rb |
| 17:11 |
MTDiscord |
<Warr1024> zzz is generally a command that tells the machine to sleep/suspend. |
| 17:11 |
muurkha |
aha, thanks |
| 17:11 |
DeepThot |
journalctl from the debian server |
| 17:11 |
muurkha |
it seems plausible that power management might shut down containers? |
| 17:12 |
muurkha |
but not, normally, on a totally differnt machine\ |
| 17:12 |
muurkha |
also 10 seconds is too fast for a TCP timeout |
| 17:12 |
MTDiscord |
<Warr1024> it really should suspend them but not kill them, same as it does with other processes. Closing network pipes makes a lot of sense though. |
| 17:13 |
muurkha |
I don't know anything about flatpak but I can easily imagine writing a service containerization system which shuts down restartable daemons before suspending |
| 17:14 |
DeepThot |
if relevant, the flatpak is run from a shell script which is called at @reboot via cron |
| 17:14 |
DeepThot |
im guessing its no big deal though and just simply dont zzz while ssh'd in |
| 17:14 |
muurkha |
maybe it was a coincidence |
| 17:15 |
DeepThot |
if coincidence, then what the heck caused the sigterm? |
| 17:15 |
DeepThot |
that is more mysterious than flatpak badly handling broken pipe |
| 17:17 |
MTDiscord |
<Warr1024> FlatPak and an @RebooT cron job are MAYBE not the best setup for running a server ... just gotta put that out there 😅 |
| 17:17 |
MTDiscord |
<Warr1024> haha, crap, there's actually a discord user named reboot? |
| 17:17 |
DeepThot |
ya, well.... im helping a friend with the server and he chose debian 11 |
| 17:17 |
DeepThot |
it was unavoidable unless i wanted to build minetest from source |
| 17:18 |
DeepThot |
i would have much rather just installed from repo but the version of minetest in debian 11's repos is old, and mods werent working with it |
| 17:29 |
MTDiscord |
<Warr1024> I generally use debian. flatpak is how you run a client on debian without recompiling; for a server, generally, use docker. |
| 17:30 |
muurkha |
building minetest from source took me about an hour and a half the first time I did it |
| 17:31 |
MTDiscord |
<Warr1024> Yeah, since getting my docker setup working, I've generally avoided building from src on the same machine I'm going to host on, and run builds on a different dev machine. |
| 17:31 |
muurkha |
but that was because I caught it at a time when the core devs had *just* made a backwards-incompatible change to Minetest's Irrlicht fork, and I was trying to build the last released version of Minetest |
| 17:32 |
|
Leopold joined #minetest |
| 17:32 |
muurkha |
so I had to guess why I was getting compile errors and then look at the Irrlicht Git history |
| 17:32 |
muurkha |
hopefully now they are more careful about that kind of thing |
| 17:33 |
MTDiscord |
<Warr1024> Hmm, I never really build MT-master against Irr-master. I usually interrogate MT what version of Irr it wants and just use that. It's sort of like a "DIY submodule" kind of thing... |
| 17:33 |
muurkha |
I don't think it said at the time |
| 17:34 |
MTDiscord |
<Jonathon> yeah, the irrlicht dep is basically we need to do it ourselves even though its worse than the defacto solution |
| 17:34 |
muurkha |
I don't think the Irrlicht dep is bad, just that there was no indication of which version I was supposed to use |
| 17:35 |
MTDiscord |
<Warr1024> Submodules have certain problems, so I can see the point in trying to do something different ... though, in our case, it does seem like we've pretty much arrived at the same situation anyway, with some added drawbacks from being nonstandard. |
| 17:35 |
muurkha |
anyway I'd expect that normally building minetest from source would be about ten or twenty minutes if you haven't done it before but know how to compile things and have Debian already installed |
| 17:39 |
lissobone |
I compiled my copy of minetest myself. |
| 17:41 |
lissobone |
It never takes too long to compile. |
| 17:49 |
DeepThot |
id much rather compile than use docker |
| 17:52 |
MTDiscord |
<Warr1024> That sounds sorta like "I'd rather wear clothing than ride a bike." Doing one does not necessarily preclude you doing the other. |
| 17:55 |
|
ytterbium joined #minetest |
| 18:04 |
DeepThot |
why would i overcomplicate the setup w docker |
| 18:05 |
DeepThot |
i cannot see any advantage to using it, except using a precompiled container, which is still just a means to avoid having to compile |
| 18:07 |
muurkha |
the advantage to using Docker is that you know what your compile dependencies are |
| 18:07 |
muurkha |
so you can reproduce your past builds, and your builds don't break when you upgrade other things on the machine |
| 18:07 |
|
mrkubax10 joined #minetest |
| 18:12 |
MTDiscord |
<Warr1024> I don't see any reason to overcomplicate the setup with Docker. In fact, I would generally advise using it to do the exact opposite. |
| 18:16 |
MTDiscord |
<Warr1024> I use it, myself, to basically encapsulate a lot of the stuff involved in running an MT process inside a single unit, with a more easily controlled surface area, and which I can very easily both recreate, and replace with other units with differences in implementation but the same surface area. |
| 18:17 |
MTDiscord |
<Warr1024> The reproducibility is nice, but the surface area control is also pretty nice. |
| 18:18 |
MTDiscord |
<Warr1024> I also run plenty of stuff on NON-Docker setups, but it's a lot more work, since I have to create separate user accounts, look for options to bind things to unix-domain sockets instead of TCP so that I don't get port conflicts, deal with the fact that by default a /tmp is shared and things naively writing to it may leak across boundaries, etc. |
| 18:29 |
|
Talkless joined #minetest |
| 18:36 |
|
FavoritoHJS joined #minetest |
| 18:36 |
DeepThot |
all of the discussions of when to not use docker seem to apply to my use case, and i really dont want to learn it just to run someone elses server |
| 18:46 |
|
lhofhansl joined #minetest |
| 18:49 |
MTDiscord |
<Warr1024> Haha, well, the CORRECT way to run somebody else's server is "don't" |
| 18:51 |
|
appguru joined #minetest |
| 18:52 |
MTDiscord |
<Warr1024> Well, maybe more "ideal" than "correct"; you can't always avoid it, or at least, the cost is of avoiding is is not always worth it. |
| 18:53 |
FavoritoHJS |
why can't you use your own server, and copy everything else? I don't think many mt mods are native |
| 18:55 |
MTDiscord |
<Warr1024> Well to me I can't tell if the use-case is "I want this MT server to exist but I can't get the hosting myself" or more like "I just want to help a friend, I'm not invested in this server in particular" so I guess that would matter. |
| 18:56 |
DeepThot |
"I just want to help a friend, I'm not invested in this server in particular" |
| 18:56 |
DeepThot |
i have my own server already, he just wanted help setting up mt+mods |
| 18:57 |
MTDiscord |
<Warr1024> Then in that case, the key thing you generally aim for is being able to hand it off quickly and not get stuck on the hook for unlimited maintenance work 😄 |
| 18:57 |
DeepThot |
ya in which case i think im done with it :P |
| 18:57 |
DeepThot |
i just shouldnt sleep my box while ssh'd into it, simple as |
| 18:57 |
MTDiscord |
<Warr1024> systemd running a restart script running a native-compiled binary is probably how I'd go in that case, but it helps that I already have a script to compile MT, and to remind me of which deps I need, on Debian. |
| 18:58 |
MTDiscord |
<Warr1024> If you can hand it off and not have to be ssh'd into it at all, then your work sounds done enough to me. |
| 18:58 |
DeepThot |
ya, i only ssh into it for funsies |
| 18:58 |
DeepThot |
to spy on what other players are doing, mostly |
| 18:58 |
DeepThot |
:P |
| 18:59 |
DeepThot |
i appreciate the help and insight everyone, i gotta run for now |
| 18:59 |
MTDiscord |
<Warr1024> If you can disconnect ssh, then later reconnect to it, and then sleep, and THAT kills the server still then that's a real head-scratcher. |
| 18:59 |
FavoritoHJS |
i'm guessing that might be some sort of network stack shenanigans |
| 18:59 |
DeepThot |
its only happened once so far, and i cannot seem to replicate it |
| 18:59 |
DeepThot |
so, meh :P |
| 18:59 |
DeepThot |
was more just curiosity is why i brought it up |
| 19:00 |
MTDiscord |
<Warr1024> That's fine then. For all you know it could be some weird coincidence like somebody running a poorly written pkill command at the same time you just happened to zzz. |
| 19:00 |
MTDiscord |
<Warr1024> Usually I don't worry about something until it happens a second time. |
| 19:01 |
MTDiscord |
<Warr1024> If you've got like the ncurses terminal open in a tmux session or something, then that would make it make a little more sense to me, I guess ... I never use the ncurses/stdio terminal stuff other than just piping stdout/stderr to logs/journal/whatever. |
| 19:02 |
DeepThot |
nah i mightve had htop running, and had nano running with the logfile open |
| 19:02 |
FavoritoHJS |
i recall that on windows, when a program sends data to the console and you have something selected there, the whole program hangs until you deselect it |
| 19:03 |
DeepThot |
ok really gotta go now tho, interview time |
| 19:05 |
|
jwmhjwmh joined #minetest |
| 19:07 |
MTDiscord |
<Warr1024> Actually looking at the log dump again, I wonder if it could be because systemd thought the process was tied to the user session somehow, and that session needed to get torn down when the ssh client disconnected. I never really got the "user session" thing that systemd does. |
| 19:08 |
DeepThot |
i generally try to avoid systemd :P |
| 19:09 |
MTDiscord |
<Warr1024> I so often find myself using A because I'm trying to avoid B, using B because I'm trying to avoid using C, and using C because I'm trying to avoid using A, so it all sort of comes out the same anyway 😑 |
| 19:10 |
MTDiscord |
<Warr1024> I had tried to avoid adding stuff to systemd in the past, but I've had only limited success. |
| 19:12 |
MinetestBot |
[git] TurkeyMcMac -> minetest/minetest: Break long lines of option help (#13136) 956026b https://github.com/minetest/minetest/commit/956026bb6b20b8f4810404aaa373abb746f73910 (2023-01-12T19:12:05Z) |
| 19:15 |
MinetestBot |
[git] TurkeyMcMac -> minetest/minetest: Increase `ftos` precision (#13141) 5f2925c https://github.com/minetest/minetest/commit/5f2925c59cb3b6fa580e565e2d5a4dad3c400eeb (2023-01-12T19:12:31Z) |
| 19:22 |
MTDiscord |
<luatic> TurkeyMcMac: "Decimal32 supports 7 decimal digits of significand" - why are you setting 10 digits? You should be safe with 7 or 8. |
| 19:24 |
|
Neptune85 joined #minetest |
| 19:26 |
MTDiscord |
<luatic> NVM, should've read the docs (luk pointed me towards them) |
| 19:41 |
|
mrkubax10 left #minetest |
| 19:44 |
|
sometalgoo1 joined #minetest |
| 20:07 |
|
Fixer joined #minetest |
| 20:21 |
FavoritoHJS |
why can't i get metatables from a client mod? |
| 20:38 |
|
Desour joined #minetest |
| 20:41 |
MinetestBot |
[git] TurkeyMcMac -> minetest/minetest: Improve `MetaDataRef:{get,set}_float` precision (#13130) 3992a13 https://github.com/minetest/minetest/commit/3992a13f24fec116cd4d0920dfd51abaf76a207e (2023-01-12T20:40:34Z) |
| 21:08 |
|
Trifton joined #minetest |
| 21:11 |
|
kabou joined #minetest |
| 21:11 |
|
Leopold joined #minetest |
| 21:45 |
|
DeepThot joined #minetest |
| 21:59 |
|
Leopold joined #minetest |
| 22:58 |
|
est31 joined #minetest |
| 23:21 |
MTDiscord |
<Awkanimus> Given all the docker chat earlier, just wanted to say that so far my podman setup seems to work pretty well. I used podman's generate to give me the systemd service definition and it runs rootless. |
| 23:21 |
MTDiscord |
<Awkanimus> I've got a regular segfault occuring which I'm still hunting but I don't think that has anything to do with the use of rootless podman. |
| 23:22 |
MTDiscord |
<Awkanimus> Interestingly, it does mean I can take the core file using coredumpctl and examine it elsewhere fairly easily. Also let's me swap out the container easily too |
| 23:23 |
DeepThot |
podman seems like it eliminates one of my concerns with docker |
| 23:23 |
DeepThot |
which is running it as root |
| 23:25 |
DeepThot |
i should probably set up my znc for this channel, i plan on hanging around |
| 23:25 |
DeepThot |
im already obsessed with mt |
| 23:29 |
|
DeepTht joined #minetest |
| 23:31 |
DeepTht |
eventually i want to learn lua and write a mod. i would love to have "mob glass" and the ability to make a fishtank with fish mobs + jellyfish mobs |
| 23:44 |
|
FavoritoHJS joined #minetest |
| 23:52 |
|
sometalgoo joined #minetest |
| 23:57 |
|
kilbith joined #minetest |
