Minetest logo

IRC log for #minetest-dev, 2014-02-14

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

All times shown according to UTC.

Time Nick Message
00:02 Exio4 what about https://github.com/BlockMen/minetest/commi​t/24cd595f41079e22c871f70eb2f9219e79ba52a5 ?
00:06 iqualfragile joined #minetest-dev
00:52 EvergreenTree joined #minetest-dev
01:46 NakedFury joined #minetest-dev
01:56 Miner_48er joined #minetest-dev
04:13 ImQ009 joined #minetest-dev
05:14 iqualfragile_ joined #minetest-dev
06:42 Gethiox2 joined #minetest-dev
06:54 rsiska joined #minetest-dev
07:33 grrk-bzzt joined #minetest-dev
09:26 darkrose joined #minetest-dev
09:53 tomreyn joined #minetest-dev
10:32 Calinou joined #minetest-dev
10:40 PilzAdam joined #minetest-dev
11:20 proller joined #minetest-dev
11:20 troller joined #minetest-dev
11:20 Exio4 joined #minetest-dev
11:31 proller joined #minetest-dev
11:35 hax404 joined #minetest-dev
12:26 e1z0 joined #minetest-dev
12:32 e1z0 joined #minetest-dev
13:49 hmmmm joined #minetest-dev
13:50 werwerwer joined #minetest-dev
13:52 nore joined #minetest-dev
14:41 NakedFury joined #minetest-dev
14:50 Yepoleb joined #minetest-dev
14:56 Zeitgeist_ joined #minetest-dev
15:03 ImQ009 joined #minetest-dev
16:14 Jordach joined #minetest-dev
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)
16:22 Selah joined #minetest-dev
16:23 Selah left #minetest-dev
16:26 Selah__ joined #minetest-dev
16:48 Zeitgeist_ joined #minetest-dev
17:01 Miner_48er joined #minetest-dev
17:14 Miner_48er joined #minetest-dev
17:34 rubenwardy joined #minetest-dev
18:22 Calinou joined #minetest-dev
18:24 rubenwardy_ joined #minetest-dev
18:25 sapier joined #minetest-dev
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/commi​t/24cd595f41079e22c871f70eb2f9219e79ba52a5
18:43 rubenwardy joined #minetest-dev
18:57 Miner_48er joined #minetest-dev
19:05 Exio4 joined #minetest-dev
19:08 CheapSeth joined #minetest-dev
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:30 rubenwardy_ joined #minetest-dev
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 _rubenwardy_ joined #minetest-dev
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 rubenwardy joined #minetest-dev
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
19:46 grrk-bzzt joined #minetest-dev
19:56 rubenwardy_ joined #minetest-dev
20:29 NakedFury joined #minetest-dev
20:30 Jordach joined #minetest-dev
20:43 Jordach joined #minetest-dev
20:46 khonkhortisan joined #minetest-dev
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 Megaf joined #minetest-dev
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-c​ast-void-pointer-to-function-pointer according to this yes
21:43 sapier http://stackoverflow.com/questions/1369691​8/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/1​2358843/why-are-function-pointers-an​d-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/progr​amming/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
22:41 MichaelRpdx joined #minetest-dev
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 proller joined #minetest-dev
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

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