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: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:08 ShadowNinja D-: https://github.com/minetest/minetest/commit/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: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 06:23 sfan5 hmmmm: do you want Minetest.exe or what? 06:30 hmmmm the resource file has selective editing 06:30 hmmmm some fields use PROJECT_NAME, a few others do not 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 15:17 Zeno` ShadowNinja, you missed one: https://github.com/minetest/minetest/blob/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: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 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 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: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:21 Zeno` lol 17:21 Zeno` I just realised that minetest takes longer to start up than my OS O.o 17:26 Megaf_ est31: Hi there 18:31 hmmmm https://github.com/kwolekr/minetest/commit/f6ca3e9b479f4d913360a86bbdcdd793e64e93e6 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 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 paramat i'm not much qualified to judge the implementation but the feature seems useful 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: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 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:55 hmmmm https://github.com/kwolekr/minetest/commit/633af58a05fb9b3ad7a0a178011f4243e5f8be2e 20:55 hmmmm review requested^ 20:55 hmmmm PTAL