Minetest logo

IRC log for #minetest-dev, 2014-05-25

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

All times shown according to UTC.

Time Nick Message
00:13 crazyR joined #minetest-dev
00:13 sapier left #minetest-dev
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.c​om/2010/03/hd_vs_sd_resolutions.png
00:51 Megaf here is a good example http://www.brorsoft.com/images/how-t​o/video-converter/1080i-vs-1080p.gif
01:04 Taoki joined #minetest-dev
01:05 deltib joined #minetest-dev
01:56 aboutGod joined #minetest-dev
02:01 aboutGod left #minetest-dev
02:02 jin_xi joined #minetest-dev
02:07 BrandonReese joined #minetest-dev
05:23 CraigyDavi_ joined #minetest-dev
05:38 nore joined #minetest-dev
06:32 Bhima___ joined #minetest-dev
06:42 Bhima joined #minetest-dev
06:43 werwerwer joined #minetest-dev
07:08 darkrose joined #minetest-dev
07:13 RealBadAngel joined #minetest-dev
07:33 deltib joined #minetest-dev
07:49 Hunterz joined #minetest-dev
08:11 PenguinDad joined #minetest-dev
08:13 OldCoder joined #minetest-dev
08:17 Calinou joined #minetest-dev
08:20 Bhima joined #minetest-dev
08:46 deltib joined #minetest-dev
08:53 Hunterz joined #minetest-dev
08:58 kaeza joined #minetest-dev
08:59 SmugLeaf joined #minetest-dev
08:59 SmugLeaf joined #minetest-dev
09:10 jin_xi joined #minetest-dev
09:13 vifino joined #minetest-dev
09:15 tomreyn joined #minetest-dev
09:20 rsiska joined #minetest-dev
09:21 Anchakor_ joined #minetest-dev
09:32 ImQ009 joined #minetest-dev
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 sapier joined #minetest-dev
09:57 PenguinDad CraigyDavi: which commit id?
10:00 CraigyDavi https://github.com/minetest/minetest/commi​t/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:03 crazyR joined #minetest-dev
10:03 deltib joined #minetest-dev
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 smoke_fumus joined #minetest-dev
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 BlockMen joined #minetest-dev
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 Bhima_ joined #minetest-dev
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:15 deltib joined #minetest-dev
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 Jordach joined #minetest-dev
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 Bhima___ joined #minetest-dev
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:11 PilzAdam joined #minetest-dev
12:23 lanxu joined #minetest-dev
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:07 Zeitgeist_ joined #minetest-dev
13:07 Zeitgeist_ joined #minetest-dev
13:18 vifino joined #minetest-dev
13:35 Bhima_ joined #minetest-dev
13:49 BlockMen sapier, #1333
13:49 ShadowBot https://github.com/minetest/minetest/issues/1333 -- Remove useless statbar protection by BlockMen
13:50 PenguinDad joined #minetest-dev
13:53 sapier you know my opinion about this, i wrote it down as comment
13:53 BlockMen ok
14:13 hmmmm joined #minetest-dev
14:16 rubenwardy joined #minetest-dev
14:17 ImQ009 joined #minetest-dev
15:02 Bhima_ joined #minetest-dev
15:03 SoniEx2 I think Minetest's Lua 5.1 should be compiled without 5.0 compatibility
15:08 Bhima__ joined #minetest-dev
15:23 grrk-bzzt joined #minetest-dev
15:31 kahrl joined #minetest-dev
15:42 Megaf joined #minetest-dev
15:45 Calinou joined #minetest-dev
16:24 Bhima joined #minetest-dev
16:34 crazyR_ joined #minetest-dev
16:37 catninja_ joined #minetest-dev
16:39 GhostDoge joined #minetest-dev
16:48 jin_xi joined #minetest-dev
17:10 arjuna joined #minetest-dev
17:32 rubenwardy joined #minetest-dev
17:32 arjuna joined #minetest-dev
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 vifino joined #minetest-dev
17:43 kaeza joined #minetest-dev
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/minete​st/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 PenguinDad joined #minetest-dev
18:11 SoniEx2 either by removing it from table.* at runtime or by compiling Lua without it
18:22 Zeitgeist_ joined #minetest-dev
18:22 Zeitgeist_ joined #minetest-dev
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/
18:59 zat joined #minetest-dev
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:14 nyuszika7h left #minetest-dev
19:17 Zeitgeist_ joined #minetest-dev
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
19:56 arjuna joined #minetest-dev
19:58 ImQ009 joined #minetest-dev
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
20:25 deltib joined #minetest-dev
20:25 BlockMen left #minetest-dev
20:55 Taoki joined #minetest-dev
21:41 deltib joined #minetest-dev
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:42 sapier left #minetest-dev
22:49 ShadowNinja Commented.
23:22 RealBadAngel sapier, imho definitely worth continuing. especially for lua entities
23:38 VanessaE RealBadAngel: you have messages waiting.

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