Time Nick Message 18:05 doserj I wonder how many bugs like this are still buried in the code :) https://github.com/celeron55/minetest/pull/417 18:16 darkrose thought I fixed that a while ago, either it got reverted somewhere or I missed something 18:21 doserj there are two places where this has to be done: environment::step() and environment::activateBlock() 18:21 doserj it was only missing in activateBlock() 18:50 doserj I just checked: your fix from 2012-08-10 only fixes in environment::step() 18:57 darkrose sounds about right, when I wrote the original code I only tested it in the 0,0,0 block... so completely missed the positioning bug 19:07 darkrose merged it, if anyone complains they can bite me 19:09 doserj :) 19:15 VanessaE lol 19:15 VanessaE darkrose: surely you mean "byte me" :-) 19:16 darkrose :p 19:22 celeron55 hmm 19:22 * celeron55 looks up furnace implementation 19:23 PilzAdam https://github.com/PilzAdam/minetest_game/commit/9ebbbd7362486f1f60014adb037143fa8c4c3d37 19:26 celeron55 chances are that there are some nodes in the 0,0,0 block that launch the furnace menu when right clicked, if you have used a world for a long time to cause a situation where while a block is loaded that contains an active furnace the 0,0,0 block is already in memory 19:26 darkrose furnaces use abm's, not node timers 19:26 celeron55 i think that is quite a rare event, as people are unlikely to close the world when a furnace is active 19:26 darkrose unless that's been changed recently 19:26 celeron55 ...oh, they still do that 19:27 celeron55 didn't realize 89 19:27 celeron55 8)* 19:27 celeron55 that means nothing in default uses them so generally nothing odd couldn't have happened 19:27 celeron55 could* 19:27 darkrose indeed 19:37 doserj btw, celeron55: any comments about https://github.com/celeron55/minetest/pull/416 ? 19:38 celeron55 not now, except that i hope people will find time to test it 19:38 celeron55 i'm planning on being lazy 19:40 doserj you heard him, people. Test it! 19:42 doserj I am also interested in any suggestions for UI improvements 19:43 PilzAdam doserj, you already know what I think about it 19:45 doserj yep. and I am ok with fixing that. 19:46 PilzAdam the rest seems to be ok 20:36 sapier hello is math.h allowed in minetest? 20:48 hmmmm yes... 20:51 celeron55 grep is allowed too: 20:51 sapier good I've created a patch adding support for entities automatic rotating into movement direction ... of course configurable by entity parameter 20:51 celeron55 [celeron55@betel src]$ grep ' 20:52 celeron55 util/mathconstants.h:1:#include 20:52 sapier didn't think about using grep ... sorry 20:54 celeron55 anyway; the official requirements for what can be used without extra askings is such that it will compiled with the current libraries (irrlicht being 1.7 + 1.8) on debian stable gcc, latest stable mingw, msvc2010 and latest clang 20:54 celeron55 s/compiled/compile/ 20:55 celeron55 hmm, that should go in the reworked dev wiki at some point 20:56 celeron55 oh, and irrlicht 1.7 will be supported until debian stable upgrades to 1.8 20:56 sapier just noone will check all of those environments prior commiting :-/ 20:57 celeron55 yes, it's impossible; but good guesses are ok, and one needs to be ready to make fixes for those when a problem arises 20:58 celeron55 those are quite finite though, and supporting those is standard practice 20:59 sapier of course beeing ready to fix problems discovered after merge is mandatory ... hmm hope mandatory is right english word 21:01 celeron55 not always - it kind of depends on who initiated the merge 21:01 celeron55 if a contributor wants that something he made is merged, then it's more of the contributor's responsibility 21:02 sapier thats what I meant, the one initiating the merge is responsible for doing fixes she/he missed on first try 21:02 celeron55 if an upstream dev merges someting from somewhere that he sees is good but the contributor has just left the code there, then it's the upstream dev's responsibility 21:03 sapier https://github.com/celeron55/minetest/pull/418 21:04 sapier it's a small change but I'm quite sure it'll break protocol ... again 21:05 sapier not protocol .. protocol compatibility 21:05 celeron55 you forgot proper initialization of automatic_face_movement_dir in constructor 21:05 sapier oops 21:06 thexyz >fabs(m_prop.automatic_face_movement_dir), what does that mean? 21:06 celeron55 lol 21:06 celeron55 that sure is interesting 21:06 thexyz fabs(bool) 21:07 celeron55 other than that, it's probably good; i don't think it's worth a protocol version increment 21:08 celeron55 mobs relying on it will just walk backwards, not a huge deal 8) 21:08 sapier I don't know what fabs mean but any other bool parameter is checked this way 21:08 thexyz wat 21:09 thexyz I'm pretty sure you're wrong 21:10 thexyz any examples of such code? 21:11 sapier hmm ok the other parameter is float .. 21:11 thexyz fabs returns absolute value 21:11 thexyz fabs(x) == |x| 21:11 sapier hmm not quite wrong ... but useless 21:12 thexyz how should it work for bools? 21:12 sapier as a bool is simply 0 or 1 I'd expect it to do nothing at all 21:13 sapier float absolute ... now I understand whats ... 21:13 sapier ok as it's no float this wrong 21:17 sapier ok I've fixed it 21:18 sapier ahh ... forgot to change lua_api.txt ... one moment 21:20 sapier now its complete 21:22 sapier what do you think about this patch? https://github.com/celeron55/minetest/pull/411 21:25 thexyz why do you use dynamic_cast? 21:27 sapier I try to avoid c style casts where ever possible for security reasons .. but I haven't checked if minetest uses this convention too 21:28 sapier so I assume minetest uses c-style casting only ... I'll change 21:31 thexyz well, you cast Environment to ClientEnvironment or ServerEnvironment, and I don't think that dynamic_cast is needed in this particular case 21:31 thexyz as your Environment is always Environment 21:32 sapier no in this direction it's not sure 21:33 sapier I'm not sure if I can do a c-style cast at all 21:33 sapier ServerEnvironment* s_env = dynamic_cast(env); if I do this with a client env next line most likely will fail 21:34 doserj dynamic_cast is a c-style cast + a run-time check 21:35 sapier yes and that's required in this case 21:36 sapier if environment is a client environment pointer will be 0 and following code won't be run ... it can't be run with client environment 21:40 sapier I'm open to other suggestions ;-) 21:40 sema4 base class needs property to indicate environment type? 21:41 sapier an option but as it's a c++ class this is already in rtti 21:41 sapier we do have c++ so why not use its features? 21:41 thexyz better ask celeron55 then 21:42 sapier I hope he's reading 21:42 sema4 ok so if it is already there, can you not check prior to cast? 21:42 sapier another option would be move those functions to Environment 21:42 sapier atm there's no way to decide what type it is 21:43 sapier adding a envtype to Environment base class would be required 21:43 sema4 right which is what i suggested 21:43 doserj but the dynamic_casts to ActiveObject* are unnecessary, right? 21:43 sapier but still that's a workaround for avoiding use of c++ standard features 21:43 sapier in a programm which heavyly uses c++ 21:44 sema4 yeah, ok i see your point :) 21:44 sapier doserj yes they are 21:45 doserj https://github.com/sapier/minetest/commit/9135af8558770ce410e2cd38334873d294f0b398#L1R307 for example 21:46 sema4 i have not used c++ for over a decade. what about try/catch around the following code? 21:46 sapier try catch what? sigill? 21:47 sema4 whatever it throws. 21:47 sapier you'd be calling a function not being where you're looking for it ... i can't even guess what's called instead 21:47 * sema4 nods. i will go back to lurking now :> 21:48 sapier sigill isn't an exception its a trap :-) thus this will kill your application if you didn't specify a custom trap handler ;-) 22:20 doserj oh, and "f32 distance = speed_f.getLength();" is unused. 22:21 doserj did you mean to use that in getActiveObjects(pos_f,distance*BS,...)? 22:27 sapier ohhh ... yes I did 22:39 sapier I've changed that and removed dynamic_casts where possible ... still in my opinion dynamic_casts are the way to cast in a c++ application