| 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/50aac763e9f0bf85adb9/raw/f91788eee3a586d292f54302ce8c3a6d74da0f48/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/leprechaun_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_Guidelines#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/minetest/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/minetest-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 |
