Time  Nick         Message
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
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: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
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
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?
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: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: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: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 :)
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: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 sapier       hard to tell, I never stumbled upon a similar behaviour, I do save objects in order to do fighting too
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: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 sapier       hmm I wonder if that CiaranG at fdroid is same CiaranG doing fixes for minetest too
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 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: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
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: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: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: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 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 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:21 sapier       well that small stuff brought about factor >4< fps on android
17:21 sapier       2fps ->8
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 ;-)
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 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:22 hmmmm        haha
20:22 hmmmm        you're the one who put it there so i figured you'd have the answer
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:44 proller      peoples starts finding hidden sapiers code features
20:44 proller      one found, others - not
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