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 20:20 Soni (it's supposed to be faster when doing procedurally generated stuff) 20:20 kahrl make the changes, git add , 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 21:50 est31 !c -1933 * 16 21:50 ShadowBot est31: math calc 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