| Time |
Nick |
Message |
| 00:15 |
|
pozzoni joined #minetest-dev |
| 00:21 |
|
pozzoni joined #minetest-dev |
| 00:21 |
hmmmm |
wait a minute, that's how I had MapgenParams in the first place |
| 00:22 |
hmmmm |
I changed it because I hated having to reallocate MapgenParams and do partial copying every time the mapgen type changes |
| 00:29 |
|
pozzoni joined #minetest-dev |
| 00:50 |
|
pozzoni joined #minetest-dev |
| 00:59 |
|
pozzoni joined #minetest-dev |
| 01:02 |
paramat |
hi pozzoni please is it possible you could reduce the number of join/quit messages in this channel? |
| 01:07 |
|
pozzoni joined #minetest-dev |
| 01:22 |
|
pozzoni joined #minetest-dev |
| 01:31 |
|
Puka_ joined #minetest-dev |
| 01:35 |
|
pozzoni joined #minetest-dev |
| 01:42 |
|
pozzoni joined #minetest-dev |
| 01:42 |
|
STHGOM joined #minetest-dev |
| 01:48 |
|
pozzoni joined #minetest-dev |
| 01:49 |
paramat |
meh |
| 01:59 |
kaeza |
somebody will have to /ban *!*@2604:180::5a69:7f32##fix_your_connection or whatever the command was |
| 02:05 |
|
pozzoni joined #minetest-dev |
| 02:05 |
paramat |
heh |
| 02:20 |
|
pozzoni joined #minetest-dev |
| 02:28 |
|
pozzoni joined #minetest-dev |
| 02:32 |
paramat |
oops, i broke mgv6 backwards compatibility when i moved trees and flat flags from mg flags to mgv6 spflags. but it's not too bad because it only affects old worlds where trees were disabled, so very few. interestingly no-one has noticed or complained. i will make a post in the forum to apologise and explain how to correct the flags |
| 02:43 |
paramat |
thanks |
| 02:45 |
paramat |
i did test the PR at the time. luckily the flat flag compatibility was maintained |
| 02:46 |
|
pozzoni joined #minetest-dev |
| 02:56 |
|
pozzoni joined #minetest-dev |
| 03:05 |
|
Tmanyo joined #minetest-dev |
| 03:08 |
|
pozzoni joined #minetest-dev |
| 03:10 |
paramat |
old mgv6 worlds where trees were disabled now have trees |
| 03:23 |
hmmmm |
is this referring to the thing where default settings were modified without setting the default values for mapgenparams? |
| 03:24 |
hmmmm |
oh the tree move |
| 03:25 |
paramat |
i'll get the PR link |
| 03:25 |
hmmmm |
it's okay, i'm not that interested... |
| 03:25 |
paramat |
ok |
| 03:26 |
hmmmm |
mmm this is hard |
| 03:26 |
hmmmm |
i'm trying to decide which convention i should stick to |
| 03:26 |
paramat |
anyway, due to your changes this mess could be sorted out soon |
| 03:26 |
|
pozzoni joined #minetest-dev |
| 03:26 |
hmmmm |
so there's the general problem of having a polymorphic structure based off of a value of some other setting |
| 03:27 |
hmmmm |
notice how all throughout LuaApiMapgen i do this thing where it's like |
| 03:28 |
hmmmm |
FoobarType type = get_enum_val_from_string(get_string("setting name here")); |
| 03:28 |
hmmmm |
Foobar *foobar = Foobar::createFoobar(type); |
| 03:28 |
hmmmm |
foobar->set_general_settings_here; |
| 03:28 |
hmmmm |
switch (type) { |
| 03:28 |
hmmmm |
case FOOBAR_THINGIE1: |
| 03:28 |
hmmmm |
//set specific-Foobar type settings here |
| 03:29 |
hmmmm |
and then for MapgenParams it's like |
| 03:29 |
hmmmm |
hmm |
| 03:30 |
hmmmm |
maybe i should check out what other projects do |
| 03:30 |
hmmmm |
i'm not sure which is the best convention to follow here |
| 03:30 |
hmmmm |
or maybe there's a more clever way that i hadn't even thought of at all |
| 03:31 |
hmmmm |
but i want it to be that if some problem is solved in a certain way, i want all similar problems to be solved in that similar way |
| 03:33 |
|
pozzoni joined #minetest-dev |
| 03:33 |
hmmmm |
the reason why EmergeManager originally loaded MapgenParams was because MapgenParams itself was polymorphic and couldn't change the parent type of its own object |
| 03:33 |
hmmmm |
so am I basically reverting changes from 3+ years ago by doing this, I wonder? hrmm |
| 03:43 |
|
pozzoni joined #minetest-dev |
| 03:44 |
|
DI3HARD139 joined #minetest-dev |
| 04:35 |
paramat |
game#1146 |
| 04:35 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1146 -- Default: Remove mortar from desert stone brick by paramat |
| 04:38 |
hmmmm |
i think that's a decent change, paramat, but i can't quite tell without a screenshot showing a difference |
| 04:38 |
hmmmm |
hrmmm |
| 04:39 |
hmmmm |
i think i cause myself a lot of unnecessary pain by keeping the initial MapgenParams creation in ServerMap::loadMapMeta |
| 04:39 |
hmmmm |
i simply do not know what type of mapgen params to create until map has been fully initialized and the initial scripts had run |
| 04:40 |
* hmmmm |
slaps himself in the face |
| 04:40 |
hmmmm |
there is no architectural reason for ServerMap::loadMapMeta to even exist - it's an artefact from a bygone era |
| 04:40 |
|
RichardTheTurd joined #minetest-dev |
| 04:41 |
hmmmm |
i think i know what i'm gonna do. |
| 04:42 |
hmmmm |
on_mapgen_init may make a comeback. i haven't decided yet. |
| 05:48 |
|
DI3HARD139 joined #minetest-dev |
| 05:55 |
|
paramat joined #minetest-dev |
| 05:57 |
paramat |
iss on mapgen, innit? :] |
| 06:00 |
hmmmm |
this pisses me off because it should be such a trivial matter and i should be working on more interesting things like shaders and lighting |
| 06:02 |
hmmmm |
paramat, do you know of any mods that actually use set_noiseparams()? |
| 06:03 |
paramat |
i don't |
| 06:08 |
|
Thomas-S joined #minetest-dev |
| 06:10 |
hmmmm |
bare with me i'm just thinking out loud here |
| 06:11 |
hmmmm |
Map::loadMapMeta() gets moved to EmergeManager |
| 06:11 |
hmmmm |
does anything in between the time of ServerMap construction and mapgen initialization require knowledge of the map seed? |
| 06:12 |
hmmmm |
if not, then defer loading of map_meta.txt until after the initial pass of lua scripts have run |
| 06:12 |
hmmmm |
the lua scripts will set their mapgen parameters with set_mapgen_setting() like i had the idea of doing earlier |
| 06:13 |
hmmmm |
where it would override the map_meta.txt setting or not |
| 06:14 |
hmmmm |
and then i have to do some kind of trick with g_settings and our active settings to merge them without modifying g_settings so the user's config file doesn't get messed with |
| 06:14 |
hmmmm |
but then this would necessitate bringing back on_mapgen_init, because people won't know what the mapgen params are until the initial pass has run |
| 06:15 |
hmmmm |
but that doesn't quite matter because people already *don't* know what the mapgen is going to be until the first environment step |
| 06:15 |
hmmmm |
i really screwed up by removing on_mapgen_init |
| 06:15 |
hmmmm |
how am i going to add it back without breaking peoples' mods |
| 06:18 |
hmmmm |
fuck i screwed this up so bad, i didn't think things through as hard as i am now |
| 06:18 |
hmmmm |
now incompatibility is cemented in |
| 06:18 |
paramat |
if it's really necessary people can update their mods. i still haven't removed it from some of mine |
| 06:19 |
|
Miner_48er joined #minetest-dev |
| 06:19 |
hmmmm |
so, there, the need-to-clear-registered-decorations-on-mapgen-change issue is solved |
| 06:20 |
hmmmm |
if the params available in on_mapgen_init are read-only then we simply tell modders that's where you register decorations, not in script init |
| 07:14 |
|
Puka_ joined #minetest-dev |
| 07:17 |
|
Puka joined #minetest-dev |
| 07:18 |
|
nrzkt joined #minetest-dev |
| 07:27 |
|
paramat left #minetest-dev |
| 07:48 |
|
Hunterz joined #minetest-dev |
| 07:49 |
|
jin_xi joined #minetest-dev |
| 08:36 |
|
Thomas-S joined #minetest-dev |
| 08:47 |
|
Krock joined #minetest-dev |
| 08:49 |
|
edgrey joined #minetest-dev |
| 09:01 |
|
davisonio joined #minetest-dev |
| 10:44 |
|
ElectronLibre joined #minetest-dev |
| 10:52 |
|
ElectronLibre joined #minetest-dev |
| 10:53 |
|
nrzkt joined #minetest-dev |
| 11:01 |
|
davisonio joined #minetest-dev |
| 11:06 |
|
celeron55 joined #minetest-dev |
| 12:00 |
|
damiel_ joined #minetest-dev |
| 12:34 |
|
yyt16384 joined #minetest-dev |
| 12:34 |
|
Fixer joined #minetest-dev |
| 12:45 |
yyt16384 |
I'm trying to write the code for #4197, but not sure how to do it |
| 12:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/4197 -- Texture packs should be able to override wield_image and inventory_image |
| 12:45 |
yyt16384 |
tiles is in nodedef, but inventory_image is in itemdef |
| 12:46 |
yyt16384 |
so they need to be in different methods |
| 12:47 |
yyt16384 |
but I'd like to keep both of them in override.txt |
| 12:48 |
yyt16384 |
so it is needed to ignore overrides that are not applied in this method and don't print an error |
| 12:49 |
yyt16384 |
this seems to require writing the possible overrides types in two places, which is bad |
| 13:05 |
|
davisonio joined #minetest-dev |
| 14:08 |
|
Soni joined #minetest-dev |
| 14:25 |
|
Krock joined #minetest-dev |
| 14:34 |
|
rubenwardy joined #minetest-dev |
| 14:40 |
|
davisonio joined #minetest-dev |
| 15:11 |
|
hmmmm joined #minetest-dev |
| 15:24 |
|
Player_2 joined #minetest-dev |
| 15:24 |
|
Void7 joined #minetest-dev |
| 15:30 |
|
KaadmY joined #minetest-dev |
| 16:35 |
|
crazyR joined #minetest-dev |
| 16:40 |
|
Void7 joined #minetest-dev |
| 16:49 |
|
Samson1 joined #minetest-dev |
| 17:05 |
|
jin_xi joined #minetest-dev |
| 17:17 |
|
asl97 joined #minetest-dev |
| 17:31 |
|
AnotherBrick joined #minetest-dev |
| 17:43 |
|
est31 joined #minetest-dev |
| 18:34 |
|
Void7 joined #minetest-dev |
| 18:35 |
|
paramat joined #minetest-dev |
| 18:39 |
OldCoder |
An unhandled exception occurred: std::bad_alloc |
| 18:39 |
OldCoder |
Is that a sign of bad RAM or a software error in the core? |
| 18:41 |
paramat |
AFAIK that's a memory issue |
| 18:45 |
|
Tesseract joined #minetest-dev |
| 18:45 |
|
Tesseract joined #minetest-dev |
| 18:45 |
est31 |
OldCoder, it may mean that minetest is out of ram |
| 18:45 |
est31 |
that can have multiple causes |
| 18:45 |
est31 |
either a bug, or too much data like players mods etc |
| 18:46 |
|
Puka joined #minetest-dev |
| 18:48 |
Fixer |
mods will throw lua oom error, this one seems like engine itself, right? |
| 18:48 |
|
VanessaE_ joined #minetest-dev |
| 18:48 |
|
exoplane- joined #minetest-dev |
| 18:49 |
|
cheapie_ joined #minetest-dev |
| 18:49 |
est31 |
yes |
| 18:49 |
est31 |
lua oom is when the lua vm gets the honor to request memor but does not get it |
| 18:49 |
est31 |
std::bad_alloc happens when core c++ code wants to do it |
| 18:50 |
est31 |
(lua oom may happen much earlier thanks to this artificial boundary) |
| 18:50 |
|
exoplanet joined #minetest-dev |
| 18:50 |
|
nnnn20430_ joined #minetest-dev |
| 18:56 |
|
Taoki joined #minetest-dev |
| 19:07 |
OldCoder |
I have many GB of RAM free... does std:bad_alloc necessarily mean actually out of RAM? Note that this is C++ level; yes, I've run into artificial LuaJit memory issues |
| 19:07 |
OldCoder |
And have stopped using LuaJit for this reason |
| 19:08 |
hmmmm |
std::bad_alloc happens when operator new fails |
| 19:08 |
est31 |
well idk I can only read the docs |
| 19:08 |
est31 |
http://www.cplusplus.com/reference/new/bad_alloc/ |
| 19:08 |
hmmmm |
it could fail for any number of reasons, including a corrupted heap |
| 19:08 |
hmmmm |
or maybe out of virtual address space |
| 19:09 |
est31 |
corrupted heap ... that's interesting |
| 19:09 |
hmmmm |
or maybe the minetest process has a low memory quota set on it |
| 19:09 |
est31 |
either way gtg |
| 19:09 |
hmmmm |
it depends on the context |
| 19:09 |
hmmmm |
a "std::bad_alloc" alone is not enough information to make any judgments |
| 19:10 |
hmmmm |
maybe it could be a corrupted or uninitialized variable that counts a loop that memory gets allocated in |
| 19:20 |
|
Amaz joined #minetest-dev |
| 19:22 |
|
rubenwardy joined #minetest-dev |
| 19:23 |
rubenwardy |
paramat, hmmmm, may be interesting to you: https://forum.minetest.net/viewtopic.php?f=7&t=14963 |
| 19:23 |
rubenwardy |
~title |
| 19:23 |
ShadowBot |
Found (a little bit) speed - Minetest Forums |
| 19:23 |
paramat |
looking |
| 19:24 |
rubenwardy |
~2x speed up in lighting code by using parallelisation |
| 19:24 |
paramat |
^ hmmmm |
| 19:24 |
hmmmm |
the mapgen is already supposed to be parallel |
| 19:24 |
hmmmm |
and the mapgen is already fast enough |
| 19:25 |
hmmmm |
what needs work is synchronization |
| 19:25 |
rubenwardy |
I thought lighting code was the slowest part? |
| 19:25 |
hmmmm |
the slowest part of fast is still fast |
| 19:25 |
hmmmm |
let's focus on real bottlenecks, shall we? |
| 19:26 |
OldCoder |
hmmmm, thank you; so, any overwrite of data could do that |
| 19:26 |
rubenwardy |
sure. I thought you'd like to see that, anyway |
| 19:26 |
rubenwardy |
don't shoot the messenger |
| 19:28 |
jin_xi |
imho mt bottleneck are not in speed of the thing, but that you hit limits as soon as you try do do something remotely fun |
| 19:33 |
Fixer |
stuttering |
| 19:35 |
Fixer |
never forget |
| 19:36 |
paramat |
i can't |
| 20:21 |
|
Miner_48er joined #minetest-dev |
| 20:30 |
|
Amaz left #minetest-dev |
| 20:40 |
paramat |
hmmmm just notifying you of a schematic issue #4236 |
| 20:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/4236 -- place_schematic places old(outdated) schematic even if schematic file got updated |
| 20:41 |
|
Zeno` joined #minetest-dev |
| 20:52 |
|
est31 joined #minetest-dev |
| 21:17 |
|
Darcidride joined #minetest-dev |
| 21:18 |
hmmmm |
that's the expected behavior..? |
| 21:20 |
hmmmm |
that isn't an issue. that's literally the way it's been designed. |
| 21:32 |
|
Void7 joined #minetest-dev |
| 21:37 |
|
Tmanyo joined #minetest-dev |
| 21:50 |
|
Samson1 joined #minetest-dev |
| 21:54 |
Hijiri |
I got a failed travis build https://travis-ci.org/minetest/minetest/builds/138755743 but one failed build is a failed unit test for something I didn't change and another is a failure in a build script to connect to a keyserver |
| 21:54 |
Hijiri |
will travis try another build eventually or should I do something to trigger one? |
| 22:02 |
Hijiri |
I just amended the commit so it would trigger another build |
| 22:13 |
|
ID joined #minetest-dev |
| 22:28 |
|
paramat joined #minetest-dev |
| 22:33 |
paramat |
'[FAIL] testStartStopWait' happens to many PRs and is a known problem |
| 22:34 |
paramat |
you can ignore that |
| 22:35 |
|
proller joined #minetest-dev |
| 22:36 |
|
Tmanyo joined #minetest-dev |
| 22:38 |
paramat |
nerzhul has told me builds are having other problems recently |
