Time Nick Message 02:11 kilbith there is a bug with scroll_container[], it excludes animated_image[] 02:23 kilbith https://github.com/minetest/minetest/issues/10925 02:24 kilbith I've got a segfault on top of that 10:33 sfan5 merging #10636 and game#2822 in 10m 10:33 ShadowBot https://github.com/minetest/minetest_game/issues/2822 -- [NO SQUASH] Maintenance PR by sfan5 10:33 ShadowBot https://github.com/minetest/minetest/issues/10636 -- Improve touch event handling by numberZero 11:54 Krock adding SmoothTranslator to LuaEntitySAO. let's see if that works 11:58 sfan5 simple linear interpolation could also work 12:04 Krock but then why not do it correct? 12:04 sfan5 to save effort, dunno 12:05 sfan5 I'm not opposed to your approach just so that's clear 12:05 Krock m_base_position in the generic SAO class must be touched anyway so it's really not much of a difference 12:31 Krock what does move_to() do with physical objects? nothing? 13:11 Krock now moveTo() does not do anything. at least that's some progress :/ 13:58 unixbsd hello 13:58 unixbsd how to use the gamepads with 2 playeers for minetest on linux/devuan? is gamepad working /dev/input...? 14:00 Krock there's "joystick_id" that you need to specify. however, I think only Irrlicht API is used for that 14:01 Krock so you need either two minetest.conf files or change it between a game launch. however, I don't know how well that would work 14:02 Krock there's also yet no option to have Minetest listening to two controllers, if you meant tha 14:02 Krock t 14:27 rubenwardy unixbsd: the gamepad supports sucks a bit. You can use joystick_id to say which to use - this will work for 2 players to play with different MT instances - but tbe actual binding is a bit eh 14:28 rubenwardy also, user questions should be in #minetest 14:31 unixbsd :( 14:32 unixbsd sdl and joystick is normally easy to program and reliable 14:35 Krock except that Minetest currently does not use SDL 14:36 numzero but it will be, probably 14:36 Krock I hope so too 14:38 numzero hope? you’re core dev, you decide will it or won’t it 14:43 rubenwardy it seems fairly likely, it has unanimous support 14:48 Krock numzero: yes I am, but I'm not familiar with SDL2 14:49 celeron55 deciding something doesn't mean it will happen, somebody's got to actually do it 14:50 numzero celeron55: yet without deciding, doing stuff like that is futile, it won’t be merged 14:51 sfan5 numzero has invested some work into getting it to work and it already does(?) 14:51 numzero but as I see, many core devs actually decided using SDL is good 14:51 sfan5 there "just" needs to be some kind of plan what to do with our forked irrlicht 14:51 sfan5 (we'll need it anyway) 14:51 numzero one more decision remains 14:52 numzero should other (non-SDL) Irrlicht versions be supported on any platform? 14:52 sfan5 I don't think we should chain ourselves to SDL (in a way that isn't abstracted) 14:53 sfan5 however there's no platform where we couldn't use SDL 14:54 numzero that’s a related but different question 14:55 sfan5 it's no then 14:58 numzero so, single Irrlicht version for all Minetest builds. That makes things much simpler. 14:59 numzero on the Minetest side, it allows removing all the #if TOUCHSCREEN #if IRRLICHT_VERSION and even #if GLES 15:00 rubenwardy you'd still need to add abstractions to enable/disable touchscreen at runtime 15:01 numzero on the Irrlicht side, it allows changing APIs to suit Minetest as the latter won’t have to support “standard” API 15:01 numzero rubenwardy: runtime things are another matter 15:01 sfan5 enable_touchscreengui already exists doesn't it? 15:02 numzero there was a PR adding something like that IIRC 15:03 sfan5 #10729 15:03 ShadowBot https://github.com/minetest/minetest/issues/10729 -- Allow Enabling The Touch UI In A Desktop Build by TheBrokenRail 15:03 sfan5 ...adds another compile time option so not suitable 15:05 sfan5 wait nvm 15:05 sfan5 that one just swapped out `#ifdef __ANDROID__` for `#ifdef HAVE_TOUCHSCREENGUI` 15:07 numzero the option is called `touchtarget` IIUC 15:07 numzero and is not present in settingtypes 15:08 numzero but *is* present in `defaultsettings.cpp` 15:13 rubenwardy re: #10892 15:13 ShadowBot https://github.com/minetest/minetest/issues/10892 -- Use consistent temp folder path by rubenwardy 15:14 rubenwardy I feel like it's bad practice to merge a bug fix when you can't reproduce the bug 15:15 sfan5 that's called "maintenance" 15:15 sfan5 or "code quality" 15:15 rubenwardy yeah I guess 15:16 rubenwardy plus it removes more code than it adds 15:17 rubenwardy I'll merge that in 10 then 15:36 rubenwardy trivial fix: https://github.com/rubenwardy/minetest/commit/98a5929f79eb28a6c63a13c8033c62f460793cc3 15:36 rubenwardy tested 15:36 rubenwardy also, those variable names are terrible 15:37 rubenwardy oword1 should be source, and oword2 should be translated (?) 15:38 sfan5 since release is unlikely to happen in the next few days how about putting out another release candidate? 15:38 rubenwardy yeah sure, should we put the date for next weekend at the earliest? 15:39 rubenwardy also, what's your thoughts on physics modifiers? You added it to the milestone just before freeze 15:39 sfan5 I added it specifically because it'd (IMO) make sense to make an exception for it 15:39 rubenwardy sure. And it's not really an exception if we still have a week(ish) after merging it 15:39 rubenwardy we could say we left feature freeze and reentered ;) 15:46 nerzhul honestly there is no consensus on SDL, just some wants us to test it 15:50 rubenwardy merging trivial bug fix in 10: https://github.com/rubenwardy/minetest/commit/98a5929f79eb28a6c63a13c8033c62f460793cc3 15:51 numzero nerzhul: I’m not an SDL fan actually but it may help Minetest a lot 15:53 numzero we need to fork Irrlicht (there is a fork actually but only for some platforms) but maintaining a multiplatform framework is hard. SDL takes that heavylifting providing us a uniform interface 15:54 numzero there are sharp corners ofc (like Android build system) but these are inevitable 17:03 MTDiscord Is it possible to increase the limit for registered nodes? 17:09 rubenwardy issue: #6101 17:09 ShadowBot https://github.com/minetest/minetest/issues/6101 -- Allow registering more than 32768 nodes 17:10 MTDiscord https://forum.minetest.net/viewtopic.php?t=20052 as well 17:10 MTDiscord also things like https://github.com/minetest/minetest/issues/9193 would make it so you didnt need so many nodes 17:36 rubenwardy when was `alpha` removed from node definitions? 17:37 rubenwardy documentation, that is 17:38 rubenwardy 0.4.16 is the first release without it 17:44 rubenwardy it was 17:44 rubenwardy !title http://github.com/minetest/minetest/commit/d04d8aba7029a2501854a2838fd282b81358a54e 17:44 ShadowBot rubenwardy: Add hardware node coloring. Includes: · minetest/minetest@d04d8ab · GitHub 17:45 numzero heh, `git log -p doc/lua_api.txt` with search for `alpha *=` (regex) leads to the same 17:45 rubenwardy that's what I did 17:46 rubenwardy well, after looking through versions 17:56 sfan5 huh interesting I thought it was just never documented 18:00 rubenwardy There was never an alpha deprecation message, so it's argubably about whether support should be removed for it completely now 18:01 rubenwardy do liquids use texture clip or blend in 5.3.0? Looks like blend, which is good 18:01 sfan5 liquids default to opaque 18:01 rubenwardy your chart says blend(val) though 18:01 rubenwardy doesn't that break transparent liquids if you also remove `alpha`? 18:02 sfan5 ...but if alpha is set and not 255 it gets set to blend 18:02 rubenwardy if alpha isn't set and there's a transparent image then is it opaque? 18:03 sfan5 yes 18:03 rubenwardy doesn't this mean that 5.3.0 connecting to any 5.4.0 server sees opaque water? 18:03 rubenwardy I'm assuming alpha was removed completely from the reportts 18:04 rubenwardy I shouldn't assume 18:04 sfan5 for legacy clients the engine choose the next best alternative 18:04 sfan5 the `alpha` in the noddef changes meaning but the serialization is backwards compatible 18:06 sfan5 ( https://github.com/minetest/minetest/pull/10819/files#diff-1a57c4608538ac1f37a6e032831761b99629522cea1d851ab0e0e455c21c83b8R408-R432 ) 18:11 rubenwardy this feels rather tedious and weird 18:12 MTDiscord So I'd have to have one set of fields set for 5.3-, one set for 5.4+, and a crossover set if I want to support both, which will cause me to get a bunch of unavoidable deprecation warnings? 18:14 sfan5 there's a minetest.features detection for this 18:15 MTDiscord So that means I have to sprinkle around a whole bunch of feature checks everywhere to determine how to define nodes based on version, and then rip them out again later when I EOS the old version? That seems like a lot of work compared to what this could have been... 18:16 sfan5 what is your suggestion then? 18:16 MTDiscord Seems like it would be a lot easier for me to just monkey-patch register_node at that point 18:17 rubenwardy if you keep support for `alpha`, you wouldn't need to change this at all 18:17 sfan5 with "this" being ? 18:17 rubenwardy the water definitions with custom transparency 18:18 MTDiscord yeah, I mean, one of the things I've been considering is to detect alpha in the node def, walk all the tile def objects (which can be rather complex) and sprinkle in the ^[opacity: that I now would have to do manually, and remove the alpha field before calling the upstream API method... 18:19 sfan5 how does that solve the issue with needing a whole bunch of feature checks for use_texture_alpha? 18:21 MTDiscord Do I actually need feature checks for it? I'm running a 5.3 server with the new 5.4+ use_texture_alpha values, and it seems like 5.3 is ignoring them safely. 18:21 rubenwardy 5.3 will treat strings as false 18:21 rubenwardy oops, *true 18:22 sfan5 really? 18:22 rubenwardy yes, strings are truthy 18:22 sfan5 I know but you never know how strict the type checks are 18:22 rubenwardy if it's stricter then it's broken 18:22 MTDiscord Okay, that's not ideal, but I can probably live with that for the transition. It will cause a regression in a few nodes that require clip but get blend since truthy in 5.3 seems to mean blend, but if it's just transitional I can suvive that 18:22 rubenwardy Lua's and/or returns one of the operands 18:23 MTDiscord It just sounds like I'll have to figure out a way to deal with water opacity in 5.3 though because that's a game-breaker. 18:23 rubenwardy so if you required it to be true or false, you'd have to do (var and var2) and true or false 18:23 MTDiscord or not not (var or var2), lovely javascriptism :-) 18:23 sfan5 you can do the ^[opacity: thing to the textures, set use_texture_alpha to something truth-y and it will work for both 5.3 and 5.4 18:23 rubenwardy lua_toboolean will take anything other than nil and false as true 18:24 sfan5 (that is for any combination for {client 5.3, client 5.4} * {server 5.3, server 5.4}) 18:24 MTDiscord I've got a 5.3 server that's running the 5.4 version of the code (use_texture_alpha truthy, opacity texturemod, no alpha field) and it looks wrong when I connect a 5.4 client to it... 18:25 sfan5 that'd be a bug 18:27 MTDiscord NodeCore Community server is running I think 5.3.0-release (or a version shortly after), and nodecore https://gitlab.com/sztest/nodecore/-/commit/dabf8ac697a10c337195b59ff140a17575e946f5, and when I connect client 5.4.0-dev-857dbcd57 to it, water is opaque 18:28 MTDiscord works fine in SP, so the node def I'm pretty sure is right. 18:29 sfan5 2021-02-07 19:29:14: ERROR[Main]: Invalid field use_texture_alpha (expected boolean got string). 18:29 sfan5 this cannot possibly work without feature checks 18:30 MTDiscord Well shit, looks like I'm monkey-patching the API after all 18:30 sfan5 that's not a bad solution at all if you know you require this for an entire game 18:31 MTDiscord Well, I require it for all games, but I'm only responsible for the one. 18:33 sfan5 I've sometimes wondered if Minetest should provide an explicitly versioned api (no cross-version compat) and mods would then use polyfills to get support with newer versions 18:33 sfan5 but that sounds like it'd be a mess 18:36 MTDiscord https://gitlab.com/sztest/nodecore/-/commit/c85ad5d662bb82b502901c02a43ce8edb6d3a5fa ugly, but works for now. 18:37 MTDiscord I don't mind maintaining a little compat code, but I always try to target the newest API, and make it so that I only have to delete a hack when I EOS an old version. 19:57 kilbith https://github.com/minetest/minetest/issues/10925#issuecomment-774748434 19:57 kilbith counts as trivial 23:25 kilbith https://paste.ubuntu.com/p/S3RPvGfGYP/