Time Nick Message 00:27 hmmmm https://github.com/kwolekr/minetest/commit/46a2c1f167f76b1ceb0164e9028b67eb6bf76e79 01:34 devmarth https://github.com/blokel/blokel/issues/2 01:34 devmarth Someone take a look at this? The error happened after messing around with camera.cpp to make the default camera view third person, but now even after switching it back, it still gives the error 02:21 hmmmm devmarth: Sorry blockel is not supported here 02:21 devmarth Lol, but the error would lead to the same place if it happened on Minetest right? hmmmm 02:22 hmmmm I dunno about that 02:23 hmmmm If you suspect there's an issue with Minetest, please post an entry on the Issues tracker on our GitHub page, at https://github.com/minetest/minetest 02:23 hmmmm Please post a complete description of the problem you are experiencing and steps to reproduce. 03:23 Zeno` hmmmm has two extra 'm's 03:23 hmmmmmm that means I disconnected twice 03:24 Zeno` :D 03:54 paramat hmmmm this is bemusing #2639 03:54 ShadowBot https://github.com/minetest/minetest/issues/2639 -- The mysterious patchy forests of the biome API 04:39 paramat aww yeah! solved, it was 'place centre x' 'place centre z', without these the bug is fixed 04:40 paramat something to do with those displacing the node check form the heightmap 04:40 paramat (from) 04:40 paramat which is why the bug is not present on a flat landscape =) 04:52 paramat it came to me while doing the washing-up 04:55 hmmmm heh 04:55 hmmmm it's probably time to pay down some technical debt 04:56 hmmmm i dunno about you guys but right now i'm working on noise unit tests and schematic unit tests 04:56 paramat i'll work on a fix 04:56 hmmmm it might not be so easy to fix, lemme check 04:57 paramat yeah, what i mean is 'attempt' 04:58 paramat my understanding is now commented in the thread 04:59 hmmmm so yeah, where a decoration is placed gets determined in Decoration::placeDeco, but the flags get applied in DecoSchematic::generate() 04:59 hmmmm i sort of expected a problem like this but wasn't exactly sure what 04:59 hmmmm i've dealt with this sort of thing before but apparently not all the cases 05:00 hmmmm so right now there are only two types of decorations, simple and schematic 05:00 hmmmm simple is a single vertical node column so it doesn't have this problem 05:01 hmmmm but when you think of all the future decorations, like lsystem trees and structures, they both have the same problem in common with schematics 05:02 hmmmm the abstractions currently supplied by Decoration are not sufficient 05:02 paramat the place_on checks are before flags are applied so the code order seems correct 05:04 paramat actually the order is not correct 05:05 paramat place_on check comes after flags are applied 05:05 hmmmm how is that an incorrect order 05:05 paramat (for schematics) 05:06 paramat position for place_on check is displaced sideways, therefore under/overground 05:08 paramat canPlaceDecoration should be used before flags apply 'place centre x/z' 05:08 paramat well shall i try it and see? 05:09 paramat rather, use if (!CONTAINS(c_place_on, c)) return 0; before flags applied 05:10 hmmmm wait, i'm not convinced 05:11 hmmmm how does the order of c_place_on matter? 05:11 hmmmm hrmm 05:11 hmmmm oh, it's checking the wrong thing 05:11 hmmmm we want to make sure the center of the tree, i.e. the trunk, is being placed on the correct thing 05:12 hmmmm so the pos we decided on earlier is where the center is going to be placed 05:12 paramat it is 05:12 hmmmm indeed, that's the problem. great job =] 05:12 paramat shall i fix? 05:13 hmmmm in any case, schematics are far from perfect. it's incredible how much attention they get and how much work they still need 05:13 hmmmm yes, while you're there however, take a look at vm->m_area.contains(p) 05:13 hmmmm that's wrong for schematics obviously 05:14 hmmmm it happens to work because blitToVManip() is careful and checks if each point is within the voxelmanip, but this could cause cutoffs 05:14 paramat ah should be limited to the mapchunk only 05:14 paramat ? 05:14 hmmmm no 05:14 paramat check if edges of schem are within the vm 05:15 hmmmm do contains() on the VoxelArea that the schematic is going to take up, not the precise point of the corner of the schematic 05:15 hmmmm contains() is overloaded and takes both a v3s16 and a VoxelArea & 05:15 hmmmm like i said. it's far from perfect. 05:16 hmmmm and now add rotations into the mix =] 05:16 paramat ugh 05:16 hmmmm then sokomine will come back in a couple days 05:16 hmmmm "hey this doesn't work with the specific combination of PLACE_CENTER_X and rotation for a facedir > 4! 05:17 hmmmm "but I never intended full rotations..." 05:17 hmmmm "oh also please hmmm could you add mirroring for schematics" 05:17 paramat (hehe) well i might tackle the rotations > 3 thing 05:17 hmmmm don't bother 05:17 hmmmm schematics were only designed for rotations along the Y axis 05:17 hmmmm it's way too much work for not much return 05:17 paramat okay 05:18 hmmmm anyway 05:19 hmmmm add a helper function like getRotatedSize() or something and check against that while still in DecoSchematic::generate() before applying center transforms 05:19 hmmmm that should do the trick for the edge case i mentioned earlier 05:20 hmmmm " hmmmm thank you so much for your work on schematics :) now can you add a lawn mowing function? i really need it for my villages mod and it would make it soo much better" 05:20 hmmmm lol 05:20 hmmmm :( 05:22 paramat :P well i can do the first 2 things.. to work 05:22 hmmmm it's not worth it to satisfy every single edge case possible 05:22 hmmmm this is what people do and they end up spending all their energy on it 05:23 paramat "just do something simple for now" 05:24 hmmmm "a working complex system invariably once started out as a working, simple system" 05:25 hmmmm if you try to plan too much from the get go it's going to be unsuccessful 05:31 paramat how about using canPlaceDecoration for decoschems also so they can use 'spawnby'? 05:31 hmmmm there was a reason why i didn't do that 05:32 paramat okay 05:32 hmmmm i forget right now why 05:32 paramat well it must have been a good reason 05:32 hmmmm oh right 05:33 hmmmm one of the reasons was because spawn_by makes no sense for schematics 05:33 paramat oh of course 05:33 hmmmm unless it's a vertical column 05:33 hmmmm lol 05:34 hmmmm schematics can have the same thing but it'd require special handling and it'd be a very computationally intensive check 05:34 paramat i won't for now 05:34 hmmmm i.e. you'd need to check the entire plane of nodes below the schematic 05:35 hmmmm for tress I suppose this doesn't make much sense because the stem is a single column, but how are you supposed to generalize that? 05:35 hmmmm trees* 05:36 paramat it wuld just be a rough check for spawnby nodes surrounding the schematic centre, possibly still useful 05:36 paramat (would) 05:37 hmmmm so maybe it can be generalized to all schematics, with the caveat that it only checks the neighbors of a *single* node at the exact spot where the translated position is expected 05:38 hmmmm and then schematics specifically gets a heavy, complete version that checks all nodes near the bottom plane 05:38 sfan5 Why Uppercase? 05:38 sfan5 And then PROJECT_NAME_LOWER almost everywhere 05:38 sfan5 It should be lowercase 05:38 sfan5 uppercase is just... silly :) 05:38 paramat nah i wouldn't bother, just check spawnby for nodes around the schem centre 05:39 paramat useful for trees 05:39 sfan5 I told ShadowNinja that this uppercase/lowercase stuff is stupid 05:39 sfan5 there was a comment on the PR saying that 05:39 sfan5 but apparently nobody read the PR before it was merged 05:40 hmmmm it's easy to fix though, just a simple find and replace pass 05:40 hmmmm I really wish people would focus on better documentation or unit testing instead of endless refactors 05:45 Zeno` ? 05:45 Zeno` oh, yeah. I don't think it should be uppercase 06:22 neoascetic hi all. what are "leveled" nodes? (minetest.add_node_level etc) 06:23 neoascetic ShadowNinja https://github.com/neoascetic/minetest/blame/master/CMakeLists.txt#L9-L10 doesn't "minetest" should be lowercased, like on github? 06:24 hmmmm neoaesthetic 06:24 hmmmm I ended up not being able to get minetest built 06:25 hmmmm how did you compile minetest on OS X? irrlicht fails because it can't find opengl/gl.h, for me at least 06:26 neoascetic dunno why u have a problems 06:27 hmmmm i really want to get this fixed (and in a non-hacky way) 06:27 neoascetic https://github.com/neoascetic/minetest/blob/builds/.travis.yml#L4-L12 06:27 neoascetic I am doing these steps usually 06:27 hmmmm ahh okay i'll try brew 06:28 hmmmm so your travis build works? 06:28 neoascetic yep 06:28 hmmmm maybe we could somehow get that integrated into our travis ci thing 06:28 hmmmm i don't like testing only 3 of the 4 major platforms 06:28 neoascetic we talked with est31 about this previously 06:29 neoascetic yesterday. with travis, it is kind of hacky and semi-legal way 06:29 neoascetic but possible 06:29 hmmmm bleh 06:29 neoascetic did you read this? https://github.com/minetest/minetest/pull/1928#issuecomment-66501792 06:29 hmmmm using mac os x is definitely not illegal, i hate it when people say that 06:30 neoascetic I am talking about travis integration 06:30 neoascetic they are out of Macs capacity. We don't hurt travis, do we? 06:30 neoascetic don't want to * 06:31 hmmmm it has something to do with "being a cocoa application" 06:31 hmmmm I'm sure there's a better way to do it than placing the file in a specific location 06:31 hmmmm like an api call or something 06:31 neoascetic yeh, I've tried to search yesterday, but with no success 06:31 hmmmm but as it exists right now, it breaks the entire point of RUN_IN_PLACE 06:31 neoascetic all links on irrlicht forums point to this workaound: build a .app 06:32 hmmmm when I figure it out I'll be sure to post about it on the forums 06:32 neoascetic the easiest way to solve this is to create Contents directory with build system if RUN_IN_PLACE == 1 06:32 neoascetic :) 06:33 neoascetic ok, I hope you will find a solution 06:33 neoascetic however, RUN_IN_PLACE is not a big issue for end user 06:33 hmmmm how do you get 'brew'? 06:33 hmmmm ah nevermind i have to insall it manually 06:33 neoascetic http://brew.sh/ 06:42 hmmmm does brew not support Lion or something? 06:43 neoascetic probably 06:43 neoascetic do you have Lion? 06:44 hmmmm yes 06:44 hmmmm I don't suppose there's any way to automatically update to the latest 06:45 neoascetic I think brew should be ok with Lion 06:45 neoascetic do you have an error? 06:45 hmmmm yes 06:45 hmmmm hrmm 06:45 hmmmm I can't copy and paste... 06:46 neoascetic use the mouse :) 06:46 hmmmm no it's vmware 06:47 hmmmm err virtualbox 06:47 neoascetic guest additions or something... 06:48 hmmmm doesn't work for osx 06:48 hmmmm http://www.fpaste.org/213675/29598893/ 06:48 hmmmm /usr/bin/install_name_tool: object: /usr/local/Cellar/jpeg/8d/lib/libjpeg.8.dylib malformed object (unknown load command 9) 06:49 neoascetic 2-5 lines 06:49 hmmmm tells me to get xcode 5.1.1 but i can't install anything more recent than 4.6 06:49 neoascetic you don't have to install entier xcode, just developer command lines tools or something like this 06:52 hmmmm i'm downloading mavericks 06:52 hmmmm this is gonna take a while 07:47 neoascetic hmmmm could you please download yosemite instead? 08:06 neoascetic Not sure if #2627 need to be merged. I have no problem with compiling minetest on Yosemite 08:06 ShadowBot https://github.com/minetest/minetest/issues/2627 -- Fix endian.h compile error on OSX and use native byte-swap functions on BSD by snowyu 08:07 neoascetic FreeBSD also works, as per CI report 08:10 neoascetic Altrough native byte-swap function should be a good idea 09:12 OldCoder Server list is built into core, correct? How would I apply to become a server list host? 09:13 OldCoder Rather, list of server lists is built into core 09:13 neoascetic OldCoder nope 09:14 neoascetic https://github.com/minetest/minetest/blob/master/minetest.conf.example#L318-L322 09:15 OldCoder neoascetic, there is a default server list 09:15 OldCoder Correct? 09:15 OldCoder You are linking I assume to the announce settings 09:15 OldCoder I am referring to *being* the server list, not to being *on* it; do you follow? 09:16 neoascetic serverlist_url 09:16 OldCoder Yes; and there is a default, correct? 09:16 neoascetic yep 09:16 OldCoder It is said that the current default server list server is bad 09:16 OldCoder I have run an octocore for several years now with numerous worlds 09:16 neoascetic improve it, code is on github 09:17 OldCoder Are the problems in the code? 09:17 OldCoder Or external? 09:17 neoascetic you said is bad 09:17 OldCoder I am told this 09:17 OldCoder At what level are the problems coming from? 09:18 neoascetic I don't know what problems you talking about 09:18 OldCoder And, regardless, is there a strong case for retaining the current server list server? Or for limiting it to one server? 09:18 OldCoder Vanessa and others have told me that the list is hosed 09:18 OldCoder That it does not work reliably 09:18 OldCoder If this is true, and if the problems are external, I will apply to host the list 09:19 OldCoder It can hardly be argued that I and my hardware are not qualified 09:21 neoascetic My idea is use heroku or something instead 09:28 OldCoder Heroku? O_o 09:37 celeron55 OldCoder: well i guess you now applied to become a server list host; however if people think there is a problem with the current server list's hosting, report to sfan5 (the current host) and me (because i manage the DNS) so that problems can be looked at 09:38 celeron55 i haven't really heard of such issues so i assume there is no need for any changes 10:10 celeron55 ...inspired by that, i now drafted this: http://www.minetest.net/reporting_issues 10:10 celeron55 comments? 10:10 celeron55 or additions? 11:36 paramat hmmmm #2640 here's the fix for issue 2639 11:36 ShadowBot https://github.com/minetest/minetest/issues/2640 -- DecoSchematic: Fix missing trees in rough terrain by paramat 11:41 OldCoder celeron55, thank you; I am falling asleep but will review 11:49 sfan5 <OldCoder> That it does not work reliably 11:50 sfan5 i didn't hear of any problems with the server list either 11:50 OldCoder sfan5, all right; I was under the impression this was well known 11:50 OldCoder Will seek specifics 11:50 OldCoder BTW Meowtest continues 11:50 sfan5 if there are problems it would make sense to tell me because i host the server list 11:50 sfan5 thats good 11:50 OldCoder Thank you for the information 11:51 * OldCoder is half asleep 13:22 est31 celeron55, fine site. I'll ask fdroid people to set it as the "report bugs here" url for minetest app. 13:23 est31 and Oldcoder, I guess there is a technical limitation: If we want multiple servers, we will need a mechanism for serverlist servers to share information about new servers, so that both serverlists contain the same servers 13:24 est31 one new minetest server will only report to one of the servers. 14:28 ShadowNinja ~tell neoascetic No, it's supposed to be cased like that because It's used like that in some places, it's more complicated to convert a lowercase version to mixed case, and that's its proper capitaliation acording to english style rules because it's a proper noun. PROJECT_NAME_LOWER is used largely for compatability reasons. It should probably be passed as a macro to avoid the runtime lowercase calls though. 14:28 ShadowBot ShadowNinja: O.K. 14:30 sfan5 " it's more complicated to convert a lowercase version to mixed case" not really 14:30 sfan5 "and that's its proper capitaliation acording to english style rules because it's a proper noun." 14:30 sfan5 I guess thats why every other thing (suck as package names) are uppercase too 14:30 sfan5 (hint: they're not) 14:31 ShadowNinja sfan5: Well, if you keep the current casing, but say a fork used casing like MineTest... 14:31 sfan5 then it's the problem of the fork 14:31 sfan5 we can't do stuff to solve problems that might happen if someone does something we did not forsee 14:32 * Zeno` emails Emacs because their package name and binary name is... emacs 14:32 ShadowNinja sfan5: Which they have to solve with a custom lower-to-upper function wich changes chars at specific offsets, instrad of just setting the name and having it automatically converted for everything. 14:32 Zeno` idiots don't know proper English 14:32 ShadowNinja sfan5: I *am* forseeing this! 14:33 sfan5 ShadowNinja: a fork might also want to change the name to something with utf-8 14:33 sfan5 where's the code for that? 14:33 ShadowNinja sfan5: Do I need to add some? 14:33 sfan5 you don't get it 14:34 sfan5 We CAN'T add code for every possible thing someone might do with PROJECT_NAME in the future in a fork 14:34 ShadowNinja The string lowering functions mught not work on non-latin characters, but other than that it should work. 14:34 sfan5 uh 14:34 sfan5 isn't the project name put into a std::string 14:34 sfan5 like 14:34 ShadowNinja Yep. 14:34 sfan5 we do have all that wide_to_narrow stuff for a reason, do we? 14:34 ShadowNinja wide_to_narrow is for Irrlicht. 14:35 ShadowNinja Everything else can use UTF-8. 14:35 sfan5 isn't the project name passed to irrlicht? 14:35 ShadowNinja Yes. 14:35 Zeno` well... it's not in my SDL fork 14:35 Zeno` but I guess that's another story 14:36 sfan5 anyway 14:36 ShadowNinja Zeno`: You got Minetest to work under SDL? 14:36 sfan5 this isn't the point 14:37 sfan5 ShadowNinja: irrlicht has an sdl backend 14:37 ShadowNinja Ah, O.K. 14:37 sfan5 the point is that we can't add stuff for every possible thing someone might do in a fork in the future 14:37 ShadowNinja But we can easily do this. 14:37 sfan5 that doesn't mean we should 14:38 ShadowNinja Why shouldn't we? 14:38 sfan5 because it's stupid 14:39 ShadowNinja Well, isn't that a nice, well thought out, logical argument for why we should change how we handle this! 14:39 ShadowNinja ;-) 14:40 sfan5 your argument for changing it to uppercase is just as bad 14:40 sfan5 someone could want to use GNU/Hurd with Minetest, quick, ass gnu/hurd support 14:40 sfan5 add* 14:42 sfan5 changing it to uppercase just complicates things 14:42 sfan5 there is no (good) reason to change it 14:42 ShadowNinja sfan5: Uh, didn't someone already fix Hurd support? 14:43 sfan5 yes, it was just an example anyway 14:43 ShadowNinja I don't understand how this relates to the casing thing. 14:44 ShadowNinja It works well as it is now, and you'd be removing a fork support feature by changing it. 14:44 sfan5 " you'd be removing a fork support feature by changing it." 14:44 sfan5 huh lol 14:44 sfan5 "we added it, not we can't remove it again" 14:44 sfan5 now* 14:45 ShadowNinja The only thing that I think should be changed is adding a PROJECT_NAME_LOWER macro to the source so that lowercase() doesn't have to be called at runtime. 14:45 sfan5 "some fork may want to have a mixed-case name, quick, add support for it to the CMake files and change a lot of stuff" 14:45 sfan5 "someone might want to use Minetest with Minix, quick, ass minix support" 14:45 sfan5 ShadowNinja: ^ better? 14:46 ShadowNinja sfan5: I don't understand what you're trying to argue. That we shouldn't add features unless a lot of people are asking for them? 14:47 sfan5 not exactly that but basically yes 14:53 ShadowNinja sfan5: I disagree, and this patch kills and performance difference: http://sprunge.us/XZXR?diff 14:53 sfan5 i know that you disagree 14:54 sfan5 i don't dislike the change for performance reasons 14:54 ShadowNinja sfan5: What do we gain by befaulting to lowercase? 14:54 sfan5 nothing 14:54 sfan5 except that the zip is no named Minetest-something.zip (which looks stupid) 14:55 sfan5 ShadowNinja: what do we gain by defaulting to uppercase? 14:55 sfan5 (some fork might want to use it is a bad argument) 14:55 sfan5 s/use it/do this and that/ 14:55 ShadowNinja sfan5: If you don't like that just change the PROJECT_NAME to PROJECT_NAME_LOWER in the relevant line in CMakeLists.txt 14:56 ShadowNinja sfan5: How is that a bad argument? 14:56 sfan5 it's the "someone could possibly want this, let's add it" thing i tried to explain 14:57 sfan5 it might be a feature (if you even want to call it that) 14:57 sfan5 but nobody uses it 14:57 sfan5 so it's an useless feature 14:57 sfan5 and I don't think that somebody will use it in the near future 14:59 ShadowNinja sfan5: It means that we don't have to add it later, and at this point we'd be removing a feature. We could rename NAME to NAME_UPPER if that would make you feel better. 15:00 sfan5 i told you the reasons i dislike the change for 15:00 sfan5 it's not the variable name and not (exclusively) the folder name 15:00 ShadowNinja sfan5: You fine with the PROJET_NAME performance fix I just linked? 15:00 sfan5 no 15:00 ShadowNinja sfan5: Why not? 15:01 sfan5 I disagree with the basic upper-case change 15:01 sfan5 adding/changing more code will only make it harder to remove 15:01 sfan5 also 15:01 sfan5 sfan5: It means that we don't have to add it later 15:01 sfan5 we won't have to add it later 15:02 sfan5 because it's the forks problem if they want to change something the code currently doesn't support 15:02 Zeno` line 49 has a bug... should be checking for sizeof(buf) - 1 (or >=) 15:03 ShadowNinja sfan5: This is what you want? http://pastebin.ubuntu.com/10861815/ 15:03 sfan5 yes 15:03 sfan5 except 15:04 sfan5 why do we need the uppercase stuff in the cmake file? 15:04 ShadowNinja Because it's used un uppercase! 15:04 ShadowNinja Eg with minetest --version and the upper left text. 15:04 Zeno` line 49 of http://sprunge.us/XZXR?diff I mean 15:05 sfan5 ShadowNinja: we didn't have an uppercase thing in the cmake files before 15:05 ShadowNinja sfan5: Yes, because "Minetest" was hardcoded. 15:06 sfan5 un-hardcoding that doesn't justify to put it into the cmake files 15:06 ShadowNinja ... 15:07 ShadowNinja Where else should it be? 15:07 sfan5 i don't know 15:08 ShadowNinja Does that performance fix seem fine now? (that beg Zeno` mentioned was in a context line) 15:08 ShadowNinja bug* 15:09 Zeno` yeah, I wasn't saying it was related 15:10 Zeno` Can someone change the relational operator at https://github.com/minetest/minetest/blob/master/src/porting.cpp#L483 from > to >= please? (I can't right now) 15:10 Zeno` err maybe I can edit on github 15:11 Zeno` nah, I'd rather not do that 15:11 Zeno` too scary 15:11 ShadowNinja I'll do it, as long as you're sure this won't break it :-) 15:12 Zeno` it won't break anything unless the bug is a feature :) 15:12 Zeno` https://msdn.microsoft.com/en-us/library/windows/desktop/ms683188%28v=vs.85%29.aspx 15:13 ShadowNinja Hmmm, len == sizeof(buf) seems to be undefined. 15:14 ShadowNinja It returns the length needed, which should be more than you passed it. 15:14 ShadowNinja Since the length includes the NUL. 15:14 Zeno` the length returned, yeah. So it should be >= 15:15 Zeno` if sizeof buff == 5 and whatever the env var is is "12345" it will return 5 (meaning there is no NUL and buf was not large enough) 15:16 ShadowNinja Zeno`: But len == sizeof(buf) means "the buffer was too small, I need a buffer at least `len` in size to store the full string and the NUL" 15:16 Zeno` correct 15:16 ShadowNinja But the buf is that size! 15:16 ShadowNinja So it should be an impossible return value. 15:16 Zeno` no 15:17 Zeno` The size of the buffer pointed to by the lpBuffer parameter, including the null-terminating character, in characters. 15:17 ShadowNinja It returns 6 if the string's "12345". It includes the NUL. 15:17 Zeno` If the function succeeds, the return value is the number of characters stored in the buffer pointed to by lpBuffer, not including the terminating null character. 15:18 ShadowNinja ...fails... the return value is the buffer size, in characters, required to hold the string &and its terminating null character* 15:18 Zeno` So to me that means "12345" would return 5 15:18 ShadowNinja Zeno`: If the buffer was at least 6 chars long, yes. 15:19 ShadowNinja If not it would return 6. 15:19 Zeno` hmm 15:21 Zeno` ok 15:22 Zeno` carry on :) 15:25 ShadowNinja Zeno`: You O.K. with my patch? 15:31 Zeno` That was a patch? 15:32 ShadowNinja Zeno`: Yes, the lowercase(PROJECT_NAME) -> PROJECT_NAME_LOWER 15:32 Zeno` I wasn't really paying attention. Umm. Hmm. I don't think it does much :) 15:33 Zeno` I mean it does get rid of the call to lowercase, but who cares in that context? :) 15:34 Zeno` There is nothing wrong with the patch though, if you want to ask that question :P It's 1:35AM here and I'm not really here 15:38 sfan5 ShadowNinja: "(me on github) You probably need to change fewer lines when adding a capitalize function." 15:38 sfan5 i just counted through the changes 15:39 sfan5 you changed project_name to project_name_lower or project_name to lowercase(project_name) 29 times 15:39 sfan5 only to add project_name in some places 15:41 sfan5 s/some/16/ 15:52 sfan5 ShadowNinja: what about this? https://github.com/minetest/minetest/pull/2641 16:28 hmmmm oh shit 16:28 hmmmm noise is broken for lacunarity < 0.1 16:28 hmmmm 1.0 rather 16:28 hmmmm ofactor should = min{L^i} for i=0..n-1 where L is the lacunarity, n is the number of octaves 16:29 hmmmm here I mistakenly assume that the maximum value will be the maximum octave number 17:00 hmmmm https://github.com/kwolekr/minetest/commit/90a0187ca191b73073db64d71e071fee72aae091 17:10 hmmmm pushing... 18:05 Krock #2642 fixes a bug which appeared with commit 386d695 18:05 ShadowBot https://github.com/minetest/minetest/issues/2642 -- Fix crash on startup (Windows) by SmallJoker 18:06 hmmmm why would that cause a crash?? 18:07 hmmmm isn't that an indication of a much larger problem? 18:07 Krock Bug reported here: https://forum.minetest.net/viewtopic.php?p=176721#p176721 18:08 Krock '/' is not '\\', thus, the function to remove the exeutable name from the path does not work correctly 18:08 hmmmm how how does that cause the crash 18:08 Krock "dir .." on a filepath is not addepted 18:08 Krock *accepted 18:09 Krock *cd .. 18:09 Krock I tested my changes and it solved the problem 18:10 hmmmm yes but my point is that if a certain input is causing a crash, that should be fixed as well in addition to producing the correct input 18:14 Krock hmmmm, http://stackoverflow.com/questions/875249/how-to-get-current-directory -> the used function "GetModuleFileNameA" returns the path with the executable name 18:15 hmmmm what? i didn't say anything about that at all 18:16 est31 I understand what Krock means. 18:16 Krock Okay, now am I just sitting here and dunno about the actual target. 18:16 Krock est31, thank you :) 18:17 hmmmm can you explain because I don't. GetModuleFileNameA has nothing to do with the application crashing because a certain piece of a string wasn't removed 18:18 est31 hmmmm, as it seems, the function getCurrentExecPath returns the path of the executable. 18:18 Krock Well, that function is called to get the path. pathRemoveFile(buf, '/'); was previously used to remove the executable name from the string; if there's no '/' inside, there won't be anything cut away -> crash 18:18 est31 the windows implementation is done with getCurrentExecPath 18:19 est31 and yes what Krock said, the code assumes directory delimiters to be "/" 18:19 est31 this isn't portable 18:19 Krock exactly. 18:19 hmmmm Krock: Then the bug is inside of pathRemoveFile(), which I did not modify at all 18:20 * Krock facepalms 18:20 hmmmm .... 18:20 hmmmm I don't think we're understanding eachother 18:20 hmmmm A function crashes because of some kind of invalid input. This is called a bug. 18:20 Krock Yeah, same thoughts on here 18:21 est31 ERROR[main]: cannot open D:\MineTest\bin\minetest.exe\..\builtin\init.lua: No such file or directory 18:21 Krock Maybe I should move the pathRemoveFile() function to the Win32 code of getCurrentExecPath() 18:21 est31 ^ thats the error 18:21 hmmmm I understand completely that looking for '/' instead of the platform-specific char did expose the bug, and this was a trivial oversight that's easily fixed 18:21 Krock to make it clear for everybody 18:21 hmmmm est31: That isn't a crash 18:21 est31 AsyncWorkderThread execution of async base environment failed! 18:21 est31 thats the crash 18:21 hmmmm that is not a crash. 18:22 hmmmm that's an exit after some kind of initialization failure. 18:22 est31 ah yes 18:22 Krock Oh well, it opens a crash dialog after thowing the Lua errors 18:22 est31 for end users it is a crash. 18:23 hmmmm Maybe there's some kind of slight language barrier here or something but 18:23 hmmmm when you say the word "crash", this means, to me at least, that the application abnormally terminated due to a SIGSEGV, or SIGILL, SIGABRT, or simmilar 18:23 hmmmm having an error and then terminating is not a crash. 18:25 hmmmm moreover, *if there was a crash* in pathRemoveFile because the character to remove wasn't found in the string, the correct response would be to both a). fix the root cause of the crash, and b). fix the erroneous circumstances creating the edge case that exposed the crash to begin with 18:25 Krock I think that's counted as a crash: http://i.imgur.com/fRhQf8P.png 18:25 hmmmm that's happening elsewhere 18:26 hmmmm it looks to me like it could be an unhandled exception causing a SIGABRT 18:27 Krock sorry, I'm not familiar with SIG* terminations 18:27 est31 I think you mean its like #2636. I could fix it with a single line commit, but there is a deeper root cause which that "fix" would leave unchanged. 18:27 ShadowBot https://github.com/minetest/minetest/issues/2636 -- Verbose logging bloated regression 18:28 est31 what* 18:28 hmmmm yes, a deeper root cause 18:29 hmmmm either patching over the symptoms of a bug or correcting the input that caused a crash to occur but not doing both is not an appropriate fix 18:29 hmmmm of course, this is within reason 18:30 hmmmm if you had defined a function stringcopy(char *s1, char *s2) { while (*s1++ = *s2++); }, I don't think anybody would fault stringcopy() for defending against NULL parameters. 18:31 hmmmm however, I would argue that it's VERY reasonable to expect pathRemoveFile() to not crash or cause some kind of undefined behavior if the character wasn't in the string 18:31 hmmmm the former makes an assumption about preconditions; the latter would be shoddy coding 18:32 Krock If I may ask, what would you do in this case? 18:34 hmmmm simply not modify the string it's supposed to be modifying. 18:34 hmmmm that's what it actually does. in my last paragraph, I was only speaking rhetorically. now that I have the additional information that the crash was actually a program abort due to an initialization failure, this makes your fix totally sufficient 18:40 kahrl I guess all instances of pathRemoveFile can be replaced by fs::RemoveLastPathComponent 18:41 kahrl which handles both '/' and '\\' (the latter only on windows) and is unit tested 18:43 hmmmm agreed, also the "abnormal termination" that is commonly mistaken for a "crash" that happens when mainmenu lua fails to initialize is not very user friendly. I recommend that on Windows, at least, it should pop open a modal MessageBox explaining the error 18:43 est31 lua is part of the engine 18:43 est31 if it has a fatal error, you can't run it anymore 18:44 est31 but yes messagebox sounds good 18:45 est31 also kahrl's idea 18:46 est31 btw, why isn't filesys.{cpp,h} inside util? 18:47 est31 porting should be there too I think. 18:48 kahrl I thought about moving them but at the time there were a number of PRs for them 18:48 kahrl not sure how many there are now 18:48 hmmmm probably none. none as far as i'm aware of 18:49 hmmmm i think we should begin the (slow) process of reorganizing the directory structure 18:49 hmmmm right now I'm splitting test.cpp up into individual files for each thing being unit tested and putting them into a 'unittests' directory 18:50 hmmmm so basically whenever we are confident there aren't any PRs that modify a certain file, we can move it into its correct place (i.e. client/ or server/) 18:50 kahrl sounds like a good plan 18:51 kahrl maybe have some kind of mini-roadmap that shows how the directory structure should look like once this process is finished 18:52 hmmmm will do 18:57 Krock kahrl, I'm not sure if it's the best way to convert the char* to std:string to use "fs::RemoveLastPathComponent()" and then again backwards to not break the other platforms codes. As far as I see, only the Windows part returns a file path. 20:06 OldCoder est31, thank you 20:11 ElectronLibre To anyone who might be interested game#494 is updated with a better way to store flowers' datas and some little fixes to Ombridride's code. 20:11 ShadowBot https://github.com/minetest/minetest_game/issues/494 -- Simplified flowers registration by LeMagnesium 20:43 OldCoder est31, unless the server list servers were designed to report to each other. But this is probably for longer-term discussion. 20:44 est31 yes 20:44 est31 it is possible to make them do that, yes indeed. 20:47 OldCoder Thank you 21:33 luizrpgluiz chatting with colors will be very good at the game 21:39 kahrl another unreviewed commit by nerzhul? 21:46 luizrpgluiz gave me the github link for me to see what will be the new version of minetest, then I read the news :) 22:11 hmmmm alright that's it 22:11 hmmmm i hate to be the one to do this 22:13 hmmmm https://github.com/minetest/minetest/commit/e0eec201a18a0741114094b600f765313a838bfb 22:26 VanessaE ouch. 22:42 hmmmm we tolerated it too much 22:43 VanessaE well, I can't say I disagree with you having reverted it. 22:43 VanessaE just not used to seeing an outright "all right, byte me" response like that :)