Time |
Nick |
Message |
00:04 |
|
Yepoleb joined #minetest-dev |
00:07 |
hmmmm |
as for the mapgen flags for creating the world |
00:07 |
hmmmm |
light should not be an option there |
00:07 |
hmmmm |
nobody is ever going to want to explicitly set that |
00:08 |
hmmmm |
it's for modmaking use exclusively |
00:09 |
hmmmm |
there's also the deprecated v5 flags 'blobs' |
00:10 |
hmmmm |
i feel as if the GUI code doing this is very repetitive |
00:10 |
hmmmm |
this guy could use loops |
00:23 |
|
OldCoder joined #minetest-dev |
00:59 |
|
Megaf_ joined #minetest-dev |
01:14 |
Yepoleb |
hmmmm: i found an irc log where you were talking about client-side lua, what's the current state of it? |
01:14 |
hmmmm |
design and planning |
01:15 |
Yepoleb |
it ended with a discussion about running non-free code and signing |
01:16 |
Yepoleb |
did you find a solution for that? |
01:19 |
hmmmm |
i'm not absolutely sure if i had discussed this previously, but we can't force client-side mods to have any particular license |
01:19 |
hmmmm |
signing is doable although impractical - this is akin to running javascript on a particular webpage |
01:28 |
Yepoleb |
hmmmm: i think if it is completely sandboxed, you don't need any additional security |
01:29 |
hmmmm |
sure.. there are exploits though |
01:30 |
Yepoleb |
what kind of exploits? |
01:30 |
hmmmm |
breaking out of the sandbox, running arbitrary code on the host machine |
01:32 |
Yepoleb |
yeah, but what would you explot? |
01:34 |
hmmmm |
you don't know until it's too late |
01:38 |
Yepoleb |
but you also can't secure against an unknown attack |
01:50 |
|
Miner_48er joined #minetest-dev |
01:53 |
|
OldCoder joined #minetest-dev |
01:55 |
Yepoleb |
hmmmm: browsers just have a sandbox and it seems to work quite well |
01:55 |
hmmmm |
are you kidding me |
01:55 |
hmmmm |
there were so many heap spraying exploits |
01:57 |
Yepoleb |
how would you prevent exploits? |
01:57 |
hmmmm |
we can't, but that's why code signing is so appealing |
01:58 |
hmmmm |
the lua execution environment is a very large surface area for exploitation |
02:06 |
Yepoleb |
hmmmm: yeah, but signing would be way too much work |
02:07 |
Yepoleb |
and you can't just implement a quick bugfix, because it would take a few days to get signed |
02:10 |
Yepoleb |
server owners wouldn't be able to modify anything |
02:15 |
ShadowNinja |
Um, please *do NOT bundle GMP*. Running `pacman -S gmp` is cool, downloading an extra hundred megs which will always be in the Git history bloating the repo and extending the compilation step by a few minutes building GMP is *definitely NOT cool*. And all packagers are going to specifically avoid anything packaged for a number of good reasons. |
02:15 |
ShadowNinja |
s/packaged/bundled/ |
02:15 |
hmmmm |
keep reading |
02:16 |
|
paramat joined #minetest-dev |
02:17 |
paramat |
i added comments to #2561 as i'm unsure if this PR works correctly with minetest.conf and minetest.conf of the subgame |
02:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/2561 -- Add mapgen specific flags to create world dialog by srifqi |
02:18 |
hmmmm |
i'm trying to come up with some way to deprecate the flag system |
02:18 |
hmmmm |
it wasn't a very smart idea to expose that implementation detail to the end user |
02:19 |
hmmmm |
that really should be a set of boolean settings |
02:20 |
ShadowNinja |
mini-gmp sounds slightly better, but we shouldn't bundle anything IMO, you should always be using the full GMP anyway. |
02:21 |
paramat |
i have some corrections to conf.example to do, while i'm at it i will move the jungles and dungeons flags from mtgame into the engine, hope this is okay.. |
02:21 |
ShadowNinja |
The only reason JSONCPP's still in the tree is because some distros' JSONCPP cause segfaults when linked against Minetest. |
02:22 |
ShadowNinja |
And the only other bindled lib is Lua. And that's causing some major issues for the IRC mod... |
02:22 |
ShadowNinja |
(bundled Lua isn't configured with the distro's search paths) |
02:24 |
hmmmm |
what is the argument against having default bundled libraries |
02:25 |
ShadowNinja |
hmmmm: They're not configured for the distro, they can't be updated without rebuilding all packages that bundle them, they waste memory because each version has to be loaded... |
02:26 |
ShadowNinja |
I'm sure you can find a dozen other reasons with some searching. |
02:26 |
hmmmm |
why would they need to be configured for the distro? |
02:26 |
hmmmm |
minetest is only bundling a couple libraries, and this is something that does not need to be updated often |
02:27 |
hmmmm |
in fact we're using an older version on purpose for freebsd compatibility |
02:27 |
hmmmm |
third, they don't waste any memory because we'd simply *not* link against that object file if it has been chosen to use the system installation |
02:28 |
hmmmm |
you do understand that mini-gmp is a single C source file, correct? |
02:28 |
hmmmm |
it's highly portable and by no means forced onto the package builder. they can easily use the system version instead, in fact which is recommended for servers |
02:29 |
hmmmm |
on the other hand, bundling a default library saves a lot of pain and trouble that you'd otherwise experience with dependencies |
02:32 |
ShadowNinja |
hmmmm: The bindled Lua only has /usr/local in its package.(c)path, but most distros use /usr. The IRC mod comphensates for this with a hack, but it still fails on a lot of distros that use other search paths (eg, in /opt or /usr/lib-x86_64-Linux-GNU). |
02:34 |
ShadowNinja |
We can be compatible with (old) FreeBSD by simply not using 6.0-only features and letting users install whatever is the latest version available to them. |
02:35 |
hmmmm |
not old freebsd, versions as recent as 9.2 |
02:35 |
ShadowNinja |
mini-GMP might be OK, but I'd prefer a simple dependency. |
02:35 |
hmmmm |
simply put, libgmp tests the limits of many compilers and consequently breaks them |
02:36 |
ShadowNinja |
hmmmm: 9.3 and 10.1 are out, so yes, it's old. Maybe not obsolete, but old. |
02:36 |
hmmmm |
GNU libraries also arrogantly make windows a second-class citizen. i am concerned with depending on GNU libraries especially for this reason |
02:36 |
hmmmm |
when making my own windows build, I've noticed I had the most trouble with the GNU libraries |
02:37 |
ShadowNinja |
That might be a problem. |
02:37 |
hmmmm |
the bundled lua having only /usr/local as its package.cpath is a problem, but that's a bug with lua. i wouldn't say that's a reason to not pacakge it |
02:37 |
ShadowNinja |
I consider Windows a "second-class citizen" too, but I still recognize that it's important due to its userbase. |
02:37 |
hmmmm |
right |
02:38 |
hmmmm |
that same mentality carries over onto clang though |
02:38 |
hmmmm |
when I see that "freebsd 10.x x86 is broken" and so on it raises my concern |
02:38 |
hmmmm |
they don't care to work around known problems |
02:38 |
ShadowNinja |
hmmmm: No, Lua can't include every path that every distro uses. Heck, a user might decide to use somwhere in /home. |
02:39 |
hmmmm |
in general, dependencies are made easy to install with linux/bsd/etc. |
02:40 |
hmmmm |
dependencies are serious business and we can't expect everybody to have 100% access to them, which is why I'd rather have a builtin version |
03:42 |
|
Hunterz joined #minetest-dev |
03:49 |
paramat |
i would like to push this later #2623 back in ~1hr |
03:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/2623 -- Conf.example: Update, fix and improve mapgen flags docs by paramat |
03:49 |
|
paramat left #minetest-dev |
05:03 |
hmmmm |
hrmm |
05:04 |
hmmmm |
darnit where'd paramat go |
05:19 |
|
paramat joined #minetest-dev |
05:19 |
paramat |
here |
05:20 |
paramat |
i'll wait for you to push 'serialize schematic' first, to avoid conflicts |
05:30 |
|
jin_xi joined #minetest-dev |
05:30 |
hmmmm |
well |
05:30 |
hmmmm |
i don't think you'd like it right now |
05:31 |
hmmmm |
if you were to call serialize_schematic("foobar.mts", "lua") you'd get a table with untranslated node IDs |
05:31 |
hmmmm |
(well, if you were to call that during mod initialization, i mean to say) |
05:32 |
hmmmm |
the solution I am coming up with in another commit, to introduce the concept of the "node resolution strategy" |
05:32 |
hmmmm |
which you'll be able to globally set for all node resolving operations, or specifically during serialize_schematic |
05:32 |
paramat |
actually there are no conflicts with my PR 2623 =) |
05:33 |
hmmmm |
three node resolution strategies: NODE_RESOLVE_DIRECT, which directly looks up the content ID based on the contents of the name table currently existing, which means that node resolution may fail if a certain mod it contains nodes from hasn't been loaded yet |
05:34 |
hmmmm |
then NODE_RESOLVE_DEFERRED, which pends node resolutions until the registration phase has ended at which point it goes back and resolves all the nodes used in the schematic |
05:34 |
hmmmm |
and then a third, NODE_RESOLVE_NONE, where it stores a direct string list of what was loaded from the schematic definition (table or mts file, doesn't matter) and doesn't attempt to perform any resolution whatsoever |
05:35 |
hmmmm |
for schematic serialization, you'd want to use NODE_RESOLVE_NONE no doubt and then perhaps there should be a flag to not auto-register the schematic upon loading |
05:41 |
paramat |
i see. personally all i need a the moment is to (within a mod for the purpose) define a schem using a lua table, and have a way to save that as a .mts file |
05:46 |
|
Hunterz1 joined #minetest-dev |
05:53 |
paramat |
i'll push #2623 in a few minutes |
05:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/2623 -- Conf.example: Update, fix and improve mapgen flags docs by paramat |
05:56 |
hmmmm |
paramat |
05:57 |
hmmmm |
that's not just a doc update, you slipped in new default parameters |
05:57 |
hmmmm |
that would break worlds |
06:02 |
paramat |
ah.. |
06:02 |
hmmmm |
here's the way flags work: |
06:03 |
hmmmm |
there is always a baseline, default parameter hard coded into the engine |
06:03 |
hmmmm |
flags loaded out of config files or modified in lua are differences to that default parameter |
06:03 |
hmmmm |
so that way you don't need to specify "light" in mg_flags in the config |
06:03 |
hmmmm |
meaning that if people didn't explicitly put jungle, or dungeons, it would start doing so |
06:04 |
paramat |
oh man i didn't see that |
06:04 |
hmmmm |
same with worlds that were already created |
06:04 |
paramat |
will remove that stuff then, doc update only |
06:04 |
hmmmm |
map_meta.txt contains all flags available written in their explicit forms, but if a new default were added then it'd activate it by default in those map_meta.txts |
06:05 |
hmmmm |
so then you'd get inconsistent worlds |
06:07 |
paramat |
thanks for the review, updating PR.. |
06:22 |
paramat |
updated, will push when checks are done |
06:33 |
paramat |
now pushing 2623 |
06:38 |
paramat |
done |
06:43 |
|
paramat left #minetest-dev |
06:53 |
|
OldCoder joined #minetest-dev |
07:03 |
|
Darcidride joined #minetest-dev |
07:09 |
|
kilbith joined #minetest-dev |
07:26 |
|
JeDa joined #minetest-dev |
07:49 |
|
err404 joined #minetest-dev |
08:01 |
|
Yepoleb_ joined #minetest-dev |
08:01 |
|
Krock joined #minetest-dev |
09:21 |
|
Jordach joined #minetest-dev |
09:54 |
|
Darcidride joined #minetest-dev |
09:59 |
|
est31 joined #minetest-dev |
10:26 |
est31 |
about mini-gmp vs. hard dependency: I think soft dependencies are better than hard ones. git can manage that additional 4k lines file. |
10:26 |
|
Krock joined #minetest-dev |
10:31 |
est31 |
we should urge distro packagers to depend on real libgmp though. mini-gmp is clearly inferior. |
11:16 |
|
selat joined #minetest-dev |
11:40 |
|
chchjesus joined #minetest-dev |
12:04 |
|
Darcidride_ joined #minetest-dev |
12:18 |
|
Darcidride_ joined #minetest-dev |
12:37 |
|
cd2 joined #minetest-dev |
12:37 |
cd2 |
hi |
12:42 |
|
chchjesus joined #minetest-dev |
13:42 |
|
selat joined #minetest-dev |
13:44 |
|
err404 joined #minetest-dev |
14:12 |
|
Darcidride__ joined #minetest-dev |
14:58 |
|
jin_xi joined #minetest-dev |
15:10 |
|
hmmmm joined #minetest-dev |
16:17 |
|
leat joined #minetest-dev |
16:23 |
|
Hunterz joined #minetest-dev |
16:44 |
|
gtux joined #minetest-dev |
16:44 |
|
SopaXorzTaker joined #minetest-dev |
16:49 |
|
Taoki[laptop] joined #minetest-dev |
16:53 |
|
leat joined #minetest-dev |
16:53 |
|
rubenwardy joined #minetest-dev |
16:56 |
|
SopaXorzTaker joined #minetest-dev |
16:58 |
|
SopaXorzTaker joined #minetest-dev |
17:02 |
ShadowNinja |
Any objections to removing the "simple menu" that's used for Android? It prevents you from having more than one world and has a lot of code duplication. |
17:03 |
rubenwardy |
Would that remove touch friendliness? |
17:12 |
|
johnnyjoy joined #minetest-dev |
17:13 |
ShadowNinja |
rubenwardy: No, it would just give a slightly different menu layout. |
17:14 |
rubenwardy |
Okay |
17:15 |
|
Calinou joined #minetest-dev |
17:15 |
rubenwardy |
My phone is terrible, doesn't have enough memory. I recommend you stay away from Huawei, their phones and customer service are/is crap. </partially-offtopic-rant> |
17:19 |
Calinou |
Backdoorhei |
17:19 |
Calinou |
(this is widely known) |
17:19 |
|
Hijiri joined #minetest-dev |
17:19 |
rubenwardy |
Lol |
17:22 |
Hijiri |
what does minetest use gmp for? |
17:25 |
Calinou |
authentication, IIRC |
17:26 |
Hijiri |
oh |
17:47 |
ShadowNinja |
It doesn't use GMP yet, it may be added in the future though. |
17:49 |
|
MinetestForFun joined #minetest-dev |
17:50 |
Hijiri |
oh x 2 |
17:50 |
Hijiri |
thanks guys |
18:08 |
|
Hijiri joined #minetest-dev |
18:10 |
|
Hijiri joined #minetest-dev |
18:14 |
|
Hijiri joined #minetest-dev |
18:19 |
|
AnotherBrick joined #minetest-dev |
18:27 |
|
est31 joined #minetest-dev |
18:38 |
|
nrzkt joined #minetest-dev |
18:39 |
nrzkt |
ShadowNinja: agree for the unification of Android and PC platforms, Android menu is not pertinent. |
18:56 |
* est31 |
tests whether hmmmm is right and minetest doesnt compile for c++11... |
18:58 |
rubenwardy |
We should take ideas from HTML's responsive layouts |
18:58 |
rubenwardy |
Although CSS is horrible and fiddly |
19:03 |
est31 |
hmmmm is right |
19:03 |
est31 |
aaand its inside jsoncpp... |
19:04 |
hmmmm |
hrm |
19:07 |
est31 |
.git/rebase-apply/patch:5429: new blank line at EOF. |
19:07 |
est31 |
very easy to track down lol |
19:07 |
est31 |
(trying SN's patch) |
19:10 |
est31 |
but it seems only to be a problem with clang |
19:10 |
est31 |
http://reviews.llvm.org/rL201729 |
19:11 |
|
ElectronLibre joined #minetest-dev |
19:15 |
|
MinetestForFun joined #minetest-dev |
19:18 |
|
Warr1024 joined #minetest-dev |
19:18 |
|
Warr1024 joined #minetest-dev |
19:26 |
|
Robert_Zenz joined #minetest-dev |
20:03 |
|
Hijiri joined #minetest-dev |
20:15 |
|
Miner_48er joined #minetest-dev |
20:37 |
|
paramat joined #minetest-dev |
20:39 |
|
Etzos joined #minetest-dev |
20:42 |
|
ElectronLibre left #minetest-dev |
20:43 |
paramat |
hmmmm i just realised *=/ i can move the jungles and dungeons flags from mtgame's .conf into the engine's .conf, i guess this way is okay? |
21:18 |
hmmmm |
yse, that would work fine |
21:20 |
paramat |
good, will prepare a PR |
21:53 |
|
Hijiri joined #minetest-dev |
22:01 |
paramat |
okay will push #2625 later if approved |
22:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/2625 -- Defaultsettings: Add dungeons and jungles flags. Update conf.example by paramat |
22:22 |
|
Lunatrius joined #minetest-dev |
22:28 |
|
Hijiri_ joined #minetest-dev |
22:46 |
|
paramat left #minetest-dev |
23:46 |
|
Hijiri joined #minetest-dev |