| Time |
Nick |
Message |
| 00:04 |
hmmmm |
est31: still no m_authstate? |
| 00:04 |
|
proller joined #minetest-dev |
| 00:04 |
est31 |
? |
| 00:04 |
hmmmm |
what does m_authstate == 0 mean and how about == 1? |
| 00:09 |
est31 |
ah |
| 00:10 |
est31 |
dammit |
| 00:10 |
hmmmm |
no i'm really curious |
| 00:10 |
est31 |
not needed |
| 00:10 |
hmmmm |
:) |
| 00:11 |
* est31 |
removes it |
| 00:13 |
|
Wayward_Tab joined #minetest-dev |
| 00:16 |
paramat |
now pushing 2680 |
| 00:16 |
est31 |
I need it serverside |
| 00:16 |
est31 |
not clientside |
| 00:17 |
est31 |
or do I? |
| 00:18 |
est31 |
there is nothing breaking when I call srp_verifier_verify_session without having set other variables before |
| 00:18 |
est31 |
just failing to compare with the supplied M |
| 00:19 |
est31 |
of course there is the slight chance that the memory garbage ver->M is (its uninitialized after all) can be of some previous login |
| 00:19 |
paramat |
done |
| 00:19 |
est31 |
or guessable by the attacker |
| 00:19 |
est31 |
eg its 0s everywhere |
| 00:19 |
est31 |
which then enables everybody to log in without knowing the password |
| 00:20 |
est31 |
uh, that isnt good |
| 00:20 |
* est31 |
needs that |
| 00:34 |
|
Warr1024 joined #minetest-dev |
| 00:47 |
est31 |
ah dont need it after all |
| 00:47 |
est31 |
bc the chosen_mech has to be set |
| 00:48 |
est31 |
thats enough |
| 00:52 |
|
crazyR joined #minetest-dev |
| 00:52 |
|
crazyR joined #minetest-dev |
| 00:59 |
est31 |
ok then hmmmm do you +1? |
| 01:01 |
hmmmm |
you're missing header guards even |
| 01:01 |
hmmmm |
come on man =/ |
| 01:02 |
est31 |
all this #ifdef ABC_H stuff? |
| 01:02 |
hmmmm |
est31, would you agree for me to do some refactoring after the fact?? |
| 01:03 |
est31 |
yes ofc |
| 01:03 |
hmmmm |
what you have is 85% there but i'd rather not drag your PR down with more mediocre details |
| 01:05 |
est31 |
so you mean its functional, just style issues? |
| 01:05 |
hmmmm |
a little of obth |
| 01:05 |
hmmmm |
both |
| 01:07 |
hmmmm |
btw did you ever add in a comment explaining SudoMode? |
| 01:07 |
est31 |
multiple times yes |
| 01:08 |
est31 |
added include guards to auth.g |
| 01:08 |
est31 |
h* |
| 01:08 |
hmmmm |
ahh okay i see them |
| 01:08 |
est31 |
"// The authentication methods we can use to enter sudo mode (=change password)" |
| 01:08 |
est31 |
"... for sudo mode handling (auth mech generic way of changing password)." |
| 01:09 |
hmmmm |
so wait, why is it called sudo mode again |
| 01:09 |
est31 |
its like when you do sudo |
| 01:09 |
est31 |
you authenticate do something and deauth |
| 01:09 |
est31 |
sudo is nice and short |
| 01:10 |
est31 |
I dont want to name it password_change_mode |
| 01:10 |
hmmmm |
i don't know about you, but in general people don't like 'nice and short' |
| 01:10 |
hmmmm |
people like 'immediately obvious and descriptive' |
| 01:10 |
hmmmm |
i dunno, I never thought password changing should require entering into a 'mode' |
| 01:10 |
kahrl |
passwd in unix doesn't use sudo anyway, it uses setuid |
| 01:11 |
hmmmm |
i'm really nervous about just merging as-is, because protocol changes can't be fixed after the fact |
| 01:11 |
est31 |
its disabled |
| 01:11 |
hmmmm |
i'm mostly looking at the flow and which fields are sent |
| 01:11 |
est31 |
protocol version 24 is used |
| 01:12 |
hmmmm |
for example |
| 01:12 |
est31 |
and if people want srp, they edit networkprotocol.h and set the define to 25 |
| 01:12 |
hmmmm |
TOCLIENT_ACCEPT_SUDO_MODE and TOCLIENT_DENY_SUDO_MODE |
| 01:12 |
hmmmm |
those are two opcodes for basically a yes/no response of the same message |
| 01:12 |
est31 |
yes |
| 01:13 |
hmmmm |
we have a 16 bit command field, right? |
| 01:13 |
est31 |
a good thing to improve the deny packet is by adding a reason |
| 01:13 |
est31 |
lemme check |
| 01:13 |
hmmmm |
you can trivially make a field optional |
| 01:14 |
est31 |
I dont see how it would be simpler |
| 01:14 |
est31 |
bikeshedding for me |
| 01:14 |
hmmmm |
not necessarily simpler, just more organized |
| 01:14 |
hmmmm |
but this does make it simpler because look |
| 01:15 |
hmmmm |
you only change state in a single packet, not one or the other |
| 01:15 |
est31 |
there is both TOCLIENT_ADDNODE and TOCLIENT_REMOVENODE |
| 01:15 |
est31 |
can be fixed by sending a single flag there too |
| 01:15 |
hmmmm |
doesn't addnode also have metadata |
| 01:15 |
est31 |
optional |
| 01:15 |
hmmmm |
you don't need to repeat past mistakes |
| 01:16 |
est31 |
I still dont get why you want to unify it |
| 01:16 |
hmmmm |
think of it in terms of RPC |
| 01:16 |
est31 |
how would you name it? |
| 01:17 |
hmmmm |
each of these packet pairs are a function call and function result |
| 01:17 |
est31 |
TOCLIENT_ACCEPT_OR_DENY_PASSWORD_SET_MODE ?? |
| 01:17 |
hmmmm |
the client makes a call on the server, the TOSERVER_WHATEVER, and the server sends back a TOCLIENT_WHATEVER_RESULT |
| 01:18 |
hmmmm |
but instead what you have is |
| 01:18 |
hmmmm |
TOSERVER_WHATEVER |
| 01:18 |
hmmmm |
and it could return one of two responses |
| 01:19 |
est31 |
so you want to move network code to your RPC like design pattern? |
| 01:20 |
est31 |
Issue is, where do you set the 0 line? |
| 01:20 |
hmmmm |
no, i'm just saying that's the model that protocol have at a very high level |
| 01:21 |
est31 |
we already have two different packets for denying and granting access |
| 01:21 |
est31 |
and the deny packet can be sent middle in the authentication process |
| 01:21 |
est31 |
when the client does something unexpected |
| 01:21 |
est31 |
the accept only at the end |
| 01:22 |
est31 |
I'm ok with you changing it |
| 01:23 |
hmmmm |
what's up with is_empty?? |
| 01:23 |
est31 |
some server owners want to restrict passwords to non-empty |
| 01:23 |
hmmmm |
why is that necessary exactly? |
| 01:23 |
hmmmm |
okay |
| 01:24 |
est31 |
its even announced in the serverlist if I remember right |
| 01:24 |
est31 |
freeminer even uses that to display a small lock icon in the client serverlist |
| 01:24 |
est31 |
interesting sense of security |
| 01:25 |
est31 |
you can let the server "check" every proposed password to be hash("") |
| 01:25 |
est31 |
but that requires it to exeture harh() |
| 01:25 |
est31 |
hash()* |
| 01:25 |
hmmmm |
that wouldn't work with SRP. |
| 01:25 |
est31 |
it will |
| 01:26 |
hmmmm |
you need to do extra stuff. |
| 01:26 |
est31 |
yes |
| 01:26 |
est31 |
because once we make hash() hard to execute, the server will do lots of computation for nothing |
| 01:26 |
est31 |
"nothing" |
| 01:27 |
est31 |
and if people are smart enough to lie with is_empty, then its their fault to have an empty password |
| 01:27 |
est31 |
right now they can lie too |
| 01:27 |
est31 |
or not |
| 01:27 |
est31 |
also the u8 flag is nice to have for future extensions |
| 01:28 |
est31 |
like when we want to add a stronger hash mechanism |
| 01:29 |
est31 |
other issues :D |
| 01:30 |
est31 |
? |
| 01:30 |
hmmmm |
you know the more i think about it the more i wonder about SRP_FIRST |
| 01:30 |
est31 |
better name? |
| 01:30 |
hmmmm |
well, that of course, but it's not really a different authentication method |
| 01:31 |
hmmmm |
it's the same SRP, just using it to do something different |
| 01:31 |
hmmmm |
that other game i wrote an SRP implementation for has its own separate set of create new account/change password packets |
| 01:31 |
est31 |
so you want new packets again lol |
| 01:31 |
hmmmm |
not necessarily |
| 01:32 |
hmmmm |
i'm thinking about which approach could be better |
| 01:34 |
est31 |
An auth mechanism is something that the client can use to show to the server "hey I want to get associated to the following username" |
| 01:35 |
est31 |
and if we have other mechanisms than srp, the client perhaps wants to upload their public key |
| 01:35 |
est31 |
or they want to say "use this google account name to log me in in future" |
| 01:38 |
est31 |
A change I would agree with would be to make TOSERVER_FIRST_SRP more generic |
| 01:38 |
est31 |
perhaps call it TOSERVER_CREATE_ACCOUNT |
| 01:38 |
est31 |
it then has a field showing for which auth mechanism it is |
| 01:38 |
est31 |
and then a std::string logindata |
| 01:38 |
est31 |
depending on the auth mechanism |
| 01:39 |
est31 |
then, for the srp case, its a salt value and a verification key value |
| 01:42 |
|
Wayward_Tab joined #minetest-dev |
| 01:43 |
hmmmm |
and what does AUTH_MECHANISM_LEGACY_PASSWORD actually do? |
| 01:43 |
hmmmm |
i get what it does in theory, but i look at the code and it seems to me like it's all the same as AUTH_MECHANISM_SRP |
| 01:43 |
est31 |
yes |
| 01:43 |
est31 |
/ SRP based on the legacy hash |
| 01:43 |
est31 |
networkprotocol.h line 913 |
| 01:44 |
hmmmm |
so the only difference here is that it uses the legacy hash as the password when generating the verifier, I guess?? |
| 01:45 |
est31 |
yes |
| 01:46 |
hmmmm |
in any case |
| 01:46 |
hmmmm |
FIRST_SRP is not a mechanism |
| 01:46 |
hmmmm |
it's a flag |
| 01:47 |
hmmmm |
a mechanism is like you said, private key authentication or whatever |
| 01:48 |
est31 |
correct |
| 01:48 |
est31 |
every mechanism is a flag |
| 01:48 |
hmmmm |
that's how it's set up |
| 01:48 |
est31 |
yes |
| 01:48 |
hmmmm |
but strictly speaking it does not function as a separate mechanism for authenticating a user |
| 01:48 |
est31 |
why |
| 01:48 |
hmmmm |
you're still using SRP |
| 01:49 |
est31 |
do you speak about FIRST_SRP or LEGACY_PW |
| 01:49 |
hmmmm |
what does "42" do in sendInit()? |
| 01:49 |
hmmmm |
I speak of FIRST_SRP |
| 01:49 |
est31 |
FIRST_SRP doesnt do SRP |
| 01:49 |
est31 |
it does SRP_ENROLLMENT |
| 01:50 |
est31 |
perhaps a better name |
| 01:50 |
est31 |
not FIRST_SRP |
| 01:50 |
est31 |
but ENROL_SRP |
| 01:50 |
est31 |
but ENROLL_SRP |
| 01:50 |
hmmmm |
it does stuff related to SRP |
| 01:50 |
est31 |
yes |
| 01:51 |
hmmmm |
to me, at least, an "authentication method" is some method that has a set of methods to it |
| 01:51 |
hmmmm |
such as "how do I create an account for <this>?" |
| 01:51 |
hmmmm |
or "how do I change my password for <this>?" |
| 01:51 |
hmmmm |
and "I want to log in using this method" |
| 01:52 |
hmmmm |
this would work for SRP, this would work for LEGACY_AUTH, but this abstraction wouldn't hold true for FIRST_SRP |
| 01:52 |
hmmmm |
you can't log in with FIRST_SRP |
| 01:52 |
hmmmm |
so it's not a method of logging in |
| 01:52 |
est31 |
yes it is |
| 01:52 |
hmmmm |
you can actually complete a login with FIRST_SRP?? |
| 01:52 |
est31 |
the connection isnt closed after FIRST_SRP |
| 01:52 |
hmmmm |
yea it's not closed |
| 01:52 |
hmmmm |
but the user is authenticated, or not? |
| 01:52 |
est31 |
once the packet is sent you can start playing |
| 01:53 |
est31 |
yes |
| 01:53 |
est31 |
its like when you go to a newly discovered island and say "this is now my islanf" |
| 01:53 |
est31 |
then its your island |
| 01:53 |
hmmmm |
and now you said that creating a new account and changing password is the same because they both use FIRST_SRP |
| 01:53 |
est31 |
you don't have to buy it from anybody |
| 01:53 |
hmmmm |
but there is a difference |
| 01:54 |
est31 |
changing passwords is something different |
| 01:54 |
hmmmm |
the conditions of authorization for FIRST_SRP when creating a new account is that the previous account does not exist |
| 01:54 |
hmmmm |
the conditions of authorization for FIRST_SRP when changing a password is that the previous password matches |
| 01:54 |
est31 |
so? |
| 01:57 |
hmmmm |
for creating an account, you only ever need to send your salt, verifier, and username. |
| 01:57 |
hmmmm |
for changing an account password, you start out SRP by sending A and username |
| 01:57 |
hmmmm |
those are two entirely different packets! |
| 01:57 |
est31 |
ah |
| 01:57 |
est31 |
I see now |
| 01:57 |
hmmmm |
I don't know man |
| 01:57 |
hmmmm |
I just feel like it's structured in a rather non-intuitive manner |
| 01:57 |
est31 |
changing a password has two steps |
| 01:58 |
hmmmm |
right, the request, then the proof |
| 01:58 |
est31 |
1. authenticating with the old password |
| 01:58 |
est31 |
2. setting the new password |
| 01:58 |
est31 |
for 1, we can use everything |
| 01:58 |
est31 |
like AUTH_MECHANISM_LEGACY_PASSWORD |
| 01:58 |
est31 |
for 2 we use AUTH_MECHANISM_FIRST_SRP |
| 01:58 |
est31 |
currently AUTH_MECHANISM_FIRST_SRP is the only supported mechanism for step 2. |
| 01:59 |
hmmmm |
is LEGACY_PASSWORD used each time? |
| 01:59 |
est31 |
no |
| 01:59 |
hmmmm |
just the first time |
| 01:59 |
est31 |
AUTH_MECHANISM_SRP can be used too |
| 01:59 |
hmmmm |
I mean during the regular course of operation |
| 02:00 |
hmmmm |
so the user has a legacy password |
| 02:00 |
hmmmm |
wants to authenticate |
| 02:00 |
hmmmm |
how does the user know that the password is a legacy password? |
| 02:00 |
est31 |
if sb doesnt change their password nothing will happen no |
| 02:00 |
est31 |
they will stay at the legacy password |
| 02:01 |
hmmmm |
do you think the legacy password should get upgraded to an SRP verifier? |
| 02:01 |
est31 |
that info is sent on TOCLIENT_ something |
| 02:01 |
est31 |
again a byteflag |
| 02:01 |
est31 |
TOCLIENT_AUTH_ACCEPT |
| 02:01 |
est31 |
u32 : supported auth methods for sudo mode |
| 02:01 |
est31 |
(where the user can change their password) |
| 02:02 |
|
paramat left #minetest-dev |
| 02:02 |
hmmmm |
so walk me through this logon sequence |
| 02:02 |
hmmmm |
I am a user with a legacy password |
| 02:03 |
hmmmm |
I am trying to connect to CoolServer with SRP enabled |
| 02:03 |
hmmmm |
what do I say in particular that indicates i want to change this to SRP? |
| 02:03 |
hmmmm |
what does the server tell me? |
| 02:04 |
est31 |
there is no method for somebody who wants to upgrade without doing the sudo mode thing |
| 02:05 |
hmmmm |
okay, so the user enters sudo mode |
| 02:05 |
est31 |
then the user sends FIRST_SRP packet |
| 02:05 |
est31 |
and has SRP |
| 02:06 |
hmmmm |
how does a client request sudo mode? |
| 02:06 |
est31 |
network/clientiface.h has a very nice ASCII art overview |
| 02:07 |
est31 |
seen it? |
| 02:07 |
hmmmm |
yeah |
| 02:07 |
est31 |
the client just starts authenticating |
| 02:08 |
est31 |
e.g. with BYTES_A |
| 02:08 |
est31 |
thats this part of the ascii art: "any auth packet which was allowed in TOCLIENT_AUTH_ACCEPT" |
| 02:08 |
hmmmm |
unless I'm mistaken, doesn't the ASCII chart say that the client starts sudo mode by sending TOSERVER_FIRST_SRP? |
| 02:08 |
est31 |
no, thats the way it exits |
| 02:09 |
est31 |
I should perhaps document TOCLIENT_DENY_SUDO_MODE |
| 02:10 |
hmmmm |
i'm... sorta confused |
| 02:10 |
hmmmm |
maybe some others should see what they think about it all |
| 02:10 |
est31 |
ok |
| 02:10 |
hmmmm |
i'm not saying it doesn't make sense, because it clearly does - it works, it's just that i can't figure it out right now |
| 02:13 |
est31 |
np |
| 02:23 |
|
Warr1024 joined #minetest-dev |
| 02:25 |
|
est31 joined #minetest-dev |
| 02:37 |
|
VanessaE joined #minetest-dev |
| 02:38 |
|
VanessaE_ joined #minetest-dev |
| 02:45 |
hmmmm |
wtf |
| 02:45 |
hmmmm |
the player's hand is now invisible |
| 02:45 |
VanessaE |
eep |
| 02:45 |
est31 |
perhaps due to that wielditem fix |
| 02:45 |
est31 |
? |
| 02:46 |
hmmmm |
nope |
| 02:48 |
hmmmm |
it's 3a8e734 |
| 02:48 |
hmmmm |
thanks shadowninja. |
| 02:48 |
hmmmm |
two major bugs with this patch so far |
| 02:49 |
ShadowNinja |
O_O |
| 02:50 |
hmmmm |
i see the problem |
| 02:50 |
ShadowNinja |
What'd I do? |
| 02:50 |
hmmmm |
you made a series of horrible copy/paste errors leading to crashes and hidden textures |
| 02:51 |
hmmmm |
ShadowNinja: look at check_v3f. |
| 02:53 |
ShadowNinja |
Ah, pos.Z set twice, with Y ignored. |
| 02:53 |
ShadowNinja |
Sorry :-( |
| 02:54 |
hmmmm |
don't apologize to me, apologize to minetest! |
| 02:57 |
hmmmm |
i'll fix it if nobody else will |
| 03:12 |
|
alfmelmac joined #minetest-dev |
| 03:29 |
est31 |
the android app xabber also used versions like 0.x.y before, and after 0.10.something they decided to continue with 1.0.5 |
| 03:29 |
est31 |
or 1.0.2 |
| 03:40 |
|
Hijiri joined #minetest-dev |
| 03:47 |
hmmmm |
lol |
| 03:47 |
hmmmm |
novatux's randomized github avatar looks like a man with a moustache |
| 03:48 |
|
FR^3 joined #minetest-dev |
| 03:56 |
|
FR^3 joined #minetest-dev |
| 04:06 |
hmmmm |
https://github.com/kwolekr/minetest/commit/df96746b4fba988b781e6a94b7771a67976feccc |
| 04:06 |
|
FR^3 joined #minetest-dev |
| 04:18 |
hmmmm |
will push if nobody has complaints.. |
| 04:51 |
hmmmm |
pushing... |
| 04:51 |
est31 |
pushing in 15 mins https://github.com/est31/minetest/commit/33c11415bf9f05192c104c4bb38f579824addfa5 |
| 04:52 |
hmmmm |
a PacketError is when a packet does not have enough data in it for its type, correct? |
| 04:57 |
hmmmm |
phew |
| 04:57 |
hmmmm |
so I'm done for now with my unit test spike |
| 04:58 |
hmmmm |
maybe sometime in the future when I'm motivated, i'll add a convenient way to take voxelmanip snapshots and then compare node-to-node for things such as schematic/ore/decoration placement |
| 04:58 |
hmmmm |
also would be nice to do mapgen heightmaps, bulk liquid transform queue insertion, light calculations |
| 04:58 |
est31 |
is mapgen deterministic? |
| 04:58 |
hmmmm |
yes |
| 04:58 |
est31 |
nice |
| 04:59 |
hmmmm |
i can't test the mapgen directly because it... changes... |
| 04:59 |
hmmmm |
one minor change would require you to update all the unit tests |
| 04:59 |
hmmmm |
maybe for mapgen V6 we could have tests because that one's not supposed to change |
| 05:02 |
VanessaE |
hmmmm: build failure: http://pastebin.ubuntu.com/11020323/ (works fine at 33c11415) |
| 05:03 |
hmmmm |
I am going bonkers |
| 05:03 |
hmmmm |
this is a slightly different manifestation of the same problem with the commit not too long ago |
| 05:04 |
hmmmm |
for now, just add #include "util/numeric.h" to that file |
| 05:04 |
est31 |
have you found out where the file is included? |
| 05:04 |
hmmmm |
i ddidn't do that i'm going to do it now though |
| 05:09 |
hmmmm |
heh |
| 05:09 |
hmmmm |
mg_schematic.h -> mg_decoration.h -> mapgen.h -> nodedef.h -> client/tile.h -> util/numeric.h |
| 05:11 |
est31 |
lol |
| 05:11 |
hmmmm |
it's not a freebsd problem, it's a server-only-compilation problem |
| 05:12 |
est31 |
ok |
| 05:12 |
est31 |
somehow on freebsd it doesnt compile the server |
| 05:13 |
est31 |
where is the #ifdef server ? |
| 05:13 |
hmmmm |
no it doesn't compile the server by default ever since shadowninja's changes |
| 05:13 |
est31 |
not nice |
| 05:13 |
hmmmm |
so |
| 05:13 |
est31 |
I guess I have some outdated config then |
| 05:13 |
hmmmm |
although it might cut down linking time by half |
| 05:13 |
hmmmm |
it causes me to miss out on these kinds of compilation errors |
| 05:13 |
hmmmm |
:( |
| 05:14 |
est31 |
test_schematic.cpp:119:23: warning: comparison between signed and unsigned integer expressions |
| 05:14 |
hmmmm |
for remediation though, I'll strategically add an #include "util/numeric.h" in nodedef.h |
| 05:14 |
est31 |
also on 101 and 82 |
| 05:14 |
hmmmm |
wtf I didn't get that warning :( |
| 05:14 |
hmmmm |
clang needs to be more verbose i think |
| 05:14 |
hmmmm |
are you using gcc? |
| 05:14 |
est31 |
yes |
| 05:14 |
hmmmm |
are there ANY other warnings |
| 05:14 |
est31 |
no |
| 05:14 |
hmmmm |
kk |
| 05:15 |
est31 |
what wonders me a but |
| 05:15 |
est31 |
bit* |
| 05:15 |
est31 |
because I wanted to fix a warning I've caused |
| 05:15 |
est31 |
now its gone |
| 05:16 |
est31 |
ah |
| 05:16 |
est31 |
because it only has problems in release builds |
| 05:17 |
est31 |
so you merge your build fix then I merge my warning fix |
| 05:18 |
est31 |
bisectors should get a small surface as possible |
| 05:22 |
hmmmm |
yeah go ahead |
| 05:22 |
est31 |
no you first |
| 05:22 |
hmmmm |
i did |
| 05:22 |
est31 |
ok |
| 06:12 |
est31 |
hmmmm, what was that std hashmap again thats basically hashmap < list < T > > ? |
| 06:14 |
|
leat4 joined #minetest-dev |
| 06:16 |
hmmmm |
what do you mean |
| 06:16 |
hmmmm |
std::unordered_map? that's C++11 |
| 06:17 |
est31 |
I want to construct a handler hashmap for settings, where you can register handlers that get called when that specific setting name gets changed |
| 06:17 |
est31 |
now you could have multiple handlers in theory |
| 06:17 |
est31 |
I want to use it first for c++ code only, but its planned to have lua later |
| 06:17 |
hmmmm |
i had a different approach in mind |
| 06:18 |
hmmmm |
instead of expanding settings callbacks, make settings fast |
| 06:19 |
est31 |
? |
| 06:19 |
hmmmm |
with atomic operations and memory barriers, settings can for the most part be atomic |
| 06:19 |
hmmmm |
no lock, no map, etc. |
| 06:20 |
est31 |
so? |
| 06:20 |
est31 |
do I interfere with your multithreading plans :p |
| 06:21 |
hmmmm |
they're both ways of approaching the problem |
| 06:21 |
hmmmm |
you want to modify the way the interface works by adding callbacks everywhere |
| 06:22 |
hmmmm |
but it never does fix the underlying issue of using too much time for something as simple as settings |
| 06:23 |
|
Hunterz joined #minetest-dev |
| 06:23 |
est31 |
yes |
| 06:24 |
est31 |
but polling is bad |
| 06:24 |
est31 |
pushing is better |
| 06:24 |
|
leat4 joined #minetest-dev |
| 06:24 |
hmmmm |
there is no polling |
| 06:24 |
est31 |
With clouds, its easy because they are recreated every time |
| 06:24 |
hmmmm |
it just reads the value |
| 06:25 |
hmmmm |
well |
| 06:25 |
hmmmm |
i would have no problem adding a settings callback for clouds, i suppose |
| 06:25 |
|
Robert_Zenz joined #minetest-dev |
| 06:25 |
est31 |
I think it can be used at other parts too |
| 06:27 |
est31 |
for clouds, polling is perhaps even not that bad |
| 06:27 |
est31 |
we are recreating them from scratch every time every way |
| 06:27 |
est31 |
every render* |
| 06:27 |
hmmmm |
that's not necessarily a good thing |
| 06:27 |
hmmmm |
don't aggravate the problem |
| 06:28 |
est31 |
just at other places people might have very different setups |
| 06:28 |
est31 |
between two values for a setting |
| 06:28 |
est31 |
so they could do of course polling, then compare with a variable |
| 06:28 |
est31 |
but that isn't nice, is it? |
| 06:30 |
hmmmm |
compare with a variable..? |
| 06:30 |
est31 |
yes |
| 06:30 |
est31 |
store the last result |
| 06:30 |
est31 |
then compare it with that |
| 06:30 |
est31 |
if match, then nothig changed |
| 06:30 |
est31 |
else, fun begins |
| 06:30 |
hmmmm |
yeah but what's the point |
| 06:31 |
est31 |
with "fun" being the stuff inside the callback |
| 06:32 |
est31 |
whats the point then? |
| 06:32 |
hmmmm |
you're just reading some values from settings |
| 06:32 |
est31 |
so the major performance hurdle for settings is that it requires locks? |
| 06:32 |
hmmmm |
not necessarily |
| 06:33 |
hmmmm |
it's that the locks are highly contended, and that it uses a std::map, and that it reparses the string value every time |
| 06:33 |
hmmmm |
for something that really should be as simple as reading a memory location |
| 06:34 |
hmmmm |
if reading settings wasn't so heavy, then we'd be able to have them inline with the rest of the code and never have to cache settings |
| 06:34 |
|
jin_xi joined #minetest-dev |
| 06:34 |
est31 |
meh perhaps settings retrieval should base on some cool id instead? |
| 06:34 |
est31 |
and then have an enum? |
| 06:34 |
hmmmm |
basically, yes |
| 06:34 |
est31 |
or is there some preprocessor hack for that |
| 06:34 |
hmmmm |
there's nothing really wrong with an enum |
| 06:35 |
est31 |
yes if code needs it at some place, we can still have a map for the exotic stuff |
| 06:35 |
hmmmm |
right |
| 06:35 |
hmmmm |
other people also had this idea |
| 06:35 |
est31 |
eg for lua mods |
| 06:35 |
hmmmm |
i think it was called 'core settings' |
| 06:36 |
est31 |
and did it face opposition? |
| 06:36 |
hmmmm |
no, i don't think so.. |
| 06:36 |
est31 |
so what was the problem why it didn't get implemented then? |
| 06:37 |
hmmmm |
lack of time? i don't know |
| 06:38 |
est31 |
ok, future thing I may work on: backporting the utf8 fixes of xyz |
| 06:38 |
est31 |
other future thing* |
| 06:38 |
est31 |
any ideas why that hasn't been done? |
| 06:38 |
hmmmm |
no clue |
| 06:39 |
est31 |
there is one problem however |
| 06:39 |
est31 |
current chat packets send wstrings |
| 06:39 |
est31 |
this is horrible of course |
| 06:39 |
est31 |
I mean its like depending on machine endianness |
| 06:40 |
est31 |
just people might have gotten accustomed to it |
| 06:40 |
est31 |
and fear the change |
| 06:40 |
est31 |
now I wonder whether to simply break and send unicode |
| 06:40 |
hmmmm |
? |
| 06:41 |
hmmmm |
sending a std::wstring is not sensitive to endianness at all |
| 06:41 |
est31 |
yes |
| 06:41 |
est31 |
but sensitive to the machines local encoding |
| 06:41 |
est31 |
so it doesnt break always like with endianness |
| 06:41 |
est31 |
(endianness breaks always when they dont match) |
| 06:42 |
est31 |
but it still breaks when computers have different local encodings |
| 06:42 |
hmmmm |
maybe in the init packet the server can report which code page it sends wide strings as |
| 06:42 |
est31 |
oh no |
| 06:42 |
est31 |
too complicated |
| 06:43 |
est31 |
I mean it is possible to send unicode for "modern" servers and clients |
| 06:43 |
est31 |
and wstring for all before |
| 06:46 |
est31 |
but its more complex than breaking |
| 07:08 |
|
kilbith joined #minetest-dev |
| 07:23 |
est31 |
getting gazillions of warnings in gcc 5.1 |
| 07:24 |
est31 |
but at least they are colored |
| 07:24 |
est31 |
yaay |
| 07:24 |
est31 |
(gcc 5.1 turns on colors by default) |
| 07:26 |
est31 |
mostly -Wdeprecated-declarations ones |
| 07:28 |
est31 |
out of some reason leveldb doesn't like being compiled by gcc 5.1 |
| 07:28 |
est31 |
perhaps its problem of my setup options |
| 07:29 |
est31 |
perhaps its leveldbs fault |
| 07:29 |
est31 |
either way color is nice |
| 07:29 |
* est31 |
will get it onto the system in october yaay ! |
| 07:42 |
|
Fritigern joined #minetest-dev |
| 07:58 |
|
Calinou joined #minetest-dev |
| 08:06 |
|
Yepoleb joined #minetest-dev |
| 08:37 |
|
crazyR_ joined #minetest-dev |
| 08:59 |
kilbith |
ok, the client crashes when you wield a mesh node with >6 tiles : http://pastie.org/10177446 |
| 09:07 |
|
blaze joined #minetest-dev |
| 09:28 |
|
FR^2 joined #minetest-dev |
| 09:32 |
|
proller joined #minetest-dev |
| 09:43 |
|
err404 joined #minetest-dev |
| 10:04 |
|
cib0 joined #minetest-dev |
| 10:20 |
|
est31 joined #minetest-dev |
| 10:22 |
|
Amaz joined #minetest-dev |
| 11:22 |
est |
oooh I'm doing some ninja tricks to kill repetition |
| 11:22 |
est |
or, expressed better, to avoid it |
| 11:23 |
est |
because currently there isn't |
| 11:35 |
|
ElectronLibre joined #minetest-dev |
| 12:05 |
|
cib0 joined #minetest-dev |
| 12:54 |
|
kilbith joined #minetest-dev |
| 13:05 |
|
proller joined #minetest-dev |
| 13:16 |
|
proller joined #minetest-dev |
| 13:22 |
|
AnotherBrick joined #minetest-dev |
| 13:39 |
|
selat joined #minetest-dev |
| 13:55 |
|
OldCoder joined #minetest-dev |
| 14:03 |
|
hmmmm joined #minetest-dev |
| 14:13 |
|
oleastre joined #minetest-dev |
| 14:46 |
est |
hmmmm, http://pastebin.ubuntu.com/11026990/ |
| 14:47 |
est |
this is one of a gazillion warnings on gcc 5.1 usage |
| 14:47 |
est |
and I wonder whether its my config being broken or minetest :) |
| 14:47 |
est |
ideas? |
| 14:51 |
sfan5 |
est: nope, irrlicht marked those methods as deprecated |
| 14:52 |
est |
so you say its config? |
| 14:52 |
est |
(my config) |
| 14:55 |
sfan5 |
no |
| 14:55 |
sfan5 |
it's what irrlicht decided |
| 14:55 |
est |
irrlicht versions dont change |
| 14:55 |
est |
only the compiler |
| 14:56 |
est |
and gcc -v changes too |
| 14:56 |
est |
gets much much shorter |
| 14:56 |
est |
also I dont apply my distro patches |
| 14:56 |
est |
vanilla gcc |
| 15:09 |
|
leat joined #minetest-dev |
| 15:28 |
|
proller joined #minetest-dev |
| 15:36 |
|
proller joined #minetest-dev |
| 15:44 |
hmmmm |
we want reverse compatibility with older versions of irrlicht |
| 15:44 |
hmmmm |
can we just add -Wno-deprecated-declarations?? |
| 15:45 |
hmmmm |
hmm, how about this: http://pastie.org/10177446 |
| 15:46 |
hmmmm |
I sense a general trend that assertions are overused. the vast majority of these things should be treated as invalid input, not some kind of internal inconsistency... |
| 15:47 |
hmmmm |
adding assert() everywhere in your code does not automatically increase its correctness. usually it's wrong. |
| 15:47 |
est |
its better than just continuing |
| 15:47 |
est |
isnt it? |
| 15:47 |
est |
whatever |
| 15:48 |
hmmmm |
right, eating rat poison is better than shooting yourself because at least with the former you won't inadvertantly hurt others |
| 15:48 |
Sokomine |
hmmmm: there still seems to be a minor bug regarding minetest.find_nodes_with_meta how shall i report it? github, here, msg? |
| 15:48 |
hmmmm |
sokomine, do not private message people |
| 15:48 |
hmmmm |
make a github issue |
| 15:49 |
hmmmm |
first why don't you just talk about the error. it might not be a real error |
| 15:52 |
est |
why do we lock the mutex in Settings::exists ? |
| 15:52 |
est |
i mean its only there for writing isnt it? |
| 15:53 |
hmmmm |
writing can modify the std::map internals |
| 15:53 |
est |
then however it isn't deployed consistentyl |
| 15:54 |
Sokomine |
i've opened an issue now. https://github.com/minetest/minetest/issues/2682 it's minor. checks could be done in lua if the node really is inside the volume defined by the two positions |
| 15:55 |
hmmmm |
yes, it pads out to a block |
| 15:56 |
hmmmm |
is that really that bad? |
| 15:57 |
|
cib0 joined #minetest-dev |
| 16:01 |
est |
man this turns out to be copy paste hell |
| 16:01 |
est |
if we really want type dualism... |
| 16:02 |
est |
setDefault setGroup setGroupDefault setBool setS16 setU16 setS32 setU64 setFloat setV2F setV3F |
| 16:02 |
est |
and so on and so on |
| 16:02 |
est |
and thats only the setters |
| 16:02 |
est |
every single one has to be overloaded (in theory) |
| 16:03 |
hmmmm |
huh? |
| 16:03 |
hmmmm |
we do not do overloading of any type unless it's very helpful |
| 16:03 |
est |
about the settings thing you proposed |
| 16:03 |
est |
whatever |
| 16:04 |
hmmmm |
i know you love for code to be expressive and minimal |
| 16:04 |
est |
even if you dont want overloading, its a huge mess |
| 16:04 |
hmmmm |
but most others working on minetest don't like that |
| 16:05 |
Sokomine |
hmmmm: so find_node_with_meta is not restricted to the area given? i can certainly live with that. it just needs to be documented then |
| 16:05 |
hmmmm |
well i can fix that i guess |
| 16:06 |
Sokomine |
that would be breat :-) |
| 16:06 |
Sokomine |
er, great... |
| 16:10 |
ElectronLibre |
To whom it may interest : https://github.com/minetest/minetest_game/pull/502 ( game#502 ) |
| 16:10 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/502 -- Created TNT mods namespace by LeMagnesium |
| 16:14 |
est |
and overloading in this case is good |
| 16:14 |
est |
because we dont have to do stupid casting comparisons |
| 16:15 |
est |
so the compiler knows ahead of time |
| 16:39 |
* est |
wonders whether to use a vector or a pointer array for the fast access container |
| 16:43 |
|
leat joined #minetest-dev |
| 16:44 |
est |
a vector wont use more space either I guess... |
| 16:47 |
est |
ok I know where it does use more space |
| 16:47 |
est |
for the non-default list |
| 16:47 |
|
rubenwardy joined #minetest-dev |
| 16:48 |
est |
but whatever |
| 16:54 |
|
leat joined #minetest-dev |
| 17:01 |
|
Wayward_Tab joined #minetest-dev |
| 17:04 |
|
leat joined #minetest-dev |
| 17:19 |
hmmmm |
what would be really helpful is if somebody could go through all the instances of sanity_check(), assert(), and the like, and replace instances of these that are triggered by server or client network input with an error instead (such as failing inside of that function) |
| 17:19 |
hmmmm |
this is a very big pressing issue that I would do myself but I've got things to do today |
| 17:26 |
hmmmm |
https://github.com/minetest/minetest/commit/f1ccfd3c3d7d626087f70b8c5798110cd28b248a |
| 18:06 |
|
Hijiri joined #minetest-dev |
| 18:15 |
|
Krock joined #minetest-dev |
| 18:20 |
|
younishd joined #minetest-dev |
| 18:37 |
Krock |
hmmmm, please change ">= 6" to "> 6" in https://github.com/minetest/minetest/commit/f1ccf |
| 18:39 |
|
msantana joined #minetest-dev |
| 18:49 |
|
Hijiri joined #minetest-dev |
| 18:59 |
|
Anchakor joined #minetest-dev |
| 19:37 |
|
proller joined #minetest-dev |
| 19:41 |
|
MinetestForFun joined #minetest-dev |
| 19:48 |
|
Wayward_Tab joined #minetest-dev |
| 20:01 |
Calinou |
https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fminetest.net&tab=desktop |
| 20:01 |
Calinou |
minetest.net does not allow gzip compression |
| 20:01 |
Calinou |
also images could be optimized |
| 20:03 |
|
Wayward_Tab joined #minetest-dev |
| 20:03 |
celeron55 |
i'll look into gzip, but none of the others are worth the effort |
| 20:05 |
Calinou |
“optipng -o7 -strip all *.png; jpegoptim -s *.jpg†does everything in a folder |
| 20:05 |
Calinou |
:P |
| 20:07 |
Warr1024 |
optipng is pretty good, but advpng does a better job with compression |
| 20:08 |
Warr1024 |
you have to be careful with image optimizers though, as they make some assumptions |
| 20:08 |
Warr1024 |
like that completely-transparent pixels' RGB information is not important, despite ^[noalpha used for fast leaves. |
| 20:12 |
sfan5 |
Warr1024: advpng just performs better becasue it uses a custom deflate compressor |
| 20:12 |
sfan5 |
also it sounds like advpng would take a very long time to compress stuff |
| 20:15 |
|
TheWild joined #minetest-dev |
| 20:25 |
Warr1024 |
if compressing stuff on the fly, yeah. |
| 20:25 |
Warr1024 |
ideally, mod and texture pack authors really should do their own compression beforehand |
| 20:27 |
Warr1024 |
for server admins wanting to cut down on client connect time, it should be simple to provide a script that does some image pre-compression, that only has to run once ever per image. |
| 20:31 |
|
Hijiri joined #minetest-dev |
| 21:02 |
hmmmm |
there really is a memory leak |
| 21:02 |
hmmmm |
people without swapfiles will notice it |
| 21:02 |
sfan5 |
i never noticed a memory leak |
| 21:03 |
sfan5 |
maybe that's because i have 8GB RAM |
| 21:10 |
|
proller joined #minetest-dev |
| 21:25 |
hmmmm |
you won't notice it unless you look at VIRT in top |
| 21:25 |
hmmmm |
it keeps getting swapped out so it seems to you that minetest is only using about 100mb |
| 21:25 |
|
est31 joined #minetest-dev |
| 21:25 |
est31 |
hmmmm, about https://github.com/minetest/minetest/commit/f1ccfd3c3d7d626087f70b8c5798110cd28b248a |
| 21:26 |
est31 |
can this error be raised by a client? |
| 21:26 |
hmmmm |
eah i made a typo |
| 21:26 |
hmmmm |
can you fix the >= |
| 21:26 |
hmmmm |
or somebody else |
| 21:26 |
est31 |
ah I see |
| 21:26 |
hmmmm |
it still works, it'd just have an annoying error every time somebody has exactly 6 materials |
| 21:26 |
est31 |
in fact I was starting to comment about another issue |
| 21:26 |
est31 |
because errorstream logging is bad when the client can trigger it |
| 21:27 |
hmmmm |
the material count is set in the itemdef |
| 21:27 |
est31 |
because its sent to all clients |
| 21:27 |
hmmmm |
no, no, that code runs on the client only |
| 21:27 |
est31 |
ok then |
| 21:27 |
hmmmm |
this is wieldmesh.cpp |
| 21:27 |
est31 |
ah |
| 21:27 |
hmmmm |
it's not compiled with the server at all |
| 21:27 |
est31 |
yea lol |
| 21:27 |
* est31 |
should have looked |
| 21:27 |
est31 |
then its good |
| 21:28 |
hmmmm |
but the point remains |
| 21:28 |
hmmmm |
this is an example of an entire class of errors |
| 21:28 |
est31 |
yes |
| 21:29 |
hmmmm |
people add assertions to their code, but forget that a remote server or client is providing the input causing this abnormal condition |
| 21:29 |
est31 |
but server being able to take down client is not *that* bad |
| 21:29 |
hmmmm |
and there are a lot of these |
| 21:29 |
hmmmm |
not that bad, but still quite nasty |
| 21:29 |
est31 |
yes |
| 21:29 |
hmmmm |
this is a shit task i'll admit, but it's an important one |
| 21:29 |
est31 |
not good practice at all |
| 21:30 |
hmmmm |
to go through all of the asserts/sanity_checks and make sure the remote peer can't trigger it from their input |
| 21:30 |
est31 |
you know when I read some server packets, then I see checks here checks there, and on client side? its assuming the server did the right thing |
| 21:30 |
est31 |
(separate issue though) |
| 21:30 |
hmmmm |
people tend to forget this is a multiplayer game |
| 21:31 |
est31 |
I'll first do the settings thingy then focus on the utf8 backporting |
| 21:32 |
est31 |
settings turn out to be quite hairy though |
| 21:33 |
est31 |
abstracting out the defaultsettings to both provide an enum and default value initialisation was the easy part compared to that |
| 21:39 |
|
Wayward_One joined #minetest-dev |
| 21:39 |
|
Wayward_One joined #minetest-dev |
| 21:40 |
Wayward_One |
I just got this error when unchecking damage on the singleplayer menu: http://pastebin.com/4hFPauLP |
| 21:41 |
est31 |
Wayward_One, known |
| 21:41 |
Wayward_One |
ah, ok |
| 21:41 |
est31 |
and there is a PR somewhere |
| 21:41 |
est31 |
#2586 |
| 21:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/2586 -- Fix some bugs in mainmenu tab_singleplayer and tab_server by fz72 |
| 21:49 |
est31 |
hmmmm, what do you think is the preprocessor hack ugly or nice? https://github.com/est31/minetest/commit/4129674ad8446ada991b842041d0bcae775cd738 |
| 21:49 |
est31 |
(for me its the latter ofc :p) |
| 21:50 |
est31 |
the commit doesnt work at all, only the preprocessor hack is set up |
| 21:50 |
est31 |
and the MTSetting enum is populated |
| 21:50 |
est31 |
automatically |
| 23:02 |
|
Wayward_Tab joined #minetest-dev |
| 23:56 |
hmmmm |
est31, i probably wouldn't do that myself but it certainly is nice |
| 23:57 |
hmmmm |
the builtin settings are really too cumbersome and large to write to like 3 different places |
| 23:58 |
hmmmm |
instead of MTSettings I think I'd call it CoreSettings or whatever it originally was, that sounds pretty nice and it's also game name independent which some people like |
| 23:59 |
hmmmm |
also setting_instead sounds wtf |
| 23:59 |
hmmmm |
normally you'd name that something like mtsetting_value or something |
