| Time |
Nick |
Message |
| 02:34 |
|
proller joined #minetest-dev |
| 02:57 |
|
hmmmm joined #minetest-dev |
| 03:01 |
|
hmmmm joined #minetest-dev |
| 03:16 |
|
ShadowBot joined #minetest-dev |
| 03:16 |
|
ShadowNinja joined #minetest-dev |
| 03:46 |
|
ensayia joined #minetest-dev |
| 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 |
|
MTDiscord joined #minetest-dev |
| 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. |
| 04:33 |
|
calcul0n joined #minetest-dev |
| 08:22 |
|
Warr10246 joined #minetest-dev |
| 09:04 |
|
Warr1024 joined #minetest-dev |
| 09:09 |
|
appguru joined #minetest-dev |
| 09:14 |
|
Fixer joined #minetest-dev |
| 10:11 |
|
jwmhjwmh joined #minetest-dev |
| 10:12 |
|
TurkeyMcMac joined #minetest-dev |
| 11:27 |
|
jwmhjwmh joined #minetest-dev |
| 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 |
| 12:32 |
|
jwmhjwmh joined #minetest-dev |
| 12:43 |
|
appguru joined #minetest-dev |
| 13:26 |
|
appguru joined #minetest-dev |
| 13:46 |
|
Wuzzy joined #minetest-dev |
| 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 |
|
loggingbot_ joined #minetest-dev |
| 14:14 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ https://irc.minetest.net/ https://github.com/minetest |
| 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 |
<luatic> Krock: Is this a C++-side or a Lua-side comparison |
| 15:44 |
Krock |
topic .. ? |
| 15:44 |
MTDiscord |
<luatic> "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 |
<luatic> 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 |
<luatic> 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 |
| 15:59 |
|
appguru joined #minetest-dev |
| 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:36 |
|
jwmhjwmh joined #minetest-dev |
| 16:45 |
MTDiscord |
<luatic> 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. |
| 16:57 |
|
jwmhjwmh joined #minetest-dev |
| 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 |
<Jonathon> 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 |
<Jonathon> 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 |
<Jonathon> 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 |
<Jonathon> mods such as cloaking, catcommands implement this already, except for the sending of the player to clients |
| 18:15 |
MTDiscord |
<Jonathon> > 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 |
<Jonathon> 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 |
<Jonathon> 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:20 |
|
Desour joined #minetest-dev |
| 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 |
<Jonathon> ^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 |
<Jonathon> 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 |
<Jonathon> its just a chatcommand |
| 18:24 |
Krock |
core.get_server_status |
| 18:24 |
Krock |
well yes I guess... |
| 18:24 |
MTDiscord |
<Jonathon> . //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 |
<Jonathon> 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 |
<Jonathon> 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 |
<Jonathon> and that already happened |
| 18:28 |
MTDiscord |
<Jonathon> 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 |
<Jonathon> you can build the whole string without needing to parse it |
| 18:31 |
MTDiscord |
<Jonathon> its just like entity on steps, if minetest changes it, mods have to update as well |
| 18:31 |
MTDiscord |
<Jonathon> *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 |
<Jonathon> krock: not sending the player/entity to the client |
| 18:34 |
MTDiscord |
<Jonathon> 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 |
<Jordach> 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 |
<luatic> 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 |
<luatic> cheatibility |
| 18:42 |
MTDiscord |
<Jonathon> the other purpose is collisions |
| 18:42 |
MTDiscord |
<luatic> anyways, this PR is suspiciously simple |
| 18:43 |
Krock |
it looks somewhat hacky |
| 18:43 |
MTDiscord |
<Jordach> there's an even easier manner |
| 18:43 |
MTDiscord |
<luatic> ^ |
| 18:43 |
rubenwardy |
Wuzzy: already commented that |
| 18:43 |
MTDiscord |
<Jordach> just set the invisible player's vertex data to pure alpha |
| 18:43 |
MTDiscord |
<luatic> what |
| 18:43 |
MTDiscord |
<luatic> there are a million ways to hide a player |
| 18:43 |
MTDiscord |
<luatic> and a million ways for cheat clients to reveal invisible entities |
| 18:43 |
MTDiscord |
<Jordach> obviously |
| 18:44 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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:10 |
|
kilbith joined #minetest-dev |
| 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 |
|
diceLibrarian joined #minetest-dev |
| 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 |
<luatic> the comment? yes. the hack? no. |
| 19:21 |
Wuzzy |
huh? |
| 19:21 |
MTDiscord |
<luatic> 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 |
<luatic> Controversial QoL thing? |
| 19:25 |
MTDiscord |
<luatic> 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 |
<luatic> probably tag it as low priority? |
| 19:26 |
MTDiscord |
<luatic> 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 |
<luatic> printing paths to chat at all is probably bad UX |
| 19:28 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> good idea |
| 19:29 |
MTDiscord |
<luatic> + any other visual feedback - e.g. screen flashing white |
| 19:29 |
MTDiscord |
<luatic> then we can remove printing stuff to chat entirely IMO |
| 19:29 |
MTDiscord |
<luatic> also allows taking a series of screenshots without cluttering up chat |
| 19:29 |
MTDiscord |
<luatic> 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/<filename> |
| 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:44 |
|
vampirefrog joined #minetest-dev |
| 19:45 |
Wuzzy |
what about the "one approval" PRs? |
| 19:48 |
|
jwmhjwmh joined #minetest-dev |
| 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 |
| 19:49 |
|
jwmhjwmh joined #minetest-dev |
| 20:14 |
|
jwmhjwmh joined #minetest-dev |
| 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:04 |
|
calcul0n_ joined #minetest-dev |
| 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] |
<Desour> "how's that not part of dev?" <- Have you seen the mainmenu? I did |
| 21:37 |
Zughy[m] |
*I have, whatever |
| 21:39 |
|
proller joined #minetest-dev |
| 21:40 |
Desour |
Zughy[m]: the mock thing? yes. how's this relevant here? |
| 22:00 |
|
jwmhjwmh joined #minetest-dev |
| 22:35 |
|
panwolfram joined #minetest-dev |
| 22:40 |
Zughy[m] |
No, the current main menu |
| 22:44 |
Desour |
? of course I have seen minetest's mainmenu |
| 23:06 |
|
AliasStillTaken joined #minetest-dev |
| 23:32 |
|
troller joined #minetest-dev |
