Time Nick Message 03:46 ensayia good evening 03:49 ensayia Is there a direct function to remove one item from a player inventory and exchange it for another? I have an item that checks if you use it on a stone group (working) and I want it to be removed from the player's inventory and replaced with a tool. I can simply add the new item and clear the itemstack (the breakable has a max stack of one anyway) but that fails to give the player the new tool if the inventory is full. I was 03:49 ensayia hoping there's a way to do a 1:1 swap. 04:00 ensayia Oh goodness nevermind. A little looking and using my brain later, I can just make a new ItemStack() with my chosen item and return that instead. 11:34 sfan5 merging #12794, #12804, #11934 in 5m 11:34 ShadowBot https://github.com/minetest/minetest/issues/12794 -- Fix two spelling mistakes by coldtobi 11:34 ShadowBot https://github.com/minetest/minetest/issues/12804 -- Fix double escape in update checker dialog by appgurueu 11:34 ShadowBot https://github.com/minetest/minetest/issues/11934 -- Briefly explain how facedir rotations work by aerkiaga 13:47 Wuzzy What is the official policy regarding protocol bumps? When to bump / when not to bump? 13:48 sfan5 during development do it when necessary but it's also done at least once per release 13:55 sfan5 Krock: if you have tested #11939 feel free to count one approval from me 13:55 ShadowBot https://github.com/minetest/minetest/issues/11939 -- Restore and enhance bouncy behavior by pecksin 13:55 sfan5 (since I didn't do more than look at the code) 13:56 Zughy[m] TurkeyMcMac core dev before the meeting? To have some PRs of them merged 13:56 Zughy[m] *their 14:14 Krock a bump becomes necessary when no other (reasonably easy) solution can be implemented. for packets, there's usually the option to append new bytes (server-side) and old clients will not read them. no version checks needed for that. 14:15 Krock however in your case, a bump (i.e. increase) is necessary to differentiate new clients from older ones 14:16 Krock sec 14:17 Krock ah yes. I was wrong about my serialize() comment and got confused by the C++ comment 14:18 Wuzzy is it theoretically possible to do a release (non-patch) without a prot bump? 14:19 Krock sure. that has happened in the past 14:19 Wuzzy ok 14:20 Krock and modders got upset that there's no way to find out whether a client supports a certain feature or not 14:20 Wuzzy don't we have minetest.features for that? 14:20 Krock yes, also checks like "if objectref.newfunction then" presence checks 14:20 Wuzzy perhaps this isnt updated often enough (often forgotten) maybe 14:21 Krock also formspec versioning, hence I did not support that change 14:21 Krock s/change/versioning task for each release/ 14:22 Wuzzy ohhhh i just see in lua_api.txt modders actually know the prot version of the players!!! 14:22 Wuzzy interesting 14:23 Wuzzy i always thought it was internal only 14:23 sfan5 minetest.features and checking whether functions exist are for the server-side 14:26 Wuzzy Krock, I am still confused about your problem with #12807 14:26 ShadowBot https://github.com/minetest/minetest/issues/12807 -- Fix liquid drawtype faces sometimes not rendering by Wuzzy2 14:27 Krock liquid_alternative is not taken into consideration for non-liquids 14:27 Krock it'll always be CONTENT_IGNORE 14:28 Krock see src/nodedef.cpp L1684 14:28 Wuzzy oh wait... 14:29 Wuzzy WTF this if is completely wrong now! 14:30 Wuzzy because it now completely ignored liquidtype. I meant to put an OR here... ouch 14:31 Wuzzy obviously the alternative liquids need to be set in both cases: if its liquid in the sense of drawtype, or liuqid in the sense of flowing physics (or both, obv) 14:32 Krock aren't there nodes to test that in devtest? 14:33 sfan5 is liquid_alternative_flowing_id used for drawing, physics or both? 14:33 Wuzzy hmmm lemme check 14:33 Wuzzy i think both 14:34 Krock should be for both because content_t is faster than std::string 14:34 Wuzzy yes both 14:34 Krock (to look up the flowing node) 14:34 Wuzzy it makes sense, how else should minetest know which node is the flowing one? 14:37 Krock map.cpp L573 > liquid_kind = cf.liquid_alternative_flowing_id; this is the relevant part for the flow queue processing sfan5 14:40 Wuzzy its also in rendering, see client/content_mapblock.cpp line 457 14:41 Wuzzy when I think about it, i think we should update lua_txt.txt to make adding the alternative liquids a requirement. this is currently not explained very well. only exception could be if there is no flowing liquid counterpart 14:42 Wuzzy i could add this in the same PR, is that OK? (#12807) 14:42 ShadowBot https://github.com/minetest/minetest/issues/12807 -- Fix liquid drawtype faces sometimes not rendering by Wuzzy2 14:45 Krock it would be cleanest to have a separate PR. after all, you might find even more to correct in the liquids documentation 14:47 Wuzzy ok 15:23 Krock Wuzzy: is the (name == f.name) comparison necessary? 15:23 Krock integer comparisons are much faster than string 15:24 Wuzzy let me think... 15:25 Wuzzy my theory was that there might be a modder who deliberately does not specify the alternative liquids... 15:25 Wuzzy but i now thing this is unreasonable ... 15:25 Wuzzy yeah this name check can probably be nuked 15:25 Wuzzy no wait 15:26 Wuzzy what if a modder has only a node with drawtype = "liquid" (source rendering only) but no flowing variant (cuz it never flows)? 15:26 Wuzzy in that case, the alternative comparison would be CONTENT_IGNORE == CONTENT_IGNORE nad thus always true :-/ 15:27 Wuzzy oh wait again 15:28 Krock * always false 15:28 Wuzzy i already check for ignore haha 15:28 Wuzzy ok u know what? 15:28 Wuzzy I add more dummy nodes just to test this :P 15:29 Wuzzy (not in the PR for now, just a quick test) 15:30 Wuzzy at least the reported bug is fixed in that PR :P 15:30 Wuzzy (not that this is an excuse) 15:31 sfan5 unless you have a very special case you never want to compare names, only ids or properties 15:32 Wuzzy yeah this is a good point 15:33 Wuzzy this might actually be a strong case for forcing modders to *always* specify the alternative liquids then (even if its just for self-reference) 15:34 Wuzzy so even the single source node (with no flowing node) would be required to have a liquid_alternative_source 15:34 Wuzzy Yeah i think this might do the trick and then i can drop the name check safely 15:43 MTDiscord Krock: Is this a C++-side or a Lua-side comparison 15:44 Krock topic .. ? 15:44 MTDiscord "integer comparisons are much faster than string" 15:44 Krock C++ and I know well that there's short string optimizations, but these only work on .. well.. short strings. 15:44 MTDiscord Lua-side, strings are the cleanest way to implement enums since all strings are interned and thus comparisons are as fast as number comparisons 15:45 Krock good to know 15:45 MTDiscord I don't think there's a way to leverage Lua's string interning on the C++ side of things though if you always convert to a C++ str 16:04 Wuzzy oh i didnt know that, thanks 16:04 Wuzzy luatic, where did you read that? 16:04 Wuzzy or do you happen to be the inventor of Lua? :D 16:06 Wuzzy alright, the name check in the liquid PR is gone now. I tested, and it turned out to be completely unneccessary. Performance! :D 16:25 Krock Wuzzy: https://i.postimg.cc/HLSXkTCJ/grafik.png 16:26 Krock is this correct? 16:26 Krock I suppose the texture could be transparent for less impact 16:29 Wuzzy hmm 16:29 Wuzzy question is if we show a face there, which one? red or blue liquid? 16:29 Wuzzy lemme check if this is a regression 16:30 Wuzzy Krock: ok, this is old behavior that this PR does not touch 16:31 Krock that's good, I suppose. 16:32 Wuzzy i think im going to make the doc work on alternative liquids then because it needs work 16:32 Wuzzy (new PR) 16:45 MTDiscord Wuzzy: I don't remember where I read that (probably the PIL? doesn't seem to be in the reference manual), but it's an important thing to keep in mind - it enables the efficiency of strings in some places (e.g. as table keys). You can verify this yourself using collectgarbage"count" and creating the same string, say, a million times. 17:34 Zughy[m] What time is the meeting? In an hour? 17:36 Krock 24 minutes 18:00 Zughy[m] Let's go 18:03 Zughy[m] Krock: nrz: 18:04 Zughy[m] > Set visibility of players/hide them from others has been rebased twice, it's from 2020. Can anyone have a look at it? Or put it in the 5.7.0 milestone, I don't know 18:05 Zughy[m] It's #9863 18:05 ShadowBot https://github.com/minetest/minetest/issues/9863 -- Set visibility of players/hide them from others by Lejo1 18:07 Wuzzy so do i understand this right? 18:07 Wuzzy a player that is hidden is not seen by anyone else but they can still interact with the world? 18:08 Zughy[m] Yes 18:09 MTDiscord seems that all that can be done by mods, the only useful bit is not sending it to clients 18:09 Wuzzy weird that such a plyer does not even show up in get_player_names? making it invisible to the server too? O_O 18:10 Wuzzy Jonathon yeah but this seems the point as an anti-hack measure =) 18:10 Zughy[m] It's basically Minecraft vanish 18:11 Wuzzy hmmm are there chat commands in it? i dont see any. would make sense imo 18:11 Wuzzy on the other hand, will collide with mods then :/ 18:11 Wuzzy yeah probably lets not overload this pr lol 18:12 Wuzzy sadly, i cant compile it right now. irrlichtmt fail. do i need an old version? 18:12 MTDiscord seems something like https://github.com/minetest/minetest/issues/8045 would be better that gives mods control of the key thing, rather than a bulk action which mods can already do most of 18:13 Zughy[m] Imho it makes sense as an administration tool, as it makes you completely undetectable by players, cheaters included 18:13 MTDiscord sure, my only thing is bulking a bunch of stuff together 18:14 Wuzzy the code doesnt look like "bulking stuff together" tho 18:14 MTDiscord mods such as cloaking, catcommands implement this already, except for the sending of the player to clients 18:15 MTDiscord > object, in get_player_names or in the /status info three bluked items 18:15 Wuzzy do they have to overwrite anything? 18:16 Wuzzy ok the get_player_names thing seems completely out of place tho 18:16 MTDiscord the mods? yeah. overwriting certain minetest table functions is common when you start to do things like this 18:16 Wuzzy strange. but this does not actually appear in the diff. the PR text is lying!!! :O 18:17 Krock couldn't "is_visible" be adapted with additional functionality for players? 18:17 Wuzzy ok i think it is much better if things can be done without overwriting the minetest table (unless intended by minetest). it always feels hacky and clunky with a potential for mod conflict 18:18 Wuzzy ok lets ask a different question: can anyone compile and test this? Because i can't! :D 18:18 MTDiscord https://github.com/minetest/minetest/pull/8397 was the closed pr for just hiding players, entities 18:18 Krock apply the diff, not the patch. (if you want to test) 18:19 Zughy[m] Krock: Funny enough, is_visible is completely broken at the moment (I opened an issue months ago) 18:20 Krock and if it worked, it would break attachment chains for sure 18:20 rubenwardy Wuzzy: get_player_names is a client-side API thing. The purpose is to hide from the client 18:21 Krock I'd rather have basic features like hiding objects and leave the integration to mods, such as announcing the "leave" message or reassembling the status message (once that becomes configurable) 18:22 MTDiscord ^this 18:22 Krock or just don't care at all and let mods use transparent textures and make the player not pointable 18:23 MTDiscord you can already overwrite the status command i believe 18:23 Krock join/leave messages: yes. status? I don't think so. 18:23 MTDiscord its just a chatcommand 18:24 Krock core.get_server_status 18:24 Krock well yes I guess... 18:24 MTDiscord . //lua minetest.chat_send_all(dump(minetest.registered_chatcommands["status"])) 18:25 Wuzzy hmmm, attachment chains sure sounds like an issue 18:26 Wuzzy protip. there is luacmd mod, you dont need WorldEdit 18:27 MTDiscord protip, i dont care 18:27 Zughy[m] rubenwardy: you were the one supporting it, thoughts? 18:27 Zughy[m] Let's be civil, thank you 18:27 Wuzzy hmmm overwriting the status command by hand soudns really ugly tho. you must rewrite the *entire* status, you cant just cleanly replace portions of it without messing up the rest 18:28 rubenwardy it's not visibility, it's also sending updates 18:28 MTDiscord wuzzy: thats incorrect 18:28 rubenwardy tbh I supported it because I started to review it in the past, it's not something I want to do right now 18:28 Wuzzy and the !!!FUN!!! begins if minetest ever decides to change the status line 18:28 Krock Wuzzy: hacky approach: retrieve the original value and string replace the hidden users 18:28 MTDiscord and that already happened 18:28 MTDiscord this is why minetest.get_server_max_lag() exists 18:29 Wuzzy yes 18:30 Wuzzy the status text is NOT meant to be parsed as far i know 18:30 MTDiscord you can build the whole string without needing to parse it 18:31 MTDiscord its just like entity on steps, if minetest changes it, mods have to update as well 18:31 MTDiscord *entity on steps with move result 18:32 Wuzzy that's true but your output might differ from minetest's builtin output then, esp if minetest will add more info in status text in future 18:32 Wuzzy so I don't consider "overwrite everything" to be a *true* solution to all problems 18:32 Wuzzy i mean this problem specifically 18:32 Krock so if the status message and join/leave things can be done in mods, what else is left over? 18:33 Wuzzy not sending player from clients i guess 18:33 MTDiscord krock: not sending the player/entity to the client 18:34 MTDiscord in which case: https://github.com/minetest/minetest/issues/8045 https://github.com/minetest/minetest/pull/8397 are relevant 18:34 Krock yes, and if it's marked for removal, attachments will appear detached for other players 18:35 Wuzzy Are attachments client-dependent in any way? 18:35 Wuzzy If yes, i'm afraid this whole feature idea might be dead on arrival :-/ 18:35 Wuzzy or needs a complete new approach 18:36 Krock it won't be an issue if they're set to invisible too, so I guess it's not much of an issue if that's implemented 18:36 Wuzzy ok but *do* clients have to know about attachments at all? 18:37 Krock I cannot imagine a case where that would be necessary 18:37 Wuzzy ah, good 18:37 Wuzzy well, i meant more like, right now 18:37 Krock but the 3rd person view of the parent (player) must see them 18:38 Wuzzy i wondered if attachments are entirely server-side 18:38 rubenwardy they're entirely client-side because of bone positions 18:39 rubenwardy which is a bit broken imo 18:39 Wuzzy O_O 18:39 Krock fixing attachments was a joy ride /s 18:39 rubenwardy well, or maybe it assumes the bone position is null. In any case, they're not fully resolved until the client 18:40 Wuzzy so this means if you attach an object to a player and set this player "hidden" this will probably lead to hilarious breakage on other clients? 18:40 Krock the server uses the parent's position for calculations because it does not have the model information 18:40 rubenwardy yeah, you'd need to hide the child object too 18:40 Wuzzy can someone test this theory (still can't compile :( ) 18:40 MTDiscord reminder that first person attachments were kind of designed to hint at the inclusion of per client visible entities only 18:41 Krock I don't see a feature overlap of attachments and per-player visibility 18:41 Krock they're separate features 18:41 rubenwardy it's not just visibility, it's not sending the players to other clients 18:41 rubenwardy visibility is misleading 18:41 rubenwardy like, there's already an object visibility feature - is_visibility 18:42 rubenwardy this feature stops the player being sent to other clients 18:42 MTDiscord the main purpose of this probably is to allow observing cheaters without them knowing of your presence 18:42 Wuzzy ok the code definitely needs cleanup and rename every word like "visibility" with something else because this is very confusing right now. Everyone will think of "is_visible" 18:42 MTDiscord cheatibility 18:42 MTDiscord the other purpose is collisions 18:42 MTDiscord anyways, this PR is suspiciously simple 18:43 Krock it looks somewhat hacky 18:43 MTDiscord there's an even easier manner 18:43 MTDiscord ^ 18:43 rubenwardy Wuzzy: already commented that 18:43 MTDiscord just set the invisible player's vertex data to pure alpha 18:43 MTDiscord what 18:43 MTDiscord there are a million ways to hide a player 18:43 MTDiscord and a million ways for cheat clients to reveal invisible entities 18:43 MTDiscord obviously 18:44 MTDiscord although you could spam fake invisible entities so cheat clients couldn't distinguish them from the real ones :3 18:44 Wuzzy not if the player isnt sent to clients at all. then you would have to directly hack into the server or something 18:44 Desour if you attach something to an invisible player, it's like you'd spill dye over them. it makes them visible. invisible players with attachments that are visible is impossible by design 18:45 Wuzzy how about if a player is marked as hidden, the entire "attachment tree" is automatically considered hidden by impliation, too? 18:45 Wuzzy something strange about this PR, its only limited to players, and not generalized to objects. :/ 18:46 MTDiscord Anyways, I have a bad feeling that this PR in its current state might cause breakage because it introduces another semi-consistent state: You now have an entity that exists on some clients but not on others. Apart from attached entities: What about attached particlespawners and attached sounds? A bunch of error messages? 18:46 Wuzzy and i kinda agree, the join/leave and status msg thing *might* be already too over-the-top. 18:47 Wuzzy yeah i kinda agree the PR from the concept (NOT TESTEED!!!!!!) doesnt seem the greatest. as a modder, i am also not very excited about it 18:48 Wuzzy darn, i really wish Lejo1 were here. 18:48 MTDiscord I think the proper solution is to implement #8045 by having a set {[playername] = true} as part of object properties for each entity - why is this constrained to players in its current form? Such a change would probably be nontrivial to make properly, because you'd have to consider how to gracefully handle all the attached stuff. Ideally you'd figure out how to only send this to players who also got the entity. 18:48 ShadowBot https://github.com/minetest/minetest/issues/8045 -- Allow Changing Entity Visibility On A Per-Player Basis 18:49 MTDiscord and yes, the "fake join/leave message" should definitely be left up to mods 18:49 Krock yes sure you could make it overly fucking complicated 18:50 Wuzzy Question: What is the *actual* use case for this, anyway? Why is is_visible=false not enough? Sneaking to cheating players seems like a little contrived. Zughy, comments? 18:50 Wuzzy not that i am completely opposed to the idea, just confused 18:53 Wuzzy When we're done with this "hidden players" PR, may I shamelessly plug #11465? :-) its already in 5.7.0 milestone and hope to see it in 5.7.0 18:53 ShadowBot https://github.com/minetest/minetest/issues/11465 -- New physics overrides by Wuzzy2 18:57 Krock so the use-cases are rather limited to puzzles? 18:57 Krock or minigames 18:58 Wuzzy about hidden players? i dont know, i dont feel strongly about the pr and i think this is one of the "back to the drawing board" situations, i mostly agree with the concerns of others 18:58 Krock I don't see too much demand for it due to the existing "speed" override. it might not be perfect but works well enough mostly 18:58 Krock (I meant your PR) 18:59 Wuzzy its bascially more fine-grained control of the player physics, especially in liquids and the use cases for that is definitly not limited to puzzle games 19:00 Wuzzy basically allowing to swim/sneak/climb faster or slower as a powerup/potion/punishment etc 19:01 Wuzzy Would also definitely be very useful for the MineClones to re-implement effects like Dolphin Grace (Swim faster) or Swift Sneak (sneak faster) 19:02 Wuzzy ok. do you agree with the PR at least *conceptuall* or is this dead-on-arrival for you? 19:05 Krock I'm not sure. On one hand it's too fine-grained, on the other hand it's more reliable than surrounding node checks by mods 19:06 Krock there's also at least two rebase errors that snuck in: https://github.com/minetest/minetest/pull/11465/files#diff-60afc4b1ee298e01efae55db3b202d0bdbffd3919d7f0bc3212a4d300522eacaR617 19:06 Krock should be * and not *= 19:07 Wuzzy oh yes the rebase... i wanted to talk about that 19:07 MTDiscord as for the collision part of the player hiding PR, that shouldn't be tied to that but rather the "physical" object property 19:07 MTDiscord see #10139 19:07 ShadowBot https://github.com/minetest/minetest/issues/10139 -- Allow physical = false for players 19:08 Wuzzy a new rebase is needed for the player physics pr and i am currently stuck 19:08 Wuzzy thanks for telling me about the *=, noted 19:08 Krock the best approach is usually to squash all commits before rebase 19:09 Krock that way you'll only need to fix conflicts once 19:11 Wuzzy I struggle to resolve this rebase conflict in the player physcis PR: https://hastebin.com/raw/xarijocofu 19:11 Zughy[m] It's been an hour on the same point, so what's the verdict? 19:11 Wuzzy oh yeah ok lets decide that first, sorry 19:12 Wuzzy my personal non-coredev opinion: It looks like a case for "back to the drawing board" because it touches too many things, i mostly agree with others on the concerns 19:12 Zughy[m] My take: conceptually, it's a great tool for server admins to check on cheaters. I can't judge the code, I'm only speaking as a server admin 19:13 sfan5 Wuzzy: the relevant code moved 19:13 Zughy[m] Oh lol, Ruben has already closed it 19:14 Wuzzy xD 19:14 Wuzzy well thats ONE way to resolve it 19:14 Krock Zughy[m]: it seems to be useful indeed but the implementation is flawed regardless. I left a comment there. 19:14 rubenwardy oh I thought we'd moved on to physics overrides given Krock's comment 19:16 Krock I thought so too 19:16 Zughy[m] Physics override were not in the list 👀 19:16 Krock doesn't matter 19:16 Zughy[m] *s *on 19:17 Krock dev meetings exist to discuss concepts so it's okay to throw them in (as long it does not get too much) 19:17 Wuzzy thank u 19:17 Krock is there anything more to discuss about these two PRs? 19:18 Wuzzy yes, about the 2nd one 19:19 Wuzzy so I am stuck at the rebase (not the *= thing). this diff: https://hastebin.com/raw/xarijocofu has something which confuses me which is the HACK 19:19 Wuzzy why is it there and what should i do with it? 19:19 Krock keep the upper part and add your multiplicator 19:19 Krock since you're using normalized values (from factor 1) in a multiplication, you don't even need to care about that 19:20 Krock since it scales proportionally anyway 19:20 Wuzzy is the HACK from the recent jump acceleration thingie? 19:21 Krock yes. you should be able to run a git blame on that line and I'll point to the acceleration commit 19:21 Wuzzy yea 19:21 MTDiscord the comment? yes. the hack? no. 19:21 Wuzzy huh? 19:21 MTDiscord the hack was from nerzhul if I'm not mistaken :D 19:21 Krock well anyway 19:22 Krock is it okay if we move on to the next topic? 19:22 Wuzzy its ok, i can work fixing the pr later 19:22 Wuzzy thanks 19:22 Krock > #9776 19:22 ShadowBot https://github.com/minetest/minetest/issues/9776 -- Show relative screenshot filename on chat when applicable by juozaspo 19:23 Krock concept / review 19:23 Krock I don't see much need for it 19:24 Krock people run their Minetest binary from anywhere and might not even keep track of the link target 19:24 Wuzzy as an user, i don't have strong feelings about it. its nicer if the printed path is a bit shorter but really no big deal 19:24 Krock the full path does not really hurt. it's more helpful to me 19:24 Wuzzy yeah, kinda agree 19:25 MTDiscord Controversial QoL thing? 19:25 MTDiscord I mean you could go "let's add a setting" but meh 19:25 Krock also std::filesystem should be available now 19:25 MTDiscord probably tag it as low priority? 19:26 MTDiscord I mean it is kinda inconvenient to have full paths in your screenshots or screencasts 19:26 Desour as a user, I don't like to see a long absolute path printed to chat every time, especially if it's not canonicalized 19:27 MTDiscord printing paths to chat at all is probably bad UX 19:28 MTDiscord not like I will memorize the path to then look it up in my filesystem - I'll just sort my screenshots folder alphabetically / by last modification 19:28 Desour screenshot filename is good to have imo, but the full path is not necessary if you've set it manually 19:28 MTDiscord if you take a screenshot of the entire screen, you don't get a notification with the filename either (well on Android you actually do IIRC?) 19:29 Desour how about a "open screenshot dir" button in mainmenu? 19:29 MTDiscord good idea 19:29 MTDiscord + any other visual feedback - e.g. screen flashing white 19:29 MTDiscord then we can remove printing stuff to chat entirely IMO 19:29 MTDiscord also allows taking a series of screenshots without cluttering up chat 19:29 MTDiscord esp. valuable if you want to take screenshots of chat ig 19:30 Krock there's already a button to open the user path 19:30 Krock screenshots within them 19:30 Krock see About tab in the Main Menu 19:30 Desour but screenshot dir != user path i.G. 19:31 rubenwardy there's the screenshot_path setting 19:31 Krock usually it is, unless you specified a custom location 19:31 rubenwardy defaults to `screenshot` 19:31 rubenwardy which is relative to CWD I gues? 19:31 Krock relative to the user path 19:31 Krock so either bin/.. or ~/.minetest 19:31 Wuzzy ok in that case an extra button might be overkill 19:32 Wuzzy but no strong opinion 19:32 rubenwardy "Saved screenshots/foofoofoobar.png in user data directory" 19:32 rubenwardy eh, problem there is when the path is absolute or ../ to leave 19:33 Krock what if it's outside the user data dir? overengineering.. 19:33 rubenwardy or just absolute path 19:36 Desour by default it says the absolute path of minetest/bin, then /../screenshots/ 19:36 Desour (with non-system-wide build) 19:36 Desour the "/../" is ugly 19:36 Wuzzy i agree with "overengineering" :D 19:37 rubenwardy ok, so the conclusion is to just print the absolute path 19:38 Wuzzy as an user, i have no problem with that decision 19:43 Krock meeting done? 19:45 Wuzzy what about the "one approval" PRs? 19:49 Krock long, ongoing process 19:49 Krock considering they've already got an approval it can be assumed that a merge is still in reach 20:23 Zughy[m] The screen flashing white when taking a screenshot is a nice idea 20:24 Wuzzy :) 20:24 Wuzzy FYI: #11465 is usable again now. 20:24 ShadowBot https://github.com/minetest/minetest/issues/11465 -- New physics overrides by Wuzzy2 20:25 Desour the other players need to see the camera flash too. place a light source at the players head for a frame 20:27 Zughy[m] If I'm against something that is not dev related, do I have the authority to reject it (possible close) or it's something just for core devs? I'm talking about #12648 20:27 ShadowBot https://github.com/minetest/minetest/issues/12648 -- Make relative number support for chat commands visible in syntax help 20:34 sfan5 what "not dev related" is there to it? 21:22 Zughy[m] It's UX, not code 21:26 Desour how's that not part of dev? 21:31 Desour if you don't like something, write a message at the issue. AFAIK, the triager role doesn't permit you to decide UX related stuff as you wish 21:35 Wuzzy Zughy[m], why do you want to close this? 21:36 Zughy[m] I agree with the first comment 21:36 Zughy[m] "how's that not part of dev?" <- Have you seen the mainmenu? I did 21:37 Zughy[m] *I have, whatever 21:40 Desour Zughy[m]: the mock thing? yes. how's this relevant here? 22:40 Zughy[m] No, the current main menu 22:44 Desour ? of course I have seen minetest's mainmenu