Time  Nick        Message
00:02 Exio4       what about https://github.com/BlockMen/minetest/commit/24cd595f41079e22c871f70eb2f9219e79ba52a5 ?
16:18 VanessaE    sapier:  there is at least one person now complaining that 0.4.9-stable still has problems with invisible players.
16:18 VanessaE    (with my server running your patch)
18:29 sapier      Blockmen I don't understand need for this if you still keep the levels. I'd prefere to either have fixed levels or complete free scaling. https://github.com/BlockMen/minetest/commit/24cd595f41079e22c871f70eb2f9219e79ba52a5
19:15 Miner_48er  why are dashes allowed in usernames?
19:16 sapier      is there a reason not to allow them?
19:21 VanessaE    what's wrong with dashes in a username?
19:21 Miner_48er  dashes are special characters in many languages
19:22 ImQ009      Miner_48er, They're standard
19:22 ImQ009      In most possibble cases
19:22 sapier      dashes aren't even a problem on almost any filesystem
19:22 ImQ009      Miner_48er, Also, IRC protocol isn't a programming languagwe
19:23 VanessaE    regarding version numbers in the client and server networking protocol messages - we need this so that the master server list can be filtered according to whether a server can work with a given client. e.g. the proposed 0.5.0 vs 0.4.x split.  WE CANNOT have 0.5.x servers showing up on 0.4.x clients' lists.
19:23 VanessaE    I don't give a shit about scriptapi or other arguments
19:23 VanessaE    THIS needs done
19:23 sapier      well a name is obviously not a programming language *smile*
19:23 ImQ009      sapier, He kinda suggested that it is :P
19:27 Miner_48er  no scripting a bash solution to the new version of the Player::deSerialize(): PlayerArgsEnd error
19:28 sapier      what's this error?
19:29 Miner_48er  ERROR[main]: ERROR: An unhandled exception occurred: Player::deSerialize(): PlayerArgsEnd of player "CRAFTER03.~mt" not found
19:29 VanessaE    rm *.~mt
19:29 VanessaE    those files are never supposed to be present anyway
19:29 VanessaE    just make sure you have a valid player to go with it
19:29 VanessaE    valid player file*
19:30 VanessaE    I thought that glitch was fixed though?
19:30 VanessaE    (the server shouldn't attempt to load *.~mt)
19:31 VanessaE    those files are created when the server saves a player file, as a safer way to save them.  they're supposed to be deleted after the save completes.
19:31 celeron55_  i filed an issue, but i don't know if anyone fixed it yet
19:32 celeron55_  looks like it's not there anymore, so it's fixed in some version
19:32 celeron55_  wait
19:32 VanessaE    celeron55_: as long as you're here, see above re: version numbers in the network protocol
19:32 celeron55_  yes it's still there
19:32 celeron55_  https://github.com/minetest/minetest/issues/1086
19:32 celeron55_  so it's _not_ fixed
19:33 celeron55_  VanessaE: the master server stuff is completely separate and does not relate to the previously discussed problems
19:33 celeron55_  none of them
19:33 VanessaE    celeron55_: I didn't think so.  Reason I brought this up is there are concerns that, despite that complete separation, the idea was still off the table anyway
19:34 celeron55_  well actually, it depends on what will be done
19:36 celeron55_  but in the case a 0.5.0 is done, it will obviously use a practically completely separate server list
19:36 celeron55_  because mixing them up would give absolutely no benefit
19:37 VanessaE    ok
19:37 VanessaE    that's the sorta thing I had in mind
19:37 VanessaE    just so long as 0.4.x and 0.5.x clients never see the same list of servers
19:37 VanessaE    zero benefit and a guarantee of nothing but headaches
19:37 sapier      poll seems to indicate breaking old clients is fine so I assume next version to be 0.5.0
19:37 celeron55_  in the case client support is dropped from an arbitrary point (a point that is so new that older clients than it are still in use), then we need to add client version to the masterserver query
21:12 ShadowNinja VanessaE suggested that this might be worth including as a tool: http://ix.io/avi  It deletes player files and auth entries that don't have interact.  It's written in C89.
21:12 ShadowNinja Example run: http://pastebin.ubuntu.com/6933421/
21:13 sapier      well C89 shouldn't be a problem as minetest uses C99
21:26 ShadowNinja I'll make it actually parse the priv string with strtok instead of just looking for "interact" in the string with strstr...
21:31 sapier      ShadowNinja: is there another way to do this: lua_pushlightuserdata(m_luastack, (void*) script_exception_wrapper); ?
21:32 ShadowNinja sapier: What do you mean?
21:32 ShadowNinja There's no other way to catch the exceptions and turn them into Lua errors properly.
21:32 sapier      you do a function pointer to object pointer cast there, this is not always correct
21:33 sapier      some architectures use different bitlength for functions and objects
21:33 sapier      I'm gonna add this "assert(sizeof(void*) == sizeof(int(*)(lua_State*,lua_CFunction)));" to make sure we'll detect this
21:34 sapier      but assert only works on debug build
21:35 ShadowNinja sizeof is compile time.  One sec...
21:35 sapier      the issue should be visible on compiletime
21:37 ShadowNinja sapier: http://pastebin.ubuntu.com/6933649/
21:37 sapier      I used clang to fix lots of warnings, e.g. usage of "," at end of enums ... there's no need to force c++11  compilers because of a comma
21:37 ShadowNinja That might work.
21:38 sapier      the ugly thing about fixing those warning is touching quite a lot of files for simple changes
21:39 sapier      nope :-) that won't even compile shadow ;-)
21:41 sapier      assert(sizeof(void*) == sizeof(int(*)(lua_State*,lua_CFunction))
21:41 sapier      && "Void* pointers have to be same size as function pointers!" != 0);
21:41 sapier      obvious enough?
21:41 ShadowNinja sapier: "Void* pointers" as in void**?  ;-)
21:42 sapier      :-) ok ok a pointer to much ... but it'd still be correct
21:42 ShadowNinja Just "Pointers" would be fine.
21:42 ShadowNinja Are you sure that the pointer sizes can be different?
21:43 sapier      ckoverflow.com/questions/13696918/c-cast-void-pointer-to-function-pointer according to this yes
21:43 sapier      http://stackoverflow.com/questions/13696918/c-cast-void-pointer-to-function-pointer
21:47 ShadowNinja The documentation that he quotes doesn't support what he says.
21:47 sapier      well officially you aren't even allowed to cast them :-)
21:48 sapier      the doc he quotes only tells about function pointer to function pointer casting
21:49 ShadowNinja Exactly.
21:50 sapier      http://stackoverflow.com/questions/12358843/why-are-function-pointers-and-data-pointers-incompatible-in-c-c there's the explanation why it's not allowed
21:50 ShadowNinja But you can cast them, and it states that.
21:51 sapier      yes as long as your compiler does it right, most time it wont even be a difference. In this special case you create a copy of that pointer within lua stack. I'm not that sure about this working correct in any case
21:51 sapier      e.g. if the fptr really is 64 bits and void* is only 32 bit's you'll loose half of function pointer on converting it back
21:52 sapier      I know this is a hypothetical scenario
21:52 ShadowNinja Hmmm, ok.  But this should be checked on compile time, no an assertion on start with debug builds.
21:53 sapier      true if you find a way to check it on compile time ;-)
21:58 sapier      http://www.pixelbeat.org/programming/gcc/static_assert.html what do you thing about ct_assert as defined there?
22:13 ShadowNinja That's doable, until we use C++11...
22:14 sapier      well I don't see why we should use a "," at end of a enum, it's just useless
22:15 sapier      I don't understand why this is allowed in c++11 either I see no usecase where this'd help
22:15 sapier      except of lazyness maybe :-)
22:22 ShadowNinja The comma at the end is so that you can add new entries by changing only one * num_new_entries lines of code.
22:23 sapier      as I said, lazyness ;-)
22:25 ShadowNinja No, that also makes diffs cleaner.
22:26 sapier      true still imho a separator at end is somehow unclean ... obviously I'm not part of majority as this was added to c++11
22:27 sapier      right now it just causes a lot of warnings if you don't switch compiler to c++ mode which hide the real issues
22:28 sapier      I managed to remove almost all clang warnings, except that function pointer cast
22:29 sapier      and variadic-macros (C99) as well as long-long ... which is c11 too
22:35 sapier      wrong long long is C99 too
23:29 VanessaE    sapier: Can we please get a decision on that patch soon?
23:30 VanessaE    (well not you but whoever we're waiting on)
23:30 sapier      the poll is open for about 5 days from now, there's no way to do a release without tracking down the recent luajit issues too
23:31 VanessaE    I mean the current patch
23:31 VanessaE    the one I've been running.
23:31 VanessaE    I need to know whether to keep running it, roll back to something else, or wtf to do here so I can point people at known, good code
23:31 sapier      no that one wont be added to master, I'll modify it to result of poll/decision beeing done uppon the result
23:32 sapier      keep it if you want to have your server compatible as long as possible
23:32 VanessaE    *facepalm*
23:32 VanessaE    n
23:32 VanessaE    no
23:32 sapier      if compatibility is broken by the new version noone will be able to connect till we release
23:33 VanessaE    I mean this:  https://github.com/minetest/minetest/pull/1143
23:33 sapier      I know
23:34 sapier      right now it seems like this one will be stripped by version support as well as all compatibility code
23:34 VanessaE    well it still needs merged
23:34 VanessaE    even if it'll be torn out later
23:34 sapier      no
23:34 VanessaE    I need to be able to point clients to good code
23:35 VanessaE    either that or I need to roll my servers back to a point where I don't need that patch
23:35 sapier      once this is merged no old clients will be able to connect ... thats price of decision
23:35 VanessaE    I mean for right NOW
23:35 VanessaE    not for some arbitrary date 6 months down the road when 0.5.0 actually goes stable
23:35 sapier      you will either have your server run a older version or not have any old clients till next release
23:36 sapier      I can't change it
23:36 sapier      I will not maintain both compat 0.4.9 dev as welll as 0.5.0 dev
23:36 VanessaE    that's not what I meant
23:37 sapier      then I don't understand
23:37 VanessaE    I need to be able to point people to a release or mainline commit and say "use this", without having to tell them to patch it.
23:38 sapier      ok then roll back to current master ... you'll have the initiall connect issues again but that's all
23:38 VanessaE    you mean the grey screen/"mainlist==NULL" issue?
23:38 sapier      yes
23:40 * VanessaE  sighs
23:41 sapier      well that's what "breaking compatibility" means ... you'll be stuck at a version prior that breaking commit till official release is done
23:41 VanessaE    yes
23:42 VanessaE    and I'm trying to establish the best possible point for that "stuck" point.
23:42 VanessaE    and right now, we're not there.
23:42 VanessaE    your patch going mainline would probably mark that best point.
23:42 sapier      if there was a point where everything did work we wouldn't have to break compatibility
23:42 VanessaE    THEN start ripping it apart :P
23:43 sapier      I will not add compatibility code in one commit just to remove it with next commit
23:43 VanessaE    um
23:43 VanessaE    you DO realize there will probably be dozens of commits between now and when you're ready to officially break it, right?
23:44 sapier      yes I do that's why I voted for compatibility changes ... I alwayst try to have n-1 compat ... but people are so afraid about complexity they don't even think about this
23:45 VanessaE    well all I know is right now most of my players can't see each other.
23:45 VanessaE    if I can't give them a build, commit, or something they can point their tablet client vendors to, what am I suppose to do?
23:46 VanessaE    supposed*
23:46 sapier      you can't avoid complexity in a game as feature rich as minetest, you have to find ways to manage it ... and that's what abstraction and clean interfaces are used for
23:47 sapier      switch your servers back to 0.4.9 till next version is released ... dev branch is nit meant for production. I'm sorry about this vanessa and understand your problem but I don't have a solution for it.
23:47 VanessaE    I can't do that and you know it.  0.4.9 is too old and crusty
23:48 sapier      and dev is unstable and incompatible
23:48 VanessaE    then the solution is staring us right in the face.
23:48 sapier      point them to current dev if all clients use it they'll work fine
23:48 VanessaE    merge 1143, release 0.4.10 with that, THEN start on 0.5.0
23:49 VanessaE    I will put my server at 0.4.10 and leave them there until 0.5.0 is ready
23:49 VanessaE    servers*
23:49 VanessaE    that way everyone will be happy
23:50 sapier      so we release 0.4.10 in unstable condition containing compat code just to release 0.5.0 not containing compat code a day later
23:50 VanessaE    no
23:50 sapier      both beeing unstable
23:50 VanessaE    0.5.0 won't be "a day later" and you know it
23:50 VanessaE    it'll be weeks, maybe months later
23:50 sapier      that's not what poll resulted
23:50 VanessaE    you and I both know how things go with this project :P
23:50 VanessaE    that's not what the *poll* says sure, but I'm basing this on what the actual history of this project says
23:51 sapier      people want breaking client compatibility doing it the way you suggest is bumping protocol version twice
23:51 VanessaE    you could declare "ok, we start 0.5.0 TOMORROW" but it'll still be 2-3 weeks later.
23:51 VanessaE    at the very least
23:51 VanessaE    for something as egregious as 0.5.0 will be, you're gonna need a much longer feature freeze than any of the previous 0.4.x releases got
23:52 sapier      I don't like this either but that's the reason why I did the poll, I don't want to fight for compatibility code noone wants
23:52 sapier      especialy if major core devs just consider it as "increasing complexity"
23:52 VanessaE    s/no one wants/few core devs want/
23:53 VanessaE    I neither like nor dislike it, all I'm saying is this needs a clear cut not just in the code but in the versioning
23:53 sapier      if it's gonna added the way it is now (removed version support) I see absolutely no reason to do a 0.5.0 version
23:53 VanessaE    you NEED a "final 0.4.x" release before you start on 0.5.0
23:53 VanessaE    and 0.4.9 is WAY too late!
23:54 sapier      why? how to explain but 0.4.10 could do everything as well as connect to old servers and new servers why did you break it in 0.5.0 without any benefit?
23:54 VanessaE    wait, what are you talking?  I thought the plan here was that 0.5.0 would "break everything" for the sake of finally getting the networking protocol and handshaking "right" once and for all?
23:55 sapier      you know as good as I that "once and for all" is an illusion
23:55 VanessaE    why explain?  did anyone really need to explain why 0.4.0 was not compatible with 0.3.x?
23:56 sapier      1143 already fixes everything that can be fixed and is necessary to be fixed
23:56 sapier      there's nothing to do more in 0.5.0
23:56 VanessaE    0.5.0 is about future-proofing, is it not?
23:56 sapier      the only difference would be removal of compat code
23:56 sapier      no it's only because of compatibility breakage
23:57 VanessaE    exactly - the idea is to make sure that this kind of thing doesn't happen again
23:57 sapier      if you find someone who is willing to guarantee this let her/him do it, I wont guarantee it
23:58 VanessaE    what have we got how?  http, udp and perhaps tcp soon for media transmission?  half a dozen versions to account for?  all this needs ripped all to hell and rewritten from scratch and reduced to one protocol that handles everything right the first time.
23:59 sapier      that's not gonna happen because there's nothing to rewrite, you mix up low level protocol to minetest application level protocol now
23:59 VanessaE    no one can guarantee it won't ever happen again, I'm just saying that I thought the whole point was to reduce complexity down to a point where it's unlikely to ever bug out like this again
23:59 sapier      the fixes breaking compat are not related to underlying protocol this issues happen no matter if you use tcp udp enet or any other protocol to transfere the data
23:59 VanessaE    yeah I know I conflate them a bit, but they go hand-in-hand you know