| Time |
Nick |
Message |
| 00:00 |
ireallyhateirc |
generally speaking I make a city generation algorithm |
| 00:02 |
nekobit |
warr1024: why wouldn't it be merged? |
| 00:03 |
MTDiscord |
<warr1024> Because things tend to need to meet a high standard of usefulness to get merged. |
| 00:03 |
nekobit |
wsor4035: yes, enabling/disabling mods is much easier on the client |
| 00:03 |
nekobit |
This wouldn't be useful to you? Managing a server using a shell and an editor can be quite tedious sometimes. I figured this would be allowed considering minetest has an ncurses logger for convenience already. |
| 00:04 |
MTDiscord |
<wsor4035> nope |
| 00:04 |
MTDiscord |
<wsor4035> worldmods, git submodules, problem solved |
| 00:04 |
nekobit |
worldmods? |
| 00:04 |
MTDiscord |
<warr1024> minetest --world blah --enable stuff might be useful in theory, but it's a lot more work to support than sed 's/load_mod_stuff = .*/load_mod_stuff = true/' <blah/world.mt >.tmp && mv .tmp blah/world.mt. |
| 00:04 |
MTDiscord |
<wsor4035> create a folder called worldmods in your world folder, and it loads all the mods in there |
| 00:05 |
MTDiscord |
<warr1024> worldmods is one of a number of solutions that works for this and doesn't require developing, testing, maintaining, and supporting an engine feature. |
| 00:05 |
nekobit |
warr1024, i didnt just mean sed, but i mean actually adding mods to your world list, try enabling techage by downloading from curl/git without the client |
| 00:05 |
nekobit |
Anyway, didnt know about worldmods |
| 00:05 |
MTDiscord |
<warr1024> Sometimes things DO get merged that are mere "conveniences" but then that actually just serves to highlight the injustice of things that are actually irreplaceable not being merged 😆 |
| 00:06 |
nekobit |
I think my idea would be better off as a separate program tbh |
| 00:06 |
nekobit |
no? |
| 00:06 |
MTDiscord |
<wsor4035> anyways, i do think a command like minetest --world --enable/disable modname as a convivence function might be useful, but thats it |
| 00:07 |
MTDiscord |
<warr1024> Enabling a mod without using the client is pretty easy. Â I just create a folder and add a "url" and "branch" file to specify where the mod is to be cloned from, and then let my updater scripts pick it up and trigger the server restart countdown. Â It's really not that big of a deal not using the client, if you're already running a server. |
| 00:07 |
MTDiscord |
<warr1024> Separate program would definitely make the "getting it merged" aspect much less of a problem. |
| 00:08 |
MTDiscord |
<warr1024> IIRC there's a tool out there already that lets you install stuff from CDB via command line, which is nice because not all packages are synced between CDB and git. |
| 00:08 |
MTDiscord |
<wsor4035> yes |
| 00:08 |
nekobit |
Do I link directories to worldmods? Also, how would i one-off a modpack's mod? I.e. techage enables "stamina" and "unified_inventory" which I don't want |
| 00:09 |
nekobit |
if im understanding correctly, worldmods would just enable it all |
| 00:09 |
MTDiscord |
<warr1024> With worldmods,anything you put in there is automatically loaded and enabled. Â If you want to enable selectively, either don't use worldmods, or selectively delete stuff. |
| 00:09 |
MTDiscord |
<wsor4035> typically i get around modpacks only content by keeping them external and symlinking in the ones i want. |
| 00:10 |
nekobit |
warr1024: Only thing with a separate program is.. well id have to do it all myself. I figured minetest already had functions for all these things since it does it via the gui client already |
| 00:10 |
nekobit |
I could hack somethign up in perl I guess. |
| 00:10 |
MTDiscord |
<warr1024> I pretty much only ever use worldmods for SP stuff, like devleopment worlds. Â For servers I generally just install stuff into the shared mods. Â In a way, there's very little difference, since your world and mods are 1:1 on a server setup anyway. |
| 00:11 |
nekobit |
what I did initially was setup the world on my desktop, then scp my .minetest over. However, later on when I wanted to enable new mods, I found using curl, checking for updates, and enabling certain mods to be tedious |
| 00:11 |
MTDiscord |
<warr1024> Separate program is sort of the de facto standard. Â Some people have an updater script they run when they want to. Â I tend to have a container that's polling for updates. |
| 00:12 |
nekobit |
I think I will just make a seperate program them. If any devs object to making it an ncurses UI embedded into the minetest binary, please let me know. I figured it may work consider the GUI already has such functionality |
| 00:13 |
MTDiscord |
<warr1024> To add mods to my server, I add the repo and refs to the list of things the updater checks for and syncs, then I edit the master copy of the world.mt file, which overwrites the world dir copy each time the server is restarted. |
| 00:14 |
MTDiscord |
<warr1024> If it's ncurses then I already know I don't have a use for it. |
| 00:14 |
nekobit |
it could be both ncurses and a manual command |
| 00:15 |
nekobit |
well, i also wanted to be able to change mod options as well via command line, and its hard to tell what the settings for each mod is without reading their settingstypes.txt file (or just using the minetest client) |
| 00:15 |
nekobit |
Again, this is doable in my own program, but minetest already implements these things, but for gui only |
| 00:15 |
MTDiscord |
<warr1024> Is this a thing you're doing often enough that it makes sense to build a general solution? |
| 00:16 |
nekobit |
I think you could tell any scripter this and they'd be offended. |
| 00:16 |
MTDiscord |
<warr1024> Normally I just read settingtypes.txt by hand, edit the config file by hand, and then once I've got the settings set, I don't really need to worry about it again. Â If I have to tweak settings over time, I'll just remember what they mean from last time. |
| 00:16 |
nekobit |
its more of a "other people may like this" kind of thing, not just for me only |
| 00:16 |
MTDiscord |
<warr1024> Heh, I think scripters would be more offended at your implication that they just write scripts to write scripts and not because there's a real problem to solve 😑 |
| 00:17 |
nekobit |
I will happily spend 8 hours writing scripts for 2 minute tasks, thank you. |
| 00:18 |
MTDiscord |
<warr1024> If that's fun for you, then go for it. |
| 00:18 |
MTDiscord |
<warr1024> Minetest is, at its core, about fun after all. |
| 00:18 |
MTDiscord |
<luatic> not offended at all |
| 00:18 |
MTDiscord |
<luatic> then again i haven't scripted much lately... |
| 00:19 |
MTDiscord |
<luatic> and the little scripting i did was in python and related to real theoretical problems |
| 00:19 |
nekobit |
im debating just forking minetest and adding this myself since all these functions and utilities already exist in Minetest |
| 00:19 |
nekobit |
not sure i feel like dealing with build systems though |
| 00:19 |
nekobit |
does the CDB have a JSON api? |
| 00:20 |
MTDiscord |
<luatic> yes |
| 00:20 |
MTDiscord |
<warr1024> I'd rather maintain an expansive set of scripts than a fork. |
| 00:20 |
MTDiscord |
<luatic> the work required to properly maintain a fork is often underestimated |
| 00:20 |
MTDiscord |
<kimapr> that's why you improperly maintain it |
| 00:20 |
nekobit |
i wouldn't actually maintain the rest of the fork, im saying i only care about the commands |
| 00:21 |
MTDiscord |
<luatic> but if your fork is effectively a small patchset limited to changing files that aren't frequently touched you might be fine |
| 00:21 |
nekobit |
but if its just a json ui and some text replacing, then Perl should do the job just fine |
| 00:21 |
nekobit |
*json api |
| 00:22 |
nekobit |
Anyway, thank you for letting me know it wouldn't be merged. I will work on this tonight after I get my mod submitted. |
| 00:24 |
MTDiscord |
<warr1024> Perl should work fine. Â I've gotten away with just shell scripts, though the complexity of some things (e.g. detecting whether a change has happened so the server needs to be restarted) are starting to push things up to the edge of what I feel comfortable using shell scripts for. |
| 00:24 |
nekobit |
I dont feel like handling JSON with a shell script |
| 00:25 |
MTDiscord |
<luatic> hmm what wouldn't be merged by whom |
| 00:25 |
nekobit |
luatic: see #minetest-dev |
| 00:26 |
MTDiscord |
<luatic> i see |
| 00:26 |
nekobit |
I genuinely don't think it would be much code considering all the fetching and setting changing functions are already written in C++, but if it wont get merged then I wont write it. |
| 00:27 |
MTDiscord |
<luatic> changing settings is just editing minetest.conf though |
| 00:27 |
nekobit |
im talking about mod settings |
| 00:27 |
MTDiscord |
<luatic> well, define mod settings |
| 00:27 |
nekobit |
settingstypes.txt |
| 00:28 |
MTDiscord |
<luatic> yeah that's minetest.conf |
| 00:28 |
nekobit |
indeed |
| 00:28 |
nekobit |
They are just annoying to set by hand |
| 00:28 |
MTDiscord |
<luatic> i don't think i get the point |
| 00:28 |
rubenwardy |
nekobit: hey, adding cli support for ContentDB in the client is something I'd like to do |
| 00:28 |
rubenwardy |
It's not necessarily true that "it won't be merged" |
| 00:30 |
nekobit |
rubenwardy: What about changing settings in the cli and enabling/toggling mods for each world? |
| 00:30 |
nekobit |
are you fine with that? |
| 00:30 |
rubenwardy |
Yeah that makes sense |
| 00:30 |
MTDiscord |
<luatic> for me personally, this feature request so far sounds relatively low priority. on the other hand it's also relatively low effort (and low risk?); i certainly wouldn't be opposed to it, but i probably wouldn't bother reviewing it either. |
| 00:32 |
nekobit |
I personally believe it'd make managing a server a lot easier, so if it's okay, I will try adding it directly to minetest |
| 00:33 |
nekobit |
if not merged, that's fine. I've dealt with way stingier projects :^) |
| 00:33 |
|
Verticen joined #minetest |
| 00:35 |
rubenwardy |
The big issues with implementation are that the existing code is Lua and tied to the main menu, and the existing cli isn't very clean |
| 00:36 |
nekobit |
Wait, it's lua? |
| 00:37 |
rubenwardy |
Yes, the main menu is written in Lua |
| 00:37 |
rubenwardy |
https://github.com/minetest/minetest/issues/7358 |
| 00:37 |
rubenwardy |
If you're interested in how Minetest interacts with the cdb API and installs stuff see https://github.com/minetest/contentdb/blob/master/docs/minetest_client.md |
| 00:37 |
nekobit |
Oh wow, so you already had this in mind. I see |
| 00:38 |
nekobit |
Does it have to be C++? Can I not just use the lua functions straight from the cli? |
| 00:38 |
nekobit |
well, i suppose wrapping ncurses around that would be tedious |
| 00:39 |
rubenwardy |
No, the lua functions require c++ functions |
| 00:40 |
rubenwardy |
The ContentDB mainmenu integration is here https://github.com/minetest/minetest/tree/master/builtin/mainmenu/content |
| 00:41 |
nekobit |
yeah i already found it |
| 00:46 |
nekobit |
is core.check_mod_configuration mapped to a c++ function? |
| 00:49 |
nekobit |
im confused as to why pkgmgr has functions to enable mods, as it doesn't seem to do such a thing |
| 00:52 |
rubenwardy |
It does enable the mods and same them in world.mt |
| 00:52 |
rubenwardy |
*save |
| 00:53 |
nekobit |
i thought this was just for downloading packages though? How does it enable them for specific worlds? |
| 00:54 |
nekobit |
i thought enabling mods was part of the worlds menu |
| 00:54 |
rubenwardy |
It is. Which uses the pkgmgr |
| 00:54 |
nekobit |
Oh, i see now |
| 00:54 |
|
ShadowBot joined #minetest |
| 00:54 |
rubenwardy |
This folder is both those things |
| 00:55 |
nekobit |
Ok. in your github issue you mention moving it to C++. Do you mean just moving all the api calls to c++ libcurl as well as enabling/disabling mods, then linking them to lua? |
| 00:56 |
nekobit |
whilst still keeping the menu and all that in Lua |
| 01:00 |
|
illwieckz joined #minetest |
| 01:07 |
rubenwardy |
Yeah |
| 01:09 |
nekobit |
Cool. I'll see if I can do that as well, although personally, I'd keep any networking stuff in Lua cuz of potential buffer overflows or whatever |
| 01:17 |
nekobit |
> The recommended resolution is 1920x1080, and screenshots must be at least 920x517. |
| 01:17 |
nekobit |
huh |
| 01:18 |
nekobit |
shouldn't this imply aspect ratio, not 1920x1080? |
| 01:19 |
MTDiscord |
<warr1024> you aren't constrained to a particular aspect ratio |
| 01:19 |
MTDiscord |
<warr1024> There are a range of recommended ones though |
| 01:19 |
nekobit |
i couldn't upload a 1920x1080 image tho |
| 01:19 |
MTDiscord |
<warr1024> why? |
| 01:20 |
nekobit |
oh.. weird |
| 01:20 |
nekobit |
now i can |
| 01:20 |
|
ShadowBot joined #minetest |
| 01:21 |
nekobit |
Ok, submitted |
| 01:42 |
|
ShadowBot joined #minetest |
| 01:44 |
|
liceDibrarian joined #minetest |
| 01:53 |
|
bdju joined #minetest |
| 02:01 |
|
bdju joined #minetest |
| 02:04 |
|
YuGiOhJCJ joined #minetest |
| 02:57 |
|
sparky4 joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:05 |
|
TheSilentLink joined #minetest |
| 04:17 |
|
YuGiOhJCJ joined #minetest |
| 04:32 |
|
nopjmp joined #minetest |
| 04:50 |
|
beanbrain joined #minetest |
| 05:36 |
|
gregon joined #minetest |
| 06:23 |
|
TomTom joined #minetest |
| 06:49 |
|
TheSilentLink_ joined #minetest |
| 07:43 |
|
Glaedr joined #minetest |
| 07:51 |
|
Talkless joined #minetest |
| 07:58 |
|
SliverFlowCipher joined #minetest |
| 08:13 |
|
tarsovbak joined #minetest |
| 08:14 |
|
mrkubax10 joined #minetest |
| 08:22 |
|
Warr1024 joined #minetest |
| 08:22 |
|
SliverFlowCipher joined #minetest |
| 08:47 |
|
Warr1024 joined #minetest |
| 08:53 |
|
SliverFlowCipher joined #minetest |
| 08:54 |
|
TheSilentLink_ joined #minetest |
| 08:59 |
|
Izaya left #minetest |
| 08:59 |
|
Izaya joined #minetest |
| 09:30 |
|
Izaya left #minetest |
| 09:33 |
|
Izaya joined #minetest |
| 09:36 |
|
Izaya left #minetest |
| 09:37 |
|
Izaya joined #minetest |
| 09:44 |
|
TheSilentLink joined #minetest |
| 09:58 |
|
ireallyhateirc joined #minetest |
| 10:02 |
|
gregon1 joined #minetest |
| 10:05 |
|
gregon joined #minetest |
| 10:09 |
|
gregon joined #minetest |
| 10:12 |
|
gregon joined #minetest |
| 10:14 |
|
Hanicef joined #minetest |
| 10:19 |
|
tarsovbak joined #minetest |
| 10:27 |
|
jaca122 joined #minetest |
| 10:27 |
|
gregon1 joined #minetest |
| 10:28 |
|
SliverFlowCipher joined #minetest |
| 10:46 |
|
SliverFlowCipher joined #minetest |
| 10:49 |
|
gregon joined #minetest |
| 11:01 |
|
TheSilentLink joined #minetest |
| 11:27 |
|
mrkubax10 joined #minetest |
| 13:01 |
|
gh00p joined #minetest |
| 13:07 |
|
silverwolf73828 joined #minetest |
| 13:10 |
|
TheSilentLink joined #minetest |
| 13:11 |
|
tarsovbak joined #minetest |
| 13:13 |
|
bodiccea joined #minetest |
| 13:38 |
|
Verticen joined #minetest |
| 13:39 |
|
gregon joined #minetest |
| 13:40 |
|
tarsovbak joined #minetest |
| 13:48 |
|
SFENCE joined #minetest |
| 14:01 |
|
SFENCE joined #minetest |
| 14:41 |
|
jaca123 joined #minetest |
| 15:15 |
|
SliverFlowCipher joined #minetest |
| 15:20 |
|
tarsovbak joined #minetest |
| 15:31 |
|
SliverFlowCipher joined #minetest |
| 15:33 |
|
fluxionary joined #minetest |
| 15:53 |
|
fluxionary joined #minetest |
| 16:10 |
|
gregon joined #minetest |
| 16:13 |
|
bdju joined #minetest |
| 16:23 |
|
mrkubax10 joined #minetest |
| 17:33 |
nekobit |
also rubenwardy, i noticed that when you enable a modpack, it actually just flips the state of each mod, so disabled mods become enabled, which is a bug |
| 17:33 |
nekobit |
so i guess i can fix that on the way |
| 17:49 |
|
beanbrain joined #minetest |
| 17:49 |
|
beanbrain joined #minetest |
| 17:50 |
|
SliverFlowCipher joined #minetest |
| 17:50 |
|
tarsovbak joined #minetest |
| 17:50 |
|
gregon joined #minetest |
| 17:56 |
|
SliverFlowCipher joined #minetest |
| 19:05 |
|
bdju joined #minetest |
| 19:10 |
|
ireallyhateirc joined #minetest |
| 19:13 |
|
monstanner joined #minetest |
| 19:13 |
|
monstanner left #minetest |
| 19:15 |
|
SliverFlowCipher joined #minetest |
| 19:26 |
|
Hanicef joined #minetest |
| 19:47 |
|
beanbrain joined #minetest |
| 19:47 |
|
beanbrain joined #minetest |
| 19:58 |
|
Izaya left #minetest |
| 19:58 |
|
Izaya joined #minetest |
| 20:32 |
|
monstanner joined #minetest |
| 20:32 |
|
monstanner left #minetest |
| 20:55 |
|
jonadab joined #minetest |
| 20:59 |
|
BluebirdGrey51 joined #minetest |
| 21:00 |
BluebirdGrey51 |
How do I cancel all client-side movement of a player? I teleport a player to a position, but because of a previous :add_velocity() call they slide around for a bit. I'd like to do set_velocity(0) but docs say that isn't supported for players |
| 21:04 |
Mantar |
best option is to attach him to a motionless object. kind of hacky, but that seems to be where we're at |
| 21:30 |
|
simon816 joined #minetest |
| 22:04 |
MTDiscord |
<luatic> yes |
| 22:32 |
|
panwolfram joined #minetest |
| 22:51 |
|
Nusakan joined #minetest |
| 22:55 |
|
Opus joined #minetest |
| 22:56 |
ireallyhateirc |
So yesterday I tried doing long view range on my minetest client, after going through a jungle of settings I finally managed to get a somehow good result. Why are these settings scattered so much? |
| 22:58 |
ireallyhateirc |
To achieve that I needed to change max_block_generate_distance, client_mesh_chunk, client_mapblock_limit, max_simultaneous_block_sends_per_client, viewing range, etc. |
| 22:59 |
ireallyhateirc |
would be better if that was covered by one setting, because it is impossible to set that youself unless you have decent knowledge of minetest internals |
| 22:59 |
ireallyhateirc |
is this the issue for this, or should I make a new one? https://github.com/minetest/minetest/issues/5024 |
| 23:05 |
|
Eragon joined #minetest |
| 23:12 |
|
Eragon_ joined #minetest |
