| Time |
Nick |
Message |
| 00:09 |
|
est31 joined #minetest-dev |
| 00:10 |
est31 |
this is a statement by a debian packager about small point releases: https://github.com/minetest/minetest/issues/2610#issuecomment-167263938 |
| 00:11 |
est31 |
every of our releases is small point now hehe |
| 00:12 |
est31 |
this bug would highlight a case where we could do small point releases |
| 00:12 |
est31 |
but idk |
| 00:12 |
est31 |
before long calinou shows up and proposes to release all two weeks |
| 00:12 |
est31 |
bc we arent a distro |
| 00:13 |
est31 |
then other ppl show up and want us to not do any features anymore, just bugfixes |
| 00:13 |
est31 |
release discussions are always the same |
| 00:14 |
est31 |
pilzadam knows it: we talk alot, and at the end everything stays the same |
| 00:14 |
est31 |
sapier, i know find_node_near can be abused sorta yes |
| 00:15 |
est31 |
but idk limiting it feels just wrong |
| 00:15 |
est31 |
if people want sth fast and with a long radius they should use areastores |
| 00:16 |
est31 |
these scale super well |
| 00:16 |
est31 |
well, the only issue is that areastores are fully held in RAM |
| 00:16 |
est31 |
but other than that, they scale well. |
| 00:17 |
est31 |
(and one can write the extension to use disk storage as well) |
| 00:17 |
sfan5 |
does that mean we'll be considering doing a release soon-ish? |
| 00:17 |
sapier |
I didn't wanna suggest limiting it but maybe adding same check as for ABM time |
| 00:17 |
sapier |
ppl tend to not realize HOW bad it is ... myself included |
| 00:18 |
sapier |
I think I found a solution ... causing way more cpu load in total but reducing lag to < 123ms |
| 00:19 |
sapier |
well solution is a lot of code but quite simple |
| 00:20 |
sapier |
instead of checking full cube at once I split check to shell by shell base ... guess it's still gonna fail if you try to check radius 1000 ;-) but at least till 40 it's quite useable |
| 00:20 |
est31 |
doesnt it already work shell by shell |
| 00:22 |
sapier |
nope |
| 00:22 |
sapier |
shell by shell in different steps |
| 00:23 |
sapier |
current one tries to check all shells in same step |
| 00:25 |
est31 |
what is "step" for you |
| 00:25 |
sapier |
of course I had to implement this in lua and can't use the way more fast c++ functions any longer |
| 00:25 |
sapier |
serverstep |
| 00:25 |
est31 |
so why do you have to implement it in lua |
| 00:25 |
est31 |
I dont understand |
| 00:25 |
sapier |
the thing that causes lag |
| 00:26 |
est31 |
is c++ less powerful |
| 00:26 |
sapier |
in this case yes |
| 00:26 |
est31 |
why |
| 00:26 |
sapier |
because I'd need way more infrastructure to do this in c++ |
| 00:27 |
sapier |
basically I'd need ot have the lua async api as well as event handling in place |
| 00:27 |
est31 |
the async api is useless it doesnt reduce lag in any way |
| 00:27 |
est31 |
or well |
| 00:27 |
sapier |
if you use it correct it does |
| 00:28 |
est31 |
it can run while c++ runs |
| 00:28 |
est31 |
but still you need envlock |
| 00:28 |
sapier |
async api is only part of the work to be done for it to completely work |
| 00:28 |
est31 |
so whats running in minetest whats outside of envlock |
| 00:29 |
sapier |
as I said async api is only part for it to gain full benefit we need partial maplocks too |
| 00:30 |
est31 |
yeah |
| 00:30 |
sapier |
till this is done reducing lag by spliting a part to small pieces is the only way to reduce lag |
| 00:30 |
est31 |
minetest's infrastructure isnt right for changes like you propose |
| 00:30 |
sapier |
and as this is extremely specific to a particular task you can only do it in lua |
| 00:30 |
est31 |
isn't ready I mean |
| 00:31 |
est31 |
if you added it now it would just mean additional overhead without any benefit. |
| 00:31 |
est31 |
and the current async api isnt the way forward either |
| 00:31 |
est31 |
it isnt true multithreading |
| 00:32 |
est31 |
just lending out the lua global lock to some async thread |
| 00:32 |
est31 |
or is it? |
| 00:32 |
sapier |
I don't undestand your point the api itself is completely capable of doing multithreaded operation |
| 00:32 |
sapier |
everything else is implementation detail |
| 00:33 |
sapier |
imho it's better to have a clean api in place and extend it's capabilities later then having some half grown half implemented wannabe api in place |
| 00:33 |
est31 |
is the async api even available outside of mainmenu |
| 00:34 |
est31 |
i cant find it in lua_api.txt |
| 00:34 |
sapier |
no it can't be used. as I said it's never been completed |
| 00:35 |
sapier |
mainmenu was just first usage for it but I didn't continue the work ... I'd continue now but for what I remember hmmmm is already working on it so I don't wanna wast his or my time |
| 00:36 |
est31 |
I think what hmmmm wants to get in the end regarding the async api is very fine |
| 00:37 |
est31 |
i remember conversations with him |
| 00:37 |
sapier |
I believe to remember this way too yet async api to gain full benefit requires splitting the envlock ... I started that work too |
| 00:38 |
sapier |
well I added the check to find out where we need it ;-) so not very much is done by now |
| 00:38 |
est31 |
but yeah, I guess this would be something ideal for using async operation and a split up maplock |
| 00:38 |
sapier |
right now async api could only boost numbercrunching |
| 00:38 |
est31 |
(this = find_nodes_near) |
| 00:38 |
est31 |
and there isnt much numbercrunching in minetest |
| 00:39 |
sapier |
e.g. if someone wrote a mapgen capable of doing everything in it's own data and write it to map in a later step |
| 00:39 |
est31 |
yeah |
| 00:39 |
sapier |
I don't see a lot of other tasks that would benefit |
| 00:40 |
sapier |
almost everything else requires access to map |
| 00:40 |
est31 |
but there is always overhead for copying the stuff between async threads to main thread |
| 00:40 |
sapier |
true and that's something you can't avoid thus have to make it more performant |
| 00:40 |
sapier |
async thereads aren't lightweight |
| 00:40 |
sapier |
for small tasks they're useless |
| 00:41 |
est31 |
yeah |
| 00:41 |
sapier |
async is only worth if you have to do a couple of seconds of computing time |
| 00:41 |
est31 |
thats why i think its bad idea to use async api for find_node_near if the radius is smaller than, say, 10 |
| 00:41 |
est31 |
and in most cases it is just 10 or so |
| 00:41 |
sapier |
yes |
| 00:42 |
sapier |
imho a warning similar to the abm warning telling ppl what just happened would be more then enough |
| 00:42 |
est31 |
then they know where the lag comes from? |
| 00:42 |
sapier |
maybe adding another parameter to it would be worth thinking about too |
| 00:43 |
est31 |
idk, best would be pie chart or sth |
| 00:43 |
sapier |
min radius |
| 00:43 |
sapier |
thus you could check in steps |
| 00:43 |
est31 |
mhhh min radius |
| 00:43 |
sapier |
est31: there's a mod profiler in minetest you can se which mods cause lag |
| 00:43 |
est31 |
yeah sounds simple enough and useful enough |
| 00:44 |
sapier |
mod_profiling = true |
| 00:44 |
sapier |
detailed_profiling = true |
| 00:44 |
est31 |
mod profiler is cool |
| 00:44 |
est31 |
i know |
| 00:45 |
sapier |
mod profiler is one of the pieces I managed to get from mobf to core ;-) |
| 00:45 |
est31 |
<sfan5> does that mean we'll be considering doing a release soon-ish? <---- well this apoleon wanted some point release because we fixed his bug |
| 00:46 |
est31 |
point releases would be novel |
| 00:46 |
est31 |
and we would need a way to distinguish them from usual releases |
| 00:46 |
est31 |
and it would introduce problems, we'd need version branches or so |
| 00:46 |
sapier |
I've plenty of usefull pieces there yet nothing as helpfull as mod profiler :) |
| 00:47 |
est31 |
t4im greatly improved it |
| 00:47 |
est31 |
idk whether its integrated into the engine already |
| 00:47 |
sapier |
mod profiler? |
| 00:47 |
est31 |
https://github.com/t4im/profiler |
| 00:48 |
sapier |
nice why hasn't this been merged by now? |
| 00:48 |
Fixer |
can i use mod profiler on RELEASE build? |
| 00:48 |
est31 |
idk |
| 00:49 |
|
sapier1 joined #minetest-dev |
| 00:49 |
sapier1 |
Fixer: profiler is lua only so you should be able to |
| 00:50 |
Fixer |
it feels like server guys do not use it often enough, it should endorsed |
| 00:50 |
sapier1 |
actually no |
| 00:50 |
Fixer |
should be* |
| 00:50 |
sapier1 |
you shouldn't run it permanent as it causes overhead |
| 00:50 |
Fixer |
to look what things are laggy |
| 00:50 |
sapier1 |
modders should run it |
| 00:50 |
Fixer |
no, just for troubleshoot |
| 00:51 |
sapier1 |
oh yes that's what it's been meant for |
| 00:51 |
Fixer |
yeah |
| 00:51 |
sapier1 |
vanessae and myself did find a lot of issue using it |
| 00:51 |
Fixer |
I've advised people to try it to look what is lagging so badly, but I never seen actual results %) |
| 00:53 |
est31 |
it cant detect engine lag |
| 00:53 |
sapier1 |
nope but usually you do not have engine lag but mod lag |
| 00:53 |
est31 |
if a mod spawns a million rats, the overhead might not be large |
| 00:53 |
est31 |
in the profiler |
| 00:53 |
Fixer |
i mean at least mod lags |
| 00:53 |
est31 |
but the engine will have lag |
| 00:54 |
sapier1 |
actully you'd see the spawning of a million rats in profiler |
| 00:54 |
est31 |
yeah bad example |
| 00:54 |
est31 |
I should go to bed |
| 00:55 |
sapier1 |
usually you find things like the find_nodes_in issue |
| 01:00 |
sapier1 |
but still it's modders to think about how to split what they have to do to small pieces ... at least if they do have mods that do bigger things :-) |
| 01:03 |
|
sapier1 left #minetest-dev |
| 01:07 |
|
behalebabo joined #minetest-dev |
| 01:59 |
|
ElectronLibre joined #minetest-dev |
| 02:11 |
|
younishd_ joined #minetest-dev |
| 04:04 |
|
lemon joined #minetest-dev |
| 04:04 |
lemon |
hello |
| 07:22 |
|
asl97 joined #minetest-dev |
| 08:11 |
|
Hunterz joined #minetest-dev |
| 10:50 |
|
alket joined #minetest-dev |
| 11:05 |
|
sapier joined #minetest-dev |
| 11:11 |
|
Calinou joined #minetest-dev |
| 11:18 |
|
ElectronLibre joined #minetest-dev |
| 11:33 |
|
Amaz joined #minetest-dev |
| 11:37 |
|
alket joined #minetest-dev |
| 11:38 |
|
rubenwardy joined #minetest-dev |
| 11:57 |
|
Fixer joined #minetest-dev |
| 12:09 |
|
rubenwardy joined #minetest-dev |
| 12:22 |
|
ElectronLibre joined #minetest-dev |
| 13:23 |
|
Krock joined #minetest-dev |
| 13:26 |
|
younishd_ joined #minetest-dev |
| 13:40 |
|
zupoman joined #minetest-dev |
| 14:27 |
|
DFeniks joined #minetest-dev |
| 14:50 |
|
behalebabo joined #minetest-dev |
| 15:43 |
|
Amaz joined #minetest-dev |
| 15:44 |
|
zat joined #minetest-dev |
| 16:29 |
|
hmmmm joined #minetest-dev |
| 17:21 |
|
dzho joined #minetest-dev |
| 17:26 |
|
dzho joined #minetest-dev |
| 17:28 |
|
Gael-de-Sailly joined #minetest-dev |
| 18:18 |
|
Lunatrius joined #minetest-dev |
| 18:40 |
|
Amaz joined #minetest-dev |
| 19:05 |
|
nolsen joined #minetest-dev |
| 19:57 |
sofar |
I'd like to merge this (later, not just yet) into minetest_game itself: |
| 19:57 |
sofar |
https://forum.minetest.net/viewtopic.php?f=9&t=13732&p=201429#p201429 |
| 19:57 |
sofar |
would appreciate if people can comment on whether that would be something that would be mergable |
| 19:58 |
sofar |
since implementing it as a standalone mod is very cumbersome (I'd basically have to redefine lots of /doors/ code to override the handler functions) |
| 19:59 |
sofar |
and as a patch to minetest_game it's ... well tiny amounts of code, really |
| 20:05 |
|
rubenwardy joined #minetest-dev |
| 20:19 |
|
Gael-de-Sailly joined #minetest-dev |
| 20:19 |
|
rubenwardy joined #minetest-dev |
| 20:36 |
|
Siva joined #minetest-dev |
| 20:37 |
|
PenguinDad joined #minetest-dev |
| 20:50 |
|
VargaD joined #minetest-dev |
| 20:50 |
|
PenguinDad joined #minetest-dev |
| 21:33 |
sofar |
how do I edit probability values for mts files? is there an editor of some sorts? |
| 21:34 |
sfan5 |
nope |
| 21:34 |
sfan5 |
you're gonne have to jump into a hex editpr |
| 21:34 |
sofar |
vi -b? |
| 21:34 |
sfan5 |
-p |
| 21:35 |
sofar |
well that's rough |
| 21:36 |
sfan5 |
actually no that won't work |
| 21:36 |
sfan5 |
mts files contain compressed data |
| 21:36 |
sfan5 |
tl;dr it's a lot of work, don't do it unless you need to |
| 21:38 |
sofar |
well I want to add some better trees |
| 21:38 |
sofar |
so, no choice |
| 21:42 |
sofar |
you know |
| 21:43 |
sofar |
sfan5: all it needs to fix that problem is to have an in-game tool that edits node metadata and adds the probability, and a modified schematic save tool to read/convert that to the mts probability format |
| 21:44 |
kaadmy |
worldedit has schematic chances |
| 21:47 |
sofar |
euh, it's rather ... crude |
| 21:48 |
sofar |
no idea what number I'm putting in |
| 21:48 |
kaadmy |
0-255 iirc |
| 21:48 |
sofar |
0.1 ? 10? 1/10? |
| 21:49 |
kaadmy |
0-255 for chance of appearing, 255 is always, 127 is 50% |
| 21:50 |
kaadmy |
yep, checked and it's correct(from checking the code) |
| 21:50 |
kaadmy |
https://github.com/Uberi/Minetest-WorldEdit/blob/master/worldedit_commands/init.lua#L1130 |
| 21:52 |
sofar |
crashy, don't punch the wrong node :) |
| 21:59 |
kaadmy |
heh |
| 22:02 |
|
SilverLuke joined #minetest-dev |
| 22:04 |
sofar |
well either worldedit's place doesn't use it properly, or half my probabilities are lost |
| 22:04 |
sofar |
had a bunch of nodes with 75% not appear |
| 22:05 |
sofar |
placed it 3x, total 12 nodes with 75% prob, not one appeared |
| 22:05 |
kaadmy |
75%=192? |
| 22:05 |
sofar |
yeah |
| 22:05 |
kaadmy |
hmm |
| 22:06 |
sofar |
128 and 16 work ok, afaics |
| 22:07 |
sofar |
oh hey, WE calls minetest.place_schematic() |
| 22:07 |
sofar |
maybe a restart is needed |
| 22:08 |
* sofar |
not sure if he wants to fight that battle today |
| 22:09 |
sofar |
tried making normalmaps yesterday, failed at that too |
| 22:23 |
|
enesbil joined #minetest-dev |
| 23:02 |
|
zupoman joined #minetest-dev |
| 23:18 |
|
Siva_AndroIRC joined #minetest-dev |
| 23:47 |
|
Calinou joined #minetest-dev |
| 23:51 |
|
est31 joined #minetest-dev |
