| 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 |
| 00:38 |
|
sloanonlinux joined #minetest-dev |
| 01:10 |
|
jin_xi joined #minetest-dev |
| 01:43 |
|
Miner_48er joined #minetest-dev |
| 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 |
| 02:52 |
|
Void7 joined #minetest-dev |
| 03:00 |
|
yang2003 joined #minetest-dev |
| 03:38 |
|
Void7 joined #minetest-dev |
| 04:34 |
|
davisonio joined #minetest-dev |
| 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 |
| 04:44 |
|
jin_xi joined #minetest-dev |
| 04:49 |
|
Thomas-S joined #minetest-dev |
| 05:15 |
|
davisonio joined #minetest-dev |
| 05:38 |
|
paramat joined #minetest-dev |
| 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 |
|
nrzkt joined #minetest-dev |
| 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:17 |
|
Zeno` joined #minetest-dev |
| 06:18 |
|
Gundul joined #minetest-dev |
| 06:25 |
|
Gundul joined #minetest-dev |
| 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:35 |
|
davisonio joined #minetest-dev |
| 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 |
|
ssieb joined #minetest-dev |
| 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 |
|
Hunterz joined #minetest-dev |
| 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:10 |
|
paramat left #minetest-dev |
| 07:50 |
|
burli joined #minetest-dev |
| 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 |
| 07:54 |
|
MarS joined #minetest-dev |
| 08:08 |
|
Thomas-S joined #minetest-dev |
| 08:37 |
|
Krock joined #minetest-dev |
| 08:48 |
|
PilzAdam joined #minetest-dev |
| 08:55 |
|
Thomas-S joined #minetest-dev |
| 09:05 |
|
Puka joined #minetest-dev |
| 09:07 |
|
asl97 joined #minetest-dev |
| 09:23 |
|
domtron__ joined #minetest-dev |
| 10:26 |
|
davisonio joined #minetest-dev |
| 10:39 |
|
red-001 joined #minetest-dev |
| 10:52 |
|
Fixer joined #minetest-dev |
| 11:01 |
|
domtron__ joined #minetest-dev |
| 11:36 |
|
xunto joined #minetest-dev |
| 12:12 |
|
ElectronLibre joined #minetest-dev |
| 12:13 |
|
davisonio joined #minetest-dev |
| 13:07 |
|
damiel_ joined #minetest-dev |
| 13:17 |
|
davisonio joined #minetest-dev |
| 13:27 |
|
nrzkt joined #minetest-dev |
| 13:39 |
|
hmmmm joined #minetest-dev |
| 13:46 |
|
ShadowBot` joined #minetest-dev |
| 13:48 |
|
yang2003 joined #minetest-dev |
| 13:50 |
|
dmurph_ joined #minetest-dev |
| 13:50 |
|
cheapie_ joined #minetest-dev |
| 13:51 |
|
jomat joined #minetest-dev |
| 13:51 |
|
DonBatman_ joined #minetest-dev |
| 13:51 |
|
sfan5_ joined #minetest-dev |
| 13:53 |
|
Icedream joined #minetest-dev |
| 13:53 |
|
jomat joined #minetest-dev |
| 13:57 |
|
yang2003 joined #minetest-dev |
| 14:10 |
|
Void7 joined #minetest-dev |
| 14:16 |
Fixer |
!tell paramat You forgot about panels and slabs :) https://i.imgur.com/MssKkUO.png |
| 14:16 |
ShadowBot |
Fixer: O.K. |
| 14:17 |
|
domtron joined #minetest-dev |
| 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) |
| 14:44 |
|
sloanonlinux joined #minetest-dev |
| 15:46 |
|
est31 joined #minetest-dev |
| 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:10 |
|
davisonio joined #minetest-dev |
| 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 |
| 16:34 |
|
davisonio joined #minetest-dev |
| 16:46 |
|
Grandolf joined #minetest-dev |
| 17:30 |
|
davisonio joined #minetest-dev |
| 17:36 |
|
Lunatrius joined #minetest-dev |
| 17:52 |
|
MoNTE48 joined #minetest-dev |
| 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. |
| 18:06 |
|
davisonio joined #minetest-dev |
| 18:07 |
|
Miner_48er joined #minetest-dev |
| 18:10 |
|
Player_2 joined #minetest-dev |
| 18:11 |
|
Krock joined #minetest-dev |
| 18:12 |
|
davisonio joined #minetest-dev |
| 18:31 |
|
KaadmY joined #minetest-dev |
| 18:52 |
|
halt_ joined #minetest-dev |
| 18:52 |
|
halt_ left #minetest-dev |
| 19:33 |
|
Void7 joined #minetest-dev |
| 19:40 |
|
red-001 joined #minetest-dev |
| 19:55 |
|
MoNTE48 joined #minetest-dev |
| 20:12 |
|
Miner_48er joined #minetest-dev |
| 20:28 |
|
Puka joined #minetest-dev |
| 20:28 |
|
Player_2 joined #minetest-dev |
| 20:43 |
|
lisac joined #minetest-dev |
| 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:05 |
|
paramat joined #minetest-dev |
| 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:10 |
|
T4im joined #minetest-dev |
| 22:11 |
T4im |
the gnu global stuff is removed, paramat |
| 22:11 |
paramat |
ok thanks |
| 22:45 |
|
lisac joined #minetest-dev |
| 23:24 |
|
domtron joined #minetest-dev |
| 23:56 |
|
yang2003 joined #minetest-dev |
| 23:59 |
|
Fritigern joined #minetest-dev |
