Minetest logo

IRC log for #minetest-dev, 2014-06-21

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext