| Time |
Nick |
Message |
| 05:00 |
|
MTDiscord joined #luanti-dev |
| 09:22 |
|
Warr1024 joined #luanti-dev |
| 09:47 |
|
Warr1024 joined #luanti-dev |
| 09:57 |
|
whylay joined #luanti-dev |
| 10:57 |
|
mrcheese_ joined #luanti-dev |
| 12:50 |
MTDiscord |
<bla8722> not sure if relevant for alot of people but OpenAL updated its codebase to C++20 since version 1.25.0 which broke VS 2019 + vcpkg compiling because VS 2019 doesn´t fully support C++20 module scanning. possible fixes are either updating to VS 2022 or using OpenAL 1.24.3 |
| 13:08 |
|
turtleman joined #luanti-dev |
| 14:07 |
[MatrxMT] |
<Zughy> is it normal that node formspecs don't send any `on_player_receive_fields` input? |
| 14:14 |
rubenwardy |
it'll call the node def callback, not the global callback |
| 14:19 |
[MatrxMT] |
<Zughy> I don't think it's stated anywhere in the docs |
| 14:24 |
rubenwardy |
you're right |
| 14:24 |
rubenwardy |
also I think node formspecs are quite lame |
| 14:26 |
[MatrxMT] |
<Zughy> I'm working on a trivial docs PR. Also, I agree |
| 14:39 |
[MatrxMT] |
<Zughy> #16881 |
| 14:39 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16881 -- Docs: specify `on_player_receive_fields` doesn't work for node formspecs by Zughy |
| 14:42 |
[MatrxMT] |
<Zughy> so there is no way to know what a player is doing inside a node formspec, unless I'm checking from within the node? |
| 14:46 |
rubenwardy |
ContentDB translation description bug fixed |
| 14:46 |
rubenwardy |
also the description in MTG's game.conf does not match that on CDB |
| 14:47 |
rubenwardy |
should be edited to be much shorter so it can actually display in the LT client |
| 14:47 |
rubenwardy |
see also: https://content.luanti.org/packages/Luanti/minetest_game/translation/ |
| 14:53 |
sfan5 |
thx. I edited the short description now |
| 14:53 |
sfan5 |
wait that was a stupid idea, it's now cut off |
| 15:49 |
MTDiscord |
<sfence> Do we have some nice way how to detect in Lua server protocol version? |
| 15:51 |
MTDiscord |
<wsor4035> core.get_version() |
| 15:53 |
MTDiscord |
<sfence> thanks |
| 15:57 |
MTDiscord |
<luatic> you normally should prefer to use feature flags, what are you working on? |
| 16:00 |
MTDiscord |
<sfence> just wants to send notification to clients which are using old client, that they can expect crazy thinks happening. |
| 16:02 |
MTDiscord |
<wsor4035> more generous that most mods. either kick/block or do nothing |
| 16:03 |
MTDiscord |
<sfence> You are right, but in reality, it looks like Multicrafts users like to play on Luanti servers from iOS. |
| 16:03 |
MTDiscord |
<sfence> It does not looks like admin wants to simple block them. |
| 16:04 |
MTDiscord |
<wsor4035> i think we already starting to see server admins start to not care about multicraft users because they are so (5.4) outdated |
| 16:07 |
MTDiscord |
<sfence> I just was asked if it is posible to block all old clients with exception for Multicrafts users. |
| 16:07 |
MTDiscord |
<wsor4035> it is, but its rather stupid to do so |
| 16:08 |
MTDiscord |
<sfence> I agree. Just blocks all old clients or if not.. it does not matter if it is player on Multicraft or old Luanti client. |
| 16:12 |
MTDiscord |
<sfence> by the way, in 5.15.0 is included support for more then 32765 nodes? |
| 16:13 |
MTDiscord |
<wsor4035> yes |
| 16:13 |
MTDiscord |
<sfence> Did we also change proto_min in get_version able? because I assume, it is totaly incompatible with old clients. |
| 16:13 |
MTDiscord |
<luatic> sounds like you want core.get_player_information(player_name).protocol_version |
| 16:14 |
MTDiscord |
<sfence> Yea, I want to compare core.get_player_information(player_name).protocol_version and core.get_version(proto_max) |
| 16:14 |
MTDiscord |
<wsor4035> looking at the commit will tell you that (which you can get to from the end of the pr when merged) |
| 16:14 |
MTDiscord |
<wsor4035> https://cdn.discordapp.com/attachments/747163566800633906/1465017069106889019/image.png?ex=697792f7&is=69764177&hm=5a24ab1eb2ce78f7dd8e80267eaf97b1925e5c8c112288dbf2b793c3ce41ad5f& |
| 16:19 |
MTDiscord |
<sfence> well, it looks like old clients can be able to manage it. |
| 17:03 |
|
Desour joined #luanti-dev |
| 18:02 |
MTDiscord |
<sfence> Well. I did more testing. It looks like if you died, and in that situation, you get disconnected due to connection lost, or you cast end game without fulfilling the respawn formspec (like CTRL-C or cross in Windows corner) And if you after join a game that shows the joined players some formspec, it will overwrite the respawn formspec and get the player stuck in death situation. |
| 18:02 |
MTDiscord |
<sfence> So the question is... is it game bug or engine bug? |
| 18:04 |
sfan5 |
IMO games should ensure not to show a formspec to a dead player |
| 18:04 |
rubenwardy |
what if the send it just before the player dies? |
| 18:05 |
Krock |
have the death screen overwrite any formspec that is attempted to show |
| 18:05 |
Krock |
or mamilpate core.show_formspec to add such check |
| 18:05 |
Krock |
*manipulate |
| 18:05 |
sfan5 |
isn't the death screen server-side now? |
| 18:06 |
Krock |
it is. and if the quit field isn't received, the player is not respawned. |
| 18:06 |
MTDiscord |
<sfence> just after connection I see respawn formspec for a half of seconds. After it get replaced by game formspec showing rules or something like that. and if I exited that, no respawn formspec. No able to interact doe to death.... |
| 18:06 |
Krock |
builtin/game/death_screen.lua |
| 18:09 |
sfan5 |
i think we could at least detect if any non-death formspec was closed and then resend the death formspec? |
| 18:10 |
MTDiscord |
<sfence> So, should I open bug issue for this situation? |
| 18:10 |
user333_ |
that reminds me of a bug i encountered on the CTF server, where another formspec would close the death formspec, preventing you from respawing |
| 18:14 |
Krock |
"if any non-death formspec was closed" - this also includes core.close_formspec to cover perhaps all edge-cases. |
| 18:44 |
sfan5 |
thought on the discussion in #luanti: it would be good if we could publish rough, user-accessible stats on what luanti versions people are generally running |
| 18:44 |
sfan5 |
e.g. like https://apilevels.com/ |
| 18:45 |
MTDiscord |
<wsor4035> iirc ruben wanted to opt in stats or something |
| 18:45 |
MTDiscord |
<wsor4035> dunno if applicable to this |
| 18:45 |
user333_ |
would be cool to see the most popular versions/platforms |
| 18:47 |
user333_ |
which reminds me of this: [2025-11-06 20:14] <sfan5> PSA: for anyone interested here are new statistics on what versions/platforms/etc. everyone is running Luanti on from the server list POV -->> https://kitsunemimi.pw/tmp/serverlist_stats_2025-11-06.txt |
| 18:48 |
sfan5 |
i mean we have stats via CDB and the serverlist. would just have to make sure the data represents what we want it to |
| 18:49 |
sfan5 |
(e.g. in case of the server list stats: make sure those weird android apps don't distort it) |
| 18:56 |
user333_ |
"weird android apps" some player came on our server and claimed to be on "mine-build-craft", clearly there's a lot of those |
| 18:56 |
user333_ |
their version string was a 5.13.0-dev commit |
| 19:03 |
user333_ |
also note that 5.9.0-dev-943e0e9f9 is the web client |
| 19:05 |
user333_ |
here's some stats from a server my friend runs: https://termbin.com/jlw4 |
| 19:17 |
Krock |
I wonder whether something would break if I inserted a few newline characters or "`rm -f`" |
| 19:17 |
Krock |
(as the reported client version) |
| 19:21 |
user333_ |
hmmmmm |
| 19:21 |
user333_ |
try setting it to "1.20.4_Minecraft" and see what server owners do |
| 20:59 |
|
lhofhansl joined #luanti-dev |
| 21:03 |
lhofhansl |
I just installed a Luanti binary (msvc-x64) produced by a github action on my son's Windows machine. I noticed that maploading and other tasks are much (50% or more) slower on this build as with the official build? Is that expected? I looked at the Windows yaml file used to produce the build, and it seemed to be doing the right thing (a normal release build, etc). |
| 21:06 |
sfan5 |
🤷 |
| 21:09 |
lhofhansl |
So it isn't unexpected? |
| 21:24 |
[MatrxMT] |
<Zughy> It's probably a good time to think about whether we want to have a barebone implementation of v-rob's new UI API. Because author doesn't answer and I had to close the PR. #14263 |
| 21:24 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/14263 -- [NO SQUASH] Create new UI API (Formspec/HUD replacement) by v-rob |
| 21:26 |
sfan5 |
incremental changes are always better |
| 21:27 |
rubenwardy |
yeah. Even with a new API, you need to get the smallest change in first so it's in the codebase and can be worked on in smaller commits |
| 21:47 |
sfan5 |
~tell lhofhansl I don't think so. But I think nobody has looked at the optimization flags in detail. also there's the whole bunch of libraries from vcpkg which we have no insight into |
| 21:47 |
ShadowBot |
sfan5: OK. |
| 23:12 |
[MatrxMT] |
<Zughy> and is their current work a good starting point? |
| 23:25 |
MTDiscord |
<exe_virus> Maybe, they were in the weeds and may not of tidied up the core |
| 23:30 |
|
mrcheese joined #luanti-dev |
| 23:33 |
|
panwolfram joined #luanti-dev |
