| Time |
Nick |
Message |
| 15:55 |
|
loggingbot_ joined #minetest-dev |
| 15:55 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://minetest.net/wiki/doku.php?id=dev_index |
| 16:22 |
|
doserj joined #minetest-dev |
| 16:44 |
|
rubenwardy joined #minetest-dev |
| 17:04 |
|
Calinou joined #minetest-dev |
| 17:15 |
|
rubenwardy left #minetest-dev |
| 17:15 |
|
rubenwardy joined #minetest-dev |
| 17:30 |
|
hmmmm joined #minetest-dev |
| 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:32 |
|
jin_xi joined #minetest-dev |
| 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:04 |
|
rubenwardy left #minetest-dev |
| 20:18 |
|
jin_xi joined #minetest-dev |
| 20:36 |
|
sapier joined #minetest-dev |
| 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 '<math' * util/* -Isn |
| 20:52 |
celeron55 |
noise.cpp:20:#include <math.h> |
| 20:52 |
celeron55 |
util/mathconstants.h:1:#include <math.h> |
| 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:29 |
|
sema4 joined #minetest-dev |
| 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<ServerEnvironment*>(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:06 |
|
SpeedProg joined #minetest-dev |
| 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 |
| 22:39 |
|
Gambit joined #minetest-dev |
| 23:02 |
|
sfan5[iPod] joined #minetest-dev |
