Minetest logo

IRC log for #minetest-dev, 2014-07-12

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

All times shown according to UTC.

Time Nick Message
00:01 spreeuw joined #minetest-dev
00:01 spreeuw left #minetest-dev
00:11 hoodedice left #minetest-dev
00:20 HLuaBot joined #minetest-dev
00:21 ShadowNinja ''tell sapier I was having the scaling issues on a Nexus 10, not a Nexus 7.
00:21 HLuaBot I'll tell that to "sapier" next time I see them around.
00:26 alexxs joined #minetest-dev
00:27 Megaf joined #minetest-dev
02:51 cheapie joined #minetest-dev
03:00 domtron joined #minetest-dev
03:51 us`0gb joined #minetest-dev
03:57 Miner_48er joined #minetest-dev
04:22 SoniEx2 joined #minetest-dev
06:35 CraigyDavi joined #minetest-dev
06:36 nore joined #minetest-dev
06:39 Garmine joined #minetest-dev
06:40 tomreyn joined #minetest-dev
06:43 CraigyDavi` joined #minetest-dev
06:52 CraigyDavi joined #minetest-dev
07:02 CraigyDavi` joined #minetest-dev
07:05 CraigyDavi`` joined #minetest-dev
07:10 CraigyDavi joined #minetest-dev
07:14 CraigyDavi` joined #minetest-dev
07:32 Hunterz joined #minetest-dev
07:36 Jordach joined #minetest-dev
08:07 SmugLeaf joined #minetest-dev
08:07 SmugLeaf joined #minetest-dev
08:10 Zeno` joined #minetest-dev
08:10 Zeno` hi
08:14 VanessaE RealBadAngel: https://github.com/minetest/minetest/issues/1469
08:15 * darkrose pokes VanessaE
08:16 VanessaE hey darkrose  :)
08:16 darkrose hi :)
08:16 darkrose you poked me a couple of days ago?
08:16 RealBadAngel hi all
08:17 VanessaE darkrose: yeah, I was trying to see if that was you on a certain 0.4.x server - I assumed not but I wanted to be sure.
08:17 darkrose yeah, I don't play 0.4
08:17 RealBadAngel VanessaE, one side effect of my changes to cracks, one will be able to disable the effect just by removing (not supporting) the texture
08:19 RealBadAngel so it could be used to speedup the game on slower machines, digging wont be causing meshupdates then
08:19 VanessaE RealBadAngel: interesting.  well the game will always have the cracks texture anyway so that's no big deal
08:20 RealBadAngel by now the file is required, after it COULD be used
08:20 RealBadAngel and file is supported by game not the engine
08:21 VanessaE darkrose: that's what I thought.
08:22 VanessaE RealBadAngel: read the above bug report please.  you fucked up either in lua_api.txt or in the C++ code. :)
08:22 VanessaE also optional cracks imagery might actually be a good thing in some random game.
08:22 RealBadAngel i already did
08:22 VanessaE (imagine some game where there's just no need for it)
08:23 VanessaE oh, so you did :)
08:27 RealBadAngel i want to finish that crack/animation stuff now, then i will fix the trees
08:28 RealBadAngel what im doing right now is makin meshupdates as fast as possible
08:28 RealBadAngel which means all the code that plays with strings, file access etc get kicked outter space from here
08:31 Calinou joined #minetest-dev
08:32 VanessaE good. :)
08:37 grrk-bzzt joined #minetest-dev
08:37 grrk-bzzt joined #minetest-dev
08:45 Zeno` RealBadAngel, I also wondered if ps.next() was intentionally omitted in the first loop
08:46 Zeno` :range() doesn't update the next random number
08:46 RealBadAngel how im supposed to remember that after year or something like that? ;)
08:46 Zeno` nfi
08:46 Zeno` lol
08:46 Zeno` that's what comments are for :p~
08:47 RealBadAngel random stuff was working correctly but then PA insisted on generating the very same trees depending on seed
08:47 RealBadAngel which is nonsense for me, but i added that
08:47 RealBadAngel maybe then i broke something
08:48 Zeno` well, I think the seed is correct (just not initialised so it's undefined behaviour) but the chances are definately wrong (>= conditional instead of <=)
08:49 Zeno` generating the same tree given the same seed would be expected
08:50 Zeno` It needs to be stressed in the docs though... I suppose I could do that
08:50 RealBadAngel i suck creating any docs ;)
08:52 Zeno` it's not really nonsense (same seed making same tree) :p Same as rand() will return the same sequence if srand() is given the same seed or not at all
08:53 Zeno` I think PA was correct in saying that, but yeah
08:58 PenguinDad joined #minetest-dev
09:13 sapier joined #minetest-dev
09:15 sapier seems like mapgen somehow manages to delay mainloop, does anyone know how this happens?
09:16 sapier result is a runaway mainloop delay causing visible stutter in game
09:16 sapier as delay builds up to an extent where network packets are dropped
09:18 sapier you can see it in plain game too, enable profiler, stand still wait till all is done ... them move around and look at incoming packets ... you'll see wholes and spikes in there as packets haven't been handled and get handled at once
09:19 sapier in a new world of course
09:29 proller joined #minetest-dev
09:32 Garmine joined #minetest-dev
09:34 cerulean256 joined #minetest-dev
09:35 cerulean256 Hi guys, is there a plan regarding how lag is going to be dealt with. It is really a problem when compared to other games like minecraft.
09:36 sapier read up about 10 lines
09:36 sapier in history ;-)
09:36 cerulean256 I just joined so I can't
09:36 sapier http://irc.minetest.ru/minetest-dev/ you can
09:36 cerulean256 ahha.. ok :)
09:37 sapier short ... seems to be a bug
09:38 cerulean256 a long lived bug :)
09:38 cerulean256 the jumping characters around the map is quite disruptive
09:38 sapier well that's not really a bug
09:39 cerulean256 I think the discussion of "try to follow someone in minetest" is a perfect example of a problem.
09:39 sapier that's just result of minetest accepting player position from client and not controling it server side (within boundarys)
09:39 cerulean256 it may be a design choice - hence not a bug - but it may not have been the best choice.
09:40 sapier maybe but chances to change this aren't that big ... depends on how much needs to be changed of course
09:41 cerulean256 when it comes to player position it would be possible to have the client send the position updates and the server confirm them before updating the other connected clients with the new location
09:42 sapier that'd increase network load by factor 2
09:42 cerulean256 it may be considered added overhead.... but it should smoothout the gameplay
09:43 sapier how is this supposed to smooth gameplay? there'd be a change for player itself only but not for others?
09:44 cerulean256 well each update does rely on the client doing some of the work in smoothing things over, like processing the animations, etc. right?
09:45 cerulean256 we could also use TCP and make sure everything arrives in  order and that will smooth the traffic stream substatailly
09:46 cerulean256 substantially*
09:46 sapier we already ensure everything arrives in order
09:47 sapier tcp may even increase lag effect as any single client position update has to be received in order to receive the important data
09:47 sapier and client sends a lot of them
09:47 cerulean256 ok... then why can one follow another player in games like Halflife with little / no jumpiness and minetest not?
09:47 sapier guess they're smoothing client side
09:48 sapier and send less position updates then we do
09:48 sapier but as said that's a guess
09:48 cerulean256 less?? I have to disagree
09:48 cerulean256 it's a shooter.. how would less make the game playable?
09:48 sapier have you ever had a look at network packets?
09:48 cerulean256 yes
09:49 sapier client sends tremendous amounts of packets once a player moves
09:49 cerulean256 you mean minetest packets imparticular?
09:49 sapier that might even be the problem as those packets are passed to each player on server
09:50 sapier thus multiplying by player count
09:51 cerulean256 but that shouldn't be a problem for server grade hardware
09:51 PilzAdam joined #minetest-dev
09:51 proller joined #minetest-dev
09:51 sapier it is
09:51 celeron55 if people prefer smoothness in place of low latency, the minetest client could buffer movement data for like a second or two
09:51 cerulean256 are you suggesting that the lag the I see on the nummerous minetest servers out there are just home run vms?
09:51 celeron55 Taoki's post seems to refer to this
09:52 cerulean256 celeron55: I think that would be a nice compromise
09:52 sapier cerulean256: lots of them
09:52 celeron55 but the real problem is the server's design; all of this are just workarounds
09:52 Zeno` cerulean256, for the most part, yes
09:52 celeron55 so you have to first choose between whether you want to make a workaround or actually make the server not laggy
09:52 Taoki celeron55: Yeah, I mentioned buffering movement client-side a few times. IMO that's very necessary to get good movement
09:53 cerulean256 Taoki: I agree with that assessment.
09:53 sapier I think there are multiple flaws resulting in this issue
09:53 celeron55 it's possible to not make the server laggy, but there's no quick way for achieving that; it's a long process of improving the architecture that has already started
09:53 Taoki It's good if it already started
09:53 celeron55 the server of eg. quake or stuff like that does almost nothing compared to the MT server
09:54 celeron55 they just check some physics and route position packets around
09:54 Taoki celeron55: For me it was just a visual problem mostly. But some players said you can't even follow someone else in multiplayer, because the player is seen snapping all over the place. So someone can barely even show you to their house
09:54 Taoki Yeah... I hope someday we'll have Quake engine quality movement prediction
09:54 celeron55 the MT server runs a huge amount of all kinds of crap that currently interferes with the basic operation like quake's
09:54 cerulean256 celeron55: it's good to know if it's on the roadmap
09:55 cerulean256 Taoki: The "snapping" problem is something I see constantly and even worse.. I'll be building and put down say 20 blocks and the they disappear.. then show up 3 seconds later
09:55 celeron55 so to me this seems that decoupling the basic interaction loop from the heavy lifting should be achieved ASAP
09:55 sapier one of my next major tasks is spliting game physics from player interaction
09:55 celeron55 that could still imply a year of development though
09:55 Taoki ouch
09:55 Zeno` I doubt that many MT servers are running on server grade hardware. Correct me if I'm wrong.
09:55 Taoki @cerulean256
09:55 Taoki Zeno`: Not all Quake / etc servers are either
09:56 celeron55 cerulean256: that's caused by the server running some mod code and stopping everything else while doing it, and then resuming from where it left off
09:56 VanessaE Zeno`: and even if they are, the problem still persists.
09:56 sapier a year ... yes I was hoping to get it done a little bit more fast but it's in same range I expected it to be
09:56 celeron55 cerulean256: nothing about network or any kind of conventional lag that people generally talk about
09:56 Zeno` Taoki, true. But I think Quake has movement prediction
09:56 Zeno` same with projectile paths
09:56 Taoki true
09:57 sapier we've got projectile path prediction too ;-)
09:57 cerulean256 what are the minimum system requirement for a good performing minetest server?
09:57 sapier cerulean256: depends
09:58 sapier it's more about the mods you wanna run
09:58 cerulean256 related to this discussion ;)
09:58 sapier for some mods there's no "good enough" hardware
09:58 celeron55 and the amount of players you want to host
09:58 proller i want 1000
09:59 celeron55 almost any hardware can run a vanilla minetest_game with a couple of players; then everything else is up from there
09:59 Taoki Also, I think another problem is we don't network movement fast enough perhaps. Server step is still 0.1 I believe. I suggested (and still do) using at least 0.05
09:59 Taoki I mean does it eat that much CPU?
09:59 celeron55 Taoki: stop talking about that crap; you don't gain anything from it
09:59 cerulean256 if what celeron55 is saying is true about the mods delaying server execution then maybe registering mods with the main minetest loop needs to be done with care by mod developers
10:00 Taoki aha, ok
10:00 celeron55 Taoki: the only things we need are decoupling of fast and slow processing and better interpolation
10:00 Taoki I agree about that
10:00 Taoki Yeah, aht the classic yaw interpolation too heh
10:00 Taoki **and
10:01 sapier cerulean256: excactly but most mod developers don't care and blame engine ;-)
10:01 celeron55 cerulean256: yes, writing mods carefully certainly helps; but it's a lot of work
10:01 Zeno` To be fair, at least some of the blame belongs with the engine
10:01 celeron55 yes, because the engine's job is to make writing content easy
10:01 cerulean256 Zeno`: sure, to a certain degree
10:01 Taoki Yes, mods also need to be optimized. The engine can't do much if a Lua script is used badly. I always try to optimize mine the most
10:02 Zeno` I mean the main game loop is 4000 fucking lines long (or something like that)
10:02 celeron55 currently writing processing-heavy content is not easy
10:02 sapier yes but it's allways gonna be if you abuse tomethin result will be bad
10:02 Zeno` no scheduling (last I looked), nothing
10:02 cerulean256 celeron55: can you clarify what heavy content is?
10:02 sapier anything accessing more then one node on map
10:03 celeron55 cerulean256: like a lua-based map generator or a mob mod making heavy use of pathfinding
10:03 sapier pathfinding for more then about 10 nodes distance will most likely be uusable
10:04 sapier not in regular case, there it's quite fast, but worst case is the problem
10:04 cerulean256 ok.. here's another question that I haven't even looked at... is the minetest-server multithreaded?
10:04 sapier that part isn't
10:04 cerulean256 I know trying to code multitrhreaded processes in C/C++ is a bitch :)
10:04 celeron55 some parts are, some aren't
10:04 sapier and that's the improvement celeron is talking about
10:04 Zeno` reentrant and mutex-locked code isn't /that/ hard in C or C++
10:05 sapier Zeno`:  that doesn't help anything if you lock your code down to be singlethreaded again
10:05 sapier except adding locking overhead
10:05 cerulean256 sapier: :)
10:05 Zeno` sapier, correct, which is why I mentioned scheduling earlier
10:06 Zeno` I may be stupid but the main server loop is in my eyes an atrocity
10:07 sapier yes celeron I know I'm using locks very much too :-)
10:08 sapier I'd prefere to use "atomic" for most of those locations but as long as we don't have c++11 ...
10:08 sapier having to protect a variable increment by mutex is just overkill
10:09 sfan5 <sapier> I'd prefere to use "atomic" for most of those locations but as long as we don't have c++11 ...
10:09 sfan5 #if ENABLE_CXX11
10:09 sfan5 do c++11 stuff
10:09 sfan5 #else
10:09 sfan5 do c++03 stuff
10:09 sfan5 #endif
10:09 sapier I won't do that for sure
10:09 proller lol
10:09 sfan5 why not
10:09 sapier cause code will be unreadable
10:10 cerulean256 it'll also become more difficult to maintian in general
10:10 Zeno` I disagree. Most pre c++11 (or C) code works fine with mutexes and it doesn't cause considerable processing
10:10 sfan5 how about writing a generic class for mutexes, locks, etc. and varying the implementation of those between C++11 and C++03?
10:11 Zeno` Does the Linux kernel use C++11 atomic ops?
10:11 proller time to https://github.com/minetest/minetest/pull/1390
10:11 celeron55 mutexes do have overhead; you can only do like tens of thousands of lockings per second with those without making them a bottleneck
10:11 sapier for sure not kernel is C
10:11 Zeno` yeah of course there is overhead, but it should not be a bottleneck
10:12 Zeno` ok, so the Linux kernel doesn't use atomic ops (it may in some places with ASM, but in general no) and it's not what I'd call inefficient
10:13 Zeno` Anyway, I am tired :)
10:13 Zeno` maybe that main loop will be looked at one day
10:13 sfan5 so.. does anyone want to react to my suggestion?
10:14 celeron55 sfan5: we have generic classes for those
10:14 Zeno` sfan5, #ifdef... yuck
10:14 celeron55 sfan5: it's called our fork of jthread
10:14 celeron55 sfan5: so feel free to
10:14 celeron55 as long as you are testing it
10:14 * sfan5 adds to TODO list
10:14 LemonLake joined #minetest-dev
10:14 Calinou <Taoki> Also, I think another problem is we don't network movement fast enough perhaps. Server step is still 0.1 I believe. I suggested (and still do) using at least 0.05
10:15 Calinou we used to use 0.05, for some time (how much time?)
10:15 Zeno` I don't agree that using C++11 crap is the solution
10:16 sfan5 who said that it is the solution?
10:16 Zeno` the solution is to refactor the main game loop so it's not so sequential
10:16 Calinou cerulean256, map generation can use multiple threads (num_emerge_threads = N where N is number of threads, default is 1), but concurrency often happens and the speedup is small
10:16 Zeno` sfan5, I dunno :)
10:16 Calinou (and since there's lots of concurrency, you waste power)
10:16 sapier nooooooo
10:16 sapier don't use emerge thread multithreaded
10:16 sapier it's broken
10:16 sapier hmmmm is working on it but it's not completed
10:18 sapier and won't help too
10:18 Zeno` many, many, many games are not multithreaded
10:18 sapier we're working at main server loop but it's nothing that can be fixed in no time
10:19 Zeno` I will bet $1 that changes to the main server loop will/can solve 90% of the problems
10:20 Calinou …and by tweaking server settings
10:20 sapier and cause about 20% new issues
10:20 Calinou http://paste.ubuntu.com/7784138/
10:20 Calinou (-:
10:20 Calinou tweak max block sends depending on your bandwidth
10:21 Zeno` if refactoring the main server loop causes 20% more issues then that's a problem :p
10:22 celeron55 Zeno`: an MT server without mods doesn't cause "server lag"
10:22 celeron55 Zeno`: mods cause it by doing a lot of processing during a single tick
10:22 sapier if refactoring means just moving aroun then it's not gonna fix any issue too
10:22 celeron55 they run in the same thread
10:23 Zeno` fair enough then
10:23 sapier I was talking about spliting async (player related) from sync(mod/game/world) stuff
10:23 Zeno` and I didn't mean "just moving stuff around"
10:23 celeron55 really the only built-in heavy processing on the server is the map generator / loader, which is run in a separate thread for that exact reason
10:23 Zeno` but I guess moving stuff around would at least make it more comprehensible heh
10:23 sapier and mods ;-)
10:24 Zeno` I refuse to blame the mods
10:25 Zeno` Mods are an integral part of MT... to blame them is kind of passing the buck
10:25 celeron55 sapier: yes, mods, that aren't run in a separate thread
10:25 celeron55 Zeno`: knowing an issue doesn't mean blaming anyone
10:25 sfan5 we should really add threading for lua
10:25 celeron55 Zeno`: this is a completely objective thing
10:25 Zeno` that might help yeah
10:25 Zeno` celeron55, maybe
10:26 celeron55 sfan5: only if it's done properly with added locks in the engine so that it isn't effectively singlethreaded if any api calls are made
10:26 sfan5 yeah, otherwise there wouldn't be any benefit
10:26 celeron55 this is again what sapier is aiming for
10:26 celeron55 and which will take long to achieve
10:27 sfan5 goal for 0.5.0?
10:27 sapier nope
10:27 celeron55 no goal
10:27 sapier it's a evulutionary process
10:28 sapier if I change it once everything will be broken
10:28 sapier my next step towards is adding async api for mods (quite limited in first step but already helpfull for mapgens)
10:29 sapier as a mapgen doesn't need to interact to map while generating it this can be done completely async
10:30 Zeno` why not take a step back before doing that?
10:30 Zeno` I agree that that is a good thing to do, but... hmm
10:31 Zeno` Even if there is a penalty (speed-wise) for refactoring that horrible main loop I'd do that first
10:31 sapier because I do this in my freetime and fixing it is about half a year full time work
10:32 Zeno` I understand that completely sapier and am truly grateful. I did not mean to imply otherwise.
10:32 sapier guess how long it's gonna be broken if you try to do that much work in free time ;-) ... minetest will work again in ... hmmm ... 2016
10:33 sapier I know this isn't perfect but as long as there's noone having that much time available
10:34 Zeno` I didn't mean to offend, honestly. I just say it as I see it (without consideration of the things you rightfully mention heh)
10:34 Zeno` Maybe I'll rewrite the loop *shrug*
10:35 Zeno` I don't need to sleep anyway
10:36 sapier for this point we know what to do for about a year now
10:36 sapier ok last half year was spent for getting android port fly ... anyone willing to polish it? so I can focus on server improvement?
10:40 Zeno` I'll call my for ZenoTest!
10:40 Zeno` fork*
10:40 Zeno` android? errr. /me hides
10:43 RealBadAngel sapier, i will take care of opengles shaders, for sure
10:45 celeron55 there's probably infinite polishing in it, i can't really suggest anything as i am not in the target audience
10:45 celeron55 well i can suggest not focusing on it anymore
10:46 celeron55 maybe try to fix things based on user requests
10:50 sapier actually that's been my current plan to, fix the bugs but don't do changes like "improved controls" or things like that
10:51 sapier e.g. a new main menu for small devices would be nice too but I don't think it's fun to play on those devices anywa
10:51 sapier y
11:01 sfan5 >maybe try to fix things based on user requests
11:01 sfan5 this is a very good idea
11:01 cerulean256 Minetest on PC is best!
11:01 cerulean256 :)
11:02 sfan5 request after building bridges over lava for 6 hours: if I place a node somewhere it should stay there and not momentarily disappear
11:02 sapier the difference between what you understood and what is meant is "fix" isn't same as "implement" sfan5 ;-)
11:03 sfan5 ik
11:04 sapier if someone complains "hey my icons are messed up" I'll fix it for sure but if it's "hey controls aren't same as in xzy" ... nope
11:05 sapier btw can someone reproduce ShadowNinja's issues on Nexus10 and Nexus7? at least on emulator with nexus7 skin (new variant) it doesn#t happen
11:05 Zeno` my icons are messed up
11:05 sapier cleanup your desktop ;-P
11:06 Zeno` oh
11:06 Zeno` yes, good point
11:06 sapier no without joking is there a issue with minetest? ;-)
11:06 Zeno` nope :)
11:07 sfan5 sapier: yes, icons are messed up on windows
11:08 sapier sfan5 a screenshot would help ;-)
11:08 sfan5 the inventory image for cobble is just blank
11:10 sapier any errors in log?
11:14 sfan5 no
11:18 sapier what graphics card?
11:19 sfan5 AMD
11:19 asl joined #minetest-dev
11:19 sfan5 with Direct3D9 btw
11:23 sapier hmm
11:24 sapier other inventorycubes are ok?
11:24 ImQ009 joined #minetest-dev
11:24 ImQ009 joined #minetest-dev
11:25 sfan5 sometimes, sometimes not
11:26 sapier hmm sadly my invenctorycube render fix for android isn't compiled on pc
11:26 sapier tile.cpp L832 you could try to compile this on py and then set "inventory_image_hack" to true in config
11:27 sfan5 I'll consider that
11:30 Zeno` Is inventory pronounced "invent oree" or "inven toree"?
11:30 vifino joined #minetest-dev
11:32 Zeno` "invent oree" would suggest a list of items that you invent things with
11:32 Zeno` "inven toree" would suggest... I dunno
11:33 Zeno` or isn't it important?
11:36 Zeno` Maybe it's like "factory" which has nothing at all to do with facts (it stems from "manufactory")
12:06 Piggybear87 joined #minetest-dev
12:12 Piggybear87 left #minetest-dev
12:12 asl joined #minetest-dev
12:12 LemonLake joined #minetest-dev
12:12 proller joined #minetest-dev
12:12 cerulean256 joined #minetest-dev
12:12 PenguinDad joined #minetest-dev
12:12 grrk-bzzt joined #minetest-dev
12:12 Zeno` joined #minetest-dev
12:12 Hunterz joined #minetest-dev
12:12 CraigyDavi` joined #minetest-dev
12:12 nore joined #minetest-dev
12:12 SoniEx2 joined #minetest-dev
12:12 us`0gb joined #minetest-dev
12:12 alexxs joined #minetest-dev
12:12 HLuaBot joined #minetest-dev
12:12 kahrl joined #minetest-dev
12:12 crazyR joined #minetest-dev
12:12 khonkhortisan joined #minetest-dev
12:12 Ritchie joined #minetest-dev
12:12 AnotherBrick joined #minetest-dev
12:12 Taoki joined #minetest-dev
12:12 VanessaE joined #minetest-dev
12:12 deltib joined #minetest-dev
12:12 VargaD joined #minetest-dev
12:12 psedlak joined #minetest-dev
12:12 ShadowNinja joined #minetest-dev
12:12 hax404 joined #minetest-dev
12:12 Robby joined #minetest-dev
12:12 sfan5 joined #minetest-dev
12:12 harrison joined #minetest-dev
12:12 eeew joined #minetest-dev
12:12 netchip joined #minetest-dev
12:12 Anchakor_ joined #minetest-dev
12:12 darkrose joined #minetest-dev
12:12 pitriss joined #minetest-dev
12:12 celeron55 joined #minetest-dev
12:12 dzho joined #minetest-dev
12:12 daswort joined #minetest-dev
12:12 Gethiox joined #minetest-dev
12:12 catninja_ joined #minetest-dev
12:12 RealBadAngel joined #minetest-dev
12:14 CraigyDavi joined #minetest-dev
13:04 sapier >>>// Reset periodically to workaround for some bugs or stuff<<<<  I hate comments like that causing bugs to be hidden instead of fixed
13:05 sapier in this special case we send map to player each 20 seconds ... no mater if necessary or not
13:17 MichaelRpdx joined #minetest-dev
13:30 Jordach joined #minetest-dev
13:32 celeron55 sapier: it's not exactly for bugs, it's more about the quirks of the design of the algorithm
13:33 celeron55 and, well, implementation too; it's just not designed or implemented to be perfect
13:34 sapier I'm not quite sure but what I think this was necessary because of player modifications may not have been sent soon enough
13:34 sapier at least that's my current state of investigation
13:34 celeron55 wait, where is that comment
13:34 sapier code detecting which blocks to send next
13:35 celeron55 yes it's where i thought it is
13:35 sapier I think if I mark blocks modified by player and queue them prior doing the geometry based sending that hack might be unneccessary
13:36 celeron55 if you want to remvoe that, then it needs proper and solid reset mechanisms for when map has been generated in the area it has skipped, when the player has moved a large distance (i don't know about the exact details involved in doing this) and so on
13:36 celeron55 it just forces the algorithm to restart to catch all possible things it might not be accounting for
13:36 celeron55 which in my opinion is the right thing to do instead of making it fail if someone has forgotten to account for some situation
13:37 sapier right now that code results in nodes having been dug reappearing and vanishing
13:37 celeron55 because there are many rare and extremely hard to test situations it can run into
13:38 celeron55 that isn't a problem in the algorithm
13:39 sapier it seems to me like node mofifications not getting accounted soon enough
13:39 celeron55 the correct way to fix that is not to remove the ability to send blocks near the player in situations where it is actually needed
13:40 celeron55 but by doing something else to disallow it handling the state in two places and then mixing them up
13:40 celeron55 including block modification timestamps in the protocol comes to mind
13:40 sapier player moving wouldn't be a problem as this can be detected ... not generated blocks ... puuhh not sure about that one
13:41 sapier when you say blocks you really mean blocks and not nodes true?
13:42 sapier I don't really understand "(15:39:25) celeron55: the correct way to fix that is not to remove the ability to send blocks near the player in situations where it is actually needed" who does remove the ability to send blocks?
13:42 LemonLake joined #minetest-dev
13:43 celeron55 the issue likely is that when the client is placing nodes, it predicts the placement; then the server may have been doing something during that time and as a result of that, it for some reason sends and updated full mapblock to the client not yet containing the placements made by the client to it; then it proceeds to read what the client placed and handles them in whatever way it does it
13:43 kaeza joined #minetest-dev
13:44 sapier maybe but that's not what I experience, I dig a lot of nodes in creative mode
13:44 celeron55 and the client does not know that its actions weren't yet accounted on the data it received while it received the data after its actions
13:44 sapier on network I see client sending the interact packets as I dig,
13:44 sapier but block updates are somehow stuffed
13:45 celeron55 what?
13:45 sapier I get wholes in update stream ... most likely due to congestion as block information is sent on low priority
13:46 sapier making the issue even worse
13:46 sapier basicaly I need a way to handle player originated block changes at higher priority then regular map transmission ... well that's my current working thesis
13:47 celeron55 oh, so the block update is de-synced from the single-node digging updates and then the client receives it late from some congestion buffer?
13:47 sapier yes
13:47 celeron55 this is very likely to be fixed with modification timestamps
13:47 sapier ok "yes" as I know so far
13:48 sapier but I'd either have to sync them client server or stop player from changing a block till I got result ... last one is quite laggy
13:48 celeron55 this is actually caused by your network changes, because the previous code didn't send anything with differing priority
13:49 sapier I know :-/
13:49 celeron55 it might need some weird way of merging past changes into data that is newer than the past changes
13:49 celeron55 or you could be lazy and just disable differing priorization
13:49 sapier yes but that'd reintroduce lag
13:49 sapier well another sort of lag
13:50 celeron55 so the client needs to be able to see "oh i applied these updates to this block already, but the server is now telling that the block actually was this way so i'll apply all nodes from this block except the ones i updated after its timestamp" 8)
13:50 sapier that's why I prefere to move the player originated changes ot a higher priority .... as it's supposed to be, sadly for blocks it's not that easy to decide
13:50 sapier actually server doesn't even send an update if it's fine
13:51 sapier making it even worse as the outdated block is visible on client till next regular update is received
13:51 celeron55 usually diggings and placings are handled as single-node updates but we always need to have a functional fallback case of updating the whole mapblock if there is no single-node packet for doing the needed synchronization that the action caused (it can cause anything)
13:52 celeron55 and that reset in the block sending code enables us to see the bugs in this system
13:52 sapier for what I've seen that's not correct, client sends single node updates yes
13:52 sapier but server sends whole block if the result is not as expected by client
13:52 sapier for digging
13:53 sapier haven't had a look at placing by now
13:53 celeron55 yes, that's how it works
13:53 proller want commit  https://github.com/minetest/minetest/pull/1390
13:54 sapier I think I know what to do, serve remembers what blocks are on wire, in case a player modifies a block on wire we need to send it too even if the result is as expected
13:55 celeron55 could work
13:55 sapier I'll try it that way
13:57 celeron55 proller: the comments in there seem somewhat reasonable
13:58 proller nobody never use it
13:59 proller its outdated and useless
13:59 celeron55 i think the indev mapgen should be removed too if math is removed
14:00 hmmmm joined #minetest-dev
14:00 proller its other pull
14:01 proller i can remove both
14:02 celeron55 hmmmm: https://github.com/minetest/minetest/pull/1390
14:03 proller and https://github.com/minetest/minetest/pull/1407
14:06 hmmmm sounds great
14:07 proller merge?
14:10 hmmmm yep
14:10 proller both?
14:10 hmmmm yep
14:10 proller okay
14:16 sapier celeron55 thanks for discussing that issue just flaging a block being transmitted solves the issue on digging and is way less change then what I first wanted to do :-)
14:19 sapier I'll check placing too
14:24 sapier that's strange ... for placing logic is exactly opposite, if there's a prediction block is sent, if not, we'll wait for at max 20 seconds
14:24 proller done
14:25 sapier are you done with removing your work by now proller? ;-)
14:26 proller maybe need to remove json lib too
14:26 proller but..
14:26 proller sapier, write small xml replacement please
14:26 sapier nope not my issue
14:38 Calinou joined #minetest-dev
14:39 diemartin joined #minetest-dev
14:39 Megaf joined #minetest-dev
14:46 sfan5 proller: not XML
14:46 sfan5 xml sucks
14:46 LemonLake left #minetest-dev
14:46 proller mtml
14:47 sfan5 how about YAML?
14:48 kahrl isn't YAML = JSON + stuff?
14:52 sfan5 yes
14:58 crazyR_ joined #minetest-dev
14:59 Megaf_ joined #minetest-dev
14:59 sapier I don't see any reason to do any work just because of "proller wants to extinguish his help"
14:59 CraigyDavi` joined #minetest-dev
15:01 proller but json is too bad
15:02 sapier bad ... yes ... bad enough to justify the work? ... no
15:16 sfan5 so.. what about merging https://github.com/minetest/minetest/pull/1461 ?
15:17 sapier did you check it with all those databases?
15:19 proller whats about disabling compression for leveldb
15:19 sapier for what reason?
15:21 sfan5 sapier: yes, I even tested migration
15:21 proller leveldb compress data
15:21 domtron joined #minetest-dev
15:21 proller block->searialize too
15:21 proller why to compress 2 times?
15:22 sapier serialization does compress block?
15:22 sfan5 only node data
15:22 sfan5 nothing else is compressed by ser.
15:22 sfan5 leveldb can still compress things like node mappings
15:23 proller so mt compression  must be disabled when use leveldb
15:24 sfan5 why?
15:25 proller because leveldb will compress anything
15:30 sapier if there's a resonable amount of additional data to nodes that might still be acceptable
15:30 werwerwer joined #minetest-dev
15:32 sfan5 sapier: can we merge #1461 then?
15:35 sapier ok merge it
15:36 * sfan5 yays
15:38 sfan5 k, pushed
15:48 Jordach_ joined #minetest-dev
15:54 zat joined #minetest-dev
16:01 LemonLake joined #minetest-dev
16:03 us`0gb joined #minetest-dev
16:15 hmmmm lol
16:15 hmmmm in a random text file I have "minetest TODOs"
16:15 hmmmm that obviously hasn't been updated for about a year
16:15 sapier just for curiosity what's been on that list? ;-)
16:16 hmmmm "TODO:  Un-fuck proller's getHeat/getHumidity bullshit; define an 'unset' value to use as a placeholder when weather is disabled"
16:16 hmmmm "look into possibility of removing client-side knowledge of heat/humidity"
16:18 sapier guess that's been done
16:19 hmmmm ehm.  I have an entirely different list of personal todos now, namely "merge some initBlockMake tasks into finishBlockMake"  "add a std::set containing the chunk positions currently being generated or queued"
16:19 hmmmm once this moving BS is done I should be able to finally make progress
16:20 hmmmm I am glad Freeminer exists as an outlet for features we don't think fit into minetest or have poor implementations well below standards
16:23 sapier well if fm was lgpl I'd agree but the way it it now it's quite annoying
16:24 hmmmm there are a couple memory leak fixes that are great to backport but for the most part I don't feel like it affects us too much
16:24 hmmmm and again, we can circumvent that problem by doing a clean-room implementation of the same fixes by having one person describe the issue and somebody who hasn't seen freeminer's code fix it
16:25 sapier puuhh ... sounds like a lot of work ... ;-)
16:35 BlockMen joined #minetest-dev
16:37 BlockMen sfan5, https://github.com/minetes​t/minetest_game/issues/273 im fine with. but please not with fencelike drawtype
16:37 hmmmm so anyway I've settled on a bloom filter to store blocks generated in memory
16:38 hmmmm only issue is you can't unset elements, but that's O.K. because you're almost never deleting a block from the database, and if you are, the performance penalty of having to do the actual fetch is worth it
16:39 hmmmm thing is, now I need to compare it to the performance of the various databases doing a query to see if the block is simply present or not
16:39 BlockMen nore, since all other but not you answered: i think a darker steel texture makes it harder to differ between the stone and steel tools.
16:40 BlockMen and if you/all want those darker texture change all steel-ting textures aswell before mergin
16:41 nore hm... hadn't thought about the tools
16:41 kaeza regarding fences: would it be possible to adapt the collision box to fit the node box (and optionally make it so you can't jump over fences?)
16:42 kaeza ?>>1
16:42 nore but anyway, I don't have opinion on dark/light textures being better than the other
16:43 BlockMen kaeza, you can already add a nodebox to def to prevent jumping over it
16:43 kaeza BlockMen, hm?
16:43 BlockMen IIRC PA did that in minitest
16:44 kaeza BlockMen, yes, but the collision is still kinda "full-node"
16:44 kaeza +box
16:44 kaeza i.e. you can't actually go near the fence
16:44 kaeza I was saying something like xyz's xfences
16:45 kaeza (but those are implemented kinda like mesecons wires/technic cables)
16:45 BlockMen kaeza, oh. umm...try out? ;)
16:45 BlockMen maybe it uses the nodebox at all for collision detetction then
16:46 kaeza MT doesn't compile under cygwin :/
16:47 kaeza or rather, it requires a high amount of hackery in the Irrlicht makefiles
16:49 LemonLake joined #minetest-dev
16:58 rubenwardy joined #minetest-dev
16:58 Calinou joined #minetest-dev
17:01 Calinou joined #minetest-dev
17:32 Krock joined #minetest-dev
17:53 crazyR_ did someone create a swim model for minetest?
17:53 crazyR_ i remember it but cnt remember where i saw it
17:54 LemonLake just get lay and rotate it 180
17:56 cheapie joined #minetest-dev
18:13 proller joined #minetest-dev
18:13 troller joined #minetest-dev
18:13 proller__ joined #minetest-dev
18:23 sapier https://github.com/minetest/minetest/pull/1475 is supposed to fix most of the creative node digging lag
18:24 sapier not exactly all as the updated block is still sent after receiving ack for "on wire" block
18:24 Amaz_ joined #minetest-dev
18:41 kaeza joined #minetest-dev
18:58 ShadowNinja I got this message about the launchpad builds, can someone more knowledgable with launchpad fix this?: http://pastebin.ubuntu.com/7785873/
18:59 ShadowNinja It seems like you just have to increment a revision mumber and initiate a re-build.
19:00 Calinou joined #minetest-dev
19:07 kaeza joined #minetest-dev
19:09 Miner_48er joined #minetest-dev
19:59 celeron55 sapier: at least one comment is quite inaccurate
19:59 celeron55 sapier: "make sure client knows this block was updated"
20:00 celeron55 that's not really a useful comment at all
20:00 celeron55 also client->SetBlockUpdated is a bad method name
20:01 celeron55 actually, the method name might be fine, but it needs a comment to describe what it exists for
20:02 celeron55 the comment in where it is used from should say something like "make sure to re-send block to client in case outdated data is still being sent on the wire"
20:03 celeron55 otherwise it's just wtf and nobody will understand why it's there
20:10 sapier ok I'll change the comments
20:11 sapier what about calling the function "MarkBlockUpdated"?
20:12 sapier or better NotifyBlockModified
20:13 Megaf_ [17:12:50] <Megaf_> sfan5; sapier; Can you please make a link that points to the latest Androids builds?
20:13 sapier they're released ;-)
20:13 sapier github releases
20:17 Megaf_ sapier; I mean, something like, http://downloadlink,com/latestx86.apk
20:17 Megaf_ and latestarm.apk
20:18 Megaf_ like the builds for windows here http://minetest.megaf.info/in​dex.php?id=download-minetest
20:19 Megaf_ ^ PenguinDad
20:20 Megaf_ Like this http://sfan5.pf-control.de/minet​est-builds/latest.php?b=minetest
20:20 Megaf_ but for apks
20:37 proller__ joined #minetest-dev
20:52 sapier why?
20:52 sapier there's no newer version
20:52 sapier once there's something usefull I'll build a new version but by now there is none
20:52 LemonLake left #minetest-dev
20:55 sfan5 <BlockMen> sfan5, https://github.com/minetes​t/minetest_game/issues/273 im fine with. but please not with fencelike drawtype
20:55 sfan5 why not?
20:56 VanessaE sfan5: I dunno what BlockMen has in mind but I could see a "jersey wall" type of "fence" being useful perhaps, if made of cobble.
20:56 sfan5 "jersey wall"
20:56 VanessaE http://static.artfagcity.com/wordpress/wp-conte​nt/uploads/2012/05/new_jersey_barrier_2000.jpg
20:56 sfan5 whats that?
20:57 VanessaE it's a type of barrier commonly used to separate two sides of a high-speed motorway
20:57 sfan5 ah
20:57 VanessaE something like this, made of cobble, might make sense perhaps
20:57 VanessaE if the cobble were combined with some kind of mortar in the crafting recipe anyway
20:58 sfan5 what I want is something like those stone things in MC
20:58 proller__ joined #minetest-dev
20:58 VanessaE those stone things?
20:58 sfan5 I don't want a thing this 'heavy' to seperate a walkway from lava..
20:58 sfan5 ..
20:58 sfan5 http://minecraft.gamepedia.com/Cobblestone_Wall
20:58 VanessaE ah
20:58 VanessaE I think the castles mod has something like this
21:04 VanessaE hm, no.  strike that, it doesn't.
21:04 VanessaE still, I like that general idea, but honestly not that form.  it's too medieval imho
21:49 Megaf joined #minetest-dev
22:17 domtron joined #minetest-dev
23:23 domtron joined #minetest-dev

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