Minetest logo

IRC log for #minetest-dev, 2014-03-21

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

All times shown according to UTC.

Time Nick Message
00:01 celeron55 (or something similar that is not based on polling)
00:02 CiaranG Now would be the time for you to point out that I forgot to include the change to doc/lua_api.txt
00:03 CiaranG I thought about adding the event at the same time, but I also thought that an entity that's interested in collsion will be polling for the static information anyway, so you'd just end up giving it the information twice
00:07 CiaranG On the other hand, doing it event-based allows the entity to actual return a response to the collision. But that's a bigger change than this was intended to be.
00:30 EvergreenTree joined #minetest-dev
00:33 CiaranG Ok, fixed the constructor and the crappy squashed name
00:59 salamanderrake joined #minetest-dev
01:26 khonkhortisan joined #minetest-dev
02:11 kaeza joined #minetest-dev
02:29 OldCoder joined #minetest-dev
03:47 ImQ009 joined #minetest-dev
04:09 hmmmm agh crap
04:10 hmmmm ShadowNinja, your ostringstream commit broke negative integer values
04:11 hmmmm i didn't see for myself but i'm willing to bet that'll cause default mapgen v6 settings to screw up hard when saved to map_meta.txt
04:27 SmugLeaf joined #minetest-dev
05:41 nore joined #minetest-dev
06:03 Naked joined #minetest-dev
06:26 darkrose joined #minetest-dev
06:26 darkrose joined #minetest-dev
07:13 SmugLeaf joined #minetest-dev
08:03 ImQ009 joined #minetest-dev
08:09 Weedy joined #minetest-dev
08:09 Weedy joined #minetest-dev
08:16 ShadowNinja Whoops, droped part of the signedness logic.  I'll fix that...
08:18 smoke_fumus joined #minetest-dev
08:28 ShadowNinja This ought to do: http://sprunge.us/UUVZ?diff  Comments?
08:38 RealBadAngel if works then ok
08:56 ShadowNinja Minetest is consistently throwing bad_alloc on startup now.  But now just with that patch...
09:07 darkrose joined #minetest-dev
09:07 darkrose joined #minetest-dev
09:17 ShadowNinja Well, this gets it to run: http://ix.io/bcp/diff  And it seems to work.
09:56 proller joined #minetest-dev
10:04 MichaelRpdx joined #minetest-dev
10:11 Calinou joined #minetest-dev
10:16 khonkhortisan joined #minetest-dev
10:28 proller joined #minetest-dev
10:52 Jordach joined #minetest-dev
11:07 PilzAdam joined #minetest-dev
11:29 Shardvex joined #minetest-dev
11:29 ImQ009 joined #minetest-dev
11:35 restcoser joined #minetest-dev
11:58 Megaf joined #minetest-dev
12:33 iqualfragile joined #minetest-dev
12:36 PenguinDad joined #minetest-dev
12:46 Garmine joined #minetest-dev
12:55 hmmmm joined #minetest-dev
13:03 tomreyn joined #minetest-dev
13:24 Megaf_ joined #minetest-dev
13:39 EvergreenTree joined #minetest-dev
14:12 proller joined #minetest-dev
14:53 Zeitgeist_ joined #minetest-dev
15:25 PenguinDad joined #minetest-dev
15:45 kahrl joined #minetest-dev
15:49 OldCoder joined #minetest-dev
15:50 Sokomine i was able to reproduce the problem with that particular tree twoelk had on vanessas server. saving the tree with the vines, importing it into a fresh map with very limited amount of mods installed, and digging a node triggered the bug
15:50 Sokomine the schem can be found here: http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/invasionofthevines.mts
15:50 Sokomine currently trying to figure out more
15:51 VanessaE file size is about 5 kB
15:51 VanessaE so no complaints about download times :P
16:01 grrk-bzzt joined #minetest-dev
16:01 twoelk joined #minetest-dev
16:07 twoelk hi, regarding the servercrashing tree on VE-Creative I'm pretty sure by now it has something to do with the removing node part in the vines mod
16:07 VanessaE twoelk: check the log.
16:07 VanessaE http://irc.minetest.ru/minet​est-dev/2014-03-21#i_3623135
16:07 twoelk ? which log?
16:08 VanessaE Sokomine beat oy by about 15 mins :)
16:08 VanessaE you*
16:08 Sokomine twoelk: possibly. i was able to reproduce it in a singleplayer world with that tree that gave you all that trouble
16:09 Sokomine after inserting a print statement somewhere, it suddenly worked. now it seems to work even without the print statement
16:09 Sokomine what is quite obvious is that a single dig of a vine may require checking half the tree
16:09 Naked joined #minetest-dev
16:09 twoelk but do the vines still behave strangly?
16:10 twoelk digging a bottom vine should not destroy vines above
16:11 twoelk and digging a block nearby should not affect a vine not attached to the block I interact with
16:11 Sokomine hmm. digging something seems to trigger checks for falling nodes in the nodes around
16:11 VanessaE and since she's doing this in a freshly-created singleplayer world with a .mts file she saved and I made available to her, that means it ain't my map file
16:12 twoelk never said so ;-)
16:12 VanessaE Sokomine: what mods are installed in your test world, aside from vines and I presume moretrees/plants_lib ?
16:12 VanessaE twoelk: I know - I was afraid maybe my map was corrupted, but clearly that isn't the case here.
16:12 twoelk I made a skyblock with 4 trees and lots of vines, same behaviour of the vines there
16:13 twoelk though no crashes
16:13 VanessaE vines mod hasn't been touched in about 5 months, so I doubt it's a bug in that mod
16:13 VanessaE at least not a new bug anyway
16:13 twoelk I have never befor approached those trees, so I can't say
16:14 twoelk I remember though changes of the vines mod while playing on VE-Survival
16:16 Sokomine VanessaE: none relevant i'd say. mostly mods i'm working on
16:17 VanessaE Sokomine: not even the vines mod at this point? O_o
16:17 twoelk where is the group parameter "hanging_node=1" described?
16:17 Sokomine VanessaE: of course the vines mod :-) i tested first without even moretrees
16:17 VanessaE Sokomine: ok
16:18 VanessaE Sokomine: just had to check :)
16:18 Sokomine twoelk: special group defined by the vines i guess
16:18 twoelk cant find it there
16:18 Sokomine yet the result of vines without moretrees and vines with moretrees is diffrent
16:18 Sokomine twoelk: the group is just used. nothing more happens there (or anywhere i could find)
16:19 twoelk it is definitly not described in LuaApi.text
16:19 Sokomine what happens if i dig a vine on the tree: half the tree loses its sideway vines. only those that are attached to leaves or tree trunks keep hanging
16:20 VanessaE Sokomine: maybe because moretrees/plants_lib adds a bunch of leaf decay abms, hence a miniscule cpu overhead - but those do nothing if the decay code doesn't have to actually run.
16:21 GhostDoge joined #minetest-dev
16:22 VanessaE yep, a quick grep shows hanging_node troup is only used within the vines mod, but it doesn't appear to actually be *used* for anything
16:22 VanessaE group*
16:23 twoelk the avoid radius in the spawning code has similar values (3 and 5) to the values I notcied the vines get deleted around the trigger node
16:23 VanessaE I'd call that a coincidence really
16:23 twoelk hopefully
16:25 GhostDoge joined #minetest-dev
16:28 twoelk If adding a print statement between functions and deleting that again fixed the crash problem, maybe something between functions was missing? Can lua functions leak into each other if not seperated properly?
16:28 Sokomine ok...now debug message *and* crash can happen simultaneously. i cheated a bit by not using moretrees in that test world - thus more vines are bound to decay
16:29 twoelk and another theorie proved wrong within seconds
16:31 Sokomine digging a single vine ends up in 4058 checks in that special situation before the stack overflow happens
16:33 twoelk uh?
16:34 VanessaE 4058??
16:34 VanessaE that's impossible
16:34 VanessaE there can't be THAT many vines
16:34 VanessaE even a whole TREE ain't THAT big
16:35 VanessaE (there shouldn't be more than maybe a 10:1 ratio of leaves:vines, at the most, I'd guess)
16:36 Sokomine no, they're not all vines. some are air nodes. those are checked as well
16:41 VanessaE ah
16:41 twoelk to be honest I can't really find the code that deletes vines:willow or vines:side; only the one for the rope
16:42 Sokomine nodeupdate in builtin/falling.lua does check all nodes around the node concerned - with one in each direction, that leads to 9 nodes (3x3x3 cube) beeing checked
16:43 Sokomine and in our case, at least some of these contain vines as well
16:45 twoelk paramtype2 = "wallmounted" so if falling.lua finds no wall it might consider the vine prone to falling?
16:45 Sokomine yes, and in my world, those nodes get removed/fall down
16:46 ShadowNinja nodeupdate_single might be helpfull, but it sounds like it's doing something wrong.
16:46 Sokomine only what is attached to leaves remains. this may not be what the author intended
16:46 Sokomine shadowninja: did you take a look at the sample tree?
16:47 Sokomine twoelk: that also explains why the crash occoured already when you changed a node next to a vine. the vine was the neighbour, and that triggered the update
16:47 ShadowNinja Sokomine: No.  It sounds like this issue is a mod issue, not a engine issue, though.
16:47 twoelk so the 9 node checking triggers an endless cascade
16:48 Sokomine ShadowNinja: ah. hm. yes, in this case it might be eaiser/more useful to fix it in the mod concerned. yet such bugs that are hard to find are a bit problematic
16:49 Sokomine not really endless, but...too large a cascade for the stack to handle in this case
16:49 kahrl why does the recursive call in builtin/falling.lua:185 ignore the delay parameter anyway?
16:50 twoelk so maybe nodeupdate should back out if a certain value is reached?
16:51 kahrl (probably unrelated to the vines issue)
16:51 VanessaE why did this only just start in the past weeks?
16:51 kahrl actually no it probably is
16:51 VanessaE this mod has been in place for....months
16:51 salamanderrake joined #minetest-dev
16:52 twoelk was there a recent change in falling.lua?
16:52 VanessaE beats me
16:52 kahrl git log builtin/falling.lua -> last change 2013-10-01
16:52 ShadowNinja Last change I remember was by me, and long ago.
16:53 Sokomine kahrl: does not look as if the code where the delay would take effect would be called in nodeupdate_single
16:53 ShadowNinja I remember thinking that nodeupdate* looked ugly though.
16:53 VanessaE so maybe this tree just got overgrown enough with vines to actually trigger a latent bug no one found until now?
16:54 twoelk nobody dared to touch a large tree :-D
16:56 Sokomine who knows. perhaps twoelk spent too much time next to it so that the vines had time to thoughly take it over
16:56 twoelk so "hanging_node" mighthave been intended to bridge the gap between "wallmounted" nodes but never really made to work
16:56 Sokomine twoelk: i'd guess so, yes
16:57 proller nodeupdate must be in c++
16:57 Sokomine twoelk: the behaviour of falling_node does not seem to be the intended one for the vines anyway. they ought to be happy as long as the topmost vine can cling to anything. they even grow from top to bottom
16:57 Sokomine proller: perhaps. would have made debugging even worse in this case though
16:58 twoelk so falling.lua has to be convinced to ignore hanging nodes
16:58 proller but it will be 10-100x faster
17:00 Sokomine falling.lua would have to treat hanging nodes differently
17:01 twoelk so if indeed paramtype2 = "wallmounted" triggers the falling, what is the alternative?
17:02 twoelk proller: I wonder if that would also make the crash faster
17:02 proller crash?
17:06 ShadowNinja That would probably mean less Lua -> C and back switches.  So it should be a bit faster.
17:06 proller bit - like your mg speed tests ?
17:06 proller ok, 20x then
17:10 Sokomine perhaps it might be cheapest to let the topmost vine check via abm if the node it's clinging to still exists. if not, it can check how many of its kind hang below and take care of their removal and remove itshelf
17:10 Sokomine or - especially regarding completition of the api - something like neighbour_digged as a callback in the node definition?
17:11 Sokomine that way, perhaps even digged trees mapy propagate their digging state and attached leaves decide to give up
17:13 twoelk another way of decay?
17:14 Sokomine in a way, yes
17:14 Sokomine might trigger the same problem we ran into here though
17:15 Sokomine especially if too many nodes are intrested in the state of their neighbours and too many of them are in one area
17:16 twoelk the checking seems recursive
17:18 twoelk so if I have vines hanging hundreds of nodes from a skyblock, if I kill the bottom most one all hanging ones to all sides dissappear if they are neighbours
17:18 twoelk or crash if there are too many
17:18 Sokomine yes
17:19 Sokomine might be less worse in such a situation - a single long vine affects less nodes than one that conquered a moretrees jungletree
17:20 twoelk I was thinking of curtains of vines
17:21 Sokomine curtains - still 2d. yours had 3d to take over
17:21 twoelk actually I guess this only affects loaded chunks so It might really be a rare situation
17:22 PilzAdam joined #minetest-dev
17:28 twoelk so if "check_attached_node" in falling.lua first checks for "group = hanging_node" it could exclude affecting nodes that are attached to something other than blocktype nodes
17:29 rubenwardy joined #minetest-dev
17:31 Sokomine hmm. supporting hanging nodes as such might be nice; after all they're similar to falling_nodes - they just care about a node at another position than the falling ones
17:32 sapier joined #minetest-dev
17:32 twoelk actually I think this could be usefull in rope-like and curtain-like mods
17:34 Sokomine that's true. there are situations where such a behaviour is very desirable
17:36 Sokomine the vines mod already has a possible solution for the problem - the ropebox. it requires 3 diffrent nodes (top node, undiggable middle part, growing lower end) to achieve it but works pretty well
17:39 twoelk ah but we havn't yet checked a rope with that many nodes in it
17:40 twoelk and the rope delting definitly is meant to be recursive
17:40 twoelk *deleting
17:40 sapier I guess it'll be impossible to make people realize c++ isn't by definition faster then lua but only for some sorts of things .... btw "10x-100x" seems to be quite standard ... can we establish some sort of java is 5-10 times slower then lua pardigm? ;-)
17:41 Sokomine *nod* but it does have an advantage: the rope only goes up and down. far less nodes to be checked than with 3d recursion
17:41 sapier did anyoone try my latest android build?
17:41 twoelk I guess it depends on what you use java for
17:41 twoelk It surely was never intended for 3d games
17:41 sapier twoelk: you're absolutely right ;-) ... depends is always right answer
17:42 sapier well c++ wasn't intended for 3d games too ;-)
17:42 Sokomine sapier: i think in this case the point was about possible overhead if switching back and forth between languages occours
17:43 sapier as a rule of thumb the more often you need to fetch information about map the faster a c++ implementation will be ... but this is only true if you need more then ... well I don't have exact numbers but for what I remember less then around 50 accesses don't really matter
17:44 twoelk so the more players you have the better c++ gets?
17:44 sapier so if you have a call done once a minute looking for 30 map locations you'll be most likely better in pure lua
17:45 sapier player number is not really related to lua calls
17:45 twoelk well if 50players on a server open a protected chest.......
17:45 sapier at least if you don't count the increased base load resulting from more players
17:46 sapier then you have 50 calls if they do it exactly same time
17:46 sapier not relevant
17:46 proller whats about global lua lock?
17:46 twoelk add one and c++ gets better :-D
17:47 sapier its not a lua lock but a server step lock
17:47 rsiska joined #minetest-dev
17:47 proller lua must be locket, even if server will be real multithreaded
17:48 sapier twoelk: if you manage to syncronize 50 human players to open a chest in eyactly same server step I'll agree to you ;-P
17:48 CiaranG That could be easy, depends how long the server step is ;)
17:48 proller mt can have 5-10+ seconds step with 20 players- > no problem ;)
17:49 sapier CiaranG if server step is 5 seconds we don't have to bother about lua processing time ;-)
17:49 twoelk I would bet some complicated mesecon/technic contraption plus some quary modsetc can easily amount to that many calls on a busy server
17:49 sapier no it can't everything above half a second will cause major lag and is result of bugs in mods
17:50 proller 90% from 5s can be lua
17:50 proller ^ with mobf for example ;)
17:50 sapier proller I can write a loop sleeping for 10 seconds in c++ too
17:50 VanessaE all of this doesn't help solve the stack overflow in the falling code though :P
17:50 proller mobf have sleeps?
17:51 proller VanessaE, fixed in FM half year ago ;)
17:51 sapier nope mobf is perfectly fine on default minetest it's freeminer breaking base parameters mobf relies on
17:51 sapier e.g. player movement speed
17:51 VanessaE proller: would be nice if you could contribute that fix back to mt then :P
17:51 proller grab it
17:52 sapier wrong license you have to write a pull request
17:52 proller it was but..
17:53 sapier well back to android port guess noone tested it by now?
17:53 VanessaE sapier: sorry, haven't had time
17:53 twoelk got no android device :-(
17:53 sapier does anyone have an idea about the rail graphics corruption?
17:55 CiaranG Heh, leave that in, my son is fascinated by it. He wants to know where all the rails going up into the sky lead to.
17:55 sapier lol
17:55 CiaranG I'll try the latest on a few devices tomorrow if I get time
17:56 * twoelk is still digesting ..everything above half a second will cause major lag...
17:56 sapier thanks I guess there'll be quite some bugs left to fix prior it's in shape for merge
17:57 sapier don't take the half a second to be a hard limit ... doesn't matter if it's 0.4 or 0.6 ;-)
17:59 sapier hmm tile.cpp isn't the only way to create a texture
18:06 spillz joined #minetest-dev
18:09 spillz @sapier: I tried you android build yesterday on galaxy note 2. startup took crazy long time (nexus 7 didn't have this problem on a previous build) and interact/dig/place objects still sucks (at least in singleplayer) on all my devices. don't you have this problem?
18:10 sapier no I can dig and place quite fine ... what happens for you?
18:12 sapier does it take long time showing the progress bar or somewhere else?
18:14 VanessaE proller: so exactly how did you fix it?
18:15 proller - bad code
18:15 proller + good code
18:15 Sokomine i only remember that i saw shingles (which use raillike drawtype as well) shoot into the sky with an older build from stu as well
18:16 proller ok, not good, just working
18:16 CheapSeth joined #minetest-dev
18:16 Sokomine as far as lag goes: the record may be one particular server. a chat message where the other player replied immediately after reading it took 20 minutes before the answer arrived
18:16 VanessaE proller: and that good code consists of what sort of logic? :P
18:17 proller make world better ;)
18:17 celeron55 spillz: does your galaxy note have an sd card in it while nexus 7 not? those are usually very slow unless a very expensive one and that will make the copying very slow
18:17 celeron55 or do you mean some other part of the startup
18:18 Sokomine hm, startup of new versions of mt on anrdoid always took some patience the fist time
18:18 sapier joined #minetest-dev
18:18 VanessaE I suggested to sokomine just a minute ago, that the code should dump out after a certain put, without erroring/crashing, and set some flag that means "wait, there's more to do", which the server could come back around and examine later (say a few server steps later or something), at which point it could just start up the routine from the beginning, but at a new starting position in the world or something
18:18 celeron55 (on my phone it's not really slow at all)
18:18 VanessaE certain point*
18:18 VanessaE e.g. some reasonable limit of recursion depth
18:18 spillz I have to tap then hold sometimes 10 times before the game will properly accept that I am trying to break stuff
18:19 spillz Re slow start, it's the scanning step. I have sd card, but I though the mt folder was in normal storage
18:19 Sokomine a limit to the recursion depth might be fine
18:19 sfan5 celeron55: some phones also have /sdcard symlinked to internal memory
18:19 sfan5 (like mine)
18:19 spillz slow start is every time not just first
18:20 VanessaE sfan5: my tablet puts its internal flash there.
18:20 celeron55 sfan5: mine too
18:20 Sokomine almost always a crash (especially with an error message nobody understands) is more critical to mt than if a few blocks which ought to drop down don't - if the player cares, he can trigger a new drop-sequence by digging nearby
18:20 celeron55 sfan5: but maybe some don't
18:20 sapier spillz is it possible your touchscreen generates move events on tapping instead of stable tap detection?
18:21 sapier I know about at least on high dpi screen having this problem
18:21 spillz On note 2, sd card is extsd.  maybe note 2 has slow internal storage but it is high end phone
18:21 sfan5 celeron55: the crappy old one I had didn't (have /sdcard -> internal memory)
18:21 sfan5 it also had just about 100MB internal mem
18:21 sfan5 in that case it makes sense to not make apps but everything into the internal mem
18:21 celeron55 having /sdcard that isn't actually an sd card is totally stupid though
18:22 celeron55 it's like the most misleading thing in this world
18:22 spillz @sapier: quite possibly. what are you using for tap detection - android API?
18:23 sfan5 the real sd card is /storage/extSdCard on mine
18:23 sapier celeron55 did you forget about start to shutdown?
18:23 sfan5 specing: you can't use everything besides the android api to get touches (reliably)?
18:23 sfan5 s/?//
18:23 sfan5 damnit
18:23 celeron55 sapier: that's obvious; you start shutting down
18:23 sfan5 spillz: you can't use everything besides the android api to get touches (reliably)
18:24 sapier spillz: tabs are always detected by android api as well as moves are generated but right now any tab moved after touch will be ignored for digging (and placing)
18:24 sapier that could explain your problems
18:24 celeron55 well minetest uses irrlicht, but irrlicht is custom-patched to get the touches from the android api :P
18:24 celeron55 or has that changed?
18:24 spillz @celeron55: Samsung phone, need I say more? (although isn't misleading storage naming pervasive in android)
18:25 sapier irrlicht got most of our early changes in by now
18:25 sfan5 celeron55: irrlicht obviously uses the official android api for touches
18:26 spillz That's what I am wondering - whether you guys have actually checked the android API calls or just relying on irrlicht code to do it correctly.
18:26 sfan5 irrlicht does it correctly
18:26 sapier we did as irrlicht isn't finished by now but we need to handle a few things ourself
18:27 sapier yet that crapy tab thing is done by android
18:27 sapier btw is it tab or tap?
18:27 sfan5 sapier: <random thing> my irrlicht fork already translates touch inputs to mouse events, no need to do that in minetest https://github.com/sfan5/irrlicht-android </random thing>
18:28 ImQ009 joined #minetest-dev
18:28 spillz Think you mean tap?
18:28 Calinou joined #minetest-dev
18:28 sfan5 "tap" I think
18:28 sapier I don't use irrlicht forks
18:28 sfan5 but you're applying a patch to irrlicht
18:28 sfan5 that is almost the same as using a fork
18:28 domtron joined #minetest-dev
18:29 sapier nope my changes are minor and I plan to get them back to irrlicht as soon as possible
18:29 sfan5 my changes are minor too
18:29 sfan5 I just store them in a repo for easier managing
18:29 sapier but they're not separated from irrlicht that's a major issue on rebasing to new irrlicht code
18:30 sapier and I really doubt irrlicht guys will accept translation of touch events to mouse events
18:30 spillz @sapier: "tab moved after touch ignored" does that mean if the move comes in before the tap that you ignore the tap. maybe that's a problem, especially on high DPI screen?
18:31 sfan5 sapier: why?
18:31 sapier because they have touch events they won't throw touch and mouse events onto each other
18:32 sapier no spilz, android api creates unique id's for each touch
18:32 sapier in current implementation if a touch is moved it won't cause a dig or place any longer
18:35 sapier I guess if we want to translate touch events to mouse events we have to do this on our own irrlicht wont do this for us
18:35 sapier that's why I made touchscreengui to be a event translator
18:35 sapier btw does anyone know what eurasiaicon is?
18:36 sapier wait eurasiacon
18:39 kaeza joined #minetest-dev
18:43 sfan5 sapier: google
18:44 sapier doesn't result in any helpful thing (at least for me) ;-P
18:46 spillz sapier: "if a touch is moved" on high DPI phone almost impossible not to move a touch. maybe add a move threshold? but not sure why you need that at all...
18:47 sapier because a moving touch is changing view
18:47 sapier it's annoying to start digging if you just wanna look around ;-)
18:49 spillz Isn't there a measure of the touch strength? strong touch dig, weak touch ignore (user meant to look around)
18:49 sapier I don't think so
18:50 spillz anyway, however you are doing it just won't work. there's always a risk of a little movement when you press your finger down
18:51 spillz so threshold...
18:51 sapier not if you've got a high quality screen ;-) ... but yes I need to find a workaround for buggy screens anyway
18:51 twoelk by now listening to this I guess an extra button soley for digging would be best. This way moving and digging could be combined in a more controllable way
18:51 sapier that's what I wanted to avoid ;-)
18:52 sapier as you should be able to place and dig anywhere on screen (doesn't work due to a bug right now)
18:52 spillz But it works fine as touch on minecraft pocket, survivalcraft, blockstory, ...
18:53 sapier you can only build and dig on crosshair there true?
18:54 twoelk my fingers are too clumsy for such sensetive devices anyway
18:54 sapier we won't be possible to find a control suiteable for every clumsy huge finger person ... but we should try to do best we can ;-)
18:55 twoelk maybe I should take of my gloves?
18:56 sapier don't bother to do so just accept you're one of those we can't fix it for ;-)
18:56 sapier <-- just joking of course ;-)
18:56 spillz Try minecraft pocket or any of the other clones. on mc pe you can build or dig wherever you touch (if in range). Also want you start digging, moving around doesn't stop digging.
18:57 spillz *Want = once
18:57 sapier my tablet doesn't have play store access ... but if they can do it we'll be able to do so too
18:58 spillz Re "not if high quality screen" that's just wrong. Note 2 has one of the finest screen available when it was released.
18:59 spillz The problem is the sensitivity to movement is also extremely high, so you need to filter events you don't want to respond to
19:00 sapier imho filtering events is responsibility of os not application
19:02 spillz gotta work with the tools you have :)
19:02 sapier my tool does work ;-)
19:02 sapier but that's why I want you to test it
19:04 spillz relevant: http://stackoverflow.com/questions/4324362/d​etect-touch-press-vs-long-press-vs-movement
19:06 sapier well I use similar code for other things in mt right now ;-)
19:06 sapier it's not a big deal to add the threshold
19:09 PilzAdam joined #minetest-dev
19:11 spillz joined #minetest-dev
19:16 twoelk stackoverflow?   - oh Android, not Vines :-(
19:19 rubenwardy joined #minetest-dev
19:19 salamanderrake joined #minetest-dev
19:44 sapier joined #minetest-dev
19:56 werwerwer joined #minetest-dev
20:07 sapier touchscreen_threshold in latest binary version is setting for touch threshold, it's set to 20 can those with touch issues try if this is enough?
20:20 nyuszika7h joined #minetest-dev
21:02 penguindad joined #minetest-dev
21:06 PenguinDad joined #minetest-dev
21:28 n joined #minetest-dev
21:28 proller joined #minetest-dev
21:30 EvergreenTree joined #minetest-dev
21:41 spillz joined #minetest-dev
21:41 ShadowNinja sapier: Is there a reason that you chose marshal over string.dump?
21:44 spillz sapier: latest apk works much better, playable now :) will be good when you can touch to choose the node interact with or the node face to attach new node to
21:53 domtron joined #minetest-dev
21:58 spillz joined #minetest-dev
21:59 sapier yes marshal is able to encode functions too
22:00 sapier marshal should only be used in async by now
22:01 spillz joined #minetest-dev
22:03 spillz joined #minetest-dev
22:05 spillz joined #minetest-dev
22:07 spillz joined #minetest-dev
22:07 domtron joined #minetest-dev
22:11 spillz joined #minetest-dev
22:34 ShadowNinja sapier: string.dump(function)
22:35 ShadowNinja I don't mean minetest's dump(tbl), which isn't meant to be machine readable anyways.
22:36 sapier does it work for arbitrary things?
22:36 ShadowNinja Er, I didn't paste that correctly.
22:36 sapier e.g. tables containing functions as well as function pointers?
22:36 ShadowNinja sapier: No, just functions.  minetest.serializa could be extended to use it though.
22:37 ShadowNinja sapier: Don't you only use to for serializing async callables?
22:38 sapier well if you wanna do this you're welcome the less code the less chance for bugs ... but for what I've read getting this done in a performant way is not a simple task
22:38 ShadowNinja It's a builtin Lua function, so it should be just about as fast as it gets.
22:39 sapier you can try it but as I said for what I know marshall code is the only serialization version capable of doing function serialization too
22:40 sapier I assume if it was as simple as using string.dump() others would've used this variant before
22:49 EvergreenTree joined #minetest-dev
22:51 domtron joined #minetest-dev
23:45 SpeedProg joined #minetest-dev

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