Minetest logo

IRC log for #minetest-dev, 2012-12-13

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

All times shown according to UTC.

Time Nick Message
00:06 sstrandberg left #minetest-dev
00:10 SitDogDev test
00:11 celeron55 joined #minetest-dev
01:16 celeron57 joined #minetest-dev
02:11 VanessaE celeron55: have you made some kind of decision regarding my mese update?
02:20 kotolegokot joined #minetest-dev
04:01 VanessaE celeron55: is there a particular reason /me commands are not logged?
06:11 rsiska joined #minetest-dev
06:30 jin_xi joined #minetest-dev
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
09:01 thexyz joined #minetest-dev
11:35 loggingbot joined #minetest-dev
11:35 Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://minetest.net/wiki/doku.php?id=dev_index
12:28 kosc joined #minetest-dev
13:02 kotolegokot joined #minetest-dev
14:36 Taoki joined #minetest-dev
15:14 SpeedProg joined #minetest-dev
15:18 celeron55 joined #minetest-dev
15:54 hmmmm joined #minetest-dev
16:19 rsiska joined #minetest-dev
16:25 PilzAdam joined #minetest-dev
16:26 serengeor joined #minetest-dev
16:34 Calinou joined #minetest-dev
16:43 rubenwardy joined #minetest-dev
17:02 sema4 joined #minetest-dev
17:03 celeron55 joined #minetest-dev
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:16 rubenwardy1 joined #minetest-dev
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:25 SpeedProg1 joined #minetest-dev
17:41 thexyz forget it, it seems there's error with KeyPress's operator==
18:32 rubenwardy joined #minetest-dev
19:09 Jordach joined #minetest-dev
19:48 celeron55 joined #minetest-dev
19:51 rubenwardy joined #minetest-dev
20:16 rubenwardy left #minetest-dev
20:26 ok joined #minetest-dev
20:39 celeron55 joined #minetest-dev
21:07 doserj joined #minetest-dev
21:17 rsiska joined #minetest-dev
21:24 VanessaE joined #minetest-dev
21:37 celeron55 joined #minetest-dev
22:20 SitDog joined #minetest-dev

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