Minetest logo

IRC log for #minetest-dev, 2014-11-29

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

All times shown according to UTC.

Time Nick Message
00:00 VanessaE joined #minetest-dev
00:01 shadowzone joined #minetest-dev
00:58 paramat joined #minetest-dev
01:04 shadowzone joined #minetest-dev
01:25 paramat left #minetest-dev
02:08 kaeza joined #minetest-dev
02:36 shadowzone joined #minetest-dev
02:42 ShadowLadyXD joined #minetest-dev
02:55 shadowzone joined #minetest-dev
03:02 ShadowLadyXD joined #minetest-dev
03:05 Zeno` joined #minetest-dev
03:08 shadowzone joined #minetest-dev
03:18 ShadowLadyXD joined #minetest-dev
03:20 ShadowNinja Oh, BTW, I support a feature freeze now.
03:20 ShadowNinja I'll do the honors if I get another agreement (IIRC there was already one or two).
03:20 paramat joined #minetest-dev
03:24 ShadowNinja That would be Zeno`.
03:24 Zeno` Yes I would agree
03:24 Zeno` would still*
03:24 ShadowNinja If paramat thinks MGv5 needs work just mark it as indev.
03:25 RealBadAngel hi
03:25 VanessaE hi
03:25 RealBadAngel before that i need to push a few things
03:25 paramat seems too early
03:26 RealBadAngel just give me 2 days (the weekend) at least
03:27 VanessaE freeze now would be good after RBA pushes his extrude thing.  RBA:  can you check if https://github.com/VanessaE/​plantlife_modpack/issues/25 is a regression or not?  I think it happened when you tweaked how plants are positioned when scaled
03:27 kaeza joined #minetest-dev
03:27 VanessaE I fixed that ^^^ in plantlife already but I want to know if my fix was even necessary (should it have been fixed in the engine instead?)
03:27 ShadowNinja Set it for 6th of December (Saturday)?
03:27 VanessaE ShadowNinja: no, at least two weeks out
03:28 VanessaE I think we kinda agreed that a week is too soon
03:28 paramat how about releasing around winter solstice?
03:28 ShadowNinja VanessaE: Eh, that takes us a bit close if we're going for a christmas release.
03:28 RealBadAngel VanessaE, extruded plants needs the same fixes as i did to regular ones before
03:28 VanessaE ShadowNinja: I know.
03:28 ShadowNinja VanessaE: That's the start, not the end BTW.
03:29 VanessaE RealBadAngel: ok, but I'm talking about the relative scale; take a look at the bug report.
03:29 RealBadAngel 2nd mesh needs also to be offseted a bit to avoid z fighting in the middle
03:29 paramat i was planning to add pinetrees and default biomes for mgv5/v7, including default snow biomes, apt for a midwinter release
03:29 paramat anyway hmmmm usually does the release thing
03:30 RealBadAngel also i need to re-add lighting to shaders
03:30 paramat "just mark it as indev" heheh unfortunate choice of word for a mapgen
03:35 Zeno` I dunno VanessaE ... I quite like those treefern screenshots
03:35 VanessaE Zeno`:  heh
03:37 RealBadAngel Zeno`, you have linked me screens from profiler about a patch
03:37 RealBadAngel but wheres that patch?
03:37 paramat so i guess i would like 1 week minimum before freeze
03:38 Zeno` RealBadAngel, I closed it. I'm going to rewrite it after feedback was received
03:38 VanessaE ShadowNinja: ok, in that case I'll go with that; I read that as "a week-long freeze"
03:38 Zeno` RealBadAngel, https://github.com/minetest/minetest/pull/1879
03:38 VanessaE not like I have much actual say in the matter of course :P
03:41 Zeno` I can probably just cache the value in the class that needs it anyway. Changing enable_shaders using set seems to make no difference when playing the game anyway
03:42 Zeno` Then at least the mesh updates will be improved. The ones in run() will still be there until I think of a better approach to this but *shrug*
03:59 paramat hmmmm my plans for biomes are 1. add 'node_stone' to biome parameters 2. use 3 octaves 0.5 persistence for heat/humidity to reduce the amount of tiny biomes and biome stripes 3. move heat and humidity noises back into each mapgen and make them user-adjustable, so we can tune biome spreads to the scale of each mapgen and also compensate for number of biomes
04:11 shadowzone joined #minetest-dev
04:14 shadowzone joined #minetest-dev
04:56 shadowzone joined #minetest-dev
04:59 sol_invictus joined #minetest-dev
05:00 shadowzone joined #minetest-dev
05:06 paramat left #minetest-dev
05:09 ShadowLadyXD joined #minetest-dev
05:28 shadowzone joined #minetest-dev
05:41 ShadowLadyXD joined #minetest-dev
05:42 domtron joined #minetest-dev
06:04 ShadowLadyXD joined #minetest-dev
06:08 shadowzone joined #minetest-dev
06:17 Megaf joined #minetest-dev
06:28 ShadowLadyXD joined #minetest-dev
06:32 shadowzone joined #minetest-dev
06:33 blais3 joined #minetest-dev
07:04 Hunterz joined #minetest-dev
07:25 Megaf_ joined #minetest-dev
07:25 Megaf_ joined #minetest-dev
07:37 chchjesus joined #minetest-dev
08:13 darkrose joined #minetest-dev
08:13 selat joined #minetest-dev
08:19 Megaf Morning Zeno`
08:19 Megaf Zeno`: have you seen my ms_print output?
08:20 Calinou joined #minetest-dev
08:20 Zeno` no, I did see it mentioned but I was asleep :)
08:21 Megaf understandable
08:21 Megaf Zeno`: https://gist.github.com/Megaf/50aac763e9f0bf85adb9
08:22 Zeno` How much RAM was in use at that time?
08:22 Zeno` Or, alternatively, how long had the server been running?
08:23 Megaf Zeno`: about an hour I believe
08:24 Megaf Zeno`: I even played on the server while running Valgrind, and ran my mesecon/pipeworks machines
08:26 Megaf I wish I could better undertand this output https://gist.githubusercontent.com/Megaf/50a​ac763e9f0bf85adb9/raw/f91788eee3a586d292f543​02ce8c3a6d74da0f48/massif.out.1536.ms_print
08:26 Megaf (That's the same as the other link, but raw)
08:29 Zeno` Good stuff. I'll look at it more closely after I eat
08:30 Megaf Zeno`: I hope that helps
08:30 Megaf Zeno`: I can run again later on, I have a copy of my server in another computer, where I can run it and do tests at will
08:39 kilbith joined #minetest-dev
08:44 jin_xi joined #minetest-dev
09:11 Calinou how do I bring one of my fork repositories (a branch) up-to-date?
09:11 Calinou without messing up with commit history
09:11 Calinou I'd like to make a pull_request for minetest_game without invalidating my previous ones
09:14 jin_xi something along the lines of pulling newest masters, then rebase your branches
09:14 Calinou what commands do that?
09:15 jin_xi well, im not so sure to know exact commands, but you switch to master (checkout), pull, switch back to branch and rebase. hope this helps for googleing
09:16 Calinou I don't Google ;) but OK, thanks
09:17 jin_xi you're a binger?
09:18 Megaf Calinou: git pull http://minetest.git ?
09:19 Megaf just test it on another repo
09:20 Calinou thanks, works
09:20 Calinou https://github.com/minetest/minetest_game/pull/347
09:20 Calinou buffed food
09:20 Megaf Calinou: the game on my server have just stopped in time
09:27 lag01 joined #minetest-dev
09:32 Calinou https://github.com/minetest/minetest_game/pull/348
09:32 Calinou snappy axes
10:23 ImQ009 joined #minetest-dev
10:25 Megaf Calinou: we can already use swords for that
10:25 Calinou they lose durability like crazy and don't help much
10:26 Megaf hm
10:26 Megaf maybe the game should have shears as a default tool
10:27 Megaf to cut leaves and plants
10:27 Calinou that clutters players' inventories :/
10:27 Calinou should be either swords (almost no use in minetest_game base) or axes
10:27 Calinou axes are cool, because you also cut wood with them
10:28 Calinou in Carbone, swords dig snappy stuff even faster but lose durability
10:29 Megaf Calinou: you should add Leprechaun Tools to Carbone
10:29 Calinou what's that?
10:29 Calinou anyway this should be discussed in PM or in #minetest
10:29 Megaf https://github.com/Megaf/leprec​haun_tools/blob/master/story.md
10:29 Calinou another PR: https://github.com/minetest/minetest_game/pull/349
10:45 kilbith joined #minetest-dev
10:54 zat joined #minetest-dev
10:54 PenguinDad joined #minetest-dev
11:10 Amaz joined #minetest-dev
11:19 chchjesus joined #minetest-dev
11:19 puhfa hey, this is just a random thought, but is it possible to use minetests noise generator for local texture generation or even in shaders?
11:19 puhfa i mean, would be an easy way to make good-looking liquids
11:20 puhfa http://glsl.herokuapp.com/e#19493.1 <- along these lines (not the looks but the idea)
11:29 Fritigern Has anyone ever succesfully used mtdbconvert (the one that comes with mtsatellite) to convert from LevelDB to sqlite?
11:30 sfan5 why would you not want to use minetest itself to migrate databases
11:32 Fritigern I followed mtsatellite's directions because i wanted the realtime map that it provides. Little did i know that it's crap. Anyway, the directions made me convert the DB to leveldb (interleaved) and according to the documentation, it SHOULD be possible to convert it back to sqlite.
11:32 Fritigern But if you say that MT can migrate an existing DB, then please show me how
11:32 sfan5 minetestserver --world world --migrate sqlite3
11:33 Fritigern You beat me to it ;-)
11:34 Fritigern Ummm... are you sure that --world is correct? Because i start my server using --worldname (the world is also in a non-default folder)
11:39 sfan5 it is --world <path> afaik
11:39 Fritigern Is it normal for the migration process to want to load mods?
11:39 sfan5 if you have any more questions do a man minetestserver
11:39 sfan5 yes
11:41 Fritigern balaam@Sophie:~/Minetest/bin$ man minetestserver
11:41 Fritigern No manual entry for minetestserver
11:44 sfan5 man only works when you have system-wide install
11:44 Fritigern And you assumed that i have done that
11:45 Amaz http://pastie.org/9750248 <-- Contents of man minetestserver
11:46 Fritigern "Cannot migrate: new backend is same as the old one" Now what?
11:46 Fritigern BTW, it is not the same. I am migrating from leveldb to sqlite3. Well, re-migrating
11:47 sfan5 Fritigern: do you have a map.sqlite?
11:48 sfan5 and do you still have the map.db?
11:48 Fritigern Nope, i hav removed that after mograting to leveldb. I do have a map.db with a bunch of *.ldb files
11:48 Fritigern So no on the map.sqlit, yes on the map.db
11:49 Fritigern And typos be damned
11:49 sfan5 if you don't have a map.sqlite you didn't migrate to sqlite
11:49 Fritigern I know
11:49 Fritigern Tell that to minetestserver
11:49 sfan5 oh wait
11:49 sfan5 ignore what i said
11:50 sfan5 so.. mtdbconvert converted your map to leveldb and didn't change world.mt accordingly?
11:50 sfan5 if that is so, change 'backend = sqlite3' to 'backend = leveldb' and then use the migrate function
11:50 Fritigern I'll look
11:51 Fritigern You were right. Giving it another go
11:51 Fritigern That can't be right.... "Successfully migrated 0 blocks"
11:54 Fritigern Attempting a login, but i fear the worst
11:56 Zeno` sfan5: 1883  (simple fix)
11:56 Zeno` grr... #1833
11:56 ShadowBot https://github.com/minetest/minetest/issues/1833 -- Remove most exceptions from getNode() (and variants) by Zeno-
11:57 Zeno` hmm
11:57 Zeno` that's not it
11:57 Zeno` #1883 lol
11:57 ShadowBot https://github.com/minetest/minetest/issues/1883 -- Fix MSVC compiling error (argc/argv not available to pass to init_gettext) by SmallJoker
12:07 kilbith joined #minetest-dev
12:13 mitrom joined #minetest-dev
12:13 mitrom hi
12:17 sfan5 Zeno`: you know that you can merge small patches without approval? (http://dev.minetest.net/Git_G​uidelines#Rule_1_in_practice)
12:18 Zeno` Yeah, but I'm being cautious. Perhaps it would have been better to say "this is a small patch and I'll merge in 10 minutes"?
12:18 Zeno` I'll do that in future
12:18 sfan5 > Perhaps it would have been better to say "this is a small patch and I'll merge in 10 minutes"?
12:18 sfan5 yes
12:18 Zeno` #1833 is a small patch and I'll merge it in 10 minutes
12:18 ShadowBot https://github.com/minetest/minetest/issues/1833 -- Remove most exceptions from getNode() (and variants) by Zeno-
12:18 Zeno` :D
12:19 sfan5 um
12:19 sfan5 didn't you mean #1883
12:19 ShadowBot https://github.com/minetest/minetest/issues/1883 -- Fix MSVC compiling error (argc/argv not available to pass to init_gettext) by SmallJoker
12:19 sfan5 because 1833 is not a small patch
12:20 Zeno` I've done that twice now... why do I keep getting that 3 wrong :/
12:20 Zeno` of course that's what I meant, thanks
12:31 Ritchie joined #minetest-dev
12:33 CraigyDavi Hmm why did this get added a while back? https://github.com/minetes​t/minetest/commit/9a92747 imo it's better to keep it set as false because there will only be a few nodes which people want saves to be carved out of (dirt, stone, sand) and loads of blocks which people don't want to be carved (wood, crafted blocks, cobble).
12:34 CraigyDavi It's better to leave the default as blocks which are not in the minority
12:45 Krock joined #minetest-dev
13:24 nore joined #minetest-dev
13:36 jin_xi joined #minetest-dev
13:41 shadowzone joined #minetest-dev
13:46 ImQ009 joined #minetest-dev
13:51 sol_invictus joined #minetest-dev
14:12 Amaz joined #minetest-dev
14:20 shadowzone joined #minetest-dev
14:36 shadowzone joined #minetest-dev
14:40 selat joined #minetest-dev
15:08 Wayward_One joined #minetest-dev
15:16 Fritigern joined #minetest-dev
15:24 casimir joined #minetest-dev
15:28 zat joined #minetest-dev
15:59 exio4 joined #minetest-dev
16:07 Sokomine joined #minetest-dev
16:15 hmmmm joined #minetest-dev
16:16 exio41 joined #minetest-dev
16:20 Zeno` hmmmm, #1855. Most (if not all) of these settings cannot be set/cached in the constructor of another object because they can, and do, change as the program executes
16:20 ShadowBot https://github.com/minetest/minetest/issues/1855 -- Mgv5 1 up 1 down overgeneration for biome surface continuity, thinner biomes. by paramat
16:25 PenguinDad Zeno`: You seem to be be getting numbers wrong quite often today ;)
16:25 Zeno` it's the 18 :(
16:26 Zeno` I have no idea why
16:26 Zeno` #1885
16:26 ShadowBot https://github.com/minetest/minetest/issues/1885 -- Create CoreSettings class for time-critical sections to use by Zeno-
16:26 shadowzone joined #minetest-dev
16:26 Zeno` *sigh*
16:32 * VanessaE gives Zeno` a new keyboard and a new set of hands
16:32 Zeno` it's just the 188 ... I dunno what it is
16:32 Zeno` I have the same problem with my phone number
16:33 Zeno` and my phone number doesn't even include 188
16:33 PenguinDad lol
16:33 exio4 at least you know your phone number
16:33 exio4 I know mine starts with +54
16:34 shadowzone Mine is (555)111-222
16:34 exio4 that doesn't look like a correct phone number
16:34 shadowzone It is
16:34 VanessaE just call JL5-2368
16:34 shadowzone huh?
16:35 domtron joined #minetest-dev
16:42 VanessaE wait strike that, it's JL5-2020
16:42 Zeno` checked your number against movie trivia?
16:42 * shadowzone grabs her phone
16:42 VanessaE yep :)
16:43 Zeno` VanessaE, You seem to be be getting numbers wrong quite often today ;)
16:43 VanessaE so do you :)
16:43 shadowzone Me too
16:43 shadowzone I made 7 mistakes in code,chatting and talking
16:44 VanessaE shadowzone: google it :)
16:44 hmmmm Zeno`, if tracking variable changes is a requirement then perhaps you could do sort of what NodeResolver does, except in a smarter way
16:44 shadowzone pff, thanks :)
16:44 Zeno` hmmmm, it is for fast_move etc
16:45 hmmmm perhaps there can be a new type of settings getters
16:45 Zeno` I don't see what's wrong with this solution TBH
16:45 hmmmm getBoolUpdates()
16:45 Zeno` yeah I tried that yesterday and got shot down
16:45 Zeno` this way is better
16:45 hmmmm why, who?
16:47 hmmmm volatile bool fast_move; g_settings->getBoolUpdates("fast_move", &fast_move);  while (big_loop_here_runs) {  .... do stuff with fast_move ... }
16:47 VargaD joined #minetest-dev
16:47 hmmmm ofc this will only work for actual booleans rather than strings since you need to use atomic ops
16:47 Zeno` but that's for only one setting and, yes, only for bools
16:48 hmmmm so you can make getS32Updates() for S32s
16:48 Zeno` but then I'd have to call the get*Updates() every frame/server-step
16:48 hmmmm could you explain why
16:48 Zeno` which kind of defeats the purpose
16:49 hmmmm you call it only once
16:49 Zeno` well, how will the updates be flagged when an update happens?
16:49 Zeno` e.g. if the user presses 'j' (for example)
16:49 hmmmm what's wrong with checking if the value changed each frame?
16:50 Zeno` these updates happen rarely
16:50 hmmmm checking a boolean is expensive?
16:50 Zeno` so checking every frame is much more expensive than this solution
16:50 hmmmm here hold on
16:50 Zeno` it is when it's not necessary
16:51 Zeno` And those checks would need to be scattered all through the source code
16:58 kaeza joined #minetest-dev
17:00 kaeza sfan5, https://github.com/minetest/minetest_game/pull/346
17:00 hmmmm i just don't see how the conventions are different from what you're currently doing
17:00 sfan5 kaeza: looks good
17:00 sfan5 incoming merge of minetest_game#346 in 5 minutes
17:01 kilbith sfan5: also take a look in 327 & 338 please
17:05 CraigyDavi joined #minetest-dev
17:06 hmmmm Zeno`:  are you there?
17:06 hmmmm do this:  http://fpaste.org/155147/80761141/
17:06 hmmmm I don't see what's wrong with that^
17:07 Zeno` getBoolUpdates() is still using std::map
17:08 hmmmm but the difference is that you're calling it only once
17:08 Zeno` which is too slow for something that happens every frame (for the client) or server step (for the server)
17:08 hmmmm but the difference is that you're calling it only once
17:08 hmmmm but the difference is that you're calling it only once
17:08 hmmmm but the difference is that you're calling it only once
17:08 hmmmm but the difference is that you're calling it only once
17:08 hmmmm but the difference is that you're calling it only once
17:08 hmmmm holy shit
17:08 Zeno` once?
17:08 hmmmm YES!
17:08 hmmmm that's the whole point
17:09 Zeno` and this works with floats and types other than bool?
17:10 hmmmm sure
17:10 hmmmm as long as it's under a machine word in size
17:10 hmmmm for strings you could swap pointers
17:10 Zeno` what about line 15?
17:10 hmmmm what about it
17:11 hmmmm you'd do that check even with your current patch
17:11 Zeno` yes, but not every iteration
17:11 Zeno` it might be done once every 20 minutes, or never
17:12 hmmmm I don't get it
17:13 hmmmm so let's say we have g_settings->getFastBool_fastMove()
17:13 Zeno` In a normal game session most of the values won't change at all, so why check if they've changed every time through the loop?
17:13 hmmmm how would you modify client thread to handle changes there
17:13 hmmmm you don't strictly need to check
17:13 hmmmm you just want to check for... whatever reason
17:13 Zeno` so... when to check?
17:13 hmmmm if you want to do something more on changes, you'd do that as you're setting the value
17:14 Zeno` I don't get it
17:14 Calinou joined #minetest-dev
17:15 hmmmm i don't really get why you would even need to check if the value changed in the client thread though
17:15 Zeno` because the user might press 'j'
17:15 hmmmm okay
17:15 Zeno` or 'k'
17:15 Zeno` or whatever :)
17:15 hmmmm so you're saying you want SET to be fast as GET is
17:16 hmmmm why though?  i see a lot of getting, and not very much setting at all
17:16 hmmmm setting is not hot enough to optimize
17:16 Zeno` no... I want GET to be fast
17:16 hmmmm right
17:16 Zeno` right now it's horribly slow
17:16 hmmmm and here get is very fast
17:17 hmmmm because you're not calling anything
17:17 hmmmm only once in the very beginning
17:17 hmmmm and then anytime after that the variable is automatically updated
17:18 Zeno` This is just an alternative method at the end of the day
17:19 hmmmm nobody else but you likes hardcoding settings in Settings
17:19 cg72 joined #minetest-dev
17:19 Zeno` me?
17:19 Zeno` I didn't write the original class
17:19 hmmmm yeah...
17:20 Zeno` if (current_fast_move != old_fast_move) is essentially the same as hardcoding something
17:20 hmmmm first off I don't see why you'd even NEED that check
17:20 hmmmm second off it's not.  one you're modifying Settings, and the other you're modifying the specific object's code
17:20 hmmmm seperation of concerns
17:21 Zeno` yeah, and you have to remember to add if (current_fast_move != old_fast_move) { } for every single instance where you want a 'cached' value
17:21 hmmmm can you articulate why you need to do that
17:21 hmmmm I just added it there because you wanted to check if it changed or not in the getter thread
17:22 Zeno` so what is line 9 doing?
17:22 hmmmm declaring the boolean variable that receives updates
17:22 Zeno` It's adding a hardcoded object
17:22 Zeno` same thing as my class does
17:23 hmmmm your class modifies settings though
17:23 Zeno` only when it's destroyed
17:23 Zeno` and that's necessary because some of those settings need to be written to minetest.conf
17:24 Zeno` e.g. min_viewing_range needs to be written
17:24 Zeno` fast_move needs to be written
17:24 Zeno` etc etc
17:25 shadowzone joined #minetest-dev
17:25 hmmmm you clearly modify Settings by adding a metric crapton of getter/setter methods
17:25 Zeno` I have added no methods
17:26 hmmmm what is getFastBool_enable_shaders
17:26 Zeno` no idea... that's not in my patch
17:26 hmmmm https://github.com/Zeno-/minetest/commit/​915780ea26781caecb900237f020c7816c199bf2
17:26 hmmmm ????
17:27 hmmmm it says Zeno- authored a day ago
17:27 Zeno` I'm not talking about that one. I closed that
17:27 hmmmm then what one ....ARE... you talking about
17:27 Zeno` #1885
17:27 ShadowBot https://github.com/minetest/minetest/issues/1885 -- Create CoreSettings class for time-critical sections to use by Zeno-
17:28 VanessaE hey he got it right on the first try this time! :D
17:28 hmmmm whaa
17:28 hmmmm this strikes me as having a lot of code to do very little
17:29 Zeno` You can't have had time to even look at it, lol
17:32 hmmmm this is essentially what I just wrote does
17:32 hmmmm except it has more... stuff
17:33 hmmmm so what you did was make an infrastructure so that objects can register functions to get called back
17:33 hmmmm and then you added it to both settings and this new CoreSettings
17:34 hmmmm CoreSettings sets Settings on dtor
17:35 hmmmm and update is called inside of the game step if needsUpdate()
17:35 Zeno` correct
17:36 hmmmm but but but you're checking something every loooop
17:36 Zeno` ONE bool
17:36 Zeno` not 30
17:36 hmmmm you need to check 0 bools with my solution
17:37 hmmmm what you did screams "overengineered" to me
17:37 shadowzone joined #minetest-dev
17:37 Zeno` but with your solution you need to ... sigh
17:37 Zeno` nvm
17:37 hmmmm need to what
17:38 Zeno` it doesn't matter... I'm too tired right this moment to debate coherently
17:38 hmmmm so if one of the settings changed, it sets off a flurry of g_settings->get *
17:38 Zeno` yes
17:38 Zeno` and they change how often?
17:39 hmmmm not often, but I don't get why the server and the client threads need to be the ones to do the updating
17:40 hmmmm so basically what you have is a large struct of booleans that can be simply set, or if it's set through the original Settings, you raise a flag that it needs updating
17:41 hmmmm i assume you're doing this and not updating the entire thing inside of settings Set because you're afraid you'll need to add a lock in CoreSettings
17:50 Weedy joined #minetest-dev
17:50 Weedy joined #minetest-dev
17:51 NakedFury joined #minetest-dev
17:52 Weedy_ joined #minetest-dev
17:54 SmugLeaf joined #minetest-dev
17:56 Zeno` hmmmm, any real reason why this solution is not good?
17:57 Zeno` It's harder to make mistakes with this solution, as opposed to yours (IMO)
17:58 prozacgod joined #minetest-dev
17:59 Zeno` And without any evidence my gut feeling is that my solution is faster
17:59 Zeno` And fast is what we need
18:12 shadowzone joined #minetest-dev
18:16 ShadowLadyXD joined #minetest-dev
18:17 hmmmm how could your solution be faster if there's 0 work being done by the consumer?
18:17 hmmmm looking at your updated version, it's much better than hard coding shit into Settings which was the main complaint
18:17 hmmmm the current version looks like a lot of work to do very little though
18:18 hmmmm i don't know, let somebody else decide
18:19 shadowzone joined #minetest-dev
18:20 Guest71201 joined #minetest-dev
18:21 hmmmm for what it's worth, zeno, I had an idea to speed up Settings a while ago by building a settings struct with the actual value type contained instead of strings, and the setting name was just a constant value containing the offset to the setting in the struct
18:21 hmmmm i got shot down because people kept telling me it wasn't worth optimizing settings
18:23 cg72 105% of the dev effort should be set on optimizing the current code, making improvements to whats here now not adding more features(bugs) and ignoring the old code that can be greatly improved
18:31 shadowzone joined #minetest-dev
18:34 Megaf Sp there is hope, more people think like I do
18:34 CraigyDavi joined #minetest-dev
18:34 cg72 lol Megaf who is sp? and who thinks like you
18:36 shadowzone no one
18:36 Megaf s/sp/so
18:42 kahrl joined #minetest-dev
18:47 PenguinDad cg72: Where'd ya find the 5%
18:49 cg72 PenguinDad i coded an extra exponentially greater system just now, it bends space time to help productivity
18:57 hmmmm how do you signify an error in creating an object in lua?
18:57 hmmmm https://github.com/minetest/minetest/issues/1819  this guy wants an error
18:58 hmmmm script_error(L); would abort the script
18:58 hmmmm abort the server i mean
18:58 hmmmm and then if so, how am i supposed to handle errors everywhere else noise is created?
18:59 hmmmm noise is used in a lot of places...
18:59 kahrl I think he just wants a LuaError instead of a std::bad_alloc
18:59 jin_xi joined #minetest-dev
19:03 hmmmm trying to decide whether or not I should have the Noise ctor catch std::bad_allocs and set them to some default noiseparams that doesn't crash anything
19:03 hmmmm and then if so, how would I report the error...
19:03 hmmmm noise->areParamsGood() ?
19:04 kahrl that sounds like a great way to create bugs that are impossible to find
19:05 hmmmm - i want to avoid errorstream in noise.cpp
19:05 hmmmm - i don't want to wrap every single noise declaration in a try catch statement
19:06 hmmmm i want to be able to pass a LuaError along in the case of invalid parameters
19:06 hmmmm and finally i want to recover "gracefully"
19:06 hmmmm whatever that means
19:09 kahrl if someone sets bad noiseparams in the C++ source, I think it's better to just get a std::bad_alloc than "graceful" default noise params
19:10 hmmmm well bad noise params get set in the config file as well
19:10 kahrl hmm yeah
19:10 hmmmm and people modifying map_meta.txt
19:10 hmmmm map_meta.txt should be a binary format so people don't screw around with it
19:10 hmmmm ugh
19:12 hmmmm so i just checked.  there aren't as many instances where noise objects are created as i thought.  just the mapgens and a couple of script things.  i could put an exception handler around createMapgen() i guess.. but how would I handle a mapgen startup failure?  all of the server startup failures just pass along exceptions
19:13 hmmmm i think people are just upset that they see "std::bad_alloc".  if I catch that and throw InvalidNoiseParams or something instead, people won't get as upset
19:14 sol_invictus joined #minetest-dev
19:14 kahrl yeah that sounds good
19:14 khonkhortisan joined #minetest-dev
19:15 kahrl no need to catch that exception anywhere imho
19:15 hmmmm heh.. thing is that the noise params aren't necessarily invalid
19:15 kahrl maybe check them in the catch(std::bad_alloc&)
19:16 hmmmm in some cases there are noise params that have a very low spread factor or something else, resulting in lots of memory getting allocated.  so what might be invalid noise params for one machine might be not invalid for another
19:16 kahrl throw ProcessingLimitException("Noise params require too much memory")?
19:17 hmmmm i have to figure out a way to reliably determine whether or not noise params were specified wrong or just too demanding
19:17 hmmmm like obviously if octaves < 0 that's invalid, right
19:18 hmmmm then maybe if octaves > 500000 or something i'll call that invalid
19:18 khonkhortisan joined #minetest-dev
19:18 hmmmm but coming up with these upper bounds are kind of arbitrary
19:18 hmmmm s/are/is/
19:20 Krock octaves above 20 are already not needed
19:20 kahrl tbh I don't see why people are upset about std::bad_alloc
19:21 hmmmm if they don't understand what's going on when noise is being created it just looks like a random crash to them
19:21 kahrl surely if someone calls inventory:set_size("list", 1000000000) they'd understand it?
19:24 ImQ009 joined #minetest-dev
19:25 hmmmm you know I was also considering another way to handle this
19:26 hmmmm actually no nevermind
19:35 NakedFury joined #minetest-dev
19:36 hmmmm humm
19:36 hmmmm std::bad_alloc seems to abort the program before my catch can catch it
19:38 shadowzone joined #minetest-dev
19:52 kilbith joined #minetest-dev
19:52 paramat joined #minetest-dev
19:52 shadowzone joined #minetest-dev
20:00 paramat hmmmm, my experience is noise params will cause a crash when spread of the highest octave falls below 1, so that seems the most obvious check to do on noise parameters: spread / 2 ^ octaves < 1
20:00 hmmmm this is going nowhere unless I can figure out a way to catch std::bad_alloc
20:00 hmmmm it seems to work fine on Linux though
20:04 paramat i wouldn't worry too much about fixing this, i need to write an explanation of noise params and that will guide people to set sane params
20:08 Taoki_1 joined #minetest-dev
20:09 kahrl odd, I would have expected it maybe the other way around
20:09 kahrl I expected that linux would return some memory but when you tried using it, the OOM killer would lynch the process
20:11 paramat hmmmm, when you have time please let me know your opinions on my plans for biomes: http://irc.minetest.ru/minet​est-dev/2014-11-29#i_4042129
20:22 domtron joined #minetest-dev
20:40 cg72 joined #minetest-dev
20:40 domtron_ joined #minetest-dev
20:42 cg72 joined #minetest-dev
20:52 hmmmm hmmm
20:52 hmmmm paramat:  i like node_stone, but as for the noise param tweaking i'm not so sure..
20:52 hmmmm the concept was to have one centralized biome system
20:53 hmmmm just to be clear, it's the same set of noises representing the same thing, just different for each mapgen
20:53 hmmmm but you want them to go into the mapgen special parameters
20:55 hmmmm when you say "tune biome spreads to the scale of each mapgen", do you mean the overall size of the mapgen in question?
20:59 paramat well i mean some future mapgens may be on such a large scale that standard size biomes would be too small
21:00 paramat also of course spread needs to be tuned according to the number of biomes used
21:01 hmmmm what if each biome defined a "size factor" that gets used for things like this and maybe the size/depth/etc of caves
21:01 hmmmm would that work?
21:01 paramat i assume heat/humidity noises cannot currently be adjusted by the player, and are the same for each mapgen?
21:01 paramat um maybe i'll think on it
21:02 hmmmm the second thing I don't want to manually adjust the spread, i think the spread should be adjusted by the number of biomes currently active like you were mentioning before
21:02 hmmmm they can't be adjusted by the player because i just never got around to it
21:02 paramat okay =)
21:02 hmmmm but the original intent was to have a single setting for biome heat and humidity
21:05 PilzAdam joined #minetest-dev
21:06 paramat "but you want them to go into the mapgen special parameters" yes
21:07 hmmmm hrmm
21:07 hmmmm yeah that could work out i guess
21:08 paramat each mapgen would have it's own heat and humidity noises, but i feel it's essential to scale the biome size to the scale of the mapgen. not so important now but for example watershed looks ridiculous with biomes smaller than 1kn
21:08 paramat "just to be clear, it's the same set of noises representing the same thing, just different for each mapgen" yes thats what i suggest
21:10 shadowzone joined #minetest-dev
21:12 Exio joined #minetest-dev
21:13 paramat i guess what i want could be done just by making the central heat/humid noises user adjustable as you were planning, i'm okay with that
21:14 paramat how about point "use 3 octaves 0.5 persistence for heat/humidity to reduce the amount of tiny biomes and biome stripes" players have complained about tiny biomes next to huge biomes in mgv7, and i get that myself too
21:15 paramat *how about point 2
21:15 hmmmm what's it at right now?
21:15 hmmmm thing is we're walking a fine line between noise quality and continuity
21:15 hmmmm trying to get an interesting biome shape
21:16 paramat um now its 3 0.55 humid 3 0.7 heat
21:16 paramat i think
21:17 paramat yes the biome shapes are more interesting with high persist, but smaller, so i agree it's a balance
21:18 hmmmm see I'm not really too picky on what the biome default noise parameters are
21:18 hmmmm the ones that i have there now are quite arbitrary
21:19 hmmmm biomes are something i was having trouble on and so i quit working on them
21:20 paramat one centralised set of heat/humidity noises is a nice idea theoretically but i feel ideally each mapgen deserves it's own suitably tuned heat/humidity noises
21:20 hmmmm an early problem with biomes were the "bubbles" that occur inside of a biome - my initial idea was to do a fast flood fill inside the current biome map with whatever the dominant biome was, but you can see the issue with that strategy
21:21 paramat small bubbles of other biomoes appearing?
21:21 hmmmm yeah
21:22 paramat thats due to the high persistence
21:22 hmmmm these are all problems that could be solved if maps were pre-generated all at once
21:25 paramat BTW with default biomes defined for mgv5/v7, how do players disable these default biomes to define their own?
21:25 shadowzone joined #minetest-dev
21:26 hmmmm you mean the rock/water one?
21:30 domtron joined #minetest-dev
21:32 paramat i mean, i'm working on the default biomes for mgv5/v7 now, adding the registrations to default/mapgen.lua, but wondering what players do if they want to define their own biomes, how do they 'remove' the default biome definitions
21:32 hmmmm you don't
21:33 hmmmm well since it's only a problem if there's none, I guess the first biome could replace the default one instead
21:33 hmmmm that entire thing is going to get an overhaul soon
21:35 paramat eh? so what's the point of a biome API if players can't replace the default biomes
21:36 paramat lol
21:36 hmmmm after registration of ANY biome, the default biome can never be selected
21:36 paramat ah
21:36 hmmmm the default biome is only there so minetest doesn't crash if no biomes were registered
21:37 paramat so default biomes are discarded as soon as players define new ones, okay
21:39 paramat BTW worldedit does actually have a way to set probabilities by punching, so i will soon make the new tree schems. i'm aiming to have default biomes for mgv5/v7 ready for 0.4.11, but mgv5 will not be stable until the release after at the earliest
21:41 paramat people are talking of a feature freeze, 1 week from now seems suitable, thought i'd mention it since you usually organise this
21:41 ShadowLadyXD joined #minetest-dev
21:41 hmmmm yeah
21:41 hmmmm sounds good I guess
21:42 hmmmm I haven't been as involved as i should be lately
21:45 hmmmm alright
21:46 hmmmm i'll just commit my bad_alloc patch as-is.. I cannot test this because it's been confirmed that FreeBSD 9.1 (what I use) has this specific bug
21:47 paramat biome bubbles are not a problem as long as there aren't too many, they're cute, reducing persistence will reduce how many there are, i'll make a pull for 3 oct 0.5 persist and for node stone
21:48 paramat cool, the noise param crash happens very rarely to players
21:48 paramat i only know of 3 cases
22:09 shadowzone joined #minetest-dev
22:14 ShadowLadyXD joined #minetest-dev
22:35 Miner_48er joined #minetest-dev
22:54 kahrl RealBadAngel: any ideas about #1860?
22:54 exio4 joined #minetest-dev
22:54 ShadowBot https://github.com/minetest/minetest/issues/1860 -- Wield item is always fully bright
22:56 hintss joined #minetest-dev
22:57 celeron55 >CoreSettings
22:57 celeron55 i'm not going to add any settings to minetest anymore if i need to write the new setting to 10 places
22:57 celeron55 add a code generator or something, not this crap
22:59 kahrl celeron55: I agree
23:02 celeron55 (a code generator is bad too, but less bad; i don't know if such can be used in an acceptable way either though)
23:02 hmmmm any comments on my version?
23:02 celeron55 (i *think* integrating code generators is possible to cmake if they are written in C++, which might make them cross-platform enough)
23:03 celeron55 where is your version? i can't find it
23:04 hmmmm [12:06 PM] <hmmmm> do this:  http://fpaste.org/155147/80761141/
23:07 celeron55 that's not too bad otherwise, but storing the local boolean persistently can be a pain in the ass sometimes
23:07 celeron55 (unless just making it global)
23:08 hmmmm it's supposed to be a member of the object
23:09 hmmmm so this is like the way i currently cache settings in my own... abominations^H^H^H^H^H^H^Hcreations, except this auto-updates the settings
23:09 celeron55 not everything is an object
23:09 celeron55 this is not Java
23:10 kahrl volatile is not meant for synchronization
23:10 hmmmm of course not
23:10 hmmmm there's no synchronization needed here, except perhaps the entire setBool should be locked rather than just the set operation
23:11 hmmmm if you don't put volatile, the compiler might cache fast_move_update on the stack and it'd never get updated
23:11 celeron55 if i were making this and really wanted this kind of optimization, i would make a very simple global struct which would contain copies of the settings for quick access and then go from there somehow; not sure how exactly as clearly it needs some kind of synchronization
23:11 hmmmm or just not fetch it from memory in between loops
23:12 celeron55 (of course if it's just boolean settings, then hmmmm's approach probably works in practice for syncing)
23:12 kahrl I don't like adding boilerplate to every place that needs to access some setting in a fast way
23:12 hmmmm it would work in practice for any data types less than or equal to the size of a machine word
23:13 kahrl though I suppose that could be encapsulated in some helper class
23:13 celeron55 (i mean, the volatile part of it; the storage of the value is still a problem9
23:13 celeron55 )*
23:15 celeron55 but really when doing introspection-like stuff in C++, i have noticed that externally implemented code generation really helps
23:16 hmmmm i really hate generated code
23:16 celeron55 it adds a certain amount of complexity, but the complexity stops there and you can generate very optimal things with nice interfaces
23:16 celeron55 and fast compile times because you need less template or class magic
23:17 celeron55 the main problem becomes finding a good way to do the generation without hindering portability or robustness of the build system
23:19 hmmmm what if we just add python as a dependency for building!
23:19 celeron55 lol
23:19 celeron55 windows=dead
23:19 celeron55 anyway, i just want people to consider this too; i'm not implementing it so i don't get to choose anything
23:20 kahrl just ship a python implementation in PowerShell :P
23:24 kahrl how about something like this? https://gist.github.com/kahrl/c61a3ef46eae4770f165
23:28 celeron55 i don't understand where any part of this is supposed to be used
23:29 kahrl the first example is defaultsettings.cpp and the second is coresettings.h
23:30 celeron55 hmm wait, now i do
23:30 kahrl the point is to re-include it every time something needs to be done for all core settings
23:31 celeron55 this could be very handy
23:32 celeron55 it's basically a macro foreach
23:32 kahrl the only problem I see is that cpp is quite limited so it might be hard to do certain things
23:32 kahrl e.g. do something different depending on the type of the setting
23:33 celeron55 well that requires templates and it can get a bit ugly
23:35 celeron55 but i don't think it's going to be a big issue in this case
23:35 celeron55 do you?
23:35 kahrl not really
23:35 kahrl I guess we'll find out if we try it
23:36 celeron55 i would very likely approve a solution based on this
23:37 hmmmm templates make C++ turing complete
23:37 hmmmm on compile time
23:38 celeron55 i think all languages should be turing complete at compile time; it gives a lot of flexibility; in C++ it's implement by pretty much a brainfuck derivative
23:38 celeron55 implemented*
23:39 hmmmm i think i like kahrl's version the best
23:39 hmmmm i really like how it's simple
23:39 domtron joined #minetest-dev
23:43 kilbith joined #minetest-dev
23:51 paramat okay hmmmm thinking on it, it's fine by me to keep one set of heat/humidity noises in mg_biome.cpp, as long as they become settable through .conf, i may well attempt to code that myself and perhaps also the auto scaling of spreads from number of biomes
23:52 paramat then once they're settable i can change the persistence without breaking people's mgv7 worlds
23:56 paramat i made the mistake of complex future-proof coding instead of // Just do something simple for now

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