| Time |
Nick |
Message |
| 00:11 |
|
behaleba- joined #minetest-dev |
| 00:16 |
|
behalebabo joined #minetest-dev |
| 00:43 |
|
Megaf joined #minetest-dev |
| 00:53 |
|
ThomasMonroe joined #minetest-dev |
| 01:12 |
paramat |
lhofhansl #6483 tested, see my comment |
| 01:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/6483 -- Retrieve extra speed-directed, narrow view cone to load blocks the player will encounter soon. by lhofhansl |
| 01:18 |
lhofhansl |
Thanks. Let's leave some of the layout fixes (in unchanged code) to another PR (caching all those setting soon in a different PR anyway). |
| 01:26 |
paramat |
ok |
| 01:26 |
paramat |
go ahead then |
| 01:34 |
lhofhansl |
shortening the if-statement really harms readability. I do want the short-circuit of the if, though. I can break it up no problem at all, but are you sure that's what you're asking for. |
| 01:34 |
paramat |
don't change the logic, obviously |
| 01:35 |
paramat |
but split the long lines, unfortunately it will split in the list of arguements, but 90 is a hard rule |
| 01:36 |
paramat |
*arguments |
| 01:36 |
lhofhansl |
Will. Just making sure it's a hard rule :) |
| 01:38 |
paramat |
"Try to keep lines under 80 characters. It's okay if it goes over by a few, but 90 character lines or larger are definitely unacceptable. (note: this column count assumes 4-space indents)" |
| 01:38 |
paramat |
however you will notice much code goes over 90, but this is stuff we are slowly fixing |
| 01:38 |
lhofhansl |
I should change my tab width to 4. |
| 01:40 |
|
CalebDavis joined #minetest-dev |
| 01:48 |
paramat |
looking |
| 01:50 |
paramat |
ok nice but because 'continue' is indented by 1 tab the condition above must be indented by 2 tabs to distinguish |
| 01:50 |
paramat |
but the splitting is done very well |
| 01:51 |
paramat |
lines 274 275 one more indent |
| 01:52 |
paramat |
oh that was something i missed in earlier commits |
| 02:10 |
paramat |
i have to go eat, back in an hour |
| 02:20 |
|
twoelk left #minetest-dev |
| 03:10 |
|
paramat joined #minetest-dev |
| 03:11 |
CalebDavis |
where can i fins the builtin code for the pause menu? |
| 03:12 |
CalebDavis |
find^ |
| 03:15 |
CalebDavis |
nvmd found it |
| 03:23 |
paramat |
lhofhansl looks fine now |
| 03:31 |
lhofhansl |
Thanks :) |
| 03:34 |
|
torgdor joined #minetest-dev |
| 03:43 |
lhofhansl |
First push. Yeah. |
| 03:44 |
paramat |
good, thanks |
| 03:47 |
paramat |
lhofhansl when you merge a PR, copy the commit SHA by clicking the clipborad icon in the commit history, and paste it into a new comment in the PR thread |
| 03:47 |
paramat |
*clipboard |
| 03:49 |
paramat |
and you can close issue 1442 by commenting '6483 merged' or something |
| 04:11 |
|
AntumDeluge joined #minetest-dev |
| 05:12 |
lhofhansl |
should we reduce some of the unnecessarily wide u32/s32 in the network protocol for 0.5? (see client.cpp:writePlayerPos, where we send s32 for pitch and yaw and u32 for keyPressed, just a single bit). Won't save much, but it came up in some discussion on PRs. |
| 05:15 |
paramat |
nerzhul would be the dev to talk to about this, he *might* be around soon as it's 7am in france |
| 05:50 |
|
ADeluge joined #minetest-dev |
| 07:01 |
|
Hunterz joined #minetest-dev |
| 07:38 |
|
AntumDeluge joined #minetest-dev |
| 08:14 |
|
nerzhul joined #minetest-dev |
| 08:58 |
|
Krock joined #minetest-dev |
| 10:03 |
|
troller joined #minetest-dev |
| 10:31 |
|
Fixer joined #minetest-dev |
| 10:43 |
|
nerzhul joined #minetest-dev |
| 11:16 |
|
proller__ joined #minetest-dev |
| 11:25 |
|
proller joined #minetest-dev |
| 11:52 |
|
Fritigern joined #minetest-dev |
| 12:17 |
|
t7 joined #minetest-dev |
| 12:50 |
|
jcalve joined #minetest-dev |
| 12:50 |
|
jcalve left #minetest-dev |
| 13:42 |
|
Krock joined #minetest-dev |
| 14:37 |
|
ThomasMonroe joined #minetest-dev |
| 14:55 |
|
deltasquared joined #minetest-dev |
| 14:55 |
deltasquared |
Krock: right, so I'm not sure if there exists another PR as suggested in the one you linked for documentation, but would it be safe to consider that function stable yet? |
| 14:56 |
deltasquared |
me and VanessaE were considering using it in pipeworks. |
| 14:56 |
Krock |
so stable like getpos() which is deprecated for a long time but still available |
| 14:57 |
deltasquared |
Krock: we just didn't want it to vanish because it's not documented yet |
| 14:58 |
deltasquared |
granted, if something newer does come along pipeworks can be transferred to that, we just wanted to be sure it wouldn't vanish quitely without there being a replacement |
| 14:58 |
Krock |
just by the amount of attention it got till now may indicate that changes happen rarely to never there |
| 14:58 |
deltasquared |
hmm, so I guess we'd just have to come along and whine loudly if someone decides to take it out in future because it's "obscure" :P |
| 15:00 |
deltasquared |
Krock: would it help to open an issue on minetest on this then? to indicate we're at least intending to use it, possibly also request the relevant documentation being added |
| 15:00 |
deltasquared |
if there isn't already, going to have a look |
| 15:07 |
deltasquared |
Krock: right, there is a PR involving it, but it's quietly tucked into https://github.com/minetest/minetest/issues/6372 . would it be worth putting a comment there perhaps |
| 15:08 |
Krock |
yes, with a patch or PR it would be even better |
| 15:09 |
deltasquared |
Krock: I thought a PR would sweeten the deal ;) I'll have to catch w_laenger later, if he's the one who came up with it |
| 15:09 |
deltasquared |
patch though, can I file an issue with a patch attached? I'd prefer doing that to say forking the repository |
| 15:11 |
Krock |
why not fork it? That would open the possibility to help minetest more in the future. |
| 15:11 |
deltasquared |
Krock: I dunno, it feels like a commitment (I know it's not *actually*) |
| 15:11 |
deltasquared |
baby steps. |
| 16:02 |
|
proller__ joined #minetest-dev |
| 16:21 |
|
dzho joined #minetest-dev |
| 17:15 |
rubenwardy |
#6531 |
| 17:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/6531 -- Profiler: Fix multiple parameters not being passed to callback regist… by rubenwardy |
| 17:25 |
rubenwardy |
I'll merge in ~5 mins |
| 17:26 |
|
ThomasMonroe joined #minetest-dev |
| 17:29 |
|
AntumD joined #minetest-dev |
| 17:30 |
rubenwardy |
done |
| 18:00 |
|
BakerPrime joined #minetest-dev |
| 18:15 |
|
YuGiOhJCJ joined #minetest-dev |
| 18:18 |
|
ShadowBot joined #minetest-dev |
| 18:31 |
|
CalebDavis joined #minetest-dev |
| 18:32 |
|
Fixer joined #minetest-dev |
| 18:33 |
|
Krock joined #minetest-dev |
| 18:50 |
|
paramat joined #minetest-dev |
| 18:54 |
|
Warr1024 joined #minetest-dev |
| 18:56 |
|
Warr1024 joined #minetest-dev |
| 18:59 |
exio4 |
is there anybody working #6511? I might try to tackle it if nobody minds :) |
| 18:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/6511 -- Unknown items may be crafted |
| 19:01 |
red-001 |
feel free to |
| 19:02 |
|
torgdor joined #minetest-dev |
| 19:03 |
red-001 |
it shouldn't be too hard to implement |
| 19:04 |
exio4 |
yeah, looking for small issues, on an intel atom n2600 right now, heh |
| 19:04 |
paramat |
i don't know of anyone working on that |
| 19:15 |
sfan5 |
paramat: is it planned to add biome-specific grass colors to mtg at some point? |
| 19:15 |
|
Krock joined #minetest-dev |
| 19:17 |
|
AntumDeluge joined #minetest-dev |
| 19:18 |
paramat |
we can easily have a different surface node per biome, and almost do already, new surface nodes for temperate coniferous forest and deciduous forest are intended. but hardware colouring, no i'm strongly opposed, there's no advantage for just a few colours |
| 19:19 |
paramat |
so hopefully soon every biome will have a unique surface node |
| 19:20 |
paramat |
there's an issue somewhere for MC type smooth colouring |
| 19:20 |
paramat |
#6441 |
| 19:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/6441 -- Per-biome grass and foliage colors, using hardware coloring |
| 19:21 |
paramat |
that explains my thoughts |
| 19:22 |
paramat |
something for a separate new biome system written by someone else, i won't work on it or maintain it |
| 19:23 |
paramat |
and probably best used in a new fancier subgame, which we need anyway |
| 19:27 |
|
Warr1024 joined #minetest-dev |
| 19:27 |
|
twoelk joined #minetest-dev |
| 19:30 |
sfan5 |
oh right I should have looked on the issue tracker first |
| 19:30 |
lisac |
hey paramat, what program is that in the screenshot? |
| 19:30 |
sfan5 |
also i was asking about hardware coloring, not actual different nodes |
| 19:32 |
red-001 |
yeah what program is that |
| 19:33 |
sfan5 |
lisac: looks like GeoGebra to me (the geometry version) |
| 19:40 |
paramat |
correct |
| 19:41 |
paramat |
i inverted the colours to save my eyes |
| 19:42 |
paramat |
realtime voronoi cell adjustment, essential for choosing biome points |
| 20:01 |
lisac |
oh, nice |
| 20:16 |
red-001 |
strings in settings are utf-8 encoded right? |
| 20:33 |
|
ssieb joined #minetest-dev |
| 20:39 |
|
nerzhul joined #minetest-dev |
| 21:13 |
|
lhofhansl joined #minetest-dev |
| 21:14 |
lhofhansl |
going to merge #6530 in a few. |
| 21:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/6530 -- Cache server config settings. by lhofhansl |
| 21:17 |
red-001 |
lhofhansl, could you rename the commit/pr to indicate it also includes unrelated code style fixes? |
| 21:26 |
nerzhul |
lhofhansl, i don't like the approach where settings are dup in each remoteclient object :( |
| 21:28 |
Krock |
^ but it's already an improvement |
| 21:34 |
|
CalebDavis joined #minetest-dev |
| 21:43 |
|
BakerPrime joined #minetest-dev |
| 21:58 |
lhofhansl |
I will not merge then. |
| 22:01 |
lhofhansl |
Well... on the other hand I cannot think of anything better |
| 22:03 |
lhofhansl |
So I'd like to merge anyway. |
| 22:06 |
sfan5 |
maybe nrz does have a better idea since he's the one not liking the approach |
| 22:25 |
|
GreenDimond joined #minetest-dev |
| 22:38 |
paramat |
thanks for the floats stuff |
| 22:41 |
paramat |
is there any advantage in caching in a constructor as opposed to using 'const static setting = g_settings->get..' ? |
| 22:41 |
paramat |
sometimes i wonder which to use |
| 22:42 |
red-001 |
not really just looks cleaner |
| 22:42 |
sfan5 |
the latter will cache when the function is first called AFAIK |
| 22:42 |
red-001 |
there is an advantage for more complex data |
| 22:42 |
red-001 |
of being faster |
| 22:45 |
lhofhansl |
can't do statics. These settings can be changed without restarting the executable (Singleplay or Local Game). That static would not be reloaded. |
| 22:58 |
paramat |
oops of course |
| 22:59 |
paramat |
actually no |
| 23:00 |
paramat |
these settings are ones that don't need to be changed during a game session |
| 23:00 |
paramat |
we have many settings that need a program restart to alter, they are made static for performance reasons |
| 23:01 |
paramat |
and we can always use 'thread_local' to be able to change them in main menu |
| 23:01 |
paramat |
but still, no problem as either method is ok |
| 23:08 |
Hijiri |
what format are floating points transmitted in? |
| 23:09 |
Hijiri |
it's no longer number / 1000 integers right? |
| 23:09 |
sfan5 |
it still is |
| 23:11 |
lhofhansl |
yes, they do not need to change. I can start MT, play a SinglePlayer game, now these are all cached. Then I go to settings (not leaving MT) change the setting and do another SinglePlayer game, that would still see the old settings. (same for Local Game) |
| 23:12 |
lhofhansl |
Somebody who has since left MT (forgot the name) has "yelled" about not doing this. And I agree. |
| 23:15 |
rubenwardy |
hmmmm |
| 23:25 |
|
Megaf joined #minetest-dev |
| 23:38 |
lhofhansl |
yes ;) |
