| Time |
Nick |
Message |
| 00:14 |
|
Eater4 joined #minetest-dev |
| 00:15 |
cg72 |
ok how can i specify a certain texture dir for a server? i need 2 or more seperate ones as i have alot of servers on this machine |
| 00:18 |
Eater4 |
cg72: hmm? |
| 00:18 |
Eater4 |
And those are supposed to be asked on #minetest |
| 00:18 |
Eater4 |
I am Nate btw.. |
| 00:18 |
cg72 |
lol |
| 00:23 |
|
ImQ009 joined #minetest-dev |
| 00:26 |
|
m0dem joined #minetest-dev |
| 00:44 |
|
grrk-bzzt joined #minetest-dev |
| 02:15 |
|
sapier left #minetest-dev |
| 03:19 |
|
werwerwer_ joined #minetest-dev |
| 03:38 |
|
Miner_48er joined #minetest-dev |
| 04:01 |
|
kahrl joined #minetest-dev |
| 04:25 |
|
smoke_fumus joined #minetest-dev |
| 05:13 |
|
nore joined #minetest-dev |
| 05:18 |
|
OldCoder joined #minetest-dev |
| 05:35 |
|
kaeza joined #minetest-dev |
| 05:47 |
|
VanessaE joined #minetest-dev |
| 06:25 |
VanessaE |
seems some Lua crashes are still failing to reach the debug log |
| 06:25 |
VanessaE |
an example: http://pastebin.com/SAQtpBAY |
| 06:25 |
VanessaE |
(it's a mod bug in this case, obviouslt) |
| 06:25 |
VanessaE |
obviously*) |
| 06:26 |
VanessaE |
the error was only printed to stdout but not to debug.txt |
| 06:26 |
VanessaE |
(well maybe it went to stderr, idk. doesn't matter) |
| 06:49 |
|
Hunterz joined #minetest-dev |
| 06:51 |
nore |
after doing "Exit to menu": Minetest/src/script/cpp_api/s_base.cpp:74: ScriptApiBase::ScriptApiBase(): Assertion 'm_luastack' failed. |
| 06:52 |
nore |
(while playing on VE's survival server) |
| 06:54 |
hmmmm |
ahhhhhhh |
| 06:54 |
hmmmm |
sapier: when I mentioned about how I added a flag to voxelmanip, it wasn't a VOXELFLAG_, it was VMANIP_BLOCK_DATA_ |
| 06:54 |
hmmmm |
the VOXELFLAG stuff is celeron's original code |
| 06:55 |
hmmmm |
and yeah, the flag merging doesn't have any ill effect because it's simply not used in any unique situation. i suppose it used to do soemthing different at some point but not any longer. |
| 06:56 |
hmmmm |
https://github.com/sapier/minetest/commit/8bb87b57fbc4632103b03da36f606dc83d505f5e#diff-39ed02ccc671fe3b6931967be58c4ed6L248 this change, however, breaks things |
| 06:57 |
hmmmm |
see for yourself what happens with that modification and multiple emerge threads |
| 06:58 |
|
Calinou joined #minetest-dev |
| 07:16 |
Calinou |
Weblate is still down? :/ |
| 07:16 |
Calinou |
menu translations are quite broken now |
| 07:18 |
kaeza |
I guess it will need to be done the old way now :/ |
| 07:19 |
Calinou |
that sucks |
| 07:19 |
Calinou |
get a Transifex up |
| 07:20 |
|
LemonLake joined #minetest-dev |
| 07:26 |
|
proller joined #minetest-dev |
| 07:37 |
|
Ritchie joined #minetest-dev |
| 07:54 |
|
PenguinDad joined #minetest-dev |
| 08:27 |
|
asl_ joined #minetest-dev |
| 08:32 |
|
sapier joined #minetest-dev |
| 08:35 |
|
jin_xi joined #minetest-dev |
| 08:37 |
sapier |
hmmmm it's difficult to check something for an error that's known to be broken ;-) can you explain to me why you expect it to add another error? |
| 08:47 |
|
Eater4 joined #minetest-dev |
| 09:03 |
|
tomreyn joined #minetest-dev |
| 09:11 |
|
Garmine joined #minetest-dev |
| 09:14 |
|
Guest81462 joined #minetest-dev |
| 09:15 |
|
jp__ joined #minetest-dev |
| 09:16 |
|
jp__ left #minetest-dev |
| 09:26 |
|
CraigyDavi_ joined #minetest-dev |
| 09:58 |
|
restcoser joined #minetest-dev |
| 10:04 |
|
PilzAdam joined #minetest-dev |
| 10:13 |
|
RealBadAngel joined #minetest-dev |
| 10:17 |
|
diemartin joined #minetest-dev |
| 10:18 |
|
iqualfragile joined #minetest-dev |
| 10:28 |
|
ImQ009 joined #minetest-dev |
| 10:30 |
|
Jordach joined #minetest-dev |
| 10:43 |
|
Ritchie joined #minetest-dev |
| 11:03 |
sapier |
RealBadAngel: can you check this out? https://github.com/minetest/minetest/pull/1370 in case of issues they might occur on unified inventory and your machine ;-) |
| 11:15 |
RealBadAngel |
sure |
| 11:18 |
sapier |
I had to change tab headers, I did a bad mistake on implementing them initially ... basicaly pos wasn't usable at all in scaling environments |
| 11:21 |
|
CraigyDavi_ joined #minetest-dev |
| 11:22 |
celeron55_ |
i have a rather unrelated suggestion for the future |
| 11:22 |
celeron55_ |
see these http://nodejs.org/api/fs.html#fs_file_system http://nodejs.org/api/punycode.html#punycode_punycode http://nodejs.org/api/cluster.html#cluster_cluster |
| 11:22 |
celeron55_ |
node.js always marks in its documentation how stable each API is |
| 11:22 |
celeron55_ |
should we start doing the same? |
| 11:23 |
celeron55_ |
i think it currently is very unclear which things are in their first iteration and might still have bugs in their interface |
| 11:23 |
celeron55_ |
or does this matter in practice? |
| 11:24 |
sapier |
sounds interesting yes ... but considering the end of our supported features feature I don't really believe this will do more then add work |
| 11:25 |
celeron55_ |
maybe it's not appropriate for MT |
| 11:25 |
sapier |
and things like table header will still happen as I didn't even have scaling envs on schedule when implementing it fist |
| 11:26 |
sapier |
-table + tab |
| 11:26 |
celeron55_ |
there are certain interfaces that we are sure won't change incompatibly though, like set_node() |
| 11:26 |
celeron55_ |
but those might be quite obvious |
| 11:27 |
celeron55_ |
oh, whatever; just throwing this here so that people can think about it |
| 11:29 |
sfan5 |
<celeron55_> should we start doing the same? |
| 11:29 |
sfan5 |
yes |
| 11:30 |
sapier |
who do you expect to do the work sfan5? ;-) |
| 11:34 |
celeron55_ |
the work involved might be quite mechanical |
| 11:34 |
sapier |
I don't know about a algorithm to decide about stability and modify the docs ;-) |
| 11:35 |
celeron55_ |
like, some rules like: always mark a new thing as experimental, mark an experimental thing as unstable once it is released once, and mark it as stable once it has gone through a release or few without known bugs or problems |
| 11:35 |
RealBadAngel |
sapier, everything seems fine with #1370, imho youre good to go |
| 11:35 |
celeron55_ |
of course that is determinable by anyone even now by looking at the age of features and the content of the issue tracker |
| 11:36 |
sapier |
celeron55_: wouldn't this be same as defining a feature beeing in two/three/x stable versions as stable? |
| 11:37 |
celeron55_ |
yes, except not if a developer says it actually isn't stable in his opinion |
| 11:37 |
celeron55_ |
for example i will say that about the forceload api |
| 11:37 |
sapier |
while something isn't in a stable version we already do handle it as experimental so changing api not there is allowed |
| 11:38 |
sapier |
I don't actually see a big difference to what we do now but of course writing it down might make this more clear |
| 11:38 |
celeron55_ |
let's leave this out from the upstream repository; someone can do it in the wiki if he wants to |
| 11:38 |
iqualfragile |
celeron55_: the forceload api is not stable? |
| 11:39 |
celeron55_ |
iqualfragile: it sucks horribly for any kind of general use cases and will be replaced with something largely different once someone thinks it is worth his time |
| 11:39 |
iqualfragile |
it does? it kinda works for me |
| 11:39 |
celeron55_ |
(i wouldn't have let it in if i was around at the time it was merged) |
| 11:40 |
celeron55_ |
iqualfragile: your use case isn't generic, then |
| 11:40 |
iqualfragile |
something like is_forceloaded would be nice |
| 11:41 |
iqualfragile |
i just use it in a mod that adds world anchors, anchors that keep a block loaded |
| 11:41 |
sapier |
imho there should be some mechanism so you don't have to keep a block loaded |
| 11:42 |
iqualfragile |
sapier: isn't there? there is something you can use to notify your blocks when a block gets active again and how much time has passed |
| 11:42 |
iqualfragile |
saplings use that |
| 11:43 |
sapier |
why don't you use it if it would fit your needs? |
| 11:43 |
iqualfragile |
it does not |
| 11:43 |
sapier |
so the mechanism isn't complete |
| 11:43 |
iqualfragile |
yep |
| 11:43 |
sapier |
that's what I meant ;-) |
| 11:43 |
iqualfragile |
but its not really completable |
| 11:43 |
iqualfragile |
my usecase is for a treefarm with pipeworks |
| 11:44 |
iqualfragile |
using only the timedelta thing all trees grow at once and get harvested |
| 11:44 |
iqualfragile |
but if they stayed active they could have grown multiple times |
| 11:44 |
sapier |
I don't see why you couldn't handle this too? |
| 11:45 |
sapier |
just give more wood if they could've grown multiple times |
| 11:45 |
iqualfragile |
without keeping the block loaded? i would like to see you try |
| 11:45 |
sfan5 |
sapier: I did not imply it should be done right now |
| 11:46 |
sapier |
sfan5: I see the benefit too but looking at the amount of active coders I doubt we have plenty of resources to spend at formal things ;-) |
| 11:46 |
iqualfragile |
another usecase for forceloading might be minecarts |
| 11:46 |
sapier |
yet celerons suggestion about some automatic stability judgement wouldn't add a lot of overhead |
| 11:47 |
sapier |
minecarts are slightly different as they don't keep a single block loaded |
| 11:47 |
iqualfragile |
never tried, but if you send them into an unloaded block they should stop, right? |
| 11:47 |
sapier |
not exactly they get stuck |
| 11:47 |
sapier |
once the block is loaded they move on with exactly same speed as before |
| 11:47 |
iqualfragile |
with forceloading they could just load the block in front |
| 11:48 |
sapier |
yes but that's quite a different usecase. that block could be unloaded right after the cart passed |
| 11:48 |
iqualfragile |
what is quite annoying about the forceloading api is that you can't check how many times a block has been forceloaded |
| 11:48 |
sapier |
and still the minecart usecase is way more critical then yours |
| 11:49 |
sapier |
maybe we need a limit for forceload entities for example |
| 11:49 |
|
asl97 joined #minetest-dev |
| 11:49 |
|
asl97 joined #minetest-dev |
| 11:57 |
sapier |
hmmmm I just tried using multiple emerge threads but didn't see a obvious issue what am I supposed to look for? |
| 12:10 |
sapier |
wtf ... google wants 25$ for adding apps? |
| 12:11 |
sapier |
hmm I don't care about the 25$ but I won't provide my credit card information to google for sure :-) ... guess I need to get some prepaid anonymous card |
| 12:12 |
LemonLake |
yeah |
| 12:12 |
LemonLake |
i mean its google we're talking about here |
| 12:13 |
LemonLake |
Its only $25 for register, then its free, its a spam filter |
| 12:13 |
sapier |
there are better ways to do spam filtering |
| 12:13 |
LemonLake |
indeed |
| 12:13 |
LemonLake |
but hey, I'm not complaining |
| 12:13 |
LemonLake |
iOS is $99 a month/year whatever |
| 12:14 |
sapier |
true but as I said it's not the 25$ I'm annoyed but I don't intend to create a non anonymous account and providing credit card information will deanonymize it for sure |
| 12:14 |
LemonLake |
yep |
| 12:15 |
sapier |
guess NSA will be able to track it down true but I'm gonna make it as difficult as possible for them ;-) |
| 12:17 |
sapier |
and it's even more annoying to have to create an account prior beeing told it's not free |
| 12:24 |
|
kaeza joined #minetest-dev |
| 12:27 |
|
Jordach_ joined #minetest-dev |
| 12:28 |
|
kaeza joined #minetest-dev |
| 12:29 |
celeron55_ |
sapier: what payment methods they allow? |
| 12:30 |
sapier |
credit card only |
| 12:31 |
sapier |
I'm just gonny buy a prepaid one next time I see one |
| 12:32 |
sapier |
I'm gonna publish minetest on F-Droid first ... they're free and ppl there don't expect apps to be as high quality as on play store. Guess that's gonna be better for minetests reputation ;-) |
| 12:32 |
celeron55_ |
if you have a paypal account, i can route donations to you to cover the cost and some for your other efforts |
| 12:33 |
sapier |
no problem I guess I can afford those 25$ ;) |
| 12:34 |
sapier |
a simple registration causes google to send no less then 4 welcome mails |
| 12:35 |
celeron55_ |
make one; paypal isn't nearly as terrible as google as they don't have to focus on raping their users to get money; they just have old-fashioned transaction costs |
| 12:36 |
sapier |
I once had a paypal account but did delete it ... did you ever try to get rid of an account at an american company? |
| 12:37 |
celeron55_ |
yes you really can't make throwaways |
| 12:37 |
celeron55_ |
i can't blame them though; money is serious business |
| 12:37 |
celeron55_ |
paypal i mean |
| 12:38 |
celeron55_ |
they are probably required by law to keep history of stuff |
| 12:38 |
sapier |
well if they did really want to do it seriously they'd get a banking license in some serious country in eu |
| 12:38 |
celeron55_ |
they have additional bank-like limitations in EU compared to the US |
| 12:39 |
celeron55_ |
that was in news some years ago |
| 12:39 |
celeron55_ |
(not sure what exactly) |
| 12:39 |
sapier |
yes but still they choose to register in the country with lowest standards ... while this is understandable it doesn't increase trust |
| 12:40 |
sapier |
but my information could be outdated I didn't exactly follow what they did the last couple of years |
| 12:41 |
celeron55_ |
while i do know NSA has my credit card info, i haven't had problems with paypal; but whatever, i respect your privacy |
| 12:42 |
sapier |
yes I know I'm a little bit over carefull sometimes :) |
| 12:54 |
|
Jordach joined #minetest-dev |
| 13:01 |
sapier |
hmm as our android port contails gpl code guess the apk will be gpl too ... is this a issue? |
| 13:03 |
Taoki |
Interesting. It seems that object:getpos() can sometimes return incorrect positions. In which circumstances exactly I don't know, but it does so in my creatures mod |
| 13:03 |
Taoki |
Causes mobs to teleport for hundreds of nodes all of a sudden and stuff. Had to add code to prevent it |
| 13:04 |
sapier |
I noticed this about 2 years ago ;-) |
| 13:04 |
Taoki |
heh |
| 13:04 |
sapier |
usually this happens on_activate |
| 13:04 |
Taoki |
celeron55_: Any idea why this can be? It only seems to happen sometimes (randomly) |
| 13:05 |
Taoki |
sapier: For me it happens in on_step |
| 13:05 |
sapier |
then I'd look for a bug in your code, that's quite unlikely as long as the object is still valid and not a stored value |
| 13:06 |
Taoki |
Funny thing is, if I do get_pos for an entity in the on_step function of another entiry, it occasionally returns the position of self. Clearly a weird bug somewhere |
| 13:06 |
Taoki |
sapier: I looked for an hour, didn't find anything |
| 13:06 |
sapier |
where do you have the pointer to that entity from? |
| 13:06 |
Taoki |
sapier: I do self.something.entity = obj (where obj is the other entity). Later I go self.something.entity:getpos() |
| 13:06 |
Taoki |
**do |
| 13:07 |
sapier |
there's no guarantee that entity is still there |
| 13:07 |
sapier |
you may access some random memory on doing it this way |
| 13:07 |
Taoki |
I check for that first actually |
| 13:07 |
Taoki |
if obj:get_luaentity() |
| 13:07 |
sapier |
doesn't help |
| 13:07 |
Taoki |
How come? |
| 13:07 |
sapier |
obj is userdata |
| 13:08 |
sapier |
well wait |
| 13:08 |
Taoki |
I need to store and check the entity that way, no way around that. How can I properly tell if the object is still there in that case? |
| 13:08 |
sapier |
ok object should still be valid but I don't know if get_luaentity checks if the c++ representation is still there |
| 13:08 |
Taoki |
By having it stored in a table, like self.others[1] |
| 13:09 |
sapier |
e.g. the original entitiy could be unloaded and replaced by another entitiy |
| 13:09 |
sapier |
I don't think storing random entity objects is a good idea |
| 13:10 |
Taoki |
Oh my... it's true. if not self.target_current.entity:get_luaentity() sometimes returns TRUE |
| 13:10 |
Taoki |
I did something wround in my code then, it's not an engine bug like I thought |
| 13:10 |
sapier |
I'd not be sure about there not beeing a bug in engine too |
| 13:11 |
sapier |
even if you didn't have caused it by now ;-) |
| 13:12 |
Taoki |
nevermind, that was because it detected players too |
| 13:12 |
Taoki |
No, the entity is always valid it seems |
| 13:12 |
sapier |
always is a long time ;-) |
| 13:13 |
sapier |
still I'd gues you use it for situation where it's extremely unlikely to cause the bug I assume to be in there |
| 13:14 |
Taoki |
It strongly feels like getpos() is failing sometimes and once in 100 attempts returns an incorrect position (enough to break stuff if not handled) |
| 13:14 |
sapier |
there are a lot of things like that on doing mobs |
| 13:15 |
sapier |
fdroid doc is crap |
| 13:17 |
|
Robby joined #minetest-dev |
| 13:25 |
Taoki |
sapier: It's likely an engine bug. I added a debug print, and the entity name is detected when the position issue takes place |
| 13:26 |
Taoki |
So the same get_luaentity() returns a correct name all the time, and crazy positions sometimes while it does so |
| 13:26 |
sapier |
for what I know name is independent of c++ element |
| 13:29 |
Taoki |
Still, the Lua definitions address both. So something likely goes wrong somewhere... either in C++ or builtin or something |
| 13:30 |
sapier |
for what I remember entity objects are not meant to be stored permanent |
| 13:30 |
sapier |
at least it's designed that way |
| 13:30 |
sapier |
it may work but there's no guarantee |
| 13:32 |
Taoki |
Weird thing is, sometimes getpos works then breaks for one execution then works again. So it doesn't look like the entity is truly getting discarded, except maybe once per server execution at random |
| 13:32 |
sapier |
ok that's strange |
| 13:33 |
sapier |
try debugging it |
| 13:35 |
Taoki |
Tried, nothing in my Lua code can change it or seems to be at fault |
| 13:35 |
Taoki |
It makes little sense too... only happens in some parts of my code |
| 13:37 |
Taoki |
So far I work around it by checking if distance is 0, since this usually manifests as self and other positions being reported as the same. Which makes no sense |
| 13:37 |
Taoki |
Hmmmmmm... |
| 13:37 |
Taoki |
It acts almost as if getpos sometimes returns another entity's position. Could that be possible? Could some sort of offset be taking place? |
| 13:38 |
|
grrk-bzzt joined #minetest-dev |
| 13:38 |
sapier |
hard to tell, I never stumbled upon a similar behaviour, I do save objects in order to do fighting too |
| 13:39 |
|
vifino joined #minetest-dev |
| 13:41 |
Taoki |
If you ever try my Creatures mod, ask me which lines are at fault so I can help you test if you'll wish |
| 13:47 |
sapier |
I'm still quite busy with android so don't expect me to have a look at it soon sorry |
| 13:48 |
Taoki |
ok. No worries |
| 13:48 |
Taoki |
Still a strange bug... hope I'll someday know what causes it :P |
| 13:48 |
|
kaeza joined #minetest-dev |
| 13:55 |
RealBadAngel |
sapier, ive tested that gui scaling patch, got the message? |
| 13:55 |
sapier |
yes I hope someone else tests it too so I can merge it |
| 13:56 |
sapier |
did you try in game with a big window too? |
| 13:56 |
RealBadAngel |
i tried it with widescreen and UI |
| 13:56 |
RealBadAngel |
no problems at all |
| 13:57 |
sapier |
ok good |
| 13:58 |
sapier |
does anyone have any experience on using those fdroid scripts? they're quite ugly and errror messages are not telling anything |
| 13:58 |
sapier |
docs are even worse |
| 14:01 |
|
Megaf joined #minetest-dev |
| 14:01 |
sapier |
hmm I wonder if that CiaranG at fdroid is same CiaranG doing fixes for minetest too |
| 14:06 |
|
jin_xi joined #minetest-dev |
| 14:08 |
Megaf |
Hi sapier |
| 14:09 |
sapier |
hello, how can I help? |
| 14:10 |
Megaf |
sapier; I tested your latest android build on my x86 Android phone yesterday |
| 14:10 |
|
hmmmm joined #minetest-dev |
| 14:10 |
sapier |
did it even start? |
| 14:10 |
Megaf |
it was quite a weird experience, menu looked great, but when I joined my server I saw nigh and day alternating several times each second |
| 14:11 |
sapier |
that strange bug again |
| 14:11 |
Megaf |
hopefuly it was just a thing on the client side |
| 14:11 |
Megaf |
sapier; buildcraft like games does have an on screen button to control time |
| 14:12 |
Megaf |
maybe they fixed the time with that |
| 14:12 |
sapier |
I read about it in ancient issues but noone seemd to be able to reproduce it |
| 14:12 |
Megaf |
still a terrible idea for an online game |
| 14:12 |
sapier |
hmm yesterday means the ..16 build? |
| 14:12 |
Megaf |
21 |
| 14:12 |
sapier |
ok |
| 14:13 |
sapier |
so todays build :-) |
| 14:14 |
sapier |
what device is android x86? |
| 14:14 |
Megaf |
sapier; I said yesterday because was just before I went to sleep :P |
| 14:14 |
sapier |
lol |
| 14:19 |
|
kaeza joined #minetest-dev |
| 14:23 |
Megaf |
sapier; My server is set to work in real time, Im online with the android build and its cycling day/night |
| 14:23 |
sapier |
arm too? |
| 14:23 |
Megaf |
I have only x86 arm capable of running minetest |
| 14:24 |
Megaf |
and how Im supposed to close the inventory? |
| 14:24 |
sapier |
double tab outside of inventory |
| 14:24 |
sapier |
if you wanna place a single item to a inventory slot hold down one finger and tab with another somewhere else item will be put to location first finger |
| 14:25 |
sapier |
actually that's same as right clicking with mouse :) |
| 14:25 |
sapier |
the only difference is first finger is cursor |
| 14:26 |
Megaf |
sapier; the build works great |
| 14:26 |
Megaf |
only problem is the day/night thing |
| 14:26 |
Megaf |
minetest is like a strobo |
| 14:26 |
Megaf |
and its an OLED screen, so it can flickr quite fast |
| 14:28 |
Megaf |
and it crashed when opening the chat thing |
| 14:33 |
hmmmm |
sapier: how is blitting back in that manner broken? |
| 14:33 |
hmmmm |
it works fine, just less than optional since I can't blit things back if they're content ignore |
| 14:33 |
hmmmm |
err... s/optional/optimal/ |
| 14:33 |
hmmmm |
consider the case: |
| 14:35 |
hmmmm |
2 emerge threads, one emerges blocks that don't exist (they're new) so they get blank block filled and added to Map. mapgen starts generating. now a second emergethread emerges that same block because it's from a bordering chunk.. it goes to generate that block. it so happens that the first chunk gets done first, the voxelmanip blits that back to Map |
| 14:35 |
hmmmm |
now remember at this point when the voxelmanip on the 2nd emergethread emerged, it was all content ignore |
| 14:36 |
hmmmm |
so when it goes back to blit its own contents back, it didn't write all of the contents of the neighboring chunks that it needed to load anyway for caves or trees or whatever |
| 14:37 |
hmmmm |
so now you have a 2 block wide stripes of content ignore everywhere in the messiest pattern possible |
| 14:38 |
hmmmm |
the only other possible way to fix this is to have some kind of mechanism so that all voxelmanipulators are always synchronized with regard to their contents |
| 14:47 |
hmmmm |
well I guess an optimization you could do is check some kind of global variable to see if there's more than one emerge thread running, and don't use memcpy if that's the case |
| 15:02 |
|
kaeza joined #minetest-dev |
| 15:10 |
|
NakedFury joined #minetest-dev |
| 15:18 |
|
Jordach joined #minetest-dev |
| 15:32 |
|
BrandonReese joined #minetest-dev |
| 15:35 |
|
diemartin joined #minetest-dev |
| 15:52 |
|
Calinou joined #minetest-dev |
| 16:15 |
|
rdococ joined #minetest-dev |
| 16:32 |
sapier |
hmmmm you're right about that issue ...still I don't accept yet that our only choices are horribly slow in 99% case or inconsistent in collision case ... maybe we really should create some transaction model for map. |
| 16:37 |
hmmmm |
well sure |
| 16:37 |
hmmmm |
i agree |
| 16:38 |
hmmmm |
anyway, not using memcpy isn't absolutely horrible there. i think it increased blitback time by like .005 seconds or something |
| 16:38 |
sapier |
I didn't even run in this corner case by now and original code does 2 3d loops each of them way more slow then memcpy |
| 16:38 |
sapier |
it is |
| 16:38 |
sapier |
it's about a factor 10-20 |
| 16:38 |
hmmmm |
yeah |
| 16:38 |
hmmmm |
but i mean in absolute terms |
| 16:39 |
sapier |
well I managed to reduce voxelmanips total faction from more then 10% to <1% |
| 16:39 |
sapier |
it's not an issue on fast machines but once you're on slow arm things like that suddenly become quite relevant |
| 16:39 |
hmmmm |
definitely a transaction based system would be ideal but it still has to be done |
| 16:40 |
hmmmm |
we've been talking about transaciton based map access for over 2 years now |
| 16:41 |
sapier |
I don't know mapgen very well ... and to be honest I'd prefere not to start another big thing |
| 16:42 |
sapier |
guess I'm gonna rework those changes to be compiler dependent and force usage of a single emerge thread if enabled |
| 16:42 |
sapier |
complile time dependent of course |
| 16:45 |
|
zat joined #minetest-dev |
| 16:46 |
hmmmm |
huh!? |
| 16:46 |
hmmmm |
why |
| 16:46 |
hmmmm |
why not just enable memmap if there's only one emerge |
| 16:48 |
sapier |
it's used for lua to someone could choose not to write back his changes |
| 16:48 |
hmmmm |
oh |
| 16:49 |
hmmmm |
i forgot we had voxelmanipulators in lua |
| 16:49 |
|
Piggybear87 joined #minetest-dev |
| 16:50 |
sapier |
I still don't exactly understand, noone did ever check for unloaded how does this cause inconsistenc |
| 16:50 |
sapier |
y |
| 16:52 |
hmmmm |
so say we do have transactional map access |
| 16:52 |
hmmmm |
you still need to merge the two write attempts together |
| 16:52 |
sapier |
no |
| 16:52 |
|
book` joined #minetest-dev |
| 16:53 |
sapier |
that's what transactions are for in case your base data have changed writing back is denied merge has to be done by the one wanting to write |
| 16:53 |
hmmmm |
right so it fails |
| 16:53 |
hmmmm |
so what should it do when it does fail |
| 16:54 |
sapier |
do it again after reading current? |
| 16:55 |
sapier |
do you know that there are exactly two locations where a node is checked for NOT_LOADED? |
| 16:55 |
sapier |
the one replacing it by inexistent and the one printing a block in debug mode |
| 16:55 |
hmmmm |
i didn't know that |
| 16:56 |
hmmmm |
so let me figure out how this is going to work |
| 16:56 |
hmmmm |
you have two voxelmanipulators sharing a block |
| 16:56 |
sapier |
ohh a third location ... there it's NOT_LOADED or INEXISTENT :-) |
| 16:56 |
hmmmm |
the one writes real terrain to it and goes to save |
| 16:56 |
hmmmm |
it succeeds |
| 16:57 |
hmmmm |
the second one writes cave air to it then tries to save |
| 16:57 |
hmmmm |
several of the block save attempts fail |
| 16:57 |
|
Calinou joined #minetest-dev |
| 16:57 |
hmmmm |
so i guess outside of the mapgen, then, the same merge logic gets done that's in blitBackAll |
| 16:58 |
hmmmm |
we'd just be moving the block merge operation outside of VoxelManipulator and what to do in the case of a map transaction write failing |
| 16:58 |
hmmmm |
instead of the common case |
| 16:58 |
sapier |
yes that'd add overhead to special case but I'd assume it'd still be faster in total |
| 16:59 |
hmmmm |
okay |
| 16:59 |
hmmmm |
now how would merging work in a case where the data being written isn't content_ignore? |
| 16:59 |
hmmmm |
timestamps i guess |
| 16:59 |
hmmmm |
alright |
| 17:00 |
sapier |
it's not ignore bit inexistent |
| 17:06 |
sapier |
hmmmm I understand your issue but I start to believe that issue is already present |
| 17:08 |
sapier |
VOXELFLAG_NOT_LOADED is never used to decide anything except for one situation ... to decide if some element loaded has to be VOXELFLAG_NOT_LOADED too ... and once a block is emerged it's cleared ... so what does this flag actually do if noone checks for it? |
| 17:09 |
hmmmm |
it's useless |
| 17:09 |
hmmmm |
VOXELFLAG_NOT_LOADED isn't my doing, ask celeron |
| 17:09 |
sapier |
ok so you do think same as I do? |
| 17:09 |
hmmmm |
yes |
| 17:09 |
sapier |
because that flag adds more then 100% code runtime there |
| 17:09 |
hmmmm |
right |
| 17:09 |
hmmmm |
and it doesn't need to exist |
| 17:10 |
|
Jordach joined #minetest-dev |
| 17:10 |
hmmmm |
that's fine, what's not fine is simply copying nodes back instead of merging them |
| 17:10 |
hmmmm |
so i'll have to look into transactions I guess... |
| 17:10 |
sapier |
it's been done same before? |
| 17:11 |
sapier |
ahh wait |
| 17:11 |
sapier |
there wouldn't have been done anything in case of not loaded |
| 17:11 |
sapier |
ok you're right I'll fix this |
| 17:12 |
sapier |
but |
| 17:12 |
sapier |
the area we copy to is already blank |
| 17:12 |
sapier |
why merge something? |
| 17:12 |
hmmmm |
:| |
| 17:12 |
hmmmm |
I explained this above |
| 17:13 |
sapier |
wait, have a look at addArea |
| 17:13 |
sapier |
maybe we're talking about different things |
| 17:13 |
hmmmm |
i think so |
| 17:13 |
sapier |
bit there the location with //copy old data |
| 17:14 |
sapier |
the original code did check for the flag ... BUT target is created right above and initialized as blank |
| 17:14 |
sapier |
writing blank to blank doesn't cause any issues except maybe some more bytes |
| 17:15 |
hmmmm |
yeah i'm not talking about the flags though |
| 17:15 |
sapier |
maybe there should be merge code in there but I don't see anything capable of merging at that location |
| 17:15 |
hmmmm |
i'm talking about the actual content being blitted back to Map |
| 17:15 |
sapier |
ok where's that code? |
| 17:15 |
hmmmm |
in copyTo's innermost loop! |
| 17:15 |
hmmmm |
jeez |
| 17:16 |
sapier |
ohhh ... we've been talking about completely different code locations :-( |
| 17:18 |
sapier |
you're right, that change is wrong ... I'll revert it and only remove the memcpy comment ... it's a false friend in there :-/ |
| 17:20 |
hmmmm |
so |
| 17:20 |
hmmmm |
instead of optimizing the small stuff |
| 17:20 |
hmmmm |
i think it's time for transactions with RCU |
| 17:20 |
|
LemonLake left #minetest-dev |
| 17:21 |
sapier |
well that small stuff brought about factor >4< fps on android |
| 17:21 |
sapier |
2fps ->8 |
| 17:21 |
|
Zeitgeist_ joined #minetest-dev |
| 17:21 |
sapier |
while 2 is slideshow you can play with 8 ;) yes it's not that much fun but possible ;-) |
| 17:23 |
sapier |
but I won't stop you from implementing transactions for sure ;-) |
| 17:50 |
|
cg72 joined #minetest-dev |
| 18:35 |
|
RealBadAngel joined #minetest-dev |
| 19:00 |
|
Eater4 joined #minetest-dev |
| 19:02 |
|
proller joined #minetest-dev |
| 19:03 |
Calinou |
why are position-less sounds so loud and position-y ones so quiet |
| 19:03 |
Calinou |
I have to use gain = 0.75 on the position-less sound and gain = 5 on the position-y sound |
| 19:03 |
Calinou |
the sound is mono |
| 19:03 |
Calinou |
they sound similar |
| 19:04 |
sfan5 |
I love how carfully data is handled |
| 19:04 |
sfan5 |
\x4f\x45\x74\x03\<peer id>\x00\x01\x00\x40\x00\x01 |
| 19:04 |
sfan5 |
send that to any minetest server to crash it |
| 19:05 |
sfan5 |
carefully* |
| 19:06 |
Calinou |
report it in the issue tracker |
| 19:06 |
Calinou |
how would you “send†it anyway? |
| 19:06 |
sfan5 |
http://sprunge.us/aSaT?diff and press H |
| 19:07 |
jin_xi |
crash privilege |
| 19:07 |
sfan5 |
:D |
| 19:08 |
hmmmm |
that is so embarassing |
| 19:08 |
hmmmm |
so does it actually crash, or does it just cause an exception and abort |
| 19:08 |
sfan5 |
assert(0) |
| 19:09 |
hmmmm |
okay then |
| 19:09 |
hmmmm |
the worst this can do is a denial of service |
| 19:09 |
sfan5 |
what's worse than a DoS for a popular server? |
| 19:09 |
hmmmm |
at least there's no potential of arbitrary code execution |
| 19:10 |
hmmmm |
sfan5: having shellcode run on it |
| 19:10 |
sfan5 |
code exec is too hard to reliably acheive anyay |
| 19:10 |
sfan5 |
anyway* |
| 19:10 |
hmmmm |
sure, but if it happens, it's disasterous |
| 19:10 |
sfan5 |
yeah |
| 19:12 |
sfan5 |
oh |
| 19:12 |
sfan5 |
another one |
| 19:12 |
sfan5 |
this one's stupid too |
| 19:12 |
Calinou |
find a fix now |
| 19:12 |
Calinou |
it's preferable to go fast |
| 19:12 |
Calinou |
once you find a security issue and publish it |
| 19:12 |
sfan5 |
be a client protocol ver <= 22 and send a TOSERVER_CLIENT_READY |
| 19:13 |
hmmmm |
who writes this code |
| 19:13 |
Calinou |
but hey, this is better than someone telling, on the Minetest wiki, that item_drop lets you duplicate items… this is how I fixed the dupe glitch :D |
| 19:13 |
hmmmm |
jeez |
| 19:13 |
sfan5 |
(not tested, but should work) |
| 19:14 |
sfan5 |
https://github.com/minetest/minetest/blame/master/src/server.cpp#L1755 |
| 19:15 |
hmmmm |
oh |
| 19:15 |
hmmmm |
again, failing an assertion is not a horrible security concern |
| 19:15 |
sfan5 |
(I did not imply that it was a crash) |
| 19:16 |
sfan5 |
still.. a DoS is pretty bad |
| 19:16 |
hmmmm |
that doesn't exist in release mode which is what servers typically run |
| 19:16 |
sfan5 |
uhh.. no |
| 19:16 |
hmmmm |
uhh... |
| 19:16 |
sfan5 |
I tested the first thing I mentioned against a release build |
| 19:16 |
hmmmm |
the first thing != the second thing |
| 19:17 |
sfan5 |
right |
| 19:17 |
sfan5 |
but I'm pretty sure we have asserts even in release builds |
| 19:17 |
hmmmm |
we don't... go look at the definition for assert() |
| 19:17 |
hmmmm |
asserts being removed on release is also what caused the semaphore synchronization problem too |
| 19:19 |
sfan5 |
hm.... |
| 19:20 |
sfan5 |
https://github.com/minetest/minetest/commit/a013f762c4c9b39a1d143ee1b68e6d8e86dcee22 |
| 19:20 |
sfan5 |
how did this happen then? |
| 19:21 |
hmmmm |
dammit i don't know |
| 19:21 |
hmmmm |
these people love exceptions and assertions |
| 19:22 |
hmmmm |
so I guess what we need to do is make sure that ALL exceptions are caught at the appropriate level |
| 19:22 |
hmmmm |
no, it's just sapier who loves assertions |
| 19:22 |
hmmmm |
we need to go through all of his code and make sure that any assertions made can't be used in a dos |
| 19:22 |
sfan5 |
^ |
| 19:23 |
|
werwerwer joined #minetest-dev |
| 19:23 |
sfan5 |
I don't see assert() being wrapped in an #ifndef NDEBUG https://github.com/minetest/minetest/blob/master/src/debug.h#L91-94 |
| 19:25 |
hmmmm |
wtf |
| 19:25 |
hmmmm |
when did that change |
| 19:26 |
sfan5 |
never if you ask me |
| 19:26 |
sfan5 |
>2010-11-27 Initial files |
| 19:26 |
sfan5 |
it changed never |
| 19:26 |
hmmmm |
why does the assertion need to be redefined anyway |
| 19:27 |
hmmmm |
also if that's not true, then how did the semaphore problem happen...? |
| 19:29 |
hmmmm |
OH WOW |
| 19:29 |
hmmmm |
so jthread uses the real assert, and everything else uses the minetest assert |
| 19:29 |
hmmmm |
this is stupid |
| 19:30 |
hmmmm |
is there a demonstratable reason why assert needs to be overridden? |
| 19:30 |
sfan5 |
maybe it does not use assert_fail() if not redefined? |
| 19:30 |
hmmmm |
the fds don't need to be closed, that gets done on exit anyway |
| 19:30 |
sfan5 |
I'm not sure why we would need assert_fail thou |
| 19:30 |
hmmmm |
i'd rather hear the answer from celeron before anything gets changed |
| 19:31 |
hmmmm |
i feel like almost the entire debug.h is unnecessary and dangerous though |
| 19:31 |
sfan5 |
let's rm it |
| 19:31 |
sfan5 |
(not a real suggestion) |
| 19:32 |
sfan5 |
Calinou: technically we already have an issue for that, but client side |
| 19:33 |
sfan5 |
github needs an issue search feature |
| 19:34 |
PilzAdam |
sfan5, the bar at the top searchs issues if you are in the issue tab |
| 19:34 |
sfan5 |
seems like we don't have an issue then |
| 19:47 |
hmmmm |
!tell sapier in ConnectionSendThread::processReliableCommand() line 1628 you should mark your intent with /* FALLTHROUGH */ |
| 19:47 |
hmmmm |
err |
| 19:47 |
hmmmm |
.tell sapier in ConnectionSendThread::processReliableCommand() line 1628 you should mark your intent with /* FALLTHROUGH */ |
| 19:47 |
hmmmm |
nevermind |
| 19:48 |
hmmmm |
sapier: you should look very closely at assert()s used in ConnectionReceiveThread methods |
| 19:49 |
sfan5 |
hmmmm: I already looked at all assert()s in connection.cpp and did not find a way to do a DoS |
| 19:51 |
hmmmm |
what guarantees channel not being equal to zero |
| 19:51 |
hmmmm |
....oh, channel is a pointer, not a number |
| 19:51 |
hmmmm |
grr |
| 20:02 |
RealBadAngel |
can some1 test #1370, so we get it merged? |
| 20:03 |
RealBadAngel |
i have tested it on widescreen, its workin ok for me, so im after mergeing it right now |
| 20:04 |
RealBadAngel |
https://github.com/minetest/minetest/pull/1370 |
| 20:08 |
celeron55_ |
hmmmm: it's ~tell |
| 20:08 |
sfan5 |
celeron55_: ShadowBot is gone |
| 20:09 |
celeron55_ |
oh, that too then |
| 20:09 |
sfan5 |
celeron55_: also: <hmmmm> why does the assertion need to be redefined anyway (in debug.h) |
| 20:10 |
celeron55_ |
i'm not sure |
| 20:10 |
celeron55_ |
maybe it was to cause the now-unused debug stack thing to get used |
| 20:10 |
celeron55_ |
(which should be removed some day) |
| 20:11 |
celeron55_ |
and maybe it allows logging the assert in the debug log? |
| 20:12 |
celeron55_ |
it's not like it's there for no reason whatsoever anyway |
| 20:12 |
|
Piggybear87 joined #minetest-dev |
| 20:22 |
hmmmm |
haha |
| 20:22 |
hmmmm |
you're the one who put it there so i figured you'd have the answer |
| 20:22 |
|
Miner_48er joined #minetest-dev |
| 20:23 |
hmmmm |
erm, it does fclose() on some error streams, but by the POSIX standard, file streams are closed on program exit |
| 20:23 |
hmmmm |
so it's not like you even need that |
| 20:25 |
|
Jordach joined #minetest-dev |
| 20:30 |
|
diemartin joined #minetest-dev |
| 20:44 |
proller |
peoples starts finding hidden sapiers code features |
| 20:44 |
proller |
one found, others - not |
| 21:42 |
|
sapier joined #minetest-dev |
| 21:50 |
|
ImQ009 joined #minetest-dev |
| 21:51 |
RealBadAngel |
sapier, can you merge 1370? i would like to add some new code to GUIFormSpecMenu.cpp |
| 22:03 |
sapier |
ok but first I'm gonna push the fixes for those errors sfan5 recently found |
| 22:07 |
sapier |
sadly I can't rely on proller finding all my faults any longer :-) |
| 22:10 |
sapier |
RealBadAngel: hope you tested 1370 good as it's gui code it's quite likely any bug in there will cause big waves ;-) |
| 22:10 |
sapier |
AND everyone should be aware that 1370 changes position of tabheaders! |
| 22:11 |
RealBadAngel |
since few hours im working on build with that patch. adding tooltips and translations to UI |
| 22:11 |
sapier |
hmm guess you would've found big issues by now |
| 22:12 |
sapier |
did you already do the settings tooltips? |
| 22:12 |
RealBadAngel |
i havent noticed any unusual behaviour |
| 22:12 |
sapier |
if not what about replacing tthe bi tri ani checkboxes by a dropdown? |
| 22:12 |
RealBadAngel |
i do have some tooltips rdy, mainly for shaders |
| 22:13 |
RealBadAngel |
leave it as is by now, i will have to add lotsa new settings there, so then we will think how to rebuild this tab |
| 22:14 |
sapier |
that's been my thought too ... guess it's really time to do it |
| 22:15 |
RealBadAngel |
i do not plan to add extra settings before next stable |
| 22:15 |
sapier |
ok then lets keep it that way for now and think about some way to do it next time ... maybe subtabs |
| 22:18 |
sapier |
ok pushing 1370 now |
| 22:18 |
RealBadAngel |
i will need definitely more space |
| 22:19 |
RealBadAngel |
some settings will require sliders, like contrast, brightness, normalmaps smoothing etc |
| 22:19 |
sapier |
I already opened a pull request for sliders/scrollbar |
| 22:20 |
RealBadAngel |
good |
| 22:20 |
sapier |
https://github.com/minetest/minetest/pull/1391 I know scrollbars aren't exactly sliders but irrlicht doesn't have sliders ... and I don't wanna implement them on my own as it's gonna be a compatibility issue when updating irrlicht |
| 22:22 |
RealBadAngel |
will try them tommorow |
| 22:24 |
RealBadAngel |
now im going to add tooltips also for item image buttons, they do have built-in ones, but we need an option to override them |
| 22:37 |
sapier |
https://github.com/minetest/minetest/pull/1379 ShadowNinja is the new version ok to you? |
| 23:21 |
sapier |
fixing the stall file handle issue is more complex then it seems to be |
| 23:23 |
sapier |
closing a sqlite db is not equivalent to closing the file handle. sqlite in WAL mode has a quite stange behaviour. In case it believes someone may still have a file lock to it it just doesn't close the handle |
| 23:38 |
sapier |
maybe I should check first what mode we're using |
