| Time |
Nick |
Message |
| 00:26 |
|
Void7 joined #minetest-dev |
| 00:44 |
|
proller joined #minetest-dev |
| 00:59 |
|
UlamTheLucky joined #minetest-dev |
| 01:02 |
|
rubenwardy joined #minetest-dev |
| 01:06 |
|
Tmanyo joined #minetest-dev |
| 01:15 |
paramat |
game#1450 bugfix for missing sound |
| 01:15 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1450 -- Default: Add missing 'default_dig_snappy' sound by paramat |
| 01:38 |
|
octacian_ joined #minetest-dev |
| 01:43 |
|
torgdor joined #minetest-dev |
| 02:45 |
|
Tmanyo joined #minetest-dev |
| 03:41 |
|
Wayward_One joined #minetest-dev |
| 03:45 |
|
octacian__ joined #minetest-dev |
| 03:50 |
|
turtleman joined #minetest-dev |
| 04:31 |
|
Tmanyo joined #minetest-dev |
| 04:45 |
|
garywhite joined #minetest-dev |
| 04:56 |
|
Eater4 joined #minetest-dev |
| 05:07 |
|
lhofhansl joined #minetest-dev |
| 05:08 |
|
proller joined #minetest-dev |
| 05:16 |
|
paramat joined #minetest-dev |
| 06:16 |
|
octacian__ joined #minetest-dev |
| 06:22 |
|
proller joined #minetest-dev |
| 06:49 |
|
lumidify joined #minetest-dev |
| 07:10 |
|
nrzkt joined #minetest-dev |
| 08:23 |
lhofhansl |
Just filed #4877 |
| 08:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/4877 -- Limit Active Block Range to what player can see. Retrieve a spherical volume. by lhofhansl |
| 08:23 |
lhofhansl |
another optimization based on the player |
| 08:24 |
lhofhansl |
the player's view range. This time of about active blocks. |
| 08:24 |
|
Karazhan joined #minetest-dev |
| 08:24 |
lhofhansl |
s/of/it's/ |
| 08:25 |
hmmmm |
http://dev.minetest.net/Code_style_guidelines#If_statements |
| 08:27 |
hmmmm |
as for the actual PR |
| 08:28 |
hmmmm |
i don't feel like it's an optimization, this is just making the active block range shorter. that causes different problems.. a better optimization would be to make running ABMs less costly, so that larger ranges can be used |
| 08:29 |
lhofhansl |
OK... "if (range <= 0) range = active_block_range" is really the same as "range = range <= 0 ? active_block_range : range" so it seems one line is fine. Can do two lines. |
| 08:29 |
hmmmm |
for those types of statement MYMIN(), MYMAX() or rangelim() would be preferred |
| 08:29 |
hmmmm |
statements |
| 08:29 |
lhofhansl |
hmmmm: it lets you increase active_block_range and still get decent behavior with clients that do not use the full range. |
| 08:30 |
lhofhansl |
right now active_block_range defaults to 2 which is quite small. With that one can set it higher. |
| 08:30 |
hmmmm |
the client sets the active block range? |
| 08:31 |
lhofhansl |
no the server does. Now that value can be a increase a bit. |
| 08:31 |
lhofhansl |
It's weird when active objects just disappear when you just 40 or so blocks away. |
| 08:32 |
hmmmm |
set higher |
| 08:32 |
lhofhansl |
this aligns it with what you can actually see on the client, up to the setting. |
| 08:32 |
hmmmm |
because with a spherical range it lops off the edges |
| 08:32 |
hmmmm |
? |
| 08:32 |
lhofhansl |
Same as #4811 which did this for active objects only. |
| 08:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/4811 -- Optimize/adjust blocks/ActiveObjects sent at the server based on client settings. by lhofhansl |
| 08:32 |
hmmmm |
if you increase the range to 3 or something that's still going to be strictly greater than a cuboid of 2 |
| 08:33 |
hmmmm |
well that PR is different from this PR |
| 08:34 |
lhofhansl |
Yep. There're parts: (1) retrieve a sphere (saves about 40% of objects to process), and (2) take the clients view range into account and do not process things that client cannot see anyway. |
| 08:34 |
hmmmm |
the ABM catchup code doesn't account for blocks outside of the active block range, does it |
| 08:34 |
hmmmm |
only blocks loaded from an unloaded state |
| 08:34 |
lhofhansl |
right |
| 08:35 |
|
Hunterz joined #minetest-dev |
| 08:35 |
hmmmm |
so your chief complaint was that the client would be able to see a block become inactive even though it's still within sight range |
| 08:35 |
lhofhansl |
so active_block_range is upper limit set by the server. If the client sees less it's not processed. |
| 08:36 |
lhofhansl |
Yep... And there's no one good setting for the server, because it really depends on how the client can see things. |
| 08:36 |
hmmmm |
okay so this strictly is an optimization in that kind of sense |
| 08:36 |
lhofhansl |
So either things disappear or they are unnecessarily processed. |
| 08:37 |
hmmmm |
for block sending, active object sending, and now you want active block modifiers, you want it so that if the player can't see it, you don't need to do it |
| 08:37 |
hmmmm |
whereas if the client has a view range greater than the max set by the server config, they can still see it |
| 08:37 |
hmmmm |
but what about latency |
| 08:37 |
lhofhansl |
no the server sets the max. |
| 08:37 |
hmmmm |
players can move around quite fast |
| 08:38 |
lhofhansl |
client can only reduce it |
| 08:38 |
hmmmm |
so if you have a max active block range of say 3 |
| 08:38 |
hmmmm |
and the player has a viewing range of 1 |
| 08:39 |
lhofhansl |
same problem as it is now only that the server is "hardcoding" the setting for all clients regardless of how far they can see stuff. |
| 08:39 |
hmmmm |
and the player moves really quickly a block in some direction |
| 08:39 |
lhofhansl |
(it's map blocks, but yeah same point) |
| 08:39 |
hmmmm |
because of the optimization, abms will not have run for the player within that frame of time and there'd be the latency in getting it to start running again |
| 08:39 |
lhofhansl |
that's how it would work, yes |
| 08:40 |
hmmmm |
it's an unfortunate side effect |
| 08:40 |
lhofhansl |
agreed |
| 08:40 |
hmmmm |
but the real problem exists in the slow block sending and ABM running |
| 08:40 |
lhofhansl |
the ABM might be in Lua. can be arbitrarily slow. |
| 08:40 |
hmmmm |
oh of course |
| 08:40 |
hmmmm |
but that's capitalism for mods |
| 08:40 |
lhofhansl |
:) |
| 08:41 |
hmmmm |
they need to stay fast or else they'll get overtaken by the competition |
| 08:41 |
lhofhansl |
At least we should process stuff in a sphere only, not the cuboid. |
| 08:41 |
hmmmm |
or at least in theory... in reality it's still kind of difficult for server administrators to see which mods are causing the lag |
| 08:41 |
hmmmm |
anyway ABMs are usually not that slow |
| 08:42 |
hmmmm |
but what is slow is the node scanning |
| 08:42 |
hmmmm |
iirc i profiled this a while back and the node scanning (which is not lua) takes up a solid 55% of cpu time |
| 08:42 |
lhofhansl |
it you set active_block_range to 5 or 6 it gets quite slow I find. |
| 08:42 |
hmmmm |
but that's with a vanilla minetest_game |
| 08:42 |
hmmmm |
55% of cpu time spent in ABM processing* to clarify |
| 08:43 |
lhofhansl |
If we retrieve a sphere at least, we can default active block range to 3 with about the same number of objects processed. |
| 08:44 |
lhofhansl |
maybe that's all I should change, and get rid of the view_range stuff. |
| 08:44 |
hmmmm |
at such a small radius, these spheres really look like diamonds |
| 08:44 |
hmmmm |
you might be chopping off more blocks than you think |
| 08:44 |
hmmmm |
small integer radius anyway |
| 08:44 |
lhofhansl |
I counted the blocks. Does 93 instead of 125 with the default of 2. |
| 08:45 |
hmmmm |
that's a respectable difference |
| 08:45 |
hmmmm |
125 is the amount with radius = 2, right? |
| 08:45 |
lhofhansl |
yep |
| 08:45 |
hmmmm |
because it's 2+1+2 = 5 for each direction |
| 08:45 |
hmmmm |
right ok |
| 08:46 |
lhofhansl |
exactly 5^3 |
| 08:46 |
hmmmm |
mmm |
| 08:46 |
lhofhansl |
the sphere is a bit less than 4/3*pi*3^3 in that case. |
| 08:46 |
lhofhansl |
(due to the <= check) |
| 08:47 |
hmmmm |
you did the same if (foobar) foobar = 5; thing in the other PR |
| 08:47 |
hmmmm |
dammit |
| 08:47 |
lhofhansl |
yeah |
| 08:47 |
lhofhansl |
happy to change it |
| 08:47 |
hmmmm |
it's not really a big enough deal to warrant a new PR |
| 08:48 |
hmmmm |
it'll get cleaned up in somebody's omni-cleanup commit |
| 08:48 |
hmmmm |
also what's up with making POD typed parameters "const" |
| 08:48 |
hmmmm |
...did nerzhul tell you to do that? |
| 08:49 |
lhofhansl |
somebody commented on that PR to that extend. |
| 08:49 |
lhofhansl |
forgot who |
| 08:49 |
hmmmm |
that's dumb |
| 08:49 |
hmmmm |
it's nerzuhl |
| 08:49 |
hmmmm |
he can't contribute by doing real reviews so he focuses on trivial personal preferences |
| 08:50 |
hmmmm |
i don't review often because reviewing takes real time and effort if you want to be worth more than a static code analyzer |
| 08:50 |
lhofhansl |
what's dumb about it? |
| 08:51 |
OldCoder |
hmmmm, and yet it's necessary |
| 08:51 |
hmmmm |
because who cares if you modify the formal parameter of a function |
| 08:51 |
hmmmm |
nobody is getting hurt by it |
| 08:51 |
hmmmm |
the only time you need to use the const qualifier (with our code standards anyway) is if passing a reference |
| 08:53 |
lhofhansl |
went by the style of the methods around. don't really care |
| 08:53 |
hmmmm |
i feel like i'm wasting my time by discussing such trivial code style matters tbh |
| 08:53 |
hmmmm |
maybe there should be a script that checks submissions |
| 08:53 |
hmmmm |
so i don't need to point anything like this out and instead work on logic |
| 08:54 |
lhofhansl |
it's not wasted time, I think. |
| 08:54 |
lhofhansl |
With a reasonably sized code base these thing become important. |
| 08:54 |
|
ottodachshund joined #minetest-dev |
| 08:56 |
hmmmm |
well i did find at least one real error in your PR |
| 08:56 |
hmmmm |
static const blah foobar = g_settings->getBlah(); <--- see any problems? |
| 08:56 |
lhofhansl |
That's what we reviews for :) |
| 08:56 |
lhofhansl |
but that line I just moved :) |
| 08:57 |
hmmmm |
touche |
| 08:57 |
hmmmm |
you could fix a bug with this PR as well then |
| 08:57 |
lhofhansl |
yep |
| 08:58 |
lhofhansl |
wait... when can this be changed. Not in-game, right? |
| 08:58 |
hmmmm |
no |
| 08:58 |
hmmmm |
hmm |
| 08:58 |
lhofhansl |
I was also told reading from GlobalSettings is slow (probably not an issue here, since it's called once/sec) |
| 08:59 |
hmmmm |
right, it's only inside of loops |
| 08:59 |
hmmmm |
that's the case you should worry about |
| 09:00 |
lhofhansl |
alright... very late here... need to catch some sleep. |
| 09:00 |
hmmmm |
you can modify active_block_range from within a mod or by plizadam's everything-config-page |
| 09:01 |
hmmmm |
with the former you can definitely expose this bug |
| 09:01 |
hmmmm |
ahh no it happens with the latter as well |
| 09:01 |
hmmmm |
it has to modify the active settings in order to get saved to the config file |
| 09:02 |
hmmmm |
so yeah. in two cases you'd be able to modify active_block_range, restart the game, and the old setting will be in effect until you actually close the application and restart. |
| 09:03 |
lhofhansl |
I'll fix that on the way... also adjust the layout of the ifs. |
| 09:03 |
hmmmm |
sure |
| 09:04 |
hmmmm |
you're also missing a const on a parameter passed as a reference btw |
| 09:05 |
|
Hunterz joined #minetest-dev |
| 09:05 |
lhofhansl |
for the &ranges? |
| 09:05 |
hmmmm |
yes |
| 09:05 |
hmmmm |
you're not modifying ranges, are you? |
| 09:06 |
lhofhansl |
Again I went by the surrounding code. Not sure what the wanted style is when everything around it does it differently |
| 09:06 |
hmmmm |
good thing there's a wiki page for it http://dev.minetest.net/Code_style_guidelines |
| 09:07 |
lhofhansl |
I'll fix that too. |
| 09:07 |
lhofhansl |
OK... TTYL... Need to sleep. |
| 09:07 |
|
lhofhansl left #minetest-dev |
| 09:08 |
|
DFeniks joined #minetest-dev |
| 09:10 |
|
lumidify joined #minetest-dev |
| 09:19 |
|
red-001 joined #minetest-dev |
| 09:46 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:52 |
|
blaze joined #minetest-dev |
| 10:12 |
|
AcidNinjaFWHR joined #minetest-dev |
| 10:18 |
|
Wuzzy joined #minetest-dev |
| 10:25 |
|
AcidNinjaFWHR joined #minetest-dev |
| 10:42 |
|
juhdanad joined #minetest-dev |
| 10:47 |
Wuzzy |
Does the Feature Freezeâ„¢ imply a string freeze? |
| 10:56 |
|
jin_xi joined #minetest-dev |
| 11:13 |
|
Darcidride joined #minetest-dev |
| 11:19 |
|
lumidify joined #minetest-dev |
| 11:37 |
|
lumidify joined #minetest-dev |
| 11:37 |
|
milllersman joined #minetest-dev |
| 11:43 |
|
Fixer joined #minetest-dev |
| 12:06 |
Wuzzy |
Are questions about strings (for translation) on-topic here? |
| 12:22 |
|
Darcidride joined #minetest-dev |
| 12:40 |
celeron55 |
has something changed in occlusion culling? |
| 12:40 |
celeron55 |
because i think this is way more broken than i remember this being |
| 12:41 |
celeron55 |
i just dug a straight 3x4 tunnel and MT absolutely refuses to render it |
| 12:42 |
celeron55 |
this is stupid |
| 12:45 |
sfan5 |
there were some changes afaik |
| 12:46 |
sfan5 |
https://github.com/minetest/minetest/commit/2b21cac1d80454bd23c5f60c4570b30edba62584 this? |
| 12:49 |
celeron55 |
seems to be broken before that too; i guess this is just a very unfortunate place for a tunnel |
| 12:51 |
celeron55 |
i wish there was a setting to just plain disable occlusion culling if i want to |
| 12:52 |
|
AntumDeluge joined #minetest-dev |
| 12:52 |
|
sofar joined #minetest-dev |
| 12:53 |
|
Karazhan joined #minetest-dev |
| 12:54 |
celeron55 |
well this is easy to add for sure... |
| 12:55 |
jin_xi |
50 MESE blocks on fps gain |
| 12:58 |
celeron55 |
well in what i'm doing it's 60fps with, 60fps without |
| 13:00 |
celeron55 |
if i run on my dedicated card which allows more than 60, it more than halves the fps (from 130 to 60) |
| 13:01 |
celeron55 |
doesn't matter |
| 13:01 |
celeron55 |
i just want to see this damn tunnel |
| 13:05 |
|
est31 joined #minetest-dev |
| 13:13 |
|
Guest60492 joined #minetest-dev |
| 13:20 |
|
Gael-de-Sailly joined #minetest-dev |
| 13:26 |
|
turtleman joined #minetest-dev |
| 13:55 |
|
STHGOM joined #minetest-dev |
| 14:47 |
|
proller joined #minetest-dev |
| 14:49 |
|
red-001 joined #minetest-dev |
| 14:55 |
|
longerstaff13 joined #minetest-dev |
| 14:56 |
|
longerstaff13 joined #minetest-dev |
| 15:08 |
|
lumidify joined #minetest-dev |
| 15:26 |
|
lumidify joined #minetest-dev |
| 15:27 |
|
proller joined #minetest-dev |
| 16:05 |
VanessaE |
celeron55: you sure it isn't just your view range being too short? |
| 16:06 |
celeron55 |
that's not a relevant question when just disabling the culling already fixed it |
| 16:06 |
* VanessaE |
shrugs |
| 16:09 |
Fixer |
probably celeron selected unlucky spot for tunnel that is prone to occlusion mismatch |
| 16:18 |
|
lhofhansl joined #minetest-dev |
| 16:18 |
lhofhansl |
Updated #4877, I think there's some misunderstanding around it. |
| 16:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/4877 -- Limit Active Block Range to what player can see. Retrieve a spherical volume. by lhofhansl |
| 16:22 |
sfan5 |
spherical sounds fine, increating the active block range would be wonderful |
| 16:22 |
sfan5 |
being able to increase* |
| 16:23 |
lhofhansl |
Maybe I split it into two. Do the spherial in one (which also increased active_block_range's default to 3 map blocks. |
| 16:23 |
lhofhansl |
In the other I do the view-range. Then you can shred the 2nd to pieces :) |
| 16:30 |
|
Amaz joined #minetest-dev |
| 16:37 |
|
longerstaff13 joined #minetest-dev |
| 16:41 |
|
juhdanad joined #minetest-dev |
| 16:49 |
|
Gael-de-Sailly joined #minetest-dev |
| 17:20 |
|
Player_2 joined #minetest-dev |
| 17:33 |
|
xunto left #minetest-dev |
| 17:34 |
|
xunto joined #minetest-dev |
| 17:42 |
|
xunto left #minetest-dev |
| 17:43 |
|
xunto joined #minetest-dev |
| 17:43 |
|
kaeza joined #minetest-dev |
| 17:46 |
|
YuGiOhJCJ joined #minetest-dev |
| 17:55 |
|
garywhite joined #minetest-dev |
| 17:56 |
|
lhofhansl joined #minetest-dev |
| 17:57 |
|
lumidify joined #minetest-dev |
| 18:10 |
lhofhansl |
So is there interest in just doing the spherical part of #4877? |
| 18:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/4877 -- Limit Active Block Range to what player can see. Retrieve a spherical volume. by lhofhansl |
| 18:17 |
sfan5 |
i would +1 that |
| 18:21 |
|
hmmmm joined #minetest-dev |
| 18:33 |
|
AcidNinjaFWHR joined #minetest-dev |
| 18:36 |
lhofhansl |
See #4881 (also increases active_block_range, so that may cause some discussion) |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/4881 -- Process AMBs in a spherical volume instead of a cuboid by lhofhansl |
| 18:36 |
VanessaE |
what's an AMB? :) |
| 18:37 |
lhofhansl |
Oops :) |
| 18:41 |
sfan5 |
lhofhansl: two minor things: nodes not blocks, you can change any settings at runtime via /set |
| 18:41 |
sfan5 |
the question is whether it makes sense for setting changes to go into effect immediately |
| 18:42 |
est31 |
the problem is that it cant be asked for every server step |
| 18:42 |
est31 |
because retrieving settings is very slow |
| 18:42 |
est31 |
the string is not interned |
| 18:42 |
lhofhansl |
that's just called once/sec, though. |
| 18:44 |
juhdanad |
By the way, there are two kinds of ABM: the ones which have a small chance and the ones which are always happen (for example lava cooling). |
| 18:45 |
juhdanad |
The latter should be implemented with node timers IMO. |
| 18:45 |
lhofhansl |
not emotionally attached to the static const change :) |
| 18:46 |
sfan5 |
node timers are specific to a single node though |
| 18:47 |
sfan5 |
you'd need to add/remove them everytime the liquid moves |
| 18:47 |
lhofhansl |
any concerns about increasing active_block_range to 3. Even with the other changes it will double the active blocks to process. (I think that's fine, but wanted to call to that out) |
| 18:47 |
lhofhansl |
s/blocks/nodes/ |
| 18:48 |
sfan5 |
no no |
| 18:49 |
sfan5 |
active_block_range is in blocks |
| 18:49 |
lhofhansl |
Still mostly new Minetest. |
| 18:49 |
sfan5 |
but in "A 5x5x5 cube (range = 2) has 125 blocks." it's nodes |
| 18:49 |
lhofhansl |
I see. |
| 18:49 |
sfan5 |
http://dev.minetest.net/Basic_data_structures |
| 18:51 |
lhofhansl |
Oh OK. I have been referring in my mind to these as blocks and map blocks. Will use nodes. |
| 18:51 |
juhdanad |
sfan5: what I meant: lava flows->lava gets an update->if there is water, calls minetest.after(0) or sets a timer to set itself to stone. |
| 18:51 |
lhofhansl |
the 5x5x5 are map blocks, though, no? The range is given in map blocks. |
| 18:52 |
juhdanad |
water flows->water gets updated->lava gets updated because a neighbor changed->lava transforms itself |
| 18:52 |
sfan5 |
lhofhansl: one map blocks is 16x16x16 |
| 18:52 |
sfan5 |
active_block_range is the range in mapblocks |
| 18:53 |
sfan5 |
juhdanad: you would still need to remove add node timers everytime something changes with the liquids |
| 18:54 |
lhofhansl |
right, in that loop we are enumerating map blocks. |
| 18:54 |
sfan5 |
yes |
| 18:54 |
juhdanad |
It is still faster than scanning trough all nodes in each second. |
| 18:54 |
sfan5 |
how do you know? |
| 18:55 |
lhofhansl |
(anyway, not that important, I get the difference between a node and a map block, had to deal with that in #4811 and #4724, just didn't use the right term here) |
| 18:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/4811 -- Optimize/adjust blocks/ActiveObjects sent at the server based on client settings. by lhofhansl |
| 18:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/4724 -- Improve number of blocks sent and occlusion culling. by lhofhansl |
| 18:56 |
juhdanad |
I only think it can be faster. It is very rare that more than one sixth of all loaded nodes are actually changing liquids. |
| 18:57 |
juhdanad |
And you only need to check one node timer per tick: the one which will be first executed (so you can sort them by execution time). |
| 18:58 |
juhdanad |
So it is effectively checking one node per program cycle if nothing changes. |
| 18:58 |
lhofhansl |
juhdanad: what about you #4847? Seems to be an important fix. |
| 18:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/4847 -- Fix unnecessary block loading by juhdanad |
| 18:58 |
sfan5 |
it's checking zero nodes if a node timer doesn't fire |
| 18:59 |
juhdanad |
And ABMs not only check all nodes, but their neighbors too. |
| 19:00 |
juhdanad |
This is why I think converting to node timers might worth a try. |
| 19:02 |
lhofhansl |
I found when active_block_range is larger ABMHandler.apply becomes the most expensive operation. That's what prompted me to think about the sphere volume and to limit by view-range. |
| 19:02 |
juhdanad |
lhofhansl: it is only important if you are exploring. If all blocks are generated around you then it doesn't make a difference. |
| 19:02 |
juhdanad |
I mean #4847 ^ |
| 19:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/4847 -- Fix unnecessary block loading by juhdanad |
| 19:03 |
lhofhansl |
I see. Will the reloading also create new active objects as Rogier-5 suspects? |
| 19:04 |
sfan5 |
it shouldn't |
| 19:04 |
sfan5 |
however if the objects fall out of the world they might not get deleted when the block is reloaded |
| 19:04 |
juhdanad |
I'm testing it right now. |
| 19:04 |
sfan5 |
i doubt minetest forgets to delete objects when (re-)loading a block |
| 19:04 |
lhofhansl |
OK. Then it does no harm other than increase disk reads (and those would likely come from the page cache anyway) |
| 19:08 |
|
torgdor joined #minetest-dev |
| 19:12 |
juhdanad |
I found it! When the server loads a mapblock, it does not clear static objects. |
| 19:12 |
sfan5 |
it doesn't do that at all or just in this specific case? |
| 19:13 |
juhdanad |
So because not generated blocks with items were loaded multiple times, the loaded items were duplicated. |
| 19:13 |
juhdanad |
sfan5: I don't understand your question. |
| 19:14 |
sfan5 |
does it never clear static objects? |
| 19:14 |
sfan5 |
or does this only happen at the world border? |
| 19:15 |
juhdanad |
It never clears objects. You can have duplicated monsters if they happen to be in a half-generated area. |
| 19:16 |
juhdanad |
I'll push a fix to #4847 soon. |
| 19:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/4847 -- Fix unnecessary block loading by juhdanad |
| 19:29 |
juhdanad |
Pushed! |
| 19:33 |
|
lisac joined #minetest-dev |
| 19:34 |
lisac |
Hello. Is there currently a feature to make gravity pull towards a block in MT? |
| 19:35 |
sfan5 |
no |
| 19:35 |
lisac |
:( |
| 19:35 |
lisac |
Thanks. |
| 19:35 |
juhdanad |
Should the player walk on the side or the bottom of the block, then? |
| 19:36 |
lisac |
Well, I just saw this mod https://forum.minetest.net/viewtopic.php?f=9&t=15933 and wondered if one could make it possible to actually walk on the planets. |
| 19:37 |
juhdanad |
Well, I recommend Spheretest then: https://www.youtube.com/watch?v=ztAg643gJBA |
| 19:39 |
garywhite |
Question: Jeija made that, and although it says about MC, it looks like MT textures |
| 19:40 |
juhdanad |
This is a Minetest fork, the title means 'Minecraft-like world' |
| 19:42 |
garywhite |
ok hang on, does that mean that if it's still basically Minetest under the hood, does that mean that someone could create a Spheretest world that MT clients can join? |
| 19:43 |
juhdanad |
It is Minetest, just the client has a different renderer. |
| 19:44 |
juhdanad |
Oh, and the world is finite. |
| 19:44 |
garywhite |
Hang on, it's just a copy of 0.4.14-dev with a demo world |
| 19:44 |
garywhite |
0.4.14-dev with the old MSVC renderer |
| 19:45 |
garywhite |
& it looks like a freakin cartoon |
| 19:46 |
juhdanad |
Did you follow readme.mt? |
| 19:46 |
garywhite |
no |
| 19:54 |
|
lumidify joined #minetest-dev |
| 20:48 |
|
nrzkt joined #minetest-dev |
| 21:03 |
|
ptv joined #minetest-dev |
| 21:03 |
|
FirePowi joined #minetest-dev |
| 21:15 |
|
est31 joined #minetest-dev |
| 21:18 |
|
Hunterz joined #minetest-dev |
| 22:29 |
|
Optical_Long joined #minetest-dev |
| 22:53 |
Fixer |
!tell paramat are you planning to add flowing water sound to that fire sound mod? |
| 22:53 |
ShadowBot |
Fixer: O.K. |
| 23:10 |
|
paramat joined #minetest-dev |
| 23:11 |
paramat |
maybe |
| 23:18 |
|
lisac joined #minetest-dev |
| 23:33 |
|
ptv joined #minetest-dev |
| 23:46 |
paramat |
#4847 could perhaps be considered for release as it fixes 2 bugs |
| 23:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/4847 -- Fix unnecessary block loading and duplicating objects by juhdanad |
| 23:48 |
Fixer |
managed to cought reproducable crash after some --- with saved earlier map |
| 23:49 |
Fixer |
will make backtrace |
| 23:54 |
Fixer |
have we changed mapblock format recently? |
| 23:54 |
paramat |
i doubt it |
| 23:55 |
Fixer |
seen error about mapblock format: you probably made map in never version of minetest |
| 23:55 |
Fixer |
2016-12-11 01:55:26: ERROR[Main]: ServerError: World data version mismatch in MapBlock (0,0,11) |
| 23:55 |
Fixer |
2016-12-11 01:55:26: ERROR[Main]: World probably saved by a newer version of Minetest. |
| 23:56 |
Fixer |
indeed i played it in never version |
| 23:57 |
Fixer |
will post a new crash issue not related to this |
