Time |
Nick |
Message |
00:01 |
|
tomreyn joined #minetest-dev |
00:18 |
|
BrandonReese joined #minetest-dev |
00:44 |
|
VargaD joined #minetest-dev |
00:48 |
|
salamanderrake joined #minetest-dev |
01:05 |
|
MichaelRpdx joined #minetest-dev |
01:09 |
celeron55 |
iqualfragile_: minetest operates like a retarded brick in that sense, but it does it on the server side which is usually not noticeable :-D |
01:09 |
iqualfragile_ |
important point is: it operates. |
01:14 |
VanessaE |
hah, quote of the day, right there. |
01:18 |
|
domtron joined #minetest-dev |
02:41 |
|
salamanderrake_ joined #minetest-dev |
03:36 |
|
ShadowBot joined #minetest-dev |
03:52 |
VanessaE |
[03-27 23:52] <VE-Minetest> <est31> so when I capture the hash I can gain access? |
03:53 |
VanessaE |
re: sniffing a user's password as he/she logs into a server |
03:54 |
VanessaE |
maybe this is a good time to think about doing some basic ssl or some other encryption of the login part of the protocol |
03:54 |
VanessaE |
I know sapier would love the idea, anyway :) |
04:01 |
VanessaE |
[03-28 00:01] <xxxxxxxxx> Well, I managed to log into a password-protected server using a captured hash. |
04:02 |
VanessaE |
[03-28 00:02] <xxxxxxxx> xxxxx: It's a local server (my survival world, to be exact). |
04:02 |
VanessaE |
[03-28 00:02] <xxxxxxxxx> I used Wireshark to capture the hash (would work for any computer on the same LAN (basically, in the same house)). |
04:03 |
VanessaE |
I think that's enough. |
04:13 |
us`0gb |
Hmm. Assuming a compromised node somewhere along the route ... It wouldn't be limited to LANs. |
04:17 |
|
est31 joined #minetest-dev |
04:17 |
cheapie |
Hi, est31! |
04:17 |
cheapie |
This is where the devs usually are (but they all vanished, for whatever reason). |
04:18 |
cheapie |
...sapier? PilzAdam? celeron55? Anybody home? |
04:50 |
|
kaeza joined #minetest-dev |
05:23 |
|
werwerwer joined #minetest-dev |
05:34 |
|
smoke_fumus|2 joined #minetest-dev |
05:50 |
|
salamanderrake joined #minetest-dev |
06:07 |
|
kahrl joined #minetest-dev |
06:12 |
|
alexxs joined #minetest-dev |
06:52 |
|
grrk-bzzt joined #minetest-dev |
07:20 |
|
darkrose joined #minetest-dev |
07:20 |
|
darkrose joined #minetest-dev |
07:27 |
|
rsiska joined #minetest-dev |
07:43 |
|
Robby joined #minetest-dev |
07:54 |
celeron55 |
VanessaE: that's well known; minetest doesn't even try to be secure; it just hides the password from plain sight |
07:54 |
VanessaE |
just posting that as a reminder |
07:54 |
VanessaE |
seems that folks are beginning to actually consider doing that sorta stuff now is all |
08:08 |
celeron55 |
well, i guess that if someone comes up with a good way to do it, it might be done |
08:23 |
|
est31 left #minetest-dev |
08:25 |
|
est31_ joined #minetest-dev |
08:29 |
est31_ |
Hi for login you could do SCRAM-SHA1 |
08:30 |
est31_ |
and on password reset the client should set the first half of the salt for the stored_key and the server the second half. |
08:30 |
|
ImQ009 joined #minetest-dev |
08:31 |
VanessaE |
better to bring that specific idea up next time sapier is around. |
08:31 |
est31_ |
then you even can store the login safely, as it don't expose the password |
08:32 |
est31_ |
when will sapier be online? |
08:32 |
VanessaE |
I'd expect sometime in the next 6 hours, roughly. |
09:01 |
|
kaeza joined #minetest-dev |
09:17 |
|
est31 joined #minetest-dev |
09:26 |
celeron55 |
est31: any suggestions for lightweight and portable and permissibly licensed (LGPLv2 minimum) libraries? |
09:27 |
est31 |
2+3 easy |
09:27 |
est31 |
1pls wait |
09:39 |
est31 |
GNU SASL library. |
09:40 |
est31 |
no experience with it |
09:40 |
est31 |
but has 1+2+3 |
09:40 |
VanessaE |
celeron55: hah, SASL.... *gets bag of pork rinds* |
09:41 |
est31 |
why that? |
09:45 |
VanessaE |
because as I recall, c55 had a rather sour experience with SASL vs some IRC server(s) about a year or so ago :) |
09:47 |
est31 |
:) |
09:48 |
est31 |
ok don't need to be all sasl algs just SCRAM-SHA1-PLUS |
09:54 |
celeron55 |
SASL isn't wrong; but it's wrong that freenode banned my ISP and required me to use SASL |
09:55 |
celeron55 |
that has nothing to do with the technology itself |
09:55 |
est31 |
ok |
09:56 |
VanessaE |
gah, way to ruin a joke :P |
10:04 |
|
n joined #minetest-dev |
11:04 |
|
kahrl joined #minetest-dev |
11:48 |
|
PilzAdam joined #minetest-dev |
11:52 |
Exio4 |
shouldn't be there a "dev" branch with all the work (the network protocol, and so on)? |
11:54 |
PilzAdam |
Exio4, yes, its called "master" |
11:56 |
celeron55 |
master is the unstable branch, stable is the stable branch; simple |
11:57 |
celeron55 |
then if some very incompatible stuff is developed, a feature branch or a minor version branch can be used |
11:57 |
celeron55 |
(or major) |
11:58 |
celeron55 |
(but the major version has always been 0) |
11:58 |
|
iqualfragile joined #minetest-dev |
12:06 |
|
kaeza joined #minetest-dev |
12:15 |
|
PilzAdam joined #minetest-dev |
12:23 |
|
ImQ009 joined #minetest-dev |
12:40 |
|
Shardvex joined #minetest-dev |
12:50 |
|
PenguinDad joined #minetest-dev |
12:55 |
|
hmmmm joined #minetest-dev |
13:32 |
lanxu |
mitä itse käytät? |
13:32 |
lanxu |
whoops. sorry :) |
13:50 |
|
alexxs joined #minetest-dev |
14:25 |
|
Shardvex joined #minetest-dev |
14:30 |
|
tomreyn joined #minetest-dev |
15:49 |
|
PenguinDad joined #minetest-dev |
16:08 |
|
Jordach joined #minetest-dev |
16:10 |
|
Zeitgeist_ joined #minetest-dev |
16:16 |
|
rsiska joined #minetest-dev |
16:30 |
|
spillz joined #minetest-dev |
17:12 |
|
grrk-bzzt joined #minetest-dev |
17:12 |
|
rubenwardy joined #minetest-dev |
17:27 |
|
sapier joined #minetest-dev |
17:54 |
|
proller joined #minetest-dev |
18:07 |
est31 |
sapier can you read the logs here |
18:09 |
PenguinDad |
I wonder why minetest doesn't do a "VACUUM" statement before closing the SQLite DB? |
18:10 |
sapier |
done |
18:10 |
sapier |
what's in there? |
18:11 |
est31 |
i suggested how to improve the login to a MT server |
18:11 |
est31 |
vanessaE said i should probably speak you |
18:12 |
est31 |
the hash you use is static and can be subject to replay attacks |
18:12 |
sapier |
yes as celeron55 said a well known issue ... if you have suggestions how to improve it you're welcome |
18:13 |
est31 |
You may want SCRAM-SHA1 for login. It's most state of the art. |
18:14 |
sapier |
do you know a free available implementation of it? |
18:14 |
CiaranG |
It would still reveal the password when you did a 'change password'. |
18:14 |
est31 |
GNU SASL library |
18:15 |
est31 |
it depends |
18:15 |
est31 |
SCRAM only specifies the login not the change password |
18:15 |
sapier |
is GNU SASL available on windows too? |
18:15 |
est31 |
its c89 no posix dependency |
18:15 |
|
Calinou joined #minetest-dev |
18:16 |
est31 |
ciaran you could make the client send the stored_key at 'change password' |
18:16 |
celeron55 |
i glanced at it and it seemed fairly good |
18:16 |
celeron55 |
so maybe someone could take an attempt at it |
18:16 |
est31 |
the client only has to make sure that the salt is not used by some other server too |
18:16 |
sapier |
as we're about to do major changes anyway we could do this too |
18:17 |
est31 |
... that can be achieved by the client randomly choosing a part of the salt |
18:18 |
est31 |
(because if it is used by some other server that one can impersonate to the other) |
18:18 |
sapier |
I didn't read the specs by now but whatever we do a password musn't be client specific ;-) |
18:19 |
est31 |
how do you mean that? |
18:19 |
sapier |
no data stored on client may be involved |
18:20 |
sapier |
next question protect login only or do full encrypted communication? |
18:21 |
celeron55 |
sasl doesn't care about encryption (except that it kind of recommends it on top) |
18:21 |
sapier |
I'm for protecting password in first step only |
18:21 |
celeron55 |
as far as i understand |
18:21 |
est31 |
sasl doesnt care. |
18:22 |
est31 |
but: scram-*-plus has channel binding |
18:22 |
est31 |
that can be used to authenticate a servers certificate without CA. |
18:23 |
est31 |
so that it is easy to set up encryption for people running servers |
18:24 |
celeron55 |
do you happen to know a good library for encryption then? i guess gnutls is one |
18:24 |
est31 |
sry idk |
18:24 |
sapier |
I'm not thinking about servers and pc clients right now but about android clients |
18:25 |
sapier |
without hardware encryption support I don't think android clients will be able to handle the additional encryption load |
18:25 |
est31 |
how much traffic |
18:25 |
celeron55 |
but encryption isn't needed for now |
18:25 |
celeron55 |
also, the traffic is very small and android uses HTTPS connections all the time just fine |
18:26 |
celeron55 |
it can't be a problem even if it's done some day |
18:27 |
celeron55 |
the only request for encryption that i have seen has been by a chinese guy for the chat |
18:27 |
CiaranG |
Important stuff. The last thing you'd want is a malicious network sniffer seeing that you'd dug the node at 132,56,216 |
18:27 |
sapier |
you greatly underestimate traffic and performance impact of encryption ... it doesn't matter if a webpage everyone expects to be shown after 20 seconds takes 21 seconds but if our packets take 100 instead of 10 ms we've got a problem |
18:27 |
CiaranG |
Just encrypting chat might make sense |
18:28 |
sapier |
all or nothing ciaranG |
18:28 |
celeron55 |
well, in certain countries it certainly makes sense |
18:28 |
proller |
minetest - game with <1000 active users, GAME, not bank |
18:28 |
CiaranG |
sapier: all or nothing because? |
18:29 |
sapier |
because it's crap to add encryption in 50 locations instead of 1 |
18:29 |
sapier |
if we do encryption it should be done at lower protocol level |
18:29 |
VanessaE |
how difficult is it to detect what hardware support there is on a platform and, if suitable support is found, to use it (and if not, stick with the plain protocol)? |
18:30 |
celeron55 |
well, encryption would just require adding a new packet in the protocol that encrypts the stuff it encrypts |
18:30 |
CiaranG |
Seems more crap to encrypt 50 things that don't need encrypting instead of 1 |
18:30 |
proller |
all issues except chat security already fixed ? |
18:30 |
celeron55 |
and then it's really quite trivial to just do that for chat packets |
18:30 |
celeron55 |
but i agree with proller that it's unnecessary |
18:30 |
sapier |
no it's not do you wanna authenticate any single packet? |
18:31 |
CiaranG |
You would simply encrypt the payload of chat message packets |
18:31 |
celeron55 |
no? |
18:31 |
celeron55 |
it's certainly possible to only require authenticatiton for chat packets |
18:31 |
sapier |
either you create a encrypted communication then you can send all data through it or not then encryption is somehow useless |
18:31 |
celeron55 |
-t |
18:32 |
sapier |
do you wanna ask user for his password on each chat message? ;-) |
18:32 |
CiaranG |
!? |
18:32 |
sapier |
encryption without authentication is useless as you're prone to man in middle attacks |
18:33 |
celeron55 |
what the fuck now |
18:33 |
celeron55 |
you can think of the chat as a separate encrypted connection if you want |
18:33 |
sapier |
if we wanna do encryption we need to create a session on login and keep it alive for as long a s a user is logged in |
18:33 |
* proller |
faceplam |
18:33 |
celeron55 |
sapier: yes, so? |
18:34 |
celeron55 |
how does doing it only for the chat make it impossible? in no way whatsoever |
18:34 |
CiaranG |
You just need the client and server to negotiate a key on login, and use that for the rest of the session |
18:34 |
celeron55 |
let's stop this useless discussion anyway |
18:34 |
sapier |
so chat is encrypted but stealing inventory is not a issue? |
18:34 |
proller |
dont forget check client signed certificates for chatting in game |
18:34 |
celeron55 |
yes, that was the idea |
18:34 |
celeron55 |
you can't really end up in jail for moving items in minetest |
18:35 |
celeron55 |
but you can by chatting about politics |
18:35 |
VanessaE |
proller: you jest, but as I understand a number of other games use exactly that method for logging in. signed certs. |
18:35 |
sapier |
well of course this can be done but I thought we're a game not a chat client for noth korea |
18:35 |
proller |
VanessaE, this games use real money? |
18:35 |
VanessaE |
proller: not all. |
18:36 |
sapier |
Imho protecting the users password is best we can do right now encryption ... nice to have but for chat only isn't sane to me |
18:37 |
VanessaE |
hell I use a signed cert to authenticate to IRC/services, but both c55's and sapier's points stand. |
18:39 |
sapier |
crypto is always about making it more expensive to break data but it's useless to upgrade a stable wooden front door to a reinforced steel door if backdor is paper |
18:40 |
celeron55 |
there's no backdoor to listening to minetest chat if the client and server refuse to transfer unencrypted unauthenticated chat messages |
18:41 |
celeron55 |
well except if those endpoints run other software or addons that have weaknesses, but that always applies |
18:42 |
|
cheapie joined #minetest-dev |
18:43 |
celeron55 |
it can cause some weird situations for the user if someone does a man-in-the-middle attack for the unencrypted data and the chat stays encrypted and going to the right place though |
18:43 |
celeron55 |
"i can't read the chat, write it on this sign" lol |
18:43 |
CiaranG |
I know. Remove the chat packets and encode the messages as movements of different sized stacks of cobblestone in and out of the inventory. 41 cobblestone=A, 42 cobblestone=B, etc. |
18:44 |
CiaranG |
desert stone for lower case. |
18:44 |
sapier |
I'm sorry but I don't understand why chat is more important then our game data |
18:46 |
celeron55 |
i'm all in for encrypting everything if encryption is used though |
18:47 |
sapier |
me too but I fear we can burry android client prior even finishing it if we do so |
18:48 |
celeron55 |
lol, this encryption is not going to happen in a long time |
18:48 |
VanessaE |
sapier, honestly I think the renderer is gonna be FAR worse for the android client's CPU than the encryption would be |
18:48 |
celeron55 |
that's why i said a few screenfulls of text back that this shouldn't be discussed further |
18:48 |
sapier |
btw sasl seems to be a replacement for our current low level protocol if we choose to use it |
18:51 |
sapier |
what do you think about a more simple way to prevent replay attacks, server sends random salt to client, client hashes it's hash with salt and sends back to server .... or did I miss something? |
18:56 |
celeron55 |
http://tools.ietf.org/html/rfc5802#section-5 |
18:56 |
celeron55 |
SCRAM-SHA1 is quite like that |
18:56 |
celeron55 |
somewhat more complicated for whatever reason |
18:56 |
kahrl |
a MITM could obtain a one-time access code at least |
18:56 |
kahrl |
(but since the protocol isn't encrypted anyway, it doesn't matter that much) |
18:57 |
sapier |
yes this way doesn't prevent mitm attacks |
18:57 |
sapier |
it's only safe against replay |
19:02 |
sapier |
I guess I can add the simple variant I suggested within a couple of hours, but as it's just a first thought this might be completely useless if I missed some way to break it |
19:03 |
kahrl |
well the first rule of crypto is don't roll your own |
19:04 |
kahrl |
although in this case, any crypto would be strictly an improvement |
19:07 |
kahrl |
another practical question, regardless of the new auth mechanism: how do you intend to send the initial password hash if the user is connecting to a server for the first time? |
19:10 |
|
e1z0 joined #minetest-dev |
19:11 |
est31 |
sapier kahrls comment is right: no experimenting |
19:12 |
est31 |
for example, SCRAM also does PBKDF2 several (as in 4096) times |
19:12 |
est31 |
hash functions were invented to be fast not to be slow. bad you need the opposite for passwords |
19:14 |
|
BrandonReese joined #minetest-dev |
19:15 |
est31 |
kahrl that password hash (storedKey) needs to be sent in plain text (or via encryption channel). |
19:18 |
est31 |
important thing is that the server does never get the pw itself, and the salt is not equal to the one from another server |
19:18 |
celeron55 |
it can be a simple hash to begin with so that it never goes in completely plain text |
19:18 |
est31 |
heard of rainbow tables? |
19:19 |
kahrl |
est31: a problem would be that any server could claim that the player is new and needs to send the storedKey, and be able to launch replay attacks afterwards |
19:19 |
kahrl |
but this is MITM territory again |
19:19 |
sapier |
it's either experiment or not do it anytime soon |
19:19 |
celeron55 |
that's what they can do always anyway unless you authenticate them, and even then if you inadvertedly trust them |
19:20 |
celeron55 |
:P |
19:20 |
kahrl |
oh, I missed the thing about the salt |
19:20 |
sapier |
if we wanna have a secure solution we need to use certificates and tls |
19:21 |
sapier |
everything else is (more or less) unsafe |
19:22 |
celeron55 |
does there exist tls over udp for unreliable data? 8) |
19:22 |
sapier |
nope |
19:22 |
kahrl |
one time pad is safe too :D |
19:23 |
sapier |
kahrl I take this as volonteering to manually distribute millions of pads to each user ? |
19:23 |
sapier |
;-) |
19:23 |
kahrl |
sure, we could sell OTP key books |
19:23 |
kahrl |
every client-server pair needs one! |
19:24 |
sapier |
:-) lets get serious again, what we can do quite quick is some custom thing. this isn't secure in more precise way but it'll make spoofing harder |
19:24 |
est31 |
... i think tls over udp can be reached with DTLS ... |
19:24 |
celeron55 |
oh so it exists |
19:25 |
celeron55 |
that's cool 8) |
19:25 |
celeron55 |
it's even implemented by gnutls and others |
19:25 |
cheapie |
This reminds me of something: <est31> ... i think tls over udp can be reached with DTLS ... |
19:25 |
cheapie |
Why does MT even use UDP in the first place? |
19:25 |
est31 |
what? |
19:26 |
cheapie |
Did the authors of TCP kill celeron55's dad or something? |
19:26 |
celeron55 |
it actually uses UDP because i wanted to try making a protocol based on UDP, and then you guys voluntarily started to use the end result |
19:26 |
sapier |
because you don't need to retransmit a clients position of 10 seconds ago if you already sent the new one |
19:26 |
celeron55 |
but it allows sending positions with not causing extra lag in packet loss |
19:27 |
sapier |
same for entties and other moving things |
19:27 |
cheapie |
OK, so what about things like inventory moves? |
19:27 |
sapier |
we've got a reliability support uppon udp |
19:28 |
sapier |
yes all of it already exists in other protocols |
19:28 |
sapier |
no need to discuss this again ... we're already trying to find another protocol but by now everyone s quick in suggesting new ones but once evaluation starts same ppl beeing most loud ones demanding a change suddenly are very quiet |
19:30 |
sapier |
obviously just now another requirement to our new protocol was added ... authentication and encryption support |
19:31 |
|
tomasbrod joined #minetest-dev |
19:32 |
sapier |
yet ... can someone please test the android port? I'd prefere to complete one task prior starting a new (huge) one |
19:34 |
proller |
whats is new ? |
19:34 |
tomasbrod |
If you dont mind me being noob, sapier, I would test it. |
19:35 |
sapier |
noobs are welcome as they're not blind to the obvious things like developers usually are |
19:35 |
|
e1z0 joined #minetest-dev |
19:35 |
sapier |
http://animalsmod.comuf.com/downloads/Minetest-debug.apk this is to test |
19:36 |
tomasbrod |
Ok, see you later. |
19:37 |
|
domtron joined #minetest-dev |
20:00 |
|
iqualfragile_ joined #minetest-dev |
20:31 |
|
Guest94087 joined #minetest-dev |
20:37 |
|
spillz joined #minetest-dev |
20:38 |
|
NakedFury joined #minetest-dev |
20:39 |
spillz |
sapier: apk issues on galaxy note 2 (some of these will be familiar)... 1. very difficult to place blocks/items (threshold issue again?) 2. missing inventory textures for many blocks |
20:39 |
sapier |
did you try to change the threshold in settings? |
20:40 |
spillz |
digging works fine, only placement. is there a separate threshold for each? |
20:41 |
sapier |
no it's just doubleclick for placing |
20:41 |
sapier |
doubletab |
20:41 |
sapier |
wait ... |
20:41 |
spillz |
3. Top row icons screen placement is not aligned with touch (have to touch below where they appear) |
20:41 |
sapier |
maybe the doubletab detection still uses a hardcoded value |
20:42 |
sapier |
ok how do you make them appear? |
20:44 |
sapier |
doubletabdetection is missing the threshold, I'm adding it |
20:44 |
spillz |
What appear? |
20:44 |
celeron55 |
why are the items at the bottom so hard to tap |
20:44 |
sapier |
the top row icons? |
20:44 |
celeron55 |
i've tried multiple times and usually nothing happens |
20:44 |
celeron55 |
more often it places a block or does something else |
20:45 |
sapier |
I don't know |
20:45 |
celeron55 |
oh wait what |
20:45 |
celeron55 |
it picks the top ones when touching the bottom ones |
20:45 |
celeron55 |
and the bottom ones cannot be selected |
20:45 |
spillz |
They appear but to activate them i have to click the bottom row items. I can't activate bottom row at all because presumably the touch area is off the screen |
20:46 |
spillz |
sapier: I didn't realize that it was double click to place. now that works but is super laggy |
20:46 |
sapier |
ok please describe as precise as possible as on my tablet it's just single row |
20:46 |
celeron55 |
it's on two rows |
20:46 |
sapier |
yes lag is a big issue I don't know how to fix it by now |
20:46 |
celeron55 |
four on the top, four on the bottotm |
20:46 |
celeron55 |
like an inventory grid |
20:47 |
celeron55 |
-t |
20:47 |
spillz |
Same as celeron55.... I have two rows of 4 inventory items |
20:47 |
sapier |
yes I added this dependent on screen dpi |
20:47 |
celeron55 |
well what's unclear then? |
20:47 |
sapier |
but I could only test it on pc client with window size and there it works :-( |
20:47 |
celeron55 |
tapping the bottom ones selects the one at the top row |
20:47 |
celeron55 |
tapping the top ones does not modify selection |
20:48 |
sapier |
ok I'm gonna try to find out why this happens :-) |
20:48 |
celeron55 |
is the walking movement going to be improved sometime? |
20:48 |
celeron55 |
currently you have to raise your finger from the screen to press another button |
20:48 |
celeron55 |
it should work so that you can slide the finger onto another buttotn |
20:48 |
celeron55 |
-t (fucking t) |
20:49 |
celeron55 |
(how is that t even possible, this keyboard must be broken) |
20:49 |
sapier |
for movement buttons this should work (as long as you stay at buttons) |
20:49 |
sapier |
need to fix the bug when leaving the movement button area |
20:49 |
celeron55 |
oh, apparently it does |
20:49 |
celeron55 |
but usually i want to move from right to backwards |
20:50 |
celeron55 |
and then it doesn't |
20:50 |
celeron55 |
or, well... occasionally does, occasionally doesn't |
20:50 |
sapier |
yes found out some minutes ago too ... in this case you temporary slide above a not button |
20:51 |
celeron55 |
and then! the inventory cubes are completely broken |
20:51 |
celeron55 |
i think spillz mentioned that too |
20:51 |
sapier |
ok :-) some work to do |
20:51 |
celeron55 |
i guess they could be simply disabled, MT can just use the top face with... umm.. is there a setting for that? |
20:51 |
spillz |
4. I still have that awful startup lag (this phone is snappy for everything else) and maybe that explains the block placement lag (bad write speed = SQL performance) |
20:52 |
sapier |
sorry spillz but it's already leveldb on android |
20:53 |
spillz |
sapier: either way it's storage access speed affecting with db access? |
20:53 |
sapier |
possible |
20:53 |
celeron55 |
apparently there isn't a setting for that |
20:55 |
spillz |
btw, double click to place/use kinda sucks usability wise... twice the arthritis... |
20:55 |
sapier |
better ideas? |
20:55 |
spillz |
none that will make your life easier |
20:56 |
sapier |
if they are better that's not a problem ;-P |
20:57 |
celeron55 |
i'd ask for a turn sensitivity slider |
20:57 |
celeron55 |
or whatever way to configure it |
20:57 |
celeron55 |
it's way too fast for this 4.5" screen |
20:57 |
sapier |
it's configured with mouse sensitivity |
20:58 |
spillz |
You really should try out some of the competition... bottom line finger!=mouse. should be able to touch anywhere on screen to use/place active item |
20:58 |
sapier |
what about adding a dropdown similar to threshold |
20:58 |
celeron55 |
oh, random stuff: you can't quit the "change keys" menu |
20:58 |
celeron55 |
and if you press back there, minetest quits completely |
20:58 |
celeron55 |
do you even test anything yourself 8) |
20:58 |
sapier |
oops |
20:59 |
sapier |
yes but not any single feature ;-) |
20:59 |
sapier |
and I didn't even ever use key change menu on pc ;-) |
21:00 |
celeron55 |
oh wtf, double tapping a main menu tab will make minetest quit |
21:00 |
celeron55 |
how is this possible |
21:00 |
sapier |
double tab (outside of menu) to close a formspec |
21:00 |
celeron55 |
oh that explains |
21:00 |
spillz |
Would be nice to have gui controls for draw distance (and tie chunk loading distance to that too) |
21:01 |
sapier |
wait it's getting a little bit much :-) can we add it to the issues gist post |
21:02 |
sapier |
https://gist.github.com/sapier/9745980 |
21:02 |
spillz |
personally would rather play at 25 fps with decent draw distance than the <30 nodes at 40 to 50 fps the game defaults to now |
21:02 |
celeron55 |
the movement really should be a joystick-style thing where you can switch directly from left to right and forward to backward |
21:02 |
celeron55 |
currently when you switch from right to left, you move forward in the middle which is just crap |
21:03 |
VanessaE |
sapier: toldya. :P |
21:03 |
celeron55 |
and you should be able to rest your finger there without the player moving |
21:03 |
celeron55 |
then you might be able to keep the device in your hand a bit more comfortably |
21:03 |
celeron55 |
oh well, not sure of course |
21:04 |
spillz |
sounds like celeron55 wants survival craft's default controls |
21:04 |
celeron55 |
this might be the worst ide aever |
21:04 |
celeron55 |
idea ever* |
21:04 |
celeron55 |
spillz: well, they work; what can i say |
21:04 |
sapier |
well now with double line hotbar the joystick may work but for lots of screens it's a huge waste of screen |
21:04 |
celeron55 |
does someone *like* the current movement buttons? |
21:05 |
sapier |
well at least I prefere them to the previous cross wich did use 1/3 of my screen |
21:06 |
sapier |
it's hard to design controls usable at different screensizes, if you make em to small they're unusable at high dpi+ small screens |
21:07 |
sapier |
hmm well ... as I now have dpi support this may be solvable |
21:07 |
ShadowNinja |
The current buttons are O.K. But I'd prefer a joystick-like thing too. |
21:07 |
celeron55 |
i'm pretty sure placing should just happen with single tap |
21:07 |
sapier |
but I need ppl with different screens to test as I don't have different devices |
21:07 |
sapier |
how do you wanna dig celeron? |
21:07 |
sapier |
and view? |
21:08 |
ShadowNinja |
Ditto on what celeron55 said. Hold to dig/look. |
21:08 |
sapier |
hmm ok dig place decision could be time of pressing down |
21:09 |
sapier |
but you're gonna place a node anytime you accidently touch the screen |
21:09 |
spillz |
hold to dig, slide around anywhere to view. The move buttons don't bother me all that much. torn whether jump should be on left or right thumb |
21:09 |
spillz |
Press once to placr |
21:09 |
spillz |
hold to use items like carts |
21:09 |
spillz |
tap mob to attack |
21:10 |
spillz |
Press once to placr.. meant tap once to place |
21:10 |
spillz |
Doesn't happen that often in my experience |
21:10 |
spillz |
and I am pretty clumsy |
21:10 |
sapier |
I already understood this but I'm not sure if this will not cause a lot of accidentally placed nodes |
21:10 |
VanessaE |
why can't there be a button to explicitly place the wielded object and another to dig, any other touch on the screen is move/look/use? |
21:10 |
celeron55 |
what if placing worked so that it places if you hold the right thumb on the screen and tap with the left? |
21:11 |
celeron55 |
of course double tapping could be enabled at the same time for single-finger operation |
21:11 |
sapier |
some sort of modifyer key |
21:11 |
ShadowNinja |
celeron55: That's even more clumsy and confusing than double-tapping. |
21:11 |
VanessaE |
why overload the screen gestures? use a button damn it! |
21:12 |
VanessaE |
stop overcomplicating it |
21:12 |
sapier |
buttons are ugly |
21:12 |
VanessaE |
so? |
21:12 |
VanessaE |
the whole GAME is ugly if you get right down to it :P |
21:12 |
VanessaE |
since when did that stop the gameplay from being good? |
21:12 |
VanessaE |
usability trumps appearance. |
21:12 |
sapier |
the button can't be where you place the nodes so you always have to move away from where you're building |
21:12 |
ShadowNinja |
VanessaE: A button means that you need to use the cursor thing at the center. And it's hard to use. |
21:13 |
celeron55 |
well actually, i would like to place nodes to where the cursor is |
21:13 |
celeron55 |
it's hard to place nodes when your thumb is larger than the position where you want it on the screen |
21:13 |
sapier |
you can already do this celeron |
21:13 |
celeron55 |
and you need to tap over the position |
21:13 |
VanessaE |
placing/digging where the cursor is makes more sense to me but on a tablet that IS kinda hard to do |
21:13 |
celeron55 |
but of course people would usually use this on tablets and not 4.5" phones so that doesn't apply there |
21:13 |
sapier |
hope it works (touch targeting) |
21:14 |
ShadowNinja |
I'd like to be able to place and dig anywhere on screen, turning to point at something is a lot harder than just looking in that general direction. |
21:14 |
spillz |
I think minecraft pe gives the player an option. split controls that use conventional mouse cursor and buttons, and touch controls that let the user touch on screen where to place |
21:14 |
sapier |
me too it's quite handy to place a line of nodes just by moving on screen |
21:14 |
VanessaE |
spillz: +100000 |
21:15 |
sapier |
guys I already have that setting ... could you please try it ;-P |
21:16 |
sapier |
"Touch free target" ... reenables crosshair and makes it behave same way as on pc ;-P |
21:17 |
sapier |
ok not "Touch free target" enables the crosshair ... does anyone have an idea for a better name of that setting? |
21:17 |
VanessaE |
sapier: "Aim to Place" or "Aim-and-place" |
21:18 |
sapier |
i wouldn't understand that way of calling it too |
21:18 |
VanessaE |
well you use a crosshairs in a shooting weapon to aid in aiming that weapon. |
21:18 |
VanessaE |
but in this case you are doing it to aid in placing a block. |
21:19 |
sapier |
What about just "Enable crosshair" ? |
21:19 |
VanessaE |
naw |
21:19 |
VanessaE |
"What's a crosshair"? |
21:19 |
VanessaE |
etc. |
21:19 |
VanessaE |
remember, you're dealing with noobs who barely know how to turn their tablets on :P |
21:20 |
sapier |
we've got only 2-3 words so we can't write the whole story from the begining some billion years ago there ;-P |
21:23 |
VanessaE |
my point is, |
21:24 |
VanessaE |
describe WHAT it does |
21:24 |
VanessaE |
not what it IS. :) |
21:24 |
|
domtron_ joined #minetest-dev |
21:24 |
sapier |
well it disables the crosshair ;-P |
21:24 |
VanessaE |
smartass :P |
21:25 |
|
_BrandonReese joined #minetest-dev |
21:25 |
VanessaE |
think of it this way... |
21:25 |
VanessaE |
you know those cheapo cameras you can buy for like $USD 20 or so? |
21:25 |
sapier |
no |
21:25 |
VanessaE |
you just aim then and click the shutter and that's it? |
21:26 |
VanessaE |
you know, those disposable ones you buy at the petrol station before you go on a long trip? |
21:26 |
sapier |
actually I don't care how that thing is called as long as there are at least 2 people who think the new name is good ;-) |
21:26 |
VanessaE |
they're among the class of devices we call "Point and Shoot". |
21:28 |
VanessaE |
at the risk of two bad puns in a row, my point is that you need to aim for terms that the average idiot is going to understand, because people don't like to experiment. |
21:29 |
VanessaE |
people think they'll break stuff when they do. |
21:29 |
VanessaE |
hell my mom used to think her computer, I shit you not, would get "confused" if you clicked around too fast. and she was far from stupid. |
21:30 |
sapier |
but "point and shoot" wouldn't be reasonable too |
21:30 |
sapier |
at least to me |
21:30 |
VanessaE |
"point and place" would work better :) |
21:31 |
VanessaE |
but I wasn't suggesting "point and shoot" anyway |
21:31 |
VanessaE |
just giving you an example of how we use such terms |
21:32 |
sapier |
what about "Touch to place" as name for the non crosshair mode? |
21:32 |
VanessaE |
yes |
21:32 |
VanessaE |
that would be good I think |
21:32 |
ShadowNinja |
You still touch in crosshair mode. |
21:33 |
VanessaE |
tap to place? |
21:33 |
sapier |
same |
21:33 |
ShadowNinja |
"Point to place" or "Crosshair mode". |
21:33 |
sapier |
you don't place by pointing at it too ;-P |
21:33 |
sapier |
you still have to tap |
21:33 |
VanessaE |
ShadowNinja: that's why I used "and" instead of "to". a conjunction is needed if you want to use "point" here |
21:34 |
VanessaE |
oh G*d, I sound like my grade school english teacher. :P |
21:35 |
sapier |
I'm gonna fix the other bugs now hope someone found a commonly accepted naming till I've finished |
21:35 |
celeron55 |
your teacher would be proud of you! |
21:35 |
VanessaE |
celeron55: if my teachers saw how I butcher the english language in some other venues, they'd shoot me, in turn. :P |
21:39 |
|
tomasbrod left #minetest-dev |
21:43 |
|
proller joined #minetest-dev |
21:45 |
spillz |
Instead of a phrase, having a screen for controls with a picture for each control type. Also for the Crosshair controls, maybe you want to have a look around area above below some dig/use/place buttons on the right thumb side |
21:45 |
spillz |
*How about having... |
21:47 |
sapier |
good idea but I'd consider this as not crucial for first android version |
22:03 |
ShadowNinja |
Pushing in a minute: http://ix.io/bjr |
22:05 |
sapier |
are you sure this is equivalent? |
22:07 |
sapier |
and why do you rename member variables to that crazy non m_ notation noone can see it's a class member without ide support? |
22:08 |
sapier |
ShadowNinja: imho this change is way to big for a 1 minute announcement, please create a pull request for review |
22:10 |
|
domtron_ joined #minetest-dev |
22:15 |
|
spillz joined #minetest-dev |
22:17 |
sapier |
ShadowNinja: how did getBlocksOnZ exit before? |
22:17 |
ShadowNinja |
sapier: Hmmm? This is the mapper, not the engine, so we don't have to be so strict about commits. And I removed hungarian notation because the coding style recommends not using it. And what do you mean by equivalent? The main change is that LevelDB is 20+x faster. |
22:17 |
sapier |
ahh by break |
22:18 |
celeron55 |
this is for the new https://github.com/minetest/minetestmapper |
22:18 |
celeron55 |
sfan5 and ShadowNinja are pretty much free to do what they want with it |
22:18 |
sapier |
oh :-) ok how am I supposed to see this is mapper only ;-) |
22:19 |
celeron55 |
by following #minetest and every IRC channel remotely related to minetest, i guess |
22:19 |
celeron55 |
and forum and github and... |
22:19 |
celeron55 |
i.e. in no way |
22:20 |
sapier |
well as it's mapper only a pull request is obviously nonsense ;-) |
22:20 |
ShadowNinja |
Hmmm, I guess it wasn't obvious. |
22:20 |
ShadowNinja |
Minetest's database stuff is different, but you wouldn't know unless you've looked. |
22:20 |
sapier |
no, especially as database code isn't the part of minetest I know very well ;-) |
22:21 |
celeron55 |
i immediately knew because the filename had "db-" instead of minetest's "database-" :P |
22:21 |
ShadowNinja |
Last commit gives it away though. |
22:21 |
sapier |
you've written the db code celeron ;-) |
22:21 |
celeron55 |
i haven't |
22:21 |
celeron55 |
i have written none of it |
22:21 |
sapier |
thought you've been at least involved in sqlite code? |
22:21 |
celeron55 |
no |
22:21 |
celeron55 |
it was contributed initially completely |
22:22 |
celeron55 |
by a friend of the admin of the largest server at the time |
22:22 |
sapier |
ok ok :-) doesn't change the fact I don't have any idea how db code of minetest looks like ;-) |
22:22 |
sapier |
that part did work quite well by now |
22:23 |
sapier |
I don't have any idea why that damn multiline hotbar behaves that crazy |
22:25 |
|
domtron_ joined #minetest-dev |
22:27 |
sapier |
wait ... |
22:33 |
|
domtron_ joined #minetest-dev |
22:37 |
|
domtron__ joined #minetest-dev |
22:43 |
sapier |
celeron55 I think I found the double line hotbar issue but I can't test it |
22:43 |
sapier |
I already uploaded the new version |
22:44 |
Sokomine |
it might be a good idea to mark "lightwight" minetest servers in the public list somehow. the android client will be more successful connecting to one of these |
22:47 |
sapier |
there's no way to decide this aitomaticaly |
22:49 |
Sokomine |
hm. it might be possible to check how large the amount of media data the server offers is. might still be too troublesome. yet...with the normal server list, connecting to a public server will seldom work on the first attempt |
22:49 |
|
spillz joined #minetest-dev |
22:49 |
spillz |
sapier: bottom row now works correctly, top row not at all. |
22:49 |
sapier |
hmm |
22:49 |
sapier |
very strange |
22:50 |
sapier |
so there are two bugs |
22:51 |
sapier |
argh ... a very silly one |
22:56 |
sapier |
spillz: uploaded new version |
23:02 |
spillz |
working. now missing textures |
23:02 |
sapier |
a new bug? |
23:02 |
spillz |
Also all of the interactive elements are kind of big |
23:03 |
sapier |
welll size of elements is quite a matter of personal preference |
23:03 |
sapier |
and dpi and device |
23:03 |
spillz |
Not new. I mentioned earlier that many inventory items don't have textures |
23:03 |
sapier |
yes you did so the old bug ... I believe this is a ogles or irrlicht issue so I can't do very much about it atm |
23:04 |
sapier |
but any suggestion is welcome |
23:05 |
celeron55 |
just comment out itemdef.cppp:436-437 |
23:05 |
spillz |
Re size - maybe just because of my phablet. 5.5 inch screen 1280x720 or something. All buttons seem too big. |
23:05 |
celeron55 |
or make irrlicht not report that it supports render target textures |
23:06 |
celeron55 |
because they obviously are broken |
23:06 |
sapier |
could this be device dependent like the npot2 issue? |
23:06 |
celeron55 |
or add return NULL; to tile.cpp:830 |
23:07 |
celeron55 |
no, it's creating 64^2 textures |
23:08 |
celeron55 |
or well maybe it is... but survivalcraft and whatever had it disabled too |
23:08 |
celeron55 |
so they didn't find it working either |
23:12 |
sapier |
hmm is there something simple to test? |
23:13 |
Sokomine |
sapier: the 8 inventory slots at the bottom are now too big on my device (rather small phone). also the inventory cubes seem to stand on their head (compared to the normal client) |
23:14 |
iqualfragile_ |
hmmmm: any new thoughts on mapgen? |
23:14 |
sapier |
sokomine can you create a screenshot? best case add your screen size (inches) as text |
23:15 |
sapier |
the size is finetuning the more examples I can see the better I can tune ... it's useless to make it good for one device if this is even worse for another |
23:16 |
VanessaE |
I keep telling you sapier, you need to provide options to scale the UI |
23:16 |
VanessaE |
this isn't 1985 anymore, we have the technology :P |
23:16 |
sapier |
we CANT scale the UI when will people finally realize this |
23:16 |
VanessaE |
um... |
23:17 |
sapier |
we can scale some elements but not all |
23:17 |
VanessaE |
ok, ninja'd |
23:17 |
VanessaE |
I was about to say that formspecs DO scale with screen size |
23:17 |
Sokomine |
*nod* perhaps you might offer a setting somewhere |
23:17 |
sapier |
no they don't |
23:17 |
VanessaE |
yes, they do |
23:17 |
sapier |
images do scale but buttons don't completely scale |
23:18 |
VanessaE |
is this a deficiency in minetest or in irrlicht? |
23:18 |
sapier |
buttons have minimum size, texts as well as textboxes have fixed size |
23:18 |
Sokomine |
hm, yes. thumbs don't scale well. a tablet may have the same resolution as a phone. afaik the physical screen size is available somewhere on android as well. at least there are apps who can see it |
23:19 |
sapier |
btw andoid doesn't do ui scaling too as almost no other os does ... because scalable button and icon graphics are quite costly (svg) |
23:19 |
Sokomine |
stupid question, but....how do i do a screnshot on android? |
23:20 |
proller |
render menu to image and scale image ;_ |
23:20 |
sapier |
no it isn't Sokomine but dpi is (somehow) available it's 0.75 1 2 3 4 ... so it's a rough guess only |
23:20 |
VanessaE |
proller: cheater. |
23:20 |
VanessaE |
(that would work, however hacky it is) |
23:20 |
sapier |
and would look like crap |
23:21 |
VanessaE |
sapier: not if you did it right. |
23:21 |
sapier |
no |
23:21 |
VanessaE |
again, this isn't 1985 anymore. we can scale images very nicely up or down |
23:21 |
sapier |
you can't scale a 32 px rexture to a 256 button no matter what you do |
23:21 |
VanessaE |
then scale from a larger size. |
23:21 |
VanessaE |
but that's hacky |
23:21 |
VanessaE |
surely there's a better way |
23:22 |
sapier |
svg is the only way but it's slow |
23:22 |
sapier |
and I don't know if irrlicht supports svg |
23:22 |
spillz |
I think the standard way is to provide multiple sizes and pick accordingly |
23:22 |
sapier |
exactly spillz |
23:22 |
VanessaE |
sapier: it doesn't appear to support svg, no. |
23:23 |
sapier |
then we have to find a way to decide what size to use on what screen ... wich is what I need screenshots for |
23:23 |
Sokomine |
sapier: you solved the issue i had with text input lately very well. that works now convincingly |
23:24 |
sapier |
what issue? |
23:24 |
Sokomine |
sapier: only issue is when opening the chat. it would be really great to make that equivalent to f10 and show at least the last chat messages :-) |
23:24 |
sapier |
hmm you should still see the last messages? the chat overlay should be transparent |
23:26 |
Sokomine |
no, it isn't. it's completely white, showing me nothing of the game anymore. the one stu used was transparent afaik |
23:26 |
sapier |
it's transparent for me too ... what android version/device do you have andhow is this displayed for others? |
23:29 |
sapier |
is there any item that causes the broken textures? |
23:30 |
sapier |
to me this issue seems to be quite similat to what we've seen on pc client about a year ago |
23:30 |
Sokomine |
the textures work fine so far. the inventory cubes are inverted (they're seen from below and not from above as with the desktop version) - but that's a very minor issue |
23:30 |
Sokomine |
hmm |
23:31 |
sapier |
I see disorted inventory item textures every now and then but I haven't found a schme by now |
23:32 |
sapier |
hmm I believe xyz had a fix for the inverted inventorycubes but I'm not sure about it |