| Time |
Nick |
Message |
| 00:24 |
|
gregorycu joined #minetest-dev |
| 00:24 |
gregorycu |
est, good to see ya |
| 00:25 |
gregorycu |
Let's drive this ring buffer discussion to conclusion, then I can go back to fallout 4 |
| 00:25 |
est31 |
okay |
| 00:26 |
gregorycu |
I think you are talking about the scenario at() THEN push_back() |
| 00:27 |
gregorycu |
Is that correct? So, T& element = at(0); push_back(something); // element now points to something different |
| 00:28 |
est31 |
why should it point to something different? |
| 00:28 |
est31 |
it doesn't |
| 00:29 |
gregorycu |
hmmm.... |
| 00:29 |
est31 |
or well |
| 00:29 |
est31 |
it does |
| 00:29 |
est31 |
but other containers have similar properties |
| 00:30 |
gregorycu |
I agree 100% |
| 00:30 |
gregorycu |
If you do an at(), then modify the thing, you may not have the same element |
| 00:30 |
gregorycu |
We can agree on that |
| 00:30 |
gregorycu |
So, let's look at the push() THEN at() case |
| 00:31 |
gregorycu |
m_offset = 5; push will make m_offset = 6. then when you do at(6) you get the next element that will be push on-top of (aka, the oldest element) |
| 00:32 |
gregorycu |
the push call has basically overwritten at(N-1) |
| 00:33 |
gregorycu |
It's all a bit confusing, maybe that statement didn't helop |
| 00:39 |
gregorycu |
This is eating into my fallout 4 time |
| 00:40 |
est31 |
well whats the problem then? |
| 00:41 |
gregorycu |
ShadowNinja said: It seems that pushing a value causes the indexes for at() to shift over by one, which seems like an odd way to do things. |
| 00:41 |
gregorycu |
You said: Agreed, its different from vector behaviour, where the value from at(0) always points to the first element you have push()-ed. |
| 00:41 |
est31 |
yes ... ? |
| 00:41 |
gregorycu |
And you also said: No, the behaviour here is that at(0) points to the element last pushed. |
| 00:42 |
est31 |
ah |
| 00:43 |
gregorycu |
so, I was just saying that I think the implementation as it stands makes sense, and is consistent with vector and other std containers |
| 00:44 |
est31 |
yes, I'm ok with current implementation |
| 00:44 |
est31 |
and yes my statements contradict |
| 00:44 |
|
cib0 joined #minetest-dev |
| 00:44 |
est31 |
no time to find out which one is the right one :) |
| 00:46 |
gregorycu |
Can you just say you revoke your objections? That way we can ignore them :) |
| 00:46 |
gregorycu |
And I can argue with Shadow instead |
| 00:47 |
gregorycu |
I don't want this dude to be discouraged, he seems pretty good |
| 00:47 |
est31 |
yeah |
| 00:47 |
est31 |
wanted a newbie task, got a bit less of a newbie task :) |
| 00:47 |
gregorycu |
He's up for it |
| 00:47 |
gregorycu |
That's the good thing |
| 00:49 |
est31 |
and my statements do not contradict |
| 00:49 |
est31 |
the behaviour here is that at(0) points to the element last pushed. |
| 00:49 |
est31 |
the behaviour for vector is that at(0) points to the element first pushed. |
| 00:49 |
est31 |
so its different |
| 00:49 |
est31 |
which is not bad by itself |
| 00:50 |
est31 |
I only agreed to the fact that it is different from vector |
| 00:50 |
est31 |
and see, I just +1ed it |
| 00:57 |
gregorycu |
Ahh ok, cool |
| 00:57 |
gregorycu |
Awesome, Fallout 4 time |
| 00:57 |
gregorycu |
Thank you |
| 01:00 |
|
gregorycu_ joined #minetest-dev |
| 01:02 |
|
est31 joined #minetest-dev |
| 01:05 |
|
Supertanker2 joined #minetest-dev |
| 01:09 |
|
kaeza joined #minetest-dev |
| 01:47 |
kaeza |
haven't looked at the commit log, but now the rendering is mmuch faster. almost 50 fps with 150 draw range on my crap intel integrated! |
| 01:48 |
kaeza |
last time it was so |
| 01:48 |
est31 |
in the master branch? |
| 01:48 |
kaeza |
mething like 30 fps |
| 01:48 |
kaeza |
yep |
| 01:49 |
est31 |
idk |
| 01:49 |
est31 |
I cant recall anything graphically changed |
| 01:50 |
est31 |
what was the commit you were on before? |
| 01:50 |
kaeza |
dont know maybe a month or more ago |
| 01:51 |
est31 |
can you paste git reflog |
| 01:51 |
est31 |
on pastebin |
| 01:52 |
kaeza |
it is also less choppy, and map loading/gen looks faster too |
| 01:52 |
kaeza |
cant form here on mobile, but will take note to report later |
| 01:53 |
kaeza |
yes touch keyboards suck</offtopic> |
| 02:02 |
|
Wayward1 joined #minetest-dev |
| 02:07 |
|
cib0 joined #minetest-dev |
| 02:07 |
|
crazyR__ joined #minetest-dev |
| 02:15 |
Wayward1 |
I'm observing what appears to be a phantom player on one of VE's servers: http://imgur.com/nyyk1sD |
| 02:15 |
Wayward1 |
There is no visible player named "unknown" on the server. Any thoughts? |
| 02:18 |
est31 |
do /status again, is it still there? |
| 02:18 |
Wayward1 |
yep |
| 02:55 |
Wayward_One |
It's still there, if anyone's interested |
| 02:56 |
est31 |
well, unless you can reproduce after a restart ... |
| 02:57 |
Wayward_One |
Actual server restart, or relog? |
| 03:03 |
Wayward1 |
Either way, I just relogged and it's still there, but the server won't restart until 10:00 am UTC |
| 03:38 |
|
diemartin joined #minetest-dev |
| 03:40 |
diemartin |
~tell est31 FWIW, https://gist.github.com/kaeza/1f02b45b677065667db3 |
| 03:40 |
ShadowBot |
diemartin: O.K. |
| 04:44 |
|
gregorycu_ joined #minetest-dev |
| 04:46 |
|
Warr1024 joined #minetest-dev |
| 05:14 |
gregorycu |
kaeza must have been talking about my massive changes |
| 05:36 |
|
OldCoder joined #minetest-dev |
| 06:44 |
|
est31 joined #minetest-dev |
| 06:51 |
|
Hunterz joined #minetest-dev |
| 07:09 |
|
paramat joined #minetest-dev |
| 07:10 |
paramat |
i'll merge https://github.com/minetest/minetest/pull/3377 'Mgfractal: Revert unnecessary duplication of parameters' soon |
| 07:11 |
est31 |
one thing about that pr |
| 07:11 |
est31 |
you seem to edit minetest.conf.example manually |
| 07:11 |
paramat |
yes |
| 07:11 |
est31 |
be noted that from time to time it will be updated from settingstypes.txt |
| 07:11 |
paramat |
aha i didn't know |
| 07:12 |
est31 |
so any update you do in minetest.conf.example that doesnt match settingstypes.txt will be removed sooner or later |
| 07:12 |
est31 |
you can do these kinds of updates yourself as well |
| 07:12 |
est31 |
just edit |
| 07:12 |
paramat |
i see |
| 07:12 |
est31 |
lemme see... |
| 07:13 |
est31 |
Edit builtin/mainmenu/tab_settings.lua, change the "false" at line 727 to a "true" |
| 07:13 |
est31 |
then start the client, mainmenu is enough |
| 07:17 |
paramat |
nice, thanks |
| 07:18 |
est31 |
I'll merge this in ten minutes https://github.com/est31/minetest/commit/bdfb761dd06261e71f96b731ad423338a9c01008 |
| 07:18 |
paramat |
..then change the true back to false i guess |
| 07:18 |
paramat |
ok go ahead |
| 07:19 |
est31 |
is that a +1 ? |
| 07:19 |
est31 |
otherwise I wait for you |
| 07:20 |
paramat |
i'll look |
| 07:20 |
paramat |
seems simple so +1 |
| 07:23 |
est31 |
thanks, pushed |
| 07:28 |
Hunterz |
hi, est31 something broken wit the console... when serever running some days without restart, console looks like stop showing all info from the server |
| 07:28 |
est31 |
Hunterz, what do you mean? |
| 07:29 |
Hunterz |
when press some key and then enter, console show one new line of 2 days old event |
| 07:29 |
est31 |
you might have scrolled up |
| 07:29 |
est31 |
try pgup / pgdown |
| 07:29 |
Hunterz |
ah works |
| 07:30 |
Hunterz |
thanks, will be possible autoscroll? |
| 07:30 |
est31 |
yes it is autoscroll |
| 07:30 |
est31 |
just keep scrolled at bottom |
| 07:31 |
Hunterz |
how? |
| 07:31 |
est31 |
well press pgdown as often as possible |
| 07:31 |
est31 |
then it will stay there |
| 07:32 |
Hunterz |
ok |
| 07:33 |
Hunterz |
will be possible add / instead of chat to console as defaut behavior? |
| 07:34 |
Hunterz |
i think server console is primarily for server control, not chatting with players |
| 07:34 |
est31 |
it can be added |
| 07:34 |
est31 |
perhaps one mode for / one for no default |
| 07:39 |
Hunterz |
Minetest 0.4.13-dev-0876623 | Game 4575726 Time of day 19:00 -- Number after Game is seconds server online? Will be possible change it to some human readable? (Server online 2 days 8 hours...) Is possible add to this line something about memory consumption, server lag etc? I think will be useful. |
| 07:40 |
est31 |
its not uptime |
| 07:40 |
est31 |
its the time since the first start of the server |
| 07:40 |
est31 |
so its the sum of all uptimes |
| 07:40 |
est31 |
if you restart, the value continues, doesnt start with 0 again |
| 07:41 |
est31 |
And I dunno what it can be changed to |
| 07:41 |
|
Calinou joined #minetest-dev |
| 07:41 |
Hunterz |
I think actual uptime (latest restart) will be fine add too |
| 07:41 |
est31 |
well too many time values won't look nice I think |
| 07:42 |
Hunterz |
for example bukkit (minecraft) |
| 07:42 |
Hunterz |
[08:18:55 INFO]: CONSOLE issued server command: /mem |
| 07:42 |
Hunterz |
[08:18:55 INFO]: Uptime: 47 minutes 36 seconds |
| 07:42 |
Hunterz |
[08:18:55 INFO]: Current TPS = 20 |
| 07:42 |
Hunterz |
[08:18:55 INFO]: Maximum memory: 989 MB. |
| 07:42 |
Hunterz |
[08:18:55 INFO]: Allocated memory: 241 MB. |
| 07:42 |
Hunterz |
[08:18:55 INFO]: Free memory: 177 MB. |
| 07:42 |
Hunterz |
[08:18:55 INFO]: World "world": 272 chunks, 18 entities, 27 tiles. |
| 07:42 |
est31 |
use a pastebin dude |
| 07:43 |
Hunterz |
sorry |
| 07:45 |
Calinou |
server could have /uptime command, yes, definitely |
| 07:45 |
Calinou |
replies uptime in days/hours/minutes/seconds |
| 07:52 |
|
DFeniks joined #minetest-dev |
| 08:06 |
paramat |
will merge 3377 after checks |
| 08:12 |
paramat |
now merging |
| 08:17 |
paramat |
done |
| 08:28 |
|
blaze joined #minetest-dev |
| 08:31 |
|
Krock joined #minetest-dev |
| 08:36 |
est31 |
any core dev want to review #3354 #3355 #3369 ? |
| 08:39 |
est31 |
kahrl ? nore ? sfan5 ? celeron55 ? ^ |
| 08:43 |
paramat |
nore sfan5 i'll merge https://github.com/minetest/minetest_game/pull/728 'Default/mapgen: Use sidelen 16 for low density decorations' later, fairly trivial biome system maintenance |
| 08:43 |
|
workflow joined #minetest-dev |
| 08:56 |
|
deltib joined #minetest-dev |
| 08:59 |
|
nrzkt joined #minetest-dev |
| 09:17 |
paramat |
now merging game 728 |
| 09:21 |
|
OldCoder joined #minetest-dev |
| 09:22 |
paramat |
done |
| 09:23 |
|
OldCoder joined #minetest-dev |
| 09:27 |
|
paramat left #minetest-dev |
| 09:56 |
|
OldCoder joined #minetest-dev |
| 09:57 |
|
OldCoder left #minetest-dev |
| 10:33 |
|
gregorycu joined #minetest-dev |
| 10:34 |
|
who_wants_some joined #minetest-dev |
| 10:35 |
|
gregorycu joined #minetest-dev |
| 10:50 |
|
technics joined #minetest-dev |
| 10:51 |
|
OldCoder joined #minetest-dev |
| 11:24 |
|
CraigyDavi joined #minetest-dev |
| 11:31 |
|
zupoman joined #minetest-dev |
| 12:00 |
|
who_wants_some joined #minetest-dev |
| 12:02 |
nore |
paramat: looks good |
| 12:03 |
est31 |
nore, I pinged you earlier about engine PRs. they are fairly simple, but only have my approval |
| 12:03 |
est31 |
as hmmm is at mt vacation, a second person to review stuff is missing |
| 12:04 |
est31 |
If you have time can you look at #3369 #3355 #3354 |
| 12:04 |
nore |
est31: ah, I had not seen those |
| 12:04 |
nore |
looking at them now |
| 12:05 |
nore |
#3369: not tested, but looks fine if it works |
| 12:06 |
nore |
(the commit looks simple enough to me so if you tested it, +1) |
| 12:07 |
est31 |
I didn't. Ill ask if the pr creator tested |
| 12:07 |
nore |
#3355 looks fine too |
| 12:10 |
|
Darcidride joined #minetest-dev |
| 12:12 |
nore |
about #3354, it looks fine, but I don't seen what it is used for |
| 12:12 |
nore |
s/seen/see/ |
| 12:13 |
est31 |
its to replace an std::queue in profiler code |
| 12:13 |
nore |
ah, ok |
| 12:14 |
* nore |
had not seen that while looking at the code |
| 12:14 |
est31 |
yes, that pr doesnt change it |
| 12:14 |
est31 |
it only adds the data structure |
| 12:14 |
nore |
ok |
| 12:15 |
nore |
I did not check this one as much as the others though |
| 12:15 |
nore |
but the code looks fine; it however needs testing |
| 12:15 |
|
blaze joined #minetest-dev |
| 12:16 |
nore |
so let's say I give +1 to #3369 ans #3355, and to #3354 if it is tested |
| 12:17 |
est31 |
great thanks |
| 12:35 |
nrzkt |
est31 i added a +1 for the item groups craft replacements |
| 12:40 |
est31 |
fine thanks |
| 12:49 |
Hunterz |
Hi, anyone have rendering delay when first render page of unified inventory? I made video: http://www.twitch.tv/hunterzcz/v/25917402 |
| 12:50 |
Hunterz |
its on the linux |
| 12:52 |
Calinou |
Hunterz, don't use HD texture packs, it will be much faster |
| 12:52 |
Calinou |
if it's still too slow, there is not much you can do, except enabling "Preload item visuals" which will make the delay occur when starting the world, rather than opening the inventory |
| 12:52 |
Hunterz |
i have no texture pack |
| 12:52 |
who_wants_some |
i have that delay when changing pages for the first time on unified invenory |
| 12:53 |
Hunterz |
yes only first time |
| 12:53 |
Hunterz |
i think some preload to memory will be solution |
| 12:55 |
|
Amaz joined #minetest-dev |
| 12:57 |
Hunterz |
hmmm when try enable to "Preload item visuals" - during login to server sreeen flickering like hell |
| 13:26 |
|
damiel joined #minetest-dev |
| 13:39 |
|
kaeza joined #minetest-dev |
| 13:42 |
|
CraigyDavi joined #minetest-dev |
| 13:52 |
Sokomine |
hi :-) i could use some feedback. mg_villages is mostly ready to be released. the documentation can be found under https://github.com/Sokomine/mg_villages/wiki feedback regarding the docu is welcome |
| 13:56 |
Sokomine |
ups. sorry. wrong channel :-( |
| 14:29 |
|
Player2 joined #minetest-dev |
| 14:30 |
|
zat joined #minetest-dev |
| 15:10 |
|
hmmmm joined #minetest-dev |
| 15:18 |
|
Player2 joined #minetest-dev |
| 16:05 |
|
Player2 joined #minetest-dev |
| 16:24 |
|
ElectronLibre joined #minetest-dev |
| 16:37 |
who_wants_some |
http://pastebin.com/Bd4r5y0J bad allocation error on Krock's build, 32bit, windows 7, 1.6gb of ram was taken by mt at the moment of crash |
| 16:50 |
who_wants_some |
get this error after very long walks (hour or so) |
| 17:07 |
|
Krock joined #minetest-dev |
| 18:04 |
|
Player2 joined #minetest-dev |
| 18:06 |
|
rubenwardy joined #minetest-dev |
| 18:50 |
celeron55 |
who_wants_some: how much ram and swap do you have? i mean, did you run out of memory? |
| 18:50 |
celeron55 |
that kind of error can occur due to one of two reasons |
| 18:51 |
celeron55 |
either you actually ran out of memory, or the program erroneously tried to allocate a ridiculously large chunk of memory |
| 19:08 |
who_wants_some |
i made a topic about it, feel free to look at it https://forum.minetest.net/viewtopic.php?f=6&t=13585 / i have 8 gig or ram, and mt 32 bit dies at 1.6gb, that is reproducable |
| 19:09 |
hmmmm |
well I think that's your answer |
| 19:10 |
hmmmm |
how do you expect a 32 bit process to make use of your 8gb of ram? |
| 19:11 |
who_wants_some |
i think if mt is a 32bit process, it should unload some blocks if it goes close to a "limit" |
| 19:11 |
hmmmm |
right but it doesn't know that |
| 19:11 |
hmmmm |
i think all lawn should cut itself too but it doesn't |
| 19:11 |
hmmmm |
i think my lawn is bugged |
| 19:12 |
who_wants_some |
not possible to detect if os is 32 bit and enable some dirty hacks? :( |
| 19:14 |
hmmmm |
even if it were simply to do in a platform independent manner, there's a 99% chance you're running windows so you'd have to wait until the next release to get it |
| 19:14 |
hmmmm |
your best shot is to just download a 64 bit build and play that instead |
| 19:14 |
who_wants_some |
i know, i thinking about average user who does not know about this |
| 19:14 |
who_wants_some |
i'm* |
| 19:15 |
who_wants_some |
ultra large multiplayer servers like LinuxGaming2 crash 32 bit client in a metter of minutes :) |
| 19:16 |
hmmmm |
you should just lower client_mapblock_limit |
| 19:18 |
|
Amaz joined #minetest-dev |
| 19:19 |
who_wants_some |
yes, that is good too, too bad it is not lowering automaticly when reaching mem limit in 32bit os :) I don't want to argue, I want to inform, thanks for response |
| 19:20 |
|
ElectronLibre_ joined #minetest-dev |
| 19:20 |
|
ElectronLibre joined #minetest-dev |
| 19:29 |
|
VanessaE joined #minetest-dev |
| 19:37 |
|
Samson1 joined #minetest-dev |
| 19:59 |
|
VanessaE joined #minetest-dev |
| 20:05 |
|
Darcidride joined #minetest-dev |
| 20:23 |
celeron55 |
well i guess we should have a long-term goal of automatically unloading stuff if the memory limit comes close |
| 20:23 |
celeron55 |
but it's not trivial because it's completely non-standard |
| 20:24 |
celeron55 |
the OS could just stop allocating stuff even if there is free memory, or somehow create more virtual memory after the current RAM and swap are exhausted |
| 20:25 |
celeron55 |
and i don't think we could manage to maintain a system where any allocation could fail and the game could continue running |
| 20:25 |
celeron55 |
this is what hmmmm is referring to :P |
| 20:26 |
|
rubenwardy joined #minetest-dev |
| 20:27 |
celeron55 |
i mean, if you have 8GB of RAM and it's a 32 bit process, exactly what kind of a limit is 1.6GB? |
| 20:27 |
celeron55 |
i don't see any way of detecting that there would be a limit at that point |
| 20:28 |
hmmmm |
FWIW I am guessing who_wants_some is measuring memory usages from peak working set and not reserved |
| 20:28 |
hmmmm |
if the reserved memory gets around 2gb, then you have problems |
| 20:28 |
celeron55 |
that's very true |
| 20:28 |
celeron55 |
(and still very OS-dependent) |
| 20:29 |
hmmmm |
yeah i think this is totally wrong for Linux |
| 20:33 |
celeron55 |
i guess a system that checks through an os-specific wrapper how much reservable memory is not yet reserved could be created and called before each larger allocation and be set up to trigger unloading of the oldest of things; but i bet nobody is going to attempt that |
| 20:33 |
celeron55 |
it might get too fiddly and would be a very rarely used code path |
| 20:34 |
celeron55 |
basically it would probably just crash anyway :P |
| 20:41 |
who_wants_some |
some servers need [64 bit] tag, so user will know it is heavy load down there |
| 21:05 |
|
ElectronLibre left #minetest-dev |
| 21:06 |
celeron55 |
maybe some kind of a memory limit suggestion setting could be made that could default on each 32-bit platform to something that usually avoids address space exhaustion |
| 21:07 |
celeron55 |
and which would speed up mapblock unloading when it triggers |
| 21:07 |
celeron55 |
that could be simple enough, and fairly simple to test |
| 21:08 |
celeron55 |
it cannot provide 100% protection against it though because of how memory works at OS level |
| 21:08 |
hmmmm |
you know I wonder how many mapblocks contain meshes that are just solid cubes |
| 21:08 |
hmmmm |
especially underground |
| 21:08 |
celeron55 |
none |
| 21:08 |
hmmmm |
is that case optimized already? |
| 21:08 |
celeron55 |
mapblock edges are not generated into the mesh |
| 21:08 |
hmmmm |
ahh ok |
| 21:08 |
celeron55 |
if they are not needed |
| 21:09 |
celeron55 |
the mesh generation isn't actually fed the data of a single mapblcok |
| 21:09 |
celeron55 |
mapblock* |
| 21:09 |
celeron55 |
it is fed the data of 5 mapblocks in order to give it the information it needs for doing that |
| 21:09 |
celeron55 |
and it's also needed for avoiding z-fighting issues |
| 21:09 |
celeron55 |
wait, i mean 7 mapblocks? |
| 21:10 |
celeron55 |
actually no... |
| 21:10 |
celeron55 |
it's four |
| 21:10 |
celeron55 |
the middle one, and each one towards the three positive (or maybe negative, idk) coordinates |
| 21:11 |
celeron55 |
anyway; faces are generated only towards a certain side so that when mapblocks are rendered next to each other, only one covers the edge |
| 21:12 |
celeron55 |
and it will have nothing there if the other one contains something that doesn't make a face there |
| 21:12 |
|
Player2 joined #minetest-dev |
| 21:13 |
celeron55 |
(i did make FarMap work in such a way that it only generates based on a single FarBlock and it does make solid cubes underground; however it doesn't seem to be a problem) |
| 21:13 |
hmmmm |
heh |
| 21:13 |
VanessaE |
celeron55: did you see my z-fighting glitch regarding that? |
| 21:14 |
celeron55 |
it isn't necessarily related to that |
| 21:14 |
|
AnotherBrick joined #minetest-dev |
| 21:14 |
celeron55 |
a FarBlock couldn't carefully cover the individual faces of mapblock |
| 21:14 |
celeron55 |
you'd have a huge hole in there instead |
| 21:14 |
VanessaE |
oh ok. |
| 21:14 |
VanessaE |
(for reference: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-11-12_00-15-02.png ) |
| 21:14 |
celeron55 |
maybe they should be offset so that z fighting wouldn't occur |
| 21:16 |
who_wants_some |
i see z-fighting in OGL at least since 0.4.5 (i mean that texture tear I've posted on forum) |
| 21:16 |
VanessaE |
who_wants_some: I don't think this is related to that. |
| 21:17 |
who_wants_some |
maybe not |
| 22:55 |
|
AnotherBrick joined #minetest-dev |
| 23:11 |
|
luizrpgluiz joined #minetest-dev |
| 23:21 |
|
luizrpgluiz joined #minetest-dev |
