Minetest logo

IRC log for #minetest-dev, 2016-06-19

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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-de​corations-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/v​iewtopic.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/minete​st/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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext