Time  Nick       Message
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
01:02 paramat    hi pozzoni please is it possible you could reduce the number of join/quit messages in this channel?
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 paramat    heh
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
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 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 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
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: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: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: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 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
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
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 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:48 Fixer      mods will throw lua oom error, this one seems like engine itself, right?
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)
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: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: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
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: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:33 paramat    '[FAIL] testStartStopWait' happens to many PRs and is a known problem
22:34 paramat    you can ignore that
22:38 paramat    nerzhul has told me builds are having other problems recently