+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Discussion (https://forum.cuberite.org/forum-5.html)
+--- Thread: Hey! (/thread-1483.html)
Pages:
1
2
Hey! - qaisjp - 06-11-2014
Hey, I'd just like to introduce myself and get a few questions answered...
I'm qaisjp and I'm an avid lua fan
Lua'ing since 2010. I think this is a great project and even though this started out in 2011... it's just great to see this awesome project
Anyway, jumping forward with the questions:
- does it have a complete re-implementation of the current jar server?
- what does this have that bukkitcraft doesn't have (besides sexc lua and cpp)
- what does this NOT have?
- is there a todo list?
- any game breaking bugs?
- authentication? "offline servers" allow pirates, does mc-server also handle authentication?
- unless passwords are salted client-side, can't a server owner steal minecraft accounts during authentication?
You have no idea how happy I am to see this combination: GitHub + Minecraft + Lua.
Wooow
Minecraft was going to be one of the things that would help me expand from lua as my main language... but I think this will change that.
Also, just a shameless advertisement for a great mod
.
RE: Hey! - worktycho - 06-11-2014
To reply:
1) We are Not complete. See github issues for examples of missing features.
2) speed - we can run a 5 user server on a raspberry pi, (soon to be implemented includes handling of OOMs, GPU acceleration)
3) Mob AI, TNT Carts, Some Biomes, ... (See github issues)
4) Github issues
5) Sometimes (but usually fixed quickly)
6) We implement authentication
7) We never get your password, thats all handled by mojang.
RE: Hey! - FakeTruth - 06-11-2014
Hi! Welcome to the forums
Please see this thread for features and missing features https://forum.cuberite.org/showthread.php?tid=499
RE: Hey! - xoft - 06-11-2014
Hello and welcome.
You have come in the right time, I was just thinking about posting some Lua-related questions in the Lua world, fishing for answers; perhaps you can help me out then. That is, if I understood right and you are a developer familiar with Lua
We're having quite a lot of trouble in regards with Lua + threading. Our current model is "one lua state per plugin", and since the server uses multiple threads, it uses a mutex to lock the access to the entire plugin, to prevent parallel access to the lua state. However, most of the lua API calls can be blocking - for example querying a block needs to lock the world, and moving a player between worlds needs to lock two worlds. This has caused quite a lot of deadlocks, and is currently a performance bottleneck for plugins - we cannot use any blocking operations such as network I/O, if the plugin is called periodically by the world's tick thread, because it would block the (timing-critical) thread for considerable amounts of time.
So what does the Lua world have to offer thread-wise to solve this?
I was thinking about making plugins capable of using multiple lua states, so that one such lua state can take care of the world tick thread, and another lua state can take care of the webadmin stuff, and another can do some big calculations, etc. Unfortunately that would mean that the plugin wouldn't be able to share information between those states, there's effectively zero means of communication between them.
RE: Hey! - qaisjp - 06-12-2014
I've been using Lua for quite some time but I've only just begun learning how to embed Lua, so my reply may not be completely correct. I did come from MTA:SA and over there we use plugins too (except we call them "resources" instead of "plugins"). Right now we do use one lua VM per plugin/resource (I think that's what you meant when you said "one lua state per plugin") but later on we found that it was very frustrating when it came to libraries. As a result of this we've had a major fork in the project with loads of improvements, therefore I would recommend that you actually split it into one very big VM but sandboxing each plugin to an extent.
[strike]Here is a fancy image I've taken from the project documentation to show you what I mean[/strike] Sorry, I couldn't find the right picture, but this shows it a bit. But yeah, the point is, all the plugins run in one VM whilst being sandboxed. You get the security and the ability to share custom made classes between plugins. Resources for us are very high security (they are sandboxed, certain functions like os.execute are removed) but I'd be able to provide my insight if I knew whether you're intending plugins to have a limited access to the host server. Or an ACL system, allowing the ability to grant/limit access to functions in the VM.
Anyway like I said, I'm not experienced with the implementation very much but I do know people and I've asked the main developers of multiple mods I'm involved in that has a similar mechanism to what you're doing
Specifically, this and this.
RE: Hey! - xoft - 06-12-2014
Our problem is more or less the very opposite - we want to split into many VMs so that code running in one part of the plugin doesn't cause another part of the plugin to block. Our plugins can register callbacks that the server calls whenever the event occurs; for the callback to execute safely it needs to lock the entire VM; this serializes all the callbacks on the CPU, which means that if a plugin registers for an OnTick event and a webadmin page handler, the world tick thread gets blocked every time the webadmin page is being accessed.
RE: Hey! - FakeTruth - 06-12-2014
In my graduation project I use only a single VM for all plugins. It gives incredible flexibility in regards to what plugins are capable of and how they communicate with each other.
I think the only way to not completely block each thread that wants to access the Lua state is by yielding at each function call, but I'm not sure how that would impact performance.
RE: Hey! - qaisjp - 06-13-2014
(06-12-2014, 06:31 AM)xoft Wrote: Our problem is more or less the very opposite - we want to split into many VMs so that code running in one part of the plugin doesn't cause another part of the plugin to block. Our plugins can register callbacks that the server calls whenever the event occurs; for the callback to execute safely it needs to lock the entire VM; this serializes all the callbacks on the CPU, which means that if a plugin registers for an OnTick event and a webadmin page handler, the world tick thread gets blocked every time the webadmin page is being accessed.
Okay so I asked about and they said that it is blocking but for they haven't had a problem with it since ~2006. I also asked about the web interface and they said "[when someone opens a web page] it does [block the server], but only as long as the webserver generates the HTML output (and that's usually fast enough)".
But it's a bit scary that you need a call back just to get a player by their name. Almost, erm, makes me want to just use the java server :/
For us, it's just
-- Case insensitive
p = Player("qaisjp")
p:Kill()
p.vehicle = Vehicle(411, 0, 0, 0) -- warp player into a newly made vehicle at Vector3(0,0,0)
RE: Hey! - bearbin - 06-13-2014
Why's it scary? It makes sense because of multithreading. (unless you can do some sort of thing of locking a player object on creation and then unlocking it when it goes out of scope???)
RE: Hey! - FakeTruth - 06-13-2014
qaisjp is right, it completely messes up the flow of your code.