| Time |
Nick |
Message |
| 00:13 |
hmmmm |
yes, very good |
| 00:13 |
hmmmm |
that's exactly how I would've fixed it |
| 00:28 |
|
luizrpgluiz joined #minetest-dev |
| 00:30 |
|
luizrpgluiz joined #minetest-dev |
| 01:14 |
hmmmm |
https://github.com/kwolekr/minetest/commit/a02a094a2f5c3c4121b142fd53d7167140cc3b5a PTAL |
| 01:35 |
est31 |
looking |
| 01:35 |
est31 |
why is abc_t not posix compliant? |
| 01:35 |
est31 |
so you say having content_t is bad? |
| 01:36 |
hmmmm |
come to think of it, yeah it is |
| 01:36 |
hmmmm |
damn |
| 01:36 |
hmmmm |
any identifier ending with _t is reserved by posix |
| 01:36 |
est31 |
all these things should be ... documented |
| 01:37 |
hmmmm |
wow okay content_t has a problem too |
| 01:38 |
hmmmm |
alright you know what, I'm going to roll that change back to threadid_t and if it does happen to cause a name collision on some supported platform, then we'll have a reason to change it |
| 01:38 |
est31 |
fine |
| 01:38 |
hmmmm |
http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html |
| 01:38 |
hmmmm |
read this |
| 01:39 |
est31 |
oh |
| 01:39 |
est31 |
CPÅžP11? |
| 01:40 |
hmmmm |
what is that character |
| 01:40 |
est31 |
its in your patch |
| 01:40 |
hmmmm |
ermm |
| 01:40 |
est31 |
ive thought its dirt on my monitor |
| 01:40 |
est31 |
then I've scrolled and the dirt moved |
| 01:40 |
hmmmm |
oh you mean CPP11 |
| 01:40 |
est31 |
https://github.com/kwolekr/minetest/commit/a02a094a2f5c3c4121b142fd53d7167140cc3b5a#diff-92729a668babc433abcbe4987f8e14e6R71 |
| 01:40 |
hmmmm |
whaat |
| 01:41 |
hmmmm |
the fuck |
| 01:42 |
est31 |
also I wonder... do we have c++11 threads right now, or not? |
| 01:42 |
hmmmm |
I would imagine freeminer would use that mode |
| 01:42 |
est31 |
bc ShadowNinja's patch had them at the start |
| 01:42 |
est31 |
but it was dropped until it got merged, no? |
| 01:42 |
hmmmm |
they're optionally supported only if the cpp version is high enough |
| 01:43 |
hmmmm |
yeah okay this is crazy |
| 01:43 |
hmmmm |
I really have no idea at all how that character got there |
| 01:45 |
hmmmm |
anyway I think we should document our conscious decision to ignore POSIX reserved name rules |
| 01:46 |
est31 |
either of those, but documenting is never bad |
| 01:46 |
hmmmm |
removing __ and _ prefixed names is fine and all because that could cause a bigger problem and they're not already ubiquitous throughout the code |
| 01:46 |
hmmmm |
and it's an ISO C language violation |
| 01:46 |
est31 |
yeah _something looks ugly as well |
| 01:46 |
est31 |
smells of snakes |
| 01:46 |
est31 |
duck typed snakes |
| 01:46 |
hmmmm |
this on the other hand is a POSIX violation and doesn't actually make a difference unless just by chance some new revision adds it |
| 01:46 |
hmmmm |
at which point we could simply... change the name |
| 01:47 |
hmmmm |
where should this be documented? |
| 01:47 |
est31 |
http://dev.minetest.net/Code_style_guidelines ? |
| 01:48 |
hmmmm |
this doesn't quite have to do with code style |
| 01:48 |
hmmmm |
more like "project design decisions/agreements" |
| 01:48 |
est31 |
there should be some place however where it can be added |
| 01:49 |
hmmmm |
yeah the POSIX name restrictions are way too broad. for example, any identifier starting with "ENet" is invalid |
| 01:49 |
est31 |
I really doubt it needs a new wiki page |
| 01:49 |
est31 |
well if you implement them, you are on the safe side |
| 01:49 |
hmmmm |
and even the major GNU project libgmp uses mpz_t |
| 01:49 |
est31 |
if you don't you are on the fun sid |
| 01:49 |
est31 |
e |
| 01:49 |
est31 |
yea |
| 01:49 |
hmmmm |
if such a big project ignores it then that kind of sets a precedent |
| 01:50 |
est31 |
all gnu libraries I've seen have someting_t |
| 01:53 |
est31 |
there we have the real reason why GNU isn't certified UNIX |
| 01:53 |
hmmmm |
another violation is our handling of pthread_t |
| 01:53 |
hmmmm |
you cannot compare a pthread_t using ==, you must use pthread_equal() |
| 01:54 |
hmmmm |
but the problem is that std::map in debug.cpp |
| 01:54 |
est31 |
your patch fixes it doesnt it? |
| 01:54 |
hmmmm |
if you override the comparator for that map to use pthread_equal(), it's not going to be well-ordered because you can't compare "greater than" between two pthread_ts |
| 01:54 |
est31 |
ah there is an std::map? |
| 01:55 |
hmmmm |
so you need to implement something to make pthread_ts arbitrarily well-ordered |
| 01:55 |
est31 |
yeah |
| 01:55 |
est31 |
injection into well ordered se |
| 01:55 |
est31 |
t |
| 01:55 |
hmmmm |
I have no good ideas on how to do that |
| 01:56 |
hmmmm |
in any case, it only matters on platforms where pthread_t is a struct |
| 01:56 |
est31 |
what exactly does the map do? |
| 01:56 |
hmmmm |
something about debugstacks |
| 01:58 |
hmmmm |
for what it's worth, gdb maps pthread_ts to an arbitrary integer ordinal so it doesn't have these problems |
| 01:58 |
hmmmm |
sorta wondering if we should do the same |
| 01:59 |
hmmmm |
or maybe it's really too much work for something that's a non-issue on our supported platforms |
| 01:59 |
est31 |
perhaps let the preprocesor issue a warning if its not an integral type? |
| 02:00 |
hmmmm |
for what it's worth, according to the spec, pthread_t could be an ordinal and comparison would still cause problems |
| 02:00 |
hmmmm |
imagine the case where pthread_equal is implemented as thr1->kernel_thread_id == thr2->kernel_thread_id and the other members are like uhh... no idea |
| 02:01 |
hmmmm |
some implementation dependent sutff |
| 02:01 |
hmmmm |
but the point is that they could be different /pointers/ with equivalent threads |
| 02:01 |
hmmmm |
subtle breakage |
| 02:01 |
est31 |
yeah |
| 02:02 |
est31 |
thats the problem with too lose standards |
| 02:02 |
hmmmm |
FWIW, google chrome has their Chromium Base Library which implements a thread class just like our own |
| 02:02 |
hmmmm |
it completely ignores the "problems" behind pthread_t |
| 02:02 |
hmmmm |
is that a good enough precedent to follow, would you say? |
| 02:03 |
est31 |
well, that means we would at least run at all platforms chromium runs at |
| 02:03 |
|
luizrpgluiz left #minetest-dev |
| 02:03 |
hmmmm |
the thing is |
| 02:03 |
est31 |
majority of the devices out there |
| 02:04 |
est31 |
idc whether minetest runs on some exotic HP workstation |
| 02:04 |
hmmmm |
because of all this broken dependency on pthread_t being a comparable ordinal number, the effective standard has been changed |
| 02:04 |
hmmmm |
nobody in their right minds would not make pthread_t a struct due to the amount of breakage |
| 02:04 |
hmmmm |
s/would not/would/ |
| 02:05 |
est31 |
well, if the standard creators were smart, they'd have added a pthread_get_id() function |
| 02:05 |
hmmmm |
I have an HP Visualize B1000 with HP-UX 11.11u, want me to test minetest compatibility with that? :) |
| 02:05 |
hmmmm |
the thing is, pthread_t is *supposed* to be the thread ID |
| 02:05 |
est31 |
well, then the standard shouldnt make it opaque |
| 02:06 |
hmmmm |
yeah the standard is dumb imho |
| 02:06 |
est31 |
I mean that pthread_get_id() function could just return the passed argument on most platforms |
| 02:07 |
est31 |
and for your example it could return thr->kernel_thread_id |
| 02:07 |
est31 |
done |
| 02:15 |
hmmmm |
what's done? |
| 02:21 |
hmmmm |
https://github.com/kwolekr/minetest/commit/6be74d17df75714066b36cfa6ae40081526ef477 |
| 02:30 |
est31 |
looks good |
| 03:48 |
hmmmm |
https://github.com/kwolekr/minetest/commit/765a834cd04473afeb4b86b445dee901e0d0c83c PTAL |
| 04:11 |
kahrl |
heh, even the gnu libstdc++ devs are having issues with pthread_t: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114#c4 |
| 04:22 |
|
shadowzone joined #minetest-dev |
| 04:48 |
ShadowNinja |
hmmmm: ... I just started that a few minutes before your message... |
| 04:49 |
ShadowNinja |
Why the m_ for private vars though? Then you have to rename itif you make it public/protected. |
| 04:51 |
hmmmm |
code rules say that private/protected need to have the m_ prefix |
| 04:52 |
hmmmm |
if you make it public/protected, you might need to rethink your encapsulation |
| 04:56 |
|
paramat joined #minetest-dev |
| 04:59 |
ShadowNinja |
Hrm, name should probably be private, I wonder why it isn't. |
| 05:00 |
hmmmm |
probably because threads won't be able to set it outside of an initializer list |
| 05:00 |
hmmmm |
i don't think it really matters that much |
| 05:01 |
ShadowNinja |
setName(); |
| 05:02 |
hmmmm |
you know what, you're right |
| 05:02 |
hmmmm |
this makes no sense the way it is |
| 05:02 |
ShadowNinja |
Er, no, that doesn't update the var.. |
| 05:03 |
hmmmm |
ahh |
| 05:03 |
ShadowNinja |
I'll fix that. |
| 05:03 |
hmmmm |
then you'd need to make it a non-static variable |
| 05:03 |
hmmmm |
:).... |
| 05:04 |
ShadowNinja |
My patch merges threads.h into thread.h instead of keeping them oddly seperate. |
| 05:04 |
hmmmm |
whose patch are we using then? |
| 05:04 |
ShadowNinja |
I also removed the include from porting.h, since itisn't actually used there. |
| 05:05 |
ShadowNinja |
Eh, mine? I'm adding in your changes now. |
| 05:05 |
hmmmm |
I'd rather not duplicate effort |
| 05:05 |
hmmmm |
would you rather base yours off of mine? |
| 05:05 |
ShadowNinja |
Moment, I'll give you my patch so you can see what I'm doing. |
| 05:05 |
ShadowNinja |
Yes. |
| 05:05 |
hmmmm |
alright, I'll push what's currently there, then |
| 05:06 |
VanessaE |
can someone please address the shadow bug in mgv7 w/moretrees? |
| 05:06 |
hmmmm |
plate's full |
| 05:07 |
ShadowNinja |
This is what I've got so far: http://ix.io/ls8/diff\ |
| 05:07 |
ShadowNinja |
hmmmm: er. |
| 05:07 |
ShadowNinja |
I mean I'd merge your changes into mine manually, rebasing it would probably be harder. |
| 05:08 |
hmmmm |
let me think about this |
| 05:08 |
hmmmm |
I don't like defining a type as a member of a class like that |
| 05:08 |
hmmmm |
Thread::Id |
| 05:08 |
paramat |
Vanessa is it perhaps due to very tall trees reaching y = 47? maybe when the chunk above has not been generated yet? |
| 05:08 |
hmmmm |
I know it "makes sense" from an organizational point of view, but can't we just leave well enough alone? :/ |
| 05:09 |
VanessaE |
paramat: doubt it, even some of the shorter trees spawning at sea level (say, a palm tree on a beach) do it. |
| 05:09 |
VanessaE |
it's probably the chunk-above part, but not the Y>47m part. |
| 05:10 |
ShadowNinja |
hmmmm: I'm also O.K. with ThreadId, but I don't like threadid_t. |
| 05:10 |
hmmmm |
why not? |
| 05:10 |
ShadowNinja |
It doesn't use the PascalCase type name convention. |
| 05:10 |
paramat |
okay |
| 05:10 |
hmmmm |
so?? |
| 05:11 |
hmmmm |
PascalCase is for classes |
| 05:11 |
hmmmm |
not necessarily types |
| 05:11 |
ShadowNinja |
hmmmm: So I don't like it :-P |
| 05:11 |
hmmmm |
just my personal opinion, I think you're going a little too crazy with the refactoring |
| 05:11 |
hmmmm |
would be better to focus on bug fixes/features/etc. |
| 05:12 |
hmmmm |
or documentation updates |
| 05:12 |
hmmmm |
like these are the things that totally don't matter but break a lot of pull requests and add merge conflicts |
| 05:12 |
hmmmm |
the reason why I did that threading refactor was because I needed it for my envlock PR |
| 05:14 |
hmmmm |
ShadowNinja: but the main point is that I originally changed threadid_t to ThreadId, just like you said, but I went back on that decision because it'd cause more inconsistency for very little benefit |
| 05:17 |
ShadowNinja |
hmmmm: How was it more inconsistent? |
| 05:17 |
hmmmm |
because then we have all the other custom types that end with _t |
| 05:17 |
hmmmm |
there's content_t, and I'm sure there are others that I can't think of at the moment |
| 05:17 |
hmmmm |
you're not really going to do a global find+replace on content_t, are you....? |
| 05:18 |
hmmmm |
like that's a little bit too ridic |
| 05:18 |
hmmmm |
how is that helping minetest other than breaking everybody's PRs |
| 05:21 |
ShadowNinja |
hmmmm: content_t may be hard to change, but this is easy, and it's more consistent with how the standard library does it (in C++11). |
| 05:22 |
hmmmm |
who said that being more C++y is better though |
| 05:22 |
hmmmm |
this sort of thing is something we should get consensus on first before you do it i think |
| 05:29 |
ShadowNinja |
hmmmm: Why'd you change the thread priority enum to a list of constants? |
| 05:29 |
hmmmm |
because anonymous enums are dumb |
| 05:30 |
hmmmm |
on windows, those constants are defines also |
| 05:30 |
ShadowNinja |
Why are they dumb? |
| 05:30 |
hmmmm |
because they have no advantages whatsoever |
| 05:30 |
ShadowNinja |
And why clib -> lib.h? |
| 05:31 |
hmmmm |
because lib.h is more universal |
| 05:31 |
hmmmm |
are there any reasons for those changes at all to begin with...? |
| 05:31 |
ShadowNinja |
The enum syntax is nicer and the clib versions are rewuired by the standard. |
| 05:32 |
hmmmm |
why is enum syntax nicer? you use them in the same exact way |
| 05:32 |
hmmmm |
and you don't get to define their type |
| 05:32 |
hmmmm |
with a define, if you want something to be a specific type, you just add a cast to the macro definition |
| 05:33 |
hmmmm |
it just so happens that on Windows that parameter is an int, so it works fine without any implicit conversions |
| 05:34 |
hmmmm |
what if there's code that expects those constants to be macros? |
| 05:34 |
ShadowNinja |
The syntax is nicer because the "#define " and value isn't necessary. Also, you changed a comment from "// For..." to "// for...". The original was correct. |
| 05:34 |
hmmmm |
capitalizing a letter? |
| 05:34 |
hmmmm |
that's not a sentence |
| 05:35 |
hmmmm |
all these miniscule autistic details that don't really need to be changed get changed and detract from the actual changes |
| 05:35 |
ShadowNinja |
Yes, it's supposed to be capitalized. And it is a sentence, there's an implicit "This is " before it. |
| 05:36 |
ShadowNinja |
hmmmm: But you made these changes... |
| 05:36 |
hmmmm |
you made them first |
| 05:36 |
hmmmm |
then how come there's no period then? |
| 05:36 |
hmmmm |
jeez just leave those things the way they are |
| 05:44 |
ShadowNinja |
hmmmm: You also switched from _beginthreadex to CreateThread. CreateThread doesn't set up the runtime in the new thread. |
| 05:45 |
ShadowNinja |
http://stackoverflow.com/questions/331536/windows-threading-beginthread-vs-beginthreadex-vs-createthread-c |
| 05:47 |
hmmmm |
I don't think _beginthreadex does anything different other than sets up TLS |
| 05:47 |
hmmmm |
we don't use TLS. |
| 05:51 |
hmmmm |
in fact it doesn't even do that anymore, according to a comment in that very webpage you posted: http://stackoverflow.com/a/20901790/4751863 |
| 05:58 |
hmmmm |
oh I remember why I changed the thread priority values back to defines |
| 05:58 |
hmmmm |
it's because they're fundamentally not an enum, the way I had it set up those were arithmetic values that just happened to be sequential in value |
| 05:58 |
hmmmm |
i do arithmetic on them |
| 06:26 |
paramat |
hmmmm do you approve of #3248 as it is? i've rebased and renamed the field to "catch_up" |
| 06:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/3248 -- ABMs: Make catch-up behaviour optional by paramat |
| 06:27 |
hmmmm |
lmao |
| 06:27 |
hmmmm |
getting tired of ketchup jokes huh |
| 06:28 |
VanessaE |
heh |
| 06:28 |
hmmmm |
erm, yeah, +1 from me, looks good. |
| 06:29 |
paramat |
hehe thanks |
| 06:29 |
ShadowNinja |
hmmmm: You call cleanup on thread start, which clears the thread name before the OS ever learns about it. |
| 06:30 |
ShadowNinja |
And apparently you've already merged it. |
| 06:30 |
hmmmm |
whoops |
| 06:32 |
hmmmm |
you can't put cleanup() at the end of wait(), because there's nothing saying the user absolutely needs to wait after stopping |
| 06:33 |
hmmmm |
after wait() is when the user would call getReturnValue() and do whatever operation is needed |
| 06:33 |
ShadowNinja |
If you need to clear stuff it should brobably be done by the thread itself. |
| 06:33 |
hmmmm |
so it really does need to get put at the beginning of start() |
| 06:34 |
ShadowNinja |
name never needs to be cleared though/ |
| 06:34 |
hmmmm |
erm, I don't think that works for C++11 threads |
| 06:34 |
hmmmm |
okay, so just take the name clearing out |
| 06:34 |
hmmmm |
that fixes everything |
| 06:35 |
hmmmm |
also add a cleanup() after the wait() in the if (!m_running) { claus in thread::kill |
| 06:37 |
hmmmm |
paramat, look at this: https://github.com/kwolekr/minetest/commit/ae4e9cc71262fef154cee6c35539638780961796 |
| 06:38 |
* paramat |
looks |
| 06:38 |
paramat |
oooh |
| 06:38 |
hmmmm |
it's not done yet but the basic idea is to acquire a VManip somehow |
| 06:38 |
hmmmm |
run core.envlock_release() |
| 06:38 |
hmmmm |
do your mapgen |
| 06:38 |
hmmmm |
then run core.envlock_acquire() |
| 06:38 |
hmmmm |
blit the vmanip back to the map |
| 06:39 |
hmmmm |
comments/concerns with the way it's done? |
| 06:40 |
hmmmm |
VanessaE? |
| 06:41 |
hmmmm |
though this one wouldn't be as pertinent to you since you use all set_node() |
| 06:41 |
paramat |
so the lock can be released to run the heavy processing part of a lua mapgen threaded? |
| 06:41 |
VanessaE |
your basic idea seems reasonable anyway |
| 06:41 |
hmmmm |
right |
| 06:41 |
hmmmm |
and you can also use Lua Lanes to have a lua multithreaded mapgen, for what it's worth |
| 06:41 |
hmmmm |
lol that's gonna be ridic' |
| 06:41 |
paramat |
nice because most of the processing is working on the nodes in the lvm |
| 06:42 |
* VanessaE |
shudders |
| 06:42 |
paramat |
good to see this going ahead |
| 06:42 |
hmmmm |
but how's the interface |
| 06:42 |
hmmmm |
are you missing anything from it, or do you not want the functions to throw errors? |
| 06:42 |
hmmmm |
etc |
| 06:43 |
paramat |
seems okay, nice and simple |
| 06:43 |
|
nrzkt joined #minetest-dev |
| 06:44 |
paramat |
throwing errors is probably a good thing for this |
| 06:45 |
paramat |
.. because it's dangerous |
| 06:48 |
hmmmm |
this is gonna be fun when i split map locking into mapblock areas |
| 06:49 |
hmmmm |
core.request_area({MinEdge={...}, MaxEdge={...}}) |
| 06:49 |
hmmmm |
blocks until there are no locks overlapping with the requested area |
| 06:49 |
hmmmm |
still need to work out the details but what i fear is that this is going to take too many locks |
| 06:50 |
paramat |
8. |
| 06:50 |
hmmmm |
no definitely more than that |
| 06:50 |
hmmmm |
i need to do research on how "heavy" futexes are on our target platforms |
| 06:50 |
hmmmm |
or maybe come up with my own synchronization primitive altogether if necessary |
| 06:50 |
|
Hunterz joined #minetest-dev |
| 06:51 |
hmmmm |
might have to use spinlocks instead if it's too much |
| 06:51 |
hmmmm |
which sort of defeats the purpose |
| 06:52 |
nrzkt |
hmmmm, did you tried mutex perf mapsector first ? |
| 06:52 |
hmmmm |
no |
| 06:59 |
ShadowNinja |
hmmmm: On my computer I can do 39000 lock/unlock pairs per milisecond. (minetest --speedtests) |
| 07:03 |
ShadowNinja |
Actually locking the mutex should take almost no time, the issue is contention. |
| 07:03 |
hmmmm |
what i'm concerned about is if initializing a mutex does anything in kernel mode |
| 07:06 |
ShadowNinja |
Moving the Mutex into the loop brings it down to 29000/ms. |
| 07:08 |
ShadowNinja |
I'm not sure how expensive a syscall is, but the speed seems more than adequate. |
| 07:09 |
ShadowNinja |
Of course, this is Linux 4.x with recent libraries, other OSes may do much worse. |
| 07:17 |
hmmmm |
alright i just checked |
| 07:17 |
hmmmm |
on Windows it does create an event object |
| 07:22 |
hmmmm |
i think i'd rather come up with a new form of synchronization that's actually designed for this type of task |
| 07:28 |
hmmmm |
what i'm thinking of is somehow blocking on a data structure (let's start out with iterating over a list...) until there are no intersections with your requested area |
| 07:28 |
hmmmm |
could do this with events |
| 07:28 |
hmmmm |
but then i'd be waking up every single time a maplock is released |
| 07:29 |
hmmmm |
hell of a lot better than having a kernel mode event object for every single mapblock |
| 07:30 |
hmmmm |
okay this will work, and the naive approach would still work (but not very well) because it'd need to loop over a volume of mapblocks and block on each waiting to acquire |
| 07:31 |
hmmmm |
if I write this, nobody is going to bother to try improving it |
| 07:32 |
hmmmm |
I have a reason to use est's areastore :-) |
| 08:03 |
|
paramat joined #minetest-dev |
| 08:10 |
ShadowNinja |
https://github.com/ShadowNinja/minetest/commit/5b1c01126e026539a5bea2eebc63af85be38becd |
| 08:10 |
ShadowNinja |
G'night folks. |
| 08:18 |
paramat |
will merge #3248 when checks are done |
| 08:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/3248 -- ABMs: Make catch-up behaviour optional by paramat |
| 08:30 |
paramat |
uh the windows bulds failed, something to do with thread.cpp |
| 08:32 |
paramat |
minetest/src/threading/thread.cpp:170:10: error: expected initializer before '==' token |
| 08:36 |
paramat |
that line was altered by hmmmm's recent commit |
| 08:36 |
paramat |
i'll wait for his return then |
| 08:39 |
paramat |
now merging game#705 |
| 08:39 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/705 -- Default/trees: Add requirement of light level 13 for sapling growth by paramat |
| 08:40 |
VanessaE |
wait |
| 08:40 |
VanessaE |
what's the light level for a torch? |
| 08:40 |
VanessaE |
(if placed right next to the sapling) |
| 08:41 |
VanessaE |
oh hell |
| 08:41 |
VanessaE |
you already addressed that. |
| 08:41 |
VanessaE |
paramat: frankly, I'd have to veto that. |
| 08:42 |
paramat |
oh sorry, torches are not bright enough |
| 08:42 |
paramat |
but could be made level 14 |
| 08:42 |
VanessaE |
minetest's lighting system needs revamped first, imho |
| 08:42 |
VanessaE |
that's just the problem |
| 08:43 |
paramat |
you have a need to grow saplings by torchlight? |
| 08:43 |
VanessaE |
a torch should be perhaps even dimmer than it is now, but then a bright source like a mese lamp should be FAR brighter than it is (I mean how far it throws the light, too) |
| 08:43 |
VanessaE |
actually I do that sometimes, if I'm in a hurry to get a sapling to grow. |
| 08:43 |
VanessaE |
if anything, you should vary the grow time based on light level |
| 08:43 |
VanessaE |
rather than just grow-or-don't |
| 08:44 |
paramat |
we could consider making torches level 14, although that erases the difference between torches and bright lamps |
| 08:46 |
VanessaE |
if consistency is the issue, |
| 08:46 |
VanessaE |
wouldn't it be better to lower the light requirement for the other plants (as pilz alludes to)? |
| 08:46 |
VanessaE |
and make it take longer to grow if the light is too low |
| 08:47 |
VanessaE |
I do something like this with bushes_classic -- if they're planted on farming soil, they regrow their fruits faster than on plain dirt/grass. |
| 08:48 |
VanessaE |
https://github.com/VanessaE/plantlife_modpack/blob/master/bushes_classic/nodes.lua#L123 |
| 08:48 |
paramat |
perhaps open an issue about lowering the threshold for all plants. but it seems right to me that torches should never be bright enough to grow a plant |
| 08:48 |
VanessaE |
why shouldn't they? |
| 08:48 |
paramat |
it'll inconvenience some players true but tough :) |
| 08:49 |
paramat |
because they're torches |
| 08:49 |
VanessaE |
so? :) |
| 08:49 |
VanessaE |
a dim light still grows things, they just grow less. |
| 08:50 |
paramat |
nah a dim light should never grow anything in any timescale |
| 08:50 |
paramat |
think of hydroponics grow lights, you'll just have to use meselamps or mod lamps instead |
| 08:51 |
* VanessaE |
shrugs |
| 08:51 |
VanessaE |
now what happens if the light isn't right next to the object? |
| 08:51 |
paramat |
anyway see what the other devs think |
| 08:51 |
VanessaE |
doesn't a light source of '14' produce 13-and-below in the neighboring nodes? |
| 08:52 |
paramat |
yeah, the lamp needs to be immediately beside the plant |
| 08:52 |
paramat |
just as with wheat, cotton |
| 08:52 |
paramat |
diagonally-neighbouring doesn't work |
| 08:53 |
VanessaE |
that also means now it's impossible to create a hydroponics mod |
| 08:53 |
VanessaE |
if the resultant plants are more than 1 node tall |
| 08:54 |
VanessaE |
a mese lamp or other grow light of equal brightness, suspended with 2 meters of air space between it and the ground is going to give the sapling/seedling on that ground a light level of 12 |
| 08:54 |
paramat |
well my pr is only for saplings, mod plants could have a lower threshold |
| 08:55 |
paramat |
yeah falloff of 1 per node |
| 08:55 |
paramat |
https://forum.minetest.net/viewtopic.php?p=194951#p194951 |
| 08:56 |
paramat |
each lamp can grow 4 plants around it |
| 08:56 |
VanessaE |
sorry to say, but I hate that behavior |
| 08:56 |
VanessaE |
it's too crowded |
| 08:57 |
paramat |
then it's worth suggesting a lower threshold for all plants |
| 08:57 |
VanessaE |
I just did :) |
| 08:57 |
paramat |
hehe |
| 08:59 |
VanessaE |
light sources only being able to spread 14 meters or so, and barely lighting up a scene, is a real problem |
| 09:00 |
VanessaE |
I've got a 60W (equivalent) CFL bulb lighting up my computer room. In minetest, this same room looks about half as bright |
| 09:00 |
VanessaE |
(I have my house modeled in minetest) |
| 09:03 |
paramat |
personally i might approve of a plant threshold of 12, but only if torches are reduced by 1 so they can't be used as grow lamps |
| 09:06 |
paramat |
but dimmer torches may be unpopular. so i think things are ok as they are |
| 09:30 |
|
Calinou joined #minetest-dev |
| 09:35 |
|
Krock joined #minetest-dev |
| 09:44 |
|
paramat left #minetest-dev |
| 09:55 |
|
Darcidride joined #minetest-dev |
| 11:01 |
|
CraigyDavi joined #minetest-dev |
| 11:06 |
|
PilzAdam joined #minetest-dev |
| 11:23 |
|
H-H-H joined #minetest-dev |
| 11:52 |
|
technics joined #minetest-dev |
| 12:38 |
|
julienrat joined #minetest-dev |
| 12:55 |
|
Darcidride joined #minetest-dev |
| 12:58 |
|
waressearcher2 left #minetest-dev |
| 13:15 |
|
Player2 joined #minetest-dev |
| 13:33 |
|
zupoman joined #minetest-dev |
| 14:13 |
|
luizrpgluiz joined #minetest-dev |
| 14:30 |
|
jin_xi joined #minetest-dev |
| 14:44 |
|
younishd joined #minetest-dev |
| 14:55 |
|
Warr1024 joined #minetest-dev |
| 14:56 |
|
luizrpgluiz left #minetest-dev |
| 15:16 |
|
leat1 joined #minetest-dev |
| 15:27 |
|
leat1 joined #minetest-dev |
| 15:30 |
|
nm0i joined #minetest-dev |
| 15:32 |
nm0i |
Morning |
| 15:32 |
nm0i |
Is set_timeofday only way to contol brightness of sunlight? |
| 15:33 |
Calinou |
yes, nm0i. |
| 15:33 |
Calinou |
you can't change sun color server-side. |
| 15:36 |
nm0i |
Thanks. Just making darker storms... |
| 15:46 |
|
Darcidride joined #minetest-dev |
| 15:50 |
|
zat joined #minetest-dev |
| 15:54 |
Krock |
Haxx the clinent |
| 16:07 |
|
julienrat joined #minetest-dev |
| 16:08 |
|
julienrat left #minetest-dev |
| 16:12 |
|
paramat joined #minetest-dev |
| 16:13 |
paramat |
can anyone +1 #3264 ? all builds fail due to this |
| 16:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/3264 -- Fix == to = by Rui914 |
| 16:15 |
Krock |
+1 |
| 16:15 |
Krock |
> anyone |
| 16:15 |
paramat |
heh |
| 16:16 |
paramat |
well it's trivial i'll merge it |
| 16:19 |
paramat |
now merging 3264 |
| 16:24 |
paramat |
done |
| 16:41 |
|
hmmmm joined #minetest-dev |
| 16:59 |
paramat |
#3265 |
| 16:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/3265 -- findSpawnPos: Allow spawn up to 16 nodes above water level by paramat |
| 17:06 |
|
paramat left #minetest-dev |
| 17:14 |
|
Gael-de-Sailly joined #minetest-dev |
| 17:15 |
|
VirusJones joined #minetest-dev |
| 17:37 |
|
Darcidride joined #minetest-dev |
| 17:46 |
|
nore joined #minetest-dev |
| 18:08 |
|
leat2 joined #minetest-dev |
| 18:20 |
|
leat2 joined #minetest-dev |
| 18:24 |
OldCoder |
Which MT release added local map saving to the core? |
| 18:27 |
PilzAdam |
OldCoder, 0.4.11 |
| 18:27 |
OldCoder |
PilzAdam, thank you. It is kind of you to respond. |
| 18:27 |
PilzAdam |
see http://dev.minetest.net/Changelog |
| 18:27 |
OldCoder |
Very well. FYI this is to facilitate tweaks to RedCrab which is now rescued. |
| 18:30 |
|
est31 joined #minetest-dev |
| 18:39 |
PilzAdam |
est31, should #3258 also replace minetest.conf.example with the generated one? it would look like this: https://gist.github.com/PilzAdam/3503a574bf3277078e05 |
| 18:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/3258 -- New Lua main menu settings by PilzAdam |
| 18:41 |
est31 |
I'm generally not sure how we should manage that. |
| 18:41 |
est31 |
if minetest.conf.example is autogenerated, should we keep it in git tracking? |
| 18:42 |
est31 |
if yes, when and how should it updated |
| 18:42 |
hmmmm |
08:30 paramat uh the windows bulds failed, something to do with thread.cpp |
| 18:42 |
hmmmm |
WTF, I ran it on Jenkins |
| 18:42 |
est31 |
if no, same question |
| 18:42 |
hmmmm |
precisely so this does not happen |
| 18:43 |
PilzAdam |
est31, same handling as updating translation files |
| 18:43 |
hmmmm |
damn, int ret == WaitForSingleObject(... |
| 18:43 |
PilzAdam |
it should be done in feature freeze before release, so translators have time to translate it |
| 18:44 |
est31 |
hrmm, I run it every two months |
| 18:45 |
hmmmm |
08:59 VanessaE light sources only being able to spread 14 meters or so, and barely lighting up a scene, is a real problem |
| 18:45 |
hmmmm |
this is literally because of the number of bits |
| 18:45 |
hmmmm |
:( |
| 18:45 |
PilzAdam |
est31, auto-generating it, for example every startup, is not possible, since some distros may keep their doc folder in weird / non-writeable places |
| 18:45 |
est31 |
well, it is advantageous hmmmm as well |
| 18:45 |
hmmmm |
when I get rid of that asinine day/light bank thing we can have light from light sources expanding out to 256 meters |
| 18:45 |
est31 |
bc we dont have tons of lightning updates |
| 18:45 |
est31 |
only kilos :) |
| 18:46 |
hmmmm |
yeah true |
| 18:46 |
hmmmm |
I don't know man there's too many things to work on |
| 18:46 |
hmmmm |
gotta take it one at a time |
| 18:46 |
hmmmm |
I am really psyched about the map region locking mechanism I came up with last night and it seems it'd solve practically all of our problems |
| 18:47 |
est31 |
PilzAdam, perhaps it should give a way to do it over console, or at least with removing comments from some parts of the settings tab file? |
| 18:48 |
est31 |
hmmmm, tell us |
| 18:49 |
PilzAdam |
est31, https://github.com/PilzAdam/minetest/blob/lua_settings/builtin/mainmenu/tab_settings.lua#L484-L498 |
| 18:49 |
hmmmm |
I described the basics in the logs, don't have any of the details of synchronization written out yet |
| 18:49 |
hmmmm |
but basically each wait object will require a semaphore |
| 18:49 |
hmmmm |
there's two lists, one of regions currently locked, and then the second of regions currently waiting to get locked |
| 18:50 |
hmmmm |
a region lock is acquired by acquiring the region list lock and then using whatever spacial data structure to determine if any regions intersect with the requested region |
| 18:51 |
hmmmm |
if so, then the requested region gets added to the pending lock list along with a pointer to its semaphore structure |
| 18:51 |
hmmmm |
if not, it just adds its region to the locked region list |
| 18:51 |
hmmmm |
when a region is released, it checks the pending region list and if the area it's releasing overlaps with anything pending, it'll trigger the event in the list |
| 18:52 |
hmmmm |
the other thread then wakes up and rescans to see if it is able to lock |
| 18:52 |
hmmmm |
if so it acquires the lock and begins execution on that region |
| 18:52 |
hmmmm |
of course there are some details that need to be worked out |
| 18:53 |
est31 |
you write you want to use areastore, thats great |
| 18:53 |
hmmmm |
of course, but first I'm going to keep it simple and use a linear list for the proof of concept :-) |
| 18:53 |
hmmmm |
that enhancement can be added later on once this is a proven technology |
| 18:54 |
est31 |
okay |
| 18:54 |
hmmmm |
we can roll this out little by little by emulating "envlock" as it is right now by acquiring the entire map as the region |
| 18:54 |
hmmmm |
and then make small changes to restrict locks to the specific region they're actually checking or modifying |
| 18:54 |
hmmmm |
by the time we're done, nothing will use the global map lock any longer |
| 18:55 |
PilzAdam |
kahrl, would you be ok with merging #3258 now? the aggregated settings view can be done later, but it would need to be redone anyway |
| 18:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/3258 -- New Lua main menu settings by PilzAdam |
| 18:56 |
est31 |
perhaps the settings_translation_file can be generated as well? |
| 18:59 |
PilzAdam |
est31, and put it in po/, next to minetest.pot? |
| 18:59 |
PilzAdam |
sounds good |
| 18:59 |
PilzAdam |
I'll modify the script, too |
| 19:01 |
est31 |
it should contain a comment explaining that its autogenerated |
| 19:01 |
PilzAdam |
yep |
| 19:16 |
kahrl |
PilzAdam, allow me to do some bikeshedding |
| 19:16 |
kahrl |
the white-on-black gives me the impression that the settings are very technical (like in a terminal) |
| 19:17 |
kahrl |
I think making the background transparent would reduce that feeling: https://gist.github.com/kahrl/73545042400dd226c831 |
| 19:19 |
kahrl |
For the boolean settings, I think double-clicking them or pressing enter should simply toggle them, not display the edit page |
| 19:20 |
kahrl |
(the edit button should still get you to the edit page, so that you can see the description if you want) |
| 19:26 |
PilzAdam |
kahrl, done |
| 19:27 |
PilzAdam |
"no rule to make target `../po/settings_translation_file.c/minetest.po'" what? |
| 19:27 |
est31 |
that toggle thing can be seen to be against least suprise |
| 19:27 |
PilzAdam |
:-/ |
| 19:27 |
est31 |
hrmm, perhaps it should not be put there... |
| 19:27 |
est31 |
src? |
| 19:28 |
PilzAdam |
misc? |
| 19:28 |
est31 |
updatepo.sh only checks src/ and builtin/ |
| 19:28 |
PilzAdam |
est31, I already thought earlier about a fast way to toggle booleans; I would say it's quite intuitive |
| 19:29 |
kahrl |
est31: honestly I was confused at first when it opened an extra dialog for a boolean |
| 19:29 |
kahrl |
but I can see what you mean |
| 19:29 |
PilzAdam |
est31, I'll put it in src/ |
| 19:32 |
kahrl |
from a functionality perspective I think the PR can be merged now (once the translation file stuff is dealt with) |
| 19:32 |
kahrl |
I haven't reviewed the code, should I? |
| 19:32 |
PilzAdam |
no, better don't look at it ;-) |
| 19:32 |
kahrl |
hehe |
| 19:32 |
PilzAdam |
est31 already looked at it |
| 19:33 |
kahrl |
yeah I was mostly asking est31 whether he wanted someone else to look at it as well |
| 19:34 |
est31 |
kahrl, if you want, look at it, then you can be blamed as well when a bug gets discovered :) |
| 19:35 |
est31 |
when not if :p |
| 19:35 |
PilzAdam |
your assumption that my code contains bugs is wrong |
| 19:36 |
PilzAdam |
the one you discovered earlier was just a test to check if you review correctly ;-) |
| 19:36 |
|
proller joined #minetest-dev |
| 19:40 |
PilzAdam |
can I merge it now? |
| 19:40 |
est31 |
it seems kahrl is commenting |
| 19:41 |
kahrl |
yeah, I'm peephole reviewing |
| 19:42 |
PilzAdam |
github doesn't auto-update commit comments in the PR view |
| 19:46 |
est31 |
okay, having had a close look at GnuTLS, I've come to the conclusion that implementing encryption ourselves is much easier than using gnutls for rolling out dtls. |
| 19:47 |
kahrl |
lol |
| 19:50 |
est31 |
ill try a bit some more with gnutls, and if i give up ill get libnettle and do some aes(counter,packet) |
| 19:51 |
est31 |
tls was designed for TCP, dtls is a modification of it |
| 19:51 |
est31 |
also, tls is 99% used with certificates |
| 19:51 |
est31 |
we use tls with PSK (pre-shared-key) |
| 19:51 |
est31 |
so we dont need most of the parts of TLS |
| 19:53 |
kahrl |
ok, I'm through |
| 19:53 |
kahrl |
looks good except what I commented |
| 19:54 |
kahrl |
(as I said, I peephole-reviewed, so I only looked at small parts at a time, I didn't review the big picture) |
| 19:55 |
PilzAdam |
ah, good catch on the pairs() |
| 19:55 |
kahrl |
est31: wait, I thought ipairs was the one that preserved order |
| 19:56 |
PilzAdam |
previously I used the setting names as keys in the table, but then I decided to keep the order |
| 19:56 |
kahrl |
for the type variable, it's not an issue at the moment, but it could trip up someone that tries to modify this code later |
| 19:57 |
PilzAdam |
I'll change it |
| 19:58 |
est31 |
kahrl, sorry you are right |
| 19:59 |
PilzAdam |
fixed |
| 20:00 |
kahrl |
looks all good now |
| 20:01 |
kahrl |
+1 for merging from me. est31? |
| 20:01 |
est31 |
yes |
| 20:01 |
est31 |
+1 |
| 20:02 |
PilzAdam |
lets if I can still merge... it's been quite some time since my last time |
| 20:02 |
PilzAdam |
+see |
| 20:07 |
PilzAdam |
done |
| 20:08 |
PilzAdam |
I'll write a forum post |
| 20:08 |
est31 |
nice |
| 20:09 |
est31 |
why have you edited updatepo.sh? |
| 20:12 |
est31 |
--add-location is bad |
| 20:12 |
PilzAdam |
I added po/settings_translation_file.c to it, and later removed it |
| 20:12 |
est31 |
--add-location=file omits the number |
| 20:13 |
est31 |
line number |
| 20:13 |
PilzAdam |
it failed to run for me with =file |
| 20:13 |
PilzAdam |
feel free to add it back |
| 20:13 |
est31 |
your os is too old :) |
| 20:13 |
est31 |
recent xgettext has it |
| 20:17 |
|
younishd joined #minetest-dev |
| 20:18 |
|
Gael-de-Sailly joined #minetest-dev |
| 20:20 |
PilzAdam |
https://forum.minetest.net/viewtopic.php?f=18&t=13427 |
| 20:20 |
PilzAdam |
est31, I'll upgrade in 2017 when support is dropped |
| 20:22 |
|
FR^2 joined #minetest-dev |
| 20:22 |
est31 |
your xgettext is older than 0.18.4 right= |
| 20:22 |
est31 |
? |
| 20:22 |
est31 |
https://github.com/minetest/minetest/commit/94961b3364f76d5861913af321e9be6200d080b3 |
| 20:23 |
PilzAdam |
0.28.1 |
| 20:23 |
PilzAdam |
*18 |
| 20:23 |
Krock |
PilzAdam, why [Cancel] [Save]? Usually it's the other way |
| 20:23 |
est31 |
i dont think that |
| 20:23 |
est31 |
its mixed across applications |
| 20:23 |
PilzAdam |
Krock, it's consistent with the world creation dialog |
| 20:24 |
PilzAdam |
est31, it's also mixed inside of Minetest |
| 20:24 |
PilzAdam |
Krock, eh, not world creation; the configure world dialog |
| 20:24 |
Krock |
Found some stuff to read :) http://www.nngroup.com/articles/ok-cancel-or-cancel-ok/ |
| 20:24 |
PilzAdam |
world creation is exactly other way round |
| 20:25 |
PilzAdam |
Krock, feel free to create PR to make it consistent across Minetest |
| 20:25 |
Krock |
Okay, I'll do so |
| 20:27 |
PilzAdam |
kahrl, is it possible to automatically select the entry in the table when clicking the "+" to open a tree node? |
| 20:27 |
PilzAdam |
that way it would be way less "jumpy" |
| 20:28 |
PilzAdam |
currently the table gets updated when clicking +; and when updating the view always adjusts to contain the selected line |
| 20:29 |
|
Warr1024 joined #minetest-dev |
| 20:30 |
|
younishd joined #minetest-dev |
| 20:31 |
kahrl |
PilzAdam: it's possible (but not from lua, GUITable has to be changed) |
| 20:31 |
kahrl |
or perhaps updating the table should not scroll to the selected row |
| 20:35 |
PilzAdam |
kahrl, it would also be nice if the tree would be automatically extend so that the selected node is visible |
| 20:35 |
PilzAdam |
that way it would look the same when returning from the change dialog |
| 20:36 |
kahrl |
good idea |
| 20:38 |
PilzAdam |
not scrolling the table to the selected row would also fix other updates, e.g. toggling the "Show technical names" checkbox |
| 20:39 |
PilzAdam |
however, maybe that would the e.g. the world list to not show the currently selected world when starting up the game |
| 20:39 |
PilzAdam |
s/the/cause/ |
| 20:48 |
kahrl |
I tried the automatic extending to the selected item |
| 20:49 |
kahrl |
it seemed to work, but then I noticed that you can no longer close a subtree if one of its children is selected |
| 20:50 |
PilzAdam |
that would be fixed if clicking + would select this line |
| 20:50 |
PilzAdam |
wouldn't it? |
| 20:50 |
kahrl |
maybe |
| 20:59 |
PilzAdam |
this new settings commit closed 5 issues; mostly requesting single settings to be present in GUI :D |
| 21:12 |
|
Darcidride joined #minetest-dev |
| 21:39 |
Krock |
#3267 makes the "helper formspecs" look better - comments please :) |
| 21:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/3267 -- Standardize the menu button order and sizes by SmallJoker |
| 21:48 |
kahrl |
#3268 |
| 21:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/3268 -- Fix GUITable selection issues with trees by kahrl |
| 21:49 |
|
sloantothebone joined #minetest-dev |
| 21:56 |
est31 |
looks good |
| 21:56 |
est31 |
have you tested it kahrl ? |
| 21:56 |
kahrl |
yes |
| 21:57 |
est31 |
good for merge then |
| 21:57 |
kahrl |
thanks :) merge incoming |
| 22:00 |
|
hmmmmm joined #minetest-dev |
| 22:04 |
|
Miner_48er joined #minetest-dev |
| 22:41 |
|
Sokomine joined #minetest-dev |
| 22:45 |
|
kilbith joined #minetest-dev |
| 22:46 |
kilbith |
guys, i just fresh-cloned from latest commit with a virgin config and now you always spawn underground and the mapgen is fuckin screwed : https://lut.im/0vN7SbmIn4/NGGN7HUCRRalniYO.png |
| 22:47 |
|
DFeniks joined #minetest-dev |
| 22:52 |
kilbith |
no idea if it's related : WARNING[Main]: NodeDefManager: Ignoring CONTENT_IGNORE redefinition |
| 22:53 |
kahrl |
kilbith: nah, I also get that message but the spawn and mapgen is fine |
| 22:54 |
kahrl |
what game version are you using? |
| 22:55 |
kilbith |
minetest_game you mean ? |
| 22:55 |
kahrl |
yeah |
| 22:55 |
kilbith |
latest commit |
| 22:55 |
kahrl |
same here. Very weird |
| 22:55 |
kilbith |
i also compiled with clang |
| 22:56 |
kahrl |
hrmm |
| 22:56 |
kahrl |
it would be very strange but it could have an effect |
| 22:56 |
kahrl |
see e.g. https://github.com/minetest/minetest/issues/3237#issuecomment-147662882 |
| 22:57 |
kahrl |
so strictly speaking, mapgen is architecture and compiler dependent at the moment |
| 22:57 |
kahrl |
at least for lua mapgens. Not sure about minetest_game |
| 22:57 |
kilbith |
well no i highly doubt it's compiler fault |
| 22:58 |
kilbith |
no idea :( i closely checked my config and all from a fresh start |
| 22:59 |
kahrl |
if there's some undefined behaviour in minetest, then compilers can do whatever they want and it's not their fault ;) |
| 23:00 |
kilbith |
i'll inquire furthermore... |
| 23:35 |
|
OldCoder joined #minetest-dev |
| 23:55 |
|
est31 joined #minetest-dev |
| 23:55 |
est31 |
ahh the po file display bug is still there |
| 23:55 |
est31 |
somehow it got missed... |
| 23:55 |
* est31 |
trying to fix |
