Minetest logo

IRC log for #minetest-dev, 2015-05-05

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

All times shown according to UTC.

Time Nick Message
00:03 est31 why exactly is "do {} while(0)" there?
00:06 est31 ShadowNinja ^
00:07 ShadowNinja est31: It ensures that you add a semicolon after it.
00:12 est31 ah ok
00:36 hmmmm do {} while (0) is weird
00:36 hmmmm if anything you should be using
00:36 hmmmm #define THING(x) do { \
00:36 hmmmm macro body here \
00:37 hmmmm } while (0)
00:38 hmmmm also, i believe it is a specious argument that we need the extra custom type check.
00:38 hmmmm when that type becomes a field of another custom type, then we need to add yet another check
00:39 hmmmm and each time we lost sight of what the actual incorrect field inside of the custom parameter is
00:39 hmmmm i.e. foobar = {thing = "blah", size = {x=45, y=nil}}
01:17 Hijiri joined #minetest-dev
01:24 yh1986 joined #minetest-dev
01:32 yh1986 rtt failed on android, i resolved
01:32 est31 how did you make shaders work on android?
01:35 yh1986 line 1016 "driver->setRenderTarget(0, false, true, 0);" should before line 1010 "driver->endScene();" in file "tile.cpp"
01:36 yh1986 otherwise can't render to texture on android
01:37 yh1986 +est31, copy assets to sdcard and change usr_path, enable es2 and shaders
01:38 est31 what do you mean with "change usr_path"?
01:40 yh1986 point your source path
01:41 est31 yh1986, do you know git? Could you make a pull request?
01:47 yh1986 currently, i work on android with oges2 and shaders, though it can work, but many things to resolve, such as skybox render etc
01:47 est31 yh1986, it would be great if you could help to resolve those issues, I guess your english is bad?
01:50 yh1986 yes
01:51 est31 first, you should install git, read this book: http://git-scm.com/book/zh/v1
01:51 est31 then get newest minetest from https://github.com/minetest/minetest
01:52 est31 From the line numbers you told me I can tell that your minetest version isn't newest
01:52 yh1986 i know git,
01:53 yh1986 yes, i git clone many days ago
01:55 est31 It would be best if you had newest git master. Either clone again or git pull. Then make a commit with the android fix, and publish it on github
02:03 ShadowNinja hmmmm: What do you mean?  You want "field x/y/z" to be specified in the pos messages?
02:04 kaeza joined #minetest-dev
02:08 ShadowNinja D-: https://github.com/minetest/minetest/commi​t/4ea5a96fffb1a0300f73e97d4c85bb5c32e3786d
02:09 ShadowNinja _C implies a c-string, _LOWER is shorter than _CAPITALIZED, and the other way you're less likely to use _LOWER accidentally!
02:11 hmmmm we had a vote on it.
02:11 ShadowNinja Also, you could rebase instead of reverting conflicts.
02:12 ShadowNinja hmmmm: And it was a near-tie.
02:12 hmmmm 6-4???
02:12 ShadowNinja hmmmm: What's the advantage of doing it this way?
02:12 hmmmm "_C implies a C-string" - maybe to you, I've never seen _C on a macro mean anything
02:13 hmmmm because it doesn't make sense to optimize for a less common case
02:13 hmmmm in the majority of cases you want to use the lower case string version
02:13 kahrl how about _CAPS
02:13 hmmmm how about we stop talking about it already :p
02:14 hmmmm if you want to bother, sure
02:14 hmmmm this is so silly
02:14 ShadowNinja Currently perhaps, but part of that is legacy issues where the lowercase version was used when it should be uppercase.
02:14 ShadowNinja kahrl: That sounds better.
02:15 kahrl although it might imply all-caps
02:15 kahrl dunno
02:16 zat joined #minetest-dev
02:23 hmmmm speaking of PROJECT_NAME
02:23 kaeza how about _TITLE? (Titlecase)
02:23 hmmmm misc/winresource.rc should probably be updated or something
02:24 hmmmm PROJECT_NAME ".exe"
02:24 hmmmm and lol @ legal trademarks
02:24 hmmmm VALUE "LegalTrademarks", """Minetest"" is the property of the Minetest community, don't use it without permission!"
02:24 hmmmm Don't you dare use minetest, or else!
02:25 kaeza a dungeon master will eat you while you sleep!
02:25 * kaeza goes back to something more important (no offense intended)
02:25 hmmmm no offense taken :p
03:01 book` joined #minetest-dev
03:23 book` joined #minetest-dev
03:29 leat3 joined #minetest-dev
03:51 FR^4 joined #minetest-dev
03:54 FR^4 joined #minetest-dev
04:01 yh1986 joined #minetest-dev
04:03 yh1986 joined #minetest-dev
04:03 yh1986 joined #minetest-dev
04:04 FR^4 joined #minetest-dev
04:14 FR^4 joined #minetest-dev
04:20 crazyR_ joined #minetest-dev
05:05 Hunterz joined #minetest-dev
05:26 Wayward_Tab joined #minetest-dev
05:28 jin_xi joined #minetest-dev
05:29 leat3 joined #minetest-dev
06:00 Zeno` joined #minetest-dev
06:12 cib0 joined #minetest-dev
06:20 Wayward_Tab joined #minetest-dev
06:23 sfan5 hmmmm: do you want Minetest.exe or what?
06:24 nore joined #minetest-dev
06:30 hmmmm the resource file has selective editing
06:30 hmmmm some fields use PROJECT_NAME, a few others do not
06:30 kaeza joined #minetest-dev
06:31 sfan5 VALUE "LegalTrademarks", ""PROJECT_NAME_C" is the property of the "PROJECT_NAME_C" community, don't use it without permission!"
06:31 sfan5 is probably not what we want
06:50 kilbith joined #minetest-dev
07:19 Darcidride joined #minetest-dev
07:36 Calinou joined #minetest-dev
07:48 err404 joined #minetest-dev
08:00 Yepoleb_ joined #minetest-dev
08:00 FR^2 joined #minetest-dev
08:01 Calinou joined #minetest-dev
08:25 cib0 joined #minetest-dev
09:21 ElectronLibre joined #minetest-dev
09:24 Megaf_ joined #minetest-dev
09:49 kaeza joined #minetest-dev
09:50 book` joined #minetest-dev
09:55 OldCoder joined #minetest-dev
10:11 book` joined #minetest-dev
10:16 cib0 joined #minetest-dev
10:29 proller joined #minetest-dev
10:36 OldCoder joined #minetest-dev
10:37 selat joined #minetest-dev
10:47 OldCoder joined #minetest-dev
10:51 Anchakor joined #minetest-dev
10:51 kilbith joined #minetest-dev
10:53 OldCoder joined #minetest-dev
11:18 book` joined #minetest-dev
11:23 Darcidride joined #minetest-dev
11:31 ElectronLibre joined #minetest-dev
11:35 OldCoder joined #minetest-dev
11:38 err404 joined #minetest-dev
11:47 OldCoder joined #minetest-dev
11:55 book` joined #minetest-dev
12:13 ElectronLibre joined #minetest-dev
12:18 proller joined #minetest-dev
12:41 Hunterz joined #minetest-dev
12:44 err404 joined #minetest-dev
12:44 book` joined #minetest-dev
13:16 kaeza_ joined #minetest-dev
13:28 selat joined #minetest-dev
13:29 ElectronLibre joined #minetest-dev
13:34 err404 joined #minetest-dev
13:52 ElectronLibre joined #minetest-dev
14:05 book` joined #minetest-dev
14:07 proller joined #minetest-dev
14:14 ElectronLibre joined #minetest-dev
14:29 hmmmm joined #minetest-dev
15:03 Zeno` joined #minetest-dev
15:07 est31 joined #minetest-dev
15:17 Zeno` ShadowNinja, you missed one: https://github.com/minetest/minetest/b​lob/master/src/porting_android.cpp#L46
15:18 Zeno` personally I'd change that to char argv[] = PROJECT_NAME; and the next line to main(1, (char **)&argv);
15:19 Zeno` (I think the cast is necessary, but not 100% sure)
15:19 Zeno` in C I don't think it would be, but C++ I think it is
15:40 hmmmm I still can't understand the for (int i = 0; ...)   ... for (int i = 0; ...) warning
15:40 hmmmm these files are being compiled as *c++*
15:41 hmmmm it was always correct under ISO C++ to contain variable scoping to the conditional's block
15:42 hmmmm FWIW, I've never seen that warning before, and I am nearly certain that same exact code construct exists in other places too, not only test_random.cpp
15:42 est31 perhaps its because it has been declared inside the initial clause of the for loop?
15:43 hmmmm well, yes, that's the because, but the fact remains that MSVC (and apparently some oddball version of gcc??) complain about ISO C++ conformant behavior based on C89 scoping rules
15:44 hmmmm i feel that it would be more correct to disable those warnings than to modify my ISO C++ conformant code
15:44 Zeno` I don't understand it either
15:45 Zeno` Because as hmmmm said, the scoping rules have always been that way
15:46 Zeno` But, gcc does emit that warning. What the "old rules" it refers to are... I have nfi
15:46 hmmmm https://github.com/kwolekr/minetest/commit​/8e9efe7aaa36bb353b05370d20d696a47bfb6930
15:46 hmmmm Zeno`:  old C rules
15:46 hmmmm the theory goes that if it's being compiled as C++ there'd be no problem ...
15:47 hmmmm is some kind of pre-standardization C++ mode enabled on gcc?
15:49 cib0 joined #minetest-dev
15:50 Zeno` old C rules?
15:50 Zeno` C wouldn't have even compiled
15:50 hmmmm right
15:50 hmmmm hmm
15:50 hmmmm -traditional-cpp
15:51 Zeno` hmm
15:51 Zeno` maybe c99 would have I'm not sure
15:51 Zeno` maybe it's an old gcc bug
15:51 est31 /join #gcc
15:52 Zeno` OR a SoC volunteer decided to add the warning
15:52 Zeno` heh
15:52 Zeno` either way it's no big deal really... just a bit baffling
15:55 hmmmm -traditional-cpp doesn't seem to affect it
15:55 hmmmm meh
15:58 hmmmm https://github.com/kwolekr/minetest/commit​/8e9efe7aaa36bb353b05370d20d696a47bfb6930
15:59 kilbith joined #minetest-dev
16:29 hmmmm anybody?
16:36 est31 hmmmm, why make unknown now hardcoded?
16:36 hmmmm it's only unknown if there is no ndef associated to that noderesolver
16:37 hmmmm there can be multiple INodeDefManagers each with their own name for unknown node, so I figure this is good enough
16:37 hmmmm we're going to have to hard code it somewhere, there's not really any good way around this
16:38 est31 yes, but as I see it its now hardcoded at one place more?
16:39 hmmmm what i'm saying is that due to the semantics involved, this is a detail that cannot be softcoded
16:43 est31 yes but its a better practice to have hardcoding at only one place than hardcoding at multiple places
16:43 Robert_Zenz joined #minetest-dev
16:43 est31 because changing is then easier and less error prone
16:43 hmmmm alright maybe you're not understanding the way i'm explaining this
16:44 hmmmm the "unknown" string inside NodeResolver::getNodeName() is entirely independent of any nodedef managers
16:44 est31 yes
16:44 hmmmm if a nodedef manager is associated with this noderesolver, then the nodedef manager's own internal name for 'unknown' would take precedence
16:45 est31 why?
16:45 hmmmm so you have CNodeDefManager's CONTENT_UNKNOWN name that's "unknown", and then maybe in the future we have CoolNodeDefManager
16:45 hmmmm and in CoolNodeDefManager, they want to be really cool, so CONTENT_UNKNOWN's name is "I dunno what this is lol"
16:45 est31 yes
16:46 hmmmm depending on which nodedef manager had been associated with this noderesolver object, it could and should differ
16:46 est31 but what you did was hardcode it to "unknown"
16:46 hmmmm it just so happens, by cosmic coincidence, that the default name given to an unknown node if there is no nodedef manager happens to be the same as the unknown node name in the only currently existing nodedef manager
16:47 est31 ah now I get it
16:47 est31 ok then
16:47 hmmmm so if you change CNodeDefManager's content unknown node name, then by all means, it should NOT change the NodeResolver's internal version
16:47 est31 yes
16:47 hmmmm because that's just an internal detail of CNodeDefManager that we cannot be concerned about
16:48 hmmmm it's completely internal to CNodeDefManager, private to NodeResolver
16:48 est31 but isn't that dependent on what m_ndef currently is?
16:48 hmmmm m_ndef gets set when calling INodeDefManager::pendNodeResolve()
16:49 hmmmm so if you want it set to some alternative INodeDefManager, call it using a different nodedef manager object
16:49 est31 yes
16:49 hmmmm got it????
16:50 est31 just how is the call m_ndef->get(CONTENT_UNKNOWN).name; dependent on CNodeDefManager ?
16:50 est31 I see that hardcoding "unknown" is at least as good, I just can't see how its strictly better
16:51 hmmmm oh, you're saying I should use "m_ndef->get(CONTENT_UNKNOWN).name" over "return unknown_str"
16:51 hmmmm I would agree, but recall that m_ndef can be NULL at any time that's called
16:51 hmmmm if it's NULL, it's strictly better because this won't crash
16:52 est31 yes lol
16:53 est31 see my comment , otherwise it looks good
16:54 hmmmm yeah I didn't bother updating the license years
16:54 hmmmm we'll do it all at once sometime
17:00 TheWild joined #minetest-dev
17:02 hmmmm PSA to everybody:  PLEASE STOP CHANGING YOUR POINTER ASTERISK STYLE MID-FUNCTION
17:02 hmmmm it is so fucking infuirating to see:  Foobar* foo = (Foobar *)new Foobar();
17:03 hmmmm I'm not even asking you to follow the official code style, I'm asking you to follow your own code style without changing it every 5 seconds
17:16 Zeno` PSA?
17:16 hmmmm public service announcement
17:16 Zeno` never heard that one. I shall write it donw
17:16 Zeno` down*
17:19 MinetestForFun joined #minetest-dev
17:20 MinetestForFun joined #minetest-dev
17:21 Zeno` lol
17:21 Zeno` I just realised that minetest takes longer to start up than my OS O.o
17:22 cib0 joined #minetest-dev
17:26 Megaf_ est31: Hi there
17:36 err404 joined #minetest-dev
17:46 Krock joined #minetest-dev
18:31 hmmmm https://github.com/kwolekr/minetest/commit​/f6ca3e9b479f4d913360a86bbdcdd793e64e93e6
18:34 Fritigern joined #minetest-dev
18:45 kaeza joined #minetest-dev
19:10 est31 joined #minetest-dev
19:18 crazyR_ joined #minetest-dev
19:18 crazyR_ joined #minetest-dev
19:53 ElectronLibre joined #minetest-dev
19:58 Hijiri joined #minetest-dev
20:10 hmmmm nobody?
20:10 hmmmm :/
20:13 hmmmm hmmm, the addition of NodeResolver to NodeDefManager inadvertantly broke the abstraction that INodeDefManager is read-only, and to write, you need an IWritableNodeDefManager
20:13 hmmmm in practice this doesn't cause any problems whatsoever
20:14 hmmmm but when writing unit tests it becomes apparent when you need to recycle state but the fundamental way NodeResolver works is by maintaining state elsewhere
20:14 paramat joined #minetest-dev
20:14 paramat useful feature hmmmmm
20:14 hmmmm the technically correct thing to do here is to expose NodeResolver related methods like pendNodeResolve to IWritableNodeDefManager only
20:15 hmmmm but it's not practical because you have an IWritableNodeDefManager almost nowhere
20:15 hmmmm thanks paramat
20:16 hmmmm so I'm wondering, what is the best way to design the NodeResolver pieces inside of INodeDefManager such that the state can be easily reset
20:17 hmmmm ndef->resetNodeResolverState() would be obvious, but has the potential to be error prone if the implementation is somehow wrong
20:19 hmmmm paramat:  is that a "looks good to me" approval? :)
20:20 leat3 joined #minetest-dev
20:20 paramat i'm not much qualified to judge the implementation but the feature seems useful
20:22 Wayward_Tab joined #minetest-dev
20:30 leat3 joined #minetest-dev
20:34 paramat hmmmm is there something about serializing a lua table schematic to .mts that changes an "ignore" node? i use "ignore" in force-placed schematics to select the nodes i don't want force-placed, but now testing a serialized schematic those selected nodes are now being force-placed as air
20:35 hmmmm come to think of it, yes, it does do that
20:35 paramat perhaps i should be using air with prob = 0 instead
20:35 hmmmm well it should be placing air with prob = 0
20:35 hmmmm having ignore as a special 'don't place anything here' node was deprecated in the second version iirc
20:36 hmmmm if you have ignore nodes in your schematic definitions, that means you're still using .mts v1 files
20:36 paramat aha
20:36 paramat so now "air" with prob = 0 is the thing to use?
20:36 hmmmm correct
20:36 paramat cool thanks
20:37 ElectronLibre left #minetest-dev
20:38 paramat on this subject, what's your method for maing sure tree trunks are force-placed but leaves are not, to stop chopped trunks when trees overlap? i might be able to code this myself
20:39 hmmmm i don't have one
20:39 paramat (making)
20:39 hmmmm that's next on my list of things to implement
20:40 paramat my idea was to use certain values of param1 (like 255) to enable per-node force placement, but apparently this is not good practice
20:41 Amaz joined #minetest-dev
20:41 hmmmm that's not doable because couldn't people want a node with a random chance of appearing to be force placed?
20:42 paramat maybe
20:42 paramat yeah
20:42 hmmmm unless that assumption is, in fact, wrong
20:43 paramat perhaps 0-127 prob not force placed, 128-255 prob force placed
20:43 hmmmm yep
20:43 paramat since we don't need many levels of probability, extra information can be encoded within param1
20:43 hmmmm so the top bit will be the force placement flag
20:44 hmmmm and probability will be truncated to 7 bit instead
20:46 paramat perhaps keep the current force placement flag also as a way to easily override for a whole schematic
20:47 hmmmm that's how it would have to be implemented, yeah.
20:48 pozzoni joined #minetest-dev
20:55 hmmmm https://github.com/kwolekr/minetest/commit​/633af58a05fb9b3ad7a0a178011f4243e5f8be2e
20:55 hmmmm review requested^
20:55 hmmmm PTAL
21:01 Hijiri joined #minetest-dev
21:03 proller joined #minetest-dev
21:07 MinetestForFun joined #minetest-dev
21:16 AnotherBrick joined #minetest-dev
21:19 crazyR_ joined #minetest-dev
21:19 crazyR_ joined #minetest-dev
21:20 Robert_Zenz joined #minetest-dev
21:55 Hijiri joined #minetest-dev
22:25 Wayward_Tab joined #minetest-dev
22:35 paramat left #minetest-dev
23:19 misprint joined #minetest-dev
23:21 Hijiri joined #minetest-dev
23:26 Wayward_Tab joined #minetest-dev
23:51 misprint joined #minetest-dev

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