| Time |
Nick |
Message |
| 01:04 |
|
sfan5 joined #minetest-dev |
| 01:49 |
|
Sokomine joined #minetest-dev |
| 02:02 |
|
Sokomine_ joined #minetest-dev |
| 02:52 |
|
Sokomine joined #minetest-dev |
| 03:27 |
|
lhofhansl joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:57 |
|
Taoki joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:28 |
|
calcul0n joined #minetest-dev |
| 09:23 |
zughy[m] |
chiming in just to say you're all doing an amazing job :) |
| 09:44 |
MTDiscord |
<appguru> yeah |
| 09:44 |
MTDiscord |
<appguru> can we talk about bones for a minute? |
| 10:41 |
|
absurb joined #minetest-dev |
| 10:43 |
MTDiscord |
<appguru> game#2745 is ready for merge |
| 10:43 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2745 -- Redo player_api by appgurueu |
| 11:29 |
|
_Zaizen_[m] joined #minetest-dev |
| 11:30 |
|
Benrob0329[m] joined #minetest-dev |
| 11:34 |
|
Fixer joined #minetest-dev |
| 11:34 |
|
kb1000 joined #minetest-dev |
| 11:35 |
|
nathanfranke[m] joined #minetest-dev |
| 11:35 |
pgimeno |
wow, camera offset is gone?! that was fast |
| 11:40 |
|
zughy[m] joined #minetest-dev |
| 11:40 |
|
LoneWolfHT joined #minetest-dev |
| 11:42 |
|
celeron55[m] joined #minetest-dev |
| 11:43 |
|
Kimapr[m] joined #minetest-dev |
| 12:09 |
pgimeno |
ugh, no, it's not gone, it's just how to apply it to the meshed blocks that has changed :( |
| 12:10 |
pgimeno |
that was a huge WTF, so that's good, but the problem of having the camera offset everywhere in the code is still there |
| 12:21 |
Krock |
without it, the tiles end up distorted like in minecraft |
| 14:21 |
|
proller joined #minetest-dev |
| 14:51 |
pgimeno |
I know what the problem was, what I say is that the solution is bad. Instead of stepping in discrete amounts every 200 m, it should be continuous, and not affect so many areas of the code. |
| 15:00 |
|
olliy joined #minetest-dev |
| 15:07 |
sfan5 |
<sfan5> Krock: do you think TOCLIENT_NODEMETA_CHANGED should be on channel 2? I can make a commit if you agree. |
| 15:07 |
sfan5 |
<sfan5> current ones for reference: https://github.com/minetest/minetest/blob/master/src/network/serveropcodes.cpp#L215 |
| 15:08 |
Krock |
should be the same as formspec events |
| 15:08 |
Krock |
thank you for pointing out your message. I'll increase the ZNC scrollback setting now |
| 15:09 |
Krock |
considering that hecks is spreading all channels anyway, it might be better to do such a change in their PR |
| 15:25 |
sfan5 |
true |
| 15:32 |
|
absurb joined #minetest-dev |
| 15:33 |
|
vesper11 joined #minetest-dev |
| 15:35 |
MTDiscord |
<appguru> serializeString became serializeString32 and serializeLongString became serializeJsonString? |
| 15:36 |
MTDiscord |
<appguru> nvm |
| 15:38 |
|
Calinou joined #minetest-dev |
| 16:41 |
|
lisac joined #minetest-dev |
| 17:02 |
|
proller joined #minetest-dev |
| 18:03 |
|
kilbith joined #minetest-dev |
| 18:20 |
|
kilbith joined #minetest-dev |
| 19:23 |
MTDiscord |
<wwar> Hey sfan |
| 19:23 |
MTDiscord |
<wwar> U were the cool guy who made the worldedit right? |
| 19:23 |
sfan5 |
I am |
| 19:24 |
MTDiscord |
<wwar> Can u add more cmds like //lua minetest.chat? |
| 19:25 |
MTDiscord |
<wwar> Like //lua minetest.status_add("") |
| 19:25 |
sfan5 |
no idea what those are supposed to do, it is not worldedit's job to extend Minetest's API either |
| 19:25 |
MTDiscord |
<wwar> Can be useful to add the admin name when they want to leave, that will ignore alot of griefers from griefing |
| 19:25 |
sfan5 |
and this isn't the right place to discuss this |
| 19:25 |
MTDiscord |
<wwar> Oh ok |
| 21:51 |
|
hecks joined #minetest-dev |
| 22:06 |
|
lhofhansl joined #minetest-dev |
| 22:56 |
lhofhansl |
Hi all. If you feel inclined have a look at #10703. |
| 22:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/10703 -- DISCUSS: Streamline distance configuration |
| 22:57 |
hecks |
okay so |
| 22:57 |
lhofhansl |
In the past weeks I have been trying to increase various default limit of MT for more high end machines. |
| 22:57 |
hecks |
I think trying to wrangle all those settings in a sane way is a fool's errand |
| 22:57 |
lhofhansl |
What would you propose instead? |
| 22:57 |
hecks |
I don't have a concrete proposal yet but |
| 22:57 |
lhofhansl |
Right now it sucks and nobody understand unless you looks at the code or read the documentation. |
| 22:58 |
hecks |
the very fact that those settings exist means that our block "state machine" or however you call it isn't neatly designed |
| 22:58 |
lhofhansl |
Look at Minecraft, you drag a viewing range slider and off you go. |
| 22:58 |
hecks |
exactly |
| 22:58 |
hecks |
because all the other stuff should be downstream from the vision range |
| 22:58 |
lhofhansl |
This does this.. It's set the client viewing_range and server distance settings so that it all works together. |
| 22:59 |
lhofhansl |
Cannot force the client viewing_range to a remote server, though. |
| 22:59 |
lhofhansl |
The reverse is possible. |
| 22:59 |
hecks |
It should basically be the min of both |
| 22:59 |
hecks |
but |
| 23:00 |
hecks |
it might be confusing when people suddenly try to hit + on a server and their vision range is capped |
| 23:00 |
lhofhansl |
It *is* capped :) The server won't send any farther data. Of course you can look at blocks farther away that you already loaded. |
| 23:01 |
hecks |
exactly, and people expect silly things like "unlimited vision range" to work that way |
| 23:01 |
lhofhansl |
This is not going to be perfect either way. At least for local games we can make it work without reading the documentation. |
| 23:01 |
hecks |
you'd probably have a few angry folks asking you why you took that (broken) mode away |
| 23:01 |
hecks |
how about |
| 23:02 |
hecks |
setting any of those things to 0 makes it "auto" |
| 23:02 |
lhofhansl |
Right. So hence my proposal: as a user pick a preset or don't. |
| 23:02 |
hecks |
and that is the default |
| 23:02 |
hecks |
and when it's auto, it's all pegged to the big ol' "distance" setting |
| 23:02 |
celeron55 |
0 = auto sounds good to me |
| 23:02 |
sfan5 |
huh? are you advocating capping client view range to what the server has? |
| 23:02 |
lhofhansl |
yeah, but that's a separate concern. |
| 23:03 |
celeron55 |
well i would leave in the "broken mode", it's quite useful |
| 23:03 |
lhofhansl |
How do you set the server's send distance (for example for a singleplayer game) without going to "all settings" and knowing exactly what to set and what these values mean. |
| 23:03 |
hecks |
as for the client's draw distance: cap +/- according to server's settings but still let the player exceed that range by holding shift and hitting those keys |
| 23:04 |
hecks |
and don't change the "unlimited" mode because oh well, someone's gonna whine about it if you do |
| 23:04 |
lhofhansl |
The part I am trying to solve is the allow a "normal" user to configure the local server's sending distance. |
| 23:04 |
celeron55 |
for on that mode allows one to see what's loaded on the client |
| 23:04 |
sfan5 |
introducing shift to override the server's setting is needlessly complicated for no reason |
| 23:04 |
celeron55 |
for one* |
| 23:05 |
hecks |
alternatively, the unlimited mode might require the debug priv |
| 23:05 |
hecks |
because it allows xraying |
| 23:05 |
lhofhansl |
I do not want to make this overly complicated. We can have a dialog, drop down, slider, etc, to set these four or five server settings, and they will be sensibly set together. |
| 23:06 |
celeron55 |
hecks: that might make sense |
| 23:06 |
hecks |
and maybe overriding the server's distance also requires debug |
| 23:06 |
sfan5 |
I still don't see the reason for taking those features away |
| 23:07 |
celeron55 |
allowing the server to set up consistent and fair gameplay isn't exactly something to try to avoid |
| 23:07 |
lhofhansl |
That's not at all what I am proposing. |
| 23:08 |
celeron55 |
but on the other hand people like MT's features |
| 23:08 |
sfan5 |
lhofhansl: yeah that wasn't regarding your suggestion |
| 23:09 |
sfan5 |
giving the server more control over view range, fog, etc. makes sense solely because games might need those features |
| 23:09 |
sfan5 |
but restricting them by default for nebulous (heh) reasons makes zero sense to me |
| 23:09 |
lhofhansl |
Maybe like with zoom the server optionally gets control of the client's viewing_range. |
| 23:09 |
lhofhansl |
But... |
| 23:10 |
lhofhansl |
I think the main issue right now that you cannot easily have a singleplayer game and adjust your viewing_range that is consistent between client and local server. |
| 23:11 |
lhofhansl |
Or as hecks says, you set your viewing_range to 0, then the client adjusts to the server setting. I'm suggesting that as well on the issue. |
| 23:11 |
hecks |
er, what? no I didn't really suggest that |
| 23:12 |
hecks |
I suggested tying all the downstream server settings to the block send distance |
| 23:12 |
lhofhansl |
err... ok. I must have misunderstood then. |
| 23:12 |
hecks |
and then capping the client's viewing range to that too |
| 23:12 |
hecks |
unless the client has debug, then allow exceeding it |
| 23:12 |
lhofhansl |
that client bit needs to be optional |
| 23:12 |
lhofhansl |
I see |
| 23:12 |
hecks |
yeah as I mentioned, some people will complain |
| 23:13 |
hecks |
but for a smooth experience for new players, some "soft" cap would make sense at least |
| 23:13 |
hecks |
which is why I also suggested the shift thing |
| 23:13 |
lhofhansl |
Agree... That part has irked me for a while. |
| 23:13 |
sfan5 |
is it really so irritating to new players that there would be limit on how much the server sends no matter how far you increase your range? |
| 23:13 |
hecks |
but as I also said, having a viewing range further than the send distance allows you to xray and that's a bit of a cheat |
| 23:14 |
lhofhansl |
sfan5: It looks bad. The horizon simply won't load. Looks like bug. |
| 23:14 |
hecks |
sfan5: it did kinda bother me at first |
| 23:14 |
lhofhansl |
But I'd like to go to how to actually set the server side settings. |
| 23:14 |
lhofhansl |
Can we address that? |
| 23:15 |
hecks |
Okay, let's handwave the client for now |
| 23:15 |
lhofhansl |
Just saying that all of this moot if you cannot actually set sensible settings. |
| 23:16 |
hecks |
so my proposal is autodetecting most things by setting them to 0 |
| 23:16 |
lhofhansl |
Instead of preset we can a have a "max viewing_range" dropdown. From there we populate the server fields. |
| 23:16 |
sfan5 |
yeah that sounds useful |
| 23:16 |
hecks |
and making block_send_range the master setting |
| 23:17 |
lhofhansl |
How do you default max_block_send_distance? |
| 23:17 |
lhofhansl |
I see. Yes. That what's I want to do! |
| 23:17 |
hecks |
10 blocks |
| 23:17 |
hecks |
half that for a "low" setting |
| 23:18 |
lhofhansl |
and need to adjust generate distance, active block distance, active object send distance, etc. |
| 23:18 |
hecks |
yup |
| 23:18 |
lhofhansl |
Hence the presets. But we can have distance settings. |
| 23:19 |
hecks |
and from generate distance, autodetect all that esoteric mapgen queue stuff |
| 23:19 |
hecks |
generate distance should *slightly* exceed the send distance |
| 23:19 |
lhofhansl |
That's a bit harder since multiple emerge thread cause subtle mapgen bugs. |
| 23:19 |
hecks |
not that |
| 23:19 |
hecks |
emerge threads are left explicit |
| 23:20 |
hecks |
but the emerge queue size stuff, that is probably the most cryptic part of the settings and it matters |
| 23:20 |
lhofhansl |
emerge queue sizes? client queue limits, etc? |
| 23:20 |
hecks |
no opinion on the client side of that |
| 23:20 |
hecks |
cause all the client does is receive, cache and mesh the blocks |
| 23:20 |
lhofhansl |
we have good defaults now, for a wide ranging scale of use cases. But yeah, we can include these in the presets. |
| 23:21 |
hecks |
ah but... you miss the point |
| 23:21 |
hecks |
our defaults aren't actually perfect, and not setting them to 0 by default defeats the whole purpose of having that |
| 23:22 |
|
turtleman joined #minetest-dev |
| 23:22 |
hecks |
by design, most of those settings shouldn't even be touched |
| 23:22 |
hecks |
but since they're distance dependent, peg them to the distance |
| 23:23 |
hecks |
if you don't do that, the task of changing the distance on your server becomes very complicated |
| 23:23 |
lhofhansl |
That's just the mechanics. What does the user actually configure, and where is it located in the UI? |
| 23:23 |
lhofhansl |
After we answer that, let's make it so. |
| 23:23 |
hecks |
Distance slider |
| 23:24 |
hecks |
Just block distance, and honestly, I wouldn't bother with a "verbal" dropdown |
| 23:24 |
hecks |
just a "default" button to snap it back |
| 23:24 |
lhofhansl |
Ok... That's easy. That's what the presets are doing, could turn it into a slider. Then we either have presets that make sense to together, or we auto-configure them. Same difference. |
| 23:24 |
lhofhansl |
But that's what I want to achieve. |
| 23:25 |
lhofhansl |
Who knows how to make a slider for the MT UI? |
| 23:26 |
hecks |
use a scrollbar element :] |
| 23:26 |
sfan5 |
yeah that's your best bet |
| 23:27 |
hecks |
I wouldn't mind some dedicated slider and intslider widgets but that's a todo |
| 23:28 |
lhofhansl |
So we are generally in agreement it seems. I happened to have called it "presets", but anything is fine, as long as the client and server are aligning their config. And this is only for singleplayer games. |
| 23:29 |
lhofhansl |
For multiplayer games we need to discuss how the client behaves and who has control over the client's viewing range. That's a different issue/PR, IMHO |
| 23:30 |
lhofhansl |
Maybe you guys can comment on 10703. |
| 23:34 |
lhofhansl |
I'll file a demo PR. Not a UI guy, and limited time, but I'd like get the discussion started. |
