Time  Nick           Message
02:45 cg             https://github.com/minetest/minetest_game/pull/683
04:36 hmmmm          https://github.com/kwolekr/minetest/commit/b7d92ae861a0b15d0f40678da42b22e4d23503f6
04:36 hmmmm          PTAL
04:47 asl97          github diff sure isn't smart
04:49 cg             asl97 fixed
04:50 asl97          there is still the space/tab mix
04:51 cg             on #683?
04:51 ShadowBot      https://github.com/minetest/minetest/issues/683 -- Allow custom liquids to have drops by 0gb-us
04:51 cg             its all tab, god git hates me lol
04:51 asl97          why change the file from space to tab?
04:52 cg             why use space? i never do
04:54 cg             actual question, is there a rule about spaces or tab for the engine/ _game code?
04:54 asl97          yes there is
04:54 VanessaE       use tabs for primary formatting, indentation, etc, spaces to line stuff up after that
04:54 VanessaE       (like in a table)
04:54 asl97          http://dev.minetest.net/MinetestWiki:Style_Guide
04:54 cg             ok so thats what i do
04:57 asl97          cg: isn't it still the same?
04:57 asl97          if the file doesn't exist, the input should be nil
04:58 asl97          and then it throw(err)
04:58 hmmmm          anybody have anything about my commit?
04:59 VanessaE       hmmmm: only that it's another useful-looking feature.
04:59 VanessaE       but you already knew that :P
05:00 asl97          it's the pregenerate world thing isn't it?
05:00 hmmmm          yeah
05:00 hmmmm          I'm sure modders are going to find some other fantastic use for emerge_area() though
05:01 hmmmm          also I think this is a decent time to finally add a callback mechanism for block emerge completion
05:02 hmmmm          I've been thinking a lot about things, does it actually make sense to store objects in a block?
05:03 hmmmm          if I were doing minetest from scratch I'd have all objects stored in a separate database or at least section
05:03 asl97          getContainingChunk look nice,  maybe you could prove an api for it too
05:03 VanessaE       I would give them their own section of the map database
05:03 VanessaE       however, having two separate databases is better
05:03 hmmmm          right, minetest can still evolve
05:03 VanessaE       /clearobjects --> os.delete(object_db)  :)
05:03 hmmmm          yeah there's that advantage too
05:04 hmmmm          another thing I was envisioning was that mods can make queries to get "their" objects
05:05 hmmmm          instead of having to do that hacky workaround where they store object positions in a text file
05:05 VanessaE       now THAT could be useful
05:05 hmmmm          and then force load the blocks
05:05 hmmmm          I am always delighted by the creativity of modders though
05:05 VanessaE       don't you mean the abusiveness? ;)
05:05 hmmmm          yeah, abusiveness
05:05 hmmmm          I really wish they'd put that creativity/effort into making the engine better instead of hacking around it
05:06 hmmmm          minetest is NOT closed source
05:06 cg             but most find lua easy compared to c++
05:06 hmmmm          I find the verbosity of lua to be suffocating
05:07 VanessaE       verbosity?
05:07 hmmmm          yeah.. if that's a good way to put it
05:07 VanessaE       aside from lack of trinary operators, what else is missing?
05:07 VanessaE       er, ternary
05:07 hmmmm          well it's a culmination of all the little things I guess
05:07 hmmmm          the mandatory "end" statement for example
05:07 hmmmm          the fact that it's a word at all
05:08 VanessaE       ok I'll grant you that.
05:08 hmmmm          it just feels like something that ought to be small turns out to be much larger and wordier
05:08 hmmmm          also not sure about break, but there's no continue statement in lua from what I understand
05:08 hmmmm          this leads to loops that are always like..
05:08 hmmmm          if (blah) then if (blah2) then ( ... )
05:09 VanessaE       mm, true
05:09 cg             there is a break, but continue idk
05:09 hmmmm          you have more levels of indentation than seems necessary
05:09 VanessaE       no case() statement either, some to think of it
05:09 hmmmm          yeah
05:09 VanessaE       come*
05:09 hmmmm          ewgh
05:09 hmmmm          well nevermind this language babble, it's not particularily constructive
05:10 hmmmm          I see est is making nice progress on voxel area entities, that's exciting to see
05:21 cg             any way of having a selection/collision mesh?
05:22 VanessaE       collision meshes, unlikely, but selection meshes would be useful in some situations.
05:22 cg             players and models for entities is my thoughts
06:09 VanessaE       hmmmm: thoughts on the "make the map larger" conversation from earlier?
06:10 VanessaE       (I expect "fuck no, the whole idea sucks")
06:13 hmmmm          sum it up for me?
06:15 VanessaE       the map's X/Z coords (only) should be extended to u32 or u64, damn the Lua torpedoes.  imho, make new string-based hashing functions to replace the bitwise-based ones that currently return large-ish numbers (to avoid Lua's limits).  Maybe add a config switch and/or auto-detect if the map is of the larger variety and disable access to the old hash functions
06:16 VanessaE       embedded in that discussion was the question of how VAE's ought be stored.
06:16 VanessaE       (no resolution was reached there)
06:53 hmmmm          that's a horrible idea
06:54 hmmmm          i see no reason why we need to extend the map coordinates, that breaks all kinds of compatibility
06:55 VanessaE       ok.
06:59 VanessaE       it'll be needed sooner or later.
06:59 VanessaE       in either case, "almost infinite" and similar phrases need to be removed wherever they occur until then
07:24 red1           is   m_sectors a list of all sectors loaded?
09:18 asl97          cg went offline....
09:21 nrzkt          cg ?
09:22 asl97          [16:32:28] cg [~GP@204.111.255.5] has quit IRC: Quit: bye \o
09:24 nrzkt          and what is the problem with cg ?
09:24 Krock          oh yay, spreading IPs is always good
09:24 asl97          Krock: everyone should have gotten the ip :|
09:24 asl97          nrzkt: i was writing an benchmark as a respond his/her pm > https://github.com/minetest/minetest_game/pull/683#issuecomment-142540673
11:00 rubenwardy     the map size in MT is less than earth, it's not even a country
11:01 rubenwardy     It becomes limited if you want to make country maps etc
11:01 kilbith        there's no mountains of size of Himalaya either..
11:02 rubenwardy     and for MM server
11:02 rubenwardy     admittedly MT doesn't have the interest for that
11:03 rubenwardy     but big changes cause instability and bugs
11:04 asl97          does minetest or even minecraft scale well to those kind of size?  in fact, does the backend even scale that large?
11:04 rubenwardy     They've built the UK in MC
11:04 rubenwardy     from OS maps
11:04 rubenwardy     (ordinate surveys)
11:05 rubenwardy     MC is purportedly 4,000,000m
11:05 rubenwardy     ofc there's buggy areas at the edges
11:05 asl97          iirc, float point error are still a mess at those size
11:05 asl97          or whatever error it is
11:06 rubenwardy     My view is that a larger map could be needed/wanted, however it's not essential and other stuff is more important
11:06 kilbith        even bigger then UK : http://www.planetminecraft.com/project/the-recreation-of-the-earth-11500-scale/
11:06 rubenwardy     like fixing inventories, networks, client side mods, environmental sounds, etc
11:42 asl97          why does minetest.get_craft_recipe(*something invalid like air*) return {width = 0} instead of nil?
15:29 est31          hmmmm, remember to get rid of this https://github.com/kwolekr/minetest/commit/b7d92ae861a0b15d0f40678da42b22e4d23503f6#diff-93af8f0472f15bf128803754d689a4e2R775
15:31 est31          wow we really test the misc helpers at loadtime
15:31 est31          this is bad
15:31 hmmmm          yup, I did get rid of that, I uploaded a new version of that commit
15:32 hmmmm          well I just figured it'd be a nice idea to follow along with the other code in that file
15:32 hmmmm          can't hurt too much
15:32 est31          it impedes startup time
15:32 est31          yea, but it should probably be generally fixed
15:32 est31          e.g. put all the asserts and so on into another file
15:33 est31          string_to_area isnt documented
15:34 hmmmm          should it be?
15:34 est31          string_to_pos is
15:34 hmmmm          mm
15:35 est31          https://github.com/kwolekr/minetest/commit/dcf1c0baa50e26ac4aaaa1774117a37e0e3e4b7e#diff-c6d551e431c1fb79f5cf714da9b6c604R67
15:35 est31          some people wont like that
15:35 est31          they prefer if not p1 then
15:37 est31          string_to_area is only used in parse_range_str right?
15:38 nanepiwo       has anyone seen lightning glitches with v7 mapgens? I'm using paragenv7  and some regions away from spawn are very very dark
15:39 nanepiwo       might it also be a client problem?
15:39 eugd           does anyone know where in the code spawn coordinate is determined?
15:39 est31          hmmmm, the general problem I have with the emerge_area callback is that it doesnt give any guarantees
15:39 eugd           especially for singleplayer, i'd assume (servers will set player initial spawn, right?)
15:40 nanepiwo       eugd, to change it use set_static_spawnpoint
15:40 est31          you just call the area to be emerged, but it can be unloaded later
15:40 est31          also no guarantee when it will be loaded
15:40 est31          so people will still be forced to create voxelmanips
15:41 hmmmm          the purpose behind this is to pre-generate map, mostly
15:41 est31          perhaps it shouldn't be called then "emerge"
15:41 hmmmm          but it does exactly that
15:41 est31          "generate"?
15:42 T4im           wouldn't voxelmaniping an area do the same?
15:42 est31          hmmmm's commit would give a more lightweight alternative
15:43 est31          manips copy the whole content dont they
15:44 est31          also, it gives no indication when mapgen has finished
15:44 est31          e.g. if you want to emerge a certain area on your server you may want to shut it down when emerge is done so that you can restart it as a public server
15:44 est31          or so
15:49 T4im           ah, ok :)
15:50 est31          (note that the "also, it gives no indication when mapgen has finished" is a comment on hmmmm's commit and not the voxelmanip method. the voxelmanip method would allow better control in this regard)
15:51 hmmmm          voxelmanip would not generate the map at that point, i don't think
15:51 hmmmm          pretty sure if the block doesn't exist on disk it would create a blank placeholder block
15:52 T4im           btw, want me to add test_string_to_area() to coretest? that way you have it out of the way during startup
15:52 hmmmm          sure
15:52 hmmmm          in the function above there are also tests
15:52 hmmmm          it's just that i had to make this into a separate testing function because of the scope for temp variables
15:53 eugd           where is singleplayer spawn location determined? it seems to be a range several hundred blocks of 0 0 0
15:53 eugd           is it property of minetest_game?
15:53 hmmmm          it's random
15:59 est31          note that I dont have any real progress on VAEs in code, I only think right now how to do it
16:00 T4im           developing != coding ;)
16:00 est31          lol
16:00 est31          but you are right
16:01 est31          coders are the "fachinformatiker", developers are those who have studied it
16:01 eugd           re: VAEs, imo should not just slice up map
16:01 T4im           you could develop something on paper and send it to a bunch of programmers to code it down
16:02 eugd           should start by making map variable size and maybe shape (still rectangular but non-cube)
16:02 eugd           and then having multiple maps in environment
16:03 est31          the only real problem I face with VAEs is lighting
16:04 est31          our current lighting system is designed for a non-VAE world
16:04 eugd           imo lighting also should be removed from map
16:04 eugd           put in environment
16:04 est31          its stored and sent over the network inside the mapblocks,
16:05 eugd           having block 'light level' is one of the uglier parts of mc inheritance
16:05 est31          eugd, do you have a better idea for lighting?
16:05 eugd           not really
16:05 eugd           just to do it like any other graphics engine
16:05 eugd           divorce it from gameplay at base
16:06 hmmmm          I have a really simple way to do the sunlight
16:06 est31          ?
16:06 hmmmm          it could be a single dynamic light
16:06 eugd           and then if needed have blocks/nodes/entities query environment
16:06 hmmmm          that would improve the look of minetest x500 but it wouldn't offer a solution for light sources (huge problem)
16:07 est31          traditional engines load the whole map, not just parts of it
16:08 hmmmm          traditional games load up a single mesh for the entire world (or a significant portion of it) along with a static lightmap
16:09 hmmmm          we are essentially re-generating the lightmap each time a mesh is regenerated
16:09 hmmmm          except cheaply, because our lights are distributed along a regular grid of distances
16:09 hmmmm          so vertex lighting
16:10 hmmmm          another complicated idea I had was very carefully managing dynamic lights
16:10 hmmmm          if several light sources are in proximity, they could be combined
16:10 hmmmm          less significant lights could be culled out from the scene
16:10 hmmmm          etc.
16:11 VanessaE       isn't this the sort of thing shaders were designed for?
16:11 hmmmm          no
16:13 VanessaE       well pixel shaders are, for sure.
16:13 VanessaE       either way, seems to me the best idea is to have statically-stored/generated data in the map like we have now, and use shaders to actually render the lighting.
16:13 VanessaE       the GPU will always be faster than the CPU at this task.
16:15 VanessaE       i.e. ditch the CPU-managed "smooth" lighting we have now, that barely works as it is, and let the GPU handle it like it's designed to.
16:15 est31          VanessaE, sounds like you want to implement that :) ?
16:15 VanessaE       nope :)
16:15 hmmmm          lol
16:15 VanessaE       that's RBA's territory actually.
16:16 hmmmm          VanessaE, it's our job to store the lighting information
16:16 hmmmm          like I said, in normal games, this is stored as another texture
16:16 VanessaE       hmmmm: of course.  but not to *render* it (i.e. modifying vertex lighting values or whatever it is we do now)
16:16 hmmmm          there are dynamic lights but gpus only have a small number, like 4 or 8 of them, available on the screen at the same time
16:16 est31          we could in fact only store the lighting info at the edges of a mapblock
16:16 est31          then calculate the rest
16:17 hmmmm          est31, yea that was my idea at one point
16:17 hmmmm          it works
16:17 hmmmm          you only need to save 96 light values vs. 4096
16:17 eugd           i'd like to suggest again a fundamental change to engine in direction of facilitating VAEs
16:18 hmmmm          and the only time lighting is actually used is during mesh making (and checking light values at a point, for some mods)
16:18 eugd           that it becomes environment- rather than map- focused
16:18 est31          hmmmm, dont forget entities
16:18 hmmmm          ?
16:19 hmmmm          eugd:  I thought that was the plan all along, no?
16:19 est31          if you have an entity, it has the same light value as the block its "root" position is inside
16:19 eugd           i don't really know, probably not up to date
16:19 hmmmm          the map db would just be a convenient place to store it
16:19 hmmmm          est31:  oh yeah
16:19 eugd           entities should have their own maps
16:19 est31          made so that if you are in a dark cave, you don't shine like a torch :)
16:19 hmmmm          est31:  any suggestions for that? :p
16:19 eugd           right? as VAES
16:20 hmmmm          eugd, I think so yeah
16:20 eugd           i don't know efficiency issues with overhead for database stuff, if they'd actually have their own DBs
16:21 hmmmm          probably not too much tbh
16:21 est31          giving every VAE its own database? no, thats too laggy
16:21 est31          better store them in one big database
16:22 eugd           i thought would be very cool to give players own VAE space
16:22 eugd           for unique player avatars
16:23 eugd           what would cause lag in many database?
16:23 eugd           locking?
16:23 eugd           i see in code much concern about that
16:24 eugd           or is it just innate overhead stuff?
16:28 eugd           did i lose connection?
16:29 hmmmm          one feature at a time
16:29 eugd           do we have a current focus?
16:36 hmmmm          my focus is supposed to be client side modding
16:36 hmmmm          but i take a break in between to work on some smaller things that pop up
16:40 T4im           compiler complains about count being potentially uninit in l243/l276 btw
16:41 est31          T4im, about #2235 usually issues are only closed if the pr is merged
16:41 ShadowBot      https://github.com/minetest/minetest/issues/2235 -- Clarify radii and distance types in documentation
16:43 T4im           its superseded by that other issue :P https://github.com/minetest/minetest/issues/3192
16:44 hmmmm          okay how about now https://github.com/kwolekr/minetest/commit/68eef323d3bbcdf9c190df086a2ee5843d6d8083
16:46 est31          the queue had a maximum size?
16:46 est31          damn of course it was totally broken for the purposes I used it
16:47 eugd           what is core dev teams position on having variable map sizes and shapes? there is hearsay on forums that it is firmly rejected.
16:49 est31          eugd, you can limit the map size if you want
16:49 est31          rubenwardy has added such functionality to the engine
16:49 est31          and about shapes... well.. we are a voxel game, dont know whats so appealing about circles
16:50 est31          either way, we do allow for slopes etc, so you can have "smooth" landscapes if you want
16:50 T4im           well technically they are circles :>
16:50 est31          erm spheres ofc
16:50 T4im           or that, yes
16:51 T4im           didn't someone even already mapgen those slopes into the landscape?
16:51 est31          yea
16:51 est31          thats where that idea is from :)
16:52 T4im           I wonder how that performed rendering wise
16:52 eugd           i was thinking more like
16:53 eugd           MAX_MAP_GENERATION_LIMIT
16:53 eugd           and associated
16:53 eugd           adding two more
16:53 est31          eugd, that functionality exists
16:53 T4im           if the new emerge function allows to ignore that generation limit, couldn't you even "create" shapes?
16:53 eugd           to have limited x/y/z
16:53 T4im           by actively emerging shapes outside the generation limit?
16:53 eugd           from engine rather than lua
16:53 est31          no it doesnt allow the generation limit
16:54 est31          eugd, the xyz are automatially limited by mapgen
16:54 eugd           i was just saying
16:54 est31          you cant enter areas that arent generated
16:54 eugd           the way it's set up now
16:54 eugd           you are stuck to cubic worlds
16:54 eugd           regular rectangles
16:54 eugd           because we only have one value that it checks for all three axis
16:59 eugd           est31 'automatically limited by mapgen' you mean lua mapgens can set limits? i figured that
17:00 eugd           but would be nice as a core engine feature too (?)
17:00 T4im           it is limited by the engine mapgen
17:00 T4im           not by lua
17:00 eugd           you just mean the 64k cube limit?
17:00 T4im           you can decrease that limit
17:00 eugd           yeah
17:00 eugd           i was suggesting
17:01 eugd           just adding variables for limits per-axis
17:01 eugd           not sure if understood
17:05 eugd           and i'm asking if the core dev team would be opposed to that addition
17:06 eugd           splitting map_generation_limit into three variables one for each axis
17:06 sfan5          sounds like an useful addition
17:07 eugd           that's actually something i'm not even sure of
17:07 est31          I'm not strictly against that, but wondering about use cases
17:07 eugd           i *think* lua could do the same thing? right? so would it actually be useful
17:07 Calinou        at least make Y axis configurable separately
17:07 eugd           calinou exactly
17:07 eugd           that's the real problem
17:07 Calinou        yes, you can do it in Lua more or less well
17:07 Calinou        but it'll be slower than a C++ solution
17:08 eugd           ok, cool
17:08 est31          Calinou, do you want it to be minecraft limited
17:08 Calinou        maybe some people like it so
17:08 eugd           est31 exactly :)
17:08 T4im           you can't make lua stop generating something, you can just attempt to catch the players before they trigger it, afaik :P
17:08 eugd           minecraft backwards compatibility
17:08 est31          we are no minecraft clone
17:08 Calinou        I still want a full-world Minecraft converter :(
17:09 eugd           minecraft 2
17:09 est31          Calinou, doesnt the one hmmmm has created work?
17:09 Calinou        Minceraft 2, you mean :-)
17:09 T4im           no, that's probably the only way you can cobble off microsoft... messing with their trademark
17:09 hmmmm          that's for minecraft classic
17:09 Calinou        est31, haven't tried it... does it work on "real" worlds and handle Minecraft-specific worlds nicely?
17:09 T4im           :P
17:09 est31          T4im's idea is good e.g. you can just hurt players if they are outside "legal" bounds
17:09 Calinou        yeah, I want something for the full game
17:09 est31          like in lava
17:10 T4im           est31: the issue with lua trying to do these things, is that its unreliable
17:10 T4im           a malicious player can just teleport into a corner and trigger mapgen, no matter what lua tries to do
17:10 est31          but they can't "play" there
17:11 T4im           and even a common player might go a little out of bounds with sufficient lag
17:11 est31          because they get killed
17:11 Calinou        client-side damage can be undone on client
17:11 Calinou        it's quite easy to have a god mode IIRC
17:11 Calinou        (except from actual player punches or server-side settings)
17:11 T4im           wasn't there still that bug, that if your health is negative/zero, that you won't take more damage? :P
17:12 T4im           and won't die either
17:12 est31          well, after some distance, it can just teleport you
17:13 eugd           i have another question
17:13 T4im           but it won't prevent mapgen running.. and with that won't prevent disk space waste (which vps run servers might have problems with) or mapgen lag
17:13 eugd           would there be a likely problem from having two 'instances' of the same block?
17:14 eugd           for example in the extreme case of a 1x1 block world
17:14 eugd           i am wanting to do looping worlds
17:14 eugd           and thinking best way is just to do a direct and actual instance
17:14 eugd           but would it likely just crash from memory access clusterfuck?
17:15 eugd           or not really?
17:30 eugd           is there a technically ideal MAP_BLOCKSIZE? i've asked this before on the forums a year ago
17:31 est31          #3197 looks fine for me
17:31 ShadowBot      https://github.com/minetest/minetest/issues/3197 -- Save and remove player by pointer by nerzhul
17:31 est31          will merge it
17:31 est31          or nerzhul_ do you want to push it?
17:32 est31          and remove the playersave_perfix branch :)
17:32 nerzhul_       i let you push it :)
17:32 nerzhul_       i'm working on another thing :p
17:36 nrzkt          thanks est31
17:38 hmmmm          est31:  any word about dcf1c0b?
17:40 est31          perhaps the chat command description should reflect the fact that its async as well?
17:40 paramat        nanepiwo there are some minor lighting bugs in mgv7, please post a screenshot if you can. also, are you using moretrees mod or l-system trees? those cause dark patches
17:40 est31          otherwise, ok from what I see
17:40 est31          but im not very familiar with chunks etc
17:41 hmmmm          well okay
17:41 nrzkt          thanks est31
17:43 est31          hmmmm, problem
17:43 est31          why do you set allow_generate to false?
17:43 hmmmm          ah
17:43 hmmmm          because it doesn't matter
17:43 est31          it doesnt seem to matter right now because its only used in dead code
17:44 est31          but perhaps in future people might change the impl
17:44 hmmmm          force_queue_block overrides what allow_generate would do
17:44 est31          and then bug reports pop up
17:44 hmmmm          yeah to be honest emergequeue needs a lot of work
17:44 est31          ^
17:44 est31          THIS.
17:44 est31          we'd need a non locking queue impl
17:45 hmmmm          what do you personally think needs the most fixing with it
17:45 est31          its mostly features
17:45 hmmmm          oh
17:45 est31          e.g. I want to be abled to force loading an area
17:46 est31          without voxelmanips etc
17:46 hmmmm          that has more to do with the environment than it does with the emerge queue though, does it not?
17:46 est31          just for getting and parsing a mapblock
17:46 est31          my usecase is benchmarking mapblock compression
17:46 est31          and for that you need mapblock data
17:47 hmmmm          isn't there a forceload block feature?
17:47 est31          I could perhaps indeed use that, as it seems
17:48 hmmmm          hrmm
17:48 hmmmm          is the way emerge_area and delete_area are implemented kind of dumb
17:48 hmmmm          shouldn't it be emerge_block and delete_block, and then have the part where it iterates over the area as part of a lua wrapper function
17:48 hmmmm          what do you think?
17:49 est31          no it seems fine
17:49 hmmmm          really the way force loading should be implemented is that it should be an option to emerge_block()
17:50 est31          the biggest problem remaining with your patch for me is that the user has no way to know when mapgen finished
17:50 hmmmm          small steps
17:50 hmmmm          you need to fight the temptation to shove all of the functionality into a single commit
17:50 est31          meh no
17:50 hmmmm          each commit needs to have a very focused goal
17:50 est31          well yeah, no problem
17:50 est31          if you promise to do it, then its ok
17:51 est31          because you keep your promises :)
17:51 hmmmm          yeah I see what you mean
17:51 hmmmm          I guess this would be something to be wary of with an occasional contributer
17:52 hmmmm          rather than a devoted developer who's sticking around
17:52 T4im           and the uninit variable is not a problem?
17:52 hmmmm          what uninitialized variable
17:53 T4im           (06:40:35 PM) T4im: compiler complains about count being potentially uninit in l243/l276 btw
17:53 hmmmm          1243??
17:53 hmmmm          what is that
17:53 T4im           line*
17:53 hmmmm          which file
17:53 T4im           emerge.cpp
17:53 hmmmm          1243 hasn't been modified
17:53 est31          lol thats outside of hmmmm 's changes
17:54 est31          I just guess that applying the patch has triggered recompiling
17:54 est31          which means that you get the warning again
17:54 est31          but if you do a clean build on a normal copy you should get the warning as well
17:54 est31          (if my theory is right xD)
17:55 hmmmm          emerge.cpp only has 573 lines
17:55 T4im           the "1" is a "l"
17:55 T4im           L243/L276
17:55 T4im           bad font :P
17:56 hmmmm          ahhh
17:56 hmmmm          nice catch
17:56 est31          yup seeing it as well
17:56 est31          count = blocks_enqueued.size();
17:56 hmmmm          that actually might have caused a problem
17:56 hmmmm          or would it...
17:57 est31          it would
17:59 hmmmm          hmm
17:59 hmmmm          the queue limit is kind of broken anyway
17:59 est31          where
17:59 hmmmm          when I said that I think the emerge queue needs work, in particular what it needs is an actual way to discriminate against blocks that exist on disk vs. blocks that need to be generated
18:00 paramat        oh nanepiwo also note the y co-ord of the lighting bug
18:00 hmmmm          you can't tell unless you do a slow, blocking call to Map::emergeBlock(), or until the emerge queue already processed it
18:00 hmmmm          so the disk queue limit vs. generate limit are broken
18:00 hmmmm          s/are/is
18:01 hmmmm          i had an idea of how to fix, but it requires preloading a sparse table of all the blocks existing on the map
18:01 hmmmm          since this set is huge, i need to come up with an uber efficient data structure
18:01 hmmmm          I think possibly the Z addressing scheme would help here
18:02 T4im           bloom filter?
18:02 est31          why do we need such a queue anyway
18:03 hmmmm          T4im, yeah, I think I was looking at that too
18:03 hmmmm          there was a problem with it iirc
18:03 est31          preloading blocks on the map is very slow for leveldb databases
18:03 hmmmm          not preloading
18:03 hmmmm          just reading which ones exist in the DB
18:04 est31          yes precisely that
18:04 hmmmm          this is obviously going to be slow
18:04 est31          sqlite is faster
18:04 est31          just leveldb has problems out of which reason
18:04 hmmmm          so another thought was that I should cache this existence table in the db
18:06 est31          just try this commit https://github.com/est31/minetest/commit/cb85dbd03ecec23d5d92994498f4e3e2aaf09c31
18:06 est31          it will hang forever for leveldb
18:07 est31          caching might be needed
18:07 est31          but again, why do we need that queue limiting?
18:07 est31          and why does it have to be separate between map and mapgen
18:07 hmmmm          the queue limiting was there before I started coding minetest
18:07 hmmmm          so
18:08 hmmmm          ask celeron :p
18:08 est31          I can partially understand that its needed so that the server doesnt lag totally
18:08 est31          or that you cant DOS a server by having 20 clients fly around
18:09 est31          but it seems to have problems
18:09 celeron55      i don't think i have much more insight to it than you do
18:09 est31          e.g. it might be that that limiting is the reason why sometimes you have to wait so long for mapgen
18:09 celeron55      but having a queue that some issue or someone can make infinitely grow will generally make all kinds of hangs and DoSes completely distrastrous
18:09 est31          while in fact you dont wait for mapgen, its just the queue thats full
18:10 hmmmm          hmm
18:10 hmmmm          a lot of us just keep the same overall design from celeron
18:11 hmmmm          it's a tough habit to break; you come to work on minetest but you don't want to ruin something that already works, or you don't question why something is that way, so you leave it go
18:11 celeron55      i can believe it if you're saying its design has some kind of a problem if it's something that's there just because i added it at some early point
18:11 hmmmm          thinking critically about the emerge queue limit, I don't see why it needs to be done in that manner, but then again, I don't see why the emerge queue needs to be done in this manner at all..
18:12 eugd           anyone got a moment to look at map.cpp for me?
18:12 eugd           search for "map_generation_limit"
18:12 hmmmm          still to this day I have this fear that if I change something in minetest that was there already, it's going to explode in unpredictable ways
18:12 hmmmm          eugd: ?? what about it
18:12 paramat        eugd initial player spawn is a random search starting at 0,0 and working outwards with increasing radius, it calls the mapgen's 'ground level at point' to search for dry land at low altitude
18:13 eugd           wow thanks paramat
18:13 eugd           it doesn't look for trees?
18:13 eugd           can you point me to the code for it?
18:13 kilbith        eugd: your answer is likely here : ec796b8e
18:13 eugd           kilbith i don't know what that means :(
18:14 est31          its a commit hash
18:14 eugd           ha showing my inexperience
18:14 paramat        no check for trees, so sometimes you are inside one
18:14 eugd           and also can be far, far away from any, right?
18:14 paramat        i don't remember where the code is
18:14 paramat        yeah
18:15 eugd           anyway my real concern was to limit its reach from 0,0
18:15 eugd           or make that an option
18:15 eugd           um back to map.cpp
18:16 paramat        spawn will always be as close to 0,0 as possible
18:16 eugd           starting line 2579
18:16 eugd           is there a reason this little segment is the way it is, rather than just calling back to one of the functions from mapblock.h?
18:23 nanepiwo       paramat, about my lightning bugs: I'm using your paragenv7 mod, not sure of kinds of trees. it happens only in regions far enough out of spawn, which I think were generated after I updated my minetest server version
18:24 kahrl          weren't fireflies removed a long time ago
18:24 eugd           no one wants to help or no one knows re map.cpp 2581-2588?
18:24 eugd           kahri not sure if joking
18:24 eugd           he means lighting errors
18:24 kahrl          oh, ok
18:25 paramat        lol
18:26 paramat        yes more recent MT has different lighting bugs due to changes in mgv7 lighting calculations
18:26 paramat        worst shadows are at y = 63
18:27 nanepiwo       I'm away from my machine right now, but they basically look like the endless shadows similar to those caused by worldedit
18:27 nanepiwo       I've tested between y = 0 and y = 100is, still dark
18:27 nanepiwo       and rapidly becomes so
18:28 paramat        #2759 is one current bug
18:28 ShadowBot      https://github.com/minetest/minetest/issues/2759 -- Lighting bug at y = 63 in mgv7 and core mapgens in development
18:28 MinetestForFun this lightning problem is boring, in mapgenv6 with watershed i can see this shadows, and with a mapgenv7 not tweaked, i can see more and more shadows issues :/
18:28 Soni           so let's say I can add full Lua 5.2 compat to LuaJIT
18:28 Soni           (and even Lua 5.3)
18:29 Soni           (yes, it's a bit overengineered, but w/e)
18:29 hmmmm          I've heard some stuff about lua 5.3 being faster than luajit
18:29 paramat        watershed should be used in singlenode
18:29 Soni           if I do it, can we switch to Lua 5.2+?
18:29 MinetestForFun oh yes sorry, watershed + singlenode = shadows
18:29 paramat        ok
18:29 nanepiwo       its the whole entire region for me
18:29 MinetestForFun my mistake :p
18:29 Soni           (not that we'd have to - LuaJIT would already support it)
18:29 Soni           (so we'd just have to update LuaJIT)
18:29 hmmmm          Soni:  the lua language itself is reverse-compatible, correct?
18:29 Soni           not really
18:29 hmmmm          ahh
18:30 Soni           Lua 5.2 brings _ENV
18:30 hmmmm          see that's the problem
18:30 T4im           well you can compensate for that
18:30 hmmmm          is there a utility similar to Python's 2to3?
18:30 Soni           anyway, overengineering
18:30 Soni           ew 2to3
18:30 Soni           no
18:30 hmmmm          okay nevermind
18:30 T4im           there's drop-in replacements for setfenv for example written in lua
18:30 Soni           I wanna make an universal Lua VM
18:30 hmmmm          we definitely need reverse compatibility
18:30 paramat        well, best to post a screenshot of the lighting bug sometime later
18:30 hmmmm          the thing that makes minetest great are the mods
18:31 Soni           it'll be built-in
18:31 Soni           you'll just need to add a mod manifest file
18:31 hmmmm          sounds fine then
18:31 Soni           that controls the Lua version to use
18:31 T4im           ah, nice..
18:31 hmmmm          just as long as we don't end up with a python 3 situation
18:31 hmmmm          where nobody uses it because it's simply not compatible
18:31 hmmmm          if lua were updated and not reverse compatible, everybody would say "ugh I am using minetest 0.4.13"
18:32 hmmmm          "the new minetests are broken and none of the mods work with it"
18:32 Soni           I just posted on the LuaJIT mailing list about my overengineered idea
18:32 T4im           most don't make use of those things that changed, hmmmm
18:32 Soni           (altho it'll probably only do 32-bit integers in Lua 5.3)
18:32 T4im           there's rarely a setfenv or debug library use anywhere
18:33 Soni           you see, LuaJIT is already Lua 5.3-compatible
18:33 Soni           you just need to put a Lua 5.3 parser on top of it
18:33 T4im           ah
18:33 Soni           (and add a few missing Lua 5.3 libs, which's trivial)
18:34 Soni           (adding the missing C API stuff isn't trivial tho)
18:36 eugd           eh wow sorry for this terrible question, but where do i put the config file? i'm trying to test the x/y/z split thing
18:36 eugd           like minetest.conf.example, where do i put the actual minetest.conf? in the world folder?
18:36 eugd           and do i rename it [worldname].conf?
18:37 T4im           besides it, when run in place
18:37 T4im           or in the folder above it (which allows multiple versions to use the same one)
18:37 eugd           so configuration files are not world-specific?
18:37 T4im           there is a game specific one
18:38 eugd           ?
18:38 T4im           worlds do have for example map_meta.txt though
18:39 T4im           but it won't be read the same way
18:40 T4im           game specific ones are for example minetest_game/minetest.conf
18:40 T4im           installation minetest.conf overrules their settings though iirc
19:09 eugd           so, i think i've got x/y/z split working fine
19:10 eugd           except for my question about map.cpp 2581-2588, which i've left alone for the time being
19:11 eugd           would it be acceptable (desirable?) to change it to work as a count of blocks/sectors, rather than nodes?
19:11 eugd           right now it's actually a strange thing where you put in some number and the actual map size ends up significantly less
19:12 eugd           because of sector-wise generation
19:17 eugd           also why does mapgen only work sector-wise? why no ability to generate partly-empty sectors? having this kind of world size limitation work mapblock-wise would be best, i think??
19:36 Soni           http://www.freelists.org/post/luajit/Make-the-VM-Luaversionagnostic-and-modularize
19:36 Soni           just in case someone's curious
19:55 Soni           oh btw can we get a minetest batching API?
20:10 eugd           map.cpp 2581-2588
20:10 eugd           or ServerMapSector * ServerMap::createSector(v2s16 p2d)
20:11 eugd           line 2545
20:11 eugd           this whole declaration uses x/y
20:11 eugd           to refer to x/z?
20:11 eugd           or am i missing something?
20:11 eugd           is this a case where notation changes?
20:11 eugd           or just an oversight?
20:11 kahrl          eugd: yeah, v2s16 has only x and y components
20:12 eugd           oh so it is for a reason
20:12 kahrl          so y is used to refer to what appears as z in game
20:12 eugd           ok
20:12 eugd           thanks
20:16 eugd           so how to do i make push? i think i have it pretty well sorted
20:16 eugd           simple thing really
20:17 eugd           changes in four files, map.cpp, mapblock.h, defaultsettings.cpp, minetest.conf.example
20:17 eugd           not sure if the way it's done is the most efficient
20:17 kahrl          do you have a github account already?
20:17 eugd           but i'm following the format that existed
20:18 eugd           nope
20:18 kahrl          well, make one
20:18 kahrl          then go to github.com/minetest/minetest and click on the fork button
20:18 eugd           oh yes i do
20:18 eugd           ok
20:18 Soni           how does this look? https://github.com/minetest/minetest/issues/3198
20:19 kahrl          git clone from your github repository (or add your github repo as a remote if you already cloned minetest)
20:19 kahrl          git checkout -b <name_of_your_new_branch>
20:20 Soni           (it's supposed to be faster when doing procedurally generated stuff)
20:20 kahrl          make the changes, git add <list of files>, git commit
20:20 kahrl          then push to your repo
20:21 kahrl          if you then go to github.com/minetest/minetest again, it should give you the option to compare & create a pull request
20:22 kahrl          that was a bit terse so feel free to ask if any step is unclear
20:23 red1           Is m_sectors a list of all loaded sectors or is it a list of all sectors that are generated?
20:26 nanepiwo       paramat: i made some screenshots of my lighting problems here: https://imgur.com/a/YxIQ4
20:28 red1           Is that the bug were part of the map has light set to zero after placing a using voxel manipulator?
20:29 nanepiwo       i dunno, but sounds about right
20:29 nanepiwo       whole regions of my map are completely darkened
20:52 T4im           you can set light and calculate it with voxelmanip though
20:53 T4im           vm:set_lighting({day=15, night=15}) and vm:calc_lighting()
20:53 T4im           though I did have that for some blocks with simple schematic placement as well
20:53 red1           could a dev take a look at game#602
20:53 ShadowBot      https://github.com/minetest/minetest_game/issues/602 -- Allowed players with server priv to access any locked chest and open any steel door. by red-001
20:54 red1           thanks
20:57 T4im           they are both right, that that would work btw :P in both if-clauses
20:58 T4im           "if statement then return true else return false end"  can always be written as "return statement"
20:59 red1           should I add a new priv for opening doors and chests?
21:10 eugd           ok, i think i got my request in properly
21:10 eugd           i had to just use the website gui
21:46 VanessaE       http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-09-23_17-46-01.png
21:47 VanessaE       causes
21:47 VanessaE       2015-09-23 12:01:48: ERROR[Emerge-0]: Ignoring block load error. Duck and cover! (ignore_world_load_errors)
21:47 VanessaE       2015-09-23 12:01:48: ERROR[Emerge-0]: Invalid block data in database (123,-88,-1933) (SerializationError): unsupported Nam
21:47 VanessaE       eIdMapping version
21:47 est31          congrats to a corrupted map!
21:47 VanessaE       so, someone gonna fix this or what?
21:48 VanessaE       better screenshot:  http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-09-23_17-48-23.png
21:49 VanessaE       that's maybe a quarter of what I was able to see initially, but they're falling too fast to capture better./
21:49 VanessaE       and it's flooding my log with a shitton of those "invalid block" messages
21:49 est31          what exactly is the problem
21:49 VanessaE       est31: those entities are outside the world bounds.
21:50 VanessaE       why isn't the engine deleting them instead of just corrupting mapblocks?
21:50 T4im           again?
21:50 VanessaE       T4im: yep.
21:50 est31          !c -1933*16
21:50 ShadowBot      est31: math calc <math expression>
21:50 est31          !c -1933 * 16
21:50 ShadowBot      est31: math calc <math expression>
21:50 VanessaE       -30928
21:50 T4im           well luckily you have /deleteblocks now at least :D
21:51 T4im           yea, some player again digging to the bottom, placing elevator?
21:51 VanessaE       yeah, I nuked the region in which they were stored
21:51 T4im           or doing other nasty stuff
21:52 VanessaE       well nto the bottom - this is only about X=-1900 Y=-2400
21:52 VanessaE       not*
21:52 T4im           oh.. seeing it now.. mobs
21:52 * VanessaE     runs /clearobjects on the server
21:52 VanessaE       and now, it's gonna be down for like 3 hours.
21:53 VanessaE       hell, one of those entities even managed to punch me while I was also floating out-of-bounds.
21:53 T4im           wouldn't it be faster than a clearobjects to just patch that mod to delete the entities if they find themselves under a certain thrshold?
21:53 T4im           :o
21:55 VanessaE       so..
21:56 VanessaE       can we PLEASE stick to the original plan where the 0.4.13 -> 0.4.14 period was supposed to be all about bugfixes?????
21:56 est31          original?
21:56 VanessaE       yeah.
21:57 VanessaE       0.4.13 was supposed to be a stability/feature release of a sort, and the time leading up to 0.4.14 was supposed to be primarily bugfixing because there wasn't enough time to go on such a spree for 0.4.13
21:57 est31          well we did it for 0.4.13 either way
21:57 T4im           hmm primary bugfixing?
21:58 T4im           _game badly needs a bugfixing-spree too :D
22:00 paramat        nanepiwo thanks, the problem is paragenv7 itself, will fix. for now if you're using paragenv7 v0.5.0 or later delete lines 85 to 87
22:01 paramat        i set 'nolight' so on-generated needs to run for every mapchunk
22:02 VanessaE       I'm sorry to be so bitchy about this, but damn it, how can I run production servers with features people want (MOBs) if the engine is gonna trash my maps?
22:02 T4im           I think that's a reasonable thing to ask
22:02 T4im           :)
22:02 VanessaE       how much longer it this shit gonna go on before someone says "enough is enough"?!
22:04 eugd           can we add this one first https://github.com/minetest/minetest/pull/3199 ?
22:07 est31          I don't think this is the way we should do it
22:08 est31          the code itself looks good but is there any real use case for having different x and z sizes
22:08 eugd           well
22:08 eugd           minecraft 2
22:08 eugd           and future stuff along those lines really
22:09 eugd           i am looking to add looping
22:09 eugd           on engine-level, because i've seen LUA implementations and they suck
22:09 est31          if its optional and doesnt break anything, im ok with it
22:10 eugd           i don't really know if it doesn't break anything
22:10 eugd           i don't *think* it should?
22:10 est31          depends on how you implement it
22:10 eugd           is that what the checks it took forever doing automatically check?
22:11 celeron55      well one thing it breaks is that if somebody was using that setting already (and we should assume yes)
22:11 est31          agreed
22:11 celeron55      the original one should probably be left as the "master limit" or something
22:11 est31          we released a stable version with that setting
22:13 eugd           so basically equivalent but supersceded by MAX_MAP_GENERATION_LIMIT of constants.h
22:13 celeron55      this still seems kind of arbitrary though; why not have separate positive and negative edge limits?
22:13 paramat        i'm not too keen on different limits though, for artistic/design reasons, the cubic cosmology is a good MT characteristic
22:13 eugd           yeah it kind of is
22:13 eugd           also the entire way generation is currently done
22:13 eugd           is kind of weird
22:14 eugd           80x80x80 chunks but it doesn't sit evenly over 0 0 0
22:14 celeron55      also this limit sometimes has to be chosen by the game too and this setting isn't helping in that
22:14 celeron55      and this setting isn't per-world either
22:14 eugd           agreed per-world would be better but how to do that?
22:14 celeron55      the usefulness of this as it is or how you propose to change it is very limited
22:14 eugd           i tried to change the least from what existed
22:15 eugd           i intend to use it as part of next step looping worlds
22:15 est31          celeron55, lots of settings should be per world
22:15 VanessaE       I must also point out:
22:15 VanessaE       19328 minetest  20   0 10.176g 8.714g 1.823g S  99.5 27.7  62:59.95 /usr/bin/minetestserver --worldname FreeForAll_World+
22:15 est31          many server owners just have different .conf files
22:15 celeron55      est31: that is very true
22:15 VanessaE       (yes, 8.7 GB of RAM used for a server.  the 99.5 is the CPU usage, as it's running /clearobjects right now)
22:16 eugd           i was honestly surprised to learn this .conf wasn't a world-based thing
22:16 est31          if we do something like that, we should have e.g. a worldsettings.conf file or so
22:16 est31          and then make it generic for all settings
22:16 celeron55      eugd: it's global because it holds the client's graphics settings and key bindings and whatever
22:17 eugd           i think what est31 suggests would be best
22:17 celeron55      probably they would need to be split or layered somehow
22:17 eugd           mapsettings
22:17 eugd           playersettings
22:17 eugd           environmentsettings
22:18 celeron55      est31: that's the best solution assuming it doesn't create too many new problems
22:18 celeron55      it might
22:19 celeron55      the configuration UI is going to be interesting, given our bad UI capabilities
22:19 eugd           that, too. there's no UI at all for most of these
22:20 eugd           even just a simple text editor in-window would maybe help people? or one which locks the setting names and only lets you change variable
22:21 celeron55      i have a feeling that it is going to be a ridiculous uncontrollable mess; but if someone manages to do it without ending up so, that would be good 8-)
22:22 celeron55      in any case if the settings are layered to global and world settings, that can't be hidden from the user
22:22 celeron55      otherwise the user will change a global setting and wonder why it doesn't work when a world setting the user doesn't know about overrides it, or something stupid like that
22:23 eugd           why layered and not split? what cause for overlap would there be?
22:23 eugd           sincere question
22:24 celeron55      i think it should probably be split, but maybe the initial world-specific settings would be copied from global settings at world creation if needed... maybe
22:24 eugd           yeah set to default from .cpp just like current
22:24 eugd           oh you mean allow players to have their own custom-made 'default'
22:25 eugd           which all future worlds will look to
22:25 eugd           ?
22:25 celeron55      that's what i just described, yes
22:25 celeron55      not sure how that should actually work; somebody has to design it and take care of the details
22:26 eugd           how do people running servers manage it now?
22:26 celeron55      it would be kind of nice to get rid of the global creative mode and damage settings after half a decade 8D
22:27 eugd           creative mode and damage, almost an entirely different can of worms. game-based things if ever there were.
22:27 VanessaE       celeron55: well unified inventory takes care of the former.
22:27 celeron55      well many games use them in a way or another, so they are relevant
22:28 celeron55      ...and i think there still is some hardcoded behavior in the engine for those
22:28 eugd           there is
22:29 eugd           it was discussed just today
22:29 celeron55      i'm all in for making game specific main menus and whatnot, but i'm not optimistic about anyone deciding to pull that off
22:29 eugd           -1 health invulnerability
22:32 est31          a forum admin is needed at #minetest
22:33 eugd           ?
22:35 celeron55      hmm
22:40 est31          also we have to find a solution for the secure.trusted_mods setting, if its settable from a file in the world folder, security is gone
22:40 est31          (world folder can be edited by untrusted mods)
22:41 eugd           what is significance of being 'trusted' mod?
22:41 est31          a trused mod has the privileges of the user who executes minetest
22:41 est31          (if security is turned on)
22:42 est31          an untrusted mod has only limited privileges, limited to the current minetest world
22:42 est31          basically a sandbox
22:43 est31          we need trusted mods because some functionality requires user level access
22:43 est31          e.g. the irc mod
22:44 eugd           then yeah that should be a global setting?
22:44 eugd           why would you need that set world-wise anyway?
22:44 est31          it should not be settable by untrusted mods
22:45 eugd           test