Time  Nick      Message
00:01 paramat   #4239 has been updated
00:01 ShadowBot https://github.com/minetest/minetest/issues/4239 -- Use mathematical function to determine yaw direction by sfan5
02:01 hmmmm     paramat:  i don't need on_mapgen_init
02:02 hmmmm     [07:25 PM] <est31> hmmmm, what I'm not getting is: we already have a settings class   what do you mean?
02:03 hmmmm     it uses two Settings, and creates Params by combining them
02:04 hmmmm     i'm wondering if it's overbuilt, but i did that mostly for the sake of being able to add a unit test
02:04 hmmmm     not sure if it's a good choice though
02:05 est31     hrmm
02:05 est31     well, its not overcomplicating too much
02:06 est31     its only partial code so i might not be right with my assumptions about what it does
02:06 hmmmm     what are your assumptions?
02:06 hmmmm     the class itself is complete pretty much
02:06 est31     hmmmm, it essentially is an interface between the global settings (or the map local settings) and the mapgen, right?
02:06 hmmmm     hrmmm
02:07 hmmmm     i guess you could say that
02:07 hmmmm     the intent was to have an object that'll take different sources of configuration and combine them all in the correct order
02:08 est31     before, it was spread over mapgen code?
02:08 hmmmm     no
02:08 hmmmm     before it was scattered between ServerMap, EmergeManager, and other bits and pieces
02:08 est31     ok
02:08 hmmmm     the mapgen doesn't actually have anything to do with this bit of code
02:08 est31     I see.
02:08 hmmmm     the only thing the mapgen does here is consume the MapgenParams that it generates
02:09 est31     okay then
02:09 hmmmm     see i wanted to just shove it all into either EmergeManager or ServerMap
02:09 hmmmm     but then it wouldn't be unit testable
02:09 est31     your idea sounds good
02:09 hmmmm     what do you think about all the different getMapSetting and setMapSetting things
02:10 est31     I'm not super keen on getting it unit testable, but i do think that its its own independent unit of functionality
02:10 hmmmm     should i get rid of them and have the lua apis interact with the settings objects directly?
02:10 hmmmm     they take up a lot of lines of code for something very mundane
02:10 hmmmm     and wrapper-ish
02:10 est31     yeah
02:11 hmmmm     and one last thing
02:11 hmmmm     so here i moved the ownership of MapgenParams from the EmergeManager to the ServerMap
02:11 hmmmm     how do you think i should get it over to the EmergeManager now
02:12 hmmmm     should the EmergeManager request it from the ServerMap?
02:12 hmmmm     that would then require the IGameDef it gets passed to be a Server
02:12 hmmmm     whereas right now it's any IGameDef
02:12 hmmmm     so theoretically an EmergeManager right now could run on the Client
02:13 hmmmm     or, should the ServerMap call something in the EmergeManager instead?
02:13 est31     how do they usually interact
02:13 hmmmm     there is no usual
02:13 est31     i have no clue
02:13 hmmmm     right now it's a hodge podge and horribly architected
02:13 hmmmm     there is no architecture right now
02:14 hmmmm     there's no clear set of dependencies from one object to the other
02:15 est31     idk i dont think its a big issue how these two communicate
02:15 hmmmm     go in map.cpp, ctrl+F m_emerge, you'll see it used in a variety of contexts, such as for the MapgenParams it owns, or to get a pointer to the thread-local mapgen, or to queue up a block, etc.
02:15 est31     its nothing relevant we give backwards compat for
02:15 hmmmm     but do the opposite, go into EmergeManager and search around for Map access, it doesn't access any map directly except for within EmergeThread
02:16 hmmmm     of course not
02:16 est31     so we can change it if it doesnt seem to be good
02:16 hmmmm     sure, but i want to make a decision i'm satisfied with instead of changing it every week
02:17 hmmmm     and this makes me wonder
02:17 hmmmm     "what is the actual purpose of EmergeManager?"
02:17 est31     true
02:17 hmmmm     "what is the actual purpose of ServerMap?"
02:17 hmmmm     ServerMap right now does way too much different unrelated stuff
02:18 hmmmm     EmergeManager was that way too until this patch
02:18 hmmmm     actually it still is until I make the Mapgen owned by each individual EmergeThread
02:18 hmmmm     so EmergeManager is almost like EmergeThreadManager and MapgenManager
02:18 hmmmm     and up until now it was also the MapgenParamsManager
02:19 hmmmm     too much middle management :p
02:19 hmmmm     fire the incompetent middle managers i say
02:22 est31     :)
02:23 hmmmm     honestly I'm leaning toward having the EmergeManager "get" the MapgenParams from the ServerMap
04:36 hmmmm     that sounds like a good plan, to get the map generating parameters from the map
04:38 hmmmm     but it's not so clear because EmergeManager knows nothing of Map, and that would require a whole lot of additional dependencies it did not have before
04:38 hmmmm     whereas the opposite way around, ServerMap already uses several EmergeManager facilities - is this *correct*?
04:41 hmmmm     probably, this is fine, because EmergeManager is the interface with which you talk in order to defer some kind of map loading to the background
04:41 hmmmm     of course the Map should know about it
04:42 hmmmm     and as such, the proper way to *use* the EmergeManager is to tell it how you want your map to be generated when it does need to
04:42 hmmmm     i.e. pass the MapgenParams in the constructor
04:42 hmmmm     but it exists much earlier than that
05:40 paramat   merging game#1155
05:40 ShadowBot https://github.com/minetest/minetest_game/issues/1155 -- Default: Add stone / desert stone / sandstone / obsidian blocks by paramat
05:42 VanessaE  paramat: I believe moreblocks has, at the very least, the 'stone block' (as 'stone tile' I think)
05:42 VanessaE  just FYI
05:43 VanessaE  (it also has a couple of subdivided variants)
05:43 paramat   yeah, i checked moreblocks and there was nothing identical
05:44 paramat   just seen an error, updating PR
05:45 VanessaE  https://github.com/minetest-mods/moreblocks/blob/master/textures/moreblocks_stone_tile.png
05:45 VanessaE  not identical in appearance, but in function at least.
05:47 VanessaE  ..and it can be cut with the table saw also.
05:47 VanessaE  Calinou: *poke* ^^^^
05:55 paramat   ok i didn't realise it was a full node, because of the name
05:56 paramat   merging game 1155
06:01 paramat   done
06:32 paramat   hi Zeno` #4239 has been updated, possibly mergeable now
06:32 ShadowBot https://github.com/minetest/minetest/issues/4239 -- Use mathematical function to determine yaw direction by sfan5
06:36 Zeno`     I'm ok with it
06:36 Zeno`     no
06:36 Zeno`     it should be static
06:36 Zeno`     static const char *direction[4] = {"North [+Z]", "West [-X]", "South [-Z]", "East [+X]"};
06:39 Zeno`     It was basically incorrect before sfan's changes :/
06:39 Zeno`     well, not really
06:39 Zeno`     the static is so the array is not initialised every time the function is entered but the compiler (probably) does that anyway. May as well make it explicit though
06:43 Zeno`     sfan5?
06:44 hmmmm     Zeno`, an implicit conversion from type const char * to std::string is operator const char *()
06:44 Zeno`     may as well have it that in the first place though since that's what it returns
06:44 hmmmm     which is implemented in 99.999% of libstdc++s as std::string(const char *)
06:44 Zeno`     no, it was the other way around
06:44 Zeno`     std::string being returned
06:45 Zeno`     from a non-static local array... which seemed a bit strange
06:45 Zeno`     The function has always been inline static const char *yawToDirectionString(int yaw)
06:46 Zeno`     and it was returning a std::string that was in an array... hence my conversion question
06:46 hmmmm     wait a minute
06:46 hmmmm     oh that's a stale comment
06:46 Zeno`     yeah, for some reason it didn't auto hide
06:46 hmmmm     for some reason i thought it was the opposite, the return value was std::string and the type being returned was const char *
06:47 Zeno`     it's no longer applicable so I have no idea why github didn't hide it :/
06:47 Zeno`     nah, was the other way around originally
06:47 hmmmm     probably because the line you attached the comment to wasn't modified
06:47 Zeno`     oh I see
06:48 hmmmm     hrmmm
06:48 VanessaE  paramat: I forgot to ask, those blocks you added, are they meant to be rough-cut, or smooth?
06:49 VanessaE  (I ignore the fact that they're derived from existing textures)
06:50 paramat   they're meant to match bricks, but see comments i'm considering smoothing the texture of stone and maybe desert stone
06:51 paramat   the stone block looks a little too rough
06:51 VanessaE  I suppose so yeah
06:52 paramat   i mean, i'm considering smoothing the textures of stone/desert stone bricks and blocks
06:52 VanessaE  well, if you do that, I'll have to update HDX :P
06:52 VanessaE  (the stone bricks there are rough-cut)
06:52 paramat   i like to think of bricks and blocks as being fairly smooth and polished
06:53 VanessaE  perhaps separate, smooth versions are warranted.
06:53 paramat   i'll open a new PR/issue for these considerations
06:53 VanessaE  I had in mind that stone bricks were rough because you cut them from solid stone without any tools besides a pick or something
06:53 VanessaE  i.e. no polishing tools present
07:50 Zeno`     sfan5, *thumbs up*
07:51 sfan5     note that i didn't test whether that function produces correct results this way
07:51 Zeno`     by being static?
07:52 Zeno`     will make no difference (only possible an optimisation that any modern compiler would probably do anyway :))
07:53 sfan5     no in general
07:53 sfan5     with the maths
07:53 hmmmm     committing untested code?
07:54 sfan5     it wasn't originally my pull
07:54 sfan5     i just made a "pull request" with a zipped cpp file into a proper one
14:16 Fixer     !tell paramat You forgot about panels and slabs :) https://i.imgur.com/MssKkUO.png
14:16 ShadowBot Fixer: O.K.
14:21 everamzah you trying to make a PR, fixer? :D
14:21 Fixer     everamzah: no, will wait for paramat
14:22 everamzah did you already do it for that screenshot?  or is that moreblocks
14:22 Fixer     everamzah: x-decor
14:22 everamzah of course!  (/me tests them in workbench now)
14:25 everamzah i forget how, but xdecor/workbench interfaces with stairs mod somehow
14:25 everamzah (aaand, i'm in the wrong channel -- sorry)
15:50 hmmmm     hrmm
15:51 hmmmm     does anybody agree with the statement:  a getter method shall not result in side effects on an object
15:52 est31     yeah
15:52 est31     maximum side effect should be that there is a lock held as long as the getter is running
15:53 est31     that is a side effect, but a very small one
16:17 hmmmm     i agree
16:17 hmmmm     i forget where exactly but i thought i saw some getFoobar()s that do work the first time and return the cached results thereafter
16:19 est31     well thats okay as well
16:19 hmmmm     what makes it okay though
16:19 est31     its a chaching layer
16:19 hmmmm     that's clearly in violation of the principle we first stated
16:19 est31     it has no side effects
16:19 est31     except that it modifies the cache variable
16:20 hmmmm     how do you know that
16:20 est31     but that cache variable is only modified by the setter, and maybe the constructor of the class
16:20 hmmmm     what if the object the getter is called on sets the state of the object
16:20 est31     as in?
16:21 hmmmm     like creates a network connection
16:27 est31     thats bad
16:27 est31     I mean it really depends on the actual case, but generally its best to have getters dumb as possible
16:29 hmmmm     well if that were the case then getters would all be 'return variablehere;'
16:29 hmmmm     but i find that redundant which is why my code echews such getter/setter boilerplate
16:30 hmmmm     i don't personally say anything about the complexity of getters, just that they have minimal side effects
16:30 hmmmm     if it is more complex in implementation then maybe it'd be best as a calcFoobar instead of getFoobar method
17:53 MoNTE48   Hi guys
17:54 sfan5     hi
17:57 MoNTE48   I am interested in destiny of Android version
18:00 MoNTE48   If I was given the name in the credits or acquired the right to speak in the community face to block those who violate the LGPL on Play Store, I could pass MultiCraft code Minetest and release Minetest 0.4.14 in Play Store
18:01 sfan5     iirc
18:01 sfan5     if you have code in the android version of minetest
18:02 sfan5     you can use DMCA
18:02 sfan5     regardless of the credits
18:03 MoNTE48   It is difficult to prove to Google that I am the author of the code on github. They work very stupid people
18:04 MoNTE48   My designer has blocked a lot of people for stealing 1 32x32 texture. I spend a lot of time and can not always protect my work.
20:49 hmmmm     why is the ServerEnvironment created after mods run exactly
20:50 hmmmm     i can't tell if there's an actual reason or it's just because
21:06 paramat   Fixer nore sfan5 i think we can use the new block textures for stairs and slabs https://i.imgur.com/MssKkUO.png
21:06 Fixer     +1
21:07 paramat   i was already considering making slabs look like slabs
21:07 paramat   will make a PR
21:08 sfan5     yeah those look nice
21:20 paramat   nore sfan5 can anyone confirm this is good? game#1153
21:20 ShadowBot https://github.com/minetest/minetest_game/issues/1153 -- Update .gitignore to ignore additional ide/editors by t4im
21:25 sfan5     paramat: those in the "GNU global" section don't seem useful to me
21:25 sfan5     others are ok
21:25 paramat   ok
21:27 paramat   since we're lacking an android dev and since monte48 is interested in being more official perhaps we can consider something? http://irc.minetest.ru/minetest-dev/2016-06-25#i_4638268
21:34 hmmmm     monte48 isn't an android dev though
21:34 hmmmm     he hired somebody else to do the dev work for him
21:34 hmmmm     so i'm not really sure where the value added is
21:37 paramat   he may be coding it himself now IIRC not sure
21:38 paramat   i might make a post on the forum asking for talent
22:11 T4im      the gnu global stuff is removed, paramat
22:11 paramat   ok thanks