Minetest logo

IRC log for #minetest-dev, 2015-01-04

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

All times shown according to UTC.

Time Nick Message
00:02 sapier https://github.com/minetest/minetest/pull/2044
00:08 Wayward_One https://github.com/minetest/minetest/issues/2045
00:08 ShadowNinja VanessaE: Right.  I assumed that was intentional.  Does it detach the mouse on Windows?
00:09 VanessaE ShadowNinja: I'm not sure, but I think so.  how else would people copy&paste from the chat console? :)
00:09 ShadowNinja VanessaE: And C&P should work in the console now, although it's never worked on Linux, so that's not an issue.
00:09 ShadowNinja VanessaE: C-a C-c C-v
00:10 ShadowNinja Or Shift-direction C-c
00:10 VanessaE ShadowNinja: nope, I can't highlight to copy out from the console.
00:10 VanessaE neither c-a nor shift-arrows cause a highlight.
00:11 VanessaE nor can I paste in from e.g. hexchat.
00:11 VanessaE but I can at least c-a, c-c and copy out from the old command line back to here.
00:11 ShadowNinja VanessaE: Well, pasting has never worked.  Copying should be fixed though.  Make a comment on this usse so that this isn't forgoten.
00:12 ShadowNinja the issue*
00:13 VanessaE done.
00:18 hmmmm so I think I got a pretty solid idea down, going with a slightly modified version of alternative lighting method #2 as discussed.  i can make light spread further, i'll save 8 bits per mapnode, i can speed up lighting calculations, and i can have 24-bit colored lighting this way
00:18 * VanessaE updates just to make sure about the console C&P
00:18 hmmmm :D  yay
00:18 VanessaE hmmmm: very nice indeed.  and it works okay with mods that check light levels in the usual way?
00:18 sapier speed up light calculations? *Jumping up*
00:18 hmmmm vanessae:  nope
00:18 sapier wanna have this! ;-)
00:18 Wayward_One hmmm, can't wait to try it! :D
00:18 VanessaE hmmmm: boooo :(
00:19 Wayward_One *hmmmm
00:19 hmmmm mods are gonna have to calculate light the 'hard' way
00:19 hmmmm well
00:19 sapier hard way?
00:19 hmmmm nah i can just modify the api for it
00:19 sapier you're kidding, I once wrote that in lua it's gonna take all the speed benefit and reverse it ;-P
00:19 hmmmm but it'll be way, way, way more computationally expensive to get the light at a specific point
00:20 hmmmm because i won't store it in the node any longer
00:20 VanessaE ShadowNinja: ok, at git HEAD now and still can't c-a, c-c (doesn't highlight on c-a).
00:20 sapier so any mapgen or spawning mod requireing light information will get drastically slower
00:20 hmmmm pretty much yep
00:20 VanessaE hmmmm: um
00:20 sapier not good
00:20 hmmmm :)
00:20 VanessaE that breaks like half of plantlife.
00:21 sapier I have some mobs spawning only in areas where almost no light is there .. e.g. vombies
00:21 hmmmm I think there is a better way to do the thing you'd like to do
00:21 hmmmm rather than check light levels
00:21 sapier suggestions hmmmm?
00:21 sapier I never found a way to do same thing another less expensive way
00:21 hmmmm have a bit present in the mapnode for 'has_sunlight'
00:21 sapier won't work
00:22 sapier because spawning doesn't care about sunlight but actual light
00:22 VanessaE hmmmm: torches triggering solar panels to act as node sensors.
00:22 VanessaE (think:  automated tree farms using pipeworks and mesecons)
00:22 hmmmm that's a hacky way to do things to begin with though
00:23 hmmmm so what do we actually need light levels for
00:23 sapier it's not hacky to check for light if something doesn't have to spawn once light is around ;-)
00:23 ShadowNinja VanessaE: "Doing this would leave the ESC/Pause menu as the only way to release the keyboard/mouse." -- not true, opening formspecs also releases the mouse.
00:23 hmmmm is it absolutely necessary to know that (x, y, z) == 13 or something
00:23 VanessaE ShadowNinja: oh right.  /me fixes.
00:23 hmmmm or is it more like
00:23 hmmmm "i need to know where in the mapblock i can place this"
00:23 sapier no but I need to know if light at xyz is > a
00:24 hmmmm so if you're doing a bulk query then calculating light levels in a mapblock probably isn't too expensive
00:24 sapier if you can provide the max light level within a certain area that'd be enough
00:24 hmmmm yeah that too
00:24 hmmmm that would be extremely quick
00:24 sapier if light in (x1,y1,z1) (x2,y2,z2) > a
00:24 VanessaE that would NOT be enough
00:24 VanessaE you'll break everything that relies on light levels at specific locations.
00:24 sapier how do you intend to make this quick?
00:25 hmmmm VanessaE:  yes, and minetest moves forward as a whole
00:25 sapier in worst case x2 == x1+1
00:25 hmmmm well
00:25 sapier that's not moving forward thats moving backward ;-)
00:25 hmmmm hopefully your radius is conveniently the size of a mapblock
00:25 sapier you're removing a feature because it's to slow for you
00:25 * VanessaE grumbles
00:25 sapier nope
00:25 sapier a mapblock is way to big for spawning
00:26 VanessaE hmmmm: why can't the light at a given point be calculated the "old" way on demand?
00:26 sapier especally as usually no more then a few blocks are even loaded
00:26 hmmmm because that takes up 8 bits
00:26 hmmmm well
00:26 VanessaE on the server?
00:26 hmmmm on both
00:27 sapier hmmm it's not gonna work on mapblock granularity I already tried this
00:27 VanessaE you're gonna trifle over one byte?!
00:27 hmmmm that's not just one byte
00:27 sapier I had to add a separate spawn position storage with all issues to get rare mobs spawning correct
00:27 hmmmm that's 25% of the most commonly used data structure in the entire engine
00:27 VanessaE ok fine, 4k then
00:27 VanessaE (per block)
00:27 sapier I know hmmmm but that's like "let's remove the screen update it's causing most load"
00:27 hmmmm besides, with RGB lights, how are you even going to get brightness?  you'd need to do YCrCb conversion
00:28 sapier who did add rgb lights?
00:28 VanessaE ok we have maybe 2000 blocks loaded at once in worst case.  that's not even 8 MB.
00:28 hmmmm so what's the largest radius we're looking at here
00:28 VanessaE (I'm pretty sure I've seen my server's count get close to that a few times)
00:28 hmmmm larger than a mapblock?  smaller than a mapblock?
00:29 VanessaE hmmmm: for a light radius test?
00:29 sapier largest light radius I'm looking for is about 3 nodes
00:29 hmmmm for the radius tests you commonly do
00:29 VanessaE hmmmm: I would say 3x3x3 nodes off the top of my head
00:29 hmmmm note this isn't absolutely horrible
00:29 sapier yes but block granularity is way to big
00:29 VanessaE judging by what I've seen done in practice in actual users' builds
00:29 VanessaE and what I've done myself
00:30 sapier having only about 9 blocks loaded in singleplayer some mobs would never ever spawn
00:30 VanessaE but even THAT will be too coarse for some fine tuning
00:30 VanessaE (e.g. making "unit tests" so to speak, in-game)
00:30 hmmmm how many of these radiuses would happen in the same mapblock
00:30 sapier a lot
00:30 hmmmm then it'd be worth it
00:31 VanessaE depends.  in a typical pipeworks/mesecons apparatus, probably 20-30.
00:31 sapier if you find a way NOT to break light per node and still speed it up it'd be worth it
00:31 VanessaE (usually far less)
00:31 sapier mobf uses up to 20% cpu load to do this if you make it 10 times slower about 10 times less mobs will spawn
00:32 VanessaE in plantlife, probably hundreds of such checks per mapblock are done
00:32 sapier and of course lag issues will increase as spawning will take time from more valuable tasks
00:32 VanessaE (I've never counted)
00:34 sapier hmm vombie does use a radius of 0 (only spawn location)
00:36 sapier big red uses 2, 10 retries, each 60 seconds, with half this time if not beeing able to spawn at least 3 within a range of 100 nodes ... which already requires separate spawn point storage
00:36 hmmmm the problem i have is that the engine itself storing light information is quite useless since it's only used at one point, at mesh render time
00:36 VanessaE for plantlife, knowing the light level within 2 nodes of the target would be sufficient
00:37 hmmmm on the other hand mods are storing it and reading it much more often
00:37 sapier no it's a basic feature used by mods
00:37 VanessaE it's not useless because it's used by dozens of mods
00:37 sapier light is a property of a noded it's not only something client has to display
00:37 VanessaE so calculate it your fancy way, store it, and don't fret over the extra storage it takes.
00:37 sapier e.g corn growing
00:37 hmmmm well, it's never explicitly written to
00:38 sapier most nodes never write a node type too
00:38 sapier mobf for example usually doesn't modifiy exisiting nodes
00:38 ShadowNinja hmmmm: Maybe you could cache the light level in a param3 that's only compiled in on the server and isn't sent to the client?
00:38 hmmmm yeh but light information is implicit along with the content type
00:38 sapier removing per node light information is a big step backward
00:39 hmmmm ShadowNinja, that would stop working the minute we add client side scripting
00:39 ShadowNinja (Or "light", since that's a lot less cryptic.
00:39 hmmmm i'd rather focus on ways to get computing this very fast
00:39 VanessaE hmmmm: well the client will eventually do some kind of hardware-assisted lighting rendering, right?
00:40 hmmmm thought about it, no, hardware lighting doesn't help much with minetest's use case
00:40 VanessaE at that point, all it needs to know is where all the light *sources* are.  it doesn't have to care what the server says are the per-node light levels
00:40 hmmmm sunlight can be done by hardware lighting but light sources not so much
00:40 VanessaE hrm
00:40 * VanessaE pokes RealBadAngel
00:40 deezl joined #minetest-dev
00:41 hmmmm the issue is that our world is dynamic
00:41 deezl sapier, are you here?
00:41 VanessaE yeah I know
00:41 hmmmm this is simply something that games never did
00:41 sapier yes deezl
00:41 VanessaE meaning a user could potentially place thousands of light sources, while opengl et al. are limited on how many they can render.
00:41 sapier is anyone about to fix the particle spawner memory leak?
00:42 deezl hi, just had someone log into one of my servers with your name, was wondering if it was you
00:42 hmmmm calculating light correct way is very difficult, you basically need to solve the radiosity problem each time you add a light
00:42 deezl (I was doubting it)
00:42 hmmmm which is like 5 differential equations
00:42 VanessaE sapier: what about jin_xi/SN's irrlicht particles code?  shouldn't that be finished/merged first?
00:42 hmmmm the minecraft light calculation method is so cheap on the other hand
00:42 sapier if it's been the big... server yes I'm trying to pinpoint a memory leak
00:43 deezl oh ok, well that's good
00:43 ShadowNinja sapier: No.  The particles code is a mess though, and jin_xi's code needs a lot of work.
00:43 deezl yes, that was my server
00:43 sapier loosing about 2k on processing each particle packet?
00:43 sapier that's a huge issue ;-)
00:43 VanessaE sapier: you really want to see that in effect, I seem to recall the just test server had an active spawner near the spawnpoint that really set it off.
00:44 deezl sapier, if it helps any, or matters at all, BigPappa's is not standard minetest_game, it is a modified version of carbone.
00:44 sapier who wrote this code?
00:44 sapier client has no chance to cleanup the spawners
00:44 VanessaE particle spawners?  jeija did I think.
00:44 hmmmm that's mirciakitsune
00:45 VanessaE oh right
00:45 johnnyjoy joined #minetest-dev
00:45 hmmmm it's so sloppy
00:45 hmmmm i'm not sure why i approved that
00:47 sapier hmm at least there's a clear_particles() function ... let's hope it's doing what I expect it to do ... well actually it's clearing the spawners not the particles
00:47 sapier deezle thanks for this information but memory leaks still shouldn't happen ;-)
00:48 deezl agreed.
00:49 hmmmm so on a lighter note (pun intended) what do you guys say about merging some options in the pause menu
00:49 hmmmm change password, sound volume, change keys -> Options
00:49 VanessaE er...
00:50 ShadowNinja hmmmm: That sounds good.
00:50 sapier agreed
00:50 VanessaE yeah, sounds good.
00:59 paramat hmmmm sounds okay, personally i wouldn't much miss light as param2, i've written a variety of mods and have rarely used it. when it's occasionally needed in mods a slower method would be okay
01:04 sapier as I said paramat for spawning a slower method would be a desaster current method is already a big problem
01:06 compunerd joined #minetest-dev
01:06 paramat yes this will be unpopular with those who use light level a lot, i would suggest perhaps triggering spawning a different way
01:07 sapier there's no way to replace it
01:07 sapier if there's no way to spawn mobs based uppon light level the only option is removing those mobs
01:07 sapier meaning almost all hostile mobs dying in sunlight
01:08 sapier dieing
01:08 Wayward_One joined #minetest-dev
01:09 paramat i'm suggesting spawn or kill them dependant on something else then, time of day ..
01:09 sapier not very usefull
01:09 hmmmm we don't need to copy minecraft into our grave
01:09 sapier it's already hard to spawn a mob below ground
01:09 hmmmm they don't have RGB light or any of the other cool stuff because they store it all in the node information
01:09 sapier we don't need to remove features just because you think theyre slow either
01:09 paramat i would still like to have sunlight with simple shadows (low res shadows?) by hardware lighting
01:10 paramat i guess hmmmmm's method would mean a usable system without hardware sunlight, so it's not essential
01:10 sapier you could use your calculation for rgb and just store brightness in node
01:10 paramat (for slow computers)
01:11 hmmmm no, sunlight would still be hardware lighting
01:11 hmmmm sapier, how about 4 bits
01:11 hmmmm or 3
01:11 hmmmm 3 is the best I can do
01:12 sapier 3 is way to limited
01:12 hmmmm 8 levels of light??
01:12 paramat sorry i mean, with hmmmmm's suggestion hardware sunlight becomes optional instead of essential, so this would be good
01:12 hmmmm of brightness rather
01:12 sapier it's half we have now
01:12 hmmmm 4 of them are pretty much wasted
01:12 sapier 2 and those will still be wasted
01:12 hmmmm why you'd need 16 levels of light for deciding where mobs spawn is beyond me... why can't you do the same with 8
01:13 paramat 8 levels is good enough
01:13 sapier so you have 6 levels only
01:13 paramat for plant spawning too, 4 would be fine
01:13 hmmmm lemme call up my buddy who's an expert at lighting
01:14 sapier no they wouldn't it's like ohhh seee rendering my screen is slow lets draw everything black only to get it more fast
01:14 hmmmm lol
01:14 hmmmm what are you complaining about.
01:14 sapier basicaly you diminish mods making decisions based uppon day night cycle
01:15 sapier as well as artificial lighting
01:15 hmmmm the only noticable difference here is that you'd only be able to choose between 8 levels of light instead of 16
01:15 shadowzone joined #minetest-dev
01:15 sapier 8 is as good as 640kb are enough memory for any application ever beeing programmed
01:15 sapier and it's still 6 levels not 8
01:16 hmmmm that's like saying "there are 254 shades of gray"
01:16 hmmmm "not 256"
01:16 sapier why don't we just switch to monochrom mode we'd never have to cope with colors ;-)
01:16 paramat 6 is more than enough for a rough light level
01:16 sapier no it's not
01:16 hmmmm also keep in mind this is a rough light level estimate
01:17 hmmmm to get a more accurate light level it'd be a bit slower
01:17 hmmmm but possible
01:18 sapier if you get at least a two digit percentage fps increase by doing this I'd think about it but if it's only 0.5 forget it
01:18 hmmmm what about all the other advantages
01:18 paramat also, i don't see coloured light as a priority, if there's a gain from not implementing that i would choose to not have it
01:18 sapier I see no other advantages
01:18 hmmmm truecolor lighting
01:18 sapier for me it's just rendering some way to spawn mobs way less conveniant then before
01:18 hmmmm indefinite light spread distance
01:19 sapier if I'd get light color per node too I'd have at least another benefit do i get this information?
01:19 hmmmm yes
01:19 sapier so I can ask per node brightness as well as color? and this ain't horribly slow?
01:20 hmmmm best part is, if the node you're querying happens to be a light source, you can do an O(1) lookup of the brightness/color :)
01:20 hmmmm color is just a function of brightness
01:20 hmmmm rather other way around
01:20 sapier for what I know most nodes aren't light sources so don't tell optimized cases not happening very often ;-)
01:21 sapier usually next light source is quite far away
01:21 paramat i don't consider mob spawning a priority importance in minetest compared to general lighting, sorry =)
01:21 sapier paramat as everyone does that's why mobs suffer that much
01:22 sapier and mob spwaning is by far the most cpu consuming part so if you make any part of it slower it's gonna cause a huge penalty
01:22 VargaD_ joined #minetest-dev
01:22 hmmmm how is mob spawning so cpu consuming
01:23 sapier because you have to check a lot of nodes around in regular intervals
01:23 sapier light is one of the most time consuming things but checking for node types isn't much faster if it's not a single node only you have to check
01:24 paramat mob spawn/kill seems only an occasionally done thing so okay to to have a slower light check. just check less often
01:24 sapier e.g. if you wanna spawn a fish you need to make sure there's enough water around
01:24 sapier no it's not ocassional if you have about 20 different mobs
01:25 sapier even if you only do this once per 60 seconds
01:25 sapier most time you don't find a valid location for the first time
01:25 sapier I'd guess about 5-10 tries to find a suitable location
01:26 sapier if you wanna keep population stable you don't spawn a single mob only so you're doing this more then once per spawn event
01:27 sapier 20*7.5*2
01:27 sapier and the 7.5 is only true on surface, to find a suitable location below ground you often need way more tries
01:27 paramat i guess we need to consider the strongest arguments against, mob checks is one, spawning every plant by light level is overkill IMO so not important (sorry Vanessa), any others?
01:27 sapier of course that count happens for about each mapblock
01:28 VanessaE paramat: mesecons.
01:28 paramat ah lght sensors
01:28 paramat *light
01:28 sapier paramat if you find a working faster way we can think about it but by now everyone claimed it's bad but noone did find better
01:29 sapier I once tried spawning on mapgen only but ppl aren't happy if mobs don't regenerate
01:30 paramat to be clear i'm playing devil's advocate a little, i'm actually undecided but think hmmmmm's idea should be seriously considered
01:31 sapier I do consider it but only if it provides really good benefit, I'd not accept this for a 1fps increase
01:32 sapier and if those colors he suggests can't be used because reading a single nodes color is 100 times more expensive then reading current light level it's basicaly useless for mods anyway
01:35 shadowzone joined #minetest-dev
01:42 kahrl sapier, why not do only 1 spawn attempt per mapblock but if successful, spawn a pack instead of a single mob
01:43 sapier any suggestions how to spawn at a matching location at once?
01:43 Megaf_ joined #minetest-dev
01:44 sapier I already use spawn eggs doing the spawning but they still need to find locations for different mobs
01:44 sapier each spawner spawns all possible mobs distributing cpu time across them
01:45 kahrl for i = 1..rand(1,4) { pos = original pos + v3s16(rand(-3,3),rand(-1,1),rand(-3,3)); if pos is a suitable spawn location { spawn mob at pos }}
01:45 kahrl something like that?
01:45 sapier and how do you expect that random pos to match immediatly?
01:46 kahrl since you already checked the original position, the new position is more likely to be valid
01:46 sapier why?
01:46 kahrl because if the original position is dark then the new one will be too most likely
01:46 kahrl replace "dark" with "water" or whatever
01:46 MinerDad joined #minetest-dev
01:47 sapier I see no reason for this to be true in generic case
01:47 sapier if some position is stone why should next position be stone too?
01:47 kahrl because noise is continuous
01:47 sapier it'd be more likely to check for height above ground
01:48 sapier but It's useless to create a specialized spawner for every single mob I once had it it just didn't work so I need generic spawning
01:48 sapier and making it more likely always has to make assumptions which may or may not be true
01:49 sapier e.g. in vanessae's heavyly modified worls not even noise continuity is correct
01:50 sapier and even if there's a way to improve hit chances it's not gonna compensate a 100 times slower light calculation in situations where you don't find a single suiteable position and still have to try
01:51 kahrl if you don't find a position, don't spawn a mob
01:51 kahrl on first try*
01:51 kahrl simple as that
01:51 sapier and then?
01:51 sapier not spawn any mob at all?
01:51 sapier there's always a second third .. try
01:52 kahrl not in this spawn event
01:52 kahrl perhaps the next one will be successful
01:52 sapier which is already configurable and will cause drastically less mobs to be spawned in total
01:52 paramat i don't see mesecons light sensors being particularly important either (with apologies to the authors/users)
01:52 VanessaE so what you're really saying is mods aren't important at all.
01:53 sapier in worst case (lots of different mobs) you won't ever get a certain mob because a block is never active long enough to even try to spawn it
01:53 kahrl personally I think guaranteeing exactly one mob of each type being spawned per event is pretty boring
01:53 kahrl too predictable
01:53 sapier that's not a new issue it's there right now too but making spawning slower causes it to be way more of a problem
01:53 sapier I don't do this karl
01:53 sapier I try to spawn x mobs of one type
01:54 sapier if I have cpu time left in this spawn event
01:54 sapier if there's not time left nothing is spawned at all
01:54 kahrl ah, okay
01:55 sapier so if spawning becomes more time consuming overall mob spawn chance is reduced
01:55 sapier that's why I'm oposing to making some heavyly used function drastically slower
01:56 kahrl but for some reason MC can do a spawning cycle every tick (i.e. 20 per second) without completely locking up the CPU, which is why I'm wondering why it's so much more expensive in mobf
01:56 sapier and at night for example light checking uses almost full cpu time
01:57 sapier I don't lock up cpu too
01:57 sapier problem ain't mobf but the way minetest calculates light
01:58 sapier for mobf it's just reading a value that should be there
01:58 kahrl I mean they are doing 1200x as many spawn cycles than mobf
01:58 sapier I don't have any knowledge about minetest recalculating this each step
01:58 kahrl if the default interval is 60s as you said
01:58 kahrl s/than/as
01:58 sapier if e.g. minetest did recalculate light in regular intervals instead of each step you could save a lot of time too
01:59 sapier interval depends on mob
01:59 Wayward_One ShadowNinja, just finished running minetest through valgrind's massif tool, but i have no idea how to read the results lol. should i pastebin the results here...?
01:59 sapier there are mobs with 300 or more too
01:59 sapier my spawning mechanism is highly configurable
02:00 kahrl oh right, in MC the "once per tick" is only for hostile mobs
02:00 kahrl other mobs have an interval of 20s afaik
02:00 sapier I don't know how much about mc
02:00 sapier well as I said I have some way less then this
02:02 sapier still this is already an open issue so making it even more slow is wrong direction ;-)
02:03 kahrl well this is the algorithm pretty much if you want to know: http://minecraft.gamepedia.com/Spawn#Mob_spawning
02:04 sapier well I'd be glad if I could spawn in 240x240 range
02:04 sapier usually I can only spawn in 32x32
02:05 sapier because everything else is out of activity range
02:05 kahrl yeah that's a big difference too
02:05 sapier spawning a entity just to be unloaded is useless
02:05 sapier and causes lots of trouble
02:06 sapier 128 blocks activity range is about 4 times as much as we have
02:06 sapier it'd make spawning way more easy if we did have that range
02:07 kahrl I'm not sure all of those count as active
02:07 kahrl could be the case those mobs just spawn and don't move or do anything until you get nearer
02:08 sapier "However, hostile mobs (and some others) that move farther than 128 blocks from the nearest player will soon despawn" I'd understand this as similar concept then our activity range
02:08 sapier well they have different activity ranges for different mobs so it's not exactly same
02:08 kahrl not completely the same
02:08 kahrl they are not saved to the mapblock/chunk (hostile mobs, anyway)
02:09 sapier true
02:09 sapier but I don't think this is an issue for us
02:09 DuDraig joined #minetest-dev
02:10 sapier why do we have a memory leak in mapblock?
02:10 kahrl huh?
02:10 sapier nodemetalist seems not to be freed correct
02:10 kahrl ohh.. I thought that was fixed
02:10 kahrl but have imagined that
02:10 kahrl must have*
02:11 sapier well valgrind says it's not fixed ;-)
02:11 kahrl yeah, I saw that in valgrind ages ago
02:11 kahrl wonder why Zeno never noticed it even though he valgrinded a lot
02:12 sapier and particle spawners are still a mess ... not sure how they get lost
02:12 sapier ahh
02:12 sapier ok the add function doesn't even check if it already exists ... could be a chance to loose something
02:13 Wayward_One speaking of valgrind, i just ran mt through massif, and i'm not sure what to do with the output, or if it's even needed still
02:17 sapier well if you're looking for a memory leak valgrind would be more helpfull then massif
02:17 paramat left #minetest-dev
02:19 Wayward_One hmm... SN suggested massif on github, so that's what i used lol
02:19 sapier hmm well post the output maybe he knows where to look at :-)
02:19 sapier heap profiler usually is required if it's not a real leak
02:22 Wayward_One ok, here it is: http://pastebin.com/jamrtjsj
02:43 sapier left #minetest-dev
03:00 Miner_48er joined #minetest-dev
03:02 Tablet_One joined #minetest-dev
03:33 Zeno` joined #minetest-dev
03:53 * kahrl wonders what the deal with #1505 was
03:53 ShadowBot https://github.com/minetest/minetest/issues/1505 -- Update to SQLite 3.8.5 by SmallJoker
03:53 kahrl why was the bundled sqlite neither updated nor removed?
04:00 Miner_48er what updates are missing from it?
04:01 kahrl the one we're bundling is several years old
04:01 kahrl from 2011 to be exact
04:02 Zeno` Isn't it because of potential compatibility problems with LuaJIT?
04:03 kahrl does sqlite interact with LuaJIT in any meaningful way?
04:03 Zeno` lol
04:03 Zeno` of course not. I misread :)
04:04 Zeno` bundled sqlite not updated... no idea why not
04:05 kahrl SN discourages using it for this reason: http://irc.minetest.ru/minet​est-dev/2014-07-20#i_3823030
04:05 kahrl (but not everyone knows, as the discussion at that link shows)
04:06 Zeno` hmm
04:06 Zeno` not really sure how updating the bundled version can hurt though, even though I see SN's point.
04:06 kahrl I think we should update it for now, we can still remove it
04:07 Zeno` yeah, that's what I mean
04:08 hmmmm +1 for updating bundled sqlite
04:11 kahrl https://github.com/kahrl/minetest/commit/​dc90dd1d051ba62789df4224f92dfe47c4af75d7
04:11 kahrl will push ^ in a few minutes then
04:37 MinerDad joined #minetest-dev
04:42 hmmmm hmm
04:42 hmmmm paramat, i think i see the problem with the light
04:44 hmmmm nope, i know *exactly* what the issue is
04:44 hmmmm grr
04:45 hmmmm this is tough
04:47 hmmmm those ores not lighting up completely are in a part of a cave carved into the upper bordering block of the chunk directly below the one the ore exists in
04:47 hmmmm they never git hit by calcLighting()
04:47 hmmmm because I don't pass that upper border plane of blocks to calcLighting since that needs to be the overtop for sunlight propogation
04:48 hmmmm so if you calcLighting the entire full area, you'll get complete darkness because the overtop will never exist since it's outside of the vmanip
04:48 hmmmm but the ores will light up correctly
04:57 hmmmm so technically the ore has a param1 of 0, it's just that the mesh making code takes the light value of the content instead of the param1 if it's a light source
05:00 MinerDad joined #minetest-dev
05:01 MinerDad joined #minetest-dev
05:40 paramat joined #minetest-dev
05:40 paramat hmmmm i'm not so sure
05:41 paramat in my mapgen https://github.com/paramat/noisegrid every light source has the problem, where-ever it is within a mapchunk, above or below sea level
05:43 paramat if you disable the ABMs that spread the light you can see. lights in road tunnel roofs and luxore in fissures below ground
05:44 paramat the 'spread light' ABMs are in functions.lua
05:45 hmmmm paramat, try it yourself.
05:45 hmmmm change calc_lighting to calculate the entire voxelmanip area, not just the central chunk
05:45 hmmmm no sunlight but your ores sure will work
05:46 paramat ah okay perhaps i misunderstood
05:47 paramat it sounded like you were saying the only affected nodes were in particular parts of a mapchunk, which is untrue
05:50 paramat will try
06:07 paramat i edited the mod to have vm:calc_lighting({x=minp.x-16, y=minp.y-16, z=minp.z-16},{x=maxp.x+16, y=maxp.y+16, z=maxp.z+16}) but still doesn't work
06:08 paramat landscape is dark with occasional light patches
06:10 paramat is it because i have 'vm:set_lighting({day=0, night=0})' just before calc_lighting?
06:10 paramat ^ that seems to be essential for lua mapgen lighting to work properly
06:10 hmmmm no, but it's recommended that you set mapgen flags to nolight instead of zeroing the light out
06:11 hmmmm saves some execution time by doing less work
06:12 paramat okay will do in future, but that shouldn't make a difference?
06:12 hmmmm nope, it shouldn't
06:13 paramat i can confirm every light soure node in every possible position in a mapchunk is still buggy
06:13 paramat *source
06:13 hmmmm by "is still buggy", what do you mean exactly
06:13 hmmmm like what was happening with the ore in the screenshot you pasted or what?
06:13 paramat yeah
06:14 paramat light source node looks bright but light doesnt spread more than say 0.5 nodes
06:14 selat joined #minetest-dev
06:14 hmmmm i'll have to check it out but i think something might be going wrong with the mod itself because the code being executed is identical to internal mapgen code
06:15 paramat this bug happens in several of my mapgens, could be my way of coding i guess
06:26 hmmmm hey paramat, i was looking at your mapgen a little closer and i noticed that in the definition of your ore you don't have light_propgates = true
06:26 hmmmm that could be the issue here
06:26 paramat oh man i'll try
06:27 paramat okay for singlenode mapgens i will use minetest.set_mapgen_params({mgname="singlenode", flags="nolight"})
06:28 paramat i got into the habit of 'vm:set_lighting({day=0, night=0})' because my earlier mapgens created a layer above a normal v6 world
06:29 paramat where that is essential
06:30 paramat .. to set no light only in the mapchunks i was generating
06:32 hmmmm yeah I think it would be a huge problem if you don't set your light to propagate because your mapgen would actually have the same problem if you tried the old calcLighting()
06:33 paramat paramtype = "light" is in torch and lava definitions, that sets light to propagate
06:37 paramat phew it's fixed, thanks
06:37 paramat big relief
06:38 paramat one less bug for you to tackle
06:38 leat joined #minetest-dev
06:44 hmmmm hmm.. VoxelManipulator::spreadLight() doesn't have the problem i was explaining earlier because it doesn't respect the specified area boundaries, it'd just try to propogate the light 'upstrairs' and if it fails (blows an InvalidPositionException) just continues on
06:44 hmmmm but predictably it misses out on light sources in the overtop
06:46 paramat when originally creating my glowing nodes i must have not realised the importance of 'paramtype = "light"' and left that out, despite it being in the torch definition
06:46 hmmmm I can fix your river light problem, the V7 caves, and the ore light issue
06:49 paramat great. yes river water at y = 47 is dark
06:51 paramat i will add a note to lua-api.txt about setting paramtype = "light" for light sources
06:53 paramat lua-api.txt was just beginning to look good and readable, now it's in horrible MD format
06:53 hmmmm i don't think the md format is too horrible
06:53 hmmmm it reads mostly like regular text
06:58 paramat guess it's a personal thing, i am very visually sensitive and prefer simplicity, i get visually overwhelmed easily
06:58 hmmmm ahhh the v5 overtop thing
06:58 hmmmm hrmmmmmm
06:59 hmmmm i know how to solve this
07:03 T4im joined #minetest-dev
07:05 hmmmm haha
07:05 hmmmm dungeons really wreak havoc on mapgens
07:07 hmmmm awesome!  it works perfectly
07:16 paramat https://cdn.mediacru.sh/I/I4nkyaIHgODw.png 'levels' mod with a 1kn spiky tower
07:17 hmmmm cool stuff
07:17 hmmmm i'm going to work on sunlight producing shadows that fade out rather than the opposite
07:18 hmmmm i am aware that "fixLight()" would break this effect but in the common case it'd work as intended
07:20 paramat shadow decay yes please
07:21 paramat https://cdn.mediacru.sh/-/-k6m-ogUBmkF.png small spike nicely merging with nearby terrain
07:21 hmmmm do they normally merge?
07:27 paramat i wasn't expecting the spike to melt into the terrain like that
07:31 paramat it seems the spikes have a cylindrical volume around them which increases the node 'densities', and so inflate any nearby terrain causing a merge ..
07:32 hmmmm alright i sufficiently tested this BS
07:40 hmmmm :)!!!!! https://github.com/minetest/minetest/commi​t/54713cbb475f9dcf5b59dd3d0b0dc52cf62d25e2
07:43 chchjesus joined #minetest-dev
07:44 paramat good work, very productive night
07:46 paramat will test this later
08:00 chchjesus joined #minetest-dev
08:09 paramat left #minetest-dev
08:09 leat joined #minetest-dev
08:12 hmmmm wooh
08:12 hmmmm i just cleared like 7 issues
08:13 Calinou joined #minetest-dev
08:24 chchjesus neat!
08:24 chchjesus hmmmm++
08:25 hmmmm :)
08:25 hmmmm https://github.com/minetest/minetest/commi​t/ef8ed5d127f2c698586efdfd254c8e5c7ba66f19
08:25 hmmmm https://github.com/minetest/minetest/commi​t/8eb9cebdd058c7df0c1735cd083f09d962c7bb84
08:30 hmmmm https://github.com/minetest/minetest/commi​t/6fdb32361a01ed385b36f941f4ad0d7e32ea288d
08:31 hmmmm oh shoot, that last one is going to change the protocol version, isn't it
08:31 selat joined #minetest-dev
08:31 hmmmm well it's a good time for that anyway
08:32 Hunterz joined #minetest-dev
08:32 hmmmm actually nevermind, it never gets serialized
08:33 Calinou “nonsense”
08:33 Calinou I agree it was too game-specific, but respect other developers please
08:33 hmmmm he doesn't respect any of us
08:34 hmmmm i don't see why i should afford him any respect.  and none of that "be the bigger man" stuff.
08:59 chchjesus hmmmm: Who?
09:08 Krock joined #minetest-dev
09:21 kilbith joined #minetest-dev
09:22 nore joined #minetest-dev
09:47 ImQ009 joined #minetest-dev
09:56 ImQ009 joined #minetest-dev
10:27 jluc joined #minetest-dev
10:52 Zeno` joined #minetest-dev
10:54 jin_xi joined #minetest-dev
11:18 roniz joined #minetest-dev
12:16 Ritchie joined #minetest-dev
12:38 kilbith joined #minetest-dev
13:43 ImQ009 joined #minetest-dev
13:44 Zeno` joined #minetest-dev
13:53 Wayward_One joined #minetest-dev
13:59 alexxs joined #minetest-dev
14:01 roniz joined #minetest-dev
14:01 PilzAdam joined #minetest-dev
14:08 ImQ009 joined #minetest-dev
14:20 Zeno` PilzAdam, Some of the aliases in the alias.lua files are not there for backwards compatibility (e.g. STSword), so putting them in legacy.lua is wrong.
14:20 Zeno` What are they in there for?
14:21 PilzAdam the /giveme command
14:25 Wayward_One joined #minetest-dev
14:44 rubenwardy joined #minetest-dev
14:49 roniz joined #minetest-dev
14:58 Zeno` I think version numbers (of the engine) should be available to mods
14:58 Zeno` This is how every other engine/lib in the world works
14:59 Zeno` engine/game/lib
14:59 Zeno` If other software did not allow querying of the version the whole makefile/cmake/etc/etc would fall apart and be useless
15:00 Zeno` Even minetest queries the OpenGL version
15:23 ImQ009 joined #minetest-dev
15:34 celeron55 Zeno`: it's a political issue; i don't want to centralize minetest development in a way that breaks forks; everything that has a version has a central authority who decides what goes to which version
15:34 celeron55 s/everything/every API/g
15:35 celeron55 cutting off competition by political means is always a very bad idea for general progress
15:35 celeron55 and you can't even seriously disagree with that
15:35 Zeno` no, I can't
15:36 Zeno` that makes sense. Thanks
15:37 sapier joined #minetest-dev
15:38 sapier https://github.com/minetest/minetest/pull/2043 merging in a few minutes (Android only change)
15:39 celeron55 Zeno`: currently minetest's modding api and mods are such that anyone can fork mientest and continue development to a better way without having to do *any* tricks whatsoever to maintain compatibility
15:40 celeron55 i belive this forces people including me to "keep it real"
15:40 Zeno` yep, I understand the argument now that you've made it clear
15:41 celeron55 also, as you mentioned opengl, it actually partly does the same: no program ever checks whether it supports the drivers by checking the opengl version number; they check if the particular extensions are supported that they need (and the extensions can be added by anyone and then later adopted by others)
15:41 celeron55 (or, they can, but it's bad behavior)
15:42 celeron55 the version just gives a general idea
15:42 kilbith joined #minetest-dev
15:44 Calinou joined #minetest-dev
15:51 sapier on opengl the version number is almost useless as most features are "optional"
15:53 selat joined #minetest-dev
15:54 hmmmm joined #minetest-dev
16:06 sapier ShadowNinja if I ever meet you in person I'm gonna kick your ass this is the 3 time you break the android menu by doing some nonsense cleanup without testing
16:07 sapier there's been a reason why it was a separate menu, this way you could test it on pc where debugging is way more easy then on android devices
16:14 sapier And who the hell tells simple menu is android only?!
16:15 sapier I never seen a rule pc menus have to be overloaded and complex ;-P
16:19 DFeniks joined #minetest-dev
16:29 puhfa joined #minetest-dev
16:53 roniz joined #minetest-dev
16:54 Zeno` sapier, I have a cunning plant
16:54 Zeno` err plan
16:55 Zeno` Add comments to sections that sections of code that are the for a reason but maybe not obvious :p
16:55 sapier I can't do more then telling him this in person
16:55 sapier if someone doesn't understand it this way more text wont help
16:55 sapier ls
16:55 Zeno` You can't add a comment in the code?
16:56 sapier we're talking about a full file not some part of code
16:58 Zeno` so?
16:58 Zeno` Is a file not some part of code? :p
16:58 sapier well is there a line in game.cpp about this file beeing required?
16:58 Zeno` no idea off the top of my head. Is there?
16:59 sapier have a look at it
17:01 ImQ009 joined #minetest-dev
17:02 Zeno` not really sure what I'm looking for. The pause menu?
17:02 PilzAdam joined #minetest-dev
17:04 Zeno` are we talking about https://github.com/minetest/minetest/commi​t/c4e393deea4f1a6d242a3fdf392c463ed5a3b58d ?
17:04 sapier yes
17:04 sapier which is a non sense change as the simple menu is not by defininition android only
17:06 Zeno` hmm, fair enough
17:06 sapier so now we have a perfectly fine simplified menu which can only be used if you claim to run on android :-(
17:08 Zeno` yes :(
17:08 Zeno` Anyway I must sleep
17:08 sapier good night
17:14 kaeza joined #minetest-dev
17:44 Lugal joined #minetest-dev
18:01 Wuzzy joined #minetest-dev
18:02 Wuzzy Hi there. I wonder if something in the auth.txt format has changed lately significantly so that it breaks 0.4.11 worlds
18:03 Krock a timestamp has been added but that shouldn't be a problem
18:05 Calinou apparently it is for Wuzzy
18:05 Calinou <Gael-de-Sailly> 11:51:45: ERROR[main]: /usr/share/minetest/builtin/game/auth.lua:48: Invalid line in auth.txt: "singleplayer::"
18:05 Wuzzy My Tutorial World does not load in 663e42ca… but it loads in 0.4.11.
18:06 Wuzzy I shall post error output soon
18:07 Wuzzy Here it is: http://lpaste.net/raw/117753
18:07 Wuzzy This is the error I get when I try to load Tutorial World in 663e42ca…
18:08 rubenwardy https://github.com/minetest/minetest/​blob/master/builtin/game/auth.lua#L48
18:09 rubenwardy It's because there is no password specified, it seems
18:09 rubenwardy Did it work after last_login was added?
18:09 Wuzzy what is this?
18:10 rubenwardy what?
18:10 Wuzzy oh, for you, here is the content of auth.txt of Tutorial World
18:10 Wuzzy “singleplayer::”
18:10 rubenwardy yes
18:10 Wuzzy that's all
18:10 rubenwardy singleplayer:password:privs:last_login
18:10 Wuzzy I tried deleting auth.txt and reload
18:10 Wuzzy it loaded again o_O
18:11 rubenwardy It is because there is no password string there.
18:11 Wuzzy and generated a new auth.txt
18:11 PilzAdam its probably because string.split() is used instead of match()
18:11 Wuzzy Generated auth.txt is “singleplayer::interact,shout:1420398524”
18:11 Wuzzy plus a line break
18:11 rubenwardy And does that work?
18:11 Wuzzy yes
18:12 Wuzzy But why did “singleplayer::” ever work in 0.4.11 in the first place? xD
18:13 Wuzzy anyways, I think I provided enough proof to show that 0.4.11 and older worlds are currently not compatible with the bleeding edge
18:15 rubenwardy https://github.com/minetest/minetest/commi​t/ab55da589c27e65e54956b32a1550e21169447ae
18:15 rubenwardy That's the problem
18:15 rubenwardy Changed string:split
18:15 rubenwardy * probably the problem
18:15 PilzAdam it seems that string.split() with include_empty does not return an empty string after the last delimiter
18:15 PilzAdam ^ ShadowNinja
18:16 Wuzzy ok. Say my name if you fixed the bug so I can pull it and test it on Tutorial World
18:17 Gethiox joined #minetest-dev
18:19 ShadowNinja kaeza: ^
18:19 rubenwardy Lol
18:19 ShadowNinja sapier: Include things like this in your local tree: https://github.com/minetest/minetest/commi​t/21ee434832126f288c58f5a9cd2a3b509946319c
18:20 ShadowNinja sapier: Or just modify init.lua.  It's a temporary change after all.
18:20 ShadowNinja And my commit was definitely an improvement, seing as you added that back with two lines of code instead of copying the whole file..
18:21 sapier no I will not do this because I already know how often this gonna be merged
18:21 sapier especially as your change is crap
18:21 sapier you made something not beeing android specific artificially android specific
18:22 sapier there'*s not a single reason why a simple menu shouldn't be used on pc mac or any other os
18:23 ShadowNinja sapier: init_android.lua doesn't suggest Android-specific to you?  Because it sure does to me.
18:24 sapier well if you did one time read what you change you'd have relaized that filename is wrong and not content
18:24 ShadowNinja sapier: And I agree, a lot of Android-specific things shouldn't depend on that particular OS.
18:24 ShadowNinja But I didn't write the Android stuff.
18:25 PilzAdam ShadowNinja, I agree with sapier, init_android.lua should have just been renamed to init_simple.lua or so
18:25 sapier tell me where I used ANDROID where it ain't required? because I specially did look at which features are specific to android and which could be used elsewhere
18:25 ShadowNinja sapier: You can change it to use simple_menu = true/false in minetest.txt.
18:25 ShadowNinja sapier: Please make it false on Android though.
18:25 rubenwardy s/minetest.txt/minetest.conf ?
18:25 sapier ShadowNinja: because of what reason? we already have a setting where you can enable any menu not only those provided in builtin
18:26 ShadowNinja PilzAdam: Have you seen the old init_android.lua?  It was just `cp init.lua init_android.lua` with minor modifications.
18:26 ShadowNinja PilzAdam: Not only that, but it bypassed the builtin init.lua, breaking things like print() and the locale.
18:26 sapier ShadowNinja: true because simple menu did provide similar things
18:26 ShadowNinja rubenwardy: Yes.
18:26 PilzAdam ah, didn't see that
18:26 rubenwardy ok
18:27 sapier new one will fake android switch wich is just crap but best without resplitting it again
18:27 PilzAdam ShadowNinja, there should still be 2 different init_*.lua, since you can choose your menu script in minetest.conf
18:27 PilzAdam no need to check any OS for that
18:27 ShadowNinja sapier: Please make a PR, or at least post a patch here, before changing ti further.
18:28 sapier I already changed it so I can fix the bugs in there again if you don't break this a 4th time I don't intend do change anything there
18:28 PilzAdam ShadowNinja, maybe move the duplicated parts to a init_all.lua or so?
18:28 ShadowNinja PilzAdam: Just have simple_menu = true/false or menu_type = normal/simple in minetest.conf instead, no need to change the file loaded.
18:29 sapier ShadowNinja: NO
18:29 sapier why ANOTHER menu config setting
18:29 PilzAdam why provide extra settings for functionality that is already provided?
18:29 sapier next time we have a new menu for tablets then we add tablet_menu= true false?
18:29 ShadowNinja sapier: It was broken to begin with, and http://xkcd.com/1172/
18:29 PilzAdam add a comment that you can point it to the simple.lua file, thats enough
18:30 ShadowNinja PilzAdam: that's a lot simpler than telling users to set the script path to a different file.
18:30 hmmmm yeehaw...
18:31 sapier still the script path is already there and provides the required functionality
18:31 ShadowNinja sapier: Or menu_type = tablet, or better yet just make the menu adapt by itself.
18:31 sapier AND script path is the better way doing it because it enables total conversions to write their own menu
18:31 sapier why two settings for same thing?
18:32 sapier still if you want to ADD your nonsense menu_type, do it but don't expect me to consider it as a sane solution
18:32 hmmmm maybe there should be a device profile setting that's a setting and gets autodetected if not present
18:32 ShadowNinja sapier: Yes, but that's only intended for anvanced users that want to replace the whole menu.  It's a much more complicated setting than what I'm proposing.
18:32 hmmmm device_type = tablet, device_type = smartphone, etc.. in addition to setting the menu stuff it'll load performance profiles to enable/disable certain things
18:32 ShadowNinja IMO wo shouldn't have two menu styles in the first place.
18:32 hmmmm I think it's a good idea
18:32 ShadowNinja we*
18:33 sapier same as last time as long as you don't break things I don't really care ... sadly you did it again
18:33 hmmmm the alternative is to have one menu that works with both mobile and desktop and lots of things that work for desktop don't work for mobile
18:33 sapier that's not gonna work
18:33 hmmmm this is how you get firefox-type fuckups
18:33 ShadowNinja hmmmm: Some smartphones are really powerfull, some are weak, some have big screens, others tiny...
18:33 hmmmm say no to australis for minetest
18:33 sapier range of screen sizes and dpi is just to big
18:33 VanessaE jesus fuck.  stop arguing and just fix the problem, guys
18:34 roniz joined #minetest-dev
18:34 VanessaE two menu files.  a config option to select which one is used for the platform in question.  default to the "complex"/PC one if no config option is specified.
18:34 VanessaE it does NOT need to be more complicated than that.
18:34 rubenwardy "Jesus fuck"
18:34 hmmmm what, I say that sometimes
18:34 Wuzzy by the way, how is “singleplayer::” in auth.txt supposed to work/what does it mean?
18:35 ShadowNinja hmmmm: The desktop menu works fine on Android AFAIK, and I prefer it because the Android(/"simple") one only lets you manage one world.
18:35 hmmmm VanessaE:  I think it should autodetect if not present
18:35 sapier we already have two menus and default to the complex one
18:35 PilzAdam ShadowNinja, kaeza, about that auth.txt thing: I just tested it, and ab55da589c27e65e54956b32a1550e21169447ae definetly broke the old behaviour that returned an additional "" after the last ":"
18:35 hmmmm ShadowNinja, does that hold true for lower-DPI devices?
18:35 VanessaE hmmmm: I'd prefer that too but as we've seen in the past, auto-detect isn't as graceful as one would like it to be.
18:35 hmmmm it should be pretty easy to detect mobile
18:35 hmmmm and reliable
18:35 ShadowNinja Wuzzy: user="singleplayer", password="", privs = {}
18:35 sapier ShadowNinja: desktop menu doesn't work at all at low screensize android devices
18:36 VanessaE hmmmm: that's the keyword, "should" :-)
18:36 ShadowNinja hmmmm: It will probably be hard to use, but the Android menu is the same size IIRC.
18:36 sapier hmmmm I agree it "should" but in practice it's almost impossible to always find correct settings automaticaly
18:36 ShadowNinja hmmmm: (or at least very close)
18:36 PilzAdam Wuzzy, you could test your world with 86cfbc21da10e9984a1b9f8f2f5bf259fba5efb9 and then with ab55da589c27e65e54956b32a1550e21169447ae to confirm that the latter one broke it
18:36 VanessaE rubenwardy: that's a short form of "jesus fucking christ".
18:37 sapier ShadowNinja: no because of important buttons aren't visible on some low screen size devices
18:37 rubenwardy I believe that's called masturbation
18:37 VanessaE lol
18:37 hmmmm I always thought it was when you had a situation where you need to say "jesus christ" but you're super flabbergasted at whatever it is
18:37 Wuzzy ShadowNinja: Weird. That would mean no interact either. But I know in Tutorial World I amsolutely can interact with “singleplayer::” as auth.txt
18:37 Wuzzy PilzAdam: I am on my way
18:37 VanessaE hmmmm: indeed.
18:37 rubenwardy Wuzzy, default_privs in minetest.conf
18:38 hmmmm ugh
18:38 Wuzzy oh shit. This means I need to update.
18:38 hmmmm really hate typing
18:38 ShadowNinja Wuzzy: You get all privs that aren't give_to_singleplayer=false, even if they're not in auth.txt.
18:38 hmmmm ManualMapVoxelManipulator
18:38 sapier crap new ssl version doesn't work after cleaning all
18:38 hmmmm AbstractManualMapVoxelManipulatorManagerFactory
18:38 Wuzzy ShadowNinja, rubenwardy: WTF?
18:39 sapier << leaving to fix the ssl issue ... DONT break menu again!
18:39 Wuzzy You gave me 2 different answers
18:39 sapier left #minetest-dev
18:39 ShadowNinja Wuzzy: -> #minetest
18:39 hmmmm what's the most efficient way to break the menu?
18:39 rubenwardy oh
18:39 rubenwardy ShadowNinja is right
18:39 rubenwardy hmmmm: core = core / 0
18:39 ShadowNinja hmmmm: error() in init.lua
18:39 hmmmm :D
18:41 VanessaE stick a spurious comma somewhere ;)
18:41 VanessaE if you wanna both break it and be evil about it ;)
18:41 ShadowNinja hmmmm: Actually, running ./bin/minetest-noexist is even faster :-P
18:41 rubenwardy IMO, the menu is currently too techie and not enough gamie. Most games use buttons instead of tabs.https://jarime.files.wordpre​ss.com/2011/12/terraria6.png
18:42 rubenwardy But it doesn't matter that much
18:45 hmmmm https://github.com/kwolekr/minetest/commit​/10d24b48f387a642ceea85d3703748c46f34c78e
18:49 Miner_48er joined #minetest-dev
18:50 n4x joined #minetest-dev
18:50 Wuzzy PilzAdam: I tested it for both commits. It works in the first one but it fails in the second one.
18:51 PilzAdam q.e.d.
18:53 Wuzzy ok, just tell my name in chat when you fixed it yadda yadda. Or should I open an issue on GitHub?
18:53 ElectronLibre joined #minetest-dev
18:58 ShadowNinja #2046
18:58 ShadowBot https://github.com/minetest/minetest/issues/2046 -- Remove included SQLite3 by ShadowNinja
18:59 ShadowNinja I also wrote a version for JsonCpp, but I had trouble getting it to work (CMake couldn't find the include directory, but it found the library fine)
19:11 shadowzone joined #minetest-dev
20:21 MinetestForFun joined #minetest-dev
20:26 DFeniks joined #minetest-dev
20:38 ImQ009 joined #minetest-dev
20:38 Player_2 joined #minetest-dev
21:00 prozacgod joined #minetest-dev
21:09 Amaz joined #minetest-dev
21:10 zat joined #minetest-dev
21:22 ImQ009 joined #minetest-dev
21:25 ElectronLibre left #minetest-dev
21:35 ShadowNinja http://sprunge.us/ZVPa?diff
21:36 ShadowNinja Any objections?
21:36 hmmmm nope
21:36 sfan5 looks good
21:36 hmmmm probably should do the same thing for decorations though
21:41 ShadowNinja Alright, I'll do that.  I'll see if there's a make_redistration_storer or similar or make it though.
21:45 blaise joined #minetest-dev
22:00 cib0 joined #minetest-dev
22:02 blaise joined #minetest-dev
22:46 exio4 joined #minetest-dev
22:52 kaeza joined #minetest-dev
22:53 kaeza PilzAdam, hm?
22:54 PilzAdam kaeza, string.split(":", ":", true) should return {"", ""} instead of just {""}
23:06 kaeza PilzAdam, oops
23:06 kaeza PilzAdam, https://github.com/minetest/minetest/blob/m​aster/builtin/common/misc_helpers.lua#L181 --> s/len/len+1/
23:06 kaeza guess the test suite missed some cases...
23:08 MichaelRpdx joined #minetest-dev
23:11 kaeza ShadowNinja, https://github.com/minetest/minetest/pull/2047
23:19 paramat joined #minetest-dev
23:20 paramat hmmmm, https://github.com/minetest/minetes​t/issues/1727#issuecomment-68627007
23:21 younishd joined #minetest-dev
23:29 paramat any mod that uses lvm to add mapchunks to a v5/6/7 world has to use vm:set_lighting({day=0, night=0}) i'll test such a mod v. soon
23:35 paramat https://cloud.githubusercontent.com/assets/3686677​/5607999/557f6c48-946a-11e4-8c51-e8c93dafb629.png closeup
23:39 proller joined #minetest-dev

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