| Time |
Nick |
Message |
| 00:00 |
celeron55 |
the compiler can't do that because CONTENT_AIR isn't 0 |
| 00:00 |
celeron55 |
change it to be 0 and it might |
| 00:01 |
hmmmm |
speaking of that |
| 00:01 |
hmmmm |
is there any specific reason why the default content for a MapNode is CONTENT_AIR? |
| 00:01 |
hmmmm |
why not CONTENT_IGNORE? |
| 00:01 |
celeron55 |
it seems a bit odd to me too |
| 00:02 |
hmmmm |
more importantly... would the change break anything |
| 00:02 |
celeron55 |
it probably has some API implications |
| 00:02 |
Megaf |
Zeno`: ? Isnt it too late at your land now? |
| 00:02 |
Zeno` |
"would the change break anything" is the main reason I avoided it |
| 00:02 |
Megaf |
Hi celeron55, have you ever heard about this this? -> http://urho3d.github.io/ |
| 00:02 |
hmmmm |
i want to change it so I don't have to reset the entire buffer to CONTENT_IGNORE when allocating a blank buffer |
| 00:02 |
hmmmm |
lol |
| 00:02 |
hmmmm |
Megaf you silly |
| 00:03 |
celeron55 |
Megaf: what? buildat makes heavy use of that |
| 00:03 |
hmmmm |
celeron is already 5000 steps ahead of you |
| 00:03 |
celeron55 |
and i have even contributed fixes to urho3d 8D |
| 00:03 |
Megaf |
celeron55: cool |
| 00:03 |
Megaf |
so it might run well on Raspberry Pi |
| 00:03 |
Zeno` |
hmmmm, I'm sure it's POD. The only way (in C98) that it's not POD is if you have virtual functions, non-POD members, your own copy constructor or your own destructor |
| 00:03 |
Megaf |
kilbith: you could try buildat on your Raspberry Pi |
| 00:03 |
celeron55 |
Megaf: most likely not at all |
| 00:04 |
celeron55 |
but you can try |
| 00:04 |
kilbith |
GLES seems better supported than Irrlicht |
| 00:04 |
Megaf |
well, it it runs, we can try to make it better, if it doesnt, like minetest, then theres not much we can do about it |
| 00:05 |
Zeno` |
oh, the constructor |
| 00:05 |
Zeno` |
god c++ is hard sometimes |
| 00:05 |
Zeno` |
An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). |
| 00:05 |
Zeno` |
darn |
| 00:05 |
* Megaf |
throws C++ The Bible at Zeno` |
| 00:06 |
celeron55 |
Zeno`: hmmmm's previous point was that C++11 defines it differently and in it it can have a constructor |
| 00:06 |
hmmmm |
we're supposed to be "good" and use std::copy() |
| 00:06 |
Zeno` |
after 0.4.12 maybe I'll work on that whole struct... c55, yeah I know but that would imply dropping support for non C++11 targets |
| 00:07 |
hmmmm |
problem is that now unless we use restrict everywhere it'll place memmove() instead |
| 00:07 |
celeron55 |
Zeno`: my point is that C++03 compilers probably handle it like it was C++11 in practice |
| 00:07 |
hmmmm |
relying on UB is disasterous |
| 00:07 |
hmmmm |
please, don't advocate this |
| 00:07 |
celeron55 |
maybe i shouldn't 8) |
| 00:08 |
celeron55 |
speaking of this, what's the C++11 support status now in the compilers that we want to support |
| 00:08 |
celeron55 |
debian stable has had gcc 4.7 for a while now so that's not an issue anymore |
| 00:09 |
Zeno` |
ok, I'll mark the commit as WIP since it's too late for 0.4.11 anyway (it's not a feature). And then concentrate on the actual data type itself |
| 00:09 |
hmmmm |
I agree |
| 00:09 |
Megaf |
celeron55: 4.9 on the upcoming Debian 8 |
| 00:09 |
Megaf |
4.9.1 |
| 00:09 |
celeron55 |
the remaining issue might be windows, depending on things |
| 00:09 |
hmmmm |
the only reason why we're holding back on c++11 is because I'm a luddite and I don't update my operating system |
| 00:09 |
hmmmm |
:/ |
| 00:09 |
Zeno` |
Centos6.x does not have a C11 compliant compiler I don't think |
| 00:09 |
hmmmm |
there are other reasons too though |
| 00:09 |
celeron55 |
we don't officially support your OS so you're out of luck really 8) |
| 00:09 |
Zeno` |
and Centos6 is a LTS |
| 00:09 |
hmmmm |
what, FreeBSD 9.1? |
| 00:10 |
hmmmm |
minetest officially supported freebsd for a while |
| 00:10 |
celeron55 |
if it has a proper compiler, then yes |
| 00:10 |
celeron55 |
otherwise no |
| 00:10 |
hmmmm |
theoretically it supports freebsd to as far back as 5.x |
| 00:11 |
Zeno` |
I also just realised why many servers have had stuck liquids since 0.4.10 |
| 00:11 |
hmmmm |
:\ |
| 00:11 |
hmmmm |
because celeron was right and you were wrong |
| 00:11 |
hmmmm |
but eh |
| 00:11 |
hmmmm |
it seemed fine to me when i looked at it |
| 00:11 |
Zeno` |
no I'm talking about servers before my change |
| 00:12 |
hmmmm |
oh yeah, liquid transforming has always been broken it seems |
| 00:12 |
hmmmm |
it's a sad state of affairs |
| 00:12 |
Zeno` |
but it's related. That loop is limited (by iterations). If the server shuts down for whatever reason then that queue might still have 100000 or more items in it |
| 00:12 |
kahrl |
there's a PR about that IIRC |
| 00:13 |
Megaf |
I have never had problems with liquids |
| 00:14 |
celeron55 |
hmmmm: but seriously, you can get a recent gcc or clang on freebsd, right? |
| 00:15 |
hmmmm |
you can, but that complicates matters because that adds a build dependency |
| 00:15 |
celeron55 |
when will that happen then? |
| 00:15 |
hmmmm |
more dependencies are bad |
| 00:15 |
celeron55 |
if practically never, then we might just as well go to C++11 now because it will happen some day anyway |
| 00:16 |
celeron55 |
if one year from now, then waiting for it is possible while probably being a bad idea |
| 00:16 |
hmmmm |
i'm sort of scared that people will start using the bad C++11 features |
| 00:16 |
celeron55 |
you probably understand that C++11 makes development much more enjoyable and we have like 5 freebsd users |
| 00:16 |
celeron55 |
i'm going to rage at them and kick them out if they do, don't worry about that |
| 00:16 |
Zeno` |
I think that the UB in the case of 2000 is fine (ROFL). The constructor does nothing wanted anyway |
| 00:17 |
hmmmm |
i think the UB is the object lifetime |
| 00:17 |
hmmmm |
POD has different lifetimes than non-POD types |
| 00:17 |
celeron55 |
the important question is whether our visual studio guys are ready for C++11 |
| 00:17 |
Zeno` |
Yeah because of the destructor though (AFAIK) |
| 00:17 |
celeron55 |
that i do not know but would like to know |
| 00:17 |
Zeno` |
But yeah, UB is bad |
| 00:18 |
hmmmm |
visual studio 2008 is still widely used |
| 00:18 |
hmmmm |
wow, haha, 2008 seems like it's so recent when in fact it happened almost 7 years ago now |
| 00:18 |
Zeno` |
I know at least 2 server operators with VPSs that do not support C++11 |
| 00:18 |
celeron55 |
it really is ancient |
| 00:18 |
Zeno` |
One is me :) |
| 00:19 |
hmmmm |
I look forward to the relaxed PODness rules, move constructors, and std::unordered_map |
| 00:20 |
celeron55 |
frankly there are so little reasons to not move to C++11 now compared to before that we should arrange that to happen in the upcoming months |
| 00:20 |
celeron55 |
so get ready if you aren't |
| 00:21 |
celeron55 |
(personally i've been doing all my C++ programming with C++11 for two years now) |
| 00:21 |
Zeno` |
The easiest "correct" way to fix the issue I kludge in #2000 is to remove the default value for MapNode content_t content in it's constructor so there is a constructor that does nothing. But it's too late to do that now before 0.4.11 is released |
| 00:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/2000 -- Large increase in performance by Zeno- |
| 00:21 |
hmmmm |
what's your take on the foreach loop |
| 00:22 |
celeron55 |
"take"? |
| 00:22 |
celeron55 |
is there an issue with it |
| 00:22 |
celeron55 |
my take is "it works fine, but god forbid anyone who wants to make their own iterable data types" |
| 00:22 |
hmmmm |
just feels like it strays too far from C |
| 00:23 |
celeron55 |
i like it and use it everywhere |
| 00:24 |
celeron55 |
for(auto &it : container){} is lovely |
| 00:25 |
hmmmm |
i've always had the philosophy of using C++ as a C with classes and some other convenience features |
| 00:25 |
celeron55 |
if you ask me, this, if anything, is a convenience feature |
| 00:26 |
celeron55 |
compared to all the inconvenience features that C++ introduces |
| 00:26 |
celeron55 |
but i still hate C++ iterators; they have been designed in hell |
| 00:27 |
celeron55 |
i like the guys who coded them for me for STL types |
| 00:28 |
celeron55 |
did you see my blog post about umm... well this post: http://c55.me/blog/?p=1723 |
| 00:28 |
celeron55 |
you might like the language he is designing |
| 00:28 |
celeron55 |
i certainly do |
| 00:28 |
celeron55 |
https://www.youtube.com/user/jblow888/videos |
| 00:28 |
celeron55 |
</offtopic><sleep> |
| 01:14 |
|
proller joined #minetest-dev |
| 01:19 |
|
paramat left #minetest-dev |
| 01:38 |
|
Megaf_ joined #minetest-dev |
| 02:18 |
|
paramat joined #minetest-dev |
| 02:21 |
paramat |
hmmmmm thanks for the help i was just trying to detect if a node was in the leaves group, however i realised my idea is not good, you were quite right it's too hardcoded |
| 02:21 |
|
Taoki_1 joined #minetest-dev |
| 02:39 |
|
kaeza joined #minetest-dev |
| 03:17 |
paramat |
okay hmmmm #2001 is ready to go, please could you review? I indented the description lines more for clarity, this file has always been hard on the eyes because the description lines are only indented by one space |
| 03:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/2001 -- Update mapgen stuff in minetest.conf. Indent lines for clarity. by paramat |
| 03:19 |
Tesseract |
sfan5: You should set up a MSVC builder and test the Windows builds now. |
| 03:20 |
hmmmm |
are you really going to make a release with those two blockers? |
| 03:20 |
Tesseract |
hmmmm: Those vm helpers would be great, I wrote a few functions to help with that in WorldEdit (eg, we.manip_helpers.finish(vm, data)) |
| 03:21 |
hmmmm |
the windows freeze when selecting serverlist and the always bright wieldmesh with shaders |
| 03:21 |
Tesseract |
hmmmm: Depends if they're fixed in time I guess. |
| 03:22 |
Tesseract |
hmmmm: I heard the wieldmesh thing was an easy fix, but RBA wanted to do a bigger change to the weildhand. |
| 03:24 |
hmmmm |
=/ |
| 03:24 |
hmmmm |
so is he going to fix it or is he not going to fix it |
| 03:35 |
hmmmm |
frankly i don't think we can count on RBA |
| 03:35 |
hmmmm |
at least i don't count on him to get it fixed within a day |
| 03:38 |
hmmmm |
https://github.com/minetest/minetest/commit/249749dd8c06fc7902da648d7ab0986be203888e |
| 03:38 |
hmmmm |
who can help with testing on Windows? |
| 03:41 |
paramat |
tumbleweed can |
| 03:44 |
hmmmm |
so PR 2001 is not a WIP anymore? |
| 03:45 |
paramat |
correct |
| 03:46 |
paramat |
best pull number ever |
| 03:48 |
hmmmm |
who is tumbleweed and how can i get in touch with him? |
| 03:48 |
paramat |
lol |
| 03:48 |
hmmmm |
also wasn't somebody already working on 1959? |
| 04:22 |
paramat |
bbl |
| 04:22 |
|
paramat left #minetest-dev |
| 04:50 |
|
OldCoder joined #minetest-dev |
| 04:50 |
|
OldCoder joined #minetest-dev |
| 04:52 |
|
Zeno` joined #minetest-dev |
| 04:56 |
Zeno` |
2005 ok to merge? |
| 04:56 |
Zeno` |
#2005 |
| 04:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/2005 -- Make limiting of the reflow liquids queue size optional by Zeno- |
| 05:07 |
|
cg72 joined #minetest-dev |
| 05:07 |
cg72 |
Zeno`?? |
| 05:13 |
kaeza |
hmmmm, it works OK, and `src/wieldmesh.cpp:307:17: warning: unused variable 'shdrsrc' [-Wunused-variable]` |
| 05:13 |
kaeza |
(MinGW32) |
| 05:21 |
cg72 |
and here is what i think of this bs >>> http://codepad.org/xJ2HOsMg |
| 05:22 |
cg72 |
go on ban me i dont care some of you have your heads up your rearends!!!! |
| 05:24 |
cg72 |
any comments, email me gingerpollard72 gmail.com |
| 05:27 |
|
Miner_48er joined #minetest-dev |
| 05:27 |
cg72 |
Miner_48er hello |
| 05:28 |
Miner_48er |
hi |
| 05:28 |
Tesseract |
cg72: -> #minetest please. |
| 05:29 |
cg72 |
i was just gonna link him your and is chat log ;) |
| 05:34 |
|
paramat joined #minetest-dev |
| 05:41 |
hmmmm |
aghhh dammit |
| 05:41 |
hmmmm |
kaeza, did you say you were goign to work on fixing #1959? |
| 05:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/1959 -- Checking public serverlist checkbox causes minetest to freeze. |
| 05:42 |
Zeno` |
Oh yeah. I spent some time on that (most of it installing @*$(@*($( what I thought was mingw and turned out not to be mingw :() |
| 05:44 |
hmmmm |
the current theory is that the usage of globals in a multithreaded environment caused a race condition that started affecting things when processing slowed down slightly |
| 05:44 |
Zeno` |
hmmmm, shall I merge 2005? (get the last thing apart from that final blocker out of the road) |
| 05:44 |
hmmmm |
yeah |
| 05:45 |
Zeno` |
hmmmm, kaeza mentioned clicking the checkbox calls async run twice I think. Does that sound right? |
| 05:45 |
Zeno` |
Perhaps the local is get stuck |
| 05:45 |
Zeno` |
grr lock* |
| 05:45 |
hmmmm |
no idea other than speculation |
| 05:45 |
Zeno` |
can't really see how though |
| 05:45 |
hmmmm |
haven't seen that code and i can't test it either |
| 05:57 |
hmmmm |
$%)@#$( |
| 05:58 |
hmmmm |
-Wextra enables a warning the specific flag doesn't exist for -Wtype-limits |
| 05:58 |
hmmmm |
so for g++42 you can't do -Wextra -Wno-type-limits |
| 06:00 |
hmmmm |
in fact, none of the -Wextra options exist in 4.2.2 |
| 06:04 |
|
sol_invictus joined #minetest-dev |
| 06:08 |
hmmmm |
there is, in fact, no way to silence the tmpnam() linker warning |
| 06:13 |
|
Wayward_One joined #minetest-dev |
| 06:37 |
|
srifqi joined #minetest-dev |
| 06:38 |
|
srifqi left #minetest-dev |
| 06:44 |
hmmmm |
has LuaJIT been broken for a very long time for anybody else? |
| 06:44 |
hmmmm |
LuaJIT detection, to be more precise |
| 06:44 |
Zeno` |
Why add Wno-type-limits? |
| 06:44 |
hmmmm |
because I get flooded with annoying type limit warnings |
| 06:44 |
hmmmm |
I guess it must be a gcc thing.. |
| 06:45 |
Zeno` |
I use gcc and get no type limit warnings |
| 06:46 |
Zeno` |
What's an example of one? |
| 06:47 |
hmmmm |
minetest/src/script/lua_api/l_item.cpp:116: warning: comparison is always false due to limited range of data type |
| 06:47 |
hmmmm |
basically all the places where serialization version constants are checked |
| 06:48 |
hmmmm |
e.g. #define BLAH_MIN_SUPPORTED_VERSION 0 |
| 06:48 |
hmmmm |
and then sometime later during serialization or deserialization |
| 06:48 |
hmmmm |
u32 thingversion = deSerializeThing(); if (thingversion < BLAH_MIN_SUPPORTED_VERSION) ... |
| 06:49 |
hmmmm |
this is how all ~20 or so cases occur |
| 06:49 |
Zeno` |
I wonder why I've never seen them. Didn't see them with TDM on Windows the other day either |
| 06:49 |
hmmmm |
they pop up with -Wextra |
| 06:50 |
Zeno` |
oh, I get ~~80000 warnings with -Wextra |
| 06:50 |
hmmmm |
if -Wextra isn't defined, then it just be my compiler acting retarded =] |
| 06:50 |
hmmmm |
any way you look at it, it's a bogus warning |
| 06:52 |
Zeno` |
the example you gave is not a bogus warning though |
| 06:53 |
Zeno` |
that expression *is* always true |
| 06:53 |
hmmmm |
sure |
| 06:53 |
hmmmm |
but it's a constant we're comparing it to |
| 06:53 |
hmmmm |
it's not a mistake like it's made out to be |
| 06:53 |
Zeno` |
it is a mistake, because item.wear cannot (ever) be > 65535 |
| 06:54 |
hmmmm |
oh you're talking about that precise instance |
| 06:54 |
Zeno` |
yeah |
| 06:54 |
hmmmm |
maybe that one is legit but 98% of them that pop up aren't |
| 06:55 |
Zeno` |
I just uneasy about suppressing that warning I guess |
| 06:55 |
hmmmm |
it's important to suppress bogus warnings because they make it difficult to notice actual warnings |
| 06:56 |
hmmmm |
like the last warning i just fixed with the unused variable - i simply could not see that over the flood of nonsense warnings |
| 06:58 |
Zeno` |
I agree there, but I (personally) have never seen a 100% bogus warning from -Wtype-limits ... Convincing myself now :) |
| 07:03 |
Zeno` |
checked 17 so far, and so far no false warnings |
| 07:03 |
Zeno` |
s/false/bogus |
| 07:03 |
hmmmm |
then they ought to be fixed.. from what i personally saw, the majority of them were version-checking-related |
| 07:04 |
Zeno` |
None of them are bogus |
| 07:04 |
Zeno` |
I checked all 33 |
| 07:05 |
hmmmm |
perhaps you have a different definition of 'bogus' then.. |
| 07:05 |
Zeno` |
yeah that's easily fixed. ser_ver_supported() macro is, basically, broken |
| 07:06 |
Zeno` |
possibly :/ |
| 07:10 |
Zeno` |
If they're "bogus" I'd prefer to fix/hide them rather than disabling the warning altogether |
| 07:16 |
Zeno` |
like, that l_item.cpp:116 warning... something is actually broken there. Is the item supposed to be cleared if it overflows or not? |
| 07:17 |
Zeno` |
because it's never true item.clear() can never be called so what was the intention of item.clear()? |
| 07:18 |
Zeno` |
Hiding these by suppressing them at the compiler level is not a great idea IMHO |
| 07:18 |
hmmmm |
got any better ideas? |
| 07:18 |
Zeno` |
yeah manually fix them |
| 07:18 |
hmmmm |
in any case, you're right and i never said otherwise |
| 07:18 |
Zeno` |
or, I'll do it |
| 07:18 |
hmmmm |
l_item.cpp:116 is busted |
| 07:18 |
Zeno` |
but I don't know what to do about l_item.cpp:116 heh |
| 07:19 |
hmmmm |
the logic is completely broken |
| 07:19 |
Zeno` |
Because I'm not sure what the original intention actually was |
| 07:19 |
hmmmm |
if the attempted wear setting results in an overflow, simply don't set it |
| 07:19 |
hmmmm |
nothing is documented about set_wear aside from the fact that it takes "wear" as a parameter |
| 07:20 |
hmmmm |
this documentation is so pathetic... |
| 07:20 |
VanessaE |
er, wouldn't the expected behavior be to max it out? |
| 07:20 |
hmmmm |
that's acceptable too |
| 07:20 |
hmmmm |
i'm trying to think of the situation where somebody would call set_wear() with too large of a value |
| 07:21 |
VanessaE |
"super" tool repair. |
| 07:21 |
hmmmm |
exactly |
| 07:21 |
hmmmm |
I'm thinking that maybe it would increment the wear every so much amount of time |
| 07:22 |
hmmmm |
+100, +100, +100, etc. |
| 07:22 |
hmmmm |
so who's fixing l_set_wear?? |
| 07:22 |
VanessaE |
or something like that too. something like the equivalent to "quad damage" |
| 07:22 |
hmmmm |
i agree that it should be MIN(luaL_checkinteger(L, 2), 65535) |
| 07:25 |
hmmmm |
PilzAdam wrote the entire series of set_* in that file and they all handle failure in the same defective manner |
| 07:25 |
hmmmm |
if he comes around I'd like to hear the rationale |
| 07:27 |
|
paramat left #minetest-dev |
| 07:30 |
hmmmm |
and then item:set_name(5) should in theory crash the game |
| 07:34 |
Zeno` |
so... 0: original networked test with 1-byte nodes <-- that serialization version is still supported? |
| 07:35 |
hmmmm |
technically yes |
| 07:37 |
|
jin_xi joined #minetest-dev |
| 07:43 |
Zeno` |
ok well that's easy to fix |
| 07:43 |
Zeno` |
then just the crazy ones in connection.cpp |
| 07:44 |
Zeno` |
(peer_id <= MAX_UDP_PEERS) is checked 5 times, but nothing seems to be done if it's false (probably because it can never be false) |
| 07:54 |
Zeno` |
so if peer_id <= MAX_UDP_PEERS is actually checked in a sensible way (not sure how) and only once then that's all but 1 of the warnings gone |
| 07:58 |
|
abstruselyarcane joined #minetest-dev |
| 07:59 |
|
abstruselyarcane left #minetest-dev |
| 08:01 |
Zeno` |
and that only remains because it's a bug |
| 08:01 |
Zeno` |
found because of the warning :P |
| 08:01 |
|
Hunterz joined #minetest-dev |
| 08:13 |
Zeno` |
https://github.com/Zeno-/minetest/commit/e517f0368b0f8b6bff49081541c0f0443e99b66c <-- all fixed |
| 08:13 |
Zeno` |
and we don't miss stuff that might be an actual error in the futue |
| 08:13 |
Zeno` |
night all |
| 08:24 |
|
SmugLeaf joined #minetest-dev |
| 08:51 |
|
gregorycu joined #minetest-dev |
| 08:57 |
|
kilbith joined #minetest-dev |
| 09:41 |
|
Krock joined #minetest-dev |
| 09:53 |
|
FR^2 joined #minetest-dev |
| 10:11 |
|
exio4 joined #minetest-dev |
| 10:17 |
|
CraigyDavi joined #minetest-dev |
| 10:39 |
|
selat joined #minetest-dev |
| 10:43 |
|
kilbith joined #minetest-dev |
| 11:00 |
|
ImQ009 joined #minetest-dev |
| 11:29 |
|
PilzAdam joined #minetest-dev |
| 11:53 |
kilbith |
sfan5: https://github.com/minetest/minetest_game/pull/386 |
| 11:56 |
|
PilzAdam joined #minetest-dev |
| 12:25 |
|
Krock joined #minetest-dev |
| 12:25 |
|
MichaelRpdx joined #minetest-dev |
| 12:25 |
|
kahrl joined #minetest-dev |
| 12:25 |
|
DuDraig joined #minetest-dev |
| 12:25 |
|
SmugLeaf joined #minetest-dev |
| 12:26 |
|
sol_invictus joined #minetest-dev |
| 12:26 |
|
compunerd joined #minetest-dev |
| 12:26 |
|
harrison joined #minetest-dev |
| 12:26 |
|
Tesseract joined #minetest-dev |
| 12:26 |
|
Aaron1011 joined #minetest-dev |
| 12:26 |
|
PilzAdam joined #minetest-dev |
| 12:26 |
|
jin_xi joined #minetest-dev |
| 12:26 |
|
Bratmon joined #minetest-dev |
| 12:26 |
|
Hunterz joined #minetest-dev |
| 12:26 |
|
Taoki_1 joined #minetest-dev |
| 12:26 |
|
celeron55 joined #minetest-dev |
| 12:26 |
|
blaise joined #minetest-dev |
| 12:28 |
|
OldCoder joined #minetest-dev |
| 12:28 |
|
JZTech101 joined #minetest-dev |
| 12:28 |
|
pitriss joined #minetest-dev |
| 12:34 |
|
gregorycu_ joined #minetest-dev |
| 12:40 |
|
proller joined #minetest-dev |
| 12:50 |
kilbith |
PilzAdam: 386 updated. |
| 12:59 |
* Megaf_ |
would like a new 80386. One like the original, but built with all new technology we have. |
| 12:59 |
Megaf_ |
I wonder how much energy would it comsume |
| 12:59 |
Megaf_ |
consume |
| 13:16 |
|
Amaz joined #minetest-dev |
| 13:24 |
gregorycu |
So, I think I've found a bug |
| 13:26 |
Krock |
gregorycu, get a book and kill that bug |
| 13:26 |
gregorycu |
It may be a feature... |
| 13:26 |
gregorycu |
It's one of those bugs that looks so bug that it can't be a bug |
| 13:26 |
gregorycu |
Looks so big |
| 13:57 |
|
roniz joined #minetest-dev |
| 14:03 |
|
proller joined #minetest-dev |
| 14:13 |
Megaf_ |
gregorycu: is that a spider? |
| 14:13 |
Megaf_ |
gregorycu: just say what you found at once. |
| 14:13 |
gregorycu |
I cleared it up with a dev, all good |
| 14:13 |
gregorycu |
User error |
| 14:13 |
gregorycu |
I was said user |
| 14:21 |
|
Anchakor_ joined #minetest-dev |
| 14:40 |
|
Robby joined #minetest-dev |
| 14:50 |
|
shadowzone joined #minetest-dev |
| 14:51 |
|
MinetestForFun joined #minetest-dev |
| 14:52 |
|
Amaz joined #minetest-dev |
| 15:15 |
kilbith |
sfan5: https://github.com/minetest/minetest_game/pull/387 |
| 15:37 |
kahrl |
why kilbith2/kilbith3? |
| 15:38 |
|
Bratmon joined #minetest-dev |
| 15:39 |
kilbith |
because haven't figure out how to submit PRs in ignoring the previous commits on the same account |
| 15:39 |
kahrl |
make a branch for each PR |
| 15:39 |
kahrl |
branches are much easier to manage than multiple SSH keys, IMO :P |
| 15:40 |
kilbith |
someones has explained me but Git is mysterious env. for me |
| 15:40 |
kahrl |
well if it works for you, no problem |
| 15:49 |
kahrl |
all you really need to know is these four steps: |
| 15:49 |
kahrl |
1. git checkout -b branchname # make a new branch |
| 15:49 |
kahrl |
2. git add ...; git commit ... # as usual |
| 15:49 |
kahrl |
3. git push origin branchname # replace "origin" if your remote is called something else |
| 15:49 |
kahrl |
and finally 4. git checkout master # switch back to the master branch |
| 15:52 |
kilbith |
ok, i paste those steps somewhere for an eventual try later |
| 16:16 |
|
zat joined #minetest-dev |
| 16:18 |
|
shadowzone joined #minetest-dev |
| 16:20 |
sfan5 |
http://sprunge.us/FCWP << pushing in 5 minutes |
| 16:22 |
PilzAdam |
sfan5, why does the build script fetch that from your server? |
| 16:24 |
|
luizrpgluiz joined #minetest-dev |
| 16:25 |
Krock |
PilzAdam, it's not sfan5's server :P |
| 16:27 |
|
hmmmm joined #minetest-dev |
| 16:27 |
kilbith |
PilzAdam: the straw texture is original from me, you should check that closely. |
| 16:27 |
PilzAdam |
Krock, it looks like it |
| 16:28 |
PilzAdam |
kilbith, see my comment on the issue |
| 16:28 |
hmmmm |
hello PilzAdam |
| 16:28 |
PilzAdam |
hi hmmmm |
| 16:28 |
hmmmm |
mind if I ask why you decided to clear the item on failure here https://github.com/minetest/minetest/commit/a9c0961e0c9c3b854aca34b6d582198be1cd2277 ? |
| 16:29 |
PilzAdam |
ummm.... because.... um... how old is this? |
| 16:30 |
hmmmm |
looks like a little over a year |
| 16:30 |
|
Amaz joined #minetest-dev |
| 16:30 |
Krock |
0.4.10 |
| 16:30 |
Krock |
no no. 0.4.8 actually |
| 16:30 |
PilzAdam |
I'm pretty sure I just copied it from somewhere else |
| 16:32 |
PilzAdam |
hmmmm, what do you mean by "failure"? |
| 16:33 |
PilzAdam |
it seems like it's the same result as if you would create a new itemstack with the same count / name / wear |
| 16:33 |
|
exio4 joined #minetest-dev |
| 16:33 |
hmmmm |
for example in l_set_wear, if the new value to set is greater than the max, instead of just setting the max you... clear all item attributes |
| 16:33 |
PilzAdam |
a wear of > max means the item is broken |
| 16:33 |
hmmmm |
or what if it could be getting repaired by something else in the mod and they do something like: |
| 16:34 |
hmmmm |
minetest.set_wear(minetest.get_wear() + 100) every use |
| 16:34 |
hmmmm |
surely that's not broken, right..? |
| 16:34 |
PilzAdam |
thats not repairing |
| 16:34 |
PilzAdam |
- 100 would be repairing |
| 16:35 |
hmmmm |
oh |
| 16:35 |
|
luizrpgluiz left #minetest-dev |
| 16:35 |
kilbith |
PilzAdam: i've never been credited for my previous textures. |
| 16:35 |
|
proller joined #minetest-dev |
| 16:35 |
hmmmm |
still though, why clear and not just item.wear = MYMIN(luaL_checkinteger, 65535)? |
| 16:35 |
PilzAdam |
kilbith, this should be fixed, then; please create an issue with the list of textures for that |
| 16:36 |
PilzAdam |
hmmmm, if you do minetest.set_wear(minetest.get_wear() + 100) each time you use a tool, you expect it to break automatically |
| 16:36 |
PilzAdam |
and "breaking" is clearing the itemstack |
| 16:36 |
kilbith |
nah, thank you. i don't want to bother with the licenses |
| 16:37 |
PilzAdam |
kilbith, this may bring us in legal trouble... *shrug* |
| 16:38 |
PilzAdam |
hmmmm, https://github.com/minetest/minetest_game/blob/master/mods/farming/api.lua#L48-51 e.g. here we just increase the wear each time |
| 16:38 |
PilzAdam |
hmmmm, maybe it should be documented in lua_api.txt? |
| 16:39 |
hmmmm |
i think so... |
| 16:39 |
hmmmm |
doesn't that break when uses == 1? |
| 16:40 |
PilzAdam |
yes, but there is no hoe with 1 use |
| 16:47 |
hmmmm |
fair enough... anyway would you care to fix the l_set_* item code? |
| 16:48 |
hmmmm |
and add better documentation |
| 16:52 |
|
celeron55 joined #minetest-dev |
| 16:55 |
|
T4im joined #minetest-dev |
| 16:59 |
|
nore joined #minetest-dev |
| 17:01 |
|
Calinou joined #minetest-dev |
| 17:30 |
sfan5 |
..that were some long 5 minutes |
| 17:30 |
sfan5 |
PilzAdam: because ubuntu's mingw is very outdated |
| 17:35 |
|
ImQ009 joined #minetest-dev |
| 17:40 |
PilzAdam |
hmmmm, fix? what is broken? |
| 17:59 |
|
sfan5 joined #minetest-dev |
| 18:05 |
|
exio4 joined #minetest-dev |
| 18:08 |
|
ImQ009 joined #minetest-dev |
| 18:12 |
|
PilzAdam joined #minetest-dev |
| 18:35 |
|
petrusd987 joined #minetest-dev |
| 18:35 |
|
ImQ009 joined #minetest-dev |
| 18:53 |
Calinou |
https://github.com/minetest/minetest_game/pull/387#issuecomment-67981441 |
| 18:53 |
Calinou |
WTF |
| 18:55 |
celeron55 |
why is kilbith ragequiting because of that |
| 18:55 |
celeron55 |
it's a 100% valid concern |
| 18:55 |
kilbith |
the reason is explicit |
| 18:55 |
celeron55 |
and easy to solvev |
| 18:55 |
celeron55 |
solve* |
| 18:56 |
celeron55 |
and the reply already solves the issue so there's no need to close it |
| 18:59 |
Krock |
I would love strawballs |
| 19:01 |
Calinou |
we can make our own texture anyway, if really needed |
| 19:01 |
Calinou |
would be sad, as the proposed one is g ood |
| 19:02 |
* Krock |
wonders about the difference of kilbith and kilbith3 |
| 19:03 |
kilbith |
none |
| 19:03 |
celeron55 |
that was discussed earlier here, see the same question from kahrl |
| 19:06 |
Krock |
kilbith, why do you close good pulls? #341 is fine to discuss header images and stuff. |
| 19:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/341 -- minetest/doc/protocol.txt is far out of date |
| 19:06 |
Krock |
no no. the one from MTG |
| 19:07 |
celeron55 |
ShadowBot needs to support some kind of mt_game#341 style format |
| 19:07 |
Krock |
^ |
| 19:08 |
Krock |
Tesseract, have you got some free time? ^^ |
| 19:09 |
|
paramat joined #minetest-dev |
| 19:09 |
kilbith |
Krock: just tired of the constant beg for rise up the PRs, and polemical spirit. |
| 19:09 |
celeron55 |
kilbith: you are totally allowed to just leave PRs hanging around and go do something else meanwhile, and they often have to be discussed about quite much so you have to leave room for that |
| 19:09 |
Krock |
^ exactly, mostly, the theme still remains |
| 19:13 |
paramat |
i made a one-letter typo in .conf.example, fix incoming |
| 19:17 |
|
dzho joined #minetest-dev |
| 19:34 |
|
casimir joined #minetest-dev |
| 19:36 |
|
dzho joined #minetest-dev |
| 19:46 |
Tesseract |
game#341 |
| 19:46 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/341 -- New header image by kilbith |
| 19:49 |
|
shadowzone joined #minetest-dev |
| 19:49 |
|
Selah joined #minetest-dev |
| 20:03 |
Krock |
:D |
| 20:07 |
|
ImQ009 joined #minetest-dev |
| 20:08 |
|
VanessaE joined #minetest-dev |
| 20:12 |
|
proller joined #minetest-dev |
| 20:17 |
paramat |
#2008 is ready for merge |
| 20:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/2008 -- Conf.example: Fix typo in mapgen stuff by paramat |
| 20:19 |
hmmmm |
PilzAdam: specifically, the conditions of clearing for several of the api |
| 20:19 |
hmmmm |
1). l_set_name - why is item.empty() part of the condition? |
| 20:19 |
hmmmm |
2). l_set_count - copy paste error. you forgot to modify the condition to check for an item count overflow |
| 20:20 |
hmmmm |
3). l_set_wear - you assign the lua integer to a u16 and then do a comparison that could never evaluate to true due to the range of the data type |
| 20:23 |
hmmmm |
4). l_set_metadata - on invalid metadata, you don't clear the ItemStack like you do with the rest of the set_* apis |
| 20:23 |
sfan5 |
celeron55: the mesh-creation-is-slow problem doesn't seem to be limited to intel: https://cdn.mediacru.sh/d/dA2O0koHr3J_.png (AMD CPU + GPU, 0.4.11-rc1 win64) |
| 20:23 |
hmmmm |
but failure is impossible because the value at index 2 is a string. if it weren't a string, it would have thrown a LuaError and it'd never get a chance to execute the conditional |
| 20:23 |
celeron55 |
sfan5: intel is the only one that it generally *doesn't* affect |
| 20:24 |
hmmmm |
and why are you using checklstring anyway? you don't really need the length here.... |
| 20:24 |
sfan5 |
oh right |
| 20:24 |
celeron55 |
sfan5: because intel uses shared memory; that makes buffer transfer fast |
| 20:24 |
hmmmm |
item.metadata = luaL_checkstring(L, 2); |
| 20:24 |
sfan5 |
s/doesn't seem to be limited to intel/happens on windows too/ then |
| 20:24 |
celeron55 |
intel drivers on windows are bad |
| 20:24 |
celeron55 |
they use different code than linux ones |
| 20:28 |
celeron55 |
anyway, the limiting factor is the amount of opengl buffer objects; i.e. meshes should use as few meshbuffers (irrlicht terminology) as possible, in addition to there being as few meshes as possible |
| 20:28 |
celeron55 |
this means that texture atlases should be taken into use again |
| 20:28 |
sfan5 |
every MapBlock is a at least one mesh, correct? |
| 20:28 |
celeron55 |
yes, which currently has one meshbuffer per texture |
| 20:29 |
celeron55 |
one meshbuffer is one opengl object, basically |
| 20:29 |
hmmmm |
wait, texture atlases should be used again, for intel drivers? |
| 20:29 |
hmmmm |
or in general |
| 20:29 |
celeron55 |
it benefits others than intel the most |
| 20:30 |
celeron55 |
MT performs best on linux+intel currently due to... reasons |
| 20:30 |
celeron55 |
(when comparing to the actual performance of the given hardware) |
| 20:31 |
hmmmm |
there's a reason for that. i think you mentioned a while ago that minetest uses low-bandwidth streaming rather than bursts of data to the pipeline |
| 20:31 |
hmmmm |
or something like that |
| 20:31 |
celeron55 |
there are basically two performance reasons now for getting texture atlases back; one is rendering speed and one is mesh creation speed |
| 20:32 |
celeron55 |
both are limited by object count right now |
| 20:32 |
celeron55 |
(on modern hardware) |
| 20:32 |
hmmmm |
i thought the need for a texture atlas went away with texture sorting |
| 20:32 |
hmmmm |
so basically you're just looking to minimize the number of textures loaded? |
| 20:32 |
celeron55 |
not at all |
| 20:32 |
celeron55 |
it only helps rendering a bit |
| 20:33 |
Tesseract |
http://sprunge.us/CJYZ?diff fixes #2006 |
| 20:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/2006 -- Error when deleting a world |
| 20:33 |
celeron55 |
that helps rendering but doesn't affect mesh creation |
| 20:33 |
Tesseract |
(untested though) |
| 20:33 |
hmmmm |
then how come we didn't see any real-world performance gains with the texture atlas enabled |
| 20:33 |
celeron55 |
hmmmm: there is a large cost in creating a new opengl object; which maps to an irrlicht meshbuffer; that's the mesh creation issue |
| 20:34 |
Tesseract |
Complies at least. |
| 20:34 |
celeron55 |
hmmmm: it must have been tested very poorly |
| 20:35 |
hmmmm |
so a texture atlas would help with cpu-bound mesh generation??? |
| 20:35 |
celeron55 |
yes; there is a large cost on dedicated GPUs for each created opengl object (=meshbuffer in irrlicht) |
| 20:35 |
hmmmm |
how would this affect multiple mesh making threads? |
| 20:35 |
celeron55 |
when each texture is actually the same texture, you often need only one meshbuffer |
| 20:36 |
celeron55 |
irrlicht only supports one thread so they are first given to the main thread |
| 20:36 |
celeron55 |
if we used raw opengl we could upload them to the GPU from multiple threads (if we drop support for old cards) |
| 20:37 |
celeron55 |
i guess that won't help much if the object count stays the same though |
| 20:37 |
celeron55 |
or maybe it might; there are all kinds of tricks that are doable at that level |
| 20:37 |
hmmmm |
obviously we can add options to this or auto-detect based on card |
| 20:39 |
PilzAdam |
hmmmm, sorry, I don't have time for this now |
| 20:39 |
PilzAdam |
can you create an issue on github for that? |
| 20:39 |
hmmmm |
i could just do it in 5 minutes |
| 20:40 |
celeron55 |
http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsights-AsynchronousBufferTransfers.pdf |
| 20:40 |
celeron55 |
here's the full log with this channel's opengl driver guy: |
| 20:40 |
celeron55 |
http://fpaste.org/162548/67191141/ |
| 20:40 |
celeron55 |
if someone has time for investigating this issue |
| 20:44 |
celeron55 |
so, well, basically there are two layers to this issue: 1) MT is using irrlicht inefficiently (no texture atlas, maybe too small meshes) and 2) irrlicht cannot provide very good performance for an open world block game like MT because it simply wasn't made for that; it's a generic engine that uses an unsuitable abstraction level for getting top performance out of hardware in this case |
| 20:45 |
hmmmm |
i think it's the nail in the coffin for including a forked irrlicht |
| 20:45 |
hmmmm |
(besides, you did that with urho3d) |
| 20:45 |
sfan5 |
would it be a good tradeoff to merge 4x4x4 (or 2x2x2) "cubes" of MapBlocks? |
| 20:45 |
celeron55 |
my urho3d fork is actually currently totally following upstream except for a bugfix that i was too lazy to PR |
| 20:46 |
hmmmm |
if it's sufficiently compartmentalized i think we'd be able to follow upstream |
| 20:46 |
hmmmm |
and make PRs for them concurrently |
| 20:46 |
sfan5 |
https://github.com/minetest/minetest/pull/2008.diff << merging in 5 mins (it's paramat's typo fix) |
| 20:46 |
hmmmm |
sfan5: sure |
| 20:47 |
celeron55 |
sfan5: 2x2x2 would probably give a lot of benefit on modern hardware, yes |
| 20:47 |
celeron55 |
assuming mesh upload is does not get too slow |
| 20:48 |
celeron55 |
(it probably won't) |
| 20:48 |
celeron55 |
2x2x2 would also destroy performance on old hardware like the laptop i originally made MT on |
| 20:48 |
celeron55 |
too many vertices |
| 20:48 |
celeron55 |
it should be configurable at runtime |
| 20:49 |
sfan5 |
benchmark this once, save results in a file, load on every startup; ???; profit |
| 20:49 |
celeron55 |
also 2x2x2 is too small for really fast hardware |
| 20:49 |
sfan5 |
I think that might work |
| 20:49 |
celeron55 |
on some $1000 cards you probably want 3x3x3 or even more |
| 20:52 |
|
paramat left #minetest-dev |
| 20:53 |
kahrl |
<hmmmm> and why are you using checklstring anyway? you don't really need the length here.... <-- item metadata can contain NULs |
| 20:53 |
hmmmm |
ahhh.. |
| 20:59 |
|
chchjesus joined #minetest-dev |
| 21:11 |
|
electrodude512 joined #minetest-dev |
| 21:14 |
|
Sokomine joined #minetest-dev |
| 21:29 |
|
calgui joined #minetest-dev |
| 21:31 |
|
calgui left #minetest-dev |
| 21:35 |
|
Krock joined #minetest-dev |
| 21:53 |
|
OldCoder joined #minetest-dev |
| 21:53 |
|
OldCoder joined #minetest-dev |
| 22:15 |
|
shadowzone joined #minetest-dev |
| 22:15 |
Wayward_One |
I too have a typo fix for minetest.conf.example: https://github.com/minetest/minetest/pull/2009 |
| 22:20 |
|
shadowzone joined #minetest-dev |
| 22:42 |
|
FungusAdam joined #minetest-dev |
| 22:44 |
|
prol joined #minetest-dev |
| 22:44 |
|
pro joined #minetest-dev |
| 22:46 |
|
proller joined #minetest-dev |
| 22:54 |
|
paramat joined #minetest-dev |
| 22:56 |
paramat |
Wayward_One, i can include your typo fix in my next edit of .conf.example if that's okay with you |
| 22:59 |
paramat |
i actualy have another edit of that file i'd like to do within the next hour, if there's time before release |
| 22:59 |
Wayward_One |
Sure, go ahead :) |
| 23:03 |
paramat |
ok i'll get working on it now. i want to state biome noises in positional format and increase indentation for the rest of the file (if that's okay with devs) |
| 23:20 |
|
MinetestForFun joined #minetest-dev |
| 23:22 |
|
Zeno` joined #minetest-dev |
| 23:27 |
shadowzone |
Hi Zeno` |
| 23:33 |
|
mrtux joined #minetest-dev |
