Time |
Nick |
Message |
01:43 |
|
Cornelia joined #minetest-dev |
01:49 |
|
twoelk left #minetest-dev |
04:05 |
|
Tmanyo joined #minetest-dev |
05:47 |
|
opal joined #minetest-dev |
07:59 |
|
YuGiOhJCJ joined #minetest-dev |
08:56 |
|
Fixer joined #minetest-dev |
09:00 |
|
YuGiOhJCJ joined #minetest-dev |
09:16 |
|
longerstaff13-m joined #minetest-dev |
09:40 |
|
AndroBuilder joined #minetest-dev |
09:49 |
|
Gael-de-Sailly joined #minetest-dev |
12:28 |
|
Darcidride joined #minetest-dev |
12:47 |
|
Anderssen joined #minetest-dev |
12:51 |
Anderssen |
Hi. I've noticed that the steel-mod by VanessaE is no longer on github. Can it still be found somewhere else? |
12:51 |
rubenwardy |
gitlab.com/VanessaE |
12:58 |
Anderssen |
thanks; steel doesn't appear to be there though. The steel-mod used to be under https://github.com/VanessaE/minetest-steel ; maybe it's equivalent to Zeg9's mod? https://github.com/Zeg9/minetest-steel |
13:14 |
|
Taoki joined #minetest-dev |
13:15 |
|
longerstaff13-m joined #minetest-dev |
13:26 |
|
diegojsrw joined #minetest-dev |
13:26 |
|
YuGiOhJCJ joined #minetest-dev |
14:06 |
|
YuGiOhJCJ joined #minetest-dev |
15:16 |
|
Fixer joined #minetest-dev |
15:38 |
|
Krock joined #minetest-dev |
15:41 |
Krock |
rebasing #6304 |
15:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/6304 -- Raycast: export exact pointing location by juhdanad |
15:44 |
Krock |
rubenwardy: how should that be written? "The point on the selection box in meters which is pointed at."? |
15:45 |
Krock |
"world space" sounds unclear and a confusing |
15:45 |
rubenwardy |
The position is a global position relative to world origin |
15:45 |
rubenwardy |
, not to the node |
15:47 |
Krock |
oh I see. Apparently I lost the testing code while developing the mod further. Will change it to "The absolute world coordinates of the point on the selection box which is pointed at." |
15:50 |
rubenwardy |
Cool |
15:52 |
Krock |
updated. |
15:54 |
Krock |
I know that https://github.com/minetest/minetest/pull/7568#discussion_r210634394 is risky when it's forgotten. in that case it at least freezes the entire server as soon a node is removed/set |
16:00 |
ANAND |
Sorry to interrupt, would someone be able to review #7557 and #7587, please? :) |
16:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/7557 -- Expose player FOV to Lua API by ClobberXD |
16:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/7587 -- Implement on_wielditem_change callback registration by ClobberXD |
16:02 |
Krock |
"Adding a client->server FOV sending will require another server->client "request" packet, which is why it was not implemented" it's currently just one direction |
16:04 |
Krock |
It's also not necessary to change the code style of unrelated code in the PR - but it's surely not wrong to do so as long not too much is changed |
16:04 |
|
ANAND_ joined #minetest-dev |
16:09 |
VanessaE |
well not that he's here to see it, and not that it's even on topic for this channel, but I put my steel mod fork up on gitlab. |
16:14 |
Krock |
okay :) |
16:35 |
|
paramat joined #minetest-dev |
16:36 |
paramat |
#7641 is ready |
16:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/7641 -- Mgv5: Change tunnel parameters to those of other mapgens by paramat |
16:43 |
ANAND |
Is it possible to access the Server object from the Player class? |
16:44 |
Krock |
no, it's not. |
16:44 |
Krock |
the Player class is used for the client and server. probably it does not even know to which env it belongs |
16:46 |
ANAND |
Thought so. That's why I added the Server::{s|g}etPlayerFov() methods |
16:46 |
Krock |
yes, but you can inherit from the class |
16:48 |
ANAND |
You mean RemotePlayer? |
16:49 |
Krock |
you could make f32 m_fov a protected member of Player to use it in LocalPlayer and RemotePlayer |
16:49 |
ANAND |
Oh right, I see what you mean |
16:50 |
Krock |
at least the variable would be centralized, even though there are no getters/setters for it without inherited classes |
16:50 |
ANAND |
That would be good |
16:51 |
ANAND |
Should I add virtual getter/setters to Player as well? |
16:51 |
Krock |
if you want so. However, I don't see much of an use for them right now |
16:51 |
ANAND |
True... |
16:51 |
Krock |
might be another topic for the server managed player movement |
16:53 |
Krock |
sfan5, rubenwardy: Would it be possible for one of you to set up the Releases JSON file (preferably with cronjob) on one of the Minetest domains? That would bring the update notification PR along |
16:55 |
Krock |
It's not a high priority request but I think the modders/troubleshooters will appreciate that feature after 5.0.0 because it saves some time explaining that the players should update |
16:57 |
Krock |
paramat: I'm not sure about the mgv5 change. Making tunnels thicker is surely an improvement - but then it will look exactly the same as the other mapgens |
16:57 |
ANAND |
Krock, inheriting m_fov from Player still doesn't eliminate the need for the Server::{s|g}etPlayerFov() methods |
16:58 |
Krock |
ANAND: why not? |
16:59 |
ANAND |
Even if RemotePlayer::setFov is directly called from l_object.cpp, how would it access the Server object? |
17:00 |
Krock |
it wouldn't. Look at l_set_hp. player->setHP(new value); and afterwards a call to the Server function to send the updated value |
17:02 |
ANAND |
Oh right... you probably meant that both player->setFov() and getServer()->SendPlayerFov should be called in l_object.cpp |
17:02 |
ANAND |
Sounds good |
17:05 |
ANAND |
Also reverting the var==NULL to !<var> replacement commit |
17:06 |
sfan5 |
Krock: sure, if you tell me how it should look |
17:07 |
sfan5 |
also, the client should send its protocol version when requesting this json file |
17:07 |
sfan5 |
it will come in handy at some point |
17:09 |
Krock |
sfan5: for now it only need the most recent release tag |
17:10 |
Krock |
the proto version could be added via the GET url if that's okay |
17:10 |
sfan5 |
sure |
17:10 |
sfan5 |
a POST does not make sense for retrieveing resources |
17:11 |
Krock |
indeed. also keeping it similar to the server list |
17:13 |
paramat |
the underground is already mostly identical to other mapgens, and it is an improvement. it's the surface terrain that makes it mgv5 |
17:15 |
paramat |
i find there's nothing about thin tunnels that is worth preserving. keeping something bad for the sake of variety is not worth it |
17:19 |
Krock |
I see.. |
17:24 |
Krock |
sfan5: I think the simplest way would be to download https://api.github.com/repos/minetest/minetest/releases/latest |
17:24 |
Krock |
could also be converted into a custom format, but I'm not sure if that's worth the effort |
17:26 |
sfan5 |
wasting 91.9k of file size sounds great |
17:26 |
Krock |
it's 6.9kB but ok... |
17:27 |
Krock |
meanwhile the server list is ~300kB |
17:31 |
sfan5 |
oh just /releases/latest not /releases |
17:33 |
sfan5 |
depending on what you intend to display to the client you could reduce that to 400 bytes |
17:34 |
Krock |
right now the tag name suffices but more information would make it possible to extend the updater somewhen |
17:38 |
|
windscale joined #minetest-dev |
17:58 |
Krock |
will merge #6304, #7568 and #7641 in 10 minutes |
17:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/6304 -- Raycast: export exact pointing location by juhdanad |
17:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/7568 -- Check node updates whether the blocks are known by SmallJoker |
17:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/7641 -- Mgv5: Change tunnel parameters to those of other mapgens by paramat |
18:09 |
nerzhul |
Krock 300kB uncompressed |
18:09 |
Krock |
merging... |
18:11 |
paramat |
oh nice thanks |
18:12 |
Krock |
done. |
18:14 |
|
Cornelia joined #minetest-dev |
18:15 |
paramat |
ok next i'll move ore generation to before decoration placement in all mapgens, issue #7609 |
18:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/7609 -- Consider generating ores before placing decorations (mapgen order issue) |
18:21 |
rubenwardy |
Use the GitHub API for it |
18:21 |
rubenwardy |
Jekyll |
18:40 |
|
MoNTE48 joined #minetest-dev |
19:18 |
|
MoNTE48 joined #minetest-dev |
19:21 |
|
Gael-de-Sailly joined #minetest-dev |
19:25 |
|
MultiCraft joined #minetest-dev |
19:33 |
paramat |
what about #7433 ? it fixes a blocker issue |
19:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/7433 -- Really delete things in fs::RecursiveDelete by numberZero |
19:35 |
sfan5 |
currently untested |
19:58 |
|
Fixer joined #minetest-dev |
20:05 |
paramat |
yeah. #7483 has 1 approval now |
20:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/7483 -- Move touchscreen input handling to base GUIModalMenu class by stujones11 |
20:17 |
|
diegojsrw joined #minetest-dev |
20:51 |
|
Darcidride joined #minetest-dev |
21:31 |
|
rubenwardy joined #minetest-dev |
21:39 |
|
paramat joined #minetest-dev |
22:43 |
|
paramat joined #minetest-dev |
23:08 |
|
paramat joined #minetest-dev |
23:11 |
|
Megaf joined #minetest-dev |