| Time |
Nick |
Message |
| 00:02 |
Exio4 |
what about https://github.com/BlockMen/minetest/commit/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/commit/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-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 |
| 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 |
