| 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 |
