Minetest logo

IRC log for #minetest-dev, 2014-12-23

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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/commi​t/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/commi​t/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/minetes​t/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/minetes​t/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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext