Minetest logo

IRC log for #minetest-dev, 2020-03-02

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:43 NoctisLa1 joined #minetest-dev
00:51 calcul0n joined #minetest-dev
01:22 AntumDeluge joined #minetest-dev
02:25 Lone_Wolf joined #minetest-dev
03:12 fluxflux joined #minetest-dev
03:16 Foz joined #minetest-dev
04:02 Taoki joined #minetest-dev
05:46 nepugia joined #minetest-dev
07:41 ssieb joined #minetest-dev
08:30 Beton joined #minetest-dev
08:37 ShadowNinja joined #minetest-dev
09:21 erlehmann joined #minetest-dev
09:33 YuGiOhJCJ joined #minetest-dev
10:35 df458 joined #minetest-dev
10:52 df458 joined #minetest-dev
11:07 absurb joined #minetest-dev
11:08 proller joined #minetest-dev
11:30 Wuzzy joined #minetest-dev
11:53 Fixer joined #minetest-dev
11:55 proller joined #minetest-dev
12:02 kilbith joined #minetest-dev
12:03 Wuzzy Can someone help us out on #9339, please?
12:03 ShadowBot https://github.com/minetest/minetest/issues/9339 -- Fix pathfinder bugs: returning nil frequently, broken A*, jump through solid nodes by Wuzzy2
12:03 Wuzzy It's about the pathfinder fixes...
12:04 Wuzzy sfan5 wants to add a new field to minetest.features ("pathfinder_works_correctly"), but I'm not sure if I should. Asking for a 2nd core dev opinion
12:05 p_gimeno oh my... bad name
12:05 Wuzzy <sfan5> this is only possible if it can reliably detect if the pathfinder has been fixed yet.
12:06 Wuzzy sfan5: I have to admit, that's a quite strong argument. But I still feel uneasy about forcing modders to basically do an if statement before every minetest.find_path. It's not good if code blows up 🙁
12:06 p_gimeno reminds me of the LSL function llXorBase64Strings in second life, which was broken and they released a new function llXorBase64StringsCorrect, but it had bugs too and they ended up releasing llXorBase64, which had bugs but were caught early on and fixed
12:06 sfan5 nobody needs to do an if statement
12:07 sfan5 mods which don't "care" about the result or don't have an alternative to the pathfinder can just call find_path as usual
12:07 Wuzzy true dat
12:08 Wuzzy i think there needs to be a rule at which point a field like "<feature>_works_correctly" is justified
12:08 sfan5 fyi the "add a feature to signal that something works" has been done before https://github.com/minetest/minetest/blob/master/builtin/game/features.lua#L6 (and on line 15)
12:08 p_gimeno well, currently the pathfinder "works"
12:08 Wuzzy clearly it's a bad idea to extend minetest.features for every bugfix. there needs to be a limit
12:10 Wuzzy anyway, I guess I just wait for a 2nd core dev opinion for now
12:10 sfan5 well firstly, the bugfix needs to be relevant to the script api and there must be a reasonable alternative action modders could take if they could detect that <feature> is broken
12:10 sfan5 I think that excludes most
12:10 Wuzzy granted, minetest.find_path was pretty broken
12:11 sfan5 oh and if the absence/brokenness can be reliably determined by other ways minetest.features is not necessary at all
12:11 Wuzzy obviously
12:11 kilbith joined #minetest-dev
12:12 Wuzzy anyway, did you perform any tests so far?
12:12 sfan5 I am doing that right now
12:12 Wuzzy great! 🙂
12:12 Wuzzy ping me in chat if you need to know something
12:12 sfan5 it appears find_path requires you to specify an algorithm despite A*_noprefetch supposedly being the default
12:13 Wuzzy huh?
12:13 sfan5 > bad argument #6 to 'find_path' (string expected, got no value)
12:13 ShadowBot https://github.com/minetest/minetest/issues/6 -- Apples on the trees can not be eaten
12:13 Wuzzy before or after the PR?
12:13 sfan5 after, but I don't think that makes a difference
12:14 Wuzzy oh, that's definitely a bug. yes the algorithm argument must be optional accordig to lua_api
12:15 p_gimeno <sfan5> oh and if the absence/brokenness can be reliably determined by other ways minetest.features is not necessary at all  <-- I suggested to provide a code-friendly version number some years ago
12:15 sfan5 version numbers don't work for forks
12:15 Wuzzy ^^
12:16 sfan5 https://github.com/minetest/minetest/blob/master/src/script/lua_api/l_env.cpp#L1201 hmmm
12:16 sfan5 I guess absence of a value is not the same as nil?
12:16 Wuzzy i dont think code-friendly version numbers are a good method to verify if a feature exists. this would only work if we also had giant feature tables that you manually need to look up somehow. not fun
12:17 Wuzzy sfan5: yes. iirc Lua makes indeed a difference, at least in C
12:17 Wuzzy but in hte programming language Lua, absense needs to be treateted equally as nil
12:18 Wuzzy if i understood correctly, its the responsibility of the API provider (=us) to make sure that absense is treated correctly. but i'm not sure about that
12:19 Wuzzy anyway, this is fixable
12:19 Wuzzy i wonder if we have other API functions in which absense is not treated correctly...
12:21 Wuzzy by the way, the function that is used to check absense (in C) is "lua_isnone"
12:21 sfan5 http://sprunge.us/87l9PJ?diff
12:21 proller joined #minetest-dev
12:21 Wuzzy oh, i just saw there's also lua_isnoneornil. how nice of them 🙂
12:22 sfan5 just use that one then
12:22 Wuzzy yep
12:26 sfan5 the pathfinder assumes that the object walking the path is one node tall, right?
12:27 Wuzzy yes
12:28 Wuzzy adding height clearance is a much needed feature (but for a later PR)
12:30 sfan5 well I'd say it's working then
12:31 Wuzzy yay
12:34 rubenwardy I support a feature flag
12:34 rubenwardy This isn't just a bug fix, this is actually making code function
12:36 Wuzzy sfan5: rubenwardy: ok but i suggest to name it "pathfinder_works" instead of "pathfinder_works_correctly" because it's more consistent with similar names and shorter
12:36 rubenwardy Yes lol
12:39 calcul0n joined #minetest-dev
12:42 Wuzzy done
12:43 Wuzzy rubenwardy: did you do a full review again or is the code still to horrifying to you? 🙂 I have cleaned up the code (a little) and sprinkled a few comments. I hope it helps
12:52 rubenwardy Some time soon
12:52 rubenwardy Request a review to remind me
12:53 Wuzzy I just did?!
12:54 erlehmann joined #minetest-dev
12:58 BrunoMine joined #minetest-dev
13:08 proller joined #minetest-dev
13:28 pmp-p joined #minetest-dev
13:30 Unarelith joined #minetest-dev
13:32 Unarelith rubenwardy, about formspec refactor, I don't really know what to say.. yes I think it's needed, and yes it should be decoupled into multiple classes which have their own role.
13:32 Unarelith imo, you shouldn't ditch Irrlicht right away, but build a new formspec implementation on top of it which wouldn't be dependent on Irrlicht
13:33 Unarelith then, write MT's own GUI system that would replace Irrlicht
13:33 Unarelith but this is a big amount of work and I don't see how this will be possible given the current state of the project
13:33 Unarelith I went for a completely different way of handling GUI in OpenMiner
13:35 proller joined #minetest-dev
13:35 Unarelith well, not that different, but still. this is an example of GUI definition: https://github.com/Unarelith/OpenMiner/blob/master/mods/default/workbench.lua#L37-L94
13:36 Unarelith the GUI created is stored in a struct, which is serialized and sent to the client. then, the client will interpret that data to build the GUI elements from it
13:37 Unarelith so basically, for each GUI element there is: a struct (GUI def) in the server, and a class (GUI element) in the client. one class in the client is responsible for handling deserialization and GUI element creation (will move in to the element class), and one other class in the server is reponsible for Lua parsing and serialization
13:38 Unarelith (the lua parsing will move in the struct)
13:38 Unarelith I can pack what I said here into a comment on #9358 if you want, but idk if this can be of any help
13:38 ShadowBot https://github.com/minetest/minetest/issues/9358 -- Formspec Refactor
13:40 Unarelith imo, each GUI element should have two classes/structs (one for client with rendering info + deserialization, one for server with GUI data, lua parsing and serialization)
13:41 Unarelith plus two classes for the management of these classes, one in the client to store and render the complete GUI, one in the server to store and send the GUI data
13:42 Unarelith that's how it works in OpenMiner, I don't know if this is applicable to Minetest tho
13:43 Unarelith but if you go with this implementation and then want to get rid of Irrlicht for that later, only the rendering part of the client classes will change
14:27 proller joined #minetest-dev
15:27 p_gimeno rubenwardy on #9358 on ImGUI: "This is not appropriate for production games - it says this at the top of the readme"
15:27 ShadowBot https://github.com/minetest/minetest/issues/9358 -- Formspec Refactor
15:28 p_gimeno neither is Irrlicht
15:28 rubenwardy Irrlicht is intended for production games
15:28 rubenwardy It's outdated and terrible
15:28 p_gimeno not the GUI
15:28 rubenwardy No, it's not
15:28 rubenwardy Hence why we want to replace it
15:29 p_gimeno I'm not defending imGUI, just noting that what we have now is in the same condition and yet it has stuck for a while
15:30 p_gimeno and if you're able to get rid of Irrlicht's scene tree, I might be able to solve the ludicrous hack of the "camera offset" and do things properly
15:31 rubenwardy Changing GUI systems doesn't mean we'll change from irrlicht
15:31 rubenwardy That's infeasible at this point
15:32 p_gimeno shame
15:32 rubenwardy Most of the problems we have that blamed on irrlicht are actually our problems
15:33 rubenwardy One thing that could be worth doing is isolating irrlicht code from the rest of the code
15:33 rubenwardy Making it so that it's not used at all on the server
15:33 rubenwardy Although idk
15:34 rubenwardy It's currently used on the server for vectors at least, iirc
15:34 Lone_Wolf joined #minetest-dev
15:36 p_gimeno https://git.unarelith.net/Unarelith/OpenMiner/pulls/9 - OpenMiner is safe against precision problems. That solution is unfeasible in Minetest due to the scene graph handling single precision positions.
15:40 p_gimeno And also because with Irrlicht you don't have any control over how the position is applied to the transformation for rendering.
15:47 proller joined #minetest-dev
15:52 rubenwardy Nice
15:54 behalebabo joined #minetest-dev
16:55 if_gaga0 joined #minetest-dev
16:57 behalebabo joined #minetest-dev
17:12 if_gaga0 joined #minetest-dev
17:14 erlehmann joined #minetest-dev
17:22 nepugia joined #minetest-dev
17:34 nepugia joined #minetest-dev
17:35 if_gaga0 joined #minetest-dev
18:10 nepugia joined #minetest-dev
18:19 Gael-de-Sailly joined #minetest-dev
18:25 Unarelith joined #minetest-dev
18:53 calcul0n joined #minetest-dev
19:14 fluxflux joined #minetest-dev
19:28 kilbith joined #minetest-dev
19:32 kilbith_ joined #minetest-dev
19:37 pmp-p joined #minetest-dev
19:40 Jordach joined #minetest-dev
19:41 xerox123_ joined #minetest-dev
20:23 ssieb joined #minetest-dev
20:28 calcul0n_ joined #minetest-dev
20:35 Krock will merge game#2611 in 5 minutes
20:35 ShadowBot https://github.com/minetest/minetest_game/issues/2611 -- Creative: Skip redundant refreshes, fix reset button by SmallJoker
20:41 Krock <<<<
20:44 sfan5 that reminds me...
20:45 sfan5 merging game#2596 in a few mins
20:45 ShadowBot https://github.com/minetest/minetest_game/issues/2596 -- Update Chinese Translation - 2 by IFRFSX
20:45 Krock of this week's meeting points? https://dev.minetest.net/Meetings
20:45 Krock ah, no.
20:46 sfan5 well those are interesting to read too
20:56 NoctisLabs joined #minetest-dev
21:03 kilbith joined #minetest-dev
21:04 proller joined #minetest-dev
21:07 kilbith_ joined #minetest-dev
21:08 Fixer_ joined #minetest-dev
21:26 absurb joined #minetest-dev
21:52 df458 joined #minetest-dev
22:11 kilbith__ joined #minetest-dev
22:13 df458 joined #minetest-dev
23:25 erlehmann joined #minetest-dev
23:59 erlehmann joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext