| Time |
Nick |
Message |
| 00:00 |
ShadowNinja |
Hmm, so it is round |
| 00:00 |
hmmmm |
i only have it generate on tunnels of small caves with vectors longer than 35 |
| 00:00 |
hmmmm |
how long in the x,y direction it actually is depends on the length of the y component |
| 00:00 |
hmmmm |
depends largely on* |
| 00:01 |
hmmmm |
i'm pretty sure most people will like it the way i have it though |
| 00:01 |
hmmmm |
it all comes down to chance |
| 00:01 |
hmmmm |
you might get a short one that has a steep slope downward, or you might get a really long one |
| 00:01 |
hmmmm |
and i am not changing it because i like variety |
| 00:17 |
|
M13 joined #minetest-dev |
| 00:32 |
troller |
++riety |
| 00:32 |
troller |
++variety |
| 00:42 |
hmmmm |
anyway, naturally occuring obsidian at last: http://ompldr.org/vaThzdg |
| 00:42 |
hmmmm |
it's incredible what you can do with caves when you don't have the restriction of backwards compatibility |
| 00:43 |
VanessaE |
very nice |
| 00:43 |
hmmmm |
i am basically done with the caves at this point, so onto the next thing: decorationdef |
| 00:43 |
hmmmm |
we need a good format for models |
| 00:44 |
VanessaE |
isn't .x good enough for that? |
| 00:44 |
VanessaE |
or you must mean something else |
| 00:45 |
hmmmm |
this is the one detail that i hadn't fully thought out by this point, and it's pretty big.. basically, we need a way to represent the contents of a voxel box |
| 00:45 |
hmmmm |
i know somebody proposed bitmaps of each slice but i feel like that might be overly verbose |
| 00:48 |
kahrl |
wouldn't l-systems cover most of the basic needs? or am I completely misunderstanding |
| 00:50 |
VanessaE |
kahrl: l-systems can only represent three or four nodes, and not necessarily predictably. |
| 00:50 |
VanessaE |
at least within a single definition. |
| 00:50 |
kahrl |
hmm |
| 00:50 |
|
jin_xi joined #minetest-dev |
| 00:53 |
kahrl |
would it be possible to extend l-systems to allow rule_a though rule_z? |
| 00:53 |
kahrl |
through* |
| 00:53 |
VanessaE |
in theory, I suppose so |
| 00:54 |
jin_xi |
imho better rip turtle stuff from current treegen and reimplement l system on top for more flexibility |
| 01:06 |
hmmmm |
i agree |
| 01:06 |
hmmmm |
but it's not like it was a mistake to make it part of the treegen |
| 01:06 |
hmmmm |
this sort of generalization comes naturally along with evolution |
| 01:12 |
hmmmm |
i need people to make rules for the following with l-systems: current regular tree, current jungle tree, a slightly larger & nicer version of the regular tree, 0.3.x stones, stalactites/stalagmites, cactuses, papayrus |
| 01:15 |
ShadowNinja |
Cactus and papyrus sounds hard ;-) |
| 01:16 |
VanessaE |
cactus/papyrus: axiom="FFA"; rule_a="FA"; iterations = 3; randomness = 2 |
| 01:16 |
VanessaE |
should about do for those anyway |
| 01:17 |
VanessaE |
"slightly larger" default tree = use the beech tree model from moretrees. That was its intent. |
| 01:17 |
VanessaE |
stalactities/stalagmites, well that's dependent on how thick you want them to be. |
| 01:18 |
VanessaE |
0.3.x stones, I don't know what those are |
| 01:18 |
hmmmm |
varying thickness |
| 01:19 |
hmmmm |
https://github.com/minetest/minetest/blob/0.3.2/src/mapgen.cpp#L276 |
| 01:19 |
hmmmm |
agh... nevermind on that one, it uses 3d noise |
| 01:19 |
VanessaE |
got a screenshot? |
| 01:20 |
hmmmm |
nope :/ |
| 01:33 |
VanessaE |
hmmmm: think you can give some time to that alpha issue I pointed out? :) |
| 01:34 |
hmmmm |
maybe in a bit |
| 01:34 |
VanessaE |
cool |
| 02:02 |
|
BackupCoder joined #minetest-dev |
| 02:34 |
|
khonkhortisan joined #minetest-dev |
| 02:58 |
|
Kacey joined #minetest-dev |
| 02:58 |
|
Kacey left #minetest-dev |
| 03:12 |
hmmmm |
does anybody have objections do kahrl's recent pull requests? |
| 03:12 |
hmmmm |
'cuz i'm gonna pull those |
| 03:12 |
VanessaE |
it's kahrl. your objections are invalid. |
| 03:12 |
VanessaE |
"_ |
| 03:12 |
VanessaE |
:) |
| 03:13 |
hmmmm |
maybe i should wait for the param2 prediction because shadowninja has something that might conflict |
| 03:13 |
hmmmm |
but then again i should wait for the other because i'd do them both at the same time |
| 03:14 |
VanessaE |
hmmmm: well, consider c55's initial rejection of that idea though - is it indeed time (figuratively) to put that through now? |
| 03:14 |
ShadowNinja |
hmmmm: the pulls should be easy to fix, mine is just two lines |
| 03:14 |
hmmmm |
i'm pretty sure celeron would change his mind once he sees the benefit from it |
| 03:15 |
hmmmm |
it turned out to not be too complex either |
| 03:26 |
darkrose |
someone's been pinging me? |
| 03:27 |
VanessaE |
I think I did, but I already forgot why |
| 03:30 |
darkrose |
something about 0.3.x apparently |
| 03:31 |
VanessaE |
right. |
| 03:31 |
VanessaE |
doesn't much matter now :) |
| 03:32 |
kahrl |
hmmmm: I could rebase ShadowNinja's pull and add it to mine |
| 03:40 |
kahrl |
done, shall I push? |
| 03:43 |
hmmmm |
sure |
| 04:49 |
|
VanessaE joined #minetest-dev |
| 04:54 |
|
VanessaE joined #minetest-dev |
| 06:03 |
thexyz |
well, fuck |
| 06:05 |
VanessaE |
no. not here, it's loud and messy. |
| 06:11 |
hmmmm |
what's wrong? |
| 06:16 |
thexyz |
http://minetest.ru/builds/minetest-0.4.6-2.zip |
| 06:16 |
thexyz |
please, QC |
| 06:17 |
|
Nore joined #minetest-dev |
| 06:23 |
sfan5 |
"- nodebox -- See below. EXPERIMENTAL" |
| 06:23 |
VanessaE |
thexyz: I can run it in wine, but "WARNING: Block failed to save" in insane amounts. |
| 06:23 |
sfan5 |
^ i don't think the experimental is needed anymore |
| 06:24 |
VanessaE |
(I probably lack some library under wine) |
| 06:24 |
VanessaE |
thexyz: the map generates and I can look around, frame rate seems normal, sound works... |
| 06:25 |
thexyz |
VanessaE: non-latin characters in path? |
| 06:25 |
VanessaE |
thexyz: nope: vanessa rainbird:~/.wine/drive_c/minetest-0.4.6-2$ wine bin/minetest.exe |
| 06:25 |
VanessaE |
world name was just some random chars on the keyboard. |
| 06:25 |
VanessaE |
(nothing non-latin) |
| 06:25 |
hmmmm |
that's a build with leveldb i am guessing? |
| 06:26 |
VanessaE |
WARNING: Block failed to save (xxx, xxx, xxx) SQL logic error or missing database |
| 06:26 |
VanessaE |
to be exact. |
| 06:27 |
VanessaE |
seems fine with an old-ass build of 0.4.1 that I have there. |
| 06:27 |
VanessaE |
(except the framerate sucks on that old build) |
| 06:31 |
|
Nore left #minetest-dev |
| 06:33 |
|
Nore joined #minetest-dev |
| 06:36 |
|
RealBadAngel joined #minetest-dev |
| 06:42 |
* VanessaE |
pokes RealBadAngel |
| 06:42 |
VanessaE |
oops, wrong channel |
| 06:55 |
|
kaeza joined #minetest-dev |
| 06:58 |
|
iqualfragile joined #minetest-dev |
| 07:32 |
|
ImQ009 joined #minetest-dev |
| 08:05 |
|
Calinou joined #minetest-dev |
| 08:18 |
|
darkrose joined #minetest-dev |
| 08:36 |
|
darkrose joined #minetest-dev |
| 08:36 |
|
darkrose joined #minetest-dev |
| 09:22 |
|
Calinou joined #minetest-dev |
| 10:01 |
|
iqualfragile joined #minetest-dev |
| 10:22 |
|
PilzAdam joined #minetest-dev |
| 10:23 |
|
darkrose joined #minetest-dev |
| 10:23 |
|
darkrose joined #minetest-dev |
| 10:29 |
|
ImQ009 joined #minetest-dev |
| 10:29 |
|
iqualfragile joined #minetest-dev |
| 10:34 |
|
Jordach joined #minetest-dev |
| 10:34 |
|
Jordach joined #minetest-dev |
| 10:36 |
|
Jordach2 joined #minetest-dev |
| 11:07 |
|
proller__ joined #minetest-dev |
| 11:19 |
|
proller__ joined #minetest-dev |
| 11:24 |
|
Calinou joined #minetest-dev |
| 11:37 |
|
Jordach joined #minetest-dev |
| 12:09 |
|
proller joined #minetest-dev |
| 12:21 |
|
Calinou joined #minetest-dev |
| 12:25 |
|
Calinou joined #minetest-dev |
| 12:46 |
|
Jordach2 joined #minetest-dev |
| 12:52 |
|
sapier joined #minetest-dev |
| 13:08 |
|
Deivan joined #minetest-dev |
| 13:18 |
|
Jordach3 joined #minetest-dev |
| 13:34 |
|
Jordach2 joined #minetest-dev |
| 13:42 |
|
EduardeCalibal joined #minetest-dev |
| 14:07 |
|
Calinou joined #minetest-dev |
| 14:27 |
|
hmmmm joined #minetest-dev |
| 14:36 |
|
troller joined #minetest-dev |
| 14:47 |
|
nore joined #minetest-dev |
| 15:00 |
|
salamanderrake joined #minetest-dev |
| 15:08 |
|
jojoa1997 joined #minetest-dev |
| 15:17 |
|
Jordach3 joined #minetest-dev |
| 15:22 |
hmmmm |
oh god... that thread on the forums titled "dev resources" has me scared to death |
| 15:22 |
hmmmm |
these people don't know how to code at all and they think they're going to be able to do something productive with minetest |
| 15:23 |
sapier |
https://github.com/minetest/minetest/pull/613 any comments on this bugfix? |
| 15:23 |
Calinou |
more like, "these people don't know how to spell" |
| 15:23 |
hmmmm |
i'm pretty sure we wouldn't have this problem if minetest weren't something "fun" like a "game" |
| 15:24 |
Calinou |
fun is good |
| 15:24 |
kahrl |
you don't really need to know how to code to write a simple mod |
| 15:24 |
Calinou |
but it's just the targeted audience |
| 15:24 |
kahrl |
as long as you know how to read |
| 15:24 |
hmmmm |
no, kahrl, you misunderstand, they want to do things with the core |
| 15:24 |
Calinou |
^ |
| 15:24 |
kahrl |
do they even know the difference between mods and the core? |
| 15:25 |
Calinou |
I doubt :P |
| 15:25 |
hmmmm |
so you can imagine, some will be moderately successful at learning C++ and write some feature that really only _they_ wanted, full with total newbie mistakes so much that if you wanted to actually add that feature in the first place, you'd need to rewrite it from scratch |
| 15:26 |
hmmmm |
and then when you _don't_ add it because of the said problems, EVERYBODY will complain about how you're horrible, closed-minded and they need to fork minetest because of this |
| 15:26 |
Calinou |
people wanting code correctness do less end-user-visible things in general |
| 15:27 |
Calinou |
ask rovio for angry birds code and see |
| 15:27 |
Calinou |
or just decompile minecraft code |
| 15:27 |
Calinou |
it's "horrible". but the game has a lot of content |
| 15:27 |
Calinou |
(no, really, every block in minecraft has its own .java file) |
| 15:28 |
hmmmm |
that's not their fault though |
| 15:28 |
hmmmm |
that's java being stupid |
| 15:28 |
hmmmm |
(you know, each class needs its own file thing) |
| 15:28 |
Calinou |
well, if you want to look, get MCP, get a minecraft.jar from here: http://assets.minecraft.net/1_5_1/minecraft.jar, get LWJGL, and use MCP to decompile :) |
| 15:29 |
hmmmm |
from what i've seen, minecraft code is pretty okay (for java) |
| 15:29 |
Calinou |
it's decompiled so you have few comments :P but it still looks confusing sometimes |
| 15:29 |
hmmmm |
you know what really bugs me? |
| 15:29 |
Calinou |
me! |
| 15:29 |
hmmmm |
minecraft loads the entire vertical space at once |
| 15:29 |
hmmmm |
and they still don't use hardware lighting even though it's easy to do so |
| 15:30 |
Calinou |
do that in minetest too, if it's easy :P |
| 15:30 |
kahrl |
I thought they moved away from loading entire columns |
| 15:30 |
hmmmm |
it's not easy in minetest because we have blocks |
| 15:30 |
kahrl |
when they increased the height of the world |
| 15:30 |
hmmmm |
according to the source of "bukkit", that's not the case |
| 15:31 |
Calinou |
http://www.minecraftwiki.net/wiki/Anvil_file_format |
| 15:31 |
ShadowNinja |
Now there are two big connumns stacked on top of each other |
| 15:31 |
kahrl |
then why do they have these lighting glitches when there's a bedrock ceiling near the top of the map :P |
| 15:31 |
ShadowNinja |
Collumns* |
| 15:31 |
Calinou |
columns* |
| 15:31 |
hmmmm |
shrug. |
| 15:31 |
hmmmm |
but 256, that's.. pretty lame |
| 15:32 |
kahrl |
Yup |
| 15:32 |
Calinou |
only vertical height was extended |
| 15:32 |
Calinou |
it is kinda lame yeah, but few people would go higher or deeper for their builds |
| 15:32 |
hmmmm |
if they're going to split it up into multiple vertical chunks, why not go all-out? |
| 15:32 |
Calinou |
they tried doing 512 and it was too slow |
| 15:32 |
Calinou |
256 was slower than 128 already |
| 15:32 |
ShadowNinja |
lol, they did it wrong |
| 15:32 |
hmmmm |
see, things like this.. minecraft really could be a lot better than it is, but it's the design choices they make that hold it back |
| 15:33 |
hmmmm |
they do a lot of things right though |
| 15:33 |
hmmmm |
but, what they do right are common-sense things usually |
| 15:34 |
Calinou |
^ |
| 15:34 |
Calinou |
except in terms of game balance, it sucks, like minetest :P |
| 15:34 |
Calinou |
but that's not engine-related |
| 15:34 |
Calinou |
(their game is however VERY monolithic, eg. hardcoded models) |
| 15:35 |
Calinou |
that isn't common sense 8) |
| 15:35 |
Calinou |
to change models you need to edit java code |
| 15:35 |
kahrl |
I don't think it is meant to be a balanced game |
| 15:35 |
Calinou |
and the few "modelers" available are a PITA to use |
| 15:36 |
|
Jordach2 joined #minetest-dev |
| 15:39 |
|
jojoa1997 joined #minetest-dev |
| 15:39 |
|
Jordach joined #minetest-dev |
| 15:40 |
jojoa1997 |
hi |
| 15:44 |
Calinou |
hello tablet user |
| 15:47 |
jojoa1997 |
._. |
| 15:59 |
|
jin_xi joined #minetest-dev |
| 16:04 |
|
Jordach2 joined #minetest-dev |
| 16:20 |
|
Jordach3 joined #minetest-dev |
| 16:21 |
|
Jordach joined #minetest-dev |
| 16:24 |
|
Calinou joined #minetest-dev |
| 16:24 |
|
rubenwardy joined #minetest-dev |
| 16:35 |
|
Jordach2 joined #minetest-dev |
| 16:50 |
|
Jordach3 joined #minetest-dev |
| 16:52 |
hmmmm |
hrm |
| 16:53 |
hmmmm |
there is no way to get the approximate height of something that's generated by l-systems, is there |
| 16:53 |
kahrl |
doesn't seem hard to add |
| 16:54 |
kahrl |
keep track of the highest and lowest y placed inside the L-system object |
| 16:55 |
kahrl |
or do you mean before executing the l-system? |
| 16:55 |
hmmmm |
i'd need to run the algorithm twice, once as a dry run to get the height and then another to do the actual placement |
| 16:55 |
hmmmm |
which i'd like to avoid |
| 16:56 |
hmmmm |
well nevermind any of this, i bet the current l-systems implementation solved the entire problem i'm facing already |
| 16:57 |
hmmmm |
or not |
| 16:57 |
PilzAdam |
you could just go through the axiom and count every "up" movement of the turtle |
| 16:57 |
hmmmm |
it has the approximate number of blocks needed to be loaded for the tree hardcoded |
| 16:57 |
hmmmm |
that's not very robust... |
| 16:58 |
kahrl |
yeah: vmanip.initialEmerge(tree_blockp - v3s16(1,1,1), tree_blockp + v3s16(1,3,1)); |
| 16:58 |
hmmmm |
alright there's no way the trees are happening unless i chop them in half |
| 16:58 |
kahrl |
make the lua script specify the approximate dimensions? |
| 16:59 |
hmmmm |
i'll generate to the height of the overtop, then if it got cut off, i'll do the rest of it in a different chunk generation |
| 16:59 |
hmmmm |
i guess i could do that |
| 17:01 |
hmmmm |
i guess i can calculating it by going through the algorithm and counting the up movements, or if the approximate size is already specified from lua, use that, speeding things up ever so slightly |
| 17:01 |
hmmmm |
i can try calculating it* |
| 17:02 |
jin_xi |
i used a dry run in my tests. |
| 17:02 |
jin_xi |
spawing large structures still required two tries |
| 17:05 |
jin_xi |
here: https://github.com/obneq/minetest/commit/b159e8728f1a6fd12f18a9246b6ac8c767459832 |
| 17:05 |
|
Jordach2 joined #minetest-dev |
| 17:05 |
hmmmm |
hrmmm? whose is that |
| 17:06 |
jin_xi |
im obneq on github |
| 17:07 |
hmmmm |
how different is that from the current l-systems treegen |
| 17:07 |
jin_xi |
http://i.imgur.com/qhWjgHq.png this is a test biome made with it... |
| 17:07 |
hmmmm |
is it almost the same thing, with more rules added and generalized? |
| 17:07 |
jin_xi |
basically without rules/recursion and arbitrary angle and material |
| 17:08 |
jin_xi |
then programs generated with lua |
| 17:08 |
hmmmm |
ah |
| 17:08 |
hmmmm |
see, i need l-systems to be complete |
| 17:09 |
hmmmm |
you just pass in the nodes you wish to use, the axioms, and bam, it generates |
| 17:09 |
hmmmm |
in particular i'm avoiding doing any computations in lua |
| 17:11 |
hmmmm |
any callbacks to lua* i should say |
| 17:11 |
jin_xi |
this is the lua i used http://pastebin.com/HdhMJ8FK |
| 17:13 |
jin_xi |
i see the point about avoiding lua in mapgen, but it makes for more interesting stuff with some randomisation |
| 17:13 |
hmmmm |
the plan was to have the randomization along with the rules somehow |
| 17:14 |
jin_xi |
and some terrain detection... and conditionals and... |
| 17:14 |
hmmmm |
and how do the turtle graphics work out for you? is it slow? |
| 17:17 |
jin_xi |
i have only used it via tool, its fast enough but not very reliable |
| 17:17 |
jin_xi |
you end up with some empty blocks |
| 17:17 |
hmmmm |
now in your lua, where is structdef defined? |
| 17:18 |
jin_xi |
on top, line 15ff |
| 17:18 |
hmmmm |
aah |
| 17:18 |
hmmmm |
i missed that |
| 17:20 |
jin_xi |
well, axioms also get unwieldy... i tried making a forth in lua to make this stuff more compact, but i realize thats crazy |
| 17:20 |
hmmmm |
hmmmmmmmmmmm |
| 17:21 |
hmmmm |
what do personally you think i should do here? |
| 17:21 |
hmmmm |
i am thinking of having at least three different "placement types" for decorations |
| 17:21 |
hmmmm |
one is simple, involving no l-systems at all |
| 17:21 |
hmmmm |
another is using the current treegen |
| 17:21 |
hmmmm |
the third is this turtle system |
| 17:22 |
jin_xi |
one for fixed schematics would be good too |
| 17:22 |
jin_xi |
like worldedit saves |
| 17:22 |
hmmmm |
for decoration placement, or specifically l-systems? |
| 17:23 |
jin_xi |
for decoration, to place stuff that is always the same |
| 17:23 |
hmmmm |
well actually that's what i had in mind at first |
| 17:24 |
jin_xi |
oh i see |
| 17:24 |
hmmmm |
people told me that with l-systems, though, it's kind of useless |
| 17:43 |
jin_xi |
current l-systems are pretty limited: only one angle is the most cumbersome limitation imo. i dont think l-system as it is can replace schematic placement type |
| 17:53 |
|
StrayBytes joined #minetest-dev |
| 17:54 |
|
Guest89133 joined #minetest-dev |
| 18:07 |
|
jojoa1997 joined #minetest-dev |
| 18:36 |
|
serengeor joined #minetest-dev |
| 18:47 |
|
jojoa1997 joined #minetest-dev |
| 18:49 |
hmmmm |
alright |
| 18:49 |
jojoa1997 |
hi all |
| 18:49 |
hmmmm |
so for simplicity's sake, i'll just have three types, "simple", where you specify a number of some nodes to be placed vertically |
| 18:49 |
hmmmm |
then there's the "schematic" type, which we'll need |
| 18:49 |
hmmmm |
then treegen's l-systems |
| 18:50 |
hmmmm |
as for the schematic format, i'm still open to suggestions |
| 18:50 |
hmmmm |
i really would like to avoid something completely text-based because it'd get ridiculous very quickly |
| 18:53 |
jin_xi |
sfan5: didn't you start working on a binary worldedit save format? |
| 18:53 |
sfan5 |
yes |
| 18:53 |
sfan5 |
i did |
| 18:53 |
sfan5 |
but binary operations in lua are a pity |
| 18:53 |
jin_xi |
ah i see |
| 18:54 |
sfan5 |
i fear i accidently deleted the .lua file.. |
| 18:54 |
hmmmm |
how would people edit these, do you think? |
| 18:54 |
hmmmm |
that's the main thing |
| 18:55 |
hmmmm |
see, using images would be a happy medium between ease of use and verbosity |
| 19:01 |
jin_xi |
what kind of images? floor plans or diagrams? |
| 19:01 |
hmmmm |
lol |
| 19:01 |
jin_xi |
thats what i thought |
| 19:02 |
hmmmm |
you somehow define what node each color pixel you're using is |
| 19:02 |
hmmmm |
and then you have a slice from the bottom up of what's being placed |
| 19:02 |
jin_xi |
a gif |
| 19:05 |
sfan5 |
gif has a limited palette |
| 19:05 |
sfan5 |
what about apng |
| 19:06 |
|
iqualfragile1 joined #minetest-dev |
| 19:06 |
hmmmm |
how about png |
| 19:06 |
hmmmm |
:/ |
| 19:07 |
hmmmm |
really don't need to go overboard here |
| 19:07 |
hmmmm |
and this is just a random, stupid idea |
| 19:07 |
hmmmm |
it's not like we're definitely using images |
| 19:08 |
sfan5 |
if there was any good lua library for dealing with 2^x bit numbers saved as y 8bit numbers, i'd add a binary schematic format |
| 19:16 |
RealBadAngel |
http://bitop.luajit.org/ |
| 19:17 |
RealBadAngel |
btw, if youre using luajit it shall mean it is built-in, but i havent tested it yet |
| 19:20 |
|
Jordach3 joined #minetest-dev |
| 19:21 |
|
jojoa1997 joined #minetest-dev |
| 19:27 |
|
emptty joined #minetest-dev |
| 19:35 |
|
Jordach joined #minetest-dev |
| 19:35 |
|
Jordach joined #minetest-dev |
| 19:51 |
|
Jordach2 joined #minetest-dev |
| 19:52 |
kahrl |
sfan5: if schematics are going to be used in decorationdef anyway, there's no reason not to implementing reading/writing them in C++ |
| 19:52 |
kahrl |
I think |
| 19:53 |
sfan5 |
yeah, but it would be nice if some external mod (e.g. wordedit) could also load them |
| 19:53 |
kahrl |
I mean adding an API function for that |
| 19:53 |
sfan5 |
okay, that would solve it the easy way |
| 19:54 |
sfan5 |
i guess meta won't be needed |
| 19:54 |
kahrl |
hmm |
| 19:55 |
sfan5 |
it is possible to serialize lua tables in a binary format, but that'd make everything more complicated |
| 19:55 |
kahrl |
allowing to make chests would be nice but I guess it can be added later |
| 19:56 |
kahrl |
well, from C++ you could simply call NodeMetaRef::serialize() |
| 19:57 |
kahrl |
but you would probably be using a VoxelManipulator so it would be more complicated |
| 19:57 |
sfan5 |
yeah |
| 20:02 |
hmmmm |
? |
| 20:02 |
hmmmm |
chests will be done manually in lua on callback |
| 20:04 |
hmmmm |
you'd have your schematic, have that placed, then since a callback is requested on placement of that decoration, it'll pass the point at which that decoration had been placed to lua, where you can then manually create a chest with add_node and set the chest contents yourself |
| 20:05 |
sfan5 |
not the best solution, but it works |
| 20:05 |
hmmmm |
what is the best solution then? |
| 20:05 |
hmmmm |
pray tell |
| 20:05 |
kahrl |
with l-systems the chest position might be randomized, right? |
| 20:05 |
kahrl |
idea: |
| 20:05 |
kahrl |
add a l-systems command to record the current position. which will then be passed to the callback |
| 20:06 |
hmmmm |
that's possible and easily done |
| 20:06 |
kahrl |
(+ maybe a command for recording the orientation) |
| 20:06 |
hmmmm |
and l-system specific |
| 20:07 |
hmmmm |
on the other hand if you're using a schematic, you know where your chest was placed anyway |
| 20:07 |
|
Jordach joined #minetest-dev |
| 20:07 |
kahrl |
yeah |
| 20:07 |
hmmmm |
and i'm not going to add the lua position callback queue to voxelmanipulator like i originally said i was |
| 20:07 |
hmmmm |
that's stupid |
| 20:08 |
hmmmm |
i'll just pass it as a result of makechunk along with the heightmap |
| 20:17 |
sfan5 |
my suggestion for a schematic format: http://pastie.org/7734617 (the worldedit binary format would've been almost the same) |
| 20:21 |
|
emptty joined #minetest-dev |
| 20:32 |
|
emptty joined #minetest-dev |
| 20:33 |
|
thexyz joined #minetest-dev |
| 21:07 |
|
mrtux joined #minetest-dev |
| 21:15 |
|
mrtux joined #minetest-dev |
| 21:32 |
|
jojoa1997 left #minetest-dev |
| 22:02 |
hmmmm |
ahhh |
| 22:02 |
hmmmm |
now that is a good idea |
| 22:02 |
hmmmm |
how do you make a schematic? |
| 22:03 |
hmmmm |
you just build it manually in minetest and then save it as a schematic |
| 22:05 |
hmmmm |
i'm definitely sure that a binary file format is the right way to go with this, now |
| 22:05 |
hmmmm |
i'm not going to town with the existing minetest serialization functions or anything like that for obvious reasons |
| 22:07 |
hmmmm |
but i disagree on mostly everything in sfan's proposed format |
| 22:11 |
|
jojoa1997 joined #minetest-dev |
| 22:19 |
hmmmm |
http://pastebin.com/A8QH0Ytk |
| 22:39 |
kaeza |
hmmmm, a general purpose serialization format that does not resort to executing Lua code, and perfectly passes as a string (to be used as metadata) would be awesome |
| 22:40 |
hmmmm |
it would be, wouldn't it |
| 22:40 |
hmmmm |
why don't you just tack that onto the end of my format |
| 22:41 |
hmmmm |
oh, you want me to do all of your work for you so you don't have to do more coding on your own in your mod |
| 22:42 |
kaeza |
lol wut |
| 22:42 |
|
jojoa1997 joined #minetest-dev |
| 22:42 |
kaeza |
I'm just thinking aloud |
| 22:43 |
kaeza |
we are a bit on the offensive side are we? |
| 22:45 |
hmmmm |
there is already a general format |
| 22:46 |
hmmmm |
this is almost like the mapblock format in fact, but this is stripped down for a single purpose in particular |
| 22:46 |
kaeza |
I know |
| 22:46 |
hmmmm |
i don't want to get complicated here |
| 22:47 |
kaeza |
and the binary format will (most likely) make things faster in the order of magnitude |
| 22:47 |
hmmmm |
this does something in particular, and it does it very well |
| 22:47 |
hmmmm |
i can already tell people are going to use this for worldedit more than map generation --; |
| 22:48 |
hmmmm |
and you're going to nag me to add in things that would be better to have for worldedit but not make much sense for what i'm actually using it for |
| 22:48 |
kaeza |
nope... didn't say that |
| 22:48 |
hmmmm |
not you in particular |
| 22:48 |
hmmmm |
i mean people in general |
| 22:50 |
hmmmm |
and then i'm going to become responsible for all things related to this everybodys' abuse of the feature |
| 22:50 |
hmmmm |
to this and* |
| 22:52 |
kaeza |
Abuse (in this context) is something good sometimes |
| 22:52 |
hmmmm |
a disclaimer: i will not help people use schematic files for worldedit! i will not add features for making the job of worldedit's developers easier! if you want to store node metadata and other things, get creative and find a way on your own |
| 22:55 |
|
bcnjr5 joined #minetest-dev |
| 23:11 |
bcnjr5 |
$ba1 |
| 23:12 |
bcnjr5 |
$$ba1 |
| 23:12 |
bcnjr5 |
darn |
| 23:12 |
PilzAdam |
wtf? |
| 23:12 |
bcnjr5 |
nvm |
| 23:30 |
|
bcnjr5 left #minetest-dev |
| 23:36 |
kahrl |
anyone still in the shape for some algorithm discussion? |
| 23:37 |
kahrl |
I wrote a proposal how the optional dependency resolve could work. http://paste.dy.fi/MyA |
| 23:37 |
kahrl |
resolver* |
| 23:38 |
kahrl |
if anyone finds a bug please tell me :D |
