| Time |
Nick |
Message |
| 00:41 |
|
Alias joined #minetest-dev |
| 03:20 |
|
nrz joined #minetest-dev |
| 07:37 |
|
Alias joined #minetest-dev |
| 08:00 |
|
specing_ joined #minetest-dev |
| 08:11 |
|
tech_exorcist joined #minetest-dev |
| 08:22 |
|
hlqkj[m]_ joined #minetest-dev |
| 08:52 |
|
Fixer joined #minetest-dev |
| 10:03 |
|
calcul0n__ joined #minetest-dev |
| 10:54 |
|
entuland joined #minetest-dev |
| 10:54 |
|
Fixer_ joined #minetest-dev |
| 13:08 |
|
entuland_ joined #minetest-dev |
| 13:16 |
|
specing_ joined #minetest-dev |
| 13:54 |
|
freshreplicant[m joined #minetest-dev |
| 14:21 |
|
nrz joined #minetest-dev |
| 14:22 |
|
whosit joined #minetest-dev |
| 14:29 |
|
calcul0n_ joined #minetest-dev |
| 14:29 |
|
whosit joined #minetest-dev |
| 14:32 |
MTDiscord |
<josiah_wi> I tried fixing the Irrlicht path for the CI in my PR, but it's still not working. I don't know how I should debug issues on an OS I don't use with the CI log as my only tool... |
| 14:32 |
MTDiscord |
<josiah_wi> If someone were willing to test it locally that might help a lot. |
| 14:32 |
MTDiscord |
<josiah_wi> Then again, this is probably a CI specific issue. |
| 14:35 |
sfan5 |
you should be able to recreate this situation by keeping the irrlicht installation in a folder instead of system-wide |
| 14:36 |
MTDiscord |
<josiah_wi> I've done that in Linux and it works. |
| 14:36 |
sfan5 |
how? |
| 14:36 |
MTDiscord |
<josiah_wi> My Irrlicht installation isn't system wide, it's in my ~/.local folder. |
| 14:37 |
sfan5 |
with DCMAKE_PREFIX_PATH? |
| 14:37 |
MTDiscord |
<josiah_wi> Yes, it searches that path in the find_package routine and finds everything without difficulty. |
| 14:38 |
MTDiscord |
<josiah_wi> I looked at the paths to the Irrlicht installation on the CI, and it looked like the paths were typical for an installation, it was just prefixed in $libdir. |
| 14:38 |
MTDiscord |
<josiah_wi> But setting the prefix path to $libdir didn't change anything. |
| 14:39 |
sfan5 |
I'd expect cmake to look under ${CMAKE_PREFIX_PATH}/lib/cmake |
| 14:39 |
sfan5 |
but not under ${CMAKE_PREFIX_PATH}/irrlicht/lib/cmake (how is it supposed to know?) |
| 14:40 |
MTDiscord |
<josiah_wi> You're right, I have the wrong prefix, it should be $libdir/irrlicht. |
| 14:41 |
MTDiscord |
<josiah_wi> Thank you for the help. |
| 14:46 |
MTDiscord |
<josiah_wi> sfan5, it found it, and it says the build is faulty. The Targets file expects an IrrlichtMt.dll that doesn't exist. |
| 14:46 |
sfan5 |
in lib perchance? |
| 14:46 |
sfan5 |
IIRC my scripts move it to bin |
| 14:46 |
MTDiscord |
<josiah_wi> Yeah that's probably it. |
| 14:46 |
sfan5 |
you can try moving it back |
| 14:47 |
MTDiscord |
<josiah_wi> How do I do that? |
| 14:48 |
sfan5 |
at some point after extracting mv $libdir/irrlicht/{bin,lib}/IrrlichtMt.dll |
| 14:48 |
MTDiscord |
<josiah_wi> Ok, got it. |
| 14:56 |
|
whosit joined #minetest-dev |
| 15:01 |
MTDiscord |
<josiah_wi> The Prometheus build with Clang 9 is failing to find Irrlicht. Is there anything special about that build different from the other Clang/GCC builds that I should know about? |
| 15:10 |
MTDiscord |
<josiah_wi> It builds with the old Irrlicht and doesn't set an IRRLICHT_INCLUDE_DIR. |
| 15:36 |
MTDiscord |
<josiah_wi> Is the CodeQL build something I need to fix too? |
| 15:37 |
MTDiscord |
<josiah_wi> I got docker working, Prometheus will be difficult with the old Irrlicht and Mingw has a linker error about zlib. :-| |
| 15:37 |
|
Extex joined #minetest-dev |
| 15:45 |
sfan5 |
uh |
| 15:45 |
sfan5 |
it doesn't need to link to zlib, libpng or libjpeg (as needed by Irrlicht) why is it doing that? |
| 16:20 |
|
MTDiscord2 joined #minetest-dev |
| 16:22 |
MTDiscord |
<exe_virus> Would it be possible to have our .gitignore updated to ignore the visual studio build files? Just the common ones in the folder .vs and the debug files .pdb |
| 16:26 |
|
Krock_ joined #minetest-dev |
| 16:32 |
MTDiscord |
<josiah_wi> Minetest does need Zlib if I remember correctly. |
| 16:35 |
sfan5 |
yes, but it doesn't need to link the path that Irrlicht links to (which doesn't exist anyway) |
| 16:38 |
Krock |
will merge #11149 and #11307 in 10 minutes |
| 16:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/11149 -- Message for empty list output in /haspriv and /mods by Wuzzy2 |
| 16:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/11307 -- falling.lua - Fix Meshnodes Being Too Big by benrob0329 |
| 16:47 |
Krock |
merging |
| 17:16 |
|
tech_exorcist joined #minetest-dev |
| 17:55 |
MTDiscord |
<exe_virus> Oh no, I finally understand why mineclone is so slow... It's all the abms and all the global on_steps. For example, I'm looking at cartographer, which is pretty cool and nifty, but it turns out that it is using a lot of really heavy global on_steps. I think something we could look at is adding a less precise global step option. Something that has a 1 second resolution, and then maybe a 10 second resolution. Because these are all |
| 17:55 |
MTDiscord |
getting checked in a big ol linear search loop. On top of that, maybe that should be a map, instead of a linear search, so that they are sorted by increasing order. Then we could just check if the current time is past the target time for vast swaths of these global steps rather than check each individually |
| 17:56 |
nrz |
abm are nice, but if you over use ABM yep it's slow |
| 17:57 |
MTDiscord |
<Jonathon> It would be nice if there where callbacks for common things globalsteps are used for, such as checking to see if the weild item has changed, etc |
| 18:06 |
MTDiscord |
<Jordach> this |
| 18:09 |
MTDiscord |
<exe_virus> That could also work too. I like all the suggestions haha. As for ABMs I've been thinking about adding a newer system that's more efficient than ABMs. Every time you load in a new mapblock, you pre-find all the nodes of the type of the registered "ABM". Then you just loop over that list. When a node is added or removed or a mapbock unloaded, we would remove the nodes from the list(s). Much faster, hopefully, than just linear |
| 18:09 |
MTDiscord |
searching over all mapblock, over and over and over |
| 18:10 |
MTDiscord |
<Jonathon> also, if you want abms better, merge that PR that limits heights already, as that will cut down on people that only need abms for certain heights |
| 18:10 |
sfan5 |
uhm |
| 18:11 |
MTDiscord |
<Jonathon> ^^in reply to exe_virus |
| 18:11 |
sfan5 |
if you need callbacks to run every 10s use minetest.after, it's designed to efficiently do that |
| 18:12 |
sfan5 |
as for ABMs, it would be possible to do that optimization without "adding a newer system" (assuming you mean the API would change) |
| 18:12 |
MTDiscord |
<Jonathon> https://github.com/minetest/minetest/pull/11333 |
| 18:13 |
MTDiscord |
<josiah_wi> Irrlicht doesn't have a public zlib dependeny so it shouldn't need to link it with Minetest, but maybe it's trying to for some reason!? I'll research it and figure out what's up. |
| 18:13 |
MTDiscord |
<Jonathon> minetest can lock up if you have a abm running on common nodes default:stone of default:water_source |
| 18:14 |
|
hlqkj[m]_ left #minetest-dev |
| 18:37 |
MTDiscord |
<exe_virus> API wouldn't change, just extend |
| 18:37 |
MTDiscord |
<exe_virus> Sort of like formspec v1 to v2 |
| 18:37 |
MTDiscord |
<exe_virus> This would be ABM v2 |
| 18:38 |
|
Extex joined #minetest-dev |
| 19:15 |
MTDiscord |
<exe_virus> Also, no. Minetest.after is still laughably bad for things like a 50 second timeout haha. It's implemented within minetest.globalstep() and we do a for-loop, linear search over all pending jobs. So for 49.95 seconds, we check if the time has passed for that specific check roughly 1000 times before success, on a 20 step per second server. Instead, at a 1 second or 10 second interval, it's checked only 50 or 5 times. Obviously you |
| 19:16 |
MTDiscord |
lose precision here, but boy do you skip a lot of for loops. At this point, I think we could get some low hanging fruit for minetest.after if we allowed modders so specify the precision, and the low precisions would only be checked every 1-10 seconds. |
| 19:24 |
sfan5 |
not true |
| 19:24 |
sfan5 |
the queue is only iterated if at least one job expires |
| 19:25 |
|
Extex joined #minetest-dev |
| 19:25 |
MTDiscord |
<exe_virus> ? The function is a register global step. It counts stone every step. It looks through every job in the list for timeout, every globalstep |
| 19:25 |
sfan5 |
no it does not |
| 19:25 |
sfan5 |
read the code |
| 19:26 |
sfan5 |
(this was changed in 2019) |
| 19:26 |
MTDiscord |
<exe_virus> Builtin/common/after.lua |
| 19:26 |
sfan5 |
https://github.com/minetest/minetest/blob/master/builtin/common/after.lua#L8-L10 yes |
| 19:26 |
MTDiscord |
<exe_virus> Lines 7-27 |
| 19:26 |
celeron55 |
look what time_next is used for |
| 19:26 |
MTDiscord |
<exe_virus> The timenext? |
| 19:27 |
sfan5 |
yea |
| 19:27 |
sfan5 |
it's the earliest moment a job can expire |
| 19:27 |
celeron55 |
i'm surprised it's been optimized that nicely |
| 19:27 |
sfan5 |
anyway this should be improved by keeping a time-sorted queue of jobs |
| 19:27 |
sfan5 |
no need for any weird workaround with precision |
| 19:28 |
MTDiscord |
<exe_virus> So on the next count, we extend job next to the next possible time? |
| 19:28 |
sfan5 |
yes |
| 19:28 |
MTDiscord |
<exe_virus> Understood. Sorry I missed that. |
| 19:28 |
MTDiscord |
<exe_virus> Still see the value in a slower globalstep, there's lots of those used in lots of code |
| 19:29 |
MTDiscord |
<exe_virus> But yes minetest.after rocks |
| 19:29 |
MTDiscord |
<exe_virus> Lol |
| 19:29 |
sfan5 |
I wonder why minetest.after wasn't written as a time-sorted queue in the first place, it would've been easy |
| 19:30 |
MTDiscord |
<exe_virus> Most of our coders aren't the best, myself included |
| 19:31 |
MTDiscord |
<exe_virus> Also, why do we use a tracked time? Couldn't we get by with a actual time value instead of counting based on dtime? |
| 19:31 |
MTDiscord |
<exe_virus> Or also? |
| 19:31 |
MTDiscord |
<exe_virus> So that for most global steps, we can just use either the provided dtime or the provided clock time. |
| 19:31 |
sfan5 |
the game needs to freeze if paused |
| 19:31 |
sfan5 |
what advantage would wall time have? |
| 19:32 |
MTDiscord |
<exe_virus> Not wall time, game time my bad |
| 19:32 |
MTDiscord |
<exe_virus> Basically do the time=dtime+time for all mods |
| 19:32 |
sfan5 |
oh I misunderstood |
| 19:32 |
MTDiscord |
<exe_virus> Cause I see that In nearly all the global step functions |
| 19:32 |
sfan5 |
but still doesn't make sense to me |
| 19:33 |
MTDiscord |
<exe_virus> Like, on first go, you set time=current game time |
| 19:33 |
MTDiscord |
<exe_virus> Then do comparisons based on current_game time from then on |
| 19:33 |
MTDiscord |
<exe_virus> So you don't have to do time=time+dtime in each Lua side globalstep |
| 19:34 |
MTDiscord |
<exe_virus> All the .after functions would be add current_game_time to their timeout |
| 19:35 |
sfan5 |
right |
| 19:35 |
MTDiscord |
<exe_virus> And the list would all do math according to current_game_time rather than compared to our given global step's tracked "time" value |
| 19:35 |
sfan5 |
but adding two integers surely isn't the bottleneck |
| 19:35 |
MTDiscord |
<exe_virus> Never the bottleneck |
| 19:35 |
MTDiscord |
<exe_virus> But 1-2% gains add up |
| 19:36 |
MTDiscord |
<exe_virus> And also help you find the bottleneck rather quuckly |
| 19:36 |
MTDiscord |
<exe_virus> Besides ABMs, which I still think I'll put the time into making a v2 of, what are mt's biggest CPU wasters? |
| 19:40 |
sfan5 |
dunno |
| 19:40 |
sfan5 |
try the profiler |
| 19:40 |
sfan5 |
(the server one, not the lua one) |
| 19:44 |
MTDiscord |
<exe_virus> Kk, that'll have to wait till I'm not in the boonies and not on a 2006 laptop haha |
| 19:45 |
MTDiscord |
<exe_virus> This optimization push only came up today because I'm using it and some mod somewhere is using waaayyy to much CPU, and it's either ABMs or global steps..... |
| 19:47 |
|
v-rob joined #minetest-dev |
| 19:54 |
Calinou |
HotSpot can be used to profile binaries on Linux |
| 19:54 |
Calinou |
just make sure the binary you're running contains debug symbols, and it should work out of the box |
| 19:55 |
MTDiscord |
<exe_virus> Yeah I do dev work on windows, but I can switch to Linux for perf testing |
| 19:56 |
MTDiscord |
<exe_virus> I did find the issue. It's the fragmented, harddisk drive for mapblock saves on old ram |
| 19:56 |
MTDiscord |
<exe_virus> That's most of what I'm experiencing sadly |
| 20:01 |
|
specing_ joined #minetest-dev |
| 20:03 |
MTDiscord |
<exe_virus> Perhaps we could make a slider for the settings screen to adjust general default distance of minetest? It's currently at 190 from 100 as of late 2020, which I understand as a default increase, but is an issue for my eventual retail box distribution. I'll have to come up with a simple low, medium low, medium, medium high, high, and ultra settings set for the user to pick. We have a LOT of settings... |
| 20:09 |
MTDiscord |
<exe_virus> Ah, and I see we add a few more operations onto different threads since 5.3. while useful in most cases, this is a dual core. So the mapgen actually gets push down in the priority list in single player and only comes up for air occasionally |
| 20:11 |
|
wsor4035 joined #minetest-dev |
| 21:25 |
|
v-rob joined #minetest-dev |
| 22:40 |
|
tech_exorcist joined #minetest-dev |
| 23:21 |
|
three joined #minetest-dev |
