| 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/minetest-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/detect-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 |
