| Time |
Nick |
Message |
| 00:31 |
|
rsiska joined #minetest-dev |
| 00:32 |
sapier |
https://github.com/minetest/minetest/pull/1136 should fix the not working non exceptioning functions, as I had to change each of them I renamed them too |
| 00:33 |
sapier |
but it may need some testing as I'm not sure if checking for numeric conversion errors wont cause some bugs to show up |
| 01:17 |
|
robmyers joined #minetest-dev |
| 01:22 |
|
pitriss joined #minetest-dev |
| 01:25 |
|
EvergreenTree joined #minetest-dev |
| 01:31 |
|
EvergreenTree joined #minetest-dev |
| 01:36 |
|
werwerwer joined #minetest-dev |
| 01:53 |
|
werwerwer_ joined #minetest-dev |
| 01:57 |
|
paramat joined #minetest-dev |
| 02:02 |
|
werwerwer joined #minetest-dev |
| 02:12 |
|
werwerwer_ joined #minetest-dev |
| 02:48 |
hmmmm |
wait, what does that actually do? |
| 02:49 |
hmmmm |
i was intending on fixing it by not having Setting::get throw an exception, but rather the exceptioned versions on top of the non-except |
| 02:51 |
hmmmm |
i can see that you fix the case where 0 is a valid return, except in that situatiton it doesn't realllly matter since 0 is never a valid port |
| 03:06 |
hmmmm |
ohhhhh shiiiiitt |
| 03:06 |
hmmmm |
my no exception things do work fine, i did not realize that i left them blank like that |
| 03:07 |
VanessaE |
[02-04 18:14] * VanessaE waits for the "oh shit...I did THAT?" moment....... |
| 03:07 |
VanessaE |
VINDICATED! :D |
| 03:08 |
hmmmm |
alright |
| 03:08 |
hmmmm |
i can't use the NoEx variants there, i do need to explicitly check against empty |
| 03:08 |
VanessaE |
only kidding, hmmmm :) |
| 03:09 |
hmmmm |
my original intent was that empty but present means, "let the emergemanager decide what the limit should be" |
| 03:09 |
hmmmm |
but non-present means use the defaults |
| 03:09 |
hmmmm |
and present means use what is given |
| 03:20 |
|
Miner_48er joined #minetest-dev |
| 03:21 |
hmmmm |
sapier, do you have any pieces of code in mind that call emergeBlock() and would benefit from an asynchronous callback when the block actually finishes getting loaded? |
| 03:21 |
hmmmm |
i know the stuff you were working on with the duplicate objects is one thing but anything else? |
| 03:40 |
VanessaE |
current HEAD seems to work fine now |
| 03:43 |
VanessaE |
staging it for the servers, for the morning restart. may as well give it a wider test. |
| 04:01 |
ShadowNinja |
hmmmm: It looks like you forgot to close the PR. |
| 04:16 |
* VanessaE |
wanders off to bed |
| 04:18 |
hmmmm |
ShadowNinja, why don't you do that instead of telling me about it? |
| 04:18 |
hmmmm |
it takes a text select, copy, paste, and then click another button |
| 04:22 |
ShadowNinja |
hmmmm: Because you pushed it. :-) |
| 04:22 |
hmmmm |
so? |
| 04:22 |
hmmmm |
there's no unwritten rule for that |
| 04:22 |
ShadowNinja |
I'll do that next time if you prefer. |
| 04:23 |
|
sfan5 joined #minetest-dev |
| 04:24 |
hmmmm |
somebody who sees some minor chore like that left undone, it's much more productive to just do it yourself rather than not doing it but expending the energy to verbally tell the person you feel is in charge of that chore to do their chore |
| 04:25 |
|
werwerwer joined #minetest-dev |
| 04:51 |
hmmmm |
I really wonder if adding a new exception that wasn't there before to Settings was a wise thing to do now |
| 04:52 |
hmmmm |
this kind of thing is the reason why I aimed to not change the what Settings does in the first place, because it's simply too widely used. well, not only that, now sapier has changed the behavior of a primitive integer conversion function |
| 04:56 |
|
werwerwer joined #minetest-dev |
| 05:03 |
hmmmm |
sapier, problem: any time there's an invalid character encountered in one of the plain Settings::get*-with-numeric-conversions, that's going to cause a NumericException that nobody handles except for what you made it handle this far |
| 05:04 |
hmmmm |
although the idea of making errors explicit rather than hidden is a noble one, it's just not working out in practice here |
| 05:05 |
hmmmm |
for now at least I say we revert 3f376a0 and i'll just fix up the two problematic settings in EmergeManager ctor |
| 05:11 |
|
werwerwer joined #minetest-dev |
| 05:59 |
|
grrk-bzzt joined #minetest-dev |
| 06:32 |
|
darkrose joined #minetest-dev |
| 06:32 |
|
darkrose joined #minetest-dev |
| 08:39 |
|
werwerwer joined #minetest-dev |
| 09:11 |
|
Megaf joined #minetest-dev |
| 09:58 |
|
rsiska joined #minetest-dev |
| 10:16 |
|
specing joined #minetest-dev |
| 11:05 |
|
ImQ009 joined #minetest-dev |
| 11:22 |
|
xyz joined #minetest-dev |
| 11:39 |
xyz |
do we really need EMT_TRANSPARENT_ALPHA_CHANNEL_REF as the MaterialType for TILE_MATERIAL_BASIC? is there anything that makes use of it? |
| 11:58 |
|
NakedFury joined #minetest-dev |
| 12:14 |
|
xyz joined #minetest-dev |
| 12:20 |
|
xyz joined #minetest-dev |
| 12:41 |
|
iqualfragile joined #minetest-dev |
| 13:24 |
|
werwerwer joined #minetest-dev |
| 13:27 |
|
hmmmm joined #minetest-dev |
| 13:36 |
|
whirm joined #minetest-dev |
| 13:54 |
|
werwerwer joined #minetest-dev |
| 13:55 |
|
SpeedProg joined #minetest-dev |
| 14:14 |
RealBadAngel |
hi hmmmm |
| 14:49 |
|
Yepoleb joined #minetest-dev |
| 15:14 |
VanessaE |
ok something BAD happened last night after the restart - LOTS of C++ exceptions now |
| 15:15 |
VanessaE |
oh, new I see new changes. guess I better pull those |
| 15:17 |
VanessaE |
and...deployed. |
| 15:19 |
|
OldCoder joined #minetest-dev |
| 15:22 |
|
zat joined #minetest-dev |
| 15:31 |
Megaf |
when 0.4.10 is out, I will stick with it, in the stable branch |
| 15:46 |
VanessaE |
ShadowNinja: are you going to push those fixes we talked about? |
| 15:48 |
|
werwerwer_ joined #minetest-dev |
| 15:53 |
|
Jordach joined #minetest-dev |
| 15:53 |
RealBadAngel |
0.4.10?? why not 0.5? |
| 15:55 |
Kray |
why it would be 0.5? |
| 15:55 |
Kray |
does it introduce breaking changes? |
| 15:56 |
VanessaE |
version numbers are not decimal :) |
| 15:59 |
RealBadAngel |
shit, this way we will wont leave 0.4.x stage this century :P |
| 16:04 |
NakedFury |
I thought shaders alone would push it to 0.5.x numbered version |
| 16:04 |
NakedFury |
or at least push it to 4.5.0 |
| 16:07 |
RealBadAngel |
lol |
| 16:08 |
VanessaE |
I thought 0.5.x is supposed to be for some major change that totally breaks compatibility with 0.4.x |
| 16:14 |
|
Megaf_ joined #minetest-dev |
| 16:14 |
RealBadAngel |
keeping things compatible breaks more things than keeping them working |
| 16:15 |
RealBadAngel |
there are lotsa examples on that |
| 16:16 |
RealBadAngel |
major change and a reason to change version big time imho is change of net protocol |
| 16:17 |
RealBadAngel |
not some fancy schmancy eye candies |
| 16:22 |
|
OldCoder joined #minetest-dev |
| 16:54 |
|
ImQ009 joined #minetest-dev |
| 17:02 |
|
Calinou joined #minetest-dev |
| 17:13 |
|
sapier joined #minetest-dev |
| 17:17 |
|
rubenwardy joined #minetest-dev |
| 17:17 |
sapier |
well I know the NumericException is quite invasive that's why I didn't push it without discussion. Basicaly it's about deciding what to do if you can't convert something. The current behaviour is just hide it and use 0 ... you don't have any way to decide if 0 is the converted value or a error return |
| 17:18 |
sapier |
this is not only about settings |
| 17:23 |
sapier |
another point to discuss is settings.h ... this file has gotten way to big and contains too much code for a header file, imho we should add a settings.cpp |
| 17:23 |
|
PilzAdam joined #minetest-dev |
| 17:25 |
sapier |
https://github.com/minetest/minetest/pull/1135 any complains about this one? |
| 17:26 |
sapier |
https://github.com/minetest/minetest/pull/1131 ShadowNinja I'm gonna merge this today I added your last suggestions |
| 17:28 |
ShadowNinja |
sapier: Alright, the only thing I noticed was that the 0.0.0.0/:: checks were still there. Other than that it's good. |
| 17:29 |
ShadowNinja |
And 1135 seems good too, although I haven't looked at it very closely. |
| 17:30 |
sapier |
are there still 0.0.0.0 checks in there? thought I removed them with latest commit |
| 17:30 |
sapier |
oh I missed a location |
| 17:33 |
sapier |
the only functional change in 1135 is removal of a "external" debug function in client class ... debug function accessible from outside ... if someone really needs this information he/she 's supposed to use a debugger. |
| 17:33 |
sapier |
especially as that information is very very very specific for a single debug case |
| 17:35 |
sapier |
ok now all 0.0.0.0 locations should be gone |
| 17:35 |
xyz |
sapier: apparently marshal causes sigbus on android sometimes when unmarshalling a function |
| 17:36 |
sapier |
sigbus? |
| 17:36 |
|
EvergreenTree joined #minetest-dev |
| 17:36 |
|
EvergreenTree joined #minetest-dev |
| 17:36 |
sapier |
First guess is stack overflow |
| 17:36 |
sapier |
increase stack size |
| 17:37 |
sapier |
not as fix but as check if this is true |
| 17:37 |
sapier |
marshaling as any other serialization may do quite some recursion so it's prone to issues like that one |
| 17:38 |
sapier |
I wonder if it's be worth a to check this for emptty's debian jit problem too |
| 17:39 |
xyz |
it's still not resolved? |
| 17:40 |
sapier |
no I still can't reproduce and the error trace wasn't helpfull |
| 17:40 |
xyz |
maybe we can work around it? |
| 17:40 |
xyz |
like pass function name as a string, not serialized body |
| 17:41 |
sapier |
that's how it's done |
| 17:41 |
sapier |
the serialized data isn't jitted code |
| 17:42 |
sapier |
it's plain text and will be "rejitted" on async thread |
| 17:42 |
sapier |
emptty did some tests, in crash situation serialized data is still correct |
| 17:43 |
sapier |
as it doesn't happen always it may be a race condition or a random memory corruption too |
| 17:44 |
sapier |
but in case of a memory corruption I'd expect to be the reason somewhere around async/marshall too, it's quite unlikely to always cause problems there for something completely different |
| 17:47 |
sapier |
btw there are way to many "workarounds" within minetest just because everyone is to lazy to find the source of a problem. Imho we should remove them not add new ones |
| 17:49 |
sapier |
does anyone have a system with gcc and clang and knows how to tell cmake to use clang/gcc? |
| 17:53 |
xyz |
so it's plain text |
| 17:53 |
xyz |
and a race condition |
| 17:54 |
xyz |
which happens always |
| 17:55 |
sapier |
depends emtty told about 3 of 4 times |
| 17:55 |
sapier |
so quite often |
| 17:56 |
sapier |
but by now there's no obvious reason ... could be something completely different too |
| 17:56 |
xyz |
did you test it with luajit beta7? |
| 17:57 |
sapier |
not yet I used beta9 by now but if there was a problem in 7 that got fixed I don't see a reason why to look there |
| 17:57 |
sapier |
emtty has 2.0.2 |
| 17:58 |
sapier |
beta9 is latest available for wheezy |
| 17:59 |
xyz |
well have fun debugging it |
| 18:00 |
sapier |
well prior debugging I need to be able to reproduce it |
| 18:01 |
xyz |
yes just install luajit beta7 then |
| 18:03 |
sapier |
there ain't a debian package for beta7 and I won't mess up my disti without a real reason. I remember you told the beta7 bug was already fixed so why should it be back in 2.0.2 |
| 18:03 |
sapier |
? |
| 18:06 |
xyz |
because we don't know if that's a bug |
| 18:06 |
xyz |
why do you assume it is? |
| 18:06 |
xyz |
moreover, I've never told you the bug was fixed |
| 18:06 |
xyz |
stop imagining things |
| 18:11 |
RealBadAngel |
sapier, 1135 looks fine, bout 1131 i dont know the problem so i cant say anythin |
| 18:12 |
|
salamanderrake joined #minetest-dev |
| 18:14 |
sapier |
ok xyz sorry I missinterpreted "it works with 2.0.2" as "it was fixed in 2.0.2" |
| 18:16 |
xyz |
yes yes you did |
| 18:16 |
sapier |
I tend to not believe this is really related to luajit version ... and the message you liked last time tells the error checking is cleaned up ... I interpret "not working function serialization" as not working c-function serialization ... which is quite obvious true ... and not required at all |
| 18:16 |
sapier |
linked not liked |
| 18:18 |
xyz |
if it's about c functions then why'd he talk about luajit |
| 18:18 |
sapier |
because you can use c functions in lua code which obviously won't be serialized |
| 18:19 |
sapier |
at least that's what I understood |
| 18:20 |
sapier |
http://lua-users.org/wiki/TableSerialization I used marshalling because it is capable of serializing functions |
| 18:26 |
sapier |
ok now on luajit beta7 still no crash for me |
| 18:27 |
xyz |
strange |
| 18:27 |
xyz |
try running marshal tests |
| 18:27 |
xyz |
provided in its git repo |
| 18:33 |
sapier |
I'm switching back to beta9 to do so as compiling against something out of tree isn't quite user friendly |
| 18:33 |
|
whirm joined #minetest-dev |
| 18:39 |
sapier |
works |
| 18:40 |
sapier |
there has to be some other reason |
| 18:42 |
xyz |
so did you check marshal tests? |
| 18:42 |
xyz |
with luajit beta7 |
| 18:44 |
|
Calinou joined #minetest-dev |
| 18:44 |
sapier |
well I can't compile against beta7 I used beta9 |
| 18:45 |
sapier |
not sure if a marshall lib compiled against beta9 is supposed to work against beta7 library ... but it doesn't work |
| 18:45 |
sapier |
https://gist.github.com/sapier/8830371 |
| 18:47 |
xyz |
it compiled fine for me and it didn't work in the same way |
| 18:48 |
sapier |
ok so we're right where we've been befor luajit beta7 is broken and shouldn't be used |
| 18:50 |
|
Zeitgeist_ joined #minetest-dev |
| 18:57 |
sapier |
https://gist.github.com/sapier/8830371 UPDATED as you can see it's broken till beta7 and fixed as of beta8 |
| 19:06 |
|
khonkhortisan joined #minetest-dev |
| 19:47 |
|
rubenwardy_ joined #minetest-dev |
| 19:57 |
Megaf_ |
sapier: Hi, any update on 1132/1134? |
| 19:58 |
sapier |
1134 should be fixed 1132 still isn't decided |
| 20:02 |
|
VanessaE joined #minetest-dev |
| 20:04 |
|
Miner_48er joined #minetest-dev |
| 20:05 |
ShadowNinja |
The protocol bump seems to be the selected option. |
| 20:06 |
sapier |
at least it seems to be prefered version by now PilzAdam is for it I'm for it too ... I assume you're same opinion ShadowNinja? |
| 20:06 |
sapier |
-versio+variant |
| 20:10 |
sapier |
but right now I'm more concerned about the (possible) luajit<->marshalling issues |
| 20:16 |
ShadowNinja |
sapier: Yes, the proto bump seems best. |
| 20:22 |
sapier |
https://github.com/minetest/minetest/pull/1131 merging in about 15 minutes |
| 20:33 |
VanessaE |
ShadowNinja: um...how do I add another user to the core? |
| 20:34 |
VanessaE |
oops |
| 20:34 |
VanessaE |
wrong channel. |
| 20:40 |
|
Exio4 joined #minetest-dev |
| 21:06 |
|
sapier joined #minetest-dev |
| 21:18 |
|
salamanderrake joined #minetest-dev |
| 21:33 |
xyz |
everybody keeps ignoring me so I'll just spam this again, do we really need EMT_TRANSPARENT_ALPHA_CHANNEL_REF as the MaterialType for TILE_MATERIAL_BASIC? is there anything that makes use of it? |
| 21:35 |
sapier |
I assume RealBadAngel is the only one who even knows what this is about ;-) |
| 21:36 |
sapier |
is it faster without EMT_TRANSPARENT_ALPHA_CHANNEL_REF ? whatever this is |
| 21:37 |
xyz |
it's buggy on android/ogles |
| 21:37 |
xyz |
the one without ref works fine but probably is slower and also requires z sorting enabled |
| 21:37 |
xyz |
dunno if there's actually any noticeable difference |
| 21:38 |
sapier |
we should find out first, if it's just a minor penalty and no visible changes it's not a big thing to disable, but if it isn't I suggest do an architecture specific change only |
| 21:56 |
khonkhortisan |
I want to add a source file. What do I edit to compile it in? |
| 21:57 |
ShadowNinja |
khonkhortisan: src/CMakeLists.txt |
| 21:57 |
khonkhortisan |
thanks |
| 22:00 |
|
salamanderrake joined #minetest-dev |
| 22:24 |
CiaranG |
So (lua api), player:get_look_yaw() returns a value that is 90 degrees offset from the one you should pass to player:get_look_yaw() |
| 22:24 |
CiaranG |
Is there some kind of reason for that, or is it just a bug? |
| 22:25 |
CiaranG |
er, set_look_yaw, I mean, for the second one |
| 22:26 |
sapier |
some people seem to assume this is correct behaviour (it's wrong for all entities). but breaking all mods out there isn't an option so we have to live with it |
| 22:26 |
CiaranG |
Documenting it might be an idea then, if it's staying like that |
| 22:27 |
CiaranG |
Would have saved me an hour of insanity ; |
| 22:28 |
sapier |
:-) you're free to document it and write a pull request. please one pull for one feature |
| 22:28 |
|
Daimanu joined #minetest-dev |
| 22:28 |
CiaranG |
Yeah, sorry about that, it did only have one commit in it when I made the pull request |
| 22:29 |
sapier |
no problem |
| 22:29 |
CiaranG |
The 'remap mouse buttons/view direction keys' thing wasn't supposed to be pull-requested at all yet |
| 22:29 |
CiaranG |
It works great, but there's an issue. You can't ever remap the mouse buttons back to the actual mouse buttons, because the gui is capturing them when it's asking you to press the new key to define |
| 22:30 |
sapier |
well adding that one with it's upper commit message would have caused quite a lot of confusion ;-) |
| 22:30 |
CiaranG |
Probably I can just turn off the capturing during the 'press the new key' but I haven't bothered to try it yet |
| 22:33 |
ShadowNinja |
I think the offset can be fixed, looking 90 degrees off might mean you're facing the wrong way for a teleporter or something, but it isn't game-breaking. |
| 22:34 |
CiaranG |
It really ought to be fixed, it makes no sense at all. But it could be fixed in a non-breaking way if it really mattered by adding new functions and leaving the old ones deprecated as they are. |
| 22:34 |
CiaranG |
get_look_yaw_sane() |
| 22:37 |
CiaranG |
On another subject, if I created a pull request that allowed lua entities to set themselves 'active' (which means the blocks they are in stay active, as if they were a player) would that be accepted? |
| 22:37 |
ShadowNinja |
Hehe. |
| 22:37 |
ShadowNinja |
CiaranG: Nope, already done, called force_load. |
| 22:37 |
CiaranG |
Really? |
| 22:37 |
ShadowNinja |
And you can use minetest.forceload_block |
| 22:38 |
CiaranG |
Huh, so I've done it again for nothing. I guess that will teach me to read the code more. |
| 22:38 |
ShadowNinja |
The PR was made, but only the forceload_block method was accepted. |
| 22:38 |
sapier |
BUT you're strongly discourage that feature |
| 22:39 |
CiaranG |
Oh, ok, so I haven't done it for nothing :) |
| 22:40 |
sapier |
there's very little you actually need this feature and don't have another chance to do it. In most situations you're just gonna use it because of beeing lazy ;-) |
| 22:40 |
|
ShadowBot joined #minetest-dev |
| 22:50 |
CiaranG |
So I have lots of uses for it (which are not being lazy), but I'll keep it to my own server |
| 22:55 |
sapier |
well you should think about each entity causing map block load will increase server load as much as an additional server. Case this entity is moving and running havoc you'll never find it again if its somewhere far far away |
| 22:56 |
sapier |
-additional server + additional player |
| 22:56 |
CiaranG |
Yep, fully aware of that |
| 22:57 |
sapier |
hope you really know what you're doing cause this will not show up immediatly |
| 22:57 |
CiaranG |
I really know what I'm doing |
| 22:58 |
sapier |
may I ask what you need it for? |
| 22:58 |
CiaranG |
Sure... |
| 22:59 |
CiaranG |
Two current examples. 1. a mob that can be sent to another player, 2. a cart (i.e. on rails) that goes where it's supposed to go, and also comes back, without you riding in it |
| 23:00 |
CiaranG |
The latter is transporting stuff, i.e. collecting it and bringing it back |
| 23:00 |
sapier |
well true ... but both are the most critical situations too |
| 23:01 |
CiaranG |
Well the first could cause the problems you're talking about, if it goes wrong |
| 23:01 |
CiaranG |
The cart can't leave the rails though, so it's less of an issue |
| 23:02 |
sapier |
it's an entity so it can move everywhere ;-) |
| 23:02 |
CiaranG |
It definitely can't |
| 23:02 |
CiaranG |
It's an entity that can only move where there are rails |
| 23:02 |
sapier |
I'm not talking about if it's supposed to do to this |
| 23:03 |
sapier |
:-) how do you intend to mak the mob walk from player to player? |
| 23:04 |
sapier |
pathfinding wont work for large (3 digit) node distances |
| 23:06 |
CiaranG |
I'm not using any kind of pathfinding currently, it's following pre-determined routes |
| 23:06 |
CiaranG |
(which are laid out as paths on the ground) |
| 23:06 |
sapier |
hmm you know mobf already supports this? |
| 23:07 |
CiaranG |
I saw it has some pathfinding stuff yeah. I don't know if it's what I want though |
| 23:07 |
sapier |
no I'm not talking about pathinding |
| 23:07 |
CiaranG |
Oh, sorry, what then? |
| 23:24 |
|
EvergreenTree joined #minetest-dev |
| 23:25 |
|
EvergreenTree joined #minetest-dev |
| 23:25 |
|
rsiska joined #minetest-dev |
| 23:44 |
|
sapier left #minetest-dev |
| 23:49 |
Robby |
nice addition that bind_address option |
| 23:49 |
Robby |
can it also take a , separated list? |
| 23:49 |
Robby |
I want to for example bind it on one IPv4 and one IPv6 address |
| 23:51 |
Robby |
oh, nvm, I forgot about enable_ipv6 :) |
| 23:59 |
|
zat joined #minetest-dev |
