woowoo wrote:How will you differentiate yourself from procon? In other words how will it be different or better?
I have a little 'goals' section in my readme that is supposed to address this, but I'll expand it.
#1: Crossplatform. Procon is .net/C# which severely limits where you can run the layer server. This is the biggest issue I think. I'm sure you can run procon in Mono, but that is a pretty heavyweight requirement, and I bet you'd run into some significant issues with how it deals with plugins. On the other hand PyRCon is written in python and uses libraries that are cross-platform, so it can be run from pretty much any system. (Mac OS X, Linux, BSD, Windows)
#2: Lightweight. Procon is not only a layer server, but also a GUI with tons of features (map overlay stuff, plugin downloader, etc.). I firmly believe that a more modular design where extra features like this are written as separate components that can be mixed and matched is better for server administrators. Its far more likely that a server will be run from a headless or lower powered machine / VPS than from a powerful workstation.
Case in point: To run procon against my BF3 server I had to spin up an EC2 instance running Windows server. My only other alternative was renting a procon server from someone who had a dedicated Windows box (expensive), and thus giving up some control of how I wanted to deploy and run the server. Managing Procon through Remote Dekstop on EC2 was an extremely painful experience, as things slowed down dramatically when it had to redraw the UI, etc.
By design PyRCon is a console server/daemon process that is communicated with via external clients.
#3: Better plugin / module API. Writing a plugin for Procon is currently a terrible experience. Rather than exposing an API and providing a DLL that you can link against, Procon requires plugins to be written as C# code that is compiled at run time. Procon even invented their own C# preprocessor flag (#include) to get around the fact that they do this really weird runtime compilation stage that doesn't support multi-file compilation. Although you CAN build externally in order to debug, you still can't do things like link against another library, have a multi-file build process, or actually know whether or not your plugin will work until its run in procon, which, because of points #1 and #2, can be an annoying, difficult, or impossible process depending on whether you have remote desktop access to the server that is running it.
PyRCon doesn't have to deal with alot of these issues because Python is an interpreted language. But I don't want to restrict plugins from not being able to link against other libraries, etc.
Hopefully this begins to answer your questions. I'll reformat this and add it to the README.