e.e
Divine Intellect
- Joined
- Sep 16, 2016
- Messages
- 476
- Solutions
- 1
- Reaction score
- 226
Background:
Sometime around mid August I started working on an OTS project mostly for fun that is written entirely in Python.
I've named it PyOT2 after the now defunct and abandoned PyOT project simply because they're both projects written in Python, even though they share no codebase beyond PyOT's C implementation of XTEA encryption/decryption, which I modified slightly anyways for a 2x performance gain.
Vision:
Rather than implementing some traditional Otserv engine in Python I'm working on a simpler and completely modular event-driven system which should allow for much easier customization and perhaps a plugin/P&P-like system.
How PyOT2 compares with traditional OTS engines coded in C++:
PyOT2 Pros:
* Easier to read and modify the engine's source code since the server is 100% coded in Python and Python only.
* Easier to customize (simpler and more transparent/better organized code design).
* Python code has much smaller margins of errors and better exception handling than C++, meaning that instead of the server ever unexpectedly crashing in various circumstances and you having to attach a debugger to it and recreate the crash cause to figure out what went wrong, Python will gracefully handle every exception that's thrown at it without crashing and makes it very clear to the user what line of code in what file caused the exception without being overly verbose or overdoing it.
* Way fewer lines of code needed to accomplish something, which imo. makes coding way more fun.
* Still able to pretty much catch up to the speed of traditional engines in most cases with some effort put into using 3rd party modules or by writing your own.
* Single-threaded asynchronous model. No race conditions, no locks or mutexes, no deadlocks or other forms of multithreaded performance degradation, yet still completely asynchronous.
* No need to ever compile or re-compile since Python is an interpreted language. You simply run the server like any other application through Python and the server is up and running within fractions of a second.
* Very cross-platform. Should be able to run on pretty much any platform with Python3.5+ installed without having to worry about setting up and compiling anything first.
PyOT2 Cons:
* Offers weaker performance out of the box compared to traditional engines (but has the potential to pretty much catch up in every way with a little bit of effort).
* High-performance libraries and algorithms developed on my own would not be included for free (except for any donated by volunteers or taken directly from any open source projects).
* Python apparently does not release freed up memory back to the OS while still running, but it will still re-use freed up memory, so won't turn into a memory-hog as long as you have some basic common sense not to deep-copying a full real map in memory on a live/public server for example.
Progress:
As of the 24th of October the server is currently as good as stateless, everything is statically defined, there's no multiplayer interaction available, no map loading, and no saving of any states even between a single login and logout.
Features like this will be added along the way after the initial experimental phase is over.
Current client actions working as of the 1st of October:
* Logging in.
* Logging out.
* Moving around in all directions.
* Turning.
* In-game commands (currently only !pos).
* Normal talking in default.
* Looking at items and tiles which outputs formatted network data in-game.
* Throwing items which just outputs formatted network data in-game.
Screenshot from early October:
Current technical features:
* Less than 500 lines of code and much of it is simply formatted text (will obviously grow over time).
* Recognizes and names all standard 7.7 opcodes.
* Single threaded application with separate game and network logic.
* Lightning-speed network code (100k+ connections per second according to 3rd party benchmarks).
* Near C++ speed RSA encryption/decryption (0.7ms on my 8 yrs old laptop vs 0.4-0.7ms with C++) implemented by myself (no 3rd party dependencies).
* XTEA encryption/decryption 10x slower than C++ (PyOT2 speed: 10µs for small packets on my old laptop without any 3rd party dependencies. Will likely be able to achieve near C++ speeds later on as I haven't tried implementing it yet myself).
* Current CPU consumption on my old laptop running around/holding down key or map clicking with max character speed: 0.3-0.7% of one core.
* Items (objects.srv) parsing.
* Partial map (sec format) parsing - work in progress.
Interests / Looking for:
I'm interested in contact and possibly collaborating or exchanging favors with other positive-minded and helpful developers who are interested either in this project or other creative OT-related projects (and discussing or talking about these interests in the latter case).
Voluntary code-contributions are very much appreciated as well, and I will always offer my services in return for valuable contributions, though to be clear: any actual expectations of rewards or services should be formally and clearly discussed with me before-hand rather than assumed on the go.
Tasks open for contributions (evolving list):
* OTBM map format/parsing.
* OTB items format/parsing.
* SEC map parsing of recursive "Content={}" blocks using mainly a primitive C++ toolset. The rest of the parsing is already done.
* Comparing different protocol versions, in particular: 6.4, 7.1, 7.4, 8.0 and 8.6 with 7.7.
* Algorithm for XTEA encryption/decryption in pure-python.
Contact & development info:
Git: Fibrosis/PyOT2
Discord: Add e.e#0480 and msg me at least once so I know what it's about or goto OTWorld's Public Discord Server.
Sometime around mid August I started working on an OTS project mostly for fun that is written entirely in Python.
I've named it PyOT2 after the now defunct and abandoned PyOT project simply because they're both projects written in Python, even though they share no codebase beyond PyOT's C implementation of XTEA encryption/decryption, which I modified slightly anyways for a 2x performance gain.
Vision:
Rather than implementing some traditional Otserv engine in Python I'm working on a simpler and completely modular event-driven system which should allow for much easier customization and perhaps a plugin/P&P-like system.
How PyOT2 compares with traditional OTS engines coded in C++:
PyOT2 Pros:
* Easier to read and modify the engine's source code since the server is 100% coded in Python and Python only.
* Easier to customize (simpler and more transparent/better organized code design).
* Python code has much smaller margins of errors and better exception handling than C++, meaning that instead of the server ever unexpectedly crashing in various circumstances and you having to attach a debugger to it and recreate the crash cause to figure out what went wrong, Python will gracefully handle every exception that's thrown at it without crashing and makes it very clear to the user what line of code in what file caused the exception without being overly verbose or overdoing it.
* Way fewer lines of code needed to accomplish something, which imo. makes coding way more fun.
* Still able to pretty much catch up to the speed of traditional engines in most cases with some effort put into using 3rd party modules or by writing your own.
* Single-threaded asynchronous model. No race conditions, no locks or mutexes, no deadlocks or other forms of multithreaded performance degradation, yet still completely asynchronous.
* No need to ever compile or re-compile since Python is an interpreted language. You simply run the server like any other application through Python and the server is up and running within fractions of a second.
* Very cross-platform. Should be able to run on pretty much any platform with Python3.5+ installed without having to worry about setting up and compiling anything first.
PyOT2 Cons:
* Offers weaker performance out of the box compared to traditional engines (but has the potential to pretty much catch up in every way with a little bit of effort).
* High-performance libraries and algorithms developed on my own would not be included for free (except for any donated by volunteers or taken directly from any open source projects).
* Python apparently does not release freed up memory back to the OS while still running, but it will still re-use freed up memory, so won't turn into a memory-hog as long as you have some basic common sense not to deep-copying a full real map in memory on a live/public server for example.
Progress:
As of the 24th of October the server is currently as good as stateless, everything is statically defined, there's no multiplayer interaction available, no map loading, and no saving of any states even between a single login and logout.
Features like this will be added along the way after the initial experimental phase is over.
Current client actions working as of the 1st of October:
* Logging in.
* Logging out.
* Moving around in all directions.
* Turning.
* In-game commands (currently only !pos).
* Normal talking in default.
* Looking at items and tiles which outputs formatted network data in-game.
* Throwing items which just outputs formatted network data in-game.
Screenshot from early October:
Current technical features:
* Less than 500 lines of code and much of it is simply formatted text (will obviously grow over time).
* Recognizes and names all standard 7.7 opcodes.
* Single threaded application with separate game and network logic.
* Lightning-speed network code (100k+ connections per second according to 3rd party benchmarks).
* Near C++ speed RSA encryption/decryption (0.7ms on my 8 yrs old laptop vs 0.4-0.7ms with C++) implemented by myself (no 3rd party dependencies).
* XTEA encryption/decryption 10x slower than C++ (PyOT2 speed: 10µs for small packets on my old laptop without any 3rd party dependencies. Will likely be able to achieve near C++ speeds later on as I haven't tried implementing it yet myself).
* Current CPU consumption on my old laptop running around/holding down key or map clicking with max character speed: 0.3-0.7% of one core.
* Items (objects.srv) parsing.
* Partial map (sec format) parsing - work in progress.
Interests / Looking for:
I'm interested in contact and possibly collaborating or exchanging favors with other positive-minded and helpful developers who are interested either in this project or other creative OT-related projects (and discussing or talking about these interests in the latter case).
Voluntary code-contributions are very much appreciated as well, and I will always offer my services in return for valuable contributions, though to be clear: any actual expectations of rewards or services should be formally and clearly discussed with me before-hand rather than assumed on the go.
Tasks open for contributions (evolving list):
* OTBM map format/parsing.
* OTB items format/parsing.
* SEC map parsing of recursive "Content={}" blocks using mainly a primitive C++ toolset. The rest of the parsing is already done.
* Comparing different protocol versions, in particular: 6.4, 7.1, 7.4, 8.0 and 8.6 with 7.7.
* Algorithm for XTEA encryption/decryption in pure-python.
Contact & development info:
Git: Fibrosis/PyOT2
Discord: Add e.e#0480 and msg me at least once so I know what it's about or goto OTWorld's Public Discord Server.
Last edited: