| Time |
Nick |
Message |
| 00:12 |
|
fluxflux_ joined #minetest-dev |
| 01:32 |
|
olliy joined #minetest-dev |
| 02:10 |
|
kilbith joined #minetest-dev |
| 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 |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 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:01 |
|
calcul0n__ joined #minetest-dev |
| 11:10 |
|
numzero joined #minetest-dev |
| 11:25 |
|
Fixer joined #minetest-dev |
| 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 joined #minetest-dev |
| 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:13 |
|
kilbith joined #minetest-dev |
| 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:38 |
|
kilbith joined #minetest-dev |
| 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 |
<srinivas> 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 |
<Jonathon> https://forum.minetest.net/viewtopic.php?t=20052 as well |
| 17:10 |
MTDiscord |
<Jonathon> also things like https://github.com/minetest/minetest/issues/9193 would make it so you didnt need so many nodes |
| 17:16 |
|
calcul0n joined #minetest-dev |
| 17:27 |
|
kilbith joined #minetest-dev |
| 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
|
calcul0n_ joined #minetest-dev |
| 18:23 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> https://gitlab.com/sztest/nodecore/-/commit/c85ad5d662bb82b502901c02a43ce8edb6d3a5fa ugly, but works for now. |
| 18:37 |
MTDiscord |
<Warr1024> 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. |
| 18:40 |
|
BuckarooBanzai joined #minetest-dev |
| 18:48 |
|
kilbith joined #minetest-dev |
| 19:19 |
|
homthack joined #minetest-dev |
| 19:57 |
kilbith |
https://github.com/minetest/minetest/issues/10925#issuecomment-774748434 |
| 19:57 |
kilbith |
counts as trivial |
| 21:00 |
|
calcul0n_ joined #minetest-dev |
| 21:01 |
|
Fixer joined #minetest-dev |
| 22:00 |
|
Taoki joined #minetest-dev |
| 23:25 |
kilbith |
https://paste.ubuntu.com/p/S3RPvGfGYP/ |
| 23:27 |
|
fluxflux_ joined #minetest-dev |
| 23:59 |
|
kilbith_ joined #minetest-dev |
