| Time |
Nick |
Message |
| 00:06 |
hmmmm |
ermm |
| 00:06 |
hmmmm |
you joke right |
| 00:33 |
|
AnotherBrick joined #minetest-dev |
| 00:37 |
|
geheimnis joined #minetest-dev |
| 01:41 |
|
chchjesus joined #minetest-dev |
| 01:58 |
|
paramat joined #minetest-dev |
| 02:08 |
paramat |
hmmmm, in mgv5/v7 generate biomes this line https://github.com/minetest/minetest/blob/master/src/mapgen_v7.cpp#L623 checks for a supporting node below, but it doesn't also check for water, so unstable sand is placed above water, okay to fix this by adding '&& c_below != c_water_source'? |
| 02:09 |
hmmmm |
didn't you write that part? |
| 02:09 |
hmmmm |
sure, it's fine by me |
| 02:11 |
paramat |
i may have .. cool |
| 02:15 |
paramat |
i'll continue to experiment with fractals, they can get boring quickly, problem is they're fractal, so often dissolve into messy clouds of single dithered nodes. i'll try some different types, try to find some satisfying and playable terrain |
| 02:16 |
hmmmm |
when in doubt, gaussian blur |
| 02:19 |
paramat |
ah yes |
| 02:31 |
hmmmm |
anyway I've been thinking of adding a mapgen flag that does a gaussian filter over the generated terrain |
| 02:32 |
hmmmm |
it's super fast |
| 02:32 |
hmmmm |
so the basic problem with perlin noise terrain generation is that in order to get a nice terrain shape you need to use a lot of octaves |
| 02:33 |
hmmmm |
but the more octaves you use, the more messy dithered nodes you get |
| 02:33 |
hmmmm |
minecraft sorta does this with its fundamentally different noise-first-interpolate-later algorithm |
| 02:41 |
paramat |
that would be good to have |
| 02:42 |
paramat |
i remember you have ideas for how to make blur faster |
| 02:43 |
hmmmm |
I already have fast blur algorithms |
| 02:48 |
paramat |
#2629 will push after checks |
| 02:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/2629 -- Mgv5/v7: Add check for water for deciding biome node stability by paramat |
| 02:49 |
hmmmm |
sure, looks good to me. |
| 02:49 |
hmmmm |
simple enough |
| 02:50 |
paramat |
i feel like starting a core mapgen. does me v8, you v9 seem okay? |
| 02:52 |
paramat |
i'll make a PR for freshwater river nodes, non-renewable and range = 2 |
| 02:52 |
hmmmm |
well hold up now |
| 02:53 |
hmmmm |
the whole reason for the numbering scheme like v5 v6 v7 so on is because it's supposed to be the next mainstream mapgen |
| 02:53 |
hmmmm |
obviously v7 never fully replaced v6 because it isn't as well rounded |
| 02:53 |
hmmmm |
so I am wondering maybe we should continue on with different names |
| 02:55 |
paramat |
sure i'm fine using a different name, watershed is a nice name. then you will have v8 |
| 02:56 |
paramat |
i feel no need for my work to be considered a mainstream mapgen =) i can be freer that way |
| 02:59 |
paramat |
i just wanna choose the name now so i don't have to change it later, i'm open to suggestions for a new type of name |
| 02:59 |
paramat |
now pushing |
| 03:01 |
hmmmm |
well, why did you call it watershed? |
| 03:04 |
paramat |
push done |
| 03:06 |
paramat |
because it will be focussed on river generation, and to refer to my popular mod |
| 03:08 |
hmmmm |
so it's not watershed exactly, but it's a derivative of watershed? |
| 03:08 |
hmmmm |
why not call it watershed_v2 or something |
| 03:10 |
paramat |
yeah a derivative, closer to riverdev actually, but that name is as bad as 'minetest' |
| 03:11 |
paramat |
yes i had better not use watershed in case players expect an exact copy |
| 03:12 |
hmmmm |
well if you have a v2 they should expect the next iteration of something similar |
| 03:12 |
hmmmm |
i think you should keep the name because it's so recognizable |
| 03:15 |
paramat |
yeah |
| 03:17 |
paramat |
i need to push some new nodes first anyway, i think we might need freshwater (renewable, range = 8) for highland lakes, and freshriverwater (non-renewable, range = 2) for rivers |
| 03:17 |
paramat |
highland lakes = the holy grail |
| 03:19 |
hmmmm |
what is different about freshwater? |
| 03:21 |
paramat |
different colour, see my watershed/riverdev screenshots, more turquoisey. inspired by MC actually |
| 03:21 |
hmmmm |
oh cool |
| 03:22 |
hmmmm |
how does it merge with regular water? |
| 03:22 |
paramat |
in my mods there's an intermediate colour at y = 2 |
| 03:24 |
paramat |
http://i.imgur.com/IQdF0Yg.png |
| 03:24 |
hmmmm |
oh that's pretty cool |
| 03:28 |
paramat |
you might enjoy exploring riverdev mod if you haven't already https://forum.minetest.net/viewtopic.php?f=11&t=9210 |
| 03:29 |
hmmmm |
eventually I want to get Lua mapgens running faster so there's no need to use C++ at all |
| 03:29 |
hmmmm |
i like that mountain there heh |
| 03:30 |
paramat |
highland lakes will be a real challenge, i look forward to tackling that. back later after food |
| 03:30 |
|
paramat left #minetest-dev |
| 03:39 |
|
deltib joined #minetest-dev |
| 03:41 |
|
Hunterz joined #minetest-dev |
| 03:57 |
Sokomine |
the highland pools are a very nice feature. they make the maps more intresting |
| 04:13 |
Sokomine |
hmmmm: i'm afraid the rotation for the schematics does not work correctly for nodes with param2 > 4 (i.e. upside-down stairs, wallmounted slabs) |
| 04:13 |
hmmmm |
oh jesus christ |
| 04:13 |
hmmmm |
I am done with schematic rotations |
| 04:13 |
hmmmm |
if you want it fixed, do it yourself |
| 04:14 |
hmmmm |
you might look at it as a bug, but this is feature creep plain and simple |
| 05:07 |
|
Zeno` joined #minetest-dev |
| 05:22 |
|
paramat joined #minetest-dev |
| 05:22 |
paramat |
#2630 another bugfix |
| 05:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/2630 -- Mgv5: Fix above/below ground spawn when water level is altered by paramat |
| 05:29 |
hmmmm |
whoops |
| 05:30 |
* VanessaE |
wonders why paramat doesn't just stay in-channel... |
| 05:32 |
* paramat |
likes to shut down the computer sometimes |
| 05:34 |
paramat |
now pushing |
| 05:38 |
hmmmm |
hey what's up zeno |
| 05:39 |
paramat |
done |
| 05:39 |
hmmmm |
great |
| 05:39 |
hmmmm |
hmm |
| 05:40 |
Zeno` |
hiya |
| 05:40 |
Zeno` |
bbs (on hold on the telephone... great) |
| 05:41 |
hmmmm |
paramat, so what kind of Lua interface would you like to see for setting the node resolver mode? |
| 05:41 |
hmmmm |
as a modder what would you find the most useful |
| 05:41 |
paramat |
oh those 3 options.. |
| 05:42 |
hmmmm |
see what I was thinking was making it a global mode |
| 05:42 |
hmmmm |
like... |
| 05:42 |
hmmmm |
core.set_node_resolve_mode("direct"); |
| 05:42 |
hmmmm |
core.register_biome({ ... }) |
| 05:42 |
hmmmm |
and then for serialize_schematic: |
| 05:43 |
hmmmm |
core.serialize_schematic("schematics/foobar.mts", "lua", "none", true) |
| 05:43 |
hmmmm |
which would overide the global resolve mode^ |
| 05:45 |
|
Hunterz joined #minetest-dev |
| 05:46 |
paramat |
that seems good (but i don't fully grasp the issues so don't feel particularly able to judge) |
| 05:47 |
hmmmm |
also i should add another parameter no_register or something |
| 05:56 |
paramat |
so, 3 is new water types okay with you?: fresh lake water, fresh river water (non-renewable, range = 2) and mixed river water (mixed colour, at y = 2 only). the fresh lake water will be the renewable, range = 8 version of fresh river water, and can also be used for when a player buckets some river water and then places it: they will want renewable and range = 8 |
| 05:56 |
hmmmm |
yeah that's fine |
| 05:59 |
|
Anchakor_ joined #minetest-dev |
| 06:07 |
paramat |
okay. this will also add the possibility of drinkable fresh water that can add health, we'll have a use for vessels.. |
| 06:07 |
|
paramat left #minetest-dev |
| 06:19 |
hmmmm |
hrmm wth |
| 06:20 |
hmmmm |
is it just me or does the luaJIT_setmode(script_execution_wrapper) do the opposite of what we want? |
| 06:21 |
hmmmm |
rather no, it does what we want, but messes up lua exceptions in the process |
| 06:33 |
|
cib0 joined #minetest-dev |
| 06:45 |
|
VanessaE joined #minetest-dev |
| 06:47 |
|
selat joined #minetest-dev |
| 07:00 |
|
MinetestForFun joined #minetest-dev |
| 07:05 |
|
wilkgr joined #minetest-dev |
| 07:26 |
|
Krock joined #minetest-dev |
| 07:39 |
|
kilbith joined #minetest-dev |
| 07:40 |
|
wilkgr left #minetest-dev |
| 08:01 |
|
jin_xi joined #minetest-dev |
| 08:04 |
|
Yepoleb joined #minetest-dev |
| 08:06 |
|
FR^2 joined #minetest-dev |
| 08:22 |
hmmmm |
https://github.com/kwolekr/minetest/commit/9b5d734cd37be7d3569e59c5784310204b22d656 |
| 08:23 |
hmmmm |
will commit tomorrow morning if nobody has any objections |
| 08:46 |
|
cib0 joined #minetest-dev |
| 08:51 |
|
selat joined #minetest-dev |
| 09:53 |
|
MinetestForFun joined #minetest-dev |
| 10:08 |
|
proller joined #minetest-dev |
| 10:10 |
|
Krock joined #minetest-dev |
| 10:26 |
|
cib0 joined #minetest-dev |
| 10:35 |
|
kilbith joined #minetest-dev |
| 10:49 |
|
proller joined #minetest-dev |
| 11:04 |
|
MinetestForFun joined #minetest-dev |
| 11:07 |
|
leat joined #minetest-dev |
| 11:11 |
|
err404 joined #minetest-dev |
| 11:40 |
|
Fritigern joined #minetest-dev |
| 11:45 |
|
kkk5k joined #minetest-dev |
| 12:04 |
|
MinetestForFun joined #minetest-dev |
| 13:21 |
|
cib0 joined #minetest-dev |
| 13:28 |
|
leat joined #minetest-dev |
| 13:42 |
|
Wayward_One joined #minetest-dev |
| 14:25 |
|
est31 joined #minetest-dev |
| 14:27 |
est31 |
This is weiiird |
| 14:27 |
est31 |
I can safely pass a const unsigned char * bytes_v to a method, and inside that method, I can modify it |
| 14:28 |
est31 |
but when I try to free outside again, it wont work because its const |
| 14:28 |
est31 |
so next try: remove the const |
| 14:28 |
est31 |
gives an error when you pass it to the method |
| 14:28 |
est31 |
method requires const unsigned char ** |
| 14:28 |
est31 |
so I cast it |
| 14:29 |
est31 |
and the compiler is ok with that |
| 14:29 |
est31 |
rly weird |
| 14:38 |
* est31 |
learnt the difference between "char *const" and "const char *" |
| 14:47 |
sfan5 |
whats a char *const? |
| 14:49 |
sfan5 |
ohhh |
| 14:49 |
sfan5 |
thanks cdecl.org |
| 14:50 |
sfan5 |
char *const foo is "declare foo as const pointer to char" and const char *foo is "declare foo as pointer to const char" |
| 14:50 |
sfan5 |
a const pointer isn't that useful |
| 15:09 |
|
JZTech101 joined #minetest-dev |
| 15:19 |
|
hmmmm joined #minetest-dev |
| 15:24 |
|
ElectronLibre joined #minetest-dev |
| 15:34 |
|
MinetestForFun joined #minetest-dev |
| 15:54 |
|
cib0 joined #minetest-dev |
| 15:56 |
|
Calinou joined #minetest-dev |
| 16:01 |
kilbith |
is there a possibility to add the support of the alpha textures for the meshnodes ? |
| 16:01 |
|
luizrpgluiz joined #minetest-dev |
| 16:03 |
luizrpgluiz |
it would be possible someday send commands to the server without being with the client open? Such as the MC? |
| 16:05 |
|
proller joined #minetest-dev |
| 16:15 |
|
Hunterz joined #minetest-dev |
| 16:15 |
|
MinetestForFun joined #minetest-dev |
| 16:16 |
|
MinetestForFun joined #minetest-dev |
| 16:25 |
Krock |
luizrpgluiz, write a bot |
| 16:26 |
est31 |
btw discussion is in #mt right now |
| 16:26 |
est31 |
(was a crosspost) |
| 16:26 |
Krock |
k ty |
| 16:26 |
luizrpgluiz |
sorry |
| 16:27 |
|
luizrpgluiz left #minetest-dev |
| 16:28 |
|
rubenwardy joined #minetest-dev |
| 16:30 |
|
MinetestForFun joined #minetest-dev |
| 16:44 |
|
Robert_Zenz joined #minetest-dev |
| 17:21 |
Krock |
ShadowNinja, C++ is interesting, that method you said yesterday actually works. http://pastebin.com/S55fDxv0 Updated #2618 |
| 17:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/2618 -- 20s timeout when connecting to server by SmallJoker |
| 17:22 |
hmmmm |
what are you testing...? |
| 17:23 |
Krock |
hmmmm, I tested this one: http://irc.minetest.ru/minetest-dev/2015-04-15#i_4224323 |
| 17:24 |
* Krock |
slaps himself |
| 17:25 |
Krock |
| is the binary OR operator. Must use || instead. |
| 17:26 |
hmmmm |
oh man |
| 17:26 |
hmmmm |
there needs to be some basic level of C++ literacy |
| 17:27 |
Krock |
Lovely. || returns 1, can't use that one |
| 17:27 |
hmmmm |
i'm wondering if i should make some kind of pseudo-C++ class |
| 17:27 |
hmmmm |
Krock, this is not lua, you can't do the "foo or bar" trick here |
| 17:27 |
Krock |
pseudo-C++? |
| 17:27 |
Krock |
hmmmm, I know but I thought ShadowNinja would be right there. |
| 17:27 |
hmmmm |
training session |
| 17:28 |
hmmmm |
well people can learn just as well off of kahn academy or likewise |
| 17:28 |
hmmmm |
rather, code academy |
| 17:29 |
hmmmm |
Krock, what is it that you intend to do with this +u32 last_time = fps_timings->last_time | time; |
| 17:29 |
hmmmm |
if fps_timings->last_time hasn't been set before, then use 'time'? |
| 17:29 |
Krock |
hmmmm, yes, exactly that. |
| 17:29 |
hmmmm |
well first of all, where is fps_settings->last_time set in? |
| 17:30 |
Krock |
FpsControl, a struct "u32 last_time", set to 0 everywhere it is new initalized |
| 17:31 |
hmmmm |
yes, i can see that, i'm asking where does it get *set* to the value it normally holds |
| 17:32 |
Krock |
I expect "= { 0 };" sets it to zero. |
| 17:32 |
Krock |
What exactly do you mean? |
| 17:33 |
hmmmm |
initialization is one such time where a variable would be set to a value. |
| 17:33 |
hmmmm |
it's the time it's initially set |
| 17:33 |
hmmmm |
however, it is not very useful for a variable to just hold the value "0" and never change. |
| 17:33 |
hmmmm |
surely, it must be *set* to a different value somewhere later on in the execution. |
| 17:33 |
hmmmm |
this is what i mean. |
| 17:34 |
* Krock |
points at Game::limitFps(FpsControl *fps_timings, f32 *dtime) |
| 17:34 |
Krock |
There it's used. |
| 17:36 |
hmmmm |
are you sure it isn't used anywhere else? |
| 17:38 |
Krock |
eh. it's used in some other Game functions |
| 17:38 |
hmmmm |
but you're not very concerned about those other instances |
| 17:38 |
hmmmm |
so tell me what the reasoning is behind modifying that line of code? |
| 17:38 |
hmmmm |
what was wrong with it? why did it need to get changed? |
| 17:40 |
Krock |
actually, I haven't thought that far because I only had the problem with instant timeout after 10s, doesn't matter it it was connecting or not |
| 17:40 |
Krock |
*if it |
| 17:41 |
hmmmm |
the first step to fixing code is to find out what the root cause of the problem is |
| 17:41 |
hmmmm |
not making random changes |
| 17:42 |
Krock |
I see. Everything starts with limitFps. It calculates the dtime and that one is used on various places |
| 17:43 |
hmmmm |
so if you look in Game::run(), which also uses limitFps, you'll notice that it explicitly sets fps_control->last_time to the current time |
| 17:43 |
hmmmm |
look at line 1748 |
| 17:44 |
Krock |
Oh, I see what you mean. One of those lines is useless |
| 17:45 |
Krock |
removing 'draw_times.last_time = ' from Game::run() would be my soulation |
| 17:46 |
Krock |
I doupt it's ever required to get a dtime "spike" the first time it is used |
| 17:46 |
hmmmm |
no, no. |
| 17:46 |
hmmmm |
that's not correct. |
| 17:46 |
hmmmm |
how about instead of guessing, why don't you try it out yourself and see if it works or not? |
| 17:52 |
Krock |
I'm sure this build will behave like the one with line 1748. |
| 17:52 |
Krock |
However, CPU got something to do for the next 8 minutes |
| 17:53 |
est31 |
btw you dont have to clean before you build |
| 17:53 |
est31 |
its much faster |
| 17:53 |
|
proller joined #minetest-dev |
| 17:53 |
Krock |
est31, I know that. |
| 17:53 |
est31 |
still needing 8 minutes? |
| 17:53 |
Krock |
I never cleaned my minetest build since my first developement releases |
| 17:53 |
est31 |
lol |
| 17:54 |
Krock |
est31, yes, 5 minutes for linker and the rest for the .cpp files |
| 17:54 |
Krock |
switching branches almost lets me do a clean build |
| 18:03 |
|
Krock joined #minetest-dev |
| 18:12 |
Krock |
hmmmm, I decided to move the " |
| 18:12 |
Krock |
- draw_times.last_time = device->getTimer()->getTime();" part into Game::limitFps() because FpsControl has no other use than limiting the Fps. Donno how to explain with other words. |
| 18:15 |
Krock |
Minetest works as usual with that commit |
| 18:54 |
|
selat joined #minetest-dev |
| 18:56 |
|
OldCoder joined #minetest-dev |
| 19:08 |
|
ElectronLibre joined #minetest-dev |
| 19:18 |
|
leat joined #minetest-dev |
| 19:27 |
|
Player_2 joined #minetest-dev |
| 19:31 |
hmmmm |
Krock: it needs to be initialized though |
| 19:32 |
hmmmm |
Krock: the correct solution is to add draw_times.last_time = device->getTimer()->getTime() above the processing loop |
| 19:33 |
hmmmm |
in both Game::run() (which it already does) and in Game::connectToServer() |
| 19:34 |
hmmmm |
with that in mind: somebody please tell me WTF https://github.com/minetest/minetest/commit/0c634a97197d50f2ca58825f1b215d0407397ac6 is |
| 19:34 |
hmmmm |
not only is there no discussion or review, but he's not even HERE in the channel saying that he's committing something |
| 19:35 |
hmmmm |
these std::vector changes have lots of potential to break things in subtle ways. it needs to be thoroughly reviewed ASAP or reverted |
| 19:35 |
hmmmm |
and celeron55: see above. |
| 19:38 |
|
Hijiri joined #minetest-dev |
| 19:39 |
Krock |
okay, the boss spoke. Commit got updated. |
| 19:40 |
celeron55 |
hmmmm: i can confidently say i now reviewed it and it's fine; but i agree that this kind of committing is dubious |
| 19:40 |
hmmmm |
Krock: it's more important that you can see the reason why it's correct |
| 19:41 |
celeron55 |
i mean, we need to have these kinds of micro-optimizations flowing in so that everyone doesn't have to always make perfectly optimized implementations on the first merge |
| 19:41 |
Krock |
hmmmm, yes but I still would prefer a way where it's automatically set to the initialized time |
| 19:42 |
hmmmm |
there is no way to do that |
| 19:42 |
celeron55 |
but keeping track of them has to be based on trust, otherwise it's very inefficient |
| 19:42 |
hmmmm |
I suppose what you could do is add a boolean field in FpsControl "is_initialized" and then if not initialized, set it to the current time in limitFps |
| 19:42 |
hmmmm |
but that's inefficient and unnecessary |
| 19:43 |
hmmmm |
celeron55: you trust the guy who was made core developer AND subsystem maintainer of a very critical subsystem after submitting 2 prior small patches? |
| 19:43 |
hmmmm |
and subsequently introduced bugs with literally every feature added since then |
| 19:43 |
celeron55 |
that's the problem; i really don't to the required extent |
| 19:44 |
hmmmm |
he shouldn'tve been trusted in the first place |
| 19:44 |
hmmmm |
but he was |
| 19:44 |
hmmmm |
and then he proved why he shouldn't have been trusted |
| 19:44 |
hmmmm |
and he still is |
| 19:44 |
hmmmm |
how do you think this reflects on you, the team manager |
| 19:44 |
Krock |
And I expected last_time would be zero after initializing and use that to set last_time. However, the current state is acceptable |
| 19:45 |
celeron55 |
hmmmm: well if you look at his latest stuff and ignore the initial things, it's actually kind of ok |
| 19:46 |
hmmmm |
he still hasn't fixed the damage counter bug and there's an obvious solution |
| 19:46 |
hmmmm |
zeno and i are waiting to see what he's going to come up with |
| 19:47 |
celeron55 |
i'm still trying to figure out how much risk taking makes sense, sorry for the inconveniences :P |
| 19:47 |
hmmmm |
microoptimizations and new features come second to fixing bugs that were introduced by your own prior changes |
| 19:47 |
hmmmm |
i do make bugs, sure, but i fix them |
| 19:49 |
celeron55 |
one of things that i thought might help with nrzkt was that he seemed to be an active player too and i thought that would make him less inclined to leave problems unfixed in the long term; that didn't really work out that way |
| 19:50 |
celeron55 |
altough i'm not doing any final judgements this time |
| 19:50 |
hmmmm |
that's fine |
| 19:52 |
VanessaE |
I think the problem, celeron55, is that he doesn't play on an average server. |
| 19:52 |
VanessaE |
seems like it's only ever singleplayer or on his own private server |
| 19:53 |
kilbith |
yes, his server use a custom engine though |
| 19:55 |
|
cib joined #minetest-dev |
| 20:01 |
hmmmm |
so... no discussion on https://github.com/kwolekr/minetest/commit/6222de5d915a4061658648a64cfa768167d4a900 ?? |
| 20:05 |
VanessaE |
not from me :P |
| 20:22 |
|
chchjesus joined #minetest-dev |
| 20:26 |
hmmmm |
:| |
| 20:26 |
hmmmm |
okay then |
| 20:26 |
* VanessaE |
pokes Sokomine |
| 20:27 |
VanessaE |
she would be the most qualified to comment I guess. |
| 21:09 |
|
est31 joined #minetest-dev |
| 21:10 |
est31 |
the * sizeof(char) in the string handling functions in networkpacket.cpp has really no use at all |
| 21:10 |
est31 |
its deployed inconsistently |
| 21:10 |
est31 |
so for platforms where sizeof(char) != 1, we will face issues |
| 21:12 |
Sokomine |
what is the intended use of serialize_schematic? |
| 21:12 |
est31 |
I've added a method to add c strings to avoid useless copying, and saw that |
| 21:14 |
Sokomine |
i'm not sure how helpful inserting comments into a table will be. comments are certainly useful for humans who want to read a table manually - or who want to understand the table's structure. one or two examples may prove useful in such a case |
| 21:14 |
est31 |
OK found out that sizeof(char) == 1 always |
| 21:14 |
est31 |
https://isocpp.org/wiki/faq/intrinsic-types#sizeof-char |
| 21:14 |
Sokomine |
allowing multiple parameters instead of just one in general seems a good idea |
| 21:16 |
Sokomine |
the "register_after_load" parameter is certainly very intresting. i'm facing that problem with my village code as well. the original village code by nore did read the file whenever it wanted to spawn a house. i read it once now and store it as a table. hard to tell what is more efficient; probably requires extensive knowledge of the lua language in that case |
| 21:23 |
hmmmm |
est31, yes, whenever you see "* sizeof(char)" in C/C++ code, you know it was written by a novice |
| 21:23 |
hmmmm |
:) |
| 21:23 |
hmmmm |
sokomine: serialize_schematic() takes a schematic and returns it in a serialized format of your choosing |
| 21:23 |
|
proller joined #minetest-dev |
| 21:23 |
hmmmm |
either mts file or a lua table |
| 21:26 |
Sokomine |
i see. but what is the intended use of it? i did something similar on the lua side because i had to. the mapgen data is read via your useful voxelmanip, and the mts files are read using zlib-deflate - and then the schematics are inserted into the voxelmanip area manually using lua code - node by node |
| 21:29 |
Sokomine |
it's certainly good to have a function for that at hand. maybe i ought to run it on a schematic and see what its output is. or do you have an example of the lua table format it generates at hand? |
| 21:33 |
Sokomine |
hmmmm: i'd be very intrested in learning what the node_resolve_method is good for. that seems to be what you where working on? is it an internal optimization? |
| 21:35 |
hmmmm |
object definitions in general are much more structured than you probably think of them as an end user |
| 21:35 |
hmmmm |
biomes are an object definition; schematics are an object definition, decorations are, ores are |
| 21:35 |
hmmmm |
they can be registered |
| 21:35 |
hmmmm |
they all do something with nodes |
| 21:36 |
hmmmm |
in the case of schematics, they can be loaded from files or defined from within lua |
| 21:36 |
Sokomine |
*nod* so far so good |
| 21:36 |
hmmmm |
there's a single, consistent internal representation that it gets converted to regardless of whichever method you use |
| 21:36 |
hmmmm |
so let's say you register a schematic |
| 21:37 |
Sokomine |
ok |
| 21:37 |
hmmmm |
schem_tree = core.register_schematic("schematics/tree.mts") |
| 21:37 |
hmmmm |
schem_tree is a *handle* to the schematic object that got loaded and registered |
| 21:37 |
hmmmm |
when defining a decoration that places schematics, you can specify schem_tree instead of the filename |
| 21:38 |
Sokomine |
ok, so far so good |
| 21:39 |
hmmmm |
so let's say you have core.register_decoration({deco_type = "schematic", biomes = "jungle", fill_ratio = 0.5, schematic = schem_tree}) |
| 21:39 |
hmmmm |
what I did right there is that I used the schematic handle as a specifier for the schematic |
| 21:40 |
hmmmm |
it would have been also valid to repeat the same filename |
| 21:40 |
hmmmm |
the filename for schematics is the object definition name |
| 21:40 |
hmmmm |
and for biomes I referenced them by name too |
| 21:40 |
hmmmm |
I could have registered a biome, and passed along the handle for the biome instead |
| 21:40 |
hmmmm |
it's equally valid to do this: |
| 21:41 |
hmmmm |
biomes = {core.register_biome({name="jungle", top_node="grass", ...}, "desert"} |
| 21:41 |
hmmmm |
I put the definition right into the biome list for the decoration |
| 21:41 |
hmmmm |
that's because register_biome returns a handle to the biome object which could be used just as well as the name specifier |
| 21:42 |
hmmmm |
so anyway same with schematics |
| 21:42 |
hmmmm |
core.serialize_schematic() takes *some* schematic identifier, whether it's by handle, name, or lua definition |
| 21:42 |
hmmmm |
it loads it into its internal format |
| 21:42 |
hmmmm |
and it keeps it there if register_on_load is specified, AND the schematic had to be loaded |
| 21:43 |
hmmmm |
so another thing is that when schematics and ores and whatever are registered, they specify nodes |
| 21:43 |
hmmmm |
but at the time the mod initialization is executed, those nodes do not exist yet |
| 21:43 |
Sokomine |
yes. something i like to play with a lot. that list of node names the schematics come with is pretty helpful |
| 21:43 |
hmmmm |
you need to resolve the string name of a node to the content id of the node at some point |
| 21:44 |
hmmmm |
so they usually get converted to when all mods are finished initializing |
| 21:44 |
Sokomine |
ok. but that ought to be a pretty fast process and needs to be done only once? the schematic object might hold a variable indicating weather its node names have been resolved or not |
| 21:44 |
hmmmm |
this is what happens with the "deferred" node resolution method |
| 21:44 |
hmmmm |
think of "resolving" as if you're resolving a hostname using DNS |
| 21:45 |
hmmmm |
except instead of a computer hostname to an IP, it's a node name to content id |
| 21:45 |
hmmmm |
so if you use the "direct" node resolver method, it'll look up the value of the nodes based on the current existing state of the node table |
| 21:45 |
hmmmm |
it won't wait until all nodes are finished resolving |
| 21:45 |
Sokomine |
yes, i'm doing that in lua for the nodenames as well. have to. sometimes it takes nodenames, sometimes it takes content_ids; sometimes my local replacements have to be taken care of |
| 21:45 |
hmmmm |
so if you have grass and lava defined in your mod but there's water defined in a different mod that didn't load yet |
| 21:46 |
hmmmm |
that water lookup will fail and it'll silently be replaced with air |
| 21:46 |
hmmmm |
you don't normally want this |
| 21:46 |
hmmmm |
but you might want it with schematic serialization |
| 21:46 |
hmmmm |
the third resolve method, is not a resolve method |
| 21:46 |
hmmmm |
it just tells it to not resolve |
| 21:46 |
hmmmm |
this is obviously invalid combined with register_on_load |
| 21:46 |
Sokomine |
hmm. hard to think of a use case where partial resolution of node names might be desired |
| 21:47 |
hmmmm |
so because it's not resolved, there's no translation of node names to IDs at all |
| 21:47 |
hmmmm |
this way if you have a super fancy schematic called coolschematic.mts and it contains nodes from MoreBlocks |
| 21:47 |
hmmmm |
it won't give you screwed up output when you go to convert it in the base game |
| 21:48 |
Sokomine |
hmm. but the list of node names is a finite, usually rather short list, and looking up nodenames (once they're registered) ought to be pretty fast as well? |
| 21:48 |
hmmmm |
what do you mean |
| 21:48 |
Sokomine |
i think waiting until all nodes have been registered and then doing the name resolution once ought to be no problem at all? |
| 21:49 |
hmmmm |
it's an issue if a). you're doing this inside of mod initialization or b). you're doing this in a game without a mod that the schematic you're serializing has nodes from |
| 21:49 |
hmmmm |
bbl |
| 21:52 |
Sokomine |
loading schematics where the nodes the schematic (in the form of an .mts file) uses do not exist is actually an issue i'm working with currently. i've written some lua code so that players can manually select replacement nodes (or air if in doubt) for those none-existing nodes. that's admittedly code written for placing a single schematic manually - not for decorations used for complete biomes |
| 21:52 |
|
ElectronLibre left #minetest-dev |
| 23:01 |
|
Anchakor_ joined #minetest-dev |
| 23:03 |
|
Hijiri joined #minetest-dev |
| 23:35 |
|
Robby joined #minetest-dev |
| 23:38 |
|
Hijiri joined #minetest-dev |
