Time  Nick         Message
00:43 Megaf        hm, I think minetest in full screen when 1920x1080 its just actually 1080i, and not 1080p
00:43 Megaf        yep
00:44 Megaf        its 1080i
00:44 Megaf        why?
00:44 Megaf        ^ PilzAdam ShadowNinja
00:44 Megaf        minetest 1920x1080 fullscreen is actually 1080i
00:45 PilzAdam     what is 1080i ?
00:46 Megaf        minetest in fullscreen
00:46 PilzAdam     "1080i and 1080p are both High Definition display formats for HDTVs. 1080i and 1080p signals actually contain the same information. Both 1080i and 1080p represent a 1920x1080 pixel resolution (1,920 pixels across the screen by 1,080 pixels down the screen). The difference between 1080i and 1080p is in the way the signal is sent from a source component or displayed on an HDTV screen."
00:48 proller__    i = interlaced = 30fps
00:48 proller__    p = progressive = 60fps
00:48 Megaf        1080i is not actually 1080 lines, is half
00:49 Megaf        720p > 1080i
00:49 PilzAdam     maybe its your video driver?
00:50 Megaf        http://i1.ytimg.com/vi/boF_Zl-nK-A/maxresdefault.jpg
00:50 Megaf        http://aparanjape.files.wordpress.com/2010/03/hd_vs_sd_resolutions.png
00:51 Megaf        here is a good example http://www.brorsoft.com/images/how-to/video-converter/1080i-vs-1080p.gif
09:50 CraigyDavi   Managed to capture a bug caused by 3rd person view, it happens occasionally when just walking around. Did not happen before 3rd person view was introduced.
09:50 CraigyDavi   https://mediacru.sh/cOA83eNE36FV
09:50 CraigyDavi   The player you see near the end is me.
09:51 CraigyDavi   I should not be able to see myself when not using the 3rd person view mode, right?
09:56 PenguinDad   CraigyDavi: are you using the latest build?
09:56 CraigyDavi   Not the latest but a fairly recent one
09:57 PenguinDad   CraigyDavi: which commit id?
10:00 CraigyDavi   https://github.com/minetest/minetest/commit/5b1bd2fb4760e7d6f4a47e59839aa1b52c6c0f7a
10:01 CraigyDavi   Probably should get a more recent one. That is over a month old
10:01 sapier       if I rember correct blockmen said a bug like that was fixed as sideeffect of 3d mode addition
10:02 sapier       so there's reason to believe this is an old bug
10:02 CraigyDavi   it was probably fixed by "Bugfix: make waypoints respect camera offset" or "Fix player:set_animation() in third person view"
10:03 sapier       possible, there have been various changes since your version
10:04 RealBadAngel sapier, could you check why sometimes player:hud_add can return the very same id for different elements?
10:05 sapier       yes I can but I don't see a way how I might have caused that ;-)
10:05 RealBadAngel it is happening
10:05 RealBadAngel i do have two mods (UI's waypoints) and 4itemnames mod, both are using hud elements
10:06 RealBadAngel and both call hud_add and getting same id for own elements
10:06 sapier       if (id == (u32)-1) { ?? ... not the bug anyway
10:07 RealBadAngel also, i found out that putting hud_add calls in minetest_after function, solves the problem
10:09 sapier       sounds like a race condition
10:09 RealBadAngel yup, statbars were also affected by this
10:10 RealBadAngel if mods elements were added straightforward, without minetest_after, it caused bars to be overwritten
10:10 sapier       do those mods use different ways to add hud?
10:11 RealBadAngel no, simple text (or waypoint)
10:11 sapier       no I mean server step, entitiy step something else
10:11 RealBadAngel one (4itemnames) changes hud at server step
10:12 RealBadAngel UI changes that on user action (push a button) and loads data on startup (if waypoints were active, restores them)
10:12 RealBadAngel in UI case restoring had to placed in minetest_after
10:13 sapier       hmm I'll have to check that but seems to be same thread
10:13 RealBadAngel basically, if not used in minetest after, it is given wrong id
10:13 RealBadAngel which gets overriden later or something
10:14 BlockMen     or isnt applied at all (without after)
10:14 RealBadAngel it is applied
10:14 RealBadAngel i keep getting id=1 for example
10:15 RealBadAngel and then another mod is getting the very same id
10:15 RealBadAngel so the first mod assumes 1 is his own and modifies another's mod hud element
10:16 sapier       that code is strange ... it's spread throughout different classes
10:16 RealBadAngel so, it looks like whatever is done before minetest_after(0.0) gets lost
10:17 BlockMen     sapier, i doubt that the issue CraigyDavi showed here is the same that got fixed now
10:17 BlockMen     because you see the player from front
10:17 BlockMen     with the issue you would see him from back
10:17 BlockMen     it might be something else
10:17 CraigyDavi   It happens from all angles, not just the front
10:17 sapier       maybe a combination of lag and your bug?
10:18 BlockMen     hmm...might explain it then
10:18 CraigyDavi   Sometimes you see the inside of the player, sometimes you see the back, sometimes the front
10:18 BlockMen     CraigyDavi, have you tried with a current git version yet?
10:19 CraigyDavi   I'm using it now, I'll see if the problem is still there
10:19 BlockMen     k
10:21 sapier       RealBadAngel: I'm looking for that bug but I don't understand yet how it's happening, without beeing called from different threads
10:26 RealBadAngel can minetest_after calls being made from many threads?
10:27 RealBadAngel or theyre made one by one from just one thread?
10:27 sapier       for what I know everything is done from same thread
10:29 RealBadAngel hmm, i think i know the reason
10:29 sapier       if that code is supposed to be used from different threads we've got a major issue anyway
10:29 RealBadAngel builtin statbar.lua clears the hud
10:30 sapier       clears?
10:30 RealBadAngel line #39
10:30 sapier       no that's just the statbar local variable
10:31 sapier       not related to the player hud vector
10:32 sapier       change_hud receivces a pointer to a hud element, if that element is removed while still beeing processed ...
10:51 sapier       oh shit
10:51 RealBadAngel what?
10:52 sapier       hmmm no wrong idea ... even if add remove packets are lost they arrive in order
10:53 sapier       as long as we send them in order ...
10:53 sapier       which isn't guaranteed if we use it from multiple threads
10:56 sapier       assuming we really use different threads the id mechanism is completely useless
10:56 BlockMen     but it works fine in general
10:56 BlockMen     just at "start" not
10:57 sapier       as hud's ar initialized at "start" chances to mess up are way better there
10:57 sapier       think about following constellation
10:57 sapier       thread A removes hud 1, but is scheduled prior sending that packet
10:58 sapier       thread B adds a new one and is assigned id 1 because that one is now free
10:58 RealBadAngel issues is not with removing and adding at the same time
10:58 RealBadAngel we are talkin now adding returns same id
10:58 RealBadAngel one call is not delayed, second is delayed with minetest.after
10:59 sapier       which codewise means threads manage to get scheduled prior really adding their hud
10:59 RealBadAngel so definitely nothing to do with threads
10:59 RealBadAngel something that happens before minetest.after calls resests the id's counter or something like that
10:59 sapier       as of code there's no way to add huds with same id
10:59 sapier       as long as it's run singlethread
11:00 BlockMen     wait, when it does return same id when adding hud element without after, why does it work for buitin then?
11:00 BlockMen     there is no after
11:01 RealBadAngel propably point is to let builtin do its job, then go with mods hud elements
11:01 sapier       mods are initialized by same thread so there is no concurrency
11:01 RealBadAngel going to disable now builtin and see if problem is still here
11:02 BlockMen     RealBadAngel, its nothing new, so i guess it will
11:03 sapier       whole hud code isn't thread safe but I don't understand why it'd be necessary for that code
11:05 RealBadAngel and we have the winner
11:06 RealBadAngel statbar.lua definitely messes up things
11:06 RealBadAngel idk how, but it deletes everything
11:07 RealBadAngel disabling it lets hud_add work properly, no matter delayed or not
11:07 sapier       it's just another way of using it
11:08 RealBadAngel if it clears everything, no wonder mods can get same id
11:08 sapier       but there's no way to clear everything
11:09 RealBadAngel mod a is executed first, without delays gets id
11:09 RealBadAngel then comes statbar, clears it
11:10 RealBadAngel then another mod delayed
11:10 sapier       what does your mod do?
11:10 RealBadAngel both mods will get same id on first try to call hud_add
11:10 RealBadAngel add's hud elements
11:10 RealBadAngel same as the other one
11:11 RealBadAngel you can reproduce it easily
11:11 sapier       statbars should already have it's ids and not do any add or remove operation
11:11 sapier       ok give me those mods ;-)
11:11 RealBadAngel https://github.com/minetest-technic/unified_inventory
11:11 RealBadAngel https://github.com/4aiman/4itemnames
11:11 RealBadAngel enable both mods
11:12 RealBadAngel within UI, click on waypoints icon and turn some waypoints on
11:13 RealBadAngel if you enable both mods, UI's waypoints wont work
11:13 RealBadAngel now clear statbar.lua
11:13 RealBadAngel and both mods will work as a charm
11:14 RealBadAngel btw, 4aiman had problems with hud_change not workin properly
11:15 RealBadAngel no wonder if statbar messed up ids
11:15 sapier       lets see what's really happening first ;-)
11:15 sapier       how do I enable the waypoints?
11:16 RealBadAngel see buttons on bottom
11:16 RealBadAngel last one (map) turns on Waypoints tab
11:16 sapier       they miss a tooltip ;-)
11:16 sapier       ok I'm already there
11:16 RealBadAngel green flag sets the waypoint's pos
11:16 sapier       I added waypoints too how to enable them?
11:16 RealBadAngel switch next to it, turns it on/off
11:17 RealBadAngel when switch is green, you should see waypoint in game
11:17 sapier       no ... is this the bug?
11:17 RealBadAngel yes
11:17 RealBadAngel now, disable 4aiman's mod
11:18 RealBadAngel and reload game
11:19 sapier       ok I see one now
11:20 RealBadAngel now enable 4itemsname again, but clear content of statbar.lua
11:20 sapier       aren't I supposed to see ALL waypoints?
11:21 RealBadAngel if you turn all on
11:21 sapier       I did
11:21 RealBadAngel have you set different positions for each one?
11:21 sapier       yes
11:21 RealBadAngel so you should see them all
11:22 sapier       wait two of them are quite close
11:22 sapier       ok user error
11:26 RealBadAngel btw, 4itemnames show item name over inventory bar, when you change wielded item
11:26 BlockMen     but if builtin would "clean up" the ids whole time then better hud wouldnt work either
11:26 BlockMen     but it works fine
11:27 RealBadAngel does better hud use minetest after?
11:27 sapier       I don't think so
11:28 BlockMen     yes
11:28 BlockMen     oh, right
11:28 BlockMen     ups^^
11:31 RealBadAngel btw, why when i erase whole statbar.lua code, all the hud elements are still here?
11:31 RealBadAngel i mean health bar, inv
11:31 sapier       inventory isn't related
11:31 RealBadAngel what does this code really do?
11:32 sapier       you run into fallback code
11:32 sapier       the one required for old servers
11:33 RealBadAngel ok
11:33 RealBadAngel so the old one is ok, new one is used to break mods, cool :)
11:33 sapier       the old one doesn't use luahud
11:33 BlockMen     ^ better
11:33 sapier       wrong ... ugly hack
11:33 RealBadAngel gtg, bbl
11:34 sapier       but that's a different discussion
11:38 sapier       no hud removed RBA? wwaypoints aren't changed but always removed and readded
11:41 BlockMen     ^ same for the itemnames mod
11:41 sapier       if huds[pll] then player:hud_remove(huds[pll]) end do you see any code invalidating the hud?
11:42 sapier       this most likely will always clear same hud element, no matter if it was added by it or not
11:43 sapier       I don't find a bug in statbar once fixing 4aimans mod
11:45 sapier       for what I see statbar is only involved as it's another source for huds
11:45 sapier       which could be any other mod too
12:38 sapier       #1332 ... comments? sorry for the added lines but I had to follow our coding style ;-)
12:38 ShadowBot    https://github.com/minetest/minetest/issues/1332 -- Small cleanup of hud add/remove code by sapier
13:49 BlockMen     sapier, #1333
13:49 ShadowBot    https://github.com/minetest/minetest/issues/1333 -- Remove useless statbar protection by BlockMen
13:53 sapier       you know my opinion about this, i wrote it down as comment
13:53 BlockMen     ok
15:03 SoniEx2      I think Minetest's Lua 5.1 should be compiled without 5.0 compatibility
17:41 ShadowNinja  sapier: I commented on it.  There are also some {s on seperate lines than their statements, but that's less important.
17:42 sapier       I'm writing a suggestion how this should really be done ... yet that variant would break compatibility and therefore is 0.5 ... of course we could add compatibility code to it but doing so would just result in same chaos we already have
17:43 sapier       basic idea is adding generic stats to any object
17:44 sapier       removing (most of) health as well as breath special handling
17:44 sapier       maybe everything but I'm not that far right now
17:49 BlockMen     ShadowNinja: https://github.com/minetest/minetest/pull/1333#issuecomment-44140918
17:56 sapier       ShadowNinja you could write a lua coding style specification if you already refer to it ;-)
17:59 Exio4        what about making a branch and start "don't caring" about about 0.4 compat?
18:00 sapier       not without releasing a "final" 0.4 version
18:00 sapier       at least that's my opinion
18:01 sapier       And to be honest what I'm doing now is a proof of concept to illustrate how a good solution is supposed to be (at least in my oppinion)
18:02 sapier       breaking compat for a improvement that small would be quite crazy
18:02 Exio4        what i saw in the last weeks (or months) is "nah, don't do that, that would break compat" repeated at least once a day :P
18:02 sapier       the only difference would be "if lag is as big as you can't play any longer at least your statbar will be up to date"
18:03 sapier       everything else is just a nice base for mods to start from
18:04 Exio4        all the devs should agree to make a last "feature" 0.4 version
18:05 sapier       "all devs should agree" is same as "neverever do this" ;-)
18:05 Exio4        eh
18:05 Exio4        i mean, agree about the process
18:06 Exio4        you alone do it => "sapier thinks minetest is his own project"
18:06 BlockMen     ^ proller!
18:06 BlockMen     :D
18:06 sapier       did I ever say it has to be done that way?
18:07 Exio4        but you, hmmmm, RBA and c55, SN, BM :P
18:07 Exio4        everything you said that could be done is your fault sapier!
18:07 Exio4        you're why minetest doesn't have X feature! or why minetest has Y bug! :P
18:08 sapier       I know :-) I'm glad to be the one responsible if that keeps the peace  for others ;-)
18:09 sapier       if those requesting features did write half the code they suggest mt would improve almost at speed of light ;-)
18:10 SoniEx2      remove table.getn
18:11 SoniEx2      either by removing it from table.* at runtime or by compiling Lua without it
18:44 ShadowNinja  Comments on #1149?
18:44 ShadowBot    https://github.com/minetest/minetest/issues/1149 -- Add AppData file by davidgumberg
18:48 ShadowNinja  If we break compat I'd like to add some big feature, like reloadable <del>mods</del><ins>plugins</ins>.
18:50 sapier       If you have those 3-6 months to implement it shadow?
18:50 ShadowNinja  Modules would be (re)loadable C++ shared libraries, and mods would just be modufications to the engine.
18:50 ShadowNinja  sapier: Well, the main thing to do is to make register_* unregisterable.
18:50 sapier       btw you're talking about breaking compat to any mod out there not about some small client compat glitches
18:50 ShadowNinja  sapier: Yes.
18:50 sapier       basically forcing any single mod to be rewritten
18:51 ShadowNinja  sapier: I think that reloadable plugins could be done without breaking compat, but it would be uglier.
18:51 sapier       I'm listening
18:51 sapier       how do you think it could be done?
18:51 ShadowNinja  sapier: The hardest part would probably be deregistering items on the clients.
18:52 sapier       that's just a lot of work
18:52 sapier       really hard is how to separate the mods from each other
18:52 sapier       you'd have to detect and deregister dependent mods automaticaly
18:53 ShadowNinja  You would have register_* add a ["plugin"]=minetest.get_current_modname() field to everything registered, and then go through all registration tables looking for the appropriate items on unloading.
18:54 ShadowNinja  I like the way that I implemented reloadable plugins in LuaBot, but something like that would be a major compatability break.
18:54 sapier       ok sounds like a way to go for hard dependencys ... what about soft deps?
18:55 sapier       are you really willing to spend those 3 months of work or are we talking about a hypothetical scenario right now?
18:55 ShadowNinja  sapier: We should probably add a way to check if a plugin is loaded, rather than just minetest.get_modpath.
18:56 sapier       yes but first we need to fix the broken async
18:56 ShadowNinja  sapier: Hypothetical currently.  It should be fairly easy to do though.  With the exception of updating client's itemdefs, because I don't know much about that part of Minetest.
18:57 sapier       I didn't say it's complicated but it's a lot of work
18:57 ShadowNinja  sapier: Yes.  I haven't gotten any further on that.
18:57 sapier       time conduming work
18:57 sapier       -d+s
18:57 sapier       even if you know it getting it right takes time
18:58 ShadowNinja  sapier: Well, since we use make_registration only a few places will have to be changed to add it.
18:58 ShadowNinja  + a function to go through and remove entries, and a command.
18:58 sapier       and and and ;-)
18:58 Megaf        What does this means? "fdir=2"
18:59 ShadowNinja  Megaf: fdir = FaceDirection.
18:59 Megaf        I got like 7 lines of this
18:59 sapier       even without knowing the details I assume loadable mod support isn't something to be done in parallel and will require a lot of core changes
18:59 sapier       even more then android support
18:59 Megaf        http://paste.debian.net/101733/
19:02 ShadowNinja  sapier: The clean way to do it would be like this: http://pastebin.ubuntu.com/7516674/
19:03 sapier       to do what?
19:03 ShadowNinja  sapier: We could also namespace textures.  Eg, default/dirt.png
19:03 ShadowNinja  sapier: Reloadable plugins.
19:03 ShadowNinja  (mods/modules)
19:03 sapier       wait please write some concept prior starting to implement it
19:03 sapier       this is a task as big as chances your/my/anyone elses first ideas are correct are next to zero
19:04 ShadowNinja  sapier: I haven't started writing it, that's a concept.
19:04 sapier       well if that's supposed to be a concept you've got a long way to go ;-)
19:04 ShadowNinja  sapier: LuaBot ( https://github.com/ShadowNinja/LuaBot ) uses a method like this for it's reloadable plugins.
19:05 sapier       plugin concepts aren't that complicated but still we should try to find a way to implement it to not force moders to rewrite their mods in total but just modify them
19:05 sapier       that's the problem
19:06 ShadowNinja  There should also be a unload function that is called if available.  It can return true to signify that the plugin isn't unloadable.
19:06 Megaf        what could cause player timing out?
19:06 sapier       mods taking to much time
19:06 sapier       if a server step increases above client timeout all clients are dropped
19:07 ShadowNinja  sapier: Annother option is a combilition of both, with the old API depreciated and removed after a few releases.
19:07 Megaf        Im not timing out, only players with not fast internet are timing out
19:07 sapier       classical timeout about all packets beeing lost?
19:08 Megaf        16:06:31: ERROR[ConnectionSend]: con(5/1)RunTimeouts(): Peer 580 has timed out. (source=peer->timeout_counter)
19:08 Megaf        16:06:31: ACTION[ServerThread]: kaue123 times out. List of players: Megaf Ricardo
19:08 Megaf        16:08:33: ERROR[ConnectionSend]: con(5/1)RunTimeouts(): Peer 581 has timed out. (source=peer->timeout_counter)
19:08 Megaf        16:08:33: ACTION[ServerThread]: Lander times out. List of players: Megaf Ricardo kaue123
19:08 Megaf        actually everyone but me are timing out
19:09 Megaf        And i get these messages alone too, without a player actually timing out
19:09 Megaf        16:08:54: ERROR[ConnectionSend]: con(5/1)RunTimeouts(): Peer 583 has timed out. (source=peer->timeout_counter)
19:09 ShadowNinja  Megaf: pastebin please.
19:09 Megaf        http://paste.debian.net/101739/
19:17 Megaf        It's also really hard to teleport those players
19:17 Megaf        and when they die, they spawn where they died
19:27 Megaf        ok, not everyone timing out
19:30 sapier       well spawn location issue is something completely different
19:30 Megaf        You are wrong
19:30 sapier       that happens for me too
19:30 sapier       not always but sometimes
19:31 Megaf        wrong spawn location + problems teleporting + timeout = all network issues
19:31 Megaf        client and server having trouble speaking to each other
19:32 sapier       just because I'm the only one fixing bugs claiming everything to be a network issue wont help
19:32 sapier       ;-)
19:32 Megaf        i don't know whos fixing it
19:33 sapier       btw peer timeout after 2 minutest of not receiving anything from that client is perfectly ok
19:33 sapier       are those clients current ones or some old buggy ones?
19:33 Megaf        I believe those clients have poor internet connections or may be using outdated clients
19:34 sapier       then make them use recent clients in first step and see if this helps, we can't fix client side bugs causing client not to send any data on server
19:34 Megaf        so, I think there's nothing we can do about
19:35 sapier       the only difference to before is those clients have been dropped silently in old code
19:39 sapier       the spawn location thingy is a bug ... but it's not server/client communication as the position is done server side only
19:40 sapier       teleporting ... no idea, but if a client isn't initialized properly due to already timing out that might be the result
19:40 sapier       and timeout ... if there's really a slow connection and old clients that might be the reason for this one
19:40 sapier       later two issues are hard to impossible to fix on server side
19:45 Megaf        sapier, I can see no way of improving that without creating overhead
19:45 sapier       improve what?
19:45 Megaf        timeouts]
19:46 Megaf        that could be prevented
19:46 sapier       how is it supposed to be prevented? we already send pins
19:46 sapier       pings
19:46 Megaf        being passive, not sending pings
19:46 Megaf        but not a good idea
19:46 sapier       that's not an option as you'd not have a way to remove clients
19:47 sapier       dead clients
19:49 sapier       in case those clients state machine is messed up they most likely wont answer no matter if we wait 60 600 or 6000 seconds
20:11 * VanessaE   peeks in
20:22 Megaf        sapier; Just confirmed, there was 3 players having issues
20:22 Megaf        other players are fine
20:22 Megaf        no timeouts at all
20:23 sapier       ok now we'd have to find out what clients those 3 players have been using
22:24 sapier       #1335 comments on this? worth continuing and adding stats for lua entities too or drop it?
22:24 ShadowBot    https://github.com/minetest/minetest/issues/1335 -- WIP replace hp/breath by generic stat mechanism by sapier
22:25 sapier       proller you don't even have to answer the last question I already know your answer
22:33 VanessaE     how does this affect old clients if they connect to a server so-patched?
22:33 sapier       they won't have any statbar
22:33 VanessaE     ok, that's a big no, then.
22:34 sapier       that's why I suggest not to add it as is
22:34 sapier       it's an improvement for a 0.5 release
22:34 VanessaE     you should mention that in the "compatibility" line
22:34 sapier       basicaly a showcase how I believe stats should be implemented in a clean way
22:34 VanessaE     fair enough
22:35 sapier       open for suggestions and improvement till it's added or not added by 0.5
22:36 sapier       maybe it's possible to add compatibility code, but I'm not sure if it'd result in crazy code
22:37 VanessaE     well of course I suppose I should clarify, by "old" client, I mean one that has C++ statbars and doesn't support HUD
22:37 sapier       and to be honest this thing wont give a lot of benefit as long as we don't have client side lua
22:37 VanessaE     anything that supports HUD surely would work fine with an appropriately-coded game on the server.
22:38 sapier       partial
22:39 sapier       starting from lua hud support a game could at least add some sort of statbar
22:39 sapier       16x16 px
22:39 sapier       scaling with texture pack ... so not a really good way
22:40 sapier       I'll check if it's possible to make it compatible but if it's more then 500 lines of code I don't really think it's worth it
22:49 ShadowNinja  Commented.
23:22 RealBadAngel sapier, imho definitely worth continuing. especially for lua entities
23:38 VanessaE     RealBadAngel: you have messages waiting.