Hey!
#15
(06-13-2014, 03:29 AM)worktycho Wrote: Ah so your single threaded. That makes things soooo much easier. Problem is that in mcserver's architecture you have to hold the players lock when using a player object. Otherwise the object can be removed right under you're code. So if we had an api like you're example:
Code:
p = Player("qaisjp")
// what happens if another thread deletes p here?
Kick(p, "Because I say so")
So you have to hold the lock whilst doing stuff with a player. Aquiring the lock is easy. The problem comes when we need to release it. There are two ways of doing this in lua. One is to __require__ that users call a function when they are finished with the player. This is a horrible interface because people forget. And the other way is callbacks. So the choice was callbacks or explicit lock releases. And we went for callbacks because then you can't get it wrong and crash the server.
I'm probably going off on a tangent, but it probably works better in Minecraft because you guys actually have a server that is aware of the physical world (for us, only players + script created elements are synced). What's wrong with Lua's garbage collection system (for releasing a lock)? Why do you actually have to lock a player, can't you just "modify the data"?

If there was a way to schedule a disconnection it could work. For example:

1. person times out
2. server catches timeout during a script
3. schedule a hook call: "disconnect for reason "timeout" event"
3. server allows script to do what it wants to do until the script ends, return a success for everything (allow the getting of the name) (I'm not sure what kind of client-only capabilities are there, so a script could probably not do everything it is allowed to do).
4. if a player is kicked in the script, the client obviously would just get a timeout message but the kick event overwrites the schedule event (server thinks its a kick, client thinks its just a time out)
5. do kick message console log
6. call disconnect event for type "kick"

I think this works for us because we have an element based system where instead of having direct access to a client (so if a client disconnects, the player element is gone), a player is bound to a client. The only time a player element variable can turn nil (or if isElement(player) == false) is if the argument is passed around in a timer or if it's accessed later in a table.


By the way, what is the time zone on this O_O
Reply
Thanks given by:


Messages In This Thread
Hey! - by qaisjp - 06-11-2014, 07:50 AM
RE: Hey! - by worktycho - 06-11-2014, 08:35 AM
RE: Hey! - by FakeTruth - 06-11-2014, 02:00 PM
RE: Hey! - by xoft - 06-11-2014, 05:45 PM
RE: Hey! - by qaisjp - 06-12-2014, 05:29 AM
RE: Hey! - by xoft - 06-12-2014, 06:31 AM
RE: Hey! - by qaisjp - 06-13-2014, 12:53 AM
RE: Hey! - by FakeTruth - 06-12-2014, 08:17 PM
RE: Hey! - by bearbin - 06-13-2014, 01:00 AM
RE: Hey! - by FakeTruth - 06-13-2014, 01:28 AM
RE: Hey! - by bearbin - 06-13-2014, 01:48 AM
RE: Hey! - by worktycho - 06-13-2014, 01:56 AM
RE: Hey! - by qaisjp - 06-13-2014, 03:03 AM
RE: Hey! - by worktycho - 06-13-2014, 03:29 AM
RE: Hey! - by qaisjp - 06-13-2014, 04:32 AM
RE: Hey! - by worktycho - 06-13-2014, 04:41 AM
RE: Hey! - by qaisjp - 06-13-2014, 04:49 AM
RE: Hey! - by worktycho - 06-13-2014, 05:07 AM
RE: Hey! - by qaisjp - 06-13-2014, 06:07 AM



Users browsing this thread: 4 Guest(s)