Eat_My_Shortz wrote:
It would be nice to prevent people in common areas from flying around and such. Otherwise it might become a common occurrence in the city to see people flying, which would kind of ruin it. As people have said, what people do in their own ages is their own business.
But I suppose it's hard to validate if the client has control over all of the avatar's movements.
In games where cheating is an issue, the server is the final arbiter of the game state, including movement. But that's extra work for the server, so it's not something you'd want to do unless there was a clear need. You're probably better off just relying upon server administrators to monitor users and ban those who don't behave. That also deals with forms of misbehaviour which can't be detected algorithmically (e.g. harassment via text or voice chat).
Quote:
With regards to malicious Python scripts from the server -- not sure if this has been stated explicitly already, but it is generally not possible (at least in CPython, the standard Python implementation which I assume Cyan is using) to secure Python against malicious scripts. Even if you want a game which only lets Python scripts call functions within the game engine, they can still open networks, files, and anything else. Several attempts to secure Python, such as the deprecated rexec library, have been found to have unfixable holes.
MOUL uses a custom interpreter, so the situation is somewhat easier than trying to harden the stock Python interpreter. It's still harder than hardening a "minimalist" language such as Lua or JavaScript, though (mainly due to Python's habit of exposing its internals). If and when source code is available, we'll have a better idea of whether the Python implementation can be hardened sufficiently; until then, it's just guesswork.
Quote:
The only way to guard against malicious Python scripts is to hand-inspect them before letting them go out to clients.
Which would largely defeat the point of open-source.
Quote:
Incidentally, this is why games use Lua, not Python, because that language *is* restricted by default to only the game-supplied function calls.
With a custom Python interpreter, you can control what is and isn't accessible from Python. The hard part is if you want a specific function to be accessible to some Python code but not universally accessible. Where all of the restricted-execution systems tend to fall down is that there's a vast number of places to "hang" code, which makes it almost impossible to enforce a distinction between different types of code (although it has been said that MOUL does use separate sub-interpreters for different bits of code, which is more robust than trying to isolate sections of code within a single interpreter).