Time |
Nick |
Message |
00:44 |
|
AntumDeluge joined #minetest-dev |
00:56 |
|
ANAND joined #minetest-dev |
00:58 |
|
Cornelia joined #minetest-dev |
00:58 |
|
turtleman joined #minetest-dev |
01:22 |
|
Cornelia joined #minetest-dev |
01:36 |
|
Cornelia joined #minetest-dev |
02:28 |
ANAND |
I'm going to definitely try to implement SSCSM - it's an awesome feature and I don't want it to die. |
02:28 |
ANAND |
I noticed that nerzhul has made some progress in this direction (https://github.com/nerzhul/minetest/tree/csm_mod_sending) |
02:29 |
ANAND |
Am I allowed to work on top of his code? |
03:25 |
|
Cornelia joined #minetest-dev |
03:37 |
|
Cornelia joined #minetest-dev |
04:01 |
ANAND |
Hmm... not much progress has been made on his branch, unfortunately |
04:01 |
ANAND |
https://github.com/nerzhul/minetest/compare/077f231...a1dd0d3 |
05:07 |
ANAND |
Added `set_fov = true` to `minetest.features` in #7557 |
05:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/7557 -- Expose player FOV to Lua API by ClobberXD |
06:02 |
|
pmpp joined #minetest-dev |
06:06 |
|
ssieb joined #minetest-dev |
06:14 |
|
Ruslan1 joined #minetest-dev |
07:16 |
nerzhul |
ANAND good new to hear |
07:16 |
nerzhul |
if you have a design proposal before code propose it and i will amend |
07:17 |
nerzhul |
my work is very very raw |
08:25 |
|
AntumDeluge joined #minetest-dev |
08:43 |
|
proller joined #minetest-dev |
09:22 |
ANAND |
Thanks for the encouragement ;) |
09:23 |
ANAND |
I have no idea whatsoever regarding the implementation details. Perhaps I might get a better outline once I understand the all mod-related code |
09:27 |
nerzhul |
the main problem is the serialization and transport of mods |
09:41 |
ANAND |
True |
09:42 |
pmpp |
aren't in memory mod data structures to be replicated on client and server ? |
09:42 |
pmpp |
i asked about rpc earlier and i think it's maybe related |
09:55 |
ANAND |
Regular mods are purely server-side, and the client doesn't have any knowledge about them. |
09:55 |
pmp-p |
so csm mod transfer does not include any gamestate ? |
09:56 |
ANAND |
Oh I thought you were talking about regular mods, sorry |
09:57 |
pmp-p |
no i'm interested on client side only for now, server looks fine to me |
09:57 |
ANAND |
At present, the plan is to serialize the mod's files and send them over to the client. |
09:57 |
pmp-p |
as bytecode or source ? |
09:57 |
ANAND |
Probably as bytecode, for security reasons |
09:59 |
ANAND |
SSCSMs could use mod-channels (with convenience wrappers) behind the scenes for communication with their server-side counterpart. |
09:59 |
pmp-p |
i've read somewhere that luajit has machine specific features, won't it impact on bytecode used ? ( i don't know lua yet ) |
10:00 |
ANAND |
Not sure about that... |
10:00 |
ANAND |
It shouldn't affect the mods |
10:01 |
pmp-p |
as i'm currently developping a stackless vm for python bytecode i'm very interested in projects having already to move both bytecode and gamestate over the wire to see how it's done |
10:03 |
pmp-p |
i like the lua vm because it can be preempted too |
10:03 |
ANAND |
Likewise. I'm interested to see how other projects implement mod sending without any problems. |
10:05 |
ANAND |
Stuff like endianness and text encoding might pose a problem in this regard. |
10:06 |
pmp-p |
well i've seen yet quite a lot about gamestate serialization and i could say i retain Arrow or Capnproto but it's still a bit far from a running along a VM+bytecode |
10:06 |
pmp-p |
they say they are machine independant data structure but i've yet to see how it fits |
10:11 |
pmp-p |
and as client VM must be very well sandboxed, i was asking for RPC system used actually (if any as wiki is not clear about that) |
10:17 |
p_gimeno |
I don't see any gain in sending bytecode over source, and lots of inconveniences |
10:18 |
pmp-p |
i tend to agree, but bytecode does not need to compile on client side |
10:18 |
pmp-p |
and it could be faster to transmit |
10:19 |
pmp-p |
ideally both should be available |
10:19 |
p_gimeno |
Lua is quick to compile. Lua and LuaJIT bytecode are incompatible. LuaJIT 32 and 64 bit bytecodes are incompatible. |
10:19 |
pmp-p |
source while vm is not 100% safe, bytecode when optimized later |
10:20 |
pmp-p |
p_gimeno: thx for confirming that, i was not sure about portability of lua bytecode |
10:20 |
p_gimeno |
Lua-to-Lua is OK. LuaJIT-to-LuaJIT would be OK, except for the 64-bit transition. |
10:22 |
pmp-p |
why not something like lua-wasm ? wasm is fast and makes it easy to sandbox |
10:22 |
p_gimeno |
But Minetest clients can use either. I believe Windows ships with Lua by default and others with LuaJIT, I may be wrong though. |
10:23 |
p_gimeno |
Sending it gzipped would reduce bandwidth. |
10:25 |
p_gimeno |
Lua does not compile to wasm. |
10:26 |
pmp-p |
yeah not lua-jit but standard lua 5.3 seems to |
10:26 |
p_gimeno |
MT uses 5.1 only |
10:26 |
p_gimeno |
(for compatibility with LuaJIT) |
10:26 |
pmp-p |
they are so different ? |
10:27 |
p_gimeno |
yes |
10:27 |
pmp-p |
:( |
10:27 |
sfan5 |
pmp-p: even the server sandbox does not allow bytecode for security reasons |
10:27 |
sfan5 |
there is no way we would allow this on the client |
10:28 |
sfan5 |
p_gimeno: the windows build ships with luajit since a few years |
10:28 |
pmp-p |
sfan5: i agree but some modders in other games would not want to share code bits sometimes |
10:29 |
pmp-p |
minetest pleased me because it does not look "closed" |
10:29 |
sfan5 |
you can still obfuscate code |
10:30 |
sfan5 |
compare this with javascript, nobody has a problem there either |
10:30 |
p_gimeno |
sfan5: I said it reversed. Windows with LuaJIT and others with Lua. |
10:30 |
pmp-p |
dunno i try to never do javascript :p |
10:30 |
p_gimeno |
Not sure about the others though. |
10:32 |
sfan5 |
p_gimeno: that would also be wrong since at least debian, ubuntu and arch ship with luajit |
10:32 |
p_gimeno |
ah okay, that's what I was not sure about, thanks |
10:32 |
pmp-p |
indeed i had to choose beetween luajit5.1 and lua 5.2 or 5.3 |
10:41 |
p_gimeno |
LJ is THE choice. Sadly the 64 bit version has not been officially released, and MT developers are reticent to ship it by default. But LJ is the fastest interpreter out there, and many servers depend on its speed. |
10:42 |
pmp-p |
yeah for servers it makes perfect sense, not sure about the client vm for mods though |
10:42 |
p_gimeno |
(by fastest, I mean among open source interpreted languages) |
10:43 |
pmp-p |
is performance so important on the client ( which is expected to give full power to the game ) ? |
10:46 |
p_gimeno |
I can't answer that, but having a different interpreter for the server and for the client makes little sense to me, and unless explicitly disabled in compilation, the client includes a server. |
10:49 |
pmp-p |
depends on if client is doing physics or the server i guess |
10:51 |
rubenwardy |
I think that LuaJit is not-secure, so probably shouldn't be used for the client-side VM |
10:51 |
p_gimeno |
not secure in what sense? |
10:52 |
rubenwardy |
trying to find where I read i |
10:53 |
pmp-p |
https://github.com/GoogleBot42/IronBox claims to be a sandbox for luajit |
10:53 |
pmp-p |
but it's unclear about jit compilation |
10:53 |
rubenwardy |
our client VM kinda sucks in that there's no isolation from the Minetest process |
10:53 |
p_gimeno |
FFI is not secure, but FFI needs 'require'. There is a hashing attack that affects both Lua and LuaJIT (and I believe similar attacks apply to Python). |
10:56 |
pmp-p |
seems the safest is also the slowest... |
10:56 |
|
Fixer joined #minetest-dev |
10:56 |
p_gimeno |
yeah, securing things is slow :) |
10:57 |
p_gimeno |
The attack applies to any hash algorithm which does not have cryptographically secure randomization, and merely consists of deliberately causing collisions in order to slow down the VM or possibly cause a memory overflow. |
10:58 |
pmp-p |
p_gimeno: i would not chose ffi for cpython it *is* slow, but would compile code instead with nuitka+cython but same as luajit that would not be so portable |
11:02 |
p_gimeno |
I'm not aware of any security problem with LuaJIT vs. Lua other than through use of FFI. |
11:02 |
|
proller joined #minetest-dev |
11:09 |
p_gimeno |
btw rubenwardy I've been thinking about #7621. My thought is that it should not be called 'require', it should rather be a Minetest-specific function that is mod-aware. |
11:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/7621 -- Add secure require() function by rubenwardy |
11:10 |
rubenwardy |
that defeats the whole reason I'm adding it |
11:10 |
rubenwardy |
so that you can embed pure Lua libraries in builtin or a mod without having to modify them |
11:10 |
rubenwardy |
because Lua libraries use `require()`, not dofile |
11:11 |
p_gimeno |
ah |
11:11 |
rubenwardy |
it's not for loading mod files |
11:11 |
p_gimeno |
got it |
11:15 |
p_gimeno |
I think MT needs a new mod API |
11:18 |
rubenwardy |
lol |
11:19 |
p_gimeno |
it wouldn't be too hard to do on top of what there is now actually |
11:19 |
p_gimeno |
an object-oriented API where you do: local my_mod = minetest.register_mod('my_mod') |
11:19 |
|
ensonic joined #minetest-dev |
11:20 |
rubenwardy |
OO in Lua is noticiably slower for not much real benefit |
11:20 |
p_gimeno |
then all calls would go through it: my_mod:setpos(...) etc. |
11:20 |
rubenwardy |
for certain things, there is a very real benefit, eg: https://github.com/CapitalismGame/capitalism_game/blob/master/mods/capitalism/company/company.lua |
11:21 |
p_gimeno |
well, for one it would allow a very clear distinction of what mod called a particular API function |
11:21 |
rubenwardy |
oh, by OO I guess you mean giving each mod an API table which it calls with :? |
11:21 |
p_gimeno |
yes |
11:21 |
rubenwardy |
that's not that much slower |
11:22 |
p_gimeno |
it would also get rid of the need of using globals to share a mod's API functions |
11:27 |
p_gimeno |
... as well as get rid of using get_modpath just to detect if a mod is installed |
11:44 |
sfan5 |
p_gimeno: actually, I accidentially shipped gc64 luajit with 5.0 |
11:44 |
sfan5 |
but there's been no complains so I didn't revert it |
12:03 |
rubenwardy |
"accidentally" ;) |
12:04 |
pmp-p |
"i love when a plan comes together" |
12:50 |
|
Cornelia joined #minetest-dev |
13:07 |
|
Cornelia joined #minetest-dev |
13:40 |
|
pauloue joined #minetest-dev |
14:26 |
ANAND |
Hmm, where have the Travis XCode builds gone? |
14:26 |
rubenwardy |
disabled by sfan as broken |
14:26 |
ANAND |
Oh nice |
14:29 |
|
Taoki joined #minetest-dev |
14:33 |
ANAND |
#8682 is ready for re-review. |
14:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/8682 -- Make players immortal using immortal=1 by ClobberXD |
16:08 |
|
luk3yx joined #minetest-dev |
16:09 |
|
DS-minetest joined #minetest-dev |
16:23 |
|
troller joined #minetest-dev |
16:33 |
|
Krock joined #minetest-dev |
16:39 |
|
ensonic joined #minetest-dev |
16:41 |
|
Wuzzy joined #minetest-dev |
17:56 |
|
AntumD joined #minetest-dev |
18:48 |
|
ssieb joined #minetest-dev |
18:57 |
|
paramat joined #minetest-dev |
18:57 |
paramat |
merging #8702 |
18:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/8702 -- Mgfractal: Make non-fractal terrain optional by paramat |
19:44 |
paramat |
merging #8705 |
19:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/8705 -- Re-order mapgens in mainmenu and 'all settings' mapgen selection by paramat |
19:47 |
Krock |
sfan5: my laptop has some old mobile ATI radeon card installed. it surely uses OpenGL ES 2.0 |
19:48 |
Krock |
https://i.imgur.com/A8YiHdp.png |
19:49 |
Krock |
it's slow as hell but seems to work just fine |
19:50 |
sfan5 |
huh |
19:51 |
Krock |
can still check the glxinfo output but would need to start it .. meh |
20:29 |
sfan5 |
when do my PRs get merged? ;) |
20:37 |
|
troller joined #minetest-dev |
23:24 |
|
turtleman joined #minetest-dev |
23:37 |
|
AntumDeluge joined #minetest-dev |