| Time |
Nick |
Message |
| 00:08 |
Taoki |
sapier: Rebased fog code on latest master. Was probably hard to test it since the other changes were pretty old |
| 00:10 |
sapier |
no gave exactly same errors as that version you based it ... but I didn't want to test the old errors |
| 00:11 |
Taoki |
Errors? I don't get any compile errors with it here |
| 00:12 |
sapier |
no minetest core error |
| 00:12 |
sapier |
s |
| 00:13 |
Taoki |
Ok. I don't see any other errors either |
| 00:20 |
|
Miner_48er joined #minetest-dev |
| 00:27 |
Taoki |
sapier: Anyway, is it getting delayed this time too? Or can you agree to merge it? |
| 00:29 |
sapier |
yes I do agree but you need a second one to agree |
| 00:35 |
|
djdduty joined #minetest-dev |
| 00:44 |
|
Taoki joined #minetest-dev |
| 00:47 |
|
werwerwer joined #minetest-dev |
| 01:02 |
VanessaE |
Taoki: the sounds in my game come from freesound.org. They are all cc-by-sa or public domain or cc0. |
| 01:03 |
Taoki |
VanessaE: Awesome. Any links to the exact door sounds? |
| 01:03 |
VanessaE |
(at least, the ones I added to homedecor) |
| 01:03 |
Taoki |
I assume it's a big website so |
| 01:06 |
VanessaE |
ohe sec |
| 01:06 |
VanessaE |
one sec* |
| 01:07 |
VanessaE |
hrm |
| 01:07 |
VanessaE |
I thought I had a record of that here somewhere |
| 01:07 |
VanessaE |
hang on, lemme look |
| 01:08 |
VanessaE |
http://freesound.org/people/Slanesh/sounds/31768/ |
| 01:08 |
VanessaE |
this might me one of them |
| 01:08 |
VanessaE |
freesound kept a record of my downloads |
| 01:08 |
VanessaE |
http://freesound.org/people/j1987/sounds/106116/ |
| 01:09 |
VanessaE |
and this one for the gates |
| 01:10 |
VanessaE |
the interesting thing is there's some popular video, I forget exactly what, which uses that door closing sound at the very end as well :) |
| 01:11 |
VanessaE |
at least I think so. anyway the door sound is cc-by-sa, the gate sound is cc0 |
| 01:19 |
VanessaE |
I just pushed some attribute info to homedecor git for that, just to make sure :) |
| 01:29 |
|
OWNSyouAll joined #minetest-dev |
| 01:29 |
|
sapier left #minetest-dev |
| 01:37 |
Taoki |
Thanks |
| 01:38 |
VanessaE |
no prob |
| 01:39 |
VanessaE |
you may find the ones I post-processed for Homedecor's use to be more suitable than the raw sound files on freesound.org, as they've already been trimmed, time-compressed/extended, and normalized as needed. |
| 01:40 |
Taoki |
Yeah. Mostly interested for the credits |
| 01:40 |
VanessaE |
ohok |
| 01:40 |
Taoki |
I'm hoping to get them into minetest_game for the default doors too. With extra sound effects such as for player damage, if the current Lua API allows for that |
| 01:56 |
|
bas080 joined #minetest-dev |
| 02:07 |
|
RealBadAngel joined #minetest-dev |
| 02:09 |
RealBadAngel |
hi |
| 02:09 |
RealBadAngel |
how do you like the effect? http://i.imgur.com/WLLIlyZ.png |
| 02:09 |
VanessaE |
hi |
| 02:09 |
VanessaE |
nice |
| 02:11 |
RealBadAngel |
this is done only in shaders, no extra files needed. and works with default textures |
| 02:12 |
VanessaE |
on-the-fly normalmap generation |
| 02:12 |
VanessaE |
nice |
| 02:14 |
RealBadAngel |
its just some math, 1st gausian blur on the texture then sobel 3x3 filter |
| 02:34 |
|
djdduty joined #minetest-dev |
| 02:34 |
|
djdduty joined #minetest-dev |
| 02:34 |
|
OldCoder joined #minetest-dev |
| 02:36 |
kaeza |
/home/diego/src/minetest/po/lt/minetest.po: warning: Charset "CHARSET" is not a portable encoding name. |
| 02:42 |
kaeza |
also I found something interesting... mt_game seems to be leaking a few globals it probably shouldn't |
| 02:58 |
kaeza |
http://pastebin.com/PDt2ZCwQ |
| 03:03 |
VanessaE |
eek |
| 03:07 |
kaeza |
for anyone interested in running the test, add this at the top of builtin/builtin.lua: http://pastebin.com/UNRzB24F |
| 03:16 |
kaeza |
what the: [globalchecker] new global n at @/home/diego/src/minetest/bin/../builtin/falling.lua:161 |
| 03:56 |
|
diemartin joined #minetest-dev |
| 03:59 |
|
Zeitgeist_ joined #minetest-dev |
| 03:59 |
|
Zeitgeist_ joined #minetest-dev |
| 04:18 |
hmmmm |
hmmmm |
| 04:18 |
hmmmm |
hmmmmmm |
| 04:18 |
hmmmm |
hmmmmmmmmm |
| 04:19 |
hmmmm |
did the SimpleThread->JThread replacement thing get tested yet? |
| 04:19 |
hmmmm |
I want to merge it already |
| 04:22 |
hmmmm |
also if sfan5 is around I'd like to know what the status is on the playerlist tab, and if he could merge all of what he has into a single pull request |
| 04:23 |
hmmmm |
anyway, it seems I was wrong about the reason why the cave shadows exist. I was screwing around with it a little this morning and I couldn't get it fixed |
| 04:24 |
hmmmm |
I was considering maybe we should add a "slow but perfect map" option that re-generates discrete structures that would have been cut off instead of writing them to neighboring chunks |
| 04:29 |
|
us}0gb joined #minetest-dev |
| 04:49 |
ShadowNinja |
hmmmm: IIRC john_minetest tested it. |
| 04:50 |
hmmmm |
jon_tests_minetest |
| 04:50 |
|
mrtux joined #minetest-dev |
| 06:12 |
|
nore joined #minetest-dev |
| 07:42 |
|
darkrose joined #minetest-dev |
| 07:42 |
|
darkrose joined #minetest-dev |
| 07:46 |
nore |
does Minetest discard map changes if it runs out of memory while trying to save the map? |
| 08:29 |
|
Miner_48er joined #minetest-dev |
| 08:36 |
|
proller joined #minetest-dev |
| 09:11 |
|
Calinou joined #minetest-dev |
| 10:27 |
|
Akien joined #minetest-dev |
| 10:45 |
|
bas080 joined #minetest-dev |
| 11:07 |
|
Akien joined #minetest-dev |
| 11:31 |
|
john_minetest joined #minetest-dev |
| 11:41 |
|
ImQ009 joined #minetest-dev |
| 11:49 |
thexyz |
nore: I don't think modern software can handle out-of-memory errors |
| 11:49 |
thexyz |
AFAIK on Linux malloc (by default) never fails |
| 11:50 |
nore |
dunno... I generated a lot of map |
| 11:50 |
thexyz |
and then when you try to access this memory and is out of it OOM killer is coming for you? |
| 11:50 |
thexyz |
so if that's the case then you can't do anything |
| 11:50 |
nore |
and it worked fine, but when saving, my computer went swapping to hell |
| 11:50 |
nore |
and then, the map was almost completely ereased |
| 11:51 |
nore |
(and FYI, I have 8GB RAM and 16GB swap...) |
| 11:51 |
thexyz |
was the process killed? |
| 11:51 |
nore |
there was nothing in debug.txt except the usual start messages |
| 11:51 |
thexyz |
was the process killed though? |
| 11:52 |
nore |
I reckon it was, since there was no "singleplayer leaves game" line in debug.txt |
| 11:52 |
nore |
I don't know if it was really killed though |
| 11:52 |
thexyz |
you can check /var/log/messages or /var/log/syslog |
| 11:53 |
thexyz |
or some other /var/log/ file for "killed process" |
| 11:54 |
nore |
thexyz, I can't see that since I got "radeon: The kernel rejected CS, see dmesg for more information." since then, which flooded my /var/log/messages (Minetest does it quite a lot...) |
| 11:57 |
nore |
and a grep -R "killed process" in /var/log gave nothing |
| 11:59 |
Taoki |
john_minetest: Yeah |
| 12:01 |
celeron55 |
fun fact: sqlite can handle out-of-memory errors and it is unit tested for doing that always properly |
| 12:02 |
celeron55 |
(or otherwise automatically tested... "unit test" is a bit too specific) |
| 12:02 |
|
EdB joined #minetest-dev |
| 12:11 |
thexyz |
what would be a good way to make the player jump when he collides with a node? (when running forward) |
| 12:12 |
Taoki |
thexyz: There was a trampouline mod on a server once, maybe that helps |
| 12:12 |
thexyz |
I need a client-side modification |
| 12:16 |
|
EdB left #minetest-dev |
| 12:18 |
Taoki |
john_minetest: Ok. Thanks |
| 12:18 |
|
sapier joined #minetest-dev |
| 12:19 |
sapier |
hello |
| 12:20 |
|
PilzAdam joined #minetest-dev |
| 12:23 |
sapier |
John_minetest did you check the simplethread removal branch yet? |
| 12:24 |
sapier |
the one you asked how to test yesterday |
| 12:27 |
|
jin_xi joined #minetest-dev |
| 12:30 |
|
rubenwardy joined #minetest-dev |
| 12:31 |
sapier |
thanks |
| 12:36 |
sapier |
hmmmm I'm merging the simplethread removal now |
| 12:37 |
Taoki |
sapier: [14:19:22] <john_minetest> Taoki: I tested it. Runs fine and looks good. <<<< Regarding the colored fog, just so you know there's another +1 |
| 12:38 |
Taoki |
Since that was before you re-joined |
| 12:38 |
Taoki |
Need to go for a bit now also, brb |
| 12:38 |
sapier |
ok so test + one core dev comlete another one to agree and it's in |
| 12:40 |
sapier |
come on guys taokis changes are quite fine isn't here anyone to agree to it? |
| 12:43 |
sapier |
taoki? |
| 12:59 |
nore |
Taoki, I do like it too |
| 12:59 |
nore |
john_minetest, and no, it does not require shaders |
| 12:59 |
nore |
sapier, ^ |
| 12:59 |
sapier |
nore is this an agreement? |
| 13:00 |
nore |
yep... (I did not really check the code style though; it looked fine at first glance) |
| 13:02 |
Taoki |
sapier: Back. Yes? |
| 13:02 |
nore |
sapier, leave me a few seconds to test it though |
| 13:02 |
sapier |
ok I'm gonna add a setting to make pilzadam happy too |
| 13:03 |
Taoki |
Fine by me. I suggest enabling it by default though |
| 13:03 |
sapier |
yes |
| 13:03 |
Taoki |
A setting might be unneeded for something this small. But if anyone (like PilzAdam) really hates it for any reason, I don't mind. |
| 13:04 |
Taoki |
Note that the code is easy to tweak, and will be tweaked and improved in the future. It's important for it to be in at the current stage, so future changes to the sky can also include the directional coloring system |
| 13:04 |
|
ImQ009 joined #minetest-dev |
| 13:06 |
nore |
ok, it still works... ;) I'm ok for it |
| 13:06 |
sapier |
why are there so much commented bright_dawn values in there? |
| 13:07 |
nore |
Taoki, however, I have an idea: what about using a texture to know the color of sky depending on view yaw and time? |
| 13:11 |
|
Zeitgeist_ joined #minetest-dev |
| 13:12 |
nore |
sapier, is that normal? https://github.com/minetest/minetest/commit/e9e9fd7c3f12bc5119b567ad37527d777859dbc0#diff-1dc3934293fad6b8769890134ac51c21R69 |
| 13:13 |
sapier |
normal? |
| 13:14 |
|
smoke_fumus joined #minetest-dev |
| 13:14 |
Taoki |
nore: RBA will add such a texture later |
| 13:14 |
sapier |
oh the missing constructor value ... that's been a warning |
| 13:14 |
Taoki |
It's a different feature planned for the future |
| 13:14 |
nore |
the "mapgen debug info" line that changes in a commit about threads |
| 13:15 |
Taoki |
Going to be away for an hour, hopefully I'm not needed for the code merge now |
| 13:15 |
nore |
Taoki: ok, didn't know that |
| 13:15 |
sapier |
it's a style fix only, at least it's supposed to be one |
| 13:15 |
sapier |
shouldn't change behaviour at all |
| 13:16 |
nore |
ok, didn't know that... it just looked weird in that commit |
| 13:16 |
sapier |
you're right looks suspicious |
| 13:16 |
sapier |
should've noted this in pull request comment |
| 13:22 |
sapier |
taoki can you verify I did do it right https://github.com/sapier/minetest/tree/colored_fog |
| 13:29 |
PilzAdam |
sapier, why do you change the whole minetest.conf.example? |
| 13:30 |
Taoki |
sapier: Can you provide a link to the diff against master please, so I can see the actual changes? |
| 13:30 |
Taoki |
Will check them in 45 minutes at most or so |
| 13:30 |
PilzAdam |
sapier, do you read the settings in a function that is called for every frame? |
| 13:30 |
thexyz |
what's the point of adding a setting no one will use |
| 13:31 |
sfan5 |
Taoki: https://github.com/sapier/minetest/compare/colored_fog |
| 13:31 |
Taoki |
thexyz: PilzAdam doesn't seem to be fond of the colors. He and others might want to turn it off, not sure |
| 13:31 |
Taoki |
sfan5: Thanks, will see later |
| 13:31 |
thexyz |
alright, let me correct myself |
| 13:31 |
thexyz |
what's the point of adding a setting only PilzAdam (who always bitches about random things btw) will be using? |
| 13:32 |
Taoki |
Anyway, if PilzAdam is ok with it going in (even if he doesn't really like the feature), the setting might not be needed. I don't want my feature to upset any of the users or developers, so it prolly depends on him |
| 13:32 |
Taoki |
BRB again |
| 13:33 |
PilzAdam |
I dont understand why nobody sees how bad this looks |
| 13:33 |
thexyz |
maybe because it actually looks fine and you're the wrong one? |
| 13:34 |
PilzAdam |
clouds that change the color all the time looks good? |
| 13:34 |
PilzAdam |
john_minetest, the fog isnt the problem at all |
| 13:35 |
PilzAdam |
if you look at the moon at sunset and move the camera up the clouds change their color from blue to red |
| 13:36 |
PilzAdam |
the color of the clouds should not depends on yaw, it should depend on the position |
| 13:37 |
sapier |
but this is a minor issue usually you wont even notice this if you don't know it |
| 13:37 |
sapier |
guess you're primed for this issue as it was worse in prior versions (according to comments) |
| 13:37 |
PilzAdam |
people even noticed that the sky is black when looking down and the looking up fast |
| 13:38 |
sapier |
ppl keep running through world constantly looking up and down? |
| 13:39 |
|
rubenwardy_ joined #minetest-dev |
| 13:41 |
sapier |
yes it's not perfect for sure but it's a huge improvement to in game atmosphere |
| 13:41 |
PilzAdam |
it only looks good as long as you dont move the camera too much |
| 13:42 |
sapier |
with "too much" beeing angle switches above 180° ... |
| 13:43 |
PilzAdam |
too much means more than ~ 20° |
| 13:43 |
sapier |
guess thats a subjective feeling |
| 13:45 |
sapier |
but I added a setting to disable it anywa |
| 13:45 |
sapier |
y |
| 13:46 |
PilzAdam |
eh, why is the fog so near when I look up and then down again? |
| 13:46 |
Taoki |
PilzAdam: So colors don't change if you're looking fully up or down, and rotating the view. That looked even worse |
| 13:46 |
Taoki |
And BRB again, I'm here back and forth ATM |
| 13:48 |
sapier |
PilzAdam: https://github.com/sapier/minetest/commits/colored_fog can you verify this works for you |
| 13:49 |
sapier |
fog beeing near is not a issue of colored fog it's there for non colored too |
| 13:54 |
PilzAdam |
why dont we just make the color independend from the yaw and give the fog same color as the clouds? |
| 13:55 |
sapier |
because its all about the direction dependent color it'd be strange to look at cold moon and have bright sunset colors |
| 13:56 |
PilzAdam |
then let the moon rise a bit later |
| 13:56 |
PilzAdam |
(IRL the color doesnt depend on yaw either) |
| 13:56 |
sapier |
this removes the most pressing issue only, clouds and fog don't glow in oposit direction of sunset |
| 13:57 |
sapier |
it does! |
| 13:57 |
sapier |
did you ever see clouds in east glow as bright as those in west at sunset? |
| 13:57 |
PilzAdam |
the problem is just that we cant set the color of parts of the fog |
| 13:58 |
PilzAdam |
sapier, but the clouds in the west dont change the color if you look at the east |
| 13:58 |
sapier |
and that's why fog is direction dependent it's best we can get without dynamic lighting |
| 13:58 |
PilzAdam |
but dont do it for clouds, it looks really bad for clouds |
| 13:58 |
sapier |
you don't see the clouds in west if you look east ;-) |
| 13:59 |
|
zat joined #minetest-dev |
| 13:59 |
PilzAdam |
then a cloud above you or so |
| 14:00 |
sapier |
due to my testing color change becomes really noticable once you have "sun" or moon on screen ... you have to look very carefull to see a change before |
| 14:01 |
Taoki |
sapier: https://github.com/sapier/minetest/compare/colored_fog looks good to me. |
| 14:01 |
sapier |
of course hardware lighting doing the colours would be way better (as always) but taokis solution is already close and maybe it can be tweaked even more |
| 14:02 |
PilzAdam |
sapier, have you seen my 2 comments on your change? |
| 14:02 |
Taoki |
I still don't believe a setting is needed. Unless PilzAdam really really hates the change and can't live with it as is (which is ok, though a matter of taste which also justifies the setting) |
| 14:02 |
sapier |
not yet where do I find them? |
| 14:03 |
Taoki |
sapier: Hardware lighting will come later. Soon... :) |
| 14:03 |
PilzAdam |
<PilzAdam> sapier, why do you change the whole minetest.conf.example? |
| 14:03 |
PilzAdam |
<PilzAdam> sapier, do you read the settings in a function that is called for every frame? |
| 14:04 |
sapier |
first is a cleanup it's not whole just some minor whitespace fixes ... second ... good point need to find a better way to do it |
| 14:04 |
|
Akien joined #minetest-dev |
| 14:05 |
thexyz |
"read settings" is just a single map find() call |
| 14:06 |
Taoki |
PilzAdam: But yeah, this is why looking up changes the colors: Imagine there's no yaw dependence, fog color is blended only based on the direction you look in. If you look toward the horrizon, it's all fine. Now look completely up however. If you turn your view 180* in place, the entire sky changes color in a bizzare way |
| 14:06 |
Taoki |
I hope that makes sense, harder to explain without showing the 3D motion |
| 14:06 |
sapier |
depends on map size how fast this is thexyz |
| 14:06 |
sapier |
ok not exactly guess map uses hashing |
| 14:07 |
thexyz |
O(log N) |
| 14:07 |
thexyz |
no, std::map uses red black trees |
| 14:07 |
thexyz |
and std::unordered_map (c++11) uses hashes |
| 14:07 |
thexyz |
but the other day I was told that unordered_map is actually slower ;_; |
| 14:07 |
thexyz |
anyway |
| 14:07 |
sapier |
I'll read it in constructor this setting isn't something to change ingame |
| 14:08 |
|
iqualfragile joined #minetest-dev |
| 14:08 |
thexyz |
I think you can do like 10 ^ 6 reads per second? |
| 14:08 |
sapier |
why waste cpu instructions that can be used for better things? |
| 14:08 |
thexyz |
so don't optimize where you don't need |
| 14:08 |
sapier |
it's global step optimizations in there are never wasted |
| 14:09 |
thexyz |
eh |
| 14:09 |
thexyz |
it's pointless to argue anyway |
| 14:09 |
thexyz |
feel free to do whatever you want with this |
| 14:09 |
sapier |
true |
| 14:09 |
thexyz |
but just know that there will be no change |
| 14:09 |
PilzAdam |
Sep 19 20:02:44 <hmmmm>that is NOT just a binary tree lookup |
| 14:09 |
PilzAdam |
Sep 19 20:02:57 <hmmmm>you forgot about the lock, all the string comparisons, then the conversion |
| 14:09 |
PilzAdam |
Sep 19 20:03:05 <hmmmm>settings is *SLOW* |
| 14:10 |
sapier |
no change? I admit the change isn't very big but it's not 0 |
| 14:10 |
Taoki |
Is this about the setting for colored fog? |
| 14:10 |
thexyz |
SLOOOOOW |
| 14:10 |
thexyz |
string comparisons! SLOOOW |
| 14:10 |
thexyz |
well whatever |
| 14:10 |
thexyz |
O(len * logN) if you want |
| 14:11 |
thexyz |
by the way, does this shit support read write locks? |
| 14:11 |
thexyz |
jthread, that is |
| 14:11 |
sapier |
PA better this way? |
| 14:11 |
thexyz |
eh, readers-writer lock is how it's called |
| 14:11 |
sapier |
you're talking about jthread thexyz? |
| 14:11 |
thexyz |
yes |
| 14:12 |
thexyz |
I guess it doesn't |
| 14:12 |
sapier |
no mutex and semaphores only |
| 14:12 |
thexyz |
oh well |
| 14:12 |
PilzAdam |
sapier, what way? |
| 14:13 |
Taoki |
sapier: Anyway, as for the fog setting: Please ask PilzAdam if he really wants to turn my fog off in case it's merged. He said he doesn't like it, but I'm not clear if he really wants to be able to turn it off if it's added to minetest, or can live with it as is. Just looking to be clear is all |
| 14:13 |
sapier |
I added a member to sky read it on construction and only check for that member instead of reading from setting |
| 14:13 |
Taoki |
PA didn't tell me here, just that he doesn't like the current planding |
| 14:13 |
Taoki |
**blending |
| 14:13 |
PilzAdam |
sapier, thats better, yes |
| 14:13 |
sapier |
I should push it true :-) |
| 14:13 |
Taoki |
So we don't add the setting for no reason |
| 14:14 |
sapier |
ok pushed to my branch |
| 14:14 |
PilzAdam |
now why do you call the setting "disable_*"? |
| 14:14 |
sapier |
if you want another name I change it ... I don't care about naming |
| 14:15 |
sapier |
oops forgot a setting |
| 14:15 |
sapier |
so what name do you prefere? |
| 14:15 |
Taoki |
sapier: Yeah, setting the option to "true" to enable it makes more sense. But default it to true then |
| 14:16 |
PilzAdam |
sapier, the same thing without "disable_" in front of it |
| 14:16 |
sapier |
so I call setting colored_fog ? does everyone agree? |
| 14:16 |
Taoki |
sapier: Old fog is colored too. "directional fog" would be more correct |
| 14:16 |
Taoki |
directional_fog |
| 14:17 |
sapier |
ok |
| 14:17 |
Taoki |
or something like that |
| 14:17 |
PilzAdam |
what Taoki said is bette |
| 14:17 |
PilzAdam |
+r |
| 14:17 |
sapier |
then "directional_colored_fog"? |
| 14:17 |
PilzAdam |
and "Use weird color changes for clouds and fog when moving camera" as description |
| 14:17 |
sapier |
it's not the fog that changes but it's color |
| 14:18 |
Taoki |
In the end, it might be nice to have a setting to disable it. The current / old style doesn't look outright horrible either, some might like it more |
| 14:18 |
sapier |
ok PA ... but I'll skip the "weird" ;-) |
| 14:18 |
Taoki |
sapier: Yes, that's a correct name too |
| 14:18 |
Taoki |
As for description, more correct would be "Make fog and sky colors depend on dun and moon direction" |
| 14:18 |
Taoki |
**sun |
| 14:19 |
Taoki |
Or something. But anything's fine by me |
| 14:19 |
PilzAdam |
no! thats wrong |
| 14:19 |
PilzAdam |
it doesnt depend on sun and moon, but on fov |
| 14:19 |
PilzAdam |
thats why its so wrong |
| 14:19 |
Taoki |
Ok. Your description without the "weird" then ;) |
| 14:19 |
Taoki |
Yeah |
| 14:20 |
Taoki |
Well not on FOV specifically. It depends on where the player's "crosshair" is pointed |
| 14:20 |
Taoki |
FOV can be anything |
| 14:20 |
Taoki |
I just use the rotation of the player's camera\ |
| 14:20 |
PilzAdam |
eh, s/fov/yaw & pitch&/ |
| 14:20 |
Taoki |
yaw & pitch, yeah |
| 14:20 |
PilzAdam |
(I always mix up fov and yaw) |
| 14:21 |
sapier |
# Make fog and sky colors depend on daytime (dawn/sunset) and view direction |
| 14:21 |
Taoki |
I believe this is also the same thing Minecraft does. And no, that's NOT to say I did the same to copy MC :P Just that I noticed there how much it improves the visualls |
| 14:21 |
Taoki |
Sounds good |
| 14:22 |
|
salamanderrake joined #minetest-dev |
| 14:24 |
sapier |
ok updated my branch |
| 14:25 |
sapier |
argh |
| 14:27 |
sapier |
ok that's it final call for comments if there aren't any issues I'm gonna merge it in 15 minutes |
| 14:28 |
Taoki |
The latest decisions on the fog code are perfect by me, no comments there |
| 14:28 |
sapier |
that's negative effect of forced push |
| 14:28 |
sapier |
sorry john |
| 14:30 |
sapier |
did anyone look for the chat crash by now? |
| 14:34 |
sapier |
the setting is now called directional_colored_fog |
| 14:34 |
sapier |
yes |
| 14:35 |
sapier |
did you check the setting is doing what it's expected to do? |
| 14:37 |
Taoki |
It looks like before right? |
| 14:38 |
Taoki |
Ok, good then |
| 14:42 |
Taoki |
Just so everyone knows: I'm working on adding extra sound effects for minetest_game. I added door open / close sounds, and am next working on adding sounds for flowing liquid sources. I'll see where I can find more effects to add |
| 14:43 |
Taoki |
Minetest is still really lacking in the sound department, and I'm hoping to change that. Don't worry, not planning to add any intensive checks or anything annoying... just normal sounds that need to be there |
| 14:47 |
sapier |
ok merging now |
| 14:53 |
sapier |
any comments to this one https://github.com/minetest/minetest/pull/640 (core based surface detection) |
| 14:55 |
sapier |
and this one might be usefull too https://github.com/minetest/minetest/pull/670 |
| 15:05 |
sapier |
returns y-value of first surface starting at bottom or nil if no surface found |
| 15:05 |
sapier |
;-) at least that's what is written within lua_api.txt |
| 15:07 |
PilzAdam |
it looks for air, not the surface, though |
| 15:07 |
PilzAdam |
oh, wait, theres a setting for that |
| 15:07 |
sapier |
usually that's what is considered as surface |
| 15:08 |
PilzAdam |
there is the problem with caves, though |
| 15:08 |
sapier |
there's no perfect solution to the surface problem |
| 15:09 |
sapier |
that's why you can specify min/max to look for it ... but if you have an idea to improve it you're welcome |
| 15:10 |
PilzAdam |
search from the top? |
| 15:10 |
|
hmmmm joined #minetest-dev |
| 15:10 |
nore |
sapier, I have a question though... now that we have voxel manip, is it really useful? |
| 15:10 |
sapier |
searching from top has issues with trees |
| 15:10 |
sapier |
voxelmanip is a quite heavy thing it's only usefull if you need to verify more then 10k nodes |
| 15:11 |
sapier |
and this is true for luajit only ... without luajit voxelmanip may be completely useless |
| 15:13 |
iqualfragile |
https://github.com/minetest/minetest/commit/848f80b2e53155c76f598c2f7e0ebaff1faea8dc recompiling right now!!! |
| 15:14 |
* nore |
too |
| 15:15 |
|
Warr1024 joined #minetest-dev |
| 15:16 |
Warr1024 |
I noticed that it looks like the server is loading the liquid_update setting only once on startup, then never checking it again. |
| 15:16 |
Warr1024 |
Is this an important design feature? It's preventing me from controlling liquid update speed via minetest.setting_set() |
| 15:19 |
nore |
Warr1024: <hmmmm> settings is *SLOW* |
| 15:20 |
hmmmm |
Warr1024, settings are meant to be settings |
| 15:20 |
sapier |
liquid_update is nit supposed to be changed within game |
| 15:20 |
hmmmm |
not variables |
| 15:20 |
sapier |
change of settings is assumed to be active after restart only |
| 15:20 |
Warr1024 |
ugh. |
| 15:20 |
Warr1024 |
basically, I'm trying to freeze time. |
| 15:21 |
Warr1024 |
there are only a handful of builtins I need to worry about. |
| 15:21 |
Warr1024 |
the rest will be game content. |
| 15:21 |
sapier |
*smile* try to freeze mobs ;-) |
| 15:21 |
Warr1024 |
falling_node and builtin:item I already managed, since it's just velocities and accelerations. |
| 15:21 |
Warr1024 |
naw, I'm working on a total conversion this time. |
| 15:21 |
Warr1024 |
new game type. |
| 15:22 |
Warr1024 |
the built-ins were pretty tricky, but I managed. |
| 15:22 |
hmmmm |
you want to freeze water from within lua? |
| 15:22 |
Warr1024 |
yep |
| 15:22 |
hmmmm |
wait, why? |
| 15:22 |
Warr1024 |
freeze, slow down, speed up. |
| 15:22 |
hmmmm |
also I don't think you want to actually stop liquid updating |
| 15:23 |
hmmmm |
I think what you actually want to do is control the viscosity of a liquid |
| 15:23 |
Warr1024 |
that would be nice. |
| 15:23 |
hmmmm |
which there's a per-node setting for |
| 15:23 |
Warr1024 |
if I could make it infinitely viscous, it could be frozen that way. |
| 15:23 |
Warr1024 |
viscosity doesn't affect flow speed |
| 15:23 |
hmmmm |
but alas, you can't modify it outside of the so-called node registration phase |
| 15:23 |
Warr1024 |
only walking speed within the liquid. |
| 15:23 |
hmmmm |
you sure about that? |
| 15:23 |
Warr1024 |
yeah, I messed with it a bunch for a different mod. |
| 15:24 |
hmmmm |
i don't think that's true, but now that you say so it has me wondering |
| 15:24 |
Warr1024 |
if you set it insanely high, it makes you actually walk *backwards* |
| 15:24 |
hmmmm |
there's something that could use a rangelim() |
| 15:24 |
hmmmm |
ANYWAY all this is beside the point |
| 15:24 |
Warr1024 |
yeah. |
| 15:24 |
hmmmm |
here's what I would like to eventually see for settings: |
| 15:25 |
hmmmm |
I would like to see all of the settings called profiled in a single server step to determine how wasteful it is |
| 15:25 |
hmmmm |
since there's the lock acquire, property lookup, property parsing, and so on |
| 15:25 |
hmmmm |
then I'd like to change it so instead settings is like on gigantic global struct |
| 15:25 |
hmmmm |
instant access to everything |
| 15:26 |
Warr1024 |
it'd be nice if they could all change dynamically at runtime, and be parsed at change time instead of at lookup time or something, since they should change infrequently under any circumstances. |
| 15:26 |
Warr1024 |
I've actually had some success changing time_speed. |
| 15:26 |
Warr1024 |
though it only affects the day cycle animation. |
| 15:26 |
hmmmm |
I really don't think the locks are necessary because settings are set hardly ever |
| 15:26 |
Warr1024 |
basically I'm working on a strategy game. |
| 15:26 |
hmmmm |
and under very controllable circumstances |
| 15:26 |
Warr1024 |
you freeze time to order units around, then run it or fast-forward to watch the outcome. |
| 15:27 |
sapier |
those locks are absolutely required unless you want to disable settings for async |
| 15:27 |
nore |
Warr1024, to freeze liquids, you could put airlike nodes around to block them |
| 15:27 |
hmmmm |
lol |
| 15:27 |
|
Miner_48er joined #minetest-dev |
| 15:27 |
Warr1024 |
ugh, that's not really a complete solution... |
| 15:27 |
hmmmm |
whatever |
| 15:28 |
hmmmm |
we can just change everything to use atomic accesses |
| 15:28 |
sapier |
there's nothing like atomic access on x86 beyond setting an integer |
| 15:28 |
hmmmm |
that's all we need |
| 15:29 |
hmmmm |
for things such as strings, we can just swap around pointer values |
| 15:29 |
sapier |
there may not be ANY check prior swapping |
| 15:29 |
hmmmm |
and actually I think that's not accurate as of ivy bridge either, with the new transaction instructions |
| 15:30 |
sapier |
e.g. minetestes queue handling if empty ... get from queue is useless if you want to parallize work |
| 15:30 |
hmmmm |
meh I'll figure something out |
| 15:30 |
sapier |
"if empty ... get from queue" |
| 15:35 |
hmmmm |
if you have a reader on some string setting and you update the value out from under it, then so what? |
| 15:35 |
hmmmm |
if you have a setting being changed in one thread and some consumer of that setting in another, don't you think that other thread is going to be one that doesn't care about the *real time* value of that setting? |
| 15:35 |
sapier |
in worst case crash due to access of invalid memory |
| 15:36 |
hmmmm |
since it'll probably be periodically checked |
| 15:36 |
hmmmm |
yes but you're assuming people are swapping out other things related with the string setting |
| 15:36 |
hmmmm |
at which point the limited scope of the settings lock wouldn't be of any use |
| 15:37 |
hmmmm |
the actual std::string could be destroyed at a later point in time, I'm thinking of some kind of GC system |
| 15:37 |
sapier |
no what on adding a setting? |
| 15:37 |
sapier |
two threads adding a new setting simultanously |
| 15:37 |
hmmmm |
yeah? and? |
| 15:38 |
sapier |
one starts map opperation but doesn't finish ... second starts and finishes |
| 15:38 |
sapier |
first one continues with old data breaking everything |
| 15:38 |
hmmmm |
oh no I want to get rid of the map operation completely |
| 15:38 |
hmmmm |
I always thought the map lookup was silly |
| 15:38 |
sapier |
and how do you want to do it? |
| 15:38 |
hmmmm |
plainly access global settings from some kind of struct |
| 15:38 |
sapier |
a struct? |
| 15:39 |
hmmmm |
int update = g_settings->liquid_update |
| 15:39 |
sapier |
so only predefined settings are available |
| 15:39 |
sapier |
quite a limitation to now |
| 15:39 |
hmmmm |
how's that a limitation? |
| 15:39 |
sapier |
atm you can set arbitrary values |
| 15:39 |
hmmmm |
are there any settings that are not predefined? |
| 15:39 |
sapier |
more than a few |
| 15:39 |
hmmmm |
like? |
| 15:39 |
sapier |
any mod can define it's own setting |
| 15:39 |
hmmmm |
they should do that in their own namespace |
| 15:40 |
hmmmm |
I don't think it's right for them to modify minetest.conf's settings |
| 15:40 |
sapier |
then you need to add a new minetest.set_mod_setting |
| 15:40 |
hmmmm |
for the moment let's not consider backward compatibility |
| 15:40 |
hmmmm |
just in theory, how this would work |
| 15:40 |
sapier |
and you can remove access to your settings from scriptapi completely |
| 15:40 |
sapier |
there's no need to have access to core settings for mods |
| 15:40 |
hmmmm |
no, I think scriptapi should be able to access global settings |
| 15:41 |
sapier |
why? |
| 15:41 |
hmmmm |
because anything else would break the entire universe for one |
| 15:41 |
hmmmm |
unless you think they should only have read access |
| 15:41 |
hmmmm |
and then they write their own modifications to a mod-specific conf file |
| 15:41 |
sapier |
switching to fixed settings already breaks everything so it's perfectly fine to rethink about core setting acces for scriptapi |
| 15:41 |
hmmmm |
or rather, GAME-specific conf file (which already exists), aha |
| 15:42 |
hmmmm |
I think I'd be able to make it work |
| 15:42 |
hmmmm |
carefully enough to not break anything |
| 15:43 |
sapier |
I don't think this can be done without breaking compatibility ... you can proof me wrong |
| 15:43 |
hmmmm |
right |
| 15:43 |
hmmmm |
we'll see |
| 15:43 |
hmmmm |
but again, this won't happen for a while. there are more pressing issues around right now |
| 15:44 |
sapier |
I agree for that ;-) |
| 15:44 |
hmmmm |
it's just needed to take minetest's locking to a more advanced level |
| 15:44 |
hmmmm |
now as for readers on data types that would get deleted |
| 15:44 |
hmmmm |
say you have a string setting that you set |
| 15:44 |
sapier |
I don't think about removing locking on thinkig about advanced level ;-) more about making locking more sane |
| 15:44 |
hmmmm |
the pointer is swapped out, you have someone using that string in another thread |
| 15:45 |
hmmmm |
then you delete that std::string and everything explodes |
| 15:45 |
hmmmm |
instead... |
| 15:46 |
hmmmm |
add the std::string to some GC queue, atomically decrement the ref count, and then some thread (who, no clue) periodically checks it over and deletes anything with a 0 ref count |
| 15:46 |
hmmmm |
dead simple and i don't see any problem with it |
| 15:46 |
sapier |
no plz don't add gc to c++ |
| 15:47 |
hmmmm |
it's not real GC |
| 15:47 |
sapier |
we'll have enough work to get basic threading issues to work |
| 15:47 |
hmmmm |
and it'd be necessary to do what I'd like to do or else we'd have memory leaks or freed data while it's being used |
| 15:47 |
sapier |
I'd be perfectly fine if you just return a value instead |
| 15:47 |
hmmmm |
can't do that |
| 15:48 |
hmmmm |
can't do that atomically, rather |
| 15:48 |
sapier |
you can't do ref counting in a atomic way too |
| 15:48 |
hmmmm |
why not? |
| 15:49 |
sapier |
ref count ++ <threadswitch> replace <threadswitch> return replaced string --> old one counted up 1 too much new one missing 1 |
| 15:50 |
hmmmm |
hrmm |
| 15:51 |
sapier |
need to lock that again ... so nothing is won |
| 15:52 |
Warr1024 |
I was actually very tempted to add a setting that's just a multiplier for the dtime when doing the server env step, which as I understand it would control the true time flow speed... but that'd probably desync the client pretty badly at very low values, esp. zero... |
| 15:52 |
Warr1024 |
If anyone's interested in stuff like pausing a server or a "bullet-time" mod or something, though, I can see if I can get it working OK and put in a pullreq. |
| 15:53 |
hmmmm |
sapier, you increment the ref count only after you completed fetching the string |
| 15:53 |
hmmmm |
oh |
| 15:53 |
hmmmm |
nevermind |
| 15:53 |
hmmmm |
crap, |
| 15:54 |
hmmmm |
we need a 12-byte atomic swap now |
| 15:54 |
Warr1024 |
maybe you can just use a message-passing mechanism. |
| 15:54 |
Warr1024 |
i.e. the mod that wants to modify a setting just adds it to a quue |
| 15:55 |
hmmmm |
we're talking about something different |
| 15:55 |
Warr1024 |
then have a thread that polls that queue for settings updates every so often and applies them all |
| 15:56 |
Warr1024 |
ah, thought you were still talking about ways to deal with the lock overhead around setting atomicity. |
| 15:56 |
Warr1024 |
in general though, it's probably OK to keep thread-local caches of values like that and just poll for updates from shared storage only periodically, rather than on each use. |
| 15:56 |
hmmmm |
we are, but about what to do with strings to prevent memory leaks |
| 15:57 |
Warr1024 |
oof, cross-thread reference counting? |
| 15:57 |
hmmmm |
basically yeah |
| 15:57 |
Warr1024 |
how much would it cost to just duplicate the strings and have each copy owned by only 1 thread :-) |
| 15:57 |
hmmmm |
can't do it unless we have a 12 byte CAS |
| 15:57 |
hmmmm |
because the string duplicating would require a lock |
| 15:57 |
Warr1024 |
some applications are very string-heavy, but I imagine minetest is somewhat less... |
| 15:58 |
Warr1024 |
yeah, this sounds a lot like the problems with systrace. |
| 15:58 |
Warr1024 |
if you use a message-passing architecture, you're fine, but systrace is succeptible to modification of string values after validation. |
| 15:58 |
nore |
hmmmm, why 12 bytes? |
| 15:59 |
hmmmm |
nore, 8 for the pointer and 4 for the ref count |
| 15:59 |
Warr1024 |
so ideally you'd have one thread package up a copy of the string for use by the other thread, then just pass that pointer, and never access the referenced object from that thread again, i.e. you atomically pass ownership of the data to the other thread. |
| 15:59 |
nore |
4 bytes for the ref count? isn't 1 enough? |
| 16:00 |
Warr1024 |
accessing 1 byte tends to involve accessing 4 in many cases anyway, the way some procs work. |
| 16:00 |
nore |
and isn't there something to prevent a thread from being interrupted (like a lock, but global?) |
| 16:01 |
sapier |
no |
| 16:01 |
Warr1024 |
you mean like critical sections? |
| 16:01 |
sapier |
and doesn't help at all |
| 16:01 |
Warr1024 |
if an OS were to actually honor something like that, it'd be a good way to freeze an entire system... |
| 16:02 |
Warr1024 |
and I don't think they work on multiproc |
| 16:02 |
nore |
... |
| 16:02 |
sapier |
nothing prevents the data to be updated by another thread while a thread is running (can both run same time on multicore) |
| 16:03 |
nore |
hmmmm, what's the size of usual atomic swaps? |
| 16:03 |
thexyz |
didn't read, what do you want to achieve and why rwlock won't solve this? |
| 16:03 |
sapier |
there isn't atomic swap support in c/c++ ;-) |
| 16:05 |
sapier |
thexyz hmmm wants to find a way to avoid locks in settings |
| 16:05 |
sapier |
other way round |
| 16:05 |
thexyz |
well, just use rwlock since there aren't much writes anyway |
| 16:05 |
thexyz |
and if there are then it's not the most slow place in any case |
| 16:06 |
thexyz |
anyway, I wanted to ask: how much performance increase will a texture atlas give? |
| 16:06 |
sapier |
celeron postet som testcode but I don't know of any results |
| 16:06 |
thexyz |
ah, should look for it |
| 16:06 |
sapier |
about 3 days ago |
| 16:08 |
iqualfragile |
how can i /giveme or add_item and set a damage value? |
| 16:08 |
nore |
iqualfragile, I'm not sure you can with the chat command... |
| 16:09 |
sapier |
/give singleplayer <itemname> <count> |
| 16:10 |
sapier |
I don't know about damage from chat |
| 16:11 |
nore |
sapier, perhaps what could be done is: "if stack_max == 1 then damage = count" |
| 16:11 |
nore |
what would you think of that? |
| 16:12 |
iqualfragile |
i would be fine with the add_item equivalent, too |
| 16:13 |
sapier |
if you do a mod you can add a command to change health |
| 16:13 |
iqualfragile |
would it just be "default:pick_wood 1 50" for add_item? |
| 16:13 |
nore |
sapier, I mean, in builtin |
| 16:13 |
sapier |
yes |
| 16:13 |
nore |
iqualfragile, perhaps even "default:pick_wood 50" |
| 16:14 |
nore |
(cause if stack_max = 1, the second parameter would be interpreted as wear...) |
| 16:14 |
sapier |
/give singleplayer default:dirt 999 will give singleplayer 999 dirt nodes |
| 16:15 |
hmmmm |
Warr1024, that wouldn't help because you'd need to lock the string in order to copy the string contents |
| 16:15 |
hmmmm |
nore, the size of the system word |
| 16:15 |
Warr1024 |
you wouldn't need to lock the string if it were owned by the thread doing the copying. |
| 16:15 |
hmmmm |
the problem is that you need to increment the refcount from the consumer and swap the value in the producer at the same time |
| 16:16 |
hmmmm |
oh |
| 16:16 |
iqualfragile |
how much wear does a wood pickaxe have? |
| 16:16 |
hmmmm |
if you have only one thread to carry out string updates |
| 16:16 |
nore |
iqualfragile, they all have 65535 |
| 16:16 |
nore |
(all tools) |
| 16:16 |
iqualfragile |
ah, ok |
| 16:16 |
hmmmm |
I have no idea what the performance ramificationcs of that are, but I can imagine it'd potentially make things more difficult |
| 16:16 |
Warr1024 |
if each string is only accessible by one thread then you don't ever have to do locking, you don't have to count refs (they're always 1), and transfer of thread ownership can be done atomically. |
| 16:16 |
iqualfragile |
wonderfull |
| 16:17 |
Warr1024 |
the major drawback is string copying, and duplication of data. How much of a problem those are depend on how many string or array values you actually need to pass between threads... |
| 16:18 |
iqualfragile |
would it be possible to let joining players see the chat while they are loading? |
| 16:19 |
Warr1024 |
is there an event in lua that's raised whenever a mapblock is loaded? |
| 16:19 |
sapier |
Warr1024: no |
| 16:19 |
Warr1024 |
is there a reason there shouldn't be? |
| 16:20 |
sapier |
performance |
| 16:20 |
nore |
lazyness? |
| 16:20 |
PilzAdam |
Warr1024, imagine the normal loading of mapblocks being as slow as generation |
| 16:20 |
Warr1024 |
I guess as a hack you could always place one entity within each mapblock as it's generated to serve that function, though entities are probably more expensive than that hook would be... |
| 16:20 |
iqualfragile |
annoyance: when using /teleport player1 player2 autocompletition adds a space behind player2 |
| 16:20 |
nore |
(I almost went doing it once, and gave up right before coding it...) |
| 16:20 |
sapier |
no mapblock loading is done quite often calling back to lua will add another bottleneck |
| 16:20 |
iqualfragile |
but it looks like /teleport could not handle that too well |
| 16:20 |
Warr1024 |
I'm pretty sure that generation does a lot more work than just calling a hook. |
| 16:20 |
PilzAdam |
iqualfragile, indeed |
| 16:21 |
PilzAdam |
Warr1024, generation is faster than loading a block, the slow thing is the Lua callback |
| 16:21 |
sfan5 |
hmmmm: the tab_playerlist branch that is 'linked' to the pull works |
| 16:21 |
sapier |
especialy if moders actually do things in that callback ;-) |
| 16:22 |
Warr1024 |
oh really? I was under the impression that gen was slow and loading fast, based on the CPU cost of exploring new vs. old terrain. |
| 16:22 |
sapier |
btw that callback is only usefull for static things as entities get loaded way beyond block loading |
| 16:23 |
Warr1024 |
well the issue for me is that since I can't change the liquid update physics via settings, I may end up having to replace them entirely in lua. |
| 16:23 |
Warr1024 |
I can't use abm's for this either, as abm's are also on the non-modifyable timescale. |
| 16:24 |
iqualfragile |
directional clouds are faptastic, but (at least on my system) there is a litle bit of flickering |
| 16:24 |
Warr1024 |
I'm really trying to stick to doing this entirely in a game context, i.e. no C++ mods. |
| 16:25 |
hmmmm |
hey sapier wait a minute https://github.com/minetest/minetest/commit/848f80b2e53155c76f598c2f7e0ebaff1faea8dc |
| 16:25 |
|
Calinou joined #minetest-dev |
| 16:25 |
hmmmm |
I thought we agreed to not merge that until it stops looking like ass below the horizon |
| 16:26 |
nore |
hmmmm, it can be disabled... |
| 16:26 |
hmmmm |
oh there's a setting |
| 16:28 |
celeron55 |
thexyz: if you're interested in rendering performance, one thing which makes minetest feel really bad on some hardawre is the choppines that loading new mapblock meshes causes on some GPUs |
| 16:28 |
celeron55 |
at least on my desktop sandy bridge it's awful |
| 16:28 |
Warr1024 |
I can attest to that. |
| 16:28 |
Warr1024 |
atom n450, I believe. |
| 16:28 |
thexyz |
on android it feels awful too |
| 16:28 |
hmmmm |
I was thinking maybe we should add VBO, disabled by default, with the caveat of high memory usage |
| 16:28 |
celeron55 |
one thing we can do is limiting the amount of mapblocks loaded per each frame |
| 16:28 |
Warr1024 |
how high are you talking? |
| 16:28 |
celeron55 |
it's feasible to limit them to even only one per frame |
| 16:29 |
|
Miner_48er joined #minetest-dev |
| 16:29 |
celeron55 |
it currently can load sometimes like 15 per frame, then nothing the next few frames and then 10 and so on |
| 16:29 |
celeron55 |
just look at the f5 graph |
| 16:30 |
|
rubenwardy_ joined #minetest-dev |
| 16:31 |
celeron55 |
an another way to fix that would be to make the server not send excess mapblocks; currently it doesn't care of the client's view range and usually sends much more than the client is actually able to draw |
| 16:31 |
celeron55 |
or, well, a partial fix |
| 16:31 |
celeron55 |
we're not alone with that issue though |
| 16:31 |
celeron55 |
minecraft behaves just as horribly on that hardware |
| 16:32 |
celeron55 |
it's even worse |
| 16:33 |
celeron55 |
however, the limit for mapblocks per frame needs to be dynamic because for example on my intel GMA 950 laptop loading 0 or 20 mapblocks makes no difference whatsoever |
| 16:33 |
celeron55 |
it's some "clever" buffering thing in those new low-end GPUs that doesn't work well for dynamic loading |
| 16:35 |
Warr1024 |
minecraft doesn't behave badly on some of my hardware on which minetest behaves badly. |
| 16:35 |
Warr1024 |
minecraft doesn't actually behave at all: it simply won't run. |
| 16:35 |
Warr1024 |
:-) |
| 16:36 |
Warr1024 |
it would be nice to enqueue meshes that need to be updated, and dequeue them at a limited rate. |
| 16:36 |
Warr1024 |
the limit could be simple like 1 block per frame, or more adaptive, i.e. minimum of 1, but increasing if the queue size starts to increase. |
| 16:36 |
Warr1024 |
in either case, it would probably be an improvement in general. |
| 16:36 |
celeron55 |
i have tried that actually but didn't merge it forgot it then |
| 16:37 |
celeron55 |
+and |
| 16:37 |
Warr1024 |
if you can dig up a patch you want me to try on a really slow atom machine, I'm up for it. |
| 16:37 |
Warr1024 |
though it may take me like 20 minutes to compile. |
| 16:38 |
celeron55 |
is the problem the choppiness? |
| 16:38 |
Warr1024 |
yes, chop is a major issue. |
| 16:38 |
celeron55 |
can you check that it indeed is the mesh loading (from the f5 graphs) |
| 16:39 |
Warr1024 |
I see sharp mesh spikes once every couple of seconds. |
| 16:39 |
|
Akien joined #minetest-dev |
| 16:39 |
Warr1024 |
It's not easy to reproduce the ideal worst case, but a lot of liquid transforms can do it... |
| 16:39 |
celeron55 |
and those directly and linearly spike the frame time? |
| 16:39 |
Warr1024 |
yeah, it's like half a second or more of freeze. |
| 16:40 |
Warr1024 |
I get like 5fps average, with 10 or more fps during the parts where meshes AREN'T being update. |
| 16:40 |
Warr1024 |
s/(.)$/d$1/ |
| 16:43 |
|
Jordach joined #minetest-dev |
| 16:43 |
|
Gethiox joined #minetest-dev |
| 16:43 |
PilzAdam |
celeron55, I can reproduce that with my win builds in wine |
| 16:44 |
PilzAdam |
digging becomes a pain with this |
| 16:45 |
|
rubenwardy joined #minetest-dev |
| 16:46 |
celeron55 |
hmm, actually it really only does that on windows on my desktop thing |
| 16:46 |
celeron55 |
it's silky smooth on linux :P |
| 16:54 |
Calinou |
both Minetest and freeminer are very smooth here (linux too) |
| 16:55 |
Calinou |
I have VBOs on on freeminer, it helps |
| 16:57 |
Warr1024 |
I've got major mesh-lag issues with my atom machine on OpenBSD. They're much less pronounced on my Debian box (with a much better CPU and GPU) but it's still noticeable; smooth but not silkily so. |
| 16:57 |
Calinou |
that's atom, probably nothing to do |
| 16:58 |
Warr1024 |
both are intel IGP. |
| 16:59 |
Warr1024 |
I don't see why nothing could be done on the atom. |
| 16:59 |
Warr1024 |
the mesh update limiting would probably smooth both of them out considerably. |
| 17:04 |
Calinou |
atom stuff is very weak |
| 17:04 |
Warr1024 |
yes, which makes it a good stress-test for MT performance. |
| 17:05 |
Warr1024 |
if you can get shit to run smoothly on an atom, you're very likely to be set everywhere else. |
| 17:08 |
Calinou |
however, we are going to limit the game if we keep trying to make it runnable on an atom |
| 17:08 |
Warr1024 |
I don't really see how celeron's proposed fix is limiting though. |
| 17:09 |
|
rubenwardy left #minetest-dev |
| 17:09 |
Calinou |
not in this case, but in general |
| 17:10 |
Warr1024 |
yeah, but in general, this case is the only performance issue that currently exists for atom. |
| 17:11 |
Warr1024 |
as I mentioned, it also affects other systems as well, so it's more-or-less a win across the board. |
| 17:12 |
Warr1024 |
if 1 mesh per frame isn't enough, we can make it adaptive, or if that's too complex, make it tunable by setting and set the default high enough to keep close to the best working behavior for whatever your ideal "target" platform is... |
| 17:13 |
zat |
For whoever that might care: I have never been able to compile Minetest without commenting out all the typedefs in src/irrlichttypes.h. |
| 17:14 |
Warr1024 |
bbl |
| 17:15 |
thexyz |
zat: what's your os? |
| 17:15 |
thexyz |
zat: what's your irrlicht version |
| 17:16 |
celeron55 |
sounds like some distros still distribute the weird pre-release versions of irrlicht 0.8 |
| 17:16 |
celeron55 |
ehm |
| 17:16 |
celeron55 |
1.8* |
| 17:17 |
celeron55 |
or alternatively have some non-standard patches in there |
| 17:17 |
thexyz |
yes, this |
| 17:17 |
celeron55 |
minetest has a bunch of #ifdefs handling the difference between released irrlicht 1.7.* and 1.8.*, we're not going to handle anything else |
| 17:19 |
|
Warr1024 left #minetest-dev |
| 17:19 |
|
rubenwardy joined #minetest-dev |
| 17:20 |
zat |
thexyz: irrlicht-1.7.3-1.el6.i686 and CenOS 6.2 with Linux 2.6.32-279.el6.i686 |
| 17:21 |
thexyz |
oh well centos strikes again |
| 17:21 |
zat |
lol really |
| 17:21 |
zat |
I said CenOS though... |
| 17:22 |
celeron55 |
you could diff the headers in that with the official irrlicht 1.7.3 zip |
| 17:22 |
zat |
good idea |
| 17:24 |
thexyz |
I've just tested with official 1.7.3 irrlicht release and it compiles and works fine |
| 17:24 |
celeron55 |
i wonder who even packages that .rpm |
| 17:24 |
celeron55 |
it seems to be impossible to find out |
| 17:26 |
celeron55 |
redhat/fedora i guess |
| 17:31 |
zat |
I cant find either |
| 17:43 |
zat |
celeron55: three files differ. irrTypes.h is one. |
| 17:48 |
thexyz |
that's the problem |
| 17:49 |
thexyz |
submit a bug report to your distro bugtracker |
| 17:57 |
zat |
Well, it is not my distro |
| 17:58 |
zat |
I will just ask in their IRC channel. |
| 17:59 |
zat |
john_minetest in many you can know that |
| 18:06 |
zat |
Can I ask here about performance issues with server? |
| 18:07 |
zat |
It is always at over 90% CPU |
| 18:07 |
zat |
And no mods enabled. |
| 18:07 |
PilzAdam |
john_minetest, he is right regarding #799, though |
| 18:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/799 |
| 18:11 |
|
rambomedic joined #minetest-dev |
| 18:12 |
|
Miner_48er joined #minetest-dev |
| 18:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/1036 |
| 18:15 |
PilzAdam |
https://github.com/PilzAdam/minetest/commit/a2748dcd1dd4ff09fae8ae25a0cee1e1cd1e89d3 |
| 18:15 |
PilzAdam |
I guess thats something kahrl forgot |
| 18:19 |
rambomedic |
What's the purpose of the freeminer fork? As far as I see they're just using commits from minetest, and merging pull requests from minetest earlier than minetest...? |
| 18:21 |
rambomedic |
Although, I do like the name. Are you guys planning to stick with the "minetest" name? |
| 18:24 |
celeron55 |
rambomedic: it seemed that they want to focus on making one good game, while minetest focuses on overally expanding the possibilities of subgames |
| 18:29 |
thexyz |
the point of freeminer is to deliver |
| 18:29 |
|
EvergreenTree joined #minetest-dev |
| 18:34 |
Taoki |
Hello. I figured out how to loop a sound at a node's position properly. However, is there a way to make a looped sound stop when you break that node? Without intensive checks |
| 18:34 |
Taoki |
Asked on #minetest and someone said I should ask here too |
| 18:46 |
kahrl |
PilzAdam: I think that happened with the merge/rebase |
| 18:46 |
kahrl |
the curl.h include can be removed as well |
| 18:51 |
|
Akien joined #minetest-dev |
| 19:28 |
iqualfragile |
hmmmm: rumor has it that you created some v7-biomes for minetest_game? |
| 19:30 |
|
Gethiox2 joined #minetest-dev |
| 19:32 |
VanessaE |
ok, so...the un-logged crashes are going to continue for...how much longer? |
| 19:32 |
VanessaE |
how the fuck am I supposed to manage a production server from debug/crash logs if I have no G*d damn crash logs? |
| 19:33 |
sapier |
VanessaE doe the crashs occur on debug build too? |
| 19:33 |
sapier |
-e |
| 19:34 |
VanessaE |
it throws a SIGABRT when a mod error occurs |
| 19:34 |
VanessaE |
causing the actual log write to fail |
| 19:34 |
VanessaE |
so only the console output happens, which of course is never seen in a production environmnnt |
| 19:34 |
VanessaE |
environment* |
| 19:35 |
VanessaE |
http://pastebin.ubuntu.com/6579865/ |
| 19:35 |
sapier |
ok so we need to find a way to make luajit and error reporting work ... or you switch to lua to find that error |
| 19:35 |
VanessaE |
here's an example |
| 19:35 |
VanessaE |
it used to work fine before |
| 19:35 |
VanessaE |
this is very recent. |
| 19:35 |
VanessaE |
like, within the last week or so. |
| 19:35 |
VanessaE |
(or two) |
| 19:35 |
|
Calinou joined #minetest-dev |
| 19:35 |
sapier |
most likely ShadowNinja's cleanups but I can't proove that one |
| 19:38 |
PilzAdam |
VanessaE, revert to a stable version for production maybe? |
| 19:40 |
Sokomine |
celeron55: based on how "fast" <irony off> mapblocks are sent by server according to my experience, limiting that speed even further would be a bad idea. it felt like eternity until i had a sizable portion of redcrabs map downloaded when i used sfan5's modified client. it felt as if the mapblocks arrived per pigeon carrier (ok, redcrab's an older server; it usually feels faster on vanessas servers). getting ~150mb of mapdata too |
| 19:41 |
sfan5 |
Sokomine: your sentence is cut off |
| 19:41 |
Sokomine |
where is it cut off? at which word? |
| 19:41 |
sfan5 |
'getting ~150mb of mapdata took' |
| 19:41 |
VanessaE |
PilzAdam: um. no. logged crash reporting is a critical function of an engine that's explicitly geared toward modding. This should have been fixed immediatey. |
| 19:42 |
Sokomine |
ah. then only the "*weeks*" is missing. and i was online that time a lot |
| 19:42 |
Exio4 |
PilzAdam: are you *not* using preload item visuals? |
| 19:42 |
PilzAdam |
VanessaE, not immediately, just until the next release |
| 19:42 |
PilzAdam |
Exio4, yes, I have preload item visuals off |
| 19:43 |
Sokomine |
regarding those lua crashes: what about those uninformative error messages (assertion: 0)? sapier told me a quick fix for that some time ago, but i don't know if it got included? |
| 19:43 |
Sokomine |
it helped at least in those cases where the mod did provide an error message |
| 19:43 |
sapier |
switch to lua ;) |
| 19:44 |
Exio4 |
maybe the shader bug could be because there is a "disable_shader" before generating the inventory image |
| 19:44 |
sapier |
but that's not an option for VanessaE |
| 19:45 |
Exio4 |
(and enable back after tjhat) |
| 19:45 |
VanessaE |
I could back off a bit on the version or use Lua perhaps, but that ain't the point - this has been ongoing for at least a week now. |
| 19:45 |
PilzAdam |
Exio4, yea, I noticed that inventory images look different than the normal nodes |
| 19:45 |
VanessaE |
is that not enough time for someone to say "oh crap, this needs fixed"? |
| 19:45 |
Sokomine |
(back to mapblock loading and fps:) it seems to me that fps suddenly shoot up again once other mapblocks are visually hidden between others. that is: if the underground does not have to be drawn (because the mapblock with the surface finally managed to arrive), that's usually excellent for my fps (graphics capabilities are very poor - ivy bridge celeron with integrated graphics) |
| 19:48 |
Sokomine |
perhaps as far as rendering is concerned, assuming grey blocks in the areas that have not been drawn (at least on the surface!) might help? |
| 19:49 |
sapier |
VanessaE there are plenty of options to debug this error but they all involve building a non production version. How are we supposed to find that error if you don't give us anything to work with ? |
| 19:50 |
VanessaE |
the easiest option for now is running the server in gdb and letting it crash when an mod errors out |
| 19:50 |
sapier |
If you strip away all debug infos you can't expect to have em on error |
| 19:50 |
VanessaE |
the downside is the server stays down until I intervene and fix the bug |
| 19:50 |
sapier |
I assume this is still the error you posted dmesg output? |
| 19:51 |
VanessaE |
in a normal environment I can just watch for errors in my backlog or check debug periodically, or when a user reports a problem |
| 19:51 |
sapier |
in this case you can build with debug information you don't even need to run within debugger, you just have to provide the binary |
| 19:51 |
VanessaE |
s/an mod/a mod/ |
| 19:51 |
Exio4 |
make minetest coredumps |
| 19:51 |
VanessaE |
no you miss the point |
| 19:51 |
VanessaE |
I don't need core dumps or even a debug build |
| 19:51 |
Exio4 |
coredump*, and then check those |
| 19:51 |
VanessaE |
I just need to run it from a console |
| 19:51 |
thexyz |
VanessaE: may the cores help you |
| 19:51 |
VanessaE |
as long as I can see the console output from the server, I can see the error |
| 19:51 |
VanessaE |
that's the problem |
| 19:52 |
VanessaE |
the error text IS THERE |
| 19:52 |
thexyz |
and what's the problem then? |
| 19:52 |
Exio4 |
run minetest like always but debug build and coredumps enabled |
| 19:52 |
VanessaE |
it's just not being logged because the server is throwing SIGABRT before the error gets written to the log |
| 19:52 |
VanessaE |
so I can't find it in the logs |
| 19:52 |
thexyz |
well but as you say the error text is there? |
| 19:52 |
thexyz |
run it inside screen then |
| 19:52 |
VanessaE |
CHRIST |
| 19:52 |
VanessaE |
READ |
| 19:52 |
VanessaE |
sorry, I'm tired |
| 19:52 |
VanessaE |
three times I've said it already |
| 19:52 |
thexyz |
well run it in screen then? |
| 19:53 |
sapier |
ok VanessaE we need to know where that sigabort is from |
| 19:53 |
thexyz |
why won't that work? |
| 19:53 |
sapier |
it's obviously a follow up error |
| 19:53 |
VanessaE |
http://pastebin.ubuntu.com/6579865/ |
| 19:53 |
VanessaE |
there, sapier |
| 19:53 |
sapier |
NO |
| 19:53 |
VanessaE |
I'll give you a full backtrace if you want it |
| 19:53 |
sapier |
the sigabort is something independent |
| 19:53 |
sapier |
it's not originated from the lua error but caused by it |
| 19:53 |
sapier |
it's a second error caused by first one |
| 19:54 |
thexyz |
meh so you use buggy mods and expect minetest to do some magic and not crash or what? |
| 19:54 |
sapier |
if we can fix the second one you'll have your log back |
| 19:54 |
VanessaE |
*facepalm* |
| 19:54 |
VanessaE |
ok so what do you need from me? |
| 19:54 |
sapier |
thexyz I don't think lua causes a sigabort |
| 19:54 |
thexyz |
the log is here, what's the problem? i honestly don't understand, if you want you can redirect it to a file |
| 19:54 |
VanessaE |
I've got a crashed debug build open in gdb right now/. |
| 19:54 |
sapier |
that's caused by something we do after crash |
| 19:54 |
VanessaE |
it crashed due to a simple nil function cal |
| 19:54 |
thexyz |
minetestserver > log 2>&1 |
| 19:54 |
VanessaE |
call* |
| 19:54 |
sapier |
-crash + lua error |
| 19:55 |
Taoki |
Hmm... I need some advice or confirmation from the developers on something. |
| 19:55 |
sapier |
maybe we don't catch some exception or catch it to late |
| 19:55 |
VanessaE |
a routine, simple mod error that happens a dozen times a day during a coding session. NEVER should a MOD LUA ERROR cause a server to SIGABORT |
| 19:55 |
thexyz |
what should it do then? |
| 19:55 |
sapier |
show a lua error in a dialog box to press ok ;-) |
| 19:56 |
kahrl |
what is in main.cpp:1859? |
| 19:56 |
thexyz |
ah sure always forget about this |
| 19:56 |
VanessaE |
thexyz: um...maybe throw an error INTO THE LOG and exit cleanly with SIGQUIT or so? |
| 19:56 |
kahrl |
for me it's an empty line |
| 19:56 |
VanessaE |
or SIGTERM or whatever it is the server usually exits with |
| 19:56 |
Taoki |
I'm trying to add looped sounds for flowing liquid sources to minetest_game. However, I can't find any proper way to start looping a sound when appropriate, while (especially) being able to stop looping that sound when no longer needed. Would it be acceptable if I used minetest.sound_play every 5 - 10 seconds? Or would that create too much lag? |
| 19:56 |
thexyz |
kahrl: END_DEBUG_EXCEPTION_HANDLER(errorstream) |
| 19:56 |
thexyz |
for me |
| 19:56 |
sapier |
and as server doesn't have a dialog write it to log and quit |
| 19:56 |
thexyz |
well just make a big try catch around server loop then? |
| 19:56 |
Taoki |
celeron55, PilzAdam, sapier, etc.? |
| 19:57 |
Taoki |
Or If I want to do this do I really need to use loop=true |
| 19:57 |
PilzAdam |
Taoki, I think its something for the client side API |
| 19:57 |
Taoki |
Which would be best, but I have no idea how to go about it in this circumstance x.x |
| 19:57 |
kahrl |
thexyz: weird, that line is in main.cpp:1860 for me |
| 19:57 |
VanessaE |
anyway, I've got this session sitting here crashed, and I need to restart it. I've got a server to run. is there anything you need from it before I do? |
| 19:57 |
Taoki |
PilzAdam: What is? |
| 19:57 |
thexyz |
kahrl: maybe my repo clone is out of date |
| 19:57 |
PilzAdam |
Taoki, playing water sounds |
| 19:57 |
Taoki |
Ah |
| 19:58 |
Exio4 |
same here kahrl |
| 19:58 |
Taoki |
Maybe. A client API is years from now though. And sounds like this could be server-side if done properly |
| 19:58 |
Exio4 |
>sounds >server-side |
| 19:58 |
thexyz |
just add a "catch (LuaError &e)" ? |
| 19:58 |
thexyz |
I think that's what FM does |
| 19:58 |
Taoki |
PilzAdam: This is the exact problem: I can easily start the loop by registering an ABM to water_source that has a water_flowing neighbor. Problem is, how to stop looping that sound when flowing water around that source is removed, or the source itself goes away |
| 19:59 |
PilzAdam |
Taoki, of course; the server will send the Lua functions that the client should run |
| 19:59 |
kahrl |
END_DEBUG_EXCEPTION_HANDLER is supposed to flush the logstream |
| 19:59 |
PilzAdam |
also, you cant loop sounds that run on nodes/positions |
| 19:59 |
kahrl |
that's what the <<std::endl; is for |
| 20:00 |
Taoki |
I'm thinking of looing through the table containing all flowing sounds each 1 second, but that could be pretty intensive, and therefore not ok for default |
| 20:00 |
Taoki |
PilzAdam: You can loop a sound at a fixed position. But it's not related to the onde there |
| 20:00 |
Taoki |
**node |
| 20:00 |
PilzAdam |
no, you cant |
| 20:00 |
Taoki |
Strange, works fine here. Fire does it also |
| 20:00 |
PilzAdam |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L233 |
| 20:00 |
Taoki |
You just need to add "loop=true" to the sound |
| 20:01 |
Taoki |
PilzAdam: Why does it work for me on nodes then? It's a strange thing in this case :P |
| 20:01 |
Taoki |
Because if I add loop=true on a sound triggered by a node ABM, it works well |
| 20:02 |
PilzAdam |
the docs are wrong then |
| 20:02 |
Taoki |
Seems so. Or maybe downdated, from before this was possible |
| 20:03 |
Taoki |
PilzAdam: Anyway. Assuming that I have a water sound that is 5 seconds long. With no way to control when to start and stop the loop properly, I can register an ABM to the water source that runs every 5 seconds, whenever it finds the appropriate neighbors. Is this an acceptable idea? |
| 20:03 |
Taoki |
Asking because triggering play_sound every 5 seconds uses a little bandwidth |
| 20:03 |
Taoki |
I assume not much, but some might still not like it |
| 20:03 |
Taoki |
Seems like the only way. But until a better system's in place, it could work |
| 20:04 |
Taoki |
Sound is 10 seconds long, register_abm runs every 10 seconds as long as it finds flowing water nearby. |
| 20:04 |
Taoki |
Certainly it's a small packet... |
| 20:06 |
sapier |
be carefull with abms taoki if chance and frequency is to high that's quite dangerous |
| 20:06 |
Taoki |
sapier: I'm using a well filtered and tuned ABM, shouldn't be a problem |
| 20:06 |
Taoki |
With this idea, it runs every <sound file length> seconds, and also has a neighbor check so it's uses only when needed |
| 20:08 |
Taoki |
Problem is there's not enough control in the current Lua API to properly start or stop looping a sound when water starts / stops flowing. So I have to trigger sound_play the same number of seconds as the file length manually, so the check can re-run then. |
| 20:08 |
PilzAdam |
Taoki, isnt that a modding issue? |
| 20:08 |
Taoki |
5 seconds per 2-3 nodes at most isn't intensive, but sends a tiny packet in each case. Server lag can also cause breaks in the sound |
| 20:09 |
Taoki |
PilzAdam: True. I'm asking here cuz it's for an official patch I'm trying to make |
| 20:09 |
PilzAdam |
whats an "official patch"? |
| 20:09 |
Taoki |
Mostly wanted to know if my approach would be accepted for minetest_game |
| 20:09 |
Taoki |
Something intended to be added to master I mean :P |
| 20:09 |
PilzAdam |
use Minetest_plus if you want water sounds |
| 20:09 |
Taoki |
Might try it later. Want to improve existing minetest currently though |
| 20:10 |
Taoki |
Erm, minetest_game in its original state |
| 20:11 |
Taoki |
Anyway, I think I'll add the sounds this way to my branch. They can be discussed when I pull request the whole thing (I'm adding sound effects for various things, flowing water is just one) |
| 20:17 |
Taoki |
This is my current code and approach, if it helps give a better verdict: http://pastebin.com/raw.php?i=sZdKimKH "interval = 5" because the sounds are exactly 5 seconds. |
| 20:21 |
Taoki |
*sigh* That doesn't work well at all actually. 5 seconds is too long, and in case of server lag the gap will be much more visible. |
| 20:21 |
Taoki |
Frustratingly, I can use looping already and it works great. I just can't detect when and how to stop the sound from looping, if the water source is ever removed. |
| 20:24 |
proller |
celeron55, transfer vrange to server: https://github.com/proller/freeminer/commit/f86ef3a14ffdcc432029a153f14854fd9298c4d0 |
| 20:28 |
Taoki |
Alright, I might have found a way using on_placenode and on_dignode actually :) |
| 20:28 |
Taoki |
To use the loop after all |
| 20:33 |
Taoki |
Found the perfect solution, works using loop :) Code will be available in my branch |
| 20:59 |
VanessaE |
Server: xxxxxx: Failed to emerge player (player allocated to an another client) |
| 20:59 |
VanessaE |
-an |
| 21:00 |
sapier |
yes? |
| 21:00 |
VanessaE |
drop the 'an' from this log message. |
| 21:00 |
sapier |
ohhh :-) |
| 21:01 |
VanessaE |
server.cpp line 2080 |
| 21:03 |
thexyz |
VanessaE: well, this seems to be an ordinary "another player already connected" message |
| 21:06 |
|
sapier1 joined #minetest-dev |
| 21:07 |
VanessaE |
thexyz: you missed the point. grammar error in the message |
| 21:07 |
VanessaE |
it is not "an another". it should simply be "another". |
| 21:07 |
thexyz |
eh who cares |
| 21:08 |
thexyz |
well you could create a pull request and then we'll have to wait for at least two core devs to agree to it |
| 21:08 |
proller |
and 2 months |
| 21:08 |
sapier1 |
<< agrees for removing an |
| 21:09 |
VanessaE |
2 core devs to agree to removing one word from an error message to fix someone's poor grammar? O.o |
| 21:09 |
sapier |
<< ok now with approved nick agree to remove an |
| 21:09 |
VanessaE |
faith in humanity: [-] 0.1 |
| 21:09 |
thexyz |
i can't into jokes |
| 21:09 |
thexyz |
of course it's fine, just commit it |
| 21:10 |
PilzAdam |
VanessaE, c55 always says "an another" |
| 21:10 |
VanessaE |
then his grammar sucks :) |
| 21:10 |
thexyz |
then it fucking should be "an another" |
| 21:16 |
lanxu_ |
modifying the commit messages is dirty business. Just be happy that is is not like "Fixed something somewhere" |
| 21:17 |
|
kaeza joined #minetest-dev |
| 21:17 |
thexyz |
commit message? |
| 21:17 |
thexyz |
what are you talking about? |
| 21:17 |
lanxu_ |
whoops |
| 21:18 |
lanxu_ |
I misread. Please continue. :) |
| 21:20 |
|
Warr1024 joined #minetest-dev |
| 21:25 |
sapier |
https://github.com/minetest/minetest/pull/774 any comments to this one? it'll improve animation for moving entitys quite a lot |
| 21:28 |
VanessaE |
sapier: then it has no chance in hell :P |
| 21:32 |
sapier |
it adds a new property to animation called basevelocity |
| 21:33 |
sapier |
this is the velocity matching movement at 15 animationframes per second |
| 21:34 |
sapier |
eg if a entity is walking at this velocity feet will touch ground at correct time |
| 21:34 |
sapier |
after this pull request client will adjust speed of animation automaticaly if a entity is moving slower or faster than this basevelocity |
| 21:50 |
Warr1024 |
oh, that's pretty neat |
| 21:56 |
|
OldCoder joined #minetest-dev |
| 22:05 |
OldCoder |
Hi |
| 22:15 |
VanessaE |
hey OldCoder |
| 22:17 |
ShadowNinja |
Can someone check this and approve it? I've added zero/one-based index conversion. https://gist.github.com/ShadowNinja/7953481 |
| 22:17 |
ShadowNinja |
PilzAdam: ^? |
| 22:18 |
sapier |
I still miss a SINGLE usecase for this one |
| 22:18 |
sapier |
and why isn't this a pull request? |
| 22:19 |
sapier |
gists are supposed to be small non controversial bugfix only things |
| 22:19 |
OldCoder |
VanessaE, Hi! |
| 22:19 |
OldCoder |
VanessaE, may I PM? |
| 22:20 |
VanessaE |
sure |
| 22:22 |
ShadowNinja |
sapier: Because a pull request involves making a branch, commiting it, pushing it, and then requesting it, and closing the pull and deleting the branch when done. This is easier. And I've already explained it to you. |
| 22:23 |
sapier |
you have explained a lot of things true but you didn't answer that one and only question I asked |
| 22:24 |
sapier |
What is json serialization better then already included lua serialization |
| 22:26 |
ShadowNinja |
sapier: I did tell you. Check your logs. |
| 22:26 |
|
john_minetest left #minetest-dev |
| 22:27 |
sapier |
I remeber you told it's cool because it's lua and can transfere data ... beeing cool and json isn't a reason at all and data can be transfered by minetest.serialize too |
| 22:27 |
sapier |
you didn't tell anything else |
| 22:30 |
sapier |
and can you explain why this is usefull to be done in c++? I guess it'd be a lot faster if done in lua |
| 22:33 |
|
zat1 joined #minetest-dev |
| 22:35 |
thexyz |
everything is a lot faster when done in lua! why not rewrite minetest in lua then? |
| 22:35 |
thexyz |
we won't have those fat lua-c++ calls at all |
| 22:36 |
sapier |
it's not everything serialization is just passing data one by one from lua to c++ it's numbercruchning |
| 22:36 |
sapier |
and numbercrunching is exactly what c++ isn't faster then luajit |
| 22:36 |
iqualfragile |
wtf? |
| 22:37 |
sapier |
at least in most cases |
| 22:39 |
proller |
wat? |
| 22:39 |
iqualfragile |
plol |
| 22:40 |
iqualfragile |
sapier: the slow part in passing data from c++ to lua or vice versa is that you need to translate and move stuff |
| 22:40 |
proller |
sapier, now you must show one test where in 100000 iterations jit faster than c++ in 5% ! |
| 22:40 |
iqualfragile |
calls from c++ to lua and vice versa are slow for the same reason |
| 22:40 |
proller |
but in 10000 jit slower in 300% |
| 22:41 |
iqualfragile |
but c++ is allmost allways faster then any jit or interpreted solution |
| 22:42 |
sapier |
proller see pathfinding benchmarks |
| 22:42 |
sapier |
once data is in memory pathfinding isn't any faster in core than in luajit |
| 22:44 |
sapier |
an still all this performance is minor if anyone can tell a single concrete usecase ... "it's json" is as good as "it's xml", "it's odt", "it's docx" |
| 22:44 |
iqualfragile |
you cant compare xml and docx |
| 22:44 |
sapier |
hmm concrete is wrong ... "specific"? |
| 22:44 |
iqualfragile |
(odt is zipped xml) |
| 22:45 |
sapier |
the point is do we really need another serialization format? if there's good reason no question but not because of someones personal preference for json |
| 22:46 |
Taoki |
sapier, PilzAdam: I'm going to submit a fix for the colored for soon, to decrease the effect on clouds. This will address the problem PilzAdam pointed out, with clouds changing color unrealistically (fog and horrizon will stay the same) |
| 22:46 |
PilzAdam |
Taoki, .... why havent you done that already? |
| 22:46 |
Taoki |
Actually, I can easily mention what the value to change is, so I don't have to make a whole branch just for the fix |
| 22:46 |
Taoki |
PilzAdam: There were a lot of opinions on what's right or wrong. It didn't come to my attention as much at the time |
| 22:48 |
Taoki |
Alright |
| 22:48 |
Taoki |
PilzAdam: In the file sky.cpp, look at the very last line containing code, and the very last number in that line. Currently, it's 0.75, which is indeed too high. I found that it looks better if that is changed to something between 0.25 and 0.5. |
| 22:49 |
Taoki |
Can you please play with that value and see what a good change is? Please no lower than 0.25 though, it needs to color them at least a little bit |
| 22:49 |
Taoki |
That line is: m_cloudcolor_f = m_mix_scolorf(m_cloudcolor_f, video::SColorf(pointcolor), m_horizon_blend() * 0.75); |
| 22:49 |
PilzAdam |
not now |
| 22:49 |
Taoki |
ok |
| 22:49 |
Taoki |
sapier: Wanna look into it if you have time? |
| 22:50 |
sapier |
same to me tomorrow ;-) |
| 22:50 |
Taoki |
Maybe something like 0.35 works. |
| 22:50 |
Taoki |
ok |
| 22:50 |
PilzAdam |
I think its wrong to finish a feature after its merged, but whatever |
| 22:50 |
Taoki |
If I find a good default, can you simply commit the change then? |
| 22:50 |
Taoki |
PilzAdam: I know, I'm sorry I didn't look into it better. Like I said there were a lot of opinions on what should be changed, and I didn't get to look at this better |
| 22:51 |
Taoki |
Especially since at first, people complained that cloud color doesn't change and that looks ugly |
| 22:51 |
Taoki |
So initially, it was the other way around :P |
| 22:53 |
Exio4 |
iqualfragile: isn't docx an xml? |
| 22:53 |
iqualfragile |
damnd somebody actually read what i wrote |
| 22:53 |
iqualfragile |
yes it is, kinda, but its properitary |
| 22:54 |
sapier |
I give up ShadowNinja merge it ... I'm gonna merge a xml writer next week, the week after maybe a csv exporter ... I guess I'll find something for the week after |
| 22:55 |
sapier |
XML is usefull for data archiving and transfering to other xml enabled applications ... according to your logics thats enough ... same applies to csv |
| 22:58 |
Taoki |
Ok... best value seems to be 0.25. That only slightly tints the clouds, enough to make sure they match the overall hoirrizon color a bit. Color transition is very subtle on them, and looks as if it's due to the fog, so unrealism goes away |
| 22:59 |
Taoki |
sapier, PilzAdam: Can you simply change that 0.75 to 0.25 and push to master? No need to make a whole branch just to change a number. You can test it as well later... certainly it doesn't worsen anything but highly the contrary |
| 22:59 |
sapier |
can you create a gist taoki? |
| 23:00 |
Taoki |
It's the number at the end of very last line of sky.cpp. Change 0.75 to 0.25 |
| 23:00 |
Taoki |
gist? |
| 23:00 |
Taoki |
Don't think I'm experienced with that, sorry |
| 23:00 |
sapier |
git diff and post it to gist.github.com then place a link here |
| 23:00 |
Taoki |
Ah, a GIT patch? Ok |
| 23:01 |
Taoki |
sapier: https://gist.github.com/MirceaKitsune/7979559 |
| 23:03 |
VanessaE |
Taoki: be sure you try out RBA's texturable run and moon patch, make sure your clouds coordinate well with its default textures/tonemaps |
| 23:03 |
VanessaE |
https://github.com/minetest/minetest/pull/967 |
| 23:04 |
Taoki |
VanessaE: Yes, I plan to talk to him about how to integrate the colored fog with the tint map |
| 23:09 |
Taoki |
sapier: Please commit that change tonight. PilzAdam was right... the cloud colors look VERY bad and unrealistic because they're too strong, but with this they're perfect. Sorry again for not noticing earlier >_< |
| 23:09 |
VanessaE |
and SOMEONE please commit the texturable sun/moon code too :) |
| 23:11 |
Taoki |
VanessaE: If it contains the tint map, it means I need to adapt the fog colors to it soon as well |
| 23:11 |
VanessaE |
it does. |
| 23:13 |
Taoki |
Yeah then... |
| 23:13 |
Taoki |
I hope RBA won't hate me for this. I didn't know his code was already ready as well... |
| 23:15 |
VanessaE |
it's ready except according to celeron55 (who doesn't like how the sun color changes. he wants.. I dunno, some sort of multiplicative bloom effect or some such, I think) |
| 23:15 |
VanessaE |
no wait, he wants different parts of the sun to change at different rates |
| 23:15 |
Exio4 |
what the fuck |
| 23:15 |
|
sapier left #minetest-dev |
| 23:16 |
VanessaE |
Exio4: what? |
| 23:16 |
Exio4 |
i just started minetest, what did i get? 180 fps and then it lagspikes to 1fps and reduces my view-range or whatever it is called to 10 (the min value i have), and then it goes back to max and then repeats |
| 23:16 |
VanessaE |
mesh load/generation |
| 23:17 |
Exio4 |
i'm idling, not doing anything |
| 23:17 |
Exio4 |
also, isn't mesh generation done in other thread? |
| 23:17 |
VanessaE |
Taoki: looks like sapier made the commit you requested. |
| 23:18 |
Taoki |
Ah, good |
| 23:18 |
Exio4 |
i can make a small video if you want |
| 23:19 |
VanessaE |
Exio4: idk, but it kills my fps also when it happens. every new mesh that is created causes a tiny fps sag, enough of them and it becomes visible as stuttering, overall low fps, etc. |
| 23:19 |
VanessaE |
a large mesecons circuit with a blinky plant driving it, for example |
| 23:20 |
VanessaE |
or a pipeworks pipeline that's gotten itself into a self-oscillating situation will do it |
| 23:20 |
Exio4 |
maybe it is because minetest_plus bugs? |
| 23:20 |
VanessaE |
(I discovered the latter only just last night, and it will probably never happen in practice, but I'll fix it some day) |
| 23:21 |
VanessaE |
I run vanilla minetest engine, so no. |
| 23:21 |
Exio4 |
i mean, my bug |
| 23:21 |
* VanessaE |
shrugs |
| 23:21 |
VanessaE |
if it happens to both of us, I'd tend to say no |
| 23:22 |
VanessaE |
why exactly it happens, idk. I am no expert on how minetest and/or irrlicht communicates meshes to the video card. |
| 23:22 |
Exio4 |
it still happens with shaders disabled and preload items enabled |
| 23:23 |
Exio4 |
i think it is the same bug |
| 23:23 |
Exio4 |
num of processed meshes goes up to 15+ and then goes back to 1-2 |
| 23:24 |
VanessaE |
you probably have some mesecons or alike circuit somewhere in your map that fires every so often, causing mapblocks nearby to be re-generated with new content |
| 23:24 |
Exio4 |
also, mt_plus the game :P |
| 23:24 |
VanessaE |
e.g. an "off" node becomes an "on" node, etc. |
| 23:24 |
VanessaE |
each of those events forces a new mesh to be generated. |
| 23:25 |
Exio4 |
it is a new generated wolrd without any mods outside minetest_plus |
| 23:25 |
VanessaE |
what's mt_plus have in it? |
| 23:25 |
Exio4 |
https://github.com/BlockMen/minetest_plus/ |
| 23:26 |
VanessaE |
hm |
| 23:26 |
VanessaE |
well, nothing active in there that I know of, unless you have a bunch of hidden furnaces in there somewhere turning on and off randomly maybe. |
| 23:26 |
VanessaE |
or leaves decaying |
| 23:27 |
VanessaE |
flowers/grasses spreading |
| 23:27 |
VanessaE |
those are about all I can think of that mt_game and mt_plus would do to actively cause a mapblock to change |
| 23:27 |
VanessaE |
(and thuse trigger a mesh regeration) |
| 23:27 |
* Taoki |
hopes I'm not the reason sapier left the channel earlier. Would have to have annoyed any of the devs to this extent... |
| 23:27 |
VanessaE |
of course newly-generated land will do that as it comes in, too |
| 23:28 |
VanessaE |
Taoki: no, this is about when he'd usually sign off |
| 23:28 |
VanessaE |
it's around 12:30am his time I think |
| 23:28 |
Taoki |
Ah, ok. Cuz he didn't quit but left this channel |
| 23:28 |
Taoki |
Or well maybe his IRC qlient quits channels first then disconnects |
| 23:28 |
Exio4 |
it is purple = pidgin |
| 23:29 |
Exio4 |
so yeah, he is still connected tho :P |
| 23:29 |
Exio4 |
inb4 actually finch |
| 23:29 |
* VanessaE |
shrugs |
| 23:36 |
iqualfragile |
sapier uses finch |
| 23:37 |
deltib |
how long do I stare at an unchanging unresponsive BIOS updater before I assume my system is screwed? |
| 23:43 |
deltib |
bad news, the BIOS updater doesn't work, good news it didn't do anything to the flash before it stopped working |
| 23:54 |
|
bebeshko joined #minetest-dev |
| 23:58 |
VanessaE |
deltib: surely you have a modern enough board to use one of those easy-recovery utilities? every board I've bought recently has that feature |
| 23:58 |
|
EvergreenTree joined #minetest-dev |
| 23:58 |
VanessaE |
(where they basically have a backup copy of the bios available, or can flash to it quickly) |
| 23:58 |
deltib |
it's not modern |
| 23:58 |
VanessaE |
ohhh |
