Time Nick Message 00:02 hmmmm see, shit like this epitomizes freeminer's main failings: https://github.com/freeminer/freeminer/commit/89dd1d8f4bd71847ce63b80d57d08a0516d2d86e 00:02 hmmmm oh, there's a bug? fix the symptom, not the cause! 00:03 sapier *g* 00:03 sapier I learned all bugs you ignore strike back even more hard 00:05 sapier btw what do you think about how to fix https://github.com/minetest/minetest/issues/1132 00:07 hmmmm the right thing to do here would be to bump the protocol version 00:10 sapier and handle "older" clients special ... the sad thing about that way is the benefit is lost for all older clients which actually arent broken 00:11 hmmmm oh hrm 00:12 hmmmm this is a client issue, no...? what's wrong with always sending that packet regardless of the media transmission method? 00:13 sapier that's what I fixed for recent clients, but 0.4.9 clients don't do it 00:13 sapier they "forget" about it after downloading media 00:13 hmmmm ugh 00:14 sapier if there's nothing to download they're fine 00:14 sapier there may be another bug in current dev forgetting about the packet in curl mode but I'm not exactly sure about it 00:15 hmmmm what would sending the clients warning messages on an interval do to fix it 00:15 hmmmm see this really sucks 00:15 hmmmm once there's a bug we're stuck with it, because we can't make a patch or something 00:15 hmmmm we just tell people to download the newest version 00:15 sapier I added this but there's another issue spaming error messages in this situation 00:16 sapier so the notification may not be seen ... murphys law 00:16 hmmmm i don't know 00:16 hmmmm this is so screwed 00:18 hmmmm what's actually broken is the fact that we can't patch clients for big showstopping bugs like this 00:18 sapier the other issue is caused by my changes. I delay client init to avoid showing players in world prior they are ready .. but client step is started in parallel so it's missing some init data that are still "on wire" 00:19 sapier that situation isn't worth an error message now as missing hud info is now a temporary state only 00:19 hmmmm when does it get resent 00:19 sapier yes, we'd need a "autoupdate" at least telling users to update their client 00:20 sapier it doesn't have to be resent, it's sent right after TOSERVER_RECEIVED_MEDIA is received by server 00:20 hmmmm ohoh 00:20 sapier exactly 00:21 sapier if client doesn't send it it'll never finish it's join sequence 00:21 sapier 0.4.8 works fine 00:21 sapier latest works (with some bogus error messages I already have a patch to remove) 00:28 sapier but 0.4.9 will fail on first connect to a server 00:28 hmmmm i think we should integrate some statistics collection into minetest to see how many people are actually using which versions 00:29 hmmmm we should start 00:29 sapier we'd need to add major minor patch + flag stable/dev 00:30 sapier most simple way would be sending an additional packet TOSERVER_CLIENT_VERSION 00:31 hmmmm i don't want to make it seem too big brother tracking-ish but there should also be a uuid of each client so we don't duplicate entries when we aggregate the information 00:32 sapier hmm I'm not sure about this. we have IP,player name and version shouldn't this be good enough for some reasonable statistics? 00:32 sapier not perfect of course 00:33 hmmmm maybe a hash of the ip and player name 00:33 hmmmm just no personally identifiable information 00:34 hmmmm https://github.com/sapier/minetest/commit/56e23bed8faf47f5b1ec9064598b3669165072dc#diff-2543b17841165757ac531ffedd0b5fddR221 00:34 hmmmm eq 00:34 hmmmm ew* 00:35 sapier what did I do wrong there? 00:35 hmmmm why not have like const char *client_state_strs[] = { "Invalid", "Disconnecting", ... } lua_pushstring(L, client_state_strs[state]); 00:36 hmmmm also i dunno if it's intentional or not to have Disconnecting mapped to "Invalid" 00:36 sapier hmmm ... that'd been too simple to even think about it :-) ... you're right. I'll do it that way ... no that's a copy n paste error 00:36 sapier it's not ready for merge yet it's just been to show you how this could be done 00:37 hmmmm oh 00:37 sapier I'm working at a helper lua mod to administrate minetest from command line too but that's even less polished right now 00:39 sapier actually I just need the rtt and jitter information for benchmarking but why not make it a really usefull tool 01:02 hmmmm to this day i still WTF at some things i find in mapgen_indev.cpp 17:34 Megaf Hi all 18:33 sapier https://github.com/minetest/minetest/issues/1132 this issue is still open. Could some of the core devs please comment ? 18:34 sapier https://github.com/minetest/minetest/pull/1131 ShadowNinja I'm gonna merge this tonight if you don't have additional comments 18:41 PilzAdam sapier, I prefere 1), we have to bump the protocol before the next release anyway 18:43 sapier 1 has sideeffect that we can't fix the "uninit clients stand in world" issues for clients below 0.4.9 which aren't affected by the bug 18:43 sapier well I should mention this in the issue 18:45 VanessaE sure you can. 18:46 VanessaE don't let the player "appear" in the world, from the server's perspective, until you receive the first movement packet of some kind 18:46 VanessaE from the client's perspective, of course, just do whatever you normally would have done 18:46 sapier what do you think about hmmmm's suggestion making clients tell server about their version? The problem is we don't really like version numbers but for situations like the current one it's be great 18:47 VanessaE just don't send the announcement to everyone ELSE that the new client is there until the new client makes some kind of movement, or maybe responds to its first ping after the server thinks it has sent all of the media 18:47 sapier no I can't vanessae player appears as soon as the playercao is created 18:47 VanessaE why? 18:48 sapier that's why I delayed some init messages because I need information about that player cao to send it 18:48 VanessaE you're the server. Therefore, you are G*d. 18:48 sapier playersao 18:48 VanessaE you decide when you send the announcement to the *other* clients that are connected. 18:48 sapier because a playersao is just an active object and it's data is sent to clients along with all other active objects 18:48 VanessaE I'm not talking about what you send to the client that's just now connecting 18:48 sapier I don't intend to do a special handling for any sao 18:49 VanessaE you already know how to handle the connection handshake for the client that's just now connecting, regardless of the version of the client software 18:50 sapier I'd have to filter active object list for players, check against client state, and do this at each step ... well we don't need to try to improve performance if we'd add crazy things like that on the other side 18:50 VanessaE I'm talking about what to do about the announcement you send to everyone else who is already connected and actively playing. Why bother sending an announcement at all until the client can move? 18:51 sapier the "announcement" as in chat isn't the problem 18:51 VanessaE I don't mean that. 18:51 sapier the problem is the player itself as this is a plain active object 18:52 VanessaE if the server can show a player that is not able to actually *do* anything yet, the server's doing it wrong. 18:52 sapier no it isn't 18:52 VanessaE at least up until the point where the server knows for sure that the client can't, because it is e.g. still uploading media to the client. 18:52 sapier once a active object is created as of environments view its operational 18:53 sapier which is completely true there's nothing wrong about a standing still active object, all dropped items are same 18:53 VanessaE well from a technical standpoint of course not 18:53 VanessaE but these aren't just active objects. 18:53 VanessaE these aren't mobs we're talking about 18:53 VanessaE these are human beings. 18:53 sapier technicaly there's no difference 18:54 VanessaE well derp 18:54 VanessaE in th software they're the same 18:54 VanessaE but you can't treat them the same way from the users' standpoint 18:54 sapier well one difference, a playersao does load map while a luaso doesn't 18:54 VanessaE otherwise it just. plain. looks. wrong. 18:54 sapier no I HAVE to treat them same way ... any other solution will cause useless overhead 18:55 sapier that's why I delay playersao creation till client is initialized. having a player in env which isn't operational is useless 18:55 VanessaE that's what I'm trying to say 18:56 VanessaE delay the creation of that object until it can actually be used/moved 18:56 sapier that's what I do ;-) ant that's what causes one of the issues 18:56 VanessaE for an older client, delay it until the client answers its first ping or sends its first movement event or something else, idk what 18:56 VanessaE for a newer cliebnt, well it's obvious 18:56 sapier hmm 18:57 VanessaE I'm trying to say that if you are the server, you already KNOW that the client did or did not answer some request or perform some action you told it to perform :) 18:57 sapier abusing movement as replacement for missing init message ... not sure if it works .. but could be worth a try ... who's gonna tell users they need to move to join? 18:57 VanessaE within the limits of the network's lag of course 18:58 VanessaE why would you bother telling them? 18:58 sapier because they won't complete join unless they move 18:58 sapier well it's 0.4.9 only 18:58 VanessaE ok so create the object when they move OR chat then 18:59 VanessaE or anything else coming from the client that can't possibly be part of the media send/receive protocol 18:59 VanessaE is there a way to send a "special" ping packet? 18:59 VanessaE i.e. with some special tag? 18:59 sapier you can send anything but you won't get an anwer from a 0.4.9 client 18:59 VanessaE something that the client can respond to/echo back with the same value, that differs from the rest of the regular ping traffic I mean 19:00 sapier no 19:00 VanessaE damn. 19:00 sapier for new clients we can do anything that's not an issue but we don't need something for new clients but only for 0.4.9 19:01 VanessaE right 19:01 VanessaE that's what I'm trying to figure out 19:01 VanessaE well wait 19:01 VanessaE does the client answer pings AT ALL before media is finihsed sending? 19:01 VanessaE finished* 19:01 sapier yes ping is low level 19:01 VanessaE damn 19:01 VanessaE come on, work with me here :) 19:02 VanessaE and I don't mean, btw, ICMP 19:02 VanessaE I mean the server's own protocol 19:02 sapier me too 19:02 VanessaE ok, how about,. 19:02 sapier old clients/servers don't have any protocol state 19:02 VanessaE you know what order you're gonna send the media in 19:02 sapier so you can't decide from their behaviour if they're done 19:03 VanessaE just create the object right after the last file is sent, after you get the ack from that? 19:03 VanessaE just assume the client is "ready" at that point. 19:03 sapier no I don't know if a packet in send queue is a media packet or something else 19:03 VanessaE shit. 19:04 sapier that's how layering works, lower layers don't know about format of upper layers ;-) 19:05 VanessaE well unless there's some low-level protocol flag no one's mentioned, there's only one thing left - rely on incoming data from the chat, movement packets, and whatever else you can glean from the client to determine it's readiness state 19:05 sapier I'm gonna try about moving/chatting, but not sure if client will move a uninitialized player 19:05 sapier I can't even tell the player to move as he most likely wont see this message due to spamed console 19:06 VanessaE don't bother telling the player to mov 19:06 VanessaE move* 19:06 VanessaE the player will do that on his own anyway 19:06 VanessaE I've watched them 19:06 VanessaE the first damn thing EVERYONE does, if they don't say "hi" is they start looking around, trying to dig stuff, etc. 19:06 VanessaE believe me, telling them to move will not be ncessary :) 19:07 sapier try dig stuff without a visible map? 19:07 VanessaE oh right, the map 19:07 VanessaE shit 19:07 VanessaE well they will still try :) 19:07 sapier I don't know if this is gonna work but it's worth a try 19:08 * VanessaE thinks.. 19:08 VanessaE wait 19:08 VanessaE the first thing you do is teleport the client to the static spawn point, right? 19:08 VanessaE does not the client have to send back a packet that says "ok, I've moved to x,y,z" ? 19:10 sapier I'm not exactly sure but position may be sent after player init 19:11 sapier yes it's first thing to be sent after init complete 19:12 VanessaE meaning? 19:12 sapier movement may not be sent to server prior init at all 19:12 VanessaE ok, so we can at least use that to some degree 19:12 VanessaE but does that apply to the static spawnpoint? 19:13 sapier yes spawn position isn't sent prior init complete 19:13 VanessaE ok so we can use that 19:14 VanessaE send two events there. 19:14 VanessaE teleport the player to like 1,1,1 and then to the real spawn point. 19:14 VanessaE that way they will always be sure to move at least once. 19:14 sapier I can't telport "nothing" to somewhere 19:14 VanessaE fuck 19:14 VanessaE :D 19:15 VanessaE right 19:15 VanessaE but we have a hook now 19:15 VanessaE you can see where I'm going with this 19:15 sapier exactly the situation is completely messed up by now noone did really find a good option 19:15 VanessaE you wait for the first movement event....which we now know will be the static spawn point transport. 19:16 VanessaE wait, chicken and egg 19:16 VanessaE shit 19:16 sapier I'm quite sure I wont ever see a movement event but I'm gonna have a try 19:16 sapier maybe client is as buggy as server and sends movement events without beeing initialized 19:16 VanessaE maybe :() 19:16 VanessaE :)] 19:17 VanessaE wait 19:17 VanessaE hrm 19:17 VanessaE this bugs me. I can see a way here, somehow. 19:18 sapier well doing it this way any movement (on old and new clients) will cause the client to complete init 19:19 sapier not sure if pressing a cursor in load screen will result in movement event :-) 19:19 VanessaE heh 19:19 VanessaE I doubt it 19:19 sapier I'd not be too surprised 19:24 VanessaE I guess then what' 19:24 VanessaE I guess then what's needed is an extra flag attached to the player object that says whether it can be announced to the rest of the world. 19:25 VanessaE create the object as late as you can reliably do so, then flip the flag and announce it when the client will let you (e.g. when it responds to the teleport-to-(1,1,1)-then-to-spawn commands or something) 19:26 sapier no 19:26 sapier that's change for all active objects we have to live with forever just to fix a single broken version 19:26 VanessaE no? :) 19:28 sapier no that's not a sane option. I don't have a problem to add a workaround function but adding flags to a generic datastructure used for hundreds and thousands of objects is something completely different 19:28 VanessaE ok 19:29 VanessaE well I was only thinking of one bit tucked away somewhere off in no-man's land :) 19:29 VanessaE but I get your point 19:29 VanessaE if my idea of using movement/chat activity to complete the join doesn't work, then we're kinda screwed though 19:31 kahrl if I may ask, what are some of the cases where minetest would send TOSERVER_RECEIVED_MEDIA before httpfetch inclusion but wouldn't after? 19:32 sapier yes kahrl it was always sent before and afterwards it's only sent if everything was present right from start 19:33 sapier and it could still be broken for curl mode in current dev 19:33 sapier I didn't have time to investigate a issue sokomine mentioned that points to this direction 19:33 kahrl I don't remember it that way 19:34 kahrl I thought, without remote_media, it would never send it, and with, it would send it immediately (even before having received everything) 19:34 kahrl this seems correct, when looking at commit 0404bbf671 19:34 sapier well as far as I know it's been always sent after all media was received 19:35 kahrl sending it immediately was the reason for the bug with the .x files that VanessaE probably remembers 19:36 sapier there may be multiple bugs in this area 19:36 kahrl yeah 19:36 VanessaE kahrl: yep 19:36 sapier immediatly is as wrong as never send it ;-) 19:37 kahrl well not sending it is not always a bug 19:38 sapier VanessaE your idea could work, client is as buggy as client and sends position updates without knowing it's initial pos 19:38 VanessaE sapier: ah good, so maybe we can rely on that, then 19:38 sapier as of writing a simple protocol it is :-) 19:38 VanessaE sapier: why do I feel as if we just reverse-engineered the protocol a bit? :D 19:39 sapier of course you can always "guess" what state client is ... but it's way more easy to handle if you do correct handling 19:39 kahrl because the way the protocol works (worked?) is: the server considers the client initialized if TOSERVER_RECEIVED_MEDIA has been received or TOCLIENT_MEDIA has been sent 19:39 sapier yes but that was wrong 19:39 kahrl no, it wasn't wrong 19:39 sapier it is 19:40 sapier TOCLIENT_MEDIA isn't a single packet to be sent but will take some (more) time to complete 19:41 sapier therefore client isn't initialized completely 19:41 sapier that doesn't matter if you have just a few kb of textures of course ... but if its some mb it does 19:41 kahrl anything that requires the client to have all media is in reliable packets, isn't it? 19:42 kahrl so it would be delivered after the media anyways 19:42 sapier no it wont 19:42 sapier as reliable has multiple channels 19:42 kahrl are those actually used? 19:42 sapier yes that's been one of the most important fixes to reduce lag 19:44 kahrl I see 19:44 kahrl so it's a bug now 19:44 sapier no <= 0.4.8 seem to work fine 19:44 sapier it's only 0.4.9 19:45 sapier we should've investigated why pre0.4.9 couldn't connect to redcrabs server, we'd have found the issue before 19:45 kahrl there is no code in 0.4.8 to send TOSERVER_RECEIVED_MEDIA if remote_media is not used 19:45 kahrl so I don't know what happens 19:46 sapier you're talking about a texture pack? 19:47 kahrl huh? 19:47 sapier what do you mean with remote_media? 19:48 sapier curl based fetching or in protocol handling? 19:48 sapier or is there another option? 19:48 kahrl the setting in (the server's) minetest.conf as well as the field in TOCLIENT_ANNOUNCE_MEDIA 19:49 kahrl if that field is empty or the client is compiled without curl, TOSERVER_RECEIVED_MEDIA won't be sent 19:49 sapier ok I guess I wasn't aware of that issue maybe we have another bug to fix 19:50 sapier I'll check that server setting. 20:01 VanessaE sapier: and disable your damned proxy :P 20:09 sapier no :-) I don't wanna have your workaround problems ;-P 20:09 VanessaE hah! 20:09 sapier I'm fine with plain old minetest texture downloading :-) 20:09 sapier don't need curl to get my textures :-) 20:11 VanessaE well you're also gonna miss some protocol stuff if you don't 20:11 VanessaE you already know that...... 20:12 sapier well there are others who can find those issues maintainer doesn't mean I'm the only one to find and fix bugs ;-P 20:12 VanessaE true but if you're hunting a bug, you need a clean feed so you can see what the rest of us see :) 20:13 VanessaE kahrl: fwiw, I DID report the redcrab issue when it was first noticed; Sokomine brought it to my attention and I traced it back to your httpfetch commit :( 20:13 sapier I'll never see what all of you see as there are way to many possible variants ... some thing we should get rid about but can't 20:14 sapier well no need to blame anyone we all could've realized this to be a critical bug but didn't 20:14 VanessaE oh no no no, no blame at all. 20:14 VanessaE I just mean that no one chose to look into it (though it was acknowledged) 20:25 sapier vanessaE sadly your idea doesn't work, position is sent right from the beginning 20:25 VanessaE fuck. 20:28 VanessaE but wait 20:28 VanessaE you got the position from the client 20:28 VanessaE which means you have an active object already 20:28 sapier client has an object 20:28 VanessaE at that point, where do you stand? 20:28 sapier but server doesn't 20:28 VanessaE what does the server know about the client? 20:29 sapier by that time only it's peer id 20:29 VanessaE shit 20:29 VanessaE you're not making this very easy, sapier :) 20:29 sapier and protocol/serialization vesion but that won't help 20:29 sapier well I can't fix bugs to the past ;-) 20:29 VanessaE at this point, media has not been sent? 20:34 sapier no media hasn't been sent but client sends position 20:34 VanessaE ok 20:35 VanessaE not much to be done I guess 20:35 sapier no we're quite out of options 20:35 VanessaE give up and bump the protocol version. 20:35 VanessaE new server version, new clients only I guess. 20:36 VanessaE just make sure to fix the bugs that new clients get with old servers of course 20:36 sapier no only new clients isn't an option 20:36 sapier imho the only thing to decide is: 20:37 sapier accept 0.4.9 clients to fail and mak older clients work fine or make al clients behave bad but not fail 20:37 VanessaE you mena when connecting to old servers? 20:37 VanessaE mean* 20:37 sapier no old clients connecting to new server 20:38 VanessaE I dunno 20:38 VanessaE to my mind, if it can be fixed to behave the *right* way then it needs to be fixed. 20:38 VanessaE anything less is just plain wrong 20:39 VanessaE if that means older clients have to continue to behave wrongly (but with server workarounds to make sure they still work) then I guess that's what has to be done 20:39 sapier that's option two 20:40 VanessaE so current client on current server behaves perfectly right, current client on old server behaves as best as it can hope to, old client on current server behaves "wrongly" but still works, old client on old server just does what it's always done because we can't change the past. 20:40 VanessaE sound okay? 20:41 VanessaE (where "wrongly" means it appears in the world and just sits there until it can work, like it always used to) 20:41 sapier yes ... but old in this case puts all old clients to same behaviour ... while all but 0.4.9 would work 20:42 sapier unless we did increase protocol level for 0.4.9 20:42 VanessaE well do we really need to care if e.g. 0.4.8 works the same way as 0.4.9 does in this regard? 20:42 VanessaE just as long as it *works* I mean? 20:42 sapier all of your android clients are pre 0.4.9 20:42 VanessaE nope, some of those apparently are 0.4.9 20:43 VanessaE they have post-0.4.9 shaders e.g. waving leaves/water 20:43 VanessaE (yeah, it surprised me, too) 20:43 sapier hmm ok that changes situation 20:43 VanessaE I have such a client on my tablet. 20:44 sapier hmm we forgot to mention what changed in protocol version 22 20:44 VanessaE and when I last checked, those shaders required engine changes as well as the glsl code, so that puts them in 0.4.9-era code, no? 20:47 sapier1 hmm 0.4.9 could be identifyable by protocol version 20:47 VanessaE perhaps 20:47 sapier1 yes ... that's the option we've been looking for ... protocol was bumped to 22 at november 23rd 20:50 VanessaE November is rather a while back...... 20:52 sapier1 yes but post 0.4.8 and pre 0.4.9 20:54 VanessaE hm 20:54 VanessaE well 20:54 VanessaE I guess you could use that as a filter I suppose 21:13 ShadowNinja sapier: For your kick player pull you should use lua_tostring (as hmmm mentioned), add a comment after , and show the parameters and return value in the cumment above the declaration (// kick_player(name, [message]) -> success) Then you can push it. 21:14 ShadowNinja comment* 21:14 ShadowNinja (In header and source file, the ban functions have to be fixed, and maybe more, you can do that in a seperate commit) 21:15 sapier no I wont do that at all ... I've got enougth work about fixing network server issues ... I'll only fix the kick related things once I have time to do so 21:16 ShadowNinja sapier: As for bind_address: It shouldn't be in the menu as it's a very advanced feature. And it shouldn't be labeled "Address:", it should be labelled "Bind address:". 21:16 ShadowNinja I'll do it then. 21:16 sapier ok then I'm gonna drop that pull and rebase yours 21:17 sapier meanin you have to rebase yours 21:17 ShadowNinja What? 21:18 sapier I wont write that multiple times just because you don't like it... if you're that picky about adding a new feature you'll have to provide a mergable pull request yourself ... sorry if this sounds rude but I can't allways do all the work I have other things to do too 21:20 sapier It's a low prio enhancement while I tried to merge it but as it's not accepted I can live with it beeing out of master for some more times too 21:24 ShadowNinja I just asked you to remove the main menu section, but I'll remove it myself if I must. Just leave the pull up for a bit longer. 21:25 sapier I want that thing to be closed imho having a server option not available on gui is crap especialy if it's that easy to add. it's way more consistent 21:26 sapier if you start server in dedicated mode it'll be bound to port start same thing with gui not ... that's inconsistent 21:28 ShadowNinja I'll push your pull + http://ix.io/aiG and squashed in a few minutes. 21:29 ShadowNinja sapier: I don't understand your second sentence. But the bind address is a advanced option that only a few people will use and will only serve to confuse most users. 21:29 sapier seens to be fine 21:30 sapier those users won't see it 21:30 ShadowNinja And we don't want to bloat the GUI with options that most people won't use. 21:30 sapier it's just hard to explain why a server will ignore a setting if run in gui 21:30 sapier you didn't even try it did you? 21:31 sapier only those users which already set that address will see it 21:32 sapier noone else 21:48 sapier VanessaE you could try this fix for 0.4.9 clients https://github.com/sapier/minetest/tree/silence_hud_errormessage 21:49 Tesseract [16:33:51] That's better, but it means that we won't be able to put anything else at that position. And the label needs to be changed either way. 21:50 sapier what are you talking about? 21:50 ShadowNinja only those users which already set that address will see it noone else 21:51 sapier well I used only room already used now so you'd have to change layout anyway if you want to place something else there 21:52 ShadowNinja It overlaps with something? 21:53 sapier no I just split the now oversized "Port" field to two fields 21:53 sapier ok I increased it a little bit ... but that'd not be enough room to add anything else 21:56 ShadowNinja Alright. 21:56 sapier maybe we should ask for a third opinion 22:08 Calinou why not use : to separate address and port? 22:08 Calinou if none, use default port 22:08 Calinou (it is probably possible to detect IPv6 address) 22:08 sapier it's not about port but about ip binding 22:09 sapier e.g. if your server has a internet ip and a local ip 22:16 ShadowNinja It seems fine if it's done that way, as long as it's labeled Bind address and the 0.0.0.0/:: check is removed. 22:17 sapier well that check is there to reset the bind_addr setting 22:17 sapier both are the most simple way to write a bind all addr 22:18 sapier of course there are other ways to specify 0 addresses too 22:18 ShadowNinja Just empty the field. 22:18 sapier ok I'm fine with that solution too 22:33 ShadowNinja I added a reason field to the kick command: http://pastebin.ubuntu.com/6869744/ 22:33 ShadowNinja s//[reason]/ 22:34 sapier ok 22:37 ShadowNinja sapier: This is a bit over-indented, can you fix that? https://github.com/minetest/minetest/blob/ea0def381da04d3704a51b8a31a78ddd0737a06a/src/pathfinder.cpp#L63 22:37 sapier not yet 22:37 sapier it's fine for 4 space alingnment 22:38 sapier it's aligned to function length 22:39 ShadowNinja command_return_values updated... 22:39 sapier all parameters should be moved to next line, but I don't do code style fixes only ... if I did do that there's no end 22:40 ShadowNinja Yes, it shouldn't depend on tab width, it should be two tabs. 22:40 sapier code style not depending on tab width is a nice wish but only true within some limits 22:41 sapier but as I wont change anything now there's no need to discuss this again 22:42 ShadowNinja It doesn't. Although these's one file(script/common/c_content.h?) that keeps everything aligned perfectly with spaces, but everything is so spread out... 22:42 * ShadowNinja tries to fix #1111. 22:42 ShadowBot https://github.com/minetest/minetest/issues/1111 -- Allow custom types in minetest.register_craft 22:42 sapier we need a full doc of code style, reference to some more or less fitting kernel style is useless 22:43 sapier what's a custom type? 22:45 ShadowNinja Eg, minetest.register_craft({type="alloy", input={...}, output="..."}) 22:46 ShadowNinja Seems the types are built into the engine deeper than I thought though... 22:47 sapier if I remember correctly that issue has been discussed to death about a month ago 22:47 sapier resulting in "is possible but gives almost no benefit while breaking quite a lot" 22:49 ShadowNinja It lets you easily define your own craft recipes. And it won't break anything if done right. 22:50 sapier well try to find that discussin I believe it was on minetest. 22:50 ShadowNinja It's definitely very difficult to fix though... 22:52 sapier yes it's core functionality not lua 22:52 sapier the only way to fix it would be move it to lua ... with all consequences 22:53 sapier maybe adding some dummy "custom craft" type would be possible too ... but that be as hacky as technic does it 22:53 sapier it's quite useless to have it "look like" a core feature but actually do same 22:55 ShadowNinja I fixed #1099 instead: http://ix.io/aiP 22:55 ShadowBot https://github.com/minetest/minetest/issues/1099 -- Texture packs with "[" in the name causes the Texture Packs menu to not draw. 22:56 ShadowNinja sapier: Fine if I commit and push that? 22:56 sapier yes but I still think [] as folder name is crap :-) 22:57 ShadowNinja Maybe so, but no reason to let itbreak the menu. 22:57 sapier it's my personal opinion only so fixing it will not harm anyone 22:58 sapier especially as forbidding seems to be way more work then fixing 23:14 ShadowNinja Error in on_globalstep crash fix: http://ix.io/aiQ 23:17 sapier maybe that's the one still bugging me 23:29 VanessaE what's the word about the ${text} bug? 23:30 * VanessaE pokes sapier 23:30 VanessaE (I can't discuss the specifics here, logs) 23:39 sapier nothing done by now 23:39 sapier maybe shadow is interested in fixing? 23:40 sapier I need to get some sleep ;-) 23:40 ShadowNinja Hmmm, maybe... 23:44 ShadowNinja It looks like it won't work in current master, but I don't see xyzz's temporary fixer commit. 23:46 ShadowNinja Ah, sapier fixed it. 23:55 ShadowNinja This should fix it: http://ix.io/aiT 23:56 ShadowNinja I'd like to add proper in-string formating so that you can use "Locked chest (owned by ${owner})" and the like. 23:58 VanessaE that seems useful for infotext, yes 23:59 VanessaE ok