| Time |
Nick |
Message |
| 00:00 |
celeron55 |
hmmmm: yes, but we have our own standards |
| 00:00 |
emptty |
0.4.6 is 3 month old, common |
| 00:49 |
|
dexter0 joined #minetest-dev |
| 01:07 |
Exio |
https://github.com/EXio4/minetest/commit/18eec3aac4d998d63e4f87e90835964846d94f8f |
| 01:07 |
Exio |
just recalled that |
| 01:11 |
|
kaeza joined #minetest-dev |
| 01:39 |
|
kaeza joined #minetest-dev |
| 03:04 |
|
ffoxin joined #minetest-dev |
| 03:12 |
|
ssieb joined #minetest-dev |
| 04:33 |
ShadowNinja |
K|ray should probably be added to that list. |
| 04:43 |
|
neko259 joined #minetest-dev |
| 05:03 |
|
emptty joined #minetest-dev |
| 05:22 |
|
ch98 left #minetest-dev |
| 06:05 |
|
kaeza joined #minetest-dev |
| 06:31 |
|
ssieb joined #minetest-dev |
| 07:02 |
|
darkrose joined #minetest-dev |
| 07:02 |
|
darkrose joined #minetest-dev |
| 07:16 |
|
emptty joined #minetest-dev |
| 07:16 |
|
Anchakor_ joined #minetest-dev |
| 08:07 |
|
emptty1 joined #minetest-dev |
| 08:29 |
|
Calinou joined #minetest-dev |
| 08:48 |
|
celeron55 joined #minetest-dev |
| 08:59 |
|
darkrose joined #minetest-dev |
| 08:59 |
|
darkrose joined #minetest-dev |
| 09:08 |
|
Anchakor_ joined #minetest-dev |
| 09:22 |
|
Anchakor joined #minetest-dev |
| 09:26 |
|
Zeg9 joined #minetest-dev |
| 09:27 |
|
Zeg9_ joined #minetest-dev |
| 09:56 |
|
emptty joined #minetest-dev |
| 10:03 |
|
proller joined #minetest-dev |
| 10:35 |
|
ImQ009 joined #minetest-dev |
| 10:41 |
|
emptty joined #minetest-dev |
| 10:51 |
|
proller joined #minetest-dev |
| 11:06 |
|
tango_ joined #minetest-dev |
| 11:35 |
|
Calinou joined #minetest-dev |
| 12:39 |
|
rubenwardy joined #minetest-dev |
| 12:57 |
rubenwardy |
http://www.yourworldoftext.com/minetest |
| 12:57 |
rubenwardy |
woops |
| 12:57 |
rubenwardy |
wrong channel :P |
| 13:03 |
|
Zeg9 joined #minetest-dev |
| 13:04 |
|
Zeg9 joined #minetest-dev |
| 13:20 |
|
emptty joined #minetest-dev |
| 14:19 |
|
Deivan joined #minetest-dev |
| 14:33 |
|
proller joined #minetest-dev |
| 15:06 |
|
hmmmm joined #minetest-dev |
| 15:08 |
|
Jordach joined #minetest-dev |
| 15:25 |
|
emptty joined #minetest-dev |
| 15:27 |
|
iqualfragile joined #minetest-dev |
| 15:41 |
|
Jordach left #minetest-dev |
| 15:42 |
|
Jordach joined #minetest-dev |
| 15:58 |
|
PilzAdam joined #minetest-dev |
| 16:00 |
|
kaeza joined #minetest-dev |
| 16:02 |
|
dexter0 joined #minetest-dev |
| 16:11 |
|
PilzAdam_ joined #minetest-dev |
| 16:15 |
|
kaeza joined #minetest-dev |
| 16:19 |
proller |
try #N: maybe merge ipv6 with fixes ? |
| 16:20 |
|
Calinou joined #minetest-dev |
| 17:18 |
|
khonkhortisan_ joined #minetest-dev |
| 17:38 |
|
ssieb joined #minetest-dev |
| 18:01 |
|
diemartin joined #minetest-dev |
| 18:09 |
|
proller joined #minetest-dev |
| 18:15 |
|
PilzAdam joined #minetest-dev |
| 18:20 |
|
neko259 joined #minetest-dev |
| 18:24 |
|
Mallot1 joined #minetest-dev |
| 18:34 |
PilzAdam |
https://github.com/PilzAdam/minetest/commit/b23d20e8ba799c60a132a7a40908fecc596f74b9 |
| 18:34 |
PilzAdam |
any objections? |
| 18:34 |
|
emptty1 joined #minetest-dev |
| 18:37 |
VanessaE |
oh G*d no, that'll break everything and send us back to the 0.2.x days in functionality ;) |
| 18:45 |
|
Mallot1 joined #minetest-dev |
| 18:45 |
Mallot1 |
i havean edit for the mob framework |
| 18:45 |
PilzAdam |
this channel is not for mods |
| 18:45 |
Mallot1 |
ok |
| 18:45 |
Mallot1 |
sorry |
| 18:46 |
Mallot1 |
can i work on the game core? |
| 18:47 |
PilzAdam |
of course you can, Minetest's sourcecode is licensed under LGPL |
| 18:47 |
Mallot1 |
ok :) |
| 18:48 |
kaeza |
PilzAdam, I have some silly idea: how about exposing hacky_swap_node as default.swap_node? |
| 18:48 |
PilzAdam |
no, hacky_sawp_node should not be used by anyone |
| 18:49 |
Taoki |
Anyone kind enough to help a fellow dev? http://forum.minetest.net/viewtopic.php?pid=95933 |
| 18:49 |
Taoki |
That code killed my mind for hours |
| 18:49 |
kaeza |
it's used at least by technic and homedecro |
| 18:49 |
kaeza |
cor* |
| 18:52 |
kaeza |
Taoki, looks like the implementation of a GUI layout manager. Maybe you can find some code on the net |
| 18:52 |
Taoki |
hmm |
| 18:54 |
kaeza |
It's not very simple in 2D, worse in 3D |
| 18:55 |
kaeza |
but since you plan on making villages with it, I'd say ignore the 3rd dimension and take the world as a flat 2D surface |
| 18:59 |
|
ffoxin joined #minetest-dev |
| 19:01 |
|
Weedy_lappy joined #minetest-dev |
| 19:03 |
Taoki |
kaeza: The calculation needs to be in 2D |
| 19:03 |
Taoki |
Since bottom is always chosen vertically so it doesn't matter |
| 19:03 |
Taoki |
erm, ground level is |
| 19:04 |
kaeza |
Taoki, it may be simple |
| 19:05 |
kaeza |
just check whether the four coordinates are inside another box |
| 19:06 |
kaeza |
(x1,z1),(x1,z2),(x2,z1),(x2,z2) |
| 19:06 |
Taoki |
kaeza: Yeah, but I need to find the closest free space |
| 19:07 |
VanessaE |
start by comparing the largest of your candidate objects against the smallest of the free space regions |
| 19:07 |
VanessaE |
it's brute force, but it'll give you something usable |
| 19:08 |
VanessaE |
(kaeza's idea is also, but in a case like this, I don't think there's a better way) |
| 19:08 |
Taoki |
Issue is even finding the free spaces |
| 19:08 |
kahrl |
I'm pretty sure this is NP hard |
| 19:08 |
kahrl |
Assuming you're looking for the absolute "best" solution |
| 19:09 |
VanessaE |
well you surely have a large region of free space to start with (e.g. a new map). |
| 19:09 |
|
sapier joined #minetest-dev |
| 19:09 |
VanessaE |
hrm |
| 19:09 |
Taoki |
VanessaE: Sure. I start adding from a position down-to-right |
| 19:10 |
VanessaE |
Taoki: in that case, you could simply assume the next free space starts at the up-and-to-the-left corner of your candidate space |
| 19:11 |
VanessaE |
also, look at that x screensaver that does the same |
| 19:11 |
VanessaE |
what was it called, tetrominoes or some such? |
| 19:11 |
Taoki |
That would be easy if I was only adding them in one direction. But once I'd get to the rows, I need to knoww the building fits there |
| 19:11 |
VanessaE |
Polyominoes |
| 19:11 |
VanessaE |
that's the name of it |
| 19:12 |
kaeza |
Taoki, http://en.wikipedia.org/wiki/Packing_problem |
| 19:12 |
VanessaE |
that does a 2D fill of a region with irregular polys |
| 19:12 |
VanessaE |
you should be able to borrow that code to help you out |
| 19:13 |
VanessaE |
(but watching it run, it obviously brute-forces the fill) |
| 19:13 |
hmmmm |
pretty sure packing problems are NP hard |
| 19:13 |
hmmmm |
exactly, what vanessa said |
| 19:16 |
VanessaE |
Taoki: just make sure that if you brute-force it, that you limit how many tries your code makes with each successive step of the fill, so that it doesn't just run on forever when it gets to that last 10-20% of the free space. |
| 19:17 |
Taoki |
I'll think more about it |
| 19:17 |
VanessaE |
https://github.com/danfuzz/xscreensaver/blob/master/hacks/polyominoes.c |
| 19:18 |
hmmmm |
my recommendation is that you don't bother making it optimal |
| 19:19 |
hmmmm |
try a clever heuristic, but keep in mind that brute forcing a solution isn't a job for lua |
| 19:20 |
VanessaE |
agreed |
| 19:20 |
VanessaE |
hmmmm: less'n you wanna put such an algorithm into the engine ;-) |
| 19:21 |
hmmmm |
nothing like this is going into the engine |
| 19:21 |
VanessaE |
I was joking |
| 19:21 |
hmmmm |
you might give him an idea |
| 19:21 |
hmmmm |
everybody wants everything in the engine |
| 19:22 |
hmmmm |
and then if we don't do it, "waa waa you're holding minetest back, no wonder why everybody's leaving" |
| 19:23 |
|
ch98 joined #minetest-dev |
| 19:23 |
VanessaE |
well sure, but I can see their arguments too, from one standpoint only: C++ is the only way to get real, honest-to-G*d speed out of anything, in this particular venue. |
| 19:24 |
VanessaE |
There's so much out there that people want to do that is just not possible (in a playable or usable manner) in Lua, which leaves C++ as the only other option. |
| 19:25 |
|
Mallot1 joined #minetest-dev |
| 19:25 |
hmmmm |
but *they* are the ones who want it |
| 19:25 |
VanessaE |
true. |
| 19:26 |
VanessaE |
so maybe what's needed is a C++ API that is as easy to use as the Lua one. |
| 19:26 |
hmmmm |
the whole point of lua is so that if they want something they can do it without anybody else necessarily wanting it |
| 19:26 |
|
Mallot1 joined #minetest-dev |
| 19:26 |
hmmmm |
vanessae, not happening when there's so much variance in platforms |
| 19:26 |
hmmmm |
i figured that'd be a good idea too at one point |
| 19:26 |
PilzAdam |
"that is as easy to use as the Lua one." how would you do that? |
| 19:27 |
VanessaE |
PilzAdam: I haven't figured out the details yet, but I expect it would need some form of just-in-time compiling. |
| 19:27 |
VanessaE |
the API would have to be incredibly simplified of course. |
| 19:27 |
VanessaE |
most of the engine internals being off-limits |
| 19:29 |
VanessaE |
and at this rate I don't expect to figure out said details, as it's obvious that it will not be considered at this time. |
| 19:29 |
VanessaE |
(if ever) |
| 19:30 |
sapier |
theres an issue with the minetest.env: wrapper it doesn't pass nil arguments correctly |
| 19:30 |
VanessaE |
I don't believe MT is being "held back" like some folks claimed, but do consider that the main competition to MT uses mods that are integrated into, or at least which tap into, the game engine in such a way as to directly modify the engine itself. We can't do that with Lua. |
| 19:31 |
VanessaE |
which means said competitor, whom I do not need to name, has the advantage of being able to do things we simply cannot do. |
| 19:31 |
PilzAdam |
MC "mods" are more like engine patches |
| 19:31 |
VanessaE |
PilzAdam: I just said that. |
| 19:32 |
PilzAdam |
you can create engine patches for Minetest too |
| 19:32 |
PilzAdam |
(see my "see your own player" "mod") |
| 19:32 |
* Taoki |
wishes PilzAdam's mob framework would get in Minetest already :) |
| 19:32 |
VanessaE |
so we have one of two options to compete: Either keep adding random features to the API until there's nothing left that we can't do in some roundabout way, or allow C++ modding. |
| 19:32 |
sapier |
<< thinks pilzadams simplemobs are way to buggy to be included ;-P |
| 19:33 |
sapier |
btw mob framework is not simplemobs ;-) |
| 19:33 |
Taoki |
meh. The simple mobs are buggy, the not simple mobs (forgot who owns those) are too laggy |
| 19:33 |
Taoki |
yeah, that was the other one |
| 19:34 |
sapier |
taoki have you ever tried mobf without the advanced mobs? ;-) |
| 19:34 |
sapier |
I guess they won't be laggy anymore |
| 19:34 |
PilzAdam |
^ thats the third "throw simple mobs in" wish |
| 19:34 |
Taoki |
Not really. Waiting for something more... final |
| 19:34 |
VanessaE |
PilzAdam: the difference is that your code is distributed as a patch. I'm talking about self-contained blobs of program code that hook into the engine the way Lua does, but which are compiled either at run-time (ala luajit) or ahead of time for distribution (ala luac) |
| 19:34 |
VanessaE |
forget adding any mobs of any kind right now |
| 19:34 |
VanessaE |
not until those stupid entity bugs are fixed. |
| 19:35 |
PilzAdam |
mobf is too bloated |
| 19:35 |
sapier |
it'll never be final taoki as it's a matter of personal taste the more "perfect" the mobs will be the more cpu power they need |
| 19:35 |
sapier |
mobf is a library supporting different things so you don't have to reimplement it for every mob itself |
| 19:35 |
Taoki |
yeah. well, one good enough to go in Minetest mostly :) |
| 19:35 |
Taoki |
Perhaps as part of builtin |
| 19:35 |
PilzAdam |
VanessaE, MC doesnt have this |
| 19:35 |
Taoki |
yeah. That would be one I'd like to see added |
| 19:36 |
VanessaE |
PilzAdam: so? |
| 19:36 |
sapier |
taoki that's the exact problem not even mobf is perfect enough to be added to core |
| 19:36 |
VanessaE |
MC doesn't *need* it. |
| 19:36 |
sapier |
and simple mobs is far from that |
| 19:36 |
VanessaE |
because of the architecture of MT, we do need it or will eventually. |
| 19:36 |
sapier |
yes the entity bugs are crazy |
| 19:37 |
sapier |
VanessaE "self contained blobs of programm code" thats metacode |
| 19:38 |
VanessaE |
sapier: no, think more like extra libraries |
| 19:38 |
sapier |
so you have to compile it for any architecture |
| 19:38 |
VanessaE |
except in some format that we can be sure to be able to load regardles of platform |
| 19:38 |
VanessaE |
+s |
| 19:38 |
sapier |
that's not possible per definition VanessaE |
| 19:38 |
VanessaE |
it is if it's just-in-time compiled. |
| 19:38 |
sapier |
either code is platform specific or its at least metacode |
| 19:39 |
VanessaE |
such compilers exist for C++ do they not? |
| 19:39 |
sapier |
no |
| 19:39 |
sapier |
at least I never heared of c++ jit compilers |
| 19:39 |
VanessaE |
ok then a regular compiler. |
| 19:39 |
VanessaE |
compile it once, cache the result. |
| 19:39 |
sapier |
so we integrate a compiler to minetest?? |
| 19:39 |
VanessaE |
run the result on future runs of the server. |
| 19:39 |
VanessaE |
no silly |
| 19:40 |
PilzAdam |
sapier, a quick serach brought some up, but they are platform specific too |
| 19:40 |
VanessaE |
call upon whatever is installed on the system |
| 19:40 |
VanessaE |
same as we do now to compile the engine in the first place. |
| 19:40 |
PilzAdam |
inb4 Minetest OS 1.0 |
| 19:40 |
VanessaE |
if the system lacks a compiler, the mod doesn't run and the engine throws an error |
| 19:40 |
VanessaE |
don't overthink the process |
| 19:40 |
PilzAdam |
wheres the browser? |
| 19:40 |
sapier |
VanessaE users normaly don't compile minetest |
| 19:40 |
VanessaE |
sapier: oh well, then said users just don't run those kinds of mods. |
| 19:40 |
sapier |
imho that's completely wrong direction |
| 19:41 |
VanessaE |
well we don't have any other choice, have we? |
| 19:41 |
sapier |
and I think luajit is quite fast have you ever seen performance comparison of pathfinding algorithms? |
| 19:42 |
VanessaE |
it's either use Lua, which is painfully slow for some things (even with luajit), or use C++ with some kind of on-demand compiling, or introduce another language suitable for the purpose |
| 19:42 |
sapier |
luajit is faster than -O0 native code and not far from -O3 ... BUT there are some api calls that are implemented that stupid it's losing all performace |
| 19:42 |
VanessaE |
sapier: such as? |
| 19:42 |
VanessaE |
(what API calls?) |
| 19:42 |
sapier |
environment access |
| 19:43 |
kaeza |
VanessaE, it's a bit of a hack, but you can create a C library to do the hard work, which returns the result as a string. The string is thel "loaded" into Lua and it can do the job of feeding it to the engine |
| 19:43 |
sapier |
minetest now suffers about a problem linux kernel did 10 years ago |
| 19:43 |
VanessaE |
and why have such things not been fixed already? a thousand new features have been added to the engine over the past year, yet some of our worst bugs go unfixed. |
| 19:43 |
sapier |
there's exactly one LOCK |
| 19:43 |
sapier |
yes there are more but all of them are taken same time ;) |
| 19:44 |
sapier |
because fixing it is quite a big deal and needs changes throughout minetest |
| 19:44 |
kaeza |
concurrency in Lua is "unsupported" by the developers |
| 19:44 |
PilzAdam |
VanessaE, fact is that the current Lua API works perfectly fine for _many_ things |
| 19:44 |
sapier |
the scriptapi split I merged was a part of preparation to split up the locks |
| 19:45 |
VanessaE |
PilzAdam: and for many things, it sucks ass. everyone here can come up with at least one thing that's either stupidly designed, slow, or just plain inadequate. |
| 19:45 |
PilzAdam |
VanessaE, people tend to want things that are impossible, and they dont care about whats already possible |
| 19:45 |
sapier |
we need to remove the environment lock around lua calls |
| 19:45 |
VanessaE |
PilzAdam: nothing's impossible if you have the skills. |
| 19:45 |
VanessaE |
(and I presume most folks here do) |
| 19:46 |
sapier |
PilzAdam improving performance isn't impossible |
| 19:46 |
PilzAdam |
if we improve the performance people want even more complex things, wich leads to more performance improvements |
| 19:46 |
VanessaE |
PilzAdam: what makes things impossible is laziness, lack of desire, or lack of skill to code the thing in question. |
| 19:47 |
sapier |
currently minetest uses exactly one core |
| 19:47 |
PilzAdam |
I just say that improving speed isnt the only goal |
| 19:47 |
VanessaE |
bullshit |
| 19:47 |
PilzAdam |
sapier, nope |
| 19:47 |
VanessaE |
speed should be THE primary goal. |
| 19:47 |
VanessaE |
remember, Minetest is supposed to be able to run on old computers. |
| 19:47 |
sapier |
PilzAdam in current state it should be the primary goal |
| 19:47 |
PilzAdam |
adding new features is important too |
| 19:47 |
VanessaE |
adding new features is useless if the engine is too slow. |
| 19:48 |
PilzAdam |
otherwise we would have only a set_node() function that is extremly fast, but useless since there are no other functions |
| 19:48 |
kaeza |
derp |
| 19:48 |
VanessaE |
slipper slope argument. |
| 19:48 |
VanessaE |
+y |
| 19:48 |
kaeza |
wasn't the point of VoxelManipulator a faster version of set_node basically? |
| 19:48 |
VanessaE |
kaeza: and then some |
| 19:48 |
sapier |
PilzAdam we're not talking about fixing a single function we're talking about redesign of core components ... while keeping compatibility |
| 19:48 |
PilzAdam |
kaeza, its a new feature |
| 19:49 |
PilzAdam |
so its not speed improvement as VanessaE wants it |
| 19:49 |
kaeza |
PilzAdam, a new feature towards speed |
| 19:49 |
sapier |
and it doesn't fix minetests extreme data coupling problem |
| 19:49 |
VanessaE |
PilzAdam: its whole purpose is speed. |
| 19:49 |
VanessaE |
speed in setting tons of nodes at once |
| 19:49 |
VanessaE |
(and other things, hmmmm can explain it better of course) |
| 19:50 |
PilzAdam |
IMO the main goal of the engine is outsourcing more things to Lua (like HP handling (wich requires client side Lua)) |
| 19:50 |
VanessaE |
um.. |
| 19:50 |
PilzAdam |
and these things dont really need more speed in Lua |
| 19:50 |
VanessaE |
no |
| 19:50 |
VanessaE |
just, no |
| 19:51 |
PilzAdam |
how can you say "no" to a sentence that starts with "IMO"? |
| 19:51 |
VanessaE |
if you're gonna outsource everything to Lua, why bother writing anything in C++? |
| 19:51 |
PilzAdam |
oh, you misread what I was saying |
| 19:51 |
PilzAdam |
I was talking about "more things", not "everything" |
| 19:53 |
PilzAdam |
also, this doesnt mean that speed improvement or anything is completly out of scope |
| 19:53 |
sapier |
why the hell doesn't anyone realize current pc's have 4 8 16 cores ... minetest is capable of using ONE ... is it that difficult to realize the potential speed gain? |
| 19:53 |
PilzAdam |
sapier, Minetest has several threads |
| 19:53 |
Jordach |
different platforms manage cores differently |
| 19:53 |
VanessaE |
sapier: well hmmmm has done some work on getting the mapgen to use multiple cores. |
| 19:53 |
VanessaE |
but there's a lot of gain left to be had. |
| 19:53 |
sapier |
threads are USELESS if all threads require SAME LOCKS |
| 19:53 |
Jordach |
so supporting this is hard as different kernels use different APIs |
| 19:54 |
VanessaE |
and a LOT of speed improvements to be had in the form of code that just runs faster, too |
| 19:54 |
Exio |
sapier is right |
| 19:54 |
PilzAdam |
sapier, I guess the main reason for this is that Minetest is designed for slow PCs |
| 19:54 |
Exio |
PilzAdam: threads are better everywhere |
| 19:54 |
VanessaE |
PilzAdam: and runs like shit on said slow PCs |
| 19:54 |
Jordach |
i cant even break 40fps any more |
| 19:55 |
sapier |
so we need to decide either make this a powerfull engine or stay at slowmo |
| 19:55 |
VanessaE |
Jordach: go to the spawn on my server, you won't even break 20. |
| 19:55 |
Jordach |
i wont even break 10 |
| 19:55 |
PilzAdam |
problems just started because we went into a different direction lately |
| 19:56 |
sapier |
VanessaE that's something completely different I guess graphics system needs lots of improovements too but I don't know how it can be done there |
| 19:56 |
hmmmm |
sapier, like i said, RCU for mapblocks would help a lot |
| 19:56 |
VanessaE |
sapier: with the exception of that last comment about fps, I'm not talking about the client. |
| 19:56 |
hmmmm |
would eliminate the need for an envlock in most cases |
| 19:57 |
Exio |
RCU? |
| 19:57 |
hmmmm |
read-copy-update |
| 19:57 |
Exio |
ah |
| 19:57 |
hmmmm |
anyway |
| 19:57 |
sapier |
hmmmm yes it would |
| 19:57 |
VanessaE |
hmmmm: but when is that going to happen? |
| 19:57 |
hmmmm |
a good candidate for parallelizing would be the meshgen thread |
| 19:58 |
Exio |
the meshgen? |
| 19:58 |
sapier |
we need to eleminate as much locks as possible |
| 19:58 |
VanessaE |
(as in, a measure of weeks, months, years?) |
| 19:58 |
hmmmm |
but it might also be a better idea to look into smarter algorithms |
| 19:58 |
Exio |
isn't it already thread-ed? |
| 19:58 |
hmmmm |
vanessae, dunno, there are more pressing issues for me |
| 19:58 |
sapier |
once that's done we can paralellize more |
| 19:58 |
sapier |
hmmmm problem with that lock is that they are hold while lua is called |
| 19:58 |
PilzAdam |
Exio, it uses 1 thread |
| 19:59 |
sapier |
so if anyone does a long lua function mapgen can't do anything |
| 19:59 |
Exio |
ah, multithreaded in that sense |
| 20:00 |
hmmmm |
sapier, about that |
| 20:00 |
sapier |
most lua functions don't even need map access ;-) |
| 20:00 |
hmmmm |
i'm adding lua api to explicitly disable locks for the time being |
| 20:00 |
hmmmm |
along with lua MVM |
| 20:00 |
sapier |
mod access to locks? NOOOOOO .... |
| 20:00 |
hmmmm |
(you can't really make the most use of voxelmanipulator without leaving it unlocked) |
| 20:00 |
hmmmm |
sapier, yesssssss |
| 20:00 |
sapier |
no I won't look for any bug if you add this |
| 20:01 |
hmmmm |
i don't need you to look for bugs |
| 20:01 |
hmmmm |
i need people to be able to use lua effectively |
| 20:01 |
VanessaE |
that's pretty stupid, imho, hmmmm. locks should have to be *enabled* my a mod |
| 20:01 |
hmmmm |
if i wanted to, i can make minetest explode right now without explicit unlocking api |
| 20:01 |
sapier |
hmmmm you expect lua programmers to be more skilled than they are |
| 20:01 |
PilzAdam |
VanessaE, that would break current API |
| 20:01 |
sapier |
the locks have to be handled within core not in lua |
| 20:01 |
hmmmm |
if they're not skilled, then they could just leave it locked |
| 20:02 |
hmmmm |
i've thought about this a lot already |
| 20:02 |
sapier |
they won't do you know that |
| 20:02 |
hmmmm |
it's the best thing to do |
| 20:02 |
sapier |
it's just crazy hmmmm |
| 20:02 |
hmmmm |
so you say |
| 20:02 |
VanessaE |
PilzAdam: so would requiring the mod to explicitly *unlock* something |
| 20:02 |
VanessaE |
as that means adding a new API call |
| 20:02 |
VanessaE |
= breaking mods that would have otherwise worked on older versions of MT |
| 20:02 |
hmmmm |
Vanessae, lua is already called with everything locked |
| 20:02 |
PilzAdam |
VanessaE, adding a new function never breaks the API |
| 20:02 |
sapier |
it's make moders responsible instead of thinjingf about a good solution |
| 20:02 |
VanessaE |
*sigh* |
| 20:03 |
hmmmm |
sapier, like i said, if i wanted to nuke minetest right *now*, i could |
| 20:03 |
hmmmm |
you want lua to be a total sandbox with rubber edges but it's not happening |
| 20:03 |
sapier |
that's your justification for adding even more harmfull calls!? |
| 20:04 |
Exio |
#minetest-dev got converted into #minetest-fight |
| 20:04 |
hmmmm |
my justification is allowing mods to do more complicated things without dragging the rest of it down |
| 20:04 |
|
proller joined #minetest-dev |
| 20:04 |
sapier |
if you do things like that I'll support VanessaE ... if lua isn't less complex than c++ mods should be c++ |
| 20:05 |
hmmmm |
if you support C++ mods but not this, you must be insane |
| 20:05 |
PilzAdam |
I guess today is not a good day for discussing things... |
| 20:06 |
VanessaE |
this is the perfect time to discuss |
| 20:06 |
VanessaE |
when arguments are heated, the REAL opinions come out |
| 20:06 |
hmmmm |
anyway, this is what i envision: |
| 20:06 |
|
sapier1 joined #minetest-dev |
| 20:06 |
hmmmm |
on_generate gets called, user gets a map voxel manipulator, the same one used for map generation |
| 20:07 |
hmmmm |
the mod wants to do something time consuming and complex |
| 20:07 |
sapier1 |
no I'm just consequent either give modders FULL access or create a environment where they can harm as less as possible while still having almost all possibilitys |
| 20:07 |
hmmmm |
instead of stopping the entire game so that it can do what it needs to, it'll unlock con and env |
| 20:07 |
sapier1 |
I don't see any need for exposing locks to lua ... WE know which lua calls need locks so WE can add them in c++ |
| 20:07 |
|
Wuzzy joined #minetest-dev |
| 20:07 |
hmmmm |
it works on its voxelmanipulator, then when it's done, everything gets blit back and it's fast, and it didn't degrade performance for the rest of the server either |
| 20:08 |
hmmmm |
sapier, celeron already tried that if you recall. |
| 20:08 |
hmmmm |
the result wasn't that great |
| 20:08 |
VanessaE |
hmmmm: how does that help existing mods that are otherwise perfectly good, if slow due to engine slowness or poor locking? |
| 20:08 |
hmmmm |
vanessae, it doesn't help existing mods. it never did and it wasn ever intended to |
| 20:08 |
sapier1 |
I don't remember it but I guess it was because he didn't fix ALL issues |
| 20:08 |
VanessaE |
I didn't think so. |
| 20:08 |
VanessaE |
you can't just think of the future, you have to consider the *now* also |
| 20:08 |
hmmmm |
sapier, it was because of performance issues |
| 20:08 |
sapier1 |
hmmmm the engine will still be locked if lock is freed due to waiting for result |
| 20:09 |
hmmmm |
vanessae, that's all poetic and what not, but it means nothing unless you can actually come up with something better |
| 20:09 |
hmmmm |
sapier, ?? |
| 20:09 |
Jordach |
we should sort out mapgen v7 then sort out long standing bugs |
| 20:09 |
hmmmm |
result of what |
| 20:09 |
VanessaE |
hmmmm: if I could, I wouldn't bother anyways, because I know better than to try to code anything for this engine. |
| 20:09 |
hmmmm |
yeow |
| 20:10 |
hmmmm |
that was a pretty deep stab |
| 20:10 |
sapier1 |
hmmm you can't access lua stack by different threads same time so you add lots of race conditions either |
| 20:10 |
hmmmm |
minetest's engine isn't too bad all things considered |
| 20:10 |
VanessaE |
you're damn right it was, and you know perfectly well why I say that. |
| 20:10 |
hmmmm |
i don't though |
| 20:10 |
hmmmm |
territory wars? |
| 20:11 |
sapier1 |
this locking thing is a BIG one it needs a consistent minetest global solution giving modders access to locks will even make this task more complex |
| 20:11 |
VanessaE |
I've watched over the past year the direction the engine has taken, which is good for the most part, and the direction which the core development team has taken, which is not entirely good. |
| 20:11 |
VanessaE |
I've watched the engine get better in some ways, while getting progressively worse in other ways |
| 20:11 |
hmmmm |
sapier, yeah, i wanted different interpreters for emerge and server |
| 20:11 |
VanessaE |
I've bitched, LOUDLY, about it. And my arguments have been ignored. |
| 20:11 |
hmmmm |
iv'e wanted them since like 9 months ago |
| 20:11 |
PilzAdam |
VanessaE, can you be more precise? |
| 20:12 |
Jordach |
namely rendering |
| 20:12 |
VanessaE |
PilzAdam: ok, I'll give a good example. Remember when chests and furnaces were moved out of C++ and into Lua? |
| 20:12 |
sapier1 |
it can be done quite easyly hmmmm BUT data exchange between them is an issue |
| 20:12 |
hmmmm |
hardly an issue. some work needs to be done for that, but it'd be the only "big problem" we'd face |
| 20:12 |
VanessaE |
at about the same time that happened, something happened to the client that made the dig animation rendering horribly slow in some cases (but I have yet to see a pattern), particularly with high resolution textures. |
| 20:13 |
VanessaE |
such that digging an item caused the client to slow down to as little as 1 fps during the dig animation |
| 20:13 |
sapier1 |
yes but a really cruicial one as this may ruin performance by re-adding the lock sync |
| 20:13 |
PilzAdam |
VanessaE, I never noticed anything like this |
| 20:13 |
VanessaE |
I don't care how old your POS trident video card is, 1 fps is way below even the slowest computer's capabilities. |
| 20:13 |
sapier1 |
and I still don't get the need for lua lock access hmmmm |
| 20:13 |
VanessaE |
PilzAdam: you never used what I use. |
| 20:13 |
PilzAdam |
true |
| 20:13 |
VanessaE |
and this is the big problem. |
| 20:13 |
hmmmm |
maybe it'd ruin performance if you kept using the same globals in both threads |
| 20:14 |
hmmmm |
and you used locks in the first place |
| 20:14 |
PilzAdam |
VanessaE, anything else? |
| 20:14 |
VanessaE |
I use the engine in ways that fucking NO ONE WHO CARES uses too. |
| 20:14 |
hmmmm |
FOSS has always been about itching your own scratch |
| 20:15 |
sapier1 |
hmmmm I guess we could add all those things without exposing locks |
| 20:15 |
VanessaE |
PilzAdam: doesn't matter as everything else has been discussed to death. |
| 20:15 |
sapier1 |
hmmmm what do you think about a limited api set for on_generated? |
| 20:15 |
hmmmm |
sapier, even if we don't have all these other things right away, there's nothing wrong with having a GIL for lua |
| 20:16 |
sapier1 |
GIL? |
| 20:16 |
PilzAdam |
VanessaE, so, the main problem is that (ab)use the Minetest engine in a way nobody else is (ab)using it; and then you really want us to "support" your way of using it? |
| 20:16 |
hmmmm |
maybe lua callbacks in the server step could be passed over if it's locked |
| 20:16 |
hmmmm |
global interpreter lock |
| 20:16 |
VanessaE |
PilzAdam: no. use, not abuse. |
| 20:16 |
sapier1 |
hmmmm there already is a lua lock |
| 20:16 |
hmmmm |
so i know i'm being idealistic with the whole two separate lua interpeters |
| 20:16 |
VanessaE |
I'm not doing anything with the engine that others haven't been doing since at least the 0.3.x days |
| 20:16 |
hmmmm |
sapier, then what were you saying about the stack race conditions... ? |
| 20:17 |
sapier1 |
if you give modders access to the locks you'll get race conditions |
| 20:17 |
hmmmm |
i don't see how |
| 20:17 |
hmmmm |
if you want to be safe, we can make envlock/conlock functions check if it's locked before carrying on |
| 20:17 |
sapier1 |
what lock do you want to give player access to? |
| 20:17 |
hmmmm |
failing if it's not |
| 20:17 |
hmmmm |
both, ideally |
| 20:18 |
PilzAdam |
VanessaE, fact is that at least nobody in the dev team (not only core devs) uses Minetest in "your way" |
| 20:18 |
hmmmm |
i want the mod to be able to do something interesting that might take a while, but not otherwise drag the rest of the server to a screeching halt |
| 20:18 |
sapier1 |
I suggest removing those locks completly around most lua calls |
| 20:18 |
PilzAdam |
VanessaE, and devs tend to code what they want, and not what others want them to |
| 20:18 |
hmmmm |
and the conversation did a complete 360 |
| 20:18 |
VanessaE |
PilzAdam: I use my HDX texture pack as a test case because it stresses the client to its maximum, but I've seen huge performance falloffs over the past year that no one seems to give a shit about because "oh who cares, everyone else uses defaults anyway"....even though they're half the resolution of the highest that's been created for this engine so far. |
| 20:18 |
sapier1 |
hmmmm that's not possible per definition atm |
| 20:19 |
sapier1 |
I was thinking about that too |
| 20:19 |
VanessaE |
PilzAdam: if some of the dev team would use the engine "my way" as you put it, for even a day, they'd see just how bad it's gotten. |
| 20:19 |
sapier1 |
some sort of "do async lua call" |
| 20:19 |
hmmmm |
again, the reason why locks aren't made in the lua apis themselves is because of the performance hit with acquiring them |
| 20:19 |
hmmmm |
oh, you want an async variant? |
| 20:19 |
VanessaE |
PilzAdam: and if you think performance fall-offs are acceptable just because you don't use something that tends to show that fall-off, then you should NOT be coding. Sorry. |
| 20:19 |
hmmmm |
that's more complicated |
| 20:19 |
PilzAdam |
VanessaE, but its normal in FOSS projects that there need to be devs who care |
| 20:20 |
sapier |
yes but it's a way more clean design and won't interfere to current design |
| 20:20 |
PilzAdam |
VanessaE, you cant walk to the devs and force them to code what you want |
| 20:20 |
VanessaE |
PilzAdam: yeah, and the problem is that NO ONE (who can fix the issues) CARES. |
| 20:20 |
VanessaE |
and this is a BIG problem. |
| 20:20 |
sapier |
atm no matter where you do your "long runn lua call" you'll block one of minetests core threads |
| 20:20 |
hmmmm |
sapier, i guess that's somewhat better, but someone's going to have to add them all |
| 20:21 |
hmmmm |
have fun with that |
| 20:21 |
sapier |
I guess it's way less work than adding the mainmenu ;-P |
| 20:21 |
PilzAdam |
VanessaE, the solution for you would be to get a dev who cares (i.e. who uses Minetest "your way") and who actually improves things |
| 20:21 |
hmmmm |
the mainmenu thing was ridiculous |
| 20:21 |
VanessaE |
PilzAdam: and no one's saying one should be able to force the devs to do something. I'm saying one should be able to convince them to look at a problem they already know exists. |
| 20:21 |
hmmmm |
i don't understand how you actually coded that |
| 20:21 |
PilzAdam |
VanessaE, just whining in the dev channel wont result in anything useful if the devs dont care |
| 20:21 |
VanessaE |
*facepalm* |
| 20:21 |
sapier |
core work was done in 2 days hmmmm ;-) |
| 20:22 |
VanessaE |
and you wonder why I don't bother to learn C++ and try to contribute anymore? |
| 20:22 |
hmmmm |
i thought it was like 10k lines? |
| 20:22 |
PilzAdam |
VanessaE, ehm, learning C++ would actually fix your problem |
| 20:22 |
PilzAdam |
since you would be the dev who cares then |
| 20:22 |
sapier |
no I didn't expect it to be that much at beginning .... but I guess about 4k lines are modmanager game manager and online modstore |
| 20:23 |
hmmmm |
vanessae, like i said before, FOSS has always been about being able to itch your own scratch. you don't honestly think people come on here and say "i am so kind hearted that i'm going to start working for free on some open source project" |
| 20:23 |
sapier |
and lots of code is similar to things I already had in mobf |
| 20:23 |
VanessaE |
no it wouldn't, because I know my attempts to fix things would not only fail (because I just don't know the engine well enough), but would not be accepted (because everyone has their own idea of what belongs and what doesn't) |
| 20:23 |
PilzAdam |
VanessaE, getting already coded code in is way easier than convincing others to code it |
| 20:23 |
sapier |
hmmmm can you explain to me the performance problems with locks taken when needed? |
| 20:23 |
VanessaE |
hmmmm: no offense, but you're talking to a 25-year coding veteran who actually DID do that for a while. |
| 20:23 |
hmmmm |
sapier, celeron was the one who explained it |
| 20:24 |
sapier |
I know that aquireing a lock may be a heavy operation |
| 20:24 |
VanessaE |
(and who writes her MT mods for the very same reason) |
| 20:24 |
hmmmm |
he just said "it didn't work out very well" |
| 20:24 |
PilzAdam |
VanessaE, this basically looks like you want others to work for you |
| 20:24 |
VanessaE |
PilzAdam: just forget it. you're gonna twist my words around no matter how plainly I put it. |
| 20:25 |
hmmmm |
but yeah |
| 20:25 |
sapier |
locking needs to be done for async calls too so it'd be interesting where the problem was and if it may be fixed |
| 20:25 |
hmmmm |
so sapier, what are you thinking exactly? |
| 20:25 |
hmmmm |
wrapping everything around |
| 20:25 |
sapier |
I don't trust in modders to do locking correct and it'll horribly fail if done wrong in async calls |
| 20:25 |
hmmmm |
if (was unlocked) lock; <lua api body here> if (was unlocked) unlock; ? |
| 20:27 |
hmmmm |
personally, i'd just be okay if it was marked in the documentation that you shouldn't call <list of things here> while unlocked |
| 20:27 |
hmmmm |
because then it'd be the modder's stupid problem |
| 20:27 |
sapier |
PilzAdam VanessaE is one of our power users imho if she has problems we should have a closer look ant try to fix it ... of course not everything can be done |
| 20:27 |
hmmmm |
and then when people say "waa waa my minetest crashed" we'll tell them what the offending mod was |
| 20:28 |
hmmmm |
then, market forces at work, the mod developer will shape up or nobody will use it |
| 20:28 |
sapier |
market forces usually don't work very well ;-) |
| 20:28 |
hmmmm |
wrapping locks around every single api is a lot of work |
| 20:28 |
hmmmm |
there's a lot of apis, you know. |
| 20:28 |
hmmmm |
like, hundreds. |
| 20:29 |
sapier |
if and only if there's really no way to avoid giving modders access to it yes ... but imho it's a surrender to complexity |
| 20:29 |
sapier |
And I don't usualy surrender ;-P |
| 20:29 |
hmmmm |
so you don't want to give modders access to the locks at all |
| 20:30 |
hmmmm |
but how would you make lua not run like shit if they do something big in on_generate? |
| 20:30 |
hmmmm |
the main point of this is that having a lua exposed mapvoxelmanipulator won't really be enough; sure, it'll make some operations faster, but you'd still want Server to be able to step through without coming to a screeching halt |
| 20:31 |
sapier |
hmmmm I already started that work have a look at lua api there's a macro NO_MAPLOCK_REQUIRED |
| 20:31 |
hmmmm |
which, IMO, is way worse. |
| 20:31 |
hmmmm |
yeah, I saw that |
| 20:31 |
hmmmm |
you can easily adopt that macro to do what i said, assuming you really went through everything |
| 20:31 |
sapier |
it's currently only measuring time that is wasted within lock for things that don't need lock |
| 20:31 |
hmmmm |
that would remove the huge bulk of the work |
| 20:32 |
sapier |
I don't understand how this could help with lua lock acccess? |
| 20:33 |
hmmmm |
no, this is envlock and conlock, not the lua lock |
| 20:33 |
hmmmm |
lua still needs to stay locked regardless |
| 20:33 |
hmmmm |
and if there's a lua callback in the server step, we can skip over that if locked |
| 20:33 |
sapier |
that's completely different hmmmm tha lua lock is hidden within cpp_api |
| 20:34 |
sapier |
SCRIPTAPI_PRECHECKHEADER |
| 20:35 |
sapier |
first thing we could do is open up lock where currently the NO_MAPLOCK_REQUIRED call is done |
| 20:36 |
sapier |
but I'm not sure if this really would give that much benefit, at least it will allow core tasks to run in that case |
| 20:36 |
hmmmm |
that's going to probably lead to a net loss |
| 20:36 |
sapier |
why? |
| 20:39 |
PilzAdam |
ShadowNinja, no, he doesnt maintain the package anymore |
| 20:40 |
PilzAdam |
(^ answer to what you said 16 hours ago) |
| 20:40 |
hmmmm |
because that api might execute faster than it takes to re-acquire a lock |
| 20:41 |
sapier |
that's be not that good of course but it's main effect pass lock to a waiting core thread would still occur |
| 20:42 |
sapier |
-be |
| 20:42 |
sapier |
we could decide for some long run api calls to do unlock only |
| 20:43 |
sapier |
or go the other way as I originaly intended remove lock and only call a lock where currently no "NO_MAPLOCK.." is set |
| 20:45 |
hmmmm |
try both, but i bet the result will be less than satisfactory |
| 20:46 |
sapier |
so we need to think more about it ... if WE are not capable of implementing a reasonable good locking scheme how could we dare to expect modders to do? |
| 20:48 |
sapier |
completely unrelated when is the next (fast) minetest release to happen? if it's not gonna be fast I suggest adding mainmenu too |
| 20:48 |
sapier |
it's not getting better sitting around for months |
| 21:09 |
|
VanessaE left #minetest-dev |
| 21:10 |
|
iqualfragile joined #minetest-dev |
| 21:24 |
|
BackupCoder joined #minetest-dev |
| 21:39 |
ShadowNinja |
PilzAdam: Then who does? They should be listed. |
| 21:44 |
|
iqualfragile joined #minetest-dev |
| 21:44 |
Exio |
https://www.archlinux.org/packages/community/x86_64/minetest/ |
| 21:47 |
|
ffoxin joined #minetest-dev |
| 22:33 |
|
diemartin joined #minetest-dev |
| 23:17 |
|
mrtux joined #minetest-dev |
| 23:26 |
|
kaeza joined #minetest-dev |
| 23:36 |
|
kaeza joined #minetest-dev |
