Time Nick Message 01:37 paramat c55: "we need to add features to the engine based on what subgames want to do" < mulitthreaded lua mapgen is a priority then =) 01:38 VanessaE paramat: and multithreaded mesh generation too 01:39 paramat eased 3d noise in mgv5 must have been added in c55's revival branch. i feel we should make non-eased the default: higher, more dramatic and faster, the option is still there for eased set in .conf 01:41 paramat 13hrs ago irealised i broke mgv7 biomes, the reason behind tenplus1's bugs, i need a day or two to fix 01:43 paramat hmmmm this is up to you of course but i would like to see simplex noise developed before/instead of the original slow perlin noise. simplex looks amazing, is not cubic-looking and is faster 01:44 paramat anything based on simplicies/triangles is awesome 01:44 hmmmm it's not faster 01:44 hmmmm hmmm 01:44 paramat okay wikipedia was wrong heh 01:44 hmmmm adding multiple meshgen threads should be trivial since that's an embarassingly parallel task (as opposed to map generation) 01:45 hmmmm wikipedia probably said that it's faster in the sense that it has a lower algorithmic complexity 01:45 paramat yes thats what it said 01:46 hmmmm but n^2 > 2^n for lower values of n 01:46 hmmmm we don't use anything greater than 3 dimensional noise 01:47 hmmmm its actual speed depends a lot on how well i'm able to optimize it in the same manner i optimized the original noise 01:48 paramat still much more interesting than another cubic-looking perlin noise, speed aside 01:48 hmmmm i don't think i necessarily need to use simplex noise to fix that 01:48 hmmmm i'm going to try cubic interpolation and see if that helps 01:52 paramat i actually prefer non-eased mgv5 to eased, is it okay to pull that small change for 0.4.11? 01:54 paramat oh hang on that will mean retuning the cave params and lava params, perhaps better left until after 01:55 paramat easing affects tunnel width and height of highest lava 01:56 paramat what could be done is un-ease terrain noise only 01:57 VanessaE hmmmm: well multiple mesh gen threads may be relatively simple, but actually I was suggesting splitting the one mesh gen thread from the rest of the client rendering tasks so that new block meshes don't kill client fps while they're being created. 01:57 paramat lava blobs look much better eased, uneased they are all thin and fragmented 01:59 paramat i'll make a pull for un-easing terrain noise only and leave it up to others to merge/not merge before 0.4.11 02:00 electrodude512 while we're on the topic of splitting stuff into threads, could you add a general way for mods to spawn lua functions in separate threads? 02:01 electrodude512 I'm working on a computer mod, and ideally computers should all run in a thread separate from the main server thread 02:08 electrodude512 if threads are added, would they share a lua environment (forked via LuaState* lua_newthread(LuaState*)) and use locks (define a lua_lock and a lua_unlock) or would they be isolated from each other? 02:08 electrodude512 for mapgen, they could probably be isolated, but for most other things they would be almost useless if they were isolated 02:11 electrodude512 http://lua-users.org/wiki/ThreadsTutorial 02:22 electrodude512 there's also [Lua Lanes](http://cmr.github.io/lanes/), which seems a lot easier and a lot less error-prone, it's basically isolated lua_States in separate threads with special "keeper" lua_States for communication between different threads 02:23 electrodude512 but it's obviously less natural than just multiple threads 02:25 hmmmm paramat, i'd really rather not... that's a very cosmetic change and you can modify it in your own config if you really wanted to 02:25 hmmmm electrodude512, sorry we can't do that 02:26 hmmmm unfortunately it's not as simple as making separate lua threads 02:27 electrodude512 yeah, I read about it, it looked too scary 02:27 electrodude512 but lua lanes looks good 02:27 hmmmm unless you could come up with a good way to make transactional environment accesses 02:28 paramat okay no problem, i was just wondering if it was important to be truer to the non-eased original. i still love the eased version 02:28 electrodude512 hmmmm: what do you mean by "transactional environment accesses" 02:28 electrodude512 why not just lua lanes? 02:29 hmmmm because there are large data structures with lots of contention in the core that must be locked while lua is executing 02:29 electrodude512 it's like having completely separate threads, except they can communicate (albeit what could be viewed as somewhat awkwardly through messages), instead of not being able to communicate at all 02:30 electrodude512 did you even look at lua lanes yet? 02:30 electrodude512 I agree with you, normal lua threads would be impossible 02:30 hmmmm it would be okay if only a single thread had access to the minetest api 02:30 electrodude512 ok, and have the rest talk to the one thread with the minetest api through lua lanes 02:31 electrodude512 but put the minetest api and the mapgen api in different threads, for obvious reasons 02:35 electrodude512 actually, does isolating the mapgen api and the rest of the minetest api into separate threads like that even make sense? 02:36 electrodude512 for ore and terrain gen it makes sense (but that's not in lua so who cares), but functions registered via minetest.register_on_generated need minetest.set_node and minetest.get_node 02:37 electrodude512 maybe put a lock on just the minetest api functions that mapgen needs? 02:37 electrodude512 or better yet, as many of the mt api functions as possible, and make the ones that proper, safe locking isn't possible for only available in one thread 02:38 electrodude512 s/as many of/for as many of/ 02:40 hmmmm it's really not that simple 02:40 electrodude512 why not? 02:41 electrodude512 what isn't? locking or threading in general? 02:41 electrodude512 the only problem with lua lanes is that both the mapgen and the main threads should have access to the mt api 02:41 hmmmm well the api that don't need to be locked is marked with NO_MAP_LOCK_REQUIRED 02:41 hmmmm everything else that doesn't have that needs to be locked when it's called 02:41 hmmmm which is the vast majority of the API 02:42 hmmmm i don't think you understand how much contention is exactly going on with the environment 02:42 hmmmm there are both read and write accesses hammering on it constantly 02:43 electrodude512 are we talking about just the map or the whole mt api in general? 02:43 hmmmm it's also been tried before, very early on... it ends up being slower to have individual envlocks around the apis than it is to just lock it once while lua is executing 02:43 hmmmm almost all of the api deals with the map 02:45 electrodude512 would you agree that the only problem, if we use lua lanes, is between the main and mapgen threads? 02:45 hmmmm no 02:45 electrodude512 and that any other threads can just talk to a server coroutine or something in the main thread instead of having any access to the mt api? 02:45 hmmmm lua lanes is not a silver bullet 02:46 electrodude512 what if you don't give additional lua lanes threads access to the mt api? 02:50 electrodude512 then how is there a problem? 02:51 hmmmm if api access is restricted to a single thread, then there is no problem. 02:51 hmmmm lua threads aren't constantly running in the background though 02:52 hmmmm you realize this right? 02:52 electrodude512 yeah 02:52 electrodude512 but I want one that is running constantly in the background for my mod, but it doesn't need mt api access 02:52 hmmmm hey - if you can get multithreaded lua working in a non-lame manner that's thread safe, i'm all for it 02:53 hmmmm this will work out for you, but the majority of the mods that do intensive processing need map access 02:54 hmmmm meaning it's not really worth it 02:54 electrodude512 I went back and read the irc history, and realized that VanessaE was talking about putting the non-lua part of the in a separate thread, not the lua part 02:54 VanessaE yeah 02:54 VanessaE well no 02:54 electrodude512 s/the in/the mapgen in/ 02:55 VanessaE I mentioned the mesh generator, not the mapgen 02:55 electrodude512 oh, yeah 03:00 electrodude512 I guess I was just too eager to talk about threads because they would be nice for my mod, and I got confused with stuff I was reading earlier today about people talking about mapgen happening in a seperate thread 03:01 VanessaE as for separate threads, you can do a sort of "cooperative" threading by using minetest.register_globalstep() 03:02 VanessaE as long as you divide your task into small pieces, watch dtime and dump out of your code when it gets too high 03:02 VanessaE plants_lib does this to reduce latency with its mapgen code 03:02 VanessaE but too much beyond this would be offtopic for this channel. 03:02 electrodude512 yeah, but that doesn't take advantage of a multicore cpu 03:03 VanessaE yes I know 03:05 electrodude512 not like it makes a difference for me, I only have a 2 core computer 03:07 electrodude512 i'll probably just do what you said about plants_lib and put the computer resumer function in a coroutine and coroutine.resume it a few times until it's taken too long 03:08 electrodude512 we're already using minetest.register_globalstep(), so it's a pretty easy change 03:10 electrodude512 if I find any other mods (or come up with any ideas for other mods) that could benefit from having multiple threads and don't need lots of map access, I'll think about making a fork and PR that adds lua lanes support (if I have time and if it's not too complicated) 03:14 VanessaE bbl 03:57 Bratmon I don't think you'll find that many mods that are processor heavy, but don't need map access. 04:03 electrodude512 yeah, a computer mod is really the only thing 04:04 electrodude512 that would 05:53 paramat hmmmm, please could you merge https://github.com/minetest/minetest/pull/1995 ? Re-add hacky fix for underwater grass, to fix mgv7 user's biomes 06:25 hmmmm sure 06:26 hmmmm when we branch our biome implementations out, i'm going to move generateBiomes() from mapgens to the biomemanager 06:26 paramat man i make so many mistakes :/ 06:26 hmmmm i'm going to solve that issue by re-querying biomes at points for which the observed height is not equal to the heightmap at that point 06:27 hmmmm how are you going to solve it? 06:27 paramat good idea 06:27 paramat that occured to me too 06:28 hmmmm also after the release i'm going to add a typedef for ManualMapVoxelManipulator so you might want to get all your pending code in before that change 06:28 hmmmm (i.e. lots of merge conflicts) 06:29 paramat so far my idea is in my biomeapinodes branch, each registered biome has 'node_underwater_top' 'node_underwater_filler', or just one underwater node 06:31 paramat my plans are a bt simplistic because i guess i'm a little limited by my level of C++ coding 06:32 hmmmm the concepts you're implementing are usually more important than how sophisticated the code for it is 06:32 paramat is one week after release fast enough to get my pending code in? 06:32 hmmmm yeah 06:32 paramat of course it may not be completely finished by then 06:33 paramat i was going to 'consult' players on my potential changes 06:34 paramat okay i'll try to wrap up and submit my current ideas soon after release 06:36 paramat so much to do! mapgen alone could be 2 full time jobs 06:38 paramat BTW nice ore veins, how did you generate those? 06:39 hmmmm i stole the general idea for v5 caves 06:40 hmmmm it's impossible to get nice output with 3d noise by itself 06:40 paramat nice 06:40 paramat in my lua mapgens i recalculate biome at each new surface found when working downwards 06:41 hmmmm when i first played minecraft classic and minetest, i always thought ores were grouped together 06:41 paramat before that it was at every node 06:41 hmmmm when i actually got into their design and implementation, i was diappointed that was just a blob of them and there were no veins 06:41 hmmmm this way you could actually find a "hotspot" for a certain ore and set up a mine there 06:42 paramat yes i like the idea of ores in certain areas 06:42 paramat i'm working on that in lua mapgen 06:51 paramat however my hotspots may be 1kn+ apart, i like to force players to travel whahaha 07:10 hmmmm well i can do that too by changing the spread factor parameters 07:10 hmmmm and increasing the threshhold 07:11 hmmmm what i have now is good because what you don't often realize is that nodes underground are much rarer than they seem when i generate them in air for testing 07:30 paramat yep 08:51 paramat hmmmm are spread values floats or integers? 'spread = {x=512.0, y=512.0, z=512.0},' this is for my noiseparams format example in lua_api.txt 08:52 hmmmm i think they're floats 08:52 hmmmm there's no practical reason why they should be though 08:53 paramat that's what i assumed since in higher octaves they are divided and so usually end up as gloats 08:53 paramat lol floats 08:57 paramat think i'll remove the decimal as few players will define spread as a decimal 09:00 Zeno` they are definitely considered as a float but I think in an example paramat might be right 09:01 Zeno` i.e. https://github.com/minetest/minetest/blob/master/src/script/lua_api/l_noise.cpp#L82 09:03 paramat okay hmmmm and others please review/merge https://github.com/minetest/minetest/pull/1982 there's more to do but i have more important things to do and the incorrect format should be removed before 0.4.11 09:06 Zeno` Format of 'size' for 2D perlin maps: {x=dimx, y=dimy, z=1} <--- is specifying the z=1 there necessary? 09:07 paramat i think hmmmm is working on making that unnecessary 09:07 Zeno` oh ok :) 09:07 hmmmm it is unnecessary 09:07 paramat oh heh 09:08 paramat really? you advised me to set it to z = 1, not remove it 09:08 Zeno` The only other thing that makes me ask myself a question is this: for 3D perlin maps the z component of 'size' must not equal 1 otherwise 'nil' is returned 09:08 Zeno` I'd rather know what valid values for z are 09:09 Zeno` or at least if they have to be > 1 09:09 Zeno` i.e. is 0 or -8 ok? 09:09 Zeno` Good to see a start to the documentation at last :) 09:09 hmmmm let's be rational here 09:10 hmmmm you're not going to set a negative size 09:10 Zeno` hmmmm, I'm looking at it from the point of someone who has never used it 09:10 Zeno` I mean, negative values are obviously not valid, but *shrug* 09:18 paramat ah: hmmmm wrote "the 'correct' way to do things would be to omit Z in the future" 09:18 Zeno` Anyway, my point was that maybe size must be > 1 might be clearer 09:18 paramat i was confused by: hmmmm wrote "for now I recommend you just set Z == 1 because people are probably going to run your mod on a version older than 0.4.11" 09:19 Zeno` I'm confused :) 09:19 Zeno` Oh I see, the documentation should take into account versions prior to 0.4.11? That would make sense 09:19 paramat okay will change, hmmmmm wrote "it just has a single ctor and the 'size Z' parameter has a default of 1@ 09:20 paramat *" 09:20 paramat well i think it should be written for 0.4.11 so i can omit the z = 1, since it is set to 1 by default 09:20 paramat will change 09:28 paramat zeno yes i agree for 3d noise size.z > 1 is clearer 09:31 paramat will change that too 09:34 Krock Pull #1990 is rebased now 09:34 ShadowBot https://github.com/minetest/minetest/issues/1990 -- Add language setting by srifqi 09:36 Krock Hmm interesting message: "10:37:33: ERROR[main]: MSVC localization workaround active restating minetest in new environment!" 09:36 Zeno` Looks strangely similar to https://gist.github.com/Zeno-/15645da139c390994b74 09:37 Krock Zeno`, I see you also had the problem with the Android setting 09:37 Zeno` yep 09:38 Zeno` oh.. which problem? 09:38 Krock space-problem 09:38 Zeno` Maybe; I didn't even test it :D 09:38 Krock just comment-out the android part <.< 09:39 Zeno` was only meant as a start for srifqi, but maybe he didn't get the link I sent him 09:40 Zeno` how did you rebase it? 09:40 Zeno` I mean, add it to the PR? 09:40 Krock he gave me the permission to do so 09:40 Zeno` oh, :D 09:40 Krock otherwise - haxx 09:41 paramat okay perhaps ready now https://github.com/minetest/minetest/pull/1982 09:42 paramat also don't forget https://github.com/minetest/minetest/pull/1995 oh hmmmmm has gone 09:42 Zeno` After more testing today, #1987 does increase performance on Linux but in a different area to where the optimisation has an effect on Windows (based on the .png in the PR) 09:42 ShadowBot https://github.com/minetest/minetest/issues/1987 -- Change TileSpec::frames to be std::vector not std::map by gregorycu 09:43 Zeno` So I think that should be merged before 0.4.11 release 09:43 Zeno` I'll add a thumbs up to the PR 09:44 Zeno` I'm ok with 1982 09:45 paramat pull 1995 is a bugfix to be merged for 0.4.11, it's tested and TenPlus1 will hopefully test it too 09:46 paramat thanks, perhaps best wait for hmmmmm to check 1982 09:46 Zeno` I don't even understand what 1995 does hehe 09:46 Zeno` yeah, I'm just saying I'm ok with it; I like it :) 09:47 Krock Zeno`, look at its codes, it prevents grassy nodes under water 09:47 paramat 1995: 18hrs ago i realised i had broken mgv7 biomes 09:47 Zeno` Krock, I understood that part; I don't understand what the issue was (and perhaps I don't want or need to, lol) 09:48 Krock -.- why not just use the 1st node below the top-node? for a grass biome, it would be dirt 09:49 Krock perhaps, this also would work for sand 09:49 paramat that was my idea Krock 09:49 Krock paramat, but you check for c_dirt_with_grass 09:49 Zeno` Has anyone else tested #1988? 09:49 ShadowBot https://github.com/minetest/minetest/issues/1988 -- Fix #1374 by adding a listpredict piece to the formspec by MinerDad7 09:49 paramat but it breaks TenPlus1's underwater layers of sand on gravel 09:50 paramat so hmmmm's hacky fix is going back in 09:50 paramat to act exactly as it did before 09:51 paramat however i will be modifying the biome api very soon in a backwards compatible way 09:51 paramat after release 09:53 paramat then multiple biome api's will be enabled and hmmmmm starts work on his new biome system to run parallel to my work 09:54 paramat for each mapgen base terrain players will have a choice of biome apis to use 09:54 paramat more choice and variety, no possibilities are lost 09:58 paramat best 1995 waits for hmmmmm's approval too 09:58 Krock ^ looks okay for me 09:59 Krock (except of the spaces in the noise definition) 10:02 paramat those spaces result in lined up code, don't worry 10:02 Krock :/ 10:04 * Zeno` tries not to fret 10:11 Zeno` Krock, try renaming your minetest.exe to mt.exe and run using mt 10:11 Zeno` Just for interest's sake 10:11 Krock even qwertz.exe runs fine 10:11 Krock changing it to mt.exe won't change anything 10:11 Zeno` it should not change anything 10:12 Zeno` I want to see if it does 10:12 Krock it doesn't 10:12 Zeno` you just tested it? 10:12 Krock it's quite simple to rename that stuff 10:12 Zeno` please, just rename it mt.exe 10:12 Krock I did 10:12 Zeno` and make sure you run it by typing mt and not mt.exe 10:13 Krock I can't run files without a .exe or .com tailing 10:13 Zeno` in the command line you cannot simply type mt? 10:13 Zeno` you don't normally type dir.exe in full do you? 10:14 Krock It could not find the command 'mt' 10:14 Zeno` weird 10:14 celeron55 why do you think that would have any effect? 10:14 sfan5 Zeno`: windows only runs .exe files 10:14 Krock and about the dir.exe, I can use both because it searchs for .exe, .com and .bat executables 10:15 sfan5 but you can omit the .exe when running them 10:15 Zeno` celeron55, It won't fix anything I'm just wondering about line 171 of gettext.cpp 10:15 Zeno` sfan5, and that's what I'm asking Krock to try :) rename to mt.exe and launch by typing mt 10:15 Krock Lool. renaming it to minetest.com gives funny errors 10:15 sfan5 Zeno`: that doesn't work because . is not in $PATH 10:15 Krock 11:17:11: ERROR[main]: Failed to restart with current locale: 10:16 Zeno` sfan5, I assumed he would cd to the correct path 10:16 Zeno` Krock, so that's an additional error? 10:16 Zeno` error/bug? 10:16 Krock Zeno`, 1 min. pressing printscreen 10:16 celeron55 wtf, why does this matter in anything 10:17 Krock No idea but it's funny to see that .exe thing in gettext.cpp 10:18 Krock because .com is a valid extention too 10:18 celeron55 nobody has used .com for anything since 20 years ago 10:19 Zeno` why does renaming it to mt.exe and launching with mt and getting an additional error matter? 10:19 celeron55 Zeno`: he renamed it to something.com 10:19 Zeno` I didn't ask him to do that :) 10:19 sfan5 Zeno`: afaik windows only searches for foobar.{exe,com,bat} files in the PATH when you type "foobar" 10:20 Zeno` I believe that renaming to mt.exe will result in Krock> 11:17:11: ERROR[main]: Failed to restart with current locale: 10:20 Zeno` and that is what I am trying to determine. I can't directly test this 10:20 Krock http://i.imgur.com/MP3o59u.png 10:22 Zeno` So, what's that do? Crash or just ignore the language change? 10:24 Krock minetest.exe closes the console window and does not throw any significant error while minetest.com coesn't close the console window and fails to load the new language 10:24 Krock *doesn't 10:24 Zeno` what about mt.exe? 10:24 Krock that acts like minetest.exe 10:25 Krock only the file extention is important in this case 10:25 Zeno` According to if (appname.substr(appname.length() -4) != ".exe") { not just the extension is important 10:25 Zeno` But if there is no error there is no error (even though according to the standard there probably should be one) 10:26 Zeno` *shrug* 10:26 sfan5 wtf is that msvc workaround even doing 10:26 Krock ^ 10:26 Zeno` relaunching minetest 10:26 Zeno` //very very dirty workaround to force gettext to see the right environment 10:26 Krock I think it tries to emulate a new system configuratoin with other language 10:27 Krock funny thing is, removing "language = de" setting solves the problem for me :) 10:27 Krock and the language in the menu does not change with that setting removal 10:27 sfan5 uhh 10:28 sfan5 wat 10:28 sfan5 why not just check whether argv[0] contains a . 10:32 Zeno` Anyway this change should, logically, trigger that dormant bug so if the language PR is to be merged that has to be fixed as well 10:32 Zeno` I need to set up a windows toolchain one day 10:33 sfan5 Zeno`: sudo apt-get install vagrant && vagrant init ubuntu/precise64 && vagrant up && wget http://meow.minetest.net/mingw_w64_x86_64_ubuntu12.04_4.9.1.7z 10:33 sfan5 there you go ;) 10:34 Zeno` I will try that when I install Ubuntu :D 10:34 sfan5 vagrant works on other distros too 10:35 Zeno` I kind of broke cross-compiling in yum (or somehow my yum databases got messed up) 10:35 Zeno` It was working a few months ago and not now 10:35 Zeno` Perhaps I should upgrade to fedora 20 10:40 celeron55 don't touch the workaround, it's very needed 10:43 Zeno` yes of course it's needed 10:43 Zeno` nobody was suggesting changing it I don't think 10:44 Zeno` well maybe just fixing the bug 10:49 kahrl why isn't it simply something along the lines of CreateProcessW(GetModuleFileNameW(NULL), GetCommandLineW(), ...) 10:50 kahrl well GetModuleFileNameW(NULL, buf, sizeof buf); ... CreateProcessW(buf, ...) but you know what I mean 10:51 kahrl gah, not sizeof buf, but sizeof buf/sizeof *buf 10:51 Zeno` :D 11:05 Zeno` Any comments on #1851? 11:05 ShadowBot https://github.com/minetest/minetest/issues/1851 -- Cleanup updateCameraDirection and fix random input not working by Zeno- 12:04 nore sfan5: I'm ok with #379 12:04 ShadowBot https://github.com/minetest/minetest/issues/379 -- Client tries to open mesh files from any path without check [edited] 12:05 sfan5 I'll merge it now 12:07 nore ok 13:17 Zeno` Can #1987 be merged? 13:17 ShadowBot https://github.com/minetest/minetest/issues/1987 -- Change TileSpec::frames to be std::vector not std::map by gregorycu 13:18 Zeno` Or, put another way, is there a reason for it not to be merged? 13:20 Krock Zeno`, the feature freeze. it could be labaled with feature... 13:20 Zeno` It's not a new feature 13:23 Zeno` Also, #1851 (bug fix) 13:23 ShadowBot https://github.com/minetest/minetest/issues/1851 -- Cleanup updateCameraDirection and fix random input not working by Zeno- 13:25 jin_xi hm, isnt a ff meant to test such changes in the absence of adding features? 13:25 Zeno` these are not features though 13:25 jin_xi anyways i find it strange to consider 1987 a feature 13:25 Zeno` 1851 certainly isn't 13:26 Zeno` it's not a feature :/ 13:36 celeron55 none of those are important for the release to be succesful, they can be just put in right after release 13:36 celeron55 then nobody has to worry about them at all 13:37 celeron55 and they will be 100% tested without any extra effort in 0.4.12 13:38 celeron55 it's generally a bad idea to try to overly minimize the "lag" from creating something to putting it in a release, because then people start expecting it and it will just cause extra stress to everyone involved 13:39 celeron55 (it should be a constant flow with enough time for every step) 13:39 celeron55 at the moment the release is supposed to go out at any moment 13:50 celeron55 (i'm guessing hmmmm will decide when as he's been generally doing that) 13:57 Zeno` yeah I guess random movement isn't exactly critical 15:31 Zeno` actually 15:31 Zeno` I think #1987 must be merged before 0.4.11 is released 15:31 ShadowBot https://github.com/minetest/minetest/issues/1987 -- Change TileSpec::frames to be std::vector not std::map by gregorycu 15:31 Zeno` There is nothing to test 15:32 Zeno` It's not a feature; it's an optimisation by choosing the correct data type 15:32 Zeno` not much different to changing something from using double to float 15:32 Zeno` s/using/changing 15:33 Zeno` std::map was just wrong 15:33 Zeno` "feature freeze" does not mean ignoring simple optimisations 15:46 Krock Zeno`, ask someone who would agree that. And then finally merge it :P 15:46 Zeno` I just asked :) 15:55 Zeno` Any objections to merging 1987 (a trivial change of data type)? 15:56 Zeno` (to a more appropriate data type? There is no reason whatsoever that should be std::map) 15:58 * Zeno` stages 16:29 Zeno` ok, no objections? 16:41 Zeno` ok, merging 16:51 kaeza what is the compiler used for official builds? MSVC? 16:52 Zeno` mingw 16:52 sfan5 kaeza: the offial builds use msvc 16:53 Zeno` they do? 16:53 sfan5 kaeza: the official mingw builds use ... surprise! .. mingw 16:53 sfan5 Zeno`: yes 16:53 Zeno` so... why is this not documented somewhere? All the docs and the repo suggest mingw 16:53 kaeza sfan5, if the main target is MSVC, I guess #1959 is not so much of a blocker, but it still could be fixed before release 16:54 ShadowBot https://github.com/minetest/minetest/issues/1959 -- Checking public serverlist checkbox causes minetest to freeze. 16:54 kaeza Zeno`, have you managed to get a working mingw environment? 16:54 Zeno` kaeza, yes and no 16:55 Zeno` kaeza, yes I can compile, but it does not run :) 16:55 kaeza Zeno`, you need to compile the C++ libs by yourself 16:55 kaeza the plain C ones work fine 16:57 Zeno` kaeza, I dunno. I followed the cmake errors installing stuff as it encountered errors. I'll reboot into Windows again tomorrow I guess 16:58 kaeza alright 16:58 Zeno` What would I need to compile that is not covered by cmake? 16:58 kaeza my build environment uses the same libs as sfan5's builds, except for C++ libs which I had to compile myself from sources 16:58 kaeza mainly Irrlicht I think 16:58 kaeza lemme see 16:59 Zeno` I disabled sound in Windows 7 17:01 Zeno` sfan5, who compiles the official Windows releases? 17:02 sfan5 Zeno`: BlockMen for MSVC and me for MinGW 17:03 Zeno` sfan5, that doesn't make sense. You said the official Windows release was MSVC... so how does mingw come into the equation? 17:03 sfan5 there is always msvc and mingw 17:05 Zeno` so how can a release happen on the 24th since Blockmen has been MIA for months? 17:07 kaeza Zeno`, I'd have to make a huge cleanup to my build env, but basically, I ran this ( https://gist.github.com/kaeza/11bb76e32d6996ccb7dd ), compiled Irrlicht and CURL, then mucked up in cmake-gui to point it to the new libs 17:07 kaeza it's just a modified buildbot 17:07 Zeno` thanks kaeza... bookmarked and I'll try again tomorrow 17:08 sfan5 Zeno`: if BlockMen doesn't turn up I'll have to install MSVC in a VM 17:11 Zeno` I'm just trying to understand, but isn't it unusual for there to be two official builds for Windows? How does the Windows user know which one to choose? 17:12 sfan5 MSVC is the preferred one 17:13 Zeno` If I was a Windows user and tried to install, say, Skyrim and I was presented with an option to choose between an MSVC build and a MinGW build I'd be baffled and probably not install either 17:16 sfan5 Zeno`: so you think it's too hard to click on a bold download link? 17:16 Zeno` sfan5, I'd think "why can't they decide" and not bother, yes 17:18 Zeno` A typical user would sit there baffled I imagine 17:18 Zeno` what is MSVC? What is MinGW? ARRGH too hard... can't decide 17:19 Zeno` I don't click on "Get Firefox" and get presented with a list of different compilers it was built with 17:21 Zeno` Because, as a user, why should I care? 17:24 kaeza I can agree that having two Windows builds is quite unusual. most software only provides one build (and most of the time they don't bother explaining which compiler is used) 17:25 kaeza is there a reason for that? (I'm not saying it's bad or good) 17:36 VanessaE why not just put the non-preferred link somewhere else on the page entirely? 18:07 Brat_Mon kaeza, the reason is because they (should) benchmark the two versions. 18:08 Brat_Mon And only use the better one. 19:45 Tesseract kaeza: The reason is that for some users MSVC runs a lot faster and for others MinGW is a lot faster. 23:38 kilbith the new ladder brings a nice optical illusion when wielded : https://cdn.mediacru.sh/U/UAtABt05mwna.png 23:39 kilbith signlike, and it seems like a nodebox model