FOSS gamedev and creative worlds

An idea: We might implement client-side modding support. The server-side modding is just fine for most mods, but first of all mobs are painfully slow.
A client API can be used for e.g. drawing 2D pictures on the player's screen, render screenshot textures for blocks, fast entities (chest lid, move player with minecart, mobs, rays/bullets --> entities), manipulate camera...
The client must be synchronized with the server (shouldn't be too hard)
and the code could still be downloaded from the server so there is no need to install mods when playing on servers (or should there be? --> security)

This is my proof-of-concept (don't expect anything usable, it's just an experiment):
https://github.com/Jeija/minetest/tree/clientside_mods

This could be useful. Transfering some code to client and execute it might reduce lag issues.

Jeija wrote:and the code could still be downloaded from the server so there is no need to install mods when playing on servers (or should there be? --> security)

I think disabling os and io modules should be fine (not sure though).

shouldnt such stuff be built in? we are talkin bout basic things that r not workin as they should be.
its not the matter of modding but fixin issues.

xyz wrote:

Jeija wrote:and the code could still be downloaded from the server so there is no need to install mods when playing on servers (or should there be? --> security)

I think disabling os and io modules should be fine (not sure though).

What is needed is a mod-accessible database engine of sorts, since mods today are dependent on datafiles for things that can;t be done in one node. Some kind of virtualized SQLite or access to a central MySQL database with limitations imposed.

I can help but be aware that i am busy studying C++ and makeing my own minetest modding program

I'm not sure anymore if this actually is the direction we want to go. Maybe there's more potential in coding the whole client in c++, especially when targeting slower PCs.

Every mod that I've wanted to make lately has been impossible due to the limitations in using formspec; I think that mods need to have some functionality to add custom UI beyond formspec, and since that is all client-side it would necessitate a client-side API.

That said, I think that minetest could do to move more of the game logic into the engine; mobs are painfully laggy when implemented as mods and would benefit greatly from more engine support. Carts have already gotten engine support, and we've went from an unbearably laggy and buggy carts implementation to a more bearable, responsive, and much less buggy one (though I think there are some things that could still use some work…).

What we need are commands for manipulating nodes that aren't sent to the server, and another set of commands for doing something and sending it to the server. Important things to implement are rate limiting and for the server to be able to disable mod-sent messages such as node_dig if the server autodetects vandalism, or as per the wish of the server owner.

hdastwb wrote:Every mod that I've wanted to make lately has been impossible due to the limitations in using formspec; I think that mods need to have some functionality to add custom UI beyond formspec, and since that is all client-side it would necessitate a client-side API.

That said, I think that minetest could do to move more of the game logic into the engine; mobs are painfully laggy when implemented as mods and would benefit greatly from more engine support. Carts have already gotten engine support, and we've went from an unbearably laggy and buggy carts implementation to a more bearable, responsive, and much less buggy one (though I think there are some things that could still use some work…).

Carts have gotten engine support? When did this happen? I can't wait for more responsive carts.

My 2c is that mobs should be implemented in C++. Or at least the bulk of it with mods being able to make new mods to use the C++ code. (not a coder but seems logical that mobs should be done in C++)

Temperest wrote:

hdastwb wrote:Every mod that I've wanted to make lately has been impossible due to the limitations in using formspec; I think that mods need to have some functionality to add custom UI beyond formspec, and since that is all client-side it would necessitate a client-side API.

That said, I think that minetest could do to move more of the game logic into the engine; mobs are painfully laggy when implemented as mods and would benefit greatly from more engine support. Carts have already gotten engine support, and we've went from an unbearably laggy and buggy carts implementation to a more bearable, responsive, and much less buggy one (though I think there are some things that could still use some work…).

Carts have gotten engine support? When did this happen? I can't wait for more responsive carts.

As of 4.4, an the ability to attach the player to things was added to the Lua API. Thus, the carts mod was re-implemented to take advantage of the functionality. I'm not sure if they've finished adding features back in from the old version, but, over the old version that seemed to use the teleportation mechanism to transport the player, the improvements are markable.

If you have 4.4 installed and download the latest version of the carts mod, you should be set. Though, bear in mind that the physics in these versions has gotten a bit more accurate, so you'll probably have to power the cart with periodic mesecon torches in order to go anywhere that's not downhill…

Moving to luajit ?

I heard from several people that LuaJIT is not really faster or even slower.

Can you compile test with it (according to their website you need just link to luajit, instead of lua5.1 library). I'm not a big pro in programming, so i don't know how can i make it :)
p.s. if you make it, upload binaries (linux or windows) please

