| Time |
Nick |
Message |
| 00:06 |
|
MrIbby left #minetest-dev |
| 00:16 |
|
wayward1 joined #minetest-dev |
| 00:25 |
|
wayward1 left #minetest-dev |
| 01:17 |
|
proller joined #minetest-dev |
| 01:26 |
|
paramat joined #minetest-dev |
| 02:56 |
|
Tmanyo joined #minetest-dev |
| 02:58 |
|
Tmanyo joined #minetest-dev |
| 03:01 |
|
Tmanyo joined #minetest-dev |
| 03:41 |
|
Puka joined #minetest-dev |
| 04:17 |
|
sofar joined #minetest-dev |
| 04:23 |
|
kaeza joined #minetest-dev |
| 05:09 |
sofar |
bug related question |
| 05:09 |
sofar |
does class GUIFormSpecMenu know or have a member to indicate that it is being executed in a MAINMENU context or in a GAME/CLIENT context? |
| 05:10 |
sofar |
#5593 |
| 05:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/5593 -- Game exits when [tab] key pressed in server login page at [user] field |
| 05:10 |
sofar |
can fix this bug if I can somehow determine `if (in_mainmenu)` |
| 05:11 |
sofar |
m_client == NULL? |
| 05:14 |
sofar |
ahhh yes, that actually works |
| 05:16 |
sofar |
yay, fixed my own weird bug |
| 05:29 |
|
Hunterz joined #minetest-dev |
| 05:40 |
rdococ |
hello |
| 05:40 |
rdococ |
I'm here. You should go and hide. |
| 05:42 |
|
octacian joined #minetest-dev |
| 05:57 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:06 |
|
nerzhul joined #minetest-dev |
| 07:11 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:23 |
|
kaeza joined #minetest-dev |
| 07:25 |
nerzhul |
merging #4981 |
| 07:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/4981 -- Partial damage cheat fix: node damages server side by nerzhul |
| 07:44 |
|
cx384 joined #minetest-dev |
| 07:45 |
|
Krock joined #minetest-dev |
| 08:08 |
|
cx384 joined #minetest-dev |
| 09:29 |
|
DS-minetest joined #minetest-dev |
| 10:03 |
|
nerzhul joined #minetest-dev |
| 10:16 |
Krock |
nerzhul, what about https://github.com/minetest/minetest/pull/5493#discussion_r111555540 ? |
| 10:17 |
nerzhul |
Krock, yeah, sorry i forget to answer |
| 10:18 |
nerzhul |
on first test when i'm doing this overwrite on m_bgcolor there was a problem, i need to re-test since last changes |
| 10:22 |
|
Fixer joined #minetest-dev |
| 10:36 |
|
DS-minetest joined #minetest-dev |
| 10:56 |
celeron55 |
Fixer: try this https://github.com/celeron55/minetest/tree/mesh_update_block_cache |
| 11:00 |
|
kilbith joined #minetest-dev |
| 11:01 |
celeron55 |
or wait for a moment, i'm fixing a thing |
| 11:03 |
celeron55 |
ok now |
| 11:17 |
Fixer |
celeron55: will try but little later @ dinner |
| 11:17 |
Krock |
^ throws a weird MSVC error about converting "const v3s16" to "size_t" is not possible with "CachedMapBlockData *" |
| 11:18 |
Krock |
will look into this one deeper |
| 11:18 |
celeron55 |
wut? |
| 11:18 |
celeron55 |
well i suppose it tells you a line number |
| 11:20 |
Krock |
I suppose it's something with the cpp11 containers: https://pastebin.com/raw/GBub9E1x |
| 11:20 |
|
DI3HARD139 joined #minetest-dev |
| 11:21 |
Krock |
actually thrown in mesh_generator_thread.cpp |
| 11:25 |
Krock |
looks like it can't generate a hash from v3s16 as map key o.0 |
| 11:30 |
nerzhul |
yes |
| 11:30 |
nerzhul |
std::unordered_map doesn't support v2xxx and v3xxx as they are not hashable containers celeron55 |
| 11:31 |
Krock |
fixed by replacing with std::map |
| 11:35 |
celeron55 |
oh, oops; switching to std::map |
| 11:37 |
Krock |
but it works.. so far |
| 11:43 |
celeron55 |
it's a performance improvement; what you should be looking for is the almost complete disappearance of stutter from adding tasks to the mesh generator |
| 11:44 |
Krock |
yes, I'm testing it right now |
| 11:44 |
celeron55 |
there are other kinds of stutter, i don't know if people have learned to notice that exact kind of stutter :P |
| 11:44 |
celeron55 |
this is a reasonable test config to make it more apparent: |
| 11:44 |
celeron55 |
max_simultaneous_block_sends_server_total = 100 |
| 11:44 |
celeron55 |
max_simultaneous_block_sends_per_client = 100 |
| 11:44 |
celeron55 |
mesh_generation_interval = 0 |
| 11:45 |
celeron55 |
(on a high end system) |
| 11:46 |
celeron55 |
also if someone makes a windows build, throw that to me, i can test on my media pc that doesn't have a compiler or anything |
| 11:46 |
Krock |
okay, will upload |
| 11:50 |
Krock |
https://www.dropbox.com/s/bpwfpqwohdnn79o/minetest_170415_1c851e0_mesh_update_block_cache.7z |
| 11:51 |
Krock |
32-bit and std::map patched manually, so it's the most recent version |
| 11:59 |
Krock |
ah, increasing the minimal view range helps. |
| 12:02 |
celeron55 |
anything that causes more stuff to be copied to the mesh generator will exaggerate the difference |
| 12:05 |
celeron55 |
which is, anything that causes the server to send more mapblocks |
| 12:06 |
celeron55 |
it can be masked by mapblocks that have heavy use of node metadata though as it's able to cause a different stutter that can be much higher than the copying-mapblocks-for-meshgen one |
| 12:08 |
Krock |
http://i.imgur.com/X51IW7M.png local world |
| 12:09 |
Krock |
but there weren't so many processed blocks in the new one. will have to do more testse |
| 12:09 |
Krock |
*tests |
| 12:12 |
Krock |
but overall feels smoother now |
| 12:33 |
Krock |
Pushing this fix in 15 minutes: https://pastebin.com/raw/qN2A6ZE5 |
| 12:39 |
|
lisac joined #minetest-dev |
| 13:04 |
Fixer |
celeron55: i'm back, will look now |
| 13:09 |
Fixer |
celeron55: don't see much difference, default config, spawned near jungle, stuttered like crazy https://i.imgur.com/QgP4bSx.png (tested without std::map commit) |
| 13:11 |
Fixer |
will try std::map version |
| 13:16 |
celeron55 |
it doesn't look like what i would expect, are you sure you built the right version? |
| 13:24 |
Fixer |
celeron55: is not krock's screenshot also suggests there is tons of stutter anyway |
| 13:24 |
Krock |
right, there's also sometimes no sleep time for the main thread |
| 13:26 |
Krock |
but what counts is the speed of copying the map data |
| 13:34 |
Fixer |
tried krock's build, right away in forests observed very visible shitty stuttering https://i.imgur.com/p2Z26RI.png |
| 13:34 |
celeron55 |
Fixer: actually, looks like in that screenshot basically all of the block receive related stutter is gone, not counting the single big spike |
| 13:35 |
celeron55 |
that shows the same thing |
| 13:36 |
celeron55 |
there's both _other and _draw stutter left that isn't related to the toclient_blockdata handler |
| 13:36 |
celeron55 |
what CPU and GPU does this system have? |
| 13:37 |
Fixer |
core i3 2120 3.3ghz + 8gb ram + amd hd6870 1gb vram |
| 13:38 |
Fixer |
0.095 ms mainloop_dtime... karl |
| 13:38 |
Fixer |
mainloop_draw* |
| 13:38 |
Fixer |
i have no idea how it helps since game stutters like crazy anyway |
| 13:38 |
Fixer |
default config |
| 13:39 |
Fixer |
0.095 sec* |
| 13:39 |
celeron55 |
basically the same cpu as my media pc then (this has 2100) |
| 13:42 |
celeron55 |
yeah, i can see the stutter i set out to get rid of is gone |
| 13:42 |
celeron55 |
and that there are at least 2 other stutters left |
| 13:53 |
celeron55 |
the stutters left in mainloop_other don't correlate with anything that's currently graphed, the stutters left in mainloop_draw seem to partly correlate with # processed meshes and partly not with anything that is currently graphed |
| 14:32 |
|
proller joined #minetest-dev |
| 14:44 |
|
YuGiOhJCJ joined #minetest-dev |
| 14:51 |
celeron55 |
https://github.com/minetest/minetest/pull/5595 |
| 15:06 |
|
kaeza joined #minetest-dev |
| 15:12 |
Krock |
poor travis got a lot to do right now :/ |
| 15:13 |
|
paramat joined #minetest-dev |
| 15:22 |
paramat |
Zeno` are you +1 for #5519 ? i moved the temporary old move code to the end of the file to make things cleaner |
| 15:22 |
kilbith |
why the dominant male ain't allowed to push straight ahead if he wants to |
| 15:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/5519 -- Sneak: Add option for old move code by paramat |
| 15:22 |
celeron55 |
kilbith: why would i want to; these nice people will catch my errors so i don't need to |
| 15:22 |
celeron55 |
lol |
| 15:23 |
kilbith |
I remember hmmmm enforcing the rules on you |
| 15:24 |
kilbith |
you need some praetorian guards to defend your rights of dictator IMO |
| 15:25 |
Krock |
we'd get nowhere if our dictator could do what he wants :P |
| 15:25 |
celeron55 |
well someone would try enforcing them for sure, and if i made any errors it'd be kind of bad |
| 15:25 |
nerzhul |
lol the dictator era is finished in minetest (not on earth, we have three WW3 competitors) |
| 15:30 |
|
xerox123 joined #minetest-dev |
| 15:31 |
Krock |
duh, if the order of including our header files matter, then something's going wrong with the structure |
| 15:31 |
celeron55 |
yeah i added an initial commit that adds the include into util/thread.h |
| 15:31 |
celeron55 |
util/thread.h was broken |
| 15:34 |
celeron55 |
should be fixed now |
| 15:38 |
paramat |
celeron55 since you are concerned about the issue, are you able to +1 #5519 ? |
| 15:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/5519 -- Sneak: Add option for old move code by paramat |
| 15:41 |
paramat |
or maybe just a concept review |
| 15:42 |
|
troller joined #minetest-dev |
| 15:44 |
paramat |
nore ^ any opinion on that? |
| 15:44 |
nore |
paramat: need to think about it |
| 15:45 |
paramat |
ok thanks |
| 15:46 |
celeron55 |
i think the concept is fine |
| 15:47 |
celeron55 |
the only thing left from that in the long term is the byte added to the protocol |
| 15:52 |
paramat |
hmm from the extra physics override |
| 15:52 |
paramat |
i had not considered that |
| 15:53 |
|
kaeza joined #minetest-dev |
| 15:53 |
paramat |
new sneak code is going well, we now have all ladders working as before, we have 2 node sneak jump, and basic sneak behaviour only has minor issues left |
| 15:56 |
celeron55 |
(the code is fine to me also) |
| 15:56 |
celeron55 |
are we doing these partial reviews nowadays? |
| 15:56 |
nerzhul |
what do you mean with partial review ? |
| 15:57 |
celeron55 |
there's no actual rule for how to take into account something like someone saying "+1 for concept", or is there? |
| 15:57 |
celeron55 |
i wrote about it a long time ago but i guess it ended up as a suggestion |
| 15:57 |
nerzhul |
no rule, concept != quality |
| 15:59 |
celeron55 |
if someone says +1 (implying everything) and then three others say "+1 for concept", "+1 for code", "tested to work fine", i guess it sums up as two full +1s |
| 16:00 |
celeron55 |
except that then you can forget to check the protocol or something |
| 16:00 |
celeron55 |
do we even need 2 +1s for anything else than concept |
| 16:04 |
celeron55 |
i'd suggest 2 +1s should be required for concept and persistent data (being network protocol and disk formats), and for everything else one +1 is enough |
| 16:05 |
Remy_ |
+1 |
| 16:05 |
nerzhul |
celeron55, you mean less +1 ? and what about coredev ? |
| 16:06 |
celeron55 |
i mean all of those from coredevs |
| 16:07 |
nerzhul |
it's already the case for coredevs, |
| 16:07 |
nerzhul |
2 +1 for external , 1 for coredev PR |
| 16:07 |
paramat |
no concept rule is not an official thing, i was just asking your opinion on the concept (since you probably don't have time to review fully) |
| 16:08 |
paramat |
sorry i mean 'concept approval' |
| 16:09 |
paramat |
a +1 is only official if it is a full review: code and concept |
| 16:10 |
celeron55 |
really the only reason i ask is because personally i like to review concepts and protocols |
| 16:10 |
paramat |
and a core dev's approval of their own PR counts towards the 2, which helps |
| 16:11 |
|
troller joined #minetest-dev |
| 16:15 |
* Fixer |
.oO(minetest stone soup) |
| 16:46 |
nerzhul |
okay guis #5475 is now ready and has bidirectional migration, like map |
| 16:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/5475 -- WIP: player data to Database by nerzhul |
| 16:46 |
nerzhul |
guys* |
| 16:47 |
nerzhul |
the only missing thing is a little bit more documentation on minetest wiki linked into client |
| 17:07 |
nerzhul |
who manages wiki.minetest.net accounts ? |
| 17:07 |
Calinou |
nerzhul: me |
| 17:07 |
nerzhul |
Calinou, can you create me an accouhnt ? |
| 17:08 |
Calinou |
nerzhul: sure, PM me your e-mail address and desired username |
| 17:08 |
Calinou |
(note that username must start with an uppercase character) |
| 17:11 |
|
YuGiOhJCJ joined #minetest-dev |
| 17:12 |
nerzhul |
i PM you |
| 17:50 |
ShadowNinja |
The first Minetest developer meeting is in 10 minutes. :-) nore, sofar, celeron55, sfan5, paramat: you said this time worked for you, are you available today? nerzhul, Zeno`: I didn't hear from you, please tell me if this time (18:00 UTC) works for you. All devs: please join -staff for private discussion if you have not joined already. |
| 17:50 |
nore |
ShadowNinja: I'm there |
| 17:51 |
kilbith |
it's 3:50 AM where Zeno` lives |
| 17:52 |
* sofar |
yawns |
| 17:52 |
sofar |
I thought it was 50 minutes ago |
| 17:52 |
ShadowNinja |
kilbith: Oh, I suppose he won't be able to participate then. :-| |
| 17:53 |
kilbith |
and can you please explain why the development discussion has to be that opaque ? |
| 17:53 |
nore |
I just rebased two of the pulls https://github.com/Ekdohibs/minetest/tree/pull-3299 and https://github.com/Ekdohibs/minetest/tree/pull-3651 btw |
| 17:53 |
nore |
one of these is completely untested (the build one), the other only had a quick testing though |
| 17:54 |
ShadowNinja |
kilbith: What do you mean? The -staff part? That's mainly just for stuff like the meeting notes (they're editable to anyone with the URL). |
| 17:55 |
Fixer |
minetest-dev feels very b-rocratic |
| 17:55 |
kilbith |
yeah, I don't know it has to be private, there are people actually living on MT and they need to anticipate from what has been decided in upstream |
| 17:56 |
nore |
ShadowNinja: isn't there a way to have a public url that isn't editable? |
| 17:57 |
sofar |
brt |
| 17:57 |
ShadowNinja |
nore: Not with the service that I'm using (AFAIK), but we could use something else. Any ideas? |
| 18:00 |
ShadowNinja |
Good evening and welcome to the first edition of the Minetest weekly(?) developer meeting. |
| 18:00 |
ShadowNinja |
The purpose of this meeting is to quickly reach a decision on a number of PRs at a time when enough developers are available to quickly approve/deny them. This meeting is intended to be fairly fast-paced. If we decide to merge a PR it will be assigned to someone and should be merged shortly after the meeting. If a PR warrants an extended discussion we'll delay it until after the meeting. We're going to focus on the engine for now. |
| 18:00 |
ShadowNinja |
First order of business: #1188 I don't see any reason why this shouldn't be merged, although it does require some rebasing. Any objections to merging? If not, any volunteers to do the rebase and merge? |
| 18:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/1188 -- getTime refactoring by Selat |
| 18:00 |
nore |
it was a good PR, so +1 for merging from me |
| 18:00 |
nore |
I can try to rebase it |
| 18:02 |
sofar |
careful |
| 18:02 |
sofar |
I rewrote a bunch of gettime.h |
| 18:02 |
sofar |
so there's conflicts for the core parts |
| 18:03 |
ShadowNinja |
nore: Alright, great. Moving on... #3580 / #4664 (alternate implementations) Merge or close? |
| 18:03 |
sofar |
but, yes we should merge what we can from this |
| 18:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/3580 -- Added delayed shutdown feature by pinkysnowman |
| 18:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul |
| 18:04 |
nore |
I would say concept-wise, it is an useful feature |
| 18:05 |
sofar |
normally I'd agree that we want mods to do things where applicable, but this is still something I don't mind seeing in c++ |
| 18:05 |
sofar |
doesn't help that hmmmm and est31 are no longer here :) |
| 18:05 |
sofar |
and Zeno`'s alseep |
| 18:05 |
nore |
I guess we could rebase #4664 and merge it probably |
| 18:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul |
| 18:05 |
nore |
(as it seems more complete than 3580) |
| 18:06 |
sofar |
if nerzhul rebases I'm fine with it |
| 18:06 |
paramat |
here |
| 18:06 |
sofar |
but I'm looking at others more, I was already ok with it before |
| 18:08 |
ShadowNinja |
IMO nrz's implementation is overcomplicated. The simple Lua implementation should work just about as well, right? |
| 18:09 |
nore |
ShadowNinja: it doesn't allow cancelling |
| 18:09 |
ShadowNinja |
nore: True, but that could be added in Lua. |
| 18:09 |
nore |
ShadowNinja: yes, but it's not easy because it uses minetest.after |
| 18:10 |
nore |
I mean it can be done but most of the PR would have to be rewritten |
| 18:11 |
ShadowNinja |
Yeah, I guess I just like the simplicity of the Lua solution. But if you all prefer the C++ impl, we'll do that. |
| 18:11 |
ShadowNinja |
It seems we're in agreement to merge at least one of them though? |
| 18:11 |
nore |
it looks like so, yes :) |
| 18:12 |
nore |
next item on the list then, I guess? |
| 18:12 |
ShadowNinja |
paramat, sofar: opinions on which to use? |
| 18:13 |
paramat |
no opinion |
| 18:13 |
sofar |
nrz's version, since he's here to redo it |
| 18:13 |
paramat |
are we going through old PRs oldest first? |
| 18:13 |
ShadowNinja |
nerzhul: Will you rebase and merge your PR? |
| 18:14 |
ShadowNinja |
paramat: Yep. |
| 18:14 |
ShadowNinja |
(more-or-less) |
| 18:14 |
celeron55 |
i like the C++ one more |
| 18:15 |
paramat |
ah you're going by least recently updated, i was thinking oldest by number |
| 18:15 |
celeron55 |
(altough, it's almost criminal how wasteful duration_to_string is about lines of code use) |
| 18:17 |
ShadowNinja |
Alright, nerzhul's taking too long, I'll assign the PR to him for now. Next: #2085 -- Merge or close? |
| 18:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/2085 -- Disable font scaling on non-Android platforms by cheapie |
| 18:18 |
nore |
is it still relevant or not? |
| 18:18 |
nore |
I mean, is font scaling still there? |
| 18:19 |
ShadowNinja |
I'm not sure. |
| 18:21 |
ShadowNinja |
The PR is old and it seems font-scaling is working nore-or-less fine now, so I vote close. Does that sound good? |
| 18:22 |
nore |
hmmm, with quick testing (xrandr --scale 0.5x0.5, where I get text ~2 bigger), it looks like there's no problem |
| 18:22 |
nore |
so I would say close as well |
| 18:22 |
celeron55 |
i don't think making formspec behave differently on different devices is going to make anything better to anyone |
| 18:22 |
paramat |
i'm fine with close |
| 18:23 |
nore |
(interestingly, with --scale 2x2 I get text twice smaller, but some elements don't scale... well) |
| 18:23 |
celeron55 |
it would be nice to add a proper reference to this log in the closing messages |
| 18:24 |
ShadowNinja |
Alright, done. #3651: Seems ready to merge, just needs someone to rebase(trivial) and merge. Any volunteers? |
| 18:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/3651 -- Disable android leveldb by default by MoNTE48 |
| 18:24 |
celeron55 |
otherwise nobody will remember even after a few days |
| 18:24 |
nore |
already rebased it, but untested |
| 18:24 |
nore |
https://github.com/Ekdohibs/minetest/tree/pull-3651 |
| 18:24 |
ShadowNinja |
celeron55: I'll add it in. |
| 18:25 |
nore |
I can't test however, but this is a rebased version of it |
| 18:25 |
ShadowNinja |
nore: Well, since you've rebased it I think in makes sense for you to test/merge it. Is that fine? |
| 18:25 |
paramat |
could you open a new PR then? so we can close this one? |
| 18:26 |
nore |
ShadowNinja: as I said, this is android build and I can't test it |
| 18:26 |
celeron55 |
i would trust MoNTE48's choices on android |
| 18:26 |
nerzhul |
oh it's now ? :) |
| 18:26 |
nore |
that's why it is completely untested |
| 18:26 |
nerzhul |
sorry for to be late then |
| 18:27 |
paramat |
others can test the new PR |
| 18:27 |
sofar |
Wayward_One ? |
| 18:27 |
nerzhul |
yes i can rebase 4664 without doubt |
| 18:28 |
ShadowNinja |
nore: O.K., uh, anyone else to test it? (if not, I'd just say go for it) |
| 18:29 |
nore |
--> opened #5596 as paramat requested |
| 18:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/5596 -- Disable android leveldb by default by Ekdohibs |
| 18:29 |
paramat |
PR opened. so close 3651? |
| 18:29 |
nerzhul |
paramat, yes |
| 18:30 |
paramat |
will do |
| 18:30 |
paramat |
done |
| 18:30 |
ShadowNinja |
Alright, nore: the Travis build will probably do. I'll leave you to merge it as soon as it's ready. |
| 18:31 |
ShadowNinja |
Next: #1439 -- Reabse and merge or close? |
| 18:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/1439 -- Add configurable key bindings for selecting next/previous hotbar item and changing the volume by Wuzzy2 |
| 18:31 |
nore |
Didn't est31 said he could still help with android builds btw? |
| 18:31 |
nerzhul |
travis deosn't test android build |
| 18:31 |
nerzhul |
nore est31 left us |
| 18:32 |
nore |
nerzhul: I know, but he said he could still help with something I seem to remember was android building |
| 18:32 |
nore |
but anyway |
| 18:32 |
nerzhul |
i do the android builds for release, i can test it, but not know i'm rebasing the delayed shutdown pr |
| 18:32 |
nore |
I like 1439 |
| 18:32 |
ShadowNinja |
I'll leave nore to figure it out, I'd like to keep moving. :-) |
| 18:33 |
nore |
it's simple enough, so I'd just say rebase & merge |
| 18:33 |
nore |
however, paramat thought more keybindings were not needed |
| 18:34 |
nore |
depends on what others want then |
| 18:35 |
|
Hunterz joined #minetest-dev |
| 18:35 |
paramat |
1439 i think there's a new PR that covers this? |
| 18:36 |
celeron55 |
i think 1439 is fine, altough maybe the defaults should be nothing |
| 18:36 |
ShadowNinja |
There are complaints that the keybindings aren't very flexible, but that's really just an issue with our input system, not this PR in particular. |
| 18:36 |
celeron55 |
as most people probably won't use them |
| 18:36 |
|
Player_2 joined #minetest-dev |
| 18:36 |
paramat |
i think there's a newer PR that allows keybindings for hotbars of any size, up to 23 |
| 18:36 |
celeron55 |
ShadowNinja: the PR is good for going to that direction |
| 18:37 |
celeron55 |
it adds more things to bind to, which is needed anyway |
| 18:37 |
celeron55 |
as it's useless to have a better system for binding things without anything to map inputs to :P |
| 18:37 |
celeron55 |
any actions, i mean |
| 18:38 |
ShadowNinja |
Alright, I support merging. I don't care whether they're enabled by default sonce they're configurable. |
| 18:38 |
paramat |
i still don't think these are very useful, next/previous when we have number key access |
| 18:38 |
celeron55 |
well you can always think of disabled people or something |
| 18:39 |
paramat |
volume is not much needed in-game and can be controlled at hardware level |
| 18:39 |
nore |
paramat: some people think they are useful, and it causes no problem to have more keys to bind |
| 18:39 |
celeron55 |
if mouse wheel becomes freely bindable some day, then that's probably the code it's bound to |
| 18:39 |
ShadowNinja |
paramat: Well, it doesn't work with extended hotbars (>10 hotbar elements). |
| 18:39 |
ShadowNinja |
(it = number keys) |
| 18:39 |
celeron55 |
(and the previous mouse wheel code is removed) |
| 18:39 |
paramat |
there's another PR for extended hotbars |
| 18:39 |
nore |
paramat: let's say I want to mute only minetest |
| 18:40 |
ShadowNinja |
paramat: It's fine if there's more than one way to do it, they're just defferent input styles that different people will prefer. |
| 18:40 |
paramat |
yeah mute could be useful |
| 18:40 |
nore |
#4929 indeed, but the two PRs are not mutually exclusive |
| 18:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/4929 -- Make direct item selection keys freely bindable by Wuzzy2 |
| 18:41 |
paramat |
so, i'm not stringly opposed, more neutral |
| 18:41 |
nore |
also, maybe you only want to bind 10 keys because your keyboard hasn't an infinite number of keys, so the other keys for next/previous are still useful |
| 18:41 |
ShadowNinja |
Anyways it seems like everyone but paramat is in favor of merging, correct? Are there any volunteers to merge? |
| 18:41 |
nore |
hmmm, I can try to rebase |
| 18:43 |
paramat |
*strongly, not stringly :] |
| 18:43 |
ShadowNinja |
nore: Alright. Maybe someone else can step up for the later ones... :-) |
| 18:44 |
nore |
heh, I already rebased #3299 ;) |
| 18:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/3299 -- Added afternoon/morning red tint by kaadmy |
| 18:44 |
ShadowNinja |
Next: #4035 -- ~~Needs rebase~~, merge or close? |
| 18:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/4035 -- Additional hooks for inventory manipulations callbacks. by Foghrye4 |
| 18:44 |
ShadowNinja |
er... |
| 18:45 |
paramat |
3299 strongly opposed |
| 18:45 |
ShadowNinja |
Lets do 4035 first, it _does_ need a rebase. |
| 18:46 |
paramat |
foghrye4 has been inactive in MT since Nov |
| 18:47 |
nore |
4035 is interesting, it allows to track *every* item movement |
| 18:47 |
nore |
I don't think that's possible without it |
| 18:47 |
ShadowNinja |
paramat: Yeah, but if someone else can fix it up we could merge it. |
| 18:48 |
nore |
i.e. you can't even track movement of items within a player's own inventory I think? |
| 18:48 |
paramat |
i know :] added adoption needed, didn't mean that to mean close it |
| 18:48 |
nore |
I vote for rebasing |
| 18:49 |
nerzhul |
please note #4664 is now rebased and mergeable, i tested it :) |
| 18:49 |
paramat |
i meant, author not likely to rebase it |
| 18:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul |
| 18:49 |
nore |
(& merge) |
| 18:49 |
celeron55 |
4035 is massive, i wonder if anyone has done any kind of code review |
| 18:49 |
sofar |
it touches a lot of parts that nerzhul has modified |
| 18:49 |
nore |
yeah, that's the problem with it |
| 18:49 |
sofar |
hence the conflicts, perhaps nerzhul can take a look at it? |
| 18:50 |
nerzhul |
huge callback pr |
| 18:50 |
nerzhul |
i don't have time to rebase this PR as i already have player to db pr as a huge pr :p |
| 18:50 |
nerzhul |
and i am finishing the chat protocol rewrite, it's nearly complete |
| 18:51 |
nerzhul |
(for better CSM/SSM integration with chat |
| 18:51 |
nore |
okay, maybe it can wait a bit though -> leave it open and rebase it some time later, except if someone else can rebase it? |
| 18:51 |
ShadowNinja |
Before we rebase it, are we in agreement that the concept is good, regardless of the current implementation/code quality? |
| 18:52 |
nore |
+1 from me |
| 18:52 |
celeron55 |
to me, 4035 is fine in concept (but a lot of potential for bad code) |
| 18:52 |
paramat |
4035 seems potentially useful |
| 18:52 |
nerzhul |
it needs some cleanups, i don't like the GameScripting interface passed to inventorylist |
| 18:53 |
nore |
^ yeah, same, the concept is good but I don't like that point of the current implementation |
| 18:53 |
ShadowNinja |
Alright, I'll put it on hold for the next meeting, avaiting someone to adopt it and clean it up a bit. |
| 18:54 |
nerzhul |
maybe we should have some singleton in core at a moment to have better code interfaces, for example a singleton for the GameScripting and CSM will permit to call callbacks without adding those things, and these are singleton by essence |
| 18:54 |
nerzhul |
i see he prepared CSM part, it's interesting to take it, but we need more time |
| 18:54 |
celeron55 |
no; the codebase is designed to work in a situation where you have multiple Servers for whatever weird reason |
| 18:54 |
nerzhul |
celeron55, very strange situation :p |
| 18:55 |
celeron55 |
but IGameDef is designed for fetching server- or client-wide singletons |
| 18:55 |
celeron55 |
when you need something like that |
| 18:55 |
nerzhul |
it's designed for but not used as is |
| 18:55 |
celeron55 |
well, it can be added for that purpose to anywhere if needed, that's its purpose |
| 18:55 |
nerzhul |
imagine: ClientScripting::get_instance()->on_use(blah); |
| 18:55 |
nore |
I guess it could be useful for things such as server redirections or the like |
| 18:56 |
ShadowNinja |
Let's keep moving please. Next: #3299: Already rebased by nore, merge or close? |
| 18:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/3299 -- Added afternoon/morning red tint by kaadmy |
| 18:56 |
celeron55 |
some complex testing might want to compare two server instances or whtaever |
| 18:56 |
celeron55 |
whatever* |
| 18:56 |
nerzhul |
celeron55, except unittests i don't see where we can have a such thing |
| 18:56 |
celeron55 |
it's a design decision i made and we should stick with it |
| 18:56 |
nore |
paramat says he's strongly opposed to 3299 but didn't explain why yet |
| 18:57 |
paramat |
explained in thread |
| 18:58 |
nore |
hmm |
| 18:58 |
paramat |
has issues and i feel should be in shaders |
| 18:59 |
nore |
bottleneck of meshgen -> not at all, the bottleneck is not there but in getTileInfo |
| 18:59 |
ShadowNinja |
It looks like it will cause color changes in an underground bunker with no natural light, |
| 18:59 |
nore |
however yes, there's the second problem |
| 18:59 |
nore |
maybe it should wait for the change of lightbanks meaning |
| 18:59 |
paramat |
ok bottleneck comment not valid :] |
| 19:00 |
ShadowNinja |
The effect is nice, but I think it needs a better implementation. |
| 19:00 |
nore |
ShadowNinja: note the new implementation is even simpler: https://github.com/Ekdohibs/minetest/commit/aedc81bf7b3999e9f166dad69d343821fbdce173 |
| 19:00 |
paramat |
it's level of fanciness means best in shader code |
| 19:00 |
nore |
(it's literally just modifying the function giving the sunlight color) |
| 19:01 |
paramat |
and at least needs to be optional |
| 19:01 |
ShadowNinja |
nore: That works the same and doesn't affect only artificially-lit areas? |
| 19:02 |
nore |
ShadowNinja: unfortunately it does as lightbanks meaning was not changed yet |
| 19:03 |
nore |
which is something we need to change I would say, as this would allow setting the sunlight color |
| 19:04 |
ShadowNinja |
Alright, I'll mention in the natural/artificial light thread and close it for now. |
| 19:05 |
nore |
ah no, it should work in most cases with artificially-lit areas |
| 19:05 |
nore |
if it's only artificially-lit it should work |
| 19:06 |
nore |
however if it's both artifically-lit and sunlit there won't be red tint |
| 19:07 |
ShadowNinja |
nore: Still buggy, so my position's the same. |
| 19:08 |
ShadowNinja |
We're done with PRs for now. sofar mentioned that he's be willing to host a mumble server if we wanted to use it for future meetings. What are your thoughts on that? |
| 19:08 |
paramat |
even if it doesn't affect artificial light, i think it needs to be in shaders and optional |
| 19:08 |
paramat |
eh? i was just getting into this |
| 19:09 |
nore |
well, we need to change lightbanks meaning, but if we do so, it would be easy to set sunlight color as a texture to fetch from so it would be easy to make it optional, just change the texture |
| 19:09 |
sofar |
we should keep it to an hour, I need to pack boxes and feed kids atm |
| 19:09 |
paramat |
IRC is fine, why use elsewhere |
| 19:10 |
nore |
I don't really want to use voice if possible, but I can put up with it if needed |
| 19:10 |
sofar |
voice chat may help to keep the pace up, but, everyone should be OK with it |
| 19:10 |
sofar |
so, irc is ok for now |
| 19:11 |
celeron55 |
some of us (like me) aren't native english speakers; it would probably just slow things down |
| 19:11 |
nerzhul |
except if you want to hear my french english accent i prefer IRC :p |
| 19:11 |
paramat |
voice chat =/ pace up is the problem, writing helps with thought |
| 19:11 |
celeron55 |
i and nerzhul would slow it to a standstill trying to say words 8) |
| 19:11 |
paramat |
IRC has logs too |
| 19:11 |
ShadowNinja |
Voice would probably be faster, but not everyone's comfortable with it and we have non-native speakers, so I think we should pass on that. |
| 19:12 |
nore |
same as celeron55 & nerzhul, I have a problem of parsing what others say as well when speaking, it's easier when written :) |
| 19:12 |
sofar |
alright then |
| 19:12 |
nore |
hmmm maybe try to find a time for the minetest_game meeting |
| 19:12 |
nerzhul |
can we finish the remaining points ? |
| 19:13 |
sofar |
I have to leave |
| 19:13 |
nerzhul |
if we don't sofar will be ate by his kids |
| 19:13 |
ShadowNinja |
Next: C++11? It's supported by basically everything now and we already use some of its features. |
| 19:13 |
nore |
there are less devs active for it though (sofar, paramat, sfan5 and myself I guess?) |
| 19:13 |
nerzhul |
ShadowNinja, you forgot #5451 |
| 19:13 |
paramat |
(i wouldn't participate in voice chat anyway :] too shy) |
| 19:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/5451 -- Rename doc/*.txt to *.md. by ensonic |
| 19:13 |
celeron55 |
to me, 3299 is fine in concept but it needs code review AND i want to take an artistic look about it as i've kind of designed the sunrise/sunset stuff |
| 19:14 |
ShadowNinja |
nerzhul: Oh, you're right. We'll do that right after C++11. |
| 19:14 |
celeron55 |
or, i mean, not really code review but an optimization review |
| 19:15 |
nore |
celeron55: you can test the rebased version if you want, but anyway, maybe changing light banks meaning first would be good |
| 19:15 |
nore |
it would fix a lot of problems as well |
| 19:15 |
nerzhul |
for C++11 it's time to switch, compilers are a little bit late, norm was released in 2011, and GCC 4.9 and Clang 3.6 have all C++11 features which can be required by minetest |
| 19:15 |
nerzhul |
the only problem i need to test is android build, which can be a problem |
| 19:15 |
nore |
note that the android build scripts seem to use GCC 4.9 now anyway |
| 19:15 |
nerzhul |
two years ago NDK didn't permit C++11 i should test with last NDK |
| 19:16 |
ShadowNinja |
Any objections to switching to C++11? |
| 19:16 |
nerzhul |
nore the problem is not GCC for android but NDK |
| 19:16 |
nore |
nerzhul: oh, ok |
| 19:16 |
celeron55 |
can we try disabling non-C++11 compilers and just seeing how many complaints we get, before actually starting to use C++11? |
| 19:16 |
celeron55 |
like, a week |
| 19:16 |
nerzhul |
no no, wait for release :) |
| 19:17 |
nerzhul |
Debian 8 doesn't have C++11 compiler |
| 19:17 |
nerzhul |
after release, Debian 9 will release (on August or September) with a C++14 compiler |
| 19:17 |
nore |
hmmm, maybe wait until that time then |
| 19:17 |
nerzhul |
nore, for NDK, some stdlib parts was missing on my last test in Android |
| 19:18 |
nerzhul |
but two years ago on Android 4.1 :p |
| 19:19 |
ShadowNinja |
O.K. I guess we'll delay it for Debian 9. |
| 19:19 |
nore |
but I'm for switching to C++11 as soon as it is released |
| 19:19 |
nerzhul |
everybody is okay for switching to C++11 after MT release ? |
| 19:19 |
nerzhul |
(June) |
| 19:19 |
celeron55 |
can we all agree debian isn't really doing any benefit to open source projects by being like that when closed source projects have been using C++11 since 2011 |
| 19:19 |
ShadowNinja |
I have to go now, so I'll let celeron55 take over. #5451 is next. |
| 19:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/5451 -- Rename doc/*.txt to *.md. by ensonic |
| 19:20 |
nerzhul |
see you ShadowNinja :) maybe have a shortest list next time |
| 19:20 |
nerzhul |
celeron55, nore okay for that after 0.4.16 ? |
| 19:20 |
nore |
nerzhul: ok for me |
| 19:21 |
paramat |
can't judge but no objection |
| 19:21 |
nerzhul |
paramat, constexpr can benefit on your code parts in client :) |
| 19:21 |
nerzhul |
or lambdas |
| 19:21 |
celeron55 |
ok for me at whatever point debian 9 is released; i don't think that is set in stone |
| 19:22 |
paramat |
5451 next? weird order :] |
| 19:22 |
nerzhul |
yeah #5451 |
| 19:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/5451 -- Rename doc/*.txt to *.md. by ensonic |
| 19:22 |
nore |
hmm, both are fine with me for 5451 |
| 19:22 |
nerzhul |
in CSM we started to wrote it using md, because it was new and permit to have only documentation on github |
| 19:23 |
nerzhul |
md are easily readable on vim (with support md syntax) if needed |
| 19:23 |
kilbith |
it's too fancy (tm) |
| 19:23 |
celeron55 |
do we think windows users need to be able to read the README without extra software or not? |
| 19:24 |
paramat |
hard on the eyes for me, and can't link to single lines |
| 19:24 |
celeron55 |
the issue is, regular windows is quite handicapped with almost everything |
| 19:24 |
nerzhul |
windows user doesn't use console, in notepad++ it's supported too, and in some IDE too (like clion and VS with a plugin) |
| 19:24 |
celeron55 |
yeah i mean we have users that aren't developers, have you noticed |
| 19:25 |
nerzhul |
will a non developper read a lua developper API ? |
| 19:25 |
paramat |
client lua api should have been .txt for consistency |
| 19:25 |
celeron55 |
wait, this doesn't touch README |
| 19:25 |
celeron55 |
it's ok to me then, lol |
| 19:27 |
paramat |
the MD formatting of he docs needs improving |
| 19:27 |
paramat |
*the |
| 19:27 |
nore |
hmmm, I must go now, but I don't think there's anything left to discuss anyway |
| 19:28 |
nerzhul |
seems we don't have any consensus :) |
| 19:28 |
nore |
(I meant except that and I'm neutral on it :p) |
| 19:29 |
Calinou |
celeron55: I don't think our userbase is even knowledgeable enough to open a README :/ |
| 19:29 |
Calinou |
I don't think they need to read it anyway |
| 19:29 |
paramat |
Krock has issues with it too |
| 19:29 |
Calinou |
it's mostly information about compiling |
| 19:31 |
celeron55 |
maybe there should be a second readme that would be used in compiled windows packages |
| 19:33 |
celeron55 |
so does anyone actually object 5451? |
| 19:37 |
nerzhul |
not really in both cases |
| 19:39 |
celeron55 |
we're leaving it hanging around collecting better ideas then i guess |
| 19:39 |
nerzhul |
yes |
| 19:39 |
Calinou |
most people don't read READMEs anyway (except really curious people like me :P) |
| 19:40 |
nerzhul |
for the last point, clang-format just delay it on next meeting when more users will be present |
| 19:40 |
Calinou |
if we have official Windows installers ready for prime-time, we can show an information window, this is very easy to do |
| 19:40 |
Calinou |
(why do we still lack installers? .zip for Windows should be the secondary installation option for portable uses, definitely not the primary one) |
| 19:40 |
Calinou |
like… most software today |
| 19:41 |
nerzhul |
celeron55, can you review #4664 i rebased it :) |
| 19:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul |
| 19:41 |
nerzhul |
(and tested it) |
| 19:45 |
celeron55 |
do we translate any server chat messages? |
| 19:45 |
nerzhul |
it depends |
| 19:45 |
nerzhul |
with the chat protocol i'm designing it can be possible more easily |
| 19:45 |
nerzhul |
as we have a proper distinct between chat, announces, system messages and raw messages |
| 19:46 |
nerzhul |
then announce and system can be catched by gettext to be translated :) |
| 19:46 |
celeron55 |
but currently? |
| 19:46 |
nerzhul |
no |
| 19:46 |
paramat |
i object 5451 i thought that's obvious |
| 19:46 |
nerzhul |
the only server message which are translated are standard denied messages (not custom) |
| 19:46 |
celeron55 |
paramat: yeah i forgot to acknowledge that |
| 19:47 |
paramat |
:] |
| 19:47 |
paramat |
Krock too :] |
| 19:49 |
nerzhul |
i updated http://wiki.minetest.net/Database_backends with postgresql, 1 year after merging not too late :p |
| 19:50 |
Calinou |
(updated page, added a missing "s") |
| 19:51 |
|
Sokomine_ joined #minetest-dev |
| 19:53 |
celeron55 |
nerzhul: does /shutdown -1 cancel a shutdown? |
| 19:54 |
celeron55 |
it doesn't really handle that very well; i think it says "<name> shuts down server" and cancels the shutdown 8) |
| 19:54 |
celeron55 |
and is not documented in params |
| 19:55 |
celeron55 |
wait, no, it says nothing |
| 19:55 |
celeron55 |
should be in params as it's a useful feature |
| 19:56 |
|
Taoki[mobile] joined #minetest-dev |
| 19:56 |
|
Sokomine joined #minetest-dev |
| 20:04 |
paramat |
Krock nerzhul any opinions/objectons (not necessarily reviews) for #5519 ? i'm considering merging it later |
| 20:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/5519 -- Sneak: Add option for old move code by paramat |
| 20:04 |
Krock |
looks like I've missed quite much here. However, I'm neutral on that pull |
| 20:05 |
paramat |
ok |
| 20:07 |
Krock |
nerzhul, can't believe that postgres wasn't added yet. What do you think about replacing http://dev.minetest.net/CMake_Options with a README link? That page is potentially quite outdated |
| 20:07 |
Krock |
and a duplicated documentation too |
| 20:12 |
|
kilbith_ joined #minetest-dev |
| 20:17 |
|
halt_ joined #minetest-dev |
| 20:32 |
nerzhul |
Krock, as we maintain readme seems lgtm to replace it with link yes |
| 20:32 |
nerzhul |
paramat, sorry i'm not sneak aware :( |
| 20:32 |
paramat |
no problem |
| 20:33 |
nerzhul |
celeron55, sorry for to be late, yes negative value cancel it, i'm adding documentaiton |
| 20:33 |
nerzhul |
and the server announce cancel is shutdown :) |
| 20:34 |
paramat |
i'll merge 5519 later if no objections |
| 20:38 |
nerzhul |
paramat, please factorize a little code with existing code |
| 20:40 |
nerzhul |
celeron55, thanks for the review, i'm waiting for travis and will merge |
| 20:42 |
paramat |
the duplication is intentional for various reasons |
| 20:43 |
nerzhul |
there is no reason to duplicate code here as it's very very similar, don't do this |
| 20:44 |
paramat |
there is |
| 20:44 |
nerzhul |
explain with good arguments ? |
| 20:45 |
paramat |
see thread comments |
| 20:46 |
paramat |
also, the code will be removed at the end of 0.4.16, a separate block of code makes it easier to remove |
| 20:46 |
celeron55 |
yeah it's explained already |
| 20:47 |
paramat |
if it was permanent i would agree with you of course |
| 20:47 |
|
kaeza joined #minetest-dev |
| 20:47 |
nerzhul |
i don't understand, it's a temporary commit which will be removed before release ? |
| 20:48 |
paramat |
at end of 0.4.16 |
| 20:49 |
paramat |
so at 0.5 |
| 20:51 |
Krock |
what about "readU8"? what does it return when the end of the stream is reached? (i.e. old server) |
| 20:52 |
Krock |
looks like it's 0, which would make it to default true, which is intended |
| 20:54 |
celeron55 |
maybe the boolean should be added as a u8 bitfield so as not to waste 7 bytes at a time for each new boolean value... |
| 20:54 |
celeron55 |
7 bits* |
| 20:55 |
Fixer |
Calinou: portable option is essential too, since a lot of people distrast installers those days (because of crapware/adware/malware included) |
| 20:55 |
Fixer |
zipped one i mean |
| 20:56 |
celeron55 |
do you know what's probably the stupidest thing ever? the way the MT client unloads mapblocks and then the server just sends all of the unloaded ones again: http://i.imgur.com/ysOslwd.png |
| 20:57 |
celeron55 |
i think the thing i'm doing next is ripping off the mapblock sending code from the farmap PR |
| 20:57 |
Krock |
>.< |
| 20:58 |
celeron55 |
i want my PR reviewed and merged though, i'm going to want to build these on top of each other |
| 20:59 |
celeron55 |
nobody dared to +1 it yet |
| 20:59 |
Krock |
same feeling on my PRs |
| 20:59 |
nerzhul |
which PR celeron55 ? |
| 20:59 |
nerzhul |
i also have the same feeling but we don't work on same parts :p |
| 20:59 |
Krock |
#5595 |
| 20:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/5595 -- Cache MapBlock data in the mesh generator thread for less stutter by celeron55 |
| 20:59 |
nerzhul |
i started to review it , as you see :p |
| 21:00 |
nerzhul |
the idea is excellent i was thinking about exactly same concept when the Fixer complains appear |
| 21:01 |
nerzhul |
celeron55, what is the cache memory usage ? i think about android build |
| 21:03 |
paramat |
i'll test 5595 |
| 21:04 |
celeron55 |
nerzhul: it quite directly depends on the view range |
| 21:04 |
celeron55 |
what range does android generally use? |
| 21:05 |
Fixer |
nerzhul: it is not a silver bullet though, you can hardly see much difference since it stutters like crazy anyway %) |
| 21:05 |
celeron55 |
at 50 the cache seems to peak at something like 8 MB |
| 21:05 |
nerzhul |
active_block_range 1 viewing_range 25 |
| 21:06 |
Fixer |
nerzhul: it kinda fixes one stutter but elefant stutters remain |
| 21:06 |
Calinou |
Fixer: it's essential but shouldn't be the promoted option |
| 21:06 |
Calinou |
it's not convenient for newbies at all |
| 21:07 |
celeron55 |
nerzhul: generally on the client the most memory hungry thing is mapblock meshes; the base mapblocks don't really use a lot of memory even if all of them were left in the cache forever |
| 21:07 |
nerzhul |
okay |
| 21:07 |
celeron55 |
well, 4kB each |
| 21:08 |
celeron55 |
wait |
| 21:08 |
celeron55 |
i mean 16kB |
| 21:11 |
celeron55 |
being a cache it does exchange memory for lessened processing though, obviously |
| 21:15 |
celeron55 |
my best guess for viewing_range=25 is 3 MB |
| 21:16 |
celeron55 |
does it need to conserve memory more aggressively? |
| 21:17 |
nerzhul |
no it seems reasonable |
| 21:17 |
sofar |
we hundreds of mb of ram elsewhere |
| 21:18 |
sofar |
that needs to go on a diet |
| 21:18 |
sofar |
not this :) |
| 21:19 |
nerzhul |
sofar, did you get some time ? :) |
| 21:19 |
nerzhul |
#4664 merged |
| 21:19 |
* sofar |
eats lunch, needs to run again |
| 21:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/4664 -- Implement delayed server shutdown with cancelation by nerzhul |
| 21:19 |
Fixer |
minetest 32bit has problems staying below that limit |
| 21:20 |
nerzhul |
sofar, when you get time i finished the player db backend, for using it you should use --migrate-players options in server |
| 21:20 |
celeron55 |
with large ranges it can take like 50 MB |
| 21:21 |
nerzhul |
maybe we should use sqlite3 by default on new worlds for players ? and let existing worlds migrate ? |
| 21:24 |
celeron55 |
i just flew around with a range of 320 and got the cache to 90 MB... i think i'll do something to this, it shouldn't need _that_ much in any use |
| 21:44 |
thePalindrome |
Think we could get #2727 for 0.4.16? (Just asking "can this be done without breaking things") |
| 21:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/2727 -- Sound pitch |
| 21:44 |
|
DI3HARD139 joined #minetest-dev |
| 21:45 |
nerzhul |
thePalindrome, i don't know, there are many things to finish and present in the milestone |
| 21:49 |
thePalindrome |
Alrighty, I figured, just more wondering if it would break compatability |
| 21:50 |
|
Megaf joined #minetest-dev |
| 21:50 |
nerzhul |
i don't think |
| 22:00 |
VanessaE |
celeron55: you need to tell github that your fork of minetest != the official upstream, btw |
| 22:01 |
VanessaE |
nevermind |
| 22:01 |
VanessaE |
the website's just being obscure. as usual. |
| 22:14 |
VanessaE |
anyway your PR does help some. |
| 22:18 |
|
halt_ joined #minetest-dev |
| 22:19 |
|
Grandolf joined #minetest-dev |
| 23:09 |
|
Fixer joined #minetest-dev |
| 23:11 |
nore |
#5597 |
| 23:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/5597 -- getTime refactoring by Ekdohibs |
