Time Nick Message 00:10 SitDogDev test 02:11 VanessaE celeron55: have you made some kind of decision regarding my mese update? 04:01 VanessaE celeron55: is there a particular reason /me commands are not logged? 06:51 celeron55 VanessaE: i guess if mese is changed to something, it has to be something more interesting than just an ore 06:51 celeron55 VanessaE: and no 06:55 VanessaE "something more interesting than an ore".... such as? Like a different pattern for the texture? I'm not sure I follow. 06:56 yunfan VanessaE: what different texture? dynamic ? 07:28 VanessaE celeron55: so what would you suggest as "interesting" given the normal usage of mese? 07:33 celeron55 all of what usually comes to mind are a bit far-fetched, but an example of such is some kind of an alien artefact 07:33 VanessaE ew. 07:33 celeron55 i didn't say it would be easy 07:33 celeron55 8) 07:34 VanessaE that is, as you like to say, horrible. 07:35 celeron55 an alien artefact is probably a bad idea, but i do think minetest_game should have some extra theme in addition to "stuff you find by waking out of your door IRL" 07:35 celeron55 walking* 07:35 VanessaE true, but then again when was the last time you found mese in the ground? ;-) 07:36 VanessaE now, 07:36 VanessaE I was talking with hmmmm earlier, his idea would include things like moreores and a selection of gemstones in minetest_game 07:37 VanessaE those are nice of course, though I doubt they fit your idea in this case. 07:38 celeron55 i might be fine with making mese a very rare giant gemstone 07:38 VanessaE hrm 07:38 VanessaE how would you smelt it into an ingot then if it's a gem? 07:38 celeron55 it doesn't suit it's current uses in mesecons and stuff, but using mese in mesecons was a bad idea in the first place 07:38 celeron55 in no way 07:39 hmmmm well it's not like you mine mese from mese ore are you implied... this is just 'mese', some weird material substance that's found in the ground (planted by aliens) and it's refined into ingots by the minetest guy (from here on to be referred to as "Steve") so that he can make mesecons with it 07:39 VanessaE well bad idea that may be, we now have a rather sizable amount of content to consider when making changes to mese. 07:39 VanessaE so whatever mese becomes, it needs to be reasonably compatible with the ideas those mods use -- 07:39 celeron55 well, let's just assume the gem will smelt by heating it with wood then 07:39 hmmmm it just so happens that this mese is a good conductor for magical power or w/e the hell 07:40 celeron55 or, actually 07:40 celeron55 no smelting, but rather just breaking it physically to pieces 07:40 VanessaE so it's conductive, magic, with a fine crystalline structure similar to say pyrite, must be yellow, and must be incredibly hard. 07:40 celeron55 and grounding to powder or something 07:40 hmmmm mm you see, what I wanted was to relegate the primary use of mese to mesecons, you get multiple ingots from a single block of mese - but you can still use mese to make mese pickaxes which are much more rare and probably not as efficient of a use of resources 07:41 hmmmm for really hardcore pickaxes you'd have diamond! 07:41 hmmmm but come on guys, not powder.... that'd be just like redstone in minecraft except yellow instead of red 07:41 celeron55 no; the mese pickaxe should require three meses like now, but for the purposes of mesecons, a single mese gemstone thingy should be broken to many many pieces 07:41 hmmmm yeah that's what i meant 07:42 VanessaE at present, one default:mese becomes 16 mesecons wires. 07:42 VanessaE fwiw. 07:42 celeron55 too little 07:42 celeron55 it should be like 128 at least to allow making mese as rare as it'd deserve 8) 07:42 hmmmm well... we don't know that... balancing takes a long time 07:43 VanessaE why must mese be so rare? why not make a new, even harder substance that doesn't have all those properties? 07:43 VanessaE and make *that* the rare one. 07:43 celeron55 anyway; i'm fine with adding more ores, *as long as* their placement is more meaningful than currently 07:43 celeron55 just putting in more randomly placed ores is the dumbest thing ever 07:43 VanessaE the moreores mod uses the same method to spawn as iron or coal, so if you change that function, moreores will follow. 07:44 cy1 I like colorful caverns. :> 07:44 celeron55 they need to be biome-dependent or something 07:44 celeron55 to some extent 07:44 hmmmm hmmmmmmmm 07:44 cy1 gloopores has some biome-dependent ores. 07:44 cy1 well, one 07:44 VanessaE so then make the generate_ore() function (or whatever it's called) be the one that does that. 07:44 celeron55 and locally more dependent on surroundings too 07:44 celeron55 like water and the base materials of the ground 07:44 VanessaE make biomes inside the function with an optional parameter - if it isn't provided, then let ores spawn the way they do now. 07:45 cy1 I think ores could use more clustering. As in you search a while to find a type of ore, then you find a ton of it. 07:45 celeron55 VanessaE: that functions will not be used for *anything* in the future 07:45 celeron55 VanessaE: it locks the server thread completely 07:45 celeron55 it's like the worst thing ever 07:45 VanessaE celeron55: I know. I've looked at your code. 07:45 hmmmm if that's the case, i think i'm going to want to be able to pass along the biome map for the just-generated block to register_on_generated 07:45 VanessaE I'm really rather surprised at how bad it was :-) 07:45 celeron55 ores should be added to map generation at the same time as telling the generator about biomes 07:46 cy1 3D biomes... 07:46 hmmmm well hold on 07:46 hmmmm here's what i do 07:46 hmmmm i have this 2d array i calculate in makeChunk 07:47 hmmmm that has the mapping of which biome each node at each (x, z) is 07:47 VanessaE celeron55: I presume however that you will not break old mods that rely on the existing function? I mean, you'll surely point it to some new code? 07:48 hmmmm this, along with the terrain map, ought to be returned from makeChunk so they can be passed along to lua without needing any perlin noise recalculation at ALL 07:48 celeron55 well, it'll probably be left there to rot as a deprecated thing as-is 07:50 hmmmm so register_on_generated_ex() will be minp, maxp, seed, terrain_map, biome_map, humidity_map, heat_map) ? 07:50 celeron55 way more than that is required on the C++ side; the maximum allowed server delay after generating something is like 50ms 07:51 hmmmm what happens if lua spends more time than the server tick? 07:51 celeron55 by using the noise implementations provided by the api, lua might just be a ble to fill a single mapblock with random ores in that time 8) 07:51 celeron55 the server waits 07:51 celeron55 until it completes 07:52 cy1 I wish to find solid mese caves at -20k :'( 07:52 celeron55 doing nothing else than answering to network pings 07:52 hmmmm well yeah.... but i mean it's not like horrible 07:52 hmmmm that's just a tad of lag 07:52 celeron55 at least it makes RBA really asshurt 07:52 celeron55 otoh he gets that way from almost anything 07:53 hmmmm but nevermind any of that because it'l be irrelevant when the mapgen lua interpreter is in its own thread 07:53 hmmmm which i'd like to happen for 0.4.5 07:53 celeron55 well then it's fine 07:54 hmmmm er how is this going to work out.... chunk is generated in C++, added to the lua mapgen queue, and does sendblocks wait until lua signals the server thread that it's done doing whatever it needs to? 07:56 celeron55 by the way, there are two aims for releasing 0.4.5: if we end up needing a bugfix release, it'll be released any time to fix a couple of small things; otherwise the goal is to release it at 1-3 months 07:56 hmmmm i haven't taken a close enough look at sendblocks.... how does it work exactly? how does it know when emergethread is done generating it? 07:56 celeron55 the server has a global environment lock 07:57 celeron55 emergethread keeps stuff in the voxelmanipulator until it is ready, then locks the environment, puts the result in there and lets it go 07:57 hmmmm so sendblocks is blocking basically until it's finished? 07:58 celeron55 yes, sendblocks hangs on the lock like everything else too 07:58 hmmmm okay, bad, bad... how about this: sendblocks checks if there are any blocks to send in a block queue that contains stuff that emergethread is finished with generating 07:59 hmmmm on each tick 07:59 celeron55 how does that differ from anything we currently have 07:59 hmmmm i don't really want sendblocks to block because that can screw up the interval 07:59 celeron55 everything else blocks too, it's useless to make sendblocks non-blocking 07:59 hmmmm it's different because you can guarantee a worst-case latency of the server tick time 08:00 celeron55 the blit from the voxelmanipulator to the environment simply has to be fast enough to not cause delays 08:00 celeron55 and it is, unless lua is called after it to do stuff for seconds (like some map generation mods do) 08:00 hmmmm oh shoot i'm sorry 08:00 hmmmm i'm tired 08:01 hmmmm don't mind me 08:01 hmmmm yes, okay, no problems 08:02 hmmmm speaking of which it's 3am and i should get to bed now 17:13 thexyz wtf 17:15 thexyz making KeyList implementation to use std::set fixes this one https://github.com/celeron55/minetest/issues/325 17:15 thexyz https://gist.github.com/b7b8e8a85408c52f4a98 17:19 thexyz is there any reason to not use set in that case? 17:19 celeron55 wut 17:20 celeron55 i want to know why it fixes anything at all in the first place 17:20 thexyz wait.. 17:21 thexyz well, it definetly does 17:21 celeron55 there are two types of ways keys are handled 17:21 celeron55 either as characters, or as raw keys 17:21 celeron55 both need to work 17:22 celeron55 a good test is to try if "/" works on multiple key layouts 17:23 thexyz well, now it doesn't work at all 17:23 celeron55 (because it requires shift + something else on some layouts (eg. german)) 17:41 thexyz forget it, it seems there's error with KeyPress's operator==