Time Nick Message 09:54 [MatrxMT] Where should I look if I want to send a different variable type according to client's protocol version? I'm trying to implement #16603 and I have it working. I need to manage old clients though, as the text appears huge on their screen now 09:54 ShadowBot https://github.com/luanti-org/luanti/issues/16603 -- Allow more precise scaling of HUD texts 09:55 [MatrxMT] Current size is v2s32 and I have a v2f now 14:40 MTDiscord Zughy: Can you share your branch? I understand you are changing the type of size? 14:41 MTDiscord I suppose that could work, but it would require a protocol version check when writing HUD packets; if the client is older, cast size to v2s32 before sending. 14:42 MTDiscord However, I would wonder whether such an approach might create problems with other uses of size that expect it to be v2s32. 14:43 sfan5 it's easier to create or use a new hud property with the fitting type 14:44 MTDiscord yep i figure a f32 font_size property would make sense here. the other float properties don't really seem suitable for reuse. 14:45 MTDiscord (scale is already used for the bounding box...?) 15:10 [MatrxMT] Adding a new property was the second option, yes 15:11 [MatrxMT] luatic: yes, I wanted to know where I was supposed to do the cast (e.g. sendHudChange function) 15:13 [MatrxMT] I don't know, having a new property just for one type seemed unnecessary. Also, old clients should rely on size anyway, as they don't know the new property, right? 15:16 MTDiscord Yes, old clients will still only support size. But that's not really a problem: Modders can still specify size as a fallback, and since HUDs are per-player, they could even specify just size or font_size depending on the client protocol version. 15:35 [MatrxMT] mmm... as a modder, it'd annoy me to have to check the protocol every time I work with HUD elements. The type/hud_element_type is annoying enough already 15:35 [MatrxMT] *hud_element_type check 15:37 [MatrxMT] (...I mean, the whole HUD system is not the best in the world, but for that I can only wait for v-rob :P) 15:39 rubenwardy we need to get the GUI replacement in such a state that it can be merged into master, hidden behind a build flag, so we're not just waiting on v-rob 18:07 sfan5 any more comments on #16713? 18:07 ShadowBot https://github.com/luanti-org/luanti/issues/16713 -- Add self-extracting launcher for Windows by sfan5 18:07 MTDiscord as long as both are on the website im down 18:25 user333_ a bit unrelated, but why not distribute x86_64/arm64 appimages/builds for linux? 18:43 sfan5 flatpak and snap are effectively good enough 18:47 user333_ what about RUN_IN_PLACE=1 builds like windows has? 18:52 sfan5 portable builds are hard on linux 19:44 Krock you can attempt to make them compatible by targetting an older Debian/Fedora version. Despite semver, the dynamic libraries provided by the system are not always guaranteed to be ABI-compatible. 19:44 Krock So that's why Flatpak and Snap have their set of libraries - a common denominator on all systems. 19:46 user333_ can't you bundle the shared libraries with the executables like windows builds do with DLLs? 19:46 Krock you could attempt to get around that by statically linking all libraries. This 100 MB binary surely works well up to the point where someone uses musl instead of glibc 19:46 Krock what you're describing is mostly what AppImages do, yes. 20:00 user333_ making appimages shouldn't be too hard 20:00 user333_ why not distribute them to provide a wider variety of linux builds 20:02 user333_ (android has APKs and play store, windows has portable and soon installers, macos has builds and packages from package managers, and linux has flatpak/snap) 20:02 user333_ oh, and linux has package manager builds though those are often old 21:34 sfan5 merging #16729, #16702, #16687, #16713 in more than 10 min 21:34 ShadowBot https://github.com/luanti-org/luanti/issues/16729 -- `get_sky()`: return `fog_color` as well by Zughy 21:34 ShadowBot https://github.com/luanti-org/luanti/issues/16702 -- Backport PUC Lua 5.4's string.{pack,unpack,packsize} by appgurueu 21:34 ShadowBot https://github.com/luanti-org/luanti/issues/16687 -- shell.nix: replace SDL2 with SDL3 by y5nw 21:34 ShadowBot https://github.com/luanti-org/luanti/issues/16713 -- Add self-extracting launcher for Windows by sfan5 22:41 rubenwardy I assume you're waiting for it to be added to the website before doing #16129 ? 22:41 ShadowBot https://github.com/luanti-org/luanti/issues/16129 -- Primary Windows downloads should be a self-extracting executable 22:42 MTDiscord i would assume that issue can be closed now?