| Time |
Nick |
Message |
| 00:36 |
|
amfl2 joined #luanti |
| 01:25 |
|
Can0xfBows joined #luanti |
| 04:00 |
|
MTDiscord joined #luanti |
| 05:06 |
cheapie |
Hmm... on one hand celevator is currently the biggest lag source on VE-C when no players are online (a few things are running that shouldn't be, I need to look into that), on the other hand it doesn't really matter much as the max lag is fairly consistently 26ms when no players are online now |
| 05:08 |
cheapie |
According to the built-in profiler, globalsteps are taking on average 1.6ms to process. I think that's fine. |
| 05:15 |
cheapie |
Something that would be neat - not in terms of actually making any noticeable impact, just in the "lower numbers go brrrrrrr" department - would be the ability for a mod to have the engine stop calling its registered globalstep function(s) and then resume later. Sure, said functions could just immediately return, but... think of the... microseconds(?) that could be saved by just not calling them! :P |
| 05:16 |
[MatrxMT] |
<Blockhead256> make a mod that manages other mods' globalsteps and takes them in and out :P |
| 05:18 |
* cheapie |
gets to work writing Cheapie Systems Globalstep Manager Enterprise Edition™, complete with such features as taking an entire minute to load at server start and needing a second or two on every single globalstep to figure out which ones should run |
| 05:19 |
cheapie |
FWIW this is what the profiler output looked like after letting it sit empty for a few minutes: https://gist.githubusercontent.com/cheapie/2e20a96bc8eb207195055b2f8e12aee4/raw/5944a417a7e5b2eb3210dd9ba4b6d9c340c7c6be/gistfile1.txt |
| 05:20 |
cheapie |
In celevator I think there are some low-hanging fruit sorts of optimizations in globalstep[7] and globalstep[6], while the three on_step entries are a bug somewhere (probably on my end) as none of the relevant entities should exist in the world at the moment |
| 05:51 |
cheapie |
I did the "low-hanging fruit" optimizations, among other things globalstep[6] fell from 454µs to 3µs average. Average lag with no players is now 335µs. |
| 05:57 |
MTDiscord |
<nathan4220776> Excellent. |
| 07:19 |
|
Oblomov joined #luanti |
| 07:26 |
|
Meli joined #luanti |
| 07:36 |
[MatrxMT] |
<Blockhead256> does dynamic lighting always draw it so the sun is exactly on the east-west axis, or can I tilt the sun north/south and have the dynamic lighting draw that correctly? |
| 07:37 |
[MatrxMT] |
<Blockhead256> there is a tilt setting in sky after all |
| 07:38 |
pgimeno |
I wondered the same thing |
| 07:39 |
|
cheek_pain joined #luanti |
| 07:52 |
[MatrxMT] |
<Blockhead256> The answer is yes |
| 07:52 |
[MatrxMT] |
<Blockhead256> https://forum.luanti.org/viewtopic.php?p=444380#p444380 |
| 07:53 |
[MatrxMT] |
<Blockhead256> it also pleases me that the positive numbers tilt the sun towards the north. For once, southern hemisphere is the default ! |
| 07:56 |
[MatrxMT] |
<Blockhead256> mod idea: set the player's axial tilt according to their z coordinate, so they appear in the correct 'hemisphere' |
| 07:58 |
[MatrxMT] |
<Bracket> then you should never spawn at a tundra at 0, 0, 0 |
| 07:58 |
|
alpiquero joined #luanti |
| 07:59 |
[MatrxMT] |
<Blockhead256> yes, setting the heat values for mapgen would also make sense in the same world |
| 08:18 |
|
jaca122 joined #luanti |
| 08:22 |
|
Warr1024 joined #luanti |
| 08:46 |
|
Warr1024 joined #luanti |
| 09:19 |
|
mrkubax10 joined #luanti |
| 09:34 |
|
mrkubax10 joined #luanti |
| 09:43 |
|
YuGiOhJCJ joined #luanti |
| 11:30 |
|
mrkubax10 joined #luanti |
| 11:36 |
|
ireallyhateirc joined #luanti |
| 12:11 |
|
SwissalpS joined #luanti |
| 12:26 |
|
yezgromafic joined #luanti |
| 13:10 |
|
silverwolf73828 joined #luanti |
| 13:43 |
ireallyhateirc |
btw would be nice if someone could confirm this bug https://github.com/luanti-org/luanti/issues/15643 |
| 13:44 |
ireallyhateirc |
it comes with a minimal reproducer too |
| 14:20 |
|
Leopold joined #luanti |
| 15:31 |
ireallyhateirc |
Does river/cave generation happen on a separate thread? |
| 15:32 |
[MatrxMT] |
<Blockhead256> all the mapgen happens on the one thread afaik |
| 15:35 |
MTDiscord |
<wsor4035> unless you enable multiple threads. but you dont want to due to the slice bug |
| 15:36 |
ireallyhateirc |
The thing is the bug I linked above happens with emerge thread numer == 1 |
| 15:37 |
ireallyhateirc |
and I have a mod that modifies large chunks of map with Voxel Manipulators, for example I change spring soil (light) to winter soil (dark) and mapblocks that have caves/rivers often have glitches (outdated soil) |
| 15:38 |
dzho |
sorry, I've got Debian and the 5.11 from flatpak. I did clone the reproducer repo game, checked it out to the indicated commit, but I don't see the pink blocks anywhere yet |
| 15:38 |
dzho |
(which is to say, not Guix, and not 5.10, as the bug indicates) |
| 15:39 |
ireallyhateirc |
that shouldn't make a difference |
| 15:42 |
dzho |
ok, flew around a bit more to find river rather than ocean, but still no pink |
| 15:42 |
ireallyhateirc |
I'll retest it, maybe something has changed since then |
| 15:44 |
dzho |
ok |
| 15:44 |
dzho |
not a total loss on this end, it's been a while since I dug down into the flatpak ~/.var |
| 15:45 |
|
jaca122 joined #luanti |
| 15:48 |
ireallyhateirc |
Okay, I know why you can't reproduce |
| 15:49 |
ireallyhateirc |
I need to push a branch to the repo |
| 15:54 |
ireallyhateirc |
dzho, do "git checkout transparent" |
| 15:56 |
ireallyhateirc |
I believe it needs caves enabled in mapgen for the bug to appear and with that commit I reproduced the bug again with emerge threads = 1 |
| 15:56 |
|
mrkubax10 joined #luanti |
| 15:57 |
|
mrkubax10 joined #luanti |
| 15:59 |
ireallyhateirc |
the bug is quite rare but id does happen |
| 16:01 |
dzho |
ok, got something coming up soon might not be able to get to it |
| 16:01 |
ireallyhateirc |
this is from today on the "transparent" branch https://files.catbox.moe/5zbx48.png |
| 16:02 |
dzho |
at least for a little bit. we'll see if someone shows up here on time |
| 16:02 |
ireallyhateirc |
the nodes marked with "E" are mapchunk edges |
| 16:04 |
dzho |
haha yeah I got that |
| 16:04 |
dzho |
and ... there it is |
| 16:05 |
dzho |
I am seeing pink blocks in lakebeds |
| 16:05 |
ireallyhateirc |
yeah, so basically the pink nodes are the "default" stone which is used as the fallback for mapgen |
| 16:06 |
ireallyhateirc |
but there's only one biome defined in that game with gray "base" stone |
| 16:06 |
ireallyhateirc |
so pink nodes should never be generated unless mapgen somehow fails |
| 16:07 |
dzho |
so, this is me having reproduced the bug, I take it? |
| 16:07 |
dzho |
me, us, whatever |
| 16:07 |
ireallyhateirc |
yeah, but what I really need is for core devs to make my bug report as a bug |
| 16:07 |
ireallyhateirc |
because the issue went mostly unnoticed after being posted |
| 16:08 |
ireallyhateirc |
to mark* |
| 16:12 |
ireallyhateirc |
btw it appears that the improperly generated c_stone normally goes unnoticed because it is generated one node *below* the top layer of the bottom of the ocean |
| 16:13 |
ireallyhateirc |
and also because if your game has c_stone set to "default:stone" then you won't notice a thing |
| 16:14 |
dzho |
subtle |
| 16:44 |
|
Talkless joined #luanti |
| 17:44 |
pgimeno |
@Blockhead256 thanks for the tip on the shadows, awesome |
| 19:04 |
|
mrkubax10 joined #luanti |
| 19:04 |
|
mrkubax10 joined #luanti |
| 19:11 |
|
CRISPR joined #luanti |
| 19:14 |
|
diceLibrarian2 joined #luanti |
| 19:29 |
|
diceLibrarian joined #luanti |
| 20:36 |
MTDiscord |
Command sent from Discord by luatic (formerly Grghliatic): |
| 20:36 |
MTDiscord |
!tell ireallyhateirc rereading the conversation, it sounds like your problem might not have been with set_float, but rather you passed numbers as *keys* (or had them converted to strings implicitly when concatenating)? yeah, that will tostring, and that will lose precision. (set_float will also tostring and also lose precision.) |
| 20:36 |
MinetestBot |
MTDiscord: I'll pass that on when ireallyhateirc is around |
| 20:46 |
|
diceLibrarian2 joined #luanti |
| 20:48 |
ireallyhateirc |
@luatic, yeah I used floats directly as keys but the outcome was the same when I explicitly used tostring |
| 20:48 |
MinetestBot |
ireallyhateirc: Apr-27 20:36 UTC <MTDiscord> rereading the conversation, it sounds like your problem might not have been with set_float, but rather you passed numbers as *keys* (or had them converted to strings implicitly when concatenating)? yeah, that will tostring, and that will lose precision. (set_float will also tostring and also lose precision.) |
| 20:49 |
ireallyhateirc |
thank you dear bots |
| 20:59 |
[MatrxMT] |
<Bracket> the picture about the bug looks crazy, didn't know mapgen is so customizable |
| 21:11 |
|
Verticen joined #luanti |
| 21:19 |
|
kamdard_ joined #luanti |
| 21:21 |
[MatrxMT] |
<lemon> Whoever likes networking, I did a big QUIC library analysis (see GitHub). Lots of variance when it comes to usability. OpenSSL just finished and shipped its QUIC server code, so that might be the best. Likely I'll experiment with that next. |
| 21:25 |
MTDiscord |
<wsor4035> quiche (Cloudflare) was what paradust was looking at/using |
| 21:25 |
MTDiscord |
<wsor4035> also link: https://github.com/luanti-org/luanti/issues/15261#issuecomment-2833640668 |
| 22:05 |
|
Kimapr joined #luanti |
| 22:33 |
|
panwolfram joined #luanti |
| 22:43 |
|
YuGiOhJCJ joined #luanti |
| 23:05 |
|
Eragon joined #luanti |
