Minetest logo

IRC log for #minetest-dev, 2015-05-08

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

All times shown according to UTC.

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&amp;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

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