madarexxx wrote:Can you compile test with it (according to their website you need just link to luajit, instead of lua5.1 library). I'm not a big pro in programming, so i don't know how can i make it :)
p.s. if you make it, upload binaries (linux or windows) please

I've been running LuaJIT Minetest with my testing version for the last couple weeks! I really haven't noticed the difference much, but I'm on a higher-end machine so I don't have much lag in singleplayer anyway…

It is more or less fully compatible with the standard Lua distribution and compiled and ran perfectly by just changing the linking procedure in the CMake files and removing some check in serialize.lua that looked for quirky escaping rules. However, the main issue is building LuaJIT itself; I linked my version dynamically against my system-wide installation of the library. LuaJIT is very easy to build when you can just use the automake tools, but it has a somewhat non-standard build procedure and will not integrate as well with CMake as the standard distribution does. In fact, I cannot figure out at all how to convince CMake to compile LuaJIT properly, but once you've got a compiled version it works pretty smoothly.

So, Minetest does play well (in singleplayer, mind you; I haven't hosted any servers yet) with LuaJIT, though the fact that LuaJIT doesn't seem to mesh well with the CMake build system will hinder packaging. I doubt that Linux binaries would be all that useful since there are so many different Linux systems, almost everything in Linux is dynamically linked, and you haven't specified your architecture (I'm running x86_64, if you've got 32-bit Linux you're likely to really confuse your processor by running 64-bit programs). However, I may look at putting together a MinGW win32 build the next time that I'm Windows-side…

I'm also not really aware of any cases in which LuaJIT is slower than standard Lua; from what I understand, the JITing makes the pure Lua indisputably faster and the native linking is much more direct which should also aid in the speed of library-intense things like Minetest mods. I would be interested to hear where it might be slower, though…

I think maybe the people who said LuaJIT is slower may have confused LuaJIT with pre-compiled Lua bytecode? The precompiled bytecode files are usually larger than the normal Lua scripts, which might make them load slower. Precompiled bytecode is not the same thing as LuaJIT.

Menche wrote:I think maybe the people who said LuaJIT is slower may have confused LuaJIT with pre-compiled Lua bytecode? The precompiled bytecode files are usually larger than the normal Lua scripts, which might make them load slower. Precompiled bytecode is not the same thing as LuaJIT.

And they're probably the same people who think Java is primarily a compiled language…

Precompiled is longer load, faster execution. So, a longer server startup, but less lag once it starts.

hdastwb, i've 32-bit LMDE, and 32-bit W7 :)

I've been in Windows all day in order to download software; I've also had a chance to compile Minetest with LuaJIT. I've uploaded the binary to my site here:
http://hdastwb.heliohost.org/minetest-0.4.4-win32-jit.zip

I haven't noticed much of a difference, but I haven't found anything (besides some of the escaping tests in serialize.lua) that broke either.

search algorithm on 100 nodes graph depth, loop: 100 times
(one technic batbox, 100 wires connected,20 solar panels. search repeated 100x inside one abm call)

time of execution (LuaJIT):
1.32
1.1
1.45
1.39
1.53
1.55
1.52
1.5
1.29
1.16
1.36
1.3
1.26
1.42
1.4
1.37
1.38
1.62
1.37
1.54

total time: 27.83s
Average time: 1,3915s


time of execution (Lua):
2.68
2.75
2.71
2.97
3.02
3.29
3.06
3.35
3.05
3.26
3.39
3.12
3.08
3.22
3.26
3.31
3.32
3.12
3.11
3.46

total time: 59.42s
Average time: 2,971s

Those are some impressive numbers.

I thought about this but wasn't sure. Since in most cases we can code things in the client which are triggered by the server API. I'm not sure exactly what allowing LUA on the client could achieve past that, and it could risk complicating things more for no additional gain.

Currently I'm neutral about this. I'd only suggest such a thing if there's a clear case of something that can't be coded in the client and called with server LUA, otherwise I see it doing more harm than good.