| Time |
Nick |
Message |
| 00:01 |
Out`Of`Control |
\0/ |
| 00:01 |
|
ChimneySwift joined #minetest |
| 00:01 |
MinetestBot |
ChimneySwift: Sep-21 16:15 UTC <paramat> 'register_on_generated' is called once per mapchunk, after that mapchunk generates |
| 00:14 |
|
Out`Of`Control joined #minetest |
| 00:15 |
|
Out`Of`Control joined #minetest |
| 00:24 |
Out`Of`Control |
Hi. How do i force client to store media? So it does not download whole media on each connect. |
| 00:24 |
Out`Of`Control |
there was an option can't find it |
| 00:24 |
rubenwardy |
It already does |
| 00:25 |
mrchiantos |
Cdn |
| 00:25 |
mrchiantos |
Or not ... I go sleep |
| 00:26 |
Out`Of`Control |
rubenwardy: how? what line was it in config |
| 00:26 |
rubenwardy |
it's not a line in the config |
| 00:26 |
rubenwardy |
it's how Minetest works |
| 00:27 |
Out`Of`Control |
rubenwardy: well my client download whole media on each connect. It was not like this time ago |
| 00:27 |
rubenwardy |
sounds like a bug |
| 00:27 |
rubenwardy |
is there the same network usage each time? |
| 00:27 |
rubenwardy |
like |
| 00:27 |
Out`Of`Control |
yes |
| 00:27 |
rubenwardy |
delete the cache ( ~/.cache/minetest/ ) |
| 00:27 |
rubenwardy |
then see if it does more network |
| 00:27 |
Out`Of`Control |
looks as cache get deleted on each reconnect |
| 00:28 |
Out`Of`Control |
rubenwardy: downloading media takes very long on each startup |
| 00:29 |
Out`Of`Control |
ok so i can't turn that on/off its auto |
| 00:29 |
Out`Of`Control |
thanks |
| 00:33 |
rubenwardy |
file a report, Out`Of`Control |
| 00:33 |
rubenwardy |
what version? |
| 00:34 |
mrchiantos |
Good night |
| 00:35 |
Out`Of`Control |
rubenwardy: i have one from debian repo, other compiled same version |
| 00:35 |
Out`Of`Control |
compiled run_in_place works fine |
| 00:36 |
Out`Of`Control |
rubenwardy: maybe has to do with some settings on my system Debian |
| 00:39 |
|
grumble joined #minetest |
| 00:39 |
ChimneySwift |
if you have a slow drive the media download section will take a long time regardless of if you have it all or not |
| 00:40 |
Out`Of`Control |
ssd |
| 00:42 |
ChimneySwift |
it still won't be instant to finish. It needs to read the cache on each connect |
| 01:02 |
|
VanessaE joined #minetest |
| 01:40 |
|
Tmanyo joined #minetest |
| 02:45 |
|
paramat joined #minetest |
| 02:52 |
|
Ruslan1 joined #minetest |
| 03:57 |
|
ssieb joined #minetest |
| 04:10 |
|
TC01 joined #minetest |
| 05:26 |
|
Neoniet joined #minetest |
| 05:44 |
|
Scotty_Trees joined #minetest |
| 06:14 |
|
nowhere_man joined #minetest |
| 06:30 |
|
nowhereman joined #minetest |
| 06:44 |
|
CWz joined #minetest |
| 07:40 |
|
Gael-de-Sailly joined #minetest |
| 08:19 |
|
jluc joined #minetest |
| 08:37 |
|
Darcidride joined #minetest |
| 08:42 |
|
illwieckz joined #minetest |
| 09:41 |
|
Fulgen joined #minetest |
| 10:53 |
|
Krock joined #minetest |
| 11:17 |
|
Fixer joined #minetest |
| 11:39 |
|
jluc joined #minetest |
| 11:42 |
|
calcul0n joined #minetest |
| 11:59 |
|
Jordach joined #minetest |
| 12:02 |
|
Nemin joined #minetest |
| 12:04 |
Nemin |
Hello. Could somebody please explain to me how 'minetest.delete_area' works? I'm trying to make an item that would delete a large box of Nodes when you click somewhere, yet it does nothing. |
| 12:05 |
Nemin |
(Here's the code I'm trying to use: https://0bin.net/paste/cmJEIYu9tKQKLJ-P#UMU12StQwm7pf6SICqwMC0zAYF82oGug8dMi36-LZFA ) |
| 12:15 |
sfan5 |
looks correct to me |
| 12:28 |
Nemin |
Yet it does not work. I replaced it with a three-level nested loop and that one works, but I assume this one would be quicker / more efficient |
| 12:29 |
ChimneySwift |
it doesn't actually delete nodes, it removes the area from the map so it gets regenerated right? |
| 12:29 |
sfan5 |
that's what it does yes |
| 12:30 |
Nemin |
Oh... So I totally misunderstood what it stands for |
| 12:30 |
Nemin |
Well thank you this does explain it |
| 12:31 |
|
Krock joined #minetest |
| 13:23 |
|
norkle joined #minetest |
| 13:36 |
|
calcul0n joined #minetest |
| 13:51 |
|
Ruslan1 joined #minetest |
| 15:37 |
|
hecks joined #minetest |
| 15:43 |
hecks |
https://a.uguu.se/ZdBfm17Eh8cp_tree.png |
| 15:44 |
hecks |
I need some lsystem guru to help me generate this normally |
| 15:52 |
hecks |
maybe I should just generate a set of decos instead |
| 15:52 |
sfan5 |
that would be easier |
| 15:53 |
sfan5 |
there are few people that are experienced with lsystem, paramat is one of them |
| 15:53 |
rubenwardy |
also Wuzzy |
| 15:53 |
hecks |
from the description of the operators, lsystem seems ill-fit for minetest's scale |
| 15:53 |
rubenwardy |
lsystems are a common thing though, not minetest specific |
| 15:53 |
rubenwardy |
they're good for certain things |
| 15:54 |
rubenwardy |
but decos will give more control |
| 15:54 |
hecks |
I kinda know what a "turtle" is |
| 15:54 |
hecks |
but decos will probably be easier |
| 15:54 |
hecks |
and likely more efficient |
| 16:19 |
|
Fulgen joined #minetest |
| 16:52 |
|
paramat joined #minetest |
| 16:56 |
paramat |
hecks best avoid l-system for mapgen decorations. each placed l-system structure does it's own lighting update afterwards, instead of bulk l-system decoration placement followed by a single light update for the mapchunk |
| 16:56 |
hecks |
ow |
| 16:56 |
hecks |
well I'm already doing schematics |
| 16:57 |
paramat |
they're only practical for occasionally placing single structures after mapgen |
| 16:58 |
paramat |
good, see https://github.com/minetest/minetest_game/blob/master/schematic_tables.txt |
| 16:58 |
|
lisac_ joined #minetest |
| 17:05 |
hecks |
are these upside-down XY slices? |
| 17:08 |
paramat |
yes |
| 17:08 |
paramat |
although there does exist a function that will auto-flip them on read |
| 17:09 |
|
lisac__ joined #minetest |
| 17:09 |
paramat |
making upright slices possible in the table |
| 17:10 |
hecks |
kinda inconvenient, but I already made a converter from XZ slices |
| 17:12 |
paramat |
in case useful mine is https://github.com/paramat/mtgschems/blob/a9ed33133994a046532fdc16667abf6415aa37df/init.lua#L21 |
| 17:44 |
|
mrchiantos joined #minetest |
| 17:46 |
hecks |
this could use a mention in the docs; you need to register biomes first, then decos |
| 17:46 |
hecks |
otherwise decos don't appear and emerge may crash the game on exit |
| 17:49 |
|
illwieckz joined #minetest |
| 17:52 |
paramat |
hm ok |
| 17:55 |
Ingar |
minetest does schematics ? |
| 18:10 |
mrchiantos |
In World's /schems with worldedit |
| 18:11 |
mrchiantos |
paramat i have see your post. Your game un android ... I have cant test road. This is only Mapgen mod ? |
| 18:12 |
mrchiantos |
Game crash |
| 18:12 |
mrchiantos |
Nil value |
| 18:16 |
hecks |
why can't the mapgen place decos at a consistent height? |
| 18:16 |
Krock |
"nil value" can be everywhere. provide logs please. |
| 18:16 |
hecks |
if the offset is at 0, half the trees are hammered into the ground and have no roots |
| 18:17 |
hecks |
if the offset is 1, half the trees hover above the ground |
| 18:19 |
hecks |
oh wait, hold on |
| 18:19 |
hecks |
think I got a clue https://a.uguu.se/Nkx84vH1bIUl_uhhuh.png |
| 18:27 |
|
lisac joined #minetest |
| 18:35 |
mrchiantos |
https://framabin.org/p/?f6110a24b8505867#6So1/JctMe1X3IATiNsmg0bE9WSnkKteIrVIGq4jHQ8= |
| 18:36 |
mrchiantos |
For problem with superminecart |
| 18:38 |
mrchiantos |
Krock, game of paramat |
| 18:38 |
|
rafalcpp joined #minetest |
| 18:39 |
|
minduser00 joined #minetest |
| 18:43 |
hecks |
now my trees are making minetest run out of memory |
| 18:43 |
mrchiantos |
Use décorate mts on Mapgen |
| 18:43 |
mrchiantos |
I use this for tree |
| 18:44 |
hecks |
these are lua table decos |
| 18:44 |
mrchiantos |
Mmm |
| 18:45 |
hecks |
https://a.uguu.se/vLHuj0JjedCi_trees.png |
| 18:45 |
hecks |
9 x 9 x whatever |
| 18:46 |
hecks |
it's not like they're much more complex than mtg's jungle trees |
| 18:47 |
mrchiantos |
This is a mts ? |
| 18:51 |
hecks |
lua table |
| 18:53 |
paramat |
looking |
| 18:54 |
paramat |
mrchiantos my game may only work on 5.0.0 dev |
| 18:56 |
MinetestBot |
[git] SmallJoker -> minetest/minetest: Make OpenGL preference configurable, default to LEGACY (#7666) 785f68e https://git.io/fAdXI (2018-09-22T18:54:43Z) |
| 18:56 |
hecks |
aaaaaa https://a.uguu.se/4VZOjJXvfulw_fffff.png |
| 18:57 |
paramat |
hecks i can look at your code if you link |
| 18:57 |
paramat |
ah using luajit? |
| 18:57 |
paramat |
anyway decorations should not cause OOM, something is wrong |
| 18:57 |
hecks |
there's almost nothing here to look at, and yes |
| 18:57 |
hecks |
it's doing that with 6GB physical in the bank |
| 18:58 |
hecks |
I compiled this myself so there could be gremlins |
| 18:58 |
hecks |
the decos are kinda big and the more I spawn, the sooner it goes OOM |
| 18:59 |
hecks |
I'm also using threaded emerge, will try disabling |
| 19:00 |
paramat |
big decos shouldn't cause a problem, MTG has some huge rainforest trees |
| 19:01 |
hecks |
and there it goes |
| 19:01 |
mrchiantos |
On Github, this write 0.4.16 |
| 19:01 |
hecks |
yeah, jungle trees are big and jungles are quite thick |
| 19:01 |
mrchiantos |
Maybe change description ... |
| 19:01 |
hecks |
emerge threads do not affect it |
| 19:02 |
hecks |
the only thing that affects it is fill_ratio, the bigger it is the sooner it goes kablooey |
| 19:03 |
mrchiantos |
superminecart 0.1.5 by paramat.A game for Minetest Engine 0.4.16 and later. |
| 19:03 |
mrchiantos |
Change for 0.5dev only ? |
| 19:03 |
mrchiantos |
paramat |
| 19:04 |
Krock |
yes, it requires 5.0-dev |
| 19:05 |
Krock |
topic is probably outdated |
| 19:05 |
hecks |
https://a.uguu.se/QiqiMkcLXtFW_woods.png ech |
| 19:05 |
paramat |
yeah will do |
| 19:05 |
hecks |
sometimes it quits without even giving me the crash |
| 19:05 |
Krock |
[moe intensifies] |
| 19:05 |
paramat |
i think my game worked with stable at one point but now doesn't |
| 19:05 |
paramat |
0.4.16 is such ancient history it's annoying to code for |
| 19:06 |
hecks |
https://a.uguu.se/IPxUQ2tgqsKa_sfdsfds.png |
| 19:07 |
paramat |
it might be best to save the schematic to a .mts file and use that, are you specifying the lua table in the decoration registration? |
| 19:09 |
Krock |
hecks: maybe it's time to do some profiling to figure out what takes so much time to delay the steps |
| 19:09 |
hecks |
Krock: it's mapgen |
| 19:09 |
Krock |
oh |
| 19:09 |
hecks |
of all the things that cause step stalls, mapgen is the worst |
| 19:10 |
hecks |
but really, mt has some scheduling issues; global step is feast or famine |
| 19:10 |
Krock |
well, 80*80*80 nodes mostly under 1s is quite good |
| 19:10 |
hecks |
I can get like 40 seconds without an update sometimes |
| 19:10 |
paramat |
well, something's wrong with what you're doing, it's not standard MT behavioour |
| 19:10 |
paramat |
*behaviour |
| 19:11 |
hecks |
I'm recalculating a dynamic light, it's a little better with that off but still not perfect |
| 19:11 |
hecks |
and I've got that LBM that smooths terrain |
| 19:11 |
paramat |
or you've uncovered a bug somehow |
| 19:11 |
hecks |
maybe, if I were to take a stab, there's something ungodly slow about lighting calculation |
| 19:11 |
Krock |
why an LBM but not on_generate? |
| 19:11 |
paramat |
oh |
| 19:11 |
hecks |
as for the schematic, I'm specifying the table in my own format, then converting it on the fly right before registering |
| 19:11 |
hecks |
oh, it's on_generate |
| 19:11 |
hecks |
not LBM |
| 19:11 |
hecks |
sorry |
| 19:12 |
Krock |
good :) |
| 19:12 |
paramat |
well your fault then :) |
| 19:12 |
hecks |
I smooth things with voxelmanip and then I have to recalc lighting... that's the worst perf hit |
| 19:12 |
hecks |
why aren't lighting calculations deferred until every mod's on_generate has ran, anyway? |
| 19:13 |
paramat |
yes lua stuff 'on generate' can be slow |
| 19:13 |
hecks |
as it is, minetest has to compute lighting twice |
| 19:13 |
paramat |
best stick to engine mapgen |
| 19:13 |
hecks |
smooth terrain is one of the things I can't afford to give up; having to jump like in minecraft makes me retch |
| 19:14 |
hecks |
I've got wheeled carts that need smooth roads |
| 19:14 |
hecks |
there's a delay and an animation when landing from a height above 1n |
| 19:14 |
paramat |
you can delay the lighting calculation to after 'on generate' operations using 'nolight' mapgen flag, avoids the first unnecessary lighting calculation |
| 19:14 |
hecks |
why thank you |
| 19:15 |
paramat |
'why aren't lighting calculations deferred until every mod's on_generate has ran, anyway?' there may be an issue. just not coded yet |
| 19:16 |
paramat |
ah that type of smoothing, i see |
| 19:16 |
paramat |
we have a PR for autojump close to merging |
| 19:16 |
hecks |
it's no big deal, I just check neighbors of each grass node and make it a slab if it's not surrounded |
| 19:16 |
hecks |
it's still yuck |
| 19:17 |
mrchiantos |
Attack IRC have stop ? Good this ... |
| 19:17 |
hecks |
I could just set step height to 1 like voxelgarden but it's still bad |
| 19:17 |
hecks |
anyway, nolight mapgen also disables calc_lighting |
| 19:18 |
paramat |
i'd like to make a core mapgen that smooths with slabs, problem is floating decorations |
| 19:18 |
hecks |
decos can be made to ignore slabs |
| 19:19 |
hecks |
and smoothing can be made to not smooth if there's no air above; that's what mine does |
| 19:19 |
paramat |
hm good point |
| 19:20 |
hecks |
how it ends up looking depends on how you want to smooth; if you want to read the noise and use it, it'll look bad |
| 19:20 |
hecks |
but if you do a box filter like I do, it shouldn't stick out too much |
| 19:21 |
paramat |
'nolight' flag only disables the light calculation in core mapgen, any 'vm:calc_lighting()' in voxelmanip used in 'on generated' still works |
| 19:21 |
hecks |
doesn't for me, what am I missing? |
| 19:21 |
paramat |
hmm |
| 19:21 |
paramat |
will need to see your code |
| 19:21 |
hecks |
https://pastebin.com/BWWfU4mn |
| 19:22 |
hecks |
I tried calc_light before write to map, and after |
| 19:25 |
paramat |
ah try https://github.com/paramat/stability/blob/df6f0eb05daf2a853fd8a645b5ea44e8e06c7115/init.lua#L293 |
| 19:26 |
paramat |
calc lighting may need that custom volume |
| 19:26 |
paramat |
that's a lua mapgen of mine that uses 'nolight' |
| 19:27 |
paramat |
i assume you're not using mgv6 |
| 19:27 |
hecks |
it's v7 |
| 19:28 |
paramat |
it's because non-mgv6 mapgens actually generate from minp.y -1 to maxp.y + 1 |
| 19:28 |
hecks |
it works, and it's faster, as expected |
| 19:29 |
hecks |
I still get stalls though, there's just something wrong with the engine here |
| 19:29 |
hecks |
something is synchronous with the game thread that shouldn't be |
| 19:30 |
hecks |
but things are playable now; when the game generates surrounding blocks and "settles", it'll be fine as long as I travel at a reasonable speed |
| 19:31 |
hecks |
note that this happens in mtg as well; use a boat and see for yourself |
| 19:32 |
hecks |
disk I/O is also not the cause here, I'm running my test worlds in memory |
| 19:33 |
hecks |
anyway, thanks for the light code |
| 19:33 |
hecks |
it plugged one hell of a cycle hole |
| 19:34 |
paramat |
mrchiantos the 'mapgen' mod from my game should work in 0.4.16, try that |
| 19:34 |
paramat |
good |
| 19:34 |
mrchiantos |
Ok ;) |
| 19:35 |
mrchiantos |
I can use only mod Mapgen and update with DriftCar ? |
| 19:35 |
hecks |
would using an .mts for the trees actually speed things up? |
| 19:36 |
mrchiantos |
I think look for road. I like Idea |
| 19:36 |
mrchiantos |
For modify and use |
| 19:37 |
mrchiantos |
The problem this is not really use to android. This very speed , car is very speed for View generwte |
| 19:37 |
paramat |
well i suspect your decoration issue is due to doing it your own way, try copying the MTG approach |
| 19:38 |
mrchiantos |
I like DriftCar , the problem is View generwte ... Car is very speed |
| 19:38 |
paramat |
storing .mts files instead of specifying the lua table in the decoration registration *shouldn't* make a difference but maybe there's a bug or memory leak |
| 19:38 |
mrchiantos |
And android not work |
| 19:39 |
mrchiantos |
After this is à good Idea |
| 19:39 |
hecks |
there shouldn't be a difference once the deco is registered, the only overhead is in init when the table is generated |
| 19:39 |
paramat |
mrchiantos you can use the 'mapgen' mod and use it with 'driftcar' mod yes |
| 19:39 |
hecks |
and I'd ideally like to generate the table in lua, to have some randomness in the trees |
| 19:39 |
|
Gael-de-Sailly joined #minetest |
| 19:39 |
mrchiantos |
I think look for wdd your mod Mapgen |
| 19:39 |
hecks |
I could, of course, generate the trees and dump them to .mts ; I'm doing something like that with the player model already |
| 19:40 |
mrchiantos |
And maybe so village mod |
| 19:41 |
paramat |
the randomness in decorations is caused by the table, storing as .mts makes no difference to that, you still get the randomness |
| 19:41 |
hecks |
by randomness I mean generating some variants of each tree species |
| 19:41 |
mrchiantos |
After hé can use handle-schematics |
| 19:41 |
mrchiantos |
I think for tree |
| 19:42 |
paramat |
ah |
| 19:42 |
mrchiantos |
I use this for boat |
| 19:42 |
mrchiantos |
Mts |
| 19:42 |
paramat |
yes use multiple schematics then |
| 19:43 |
paramat |
in MTG we have big and small pines for example |
| 19:43 |
hecks |
since there's a serialize_schematic function I might as well |
| 19:44 |
mrchiantos |
Yes for jungle tree |
| 19:44 |
hecks |
you said something about a bug or a leak though, uh... what kind of definition should one use for "empty" nodes? |
| 19:44 |
mrchiantos |
Air ? |
| 19:45 |
hecks |
I'm using ignore with prob 0 |
| 19:45 |
hecks |
forgot to check what MTG schematics do |
| 19:45 |
|
Tmanyo joined #minetest |
| 19:45 |
hecks |
{name = "air", prob = 0} |
| 19:45 |
hecks |
not much difference |
| 19:46 |
mrchiantos |
Type = ? |
| 19:46 |
hecks |
schematic nodes don't have such a key |
| 19:55 |
|
jluc joined #minetest |
| 20:03 |
|
paramat joined #minetest |
| 20:05 |
|
Cornelia joined #minetest |
| 20:09 |
paramat |
'ignore' for nothing is fine |
| 20:10 |
paramat |
it will never be placed |
| 20:25 |
mrchiantos |
I have a Idea for mod, use emoji or smileys in game tchat minetest ... |
| 20:25 |
mrchiantos |
Lol ... |
| 20:26 |
mrchiantos |
Ok this is à stupid Idea :D |
| 20:26 |
hecks |
please no |
| 20:27 |
Krock |
please yes, but only when I get a vomiting cowboy and vomiting moon emoji |
| 20:27 |
Krock |
https://imgs.xkcd.com/comics/vomiting_emoji_2x.png |
| 20:28 |
mrchiantos |
No, yes ... Maybe ? Hahahaha |
| 20:28 |
hecks |
not even in jest |
| 20:29 |
hecks |
this is literally the feature that I deemed too horrible to even joke about weeks ago |
| 20:30 |
Krock |
it is time. time to sleep. bai. |
| 20:31 |
hecks |
and I shall stay to solve the mystery of the lost biome |
| 20:42 |
mrchiantos |
Lights Colors ? |
| 20:42 |
mrchiantos |
(hahahaha) |
| 20:47 |
hecks |
paramat: Using .mts does not fix the OOM crashes |
| 20:47 |
hecks |
the only factor in the crashing is the density of the woods, 0.33 being almost instant |
| 20:47 |
hecks |
simple decos do not cause this |
| 20:48 |
hecks |
also I cannot register two decos using one .mts file which is stupid |
| 20:50 |
|
piesquared joined #minetest |
| 20:55 |
mrchiantos |
I dont understand , why two decorste for one mts ? |
| 20:56 |
hecks |
different density in different biomes |
| 20:56 |
|
piesquared joined #minetest |
| 20:56 |
paramat |
hmm |
| 20:57 |
mrchiantos |
Copy mts with other Name ? |
| 20:57 |
mrchiantos |
:D |
| 20:57 |
hecks |
is what I do, it's still dumb |
| 20:58 |
hecks |
could the crashes have something to do with my trees abusing connectable nodeboxes? |
| 20:58 |
hecks |
I found that the crashes seem correlated with the amount of trees that touch one another |
| 20:59 |
mrchiantos |
Your use connectable for tree ? |
| 20:59 |
hecks |
yes, to make them look natural |
| 21:00 |
mrchiantos |
Ouch .. |
| 21:00 |
hecks |
https://a.uguu.se/hOqSW6FKHDPg_treees.png |
| 21:00 |
hecks |
framerate is hardly affected |
| 21:00 |
hecks |
as in, it's fast |
| 21:01 |
paramat |
connected nodeboxes might be a factor, we haven't used those in decorations |
| 21:02 |
paramat |
looks nice |
| 21:03 |
mrchiantos |
With handle-schematics maybe ? |
| 21:03 |
paramat |
no don't worry about handle schematics, it's unrelated |
| 21:04 |
paramat |
whether connected nodeboxes causes oom could be tested, and might be worth an issue |
| 21:04 |
hecks |
then again it's not "oh it just doesn't work" |
| 21:04 |
mrchiantos |
I see |
| 21:04 |
hecks |
when I limit my vision range, it doesn't crash |
| 21:05 |
hecks |
so it could be just an overload thing |
| 21:05 |
hecks |
and maybe it happens fast enough that I can't catch it when monitoring memory |
| 21:05 |
hecks |
easy fix; handle connectables after emerge is done |
| 21:12 |
|
piesquared joined #minetest |
| 21:14 |
|
piesquared joined #minetest |
| 21:15 |
|
piesquared joined #minetest |
| 21:17 |
hecks |
well well well |
| 21:17 |
hecks |
it's not connectables |
| 21:17 |
hecks |
still does it after I've changed the leaves to a simple box |
| 21:18 |
|
pietothefirst joined #minetest |
| 21:20 |
paramat |
also we didn't know you can't use 1 .mts file for 2 decos, a quick issue would be useful for that |
| 21:21 |
paramat |
yeah i don't think anyone has placed lots of connectables on mapgen before, and your trees would have a lot |
| 21:21 |
paramat |
oh |
| 21:21 |
paramat |
(catching up with chat) |
| 21:25 |
hecks |
so I'm testing this in every way possible |
| 21:26 |
hecks |
it's something to do with the deco's size, or maybe total node count |
| 21:27 |
hecks |
9x9 1y does not crash |
| 21:27 |
hecks |
9x9 3y can crash |
| 21:27 |
hecks |
5x5 15y also can crash |
| 21:28 |
paramat |
MTG has dense 5x5x16 and is fine |
| 21:28 |
hecks |
17 actually, cause I just checked |
| 21:30 |
hecks |
https://pastebin.com/ghzf9feP |
| 21:31 |
hecks |
little bug; width and depth of the tree should be 9 |
| 21:32 |
hecks |
it generates some blocks, and then gives up |
| 21:33 |
hecks |
butthurt trees indeed |
| 21:34 |
paramat |
fill ratio 0.66? |
| 21:34 |
paramat |
that's almost 1 per node? |
| 21:34 |
hecks |
trying to stress it a little |
| 21:35 |
hecks |
0.1 is enough to make it go tits up |
| 21:35 |
paramat |
ah |
| 21:39 |
paramat |
are you converting a table to .mts every game session? maybe try just storing it and keeping the .mts creating code separate from your game |
| 21:39 |
hecks |
does not matter |
| 21:39 |
paramat |
don't know if that would help but maybe a clue |
| 21:39 |
hecks |
init.lua only runs when the server starts doesn't it |
| 21:39 |
paramat |
yes |
| 21:39 |
hecks |
and it crashed with a table too, this was just to test if mts is any better |
| 21:40 |
hecks |
lastly, for my purposes I would eventually have to generate the .mts dynamically |
| 21:40 |
hecks |
at least in init |
| 21:40 |
hecks |
but that's moot as long as even static decos refuse to work |
| 21:41 |
paramat |
anyway for your smoothing code that can be memory-optimised: point 3 here https://forum.minetest.net/viewtopic.php?f=18&t=16043 |
| 21:42 |
hecks |
do I have to preallocate said buffer? |
| 21:43 |
hecks |
or is an empty table enough |
| 21:43 |
paramat |
so 'vm:get_data(buffer)'. empty table is fine |
| 21:43 |
hecks |
done and done |
| 21:49 |
hecks |
okay, this greatly reduced the crash rate |
| 21:49 |
hecks |
the mapgen is still eating a server rack's worth of memory |
| 21:49 |
hecks |
and freeing little of it |
| 21:50 |
hecks |
let's see... the woods are 0.1 thick now and I'm standing in the middle with 150 nodes draw distance |
| 21:50 |
hecks |
minetest is using 4GB memory |
| 21:51 |
hecks |
up to 5 gigs now |
| 21:52 |
hecks |
I went back to the boring lowlands, and the memory stays at 5gb |
| 21:52 |
paramat |
isn't that client meshes? |
| 21:53 |
hecks |
is there some ingame profiler for memory where I can check this? |
| 21:54 |
paramat |
perhaps generating a large volume of decorations actually makes OOM more likely, and if MTG upped tree density and size it would OOM too, hmm |
| 21:55 |
hecks |
I just wanted to say, I think I did OOM a few times in a "normal" world |
| 21:55 |
hecks |
that is, MTG with ethereal and a few other things |
| 21:55 |
paramat |
because your trees have connected nodeboxes the meshes will be very complex and memory-intensive |
| 21:57 |
paramat |
yes some mods can cause OOM if you're using luajit |
| 21:57 |
hecks |
I'm sure this isn't lua related |
| 21:57 |
paramat |
lua mapgens and use of noise buffers are the main causes, many still don't have the memory optimisations i have detailed |
| 21:58 |
hecks |
well, we fixed what there was to fix, it did sort of improve things |
| 21:59 |
hecks |
anyway, if the mesher naively creates a unique model for a whole mapblock, this could be a plausible cause for the rest of the memory issues |
| 21:59 |
paramat |
well, MT's well-known OOM problems are caused by the luajit memory limit and lua code |
| 22:00 |
hecks |
I don't think I used a build with jit for playing vanilla back when I encountered the aforementioned crashes |
| 22:00 |
hecks |
I explored a lot though, and the crashes happened around jungles |
| 22:00 |
paramat |
i don't think MT has ingame memory profiling |
| 22:00 |
hecks |
well |
| 22:01 |
hecks |
for now I'll assume the memory issue was twofold; reusing the manip buffer helped somewhat, the rest is related to the amount of geometry |
| 22:01 |
paramat |
:) |
| 22:01 |
hecks |
running the server in a separate machine would confirm this |
| 22:07 |
Fixer |
if you have OOM errors, try running it with GC64 version of luajit |
| 22:07 |
Fixer |
or simple lua version (slower) |
| 22:17 |
hecks |
kinda late to the party |
| 22:28 |
|
rafalcpp joined #minetest |
| 22:32 |
|
ChimneySwift joined #minetest |
| 22:43 |
|
Scotty_Trees joined #minetest |
| 22:51 |
|
Ruslan1 joined #minetest |
| 23:18 |
|
ChimneySwift joined #minetest |
| 23:21 |
|
Guest25977 joined #minetest |
| 23:35 |
|
Hawk777 joined #minetest |
| 23:46 |
|
BakerPrime joined #minetest |
