An update

Official Announcements about Source.Python.
your-name-here
Developer
Posts: 168
Joined: Sat Jul 07, 2012 1:58 am

An update

Postby your-name-here » Tue Feb 05, 2013 1:19 pm

Hi guys,

It's been a long time since I've posted. Things are starting to let up in my personal life giving me a bit of time and motivation to continue work on SP. Recently, after taking a look at the changes in CSGO, I realized that integrating these might not be such a trivial task. After reviewing the overall architecture of source.python, we're starting to consider rewriting a large portion of it.

When I first started this project, I didn't expect it to grow so fast. While the architecture I chose can handle the growth, it quickly leaves much to be desired. For example, currently in source.python, there is no way to ensure consistency across engines. We basically #ifdef'd out functionality that existed in CSGO from the OrangeBox build. As you can see for yourself, this led to messy and complicated code.

To ensure that source.python is prepared for the future, we have branched the codebase. You can find that branch here. There are some major changes in this branch that will break backwards compat, but solve a large number of issues going forward. Here are the list of major changes and goals for this new branch:

  • The C++ naming convention is unified with Python.
    • Method names are all lowercase with underscores between words.
    • This is possible because we're creating wrapper classes for every interface we expose.
  • Consistency across engines is guaranteed.
    • Our goal is to avoid putting conditional compilation in our code as much as possible.
      • This makes the codebase much simpler to follow.
    • If an older engine doesn't have functionality that a newer engine implements, it will have a stub in place.
      • We may try to implement the functionality ourselves but this requires thinking about the long term implications (e.g what if the behavior of the engine changes, etc).
  • Documentation
    • Is sorely lacking currently. Since the site died, we lost a lot of stuff (documentation included).
    • We're going to do our best to document as we go rather than attempting to do it all at once.
    • Still need to come up with a proper format on how to wiki-document methods, classes, etc.
  • Better design decisions
    • Our initial approach was 'wrap the engine as closely as possible'.
      • This goes out the window when what we're wrapping is so wildly inconsistent between engine versions.
      • Engine inconsistencies going forward will be exposed by a uniform interface, or stubbed out.
    • More helper classes.
      • In retrospect, this was a poor decision on our part. We can't guarantee that there will be helper classes for everything but we will do our best to include some when speed / ease-of-use is gained.
  • Support for all current engines.
    • The plan is to do an initial release with Orangebox, Left4Dead2, and CSGO support.
  • Dyndetours support.
    • Will be included in the initial release.
    • Need to reconcile how boost python and void pointers work.

We're currently just experimenting with the source-python-2 branch right now. The plan is to do things on a small scale and see if it works out. If it does, we'll solidify the design decisions and continue to move forward with the rest of the plugin.

We know things have gotten quiet, but we're not dead! As always, you can check out our progress from 'Source Code' link at the top of our webpage. Feel free to ask us questions or give us critique on potential issues you foresee in our code.

Thanks,
your-name-here
User avatar
Ayuto
Project Leader
Posts: 2193
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Postby Ayuto » Tue Feb 05, 2013 3:47 pm

Nice to see you back on the project. Do you think you will include DynDetours by using a shared or static library? I you are going to use a shared library we could keep at least compatibility with SPE.
your-name-here
Developer
Posts: 168
Joined: Sat Jul 07, 2012 1:58 am

Postby your-name-here » Tue Feb 05, 2013 3:53 pm

Ayuto wrote:Nice to see you back on the project. Do you think you will include DynDetours by using a shared or static library? I you are going to use a shared library we could keep at least compatibility with SPE.


If you have a shared library for DynDetours built for SPE, I would be more than happy to use it (plus it's easier on us). :)
User avatar
Ayuto
Project Leader
Posts: 2193
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Postby Ayuto » Tue Feb 05, 2013 4:08 pm

Then I will do that, but you need to do two things:
1. Fixing HookAction.Override for cdecl functions
2. Adding support for post hooks

However, this month I won't have time to do that, because it's my last year in school and I'm writing every 2-3 day an exam. :(
Woody
Global Moderator
Posts: 42
Joined: Sat Jul 07, 2012 2:45 am
Location: California

Postby Woody » Tue Feb 05, 2013 4:31 pm

Glad to see you are still around your-name-here! :cool:

Awesome to see support for other engines as CS:GO has died down quite a bit.
necavi
Developer
Posts: 129
Joined: Wed Jan 30, 2013 9:51 pm

Postby necavi » Thu Feb 07, 2013 8:34 pm

your-name-here wrote:

  • Better design decisions
    • Our initial approach was 'wrap the engine as closely as possible'.
      • This goes out the window when what we're wrapping is so wildly inconsistent between engine versions.
      • Engine inconsistencies going forward will be exposed by a uniform interface, or stubbed out.
    • More helper classes.
      • In retrospect, this was a poor decision on our part. We can't guarantee that there will be helper classes for everything but we will do our best to include some when speed / ease-of-use is gained.


This seems like QUITE an improvement - it should be easier to write plugins in python than in sourcepawn, not the other way around as it currently seems to be (coming from someone whose primary language is still python). I'm very interested to see how this goes.
User avatar
satoon101
Project Leader
Posts: 2697
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Sat Feb 09, 2013 2:49 am

Not trying to derail this thread, but I am slightly confused by your statement. Overall, the Python-side API will still function as-is. It is just the links between the API and the C++ side (what we refer to as Source) are going to be a lot more consistent. Obviously, you can choose to use the Source functionality yourself, as well.

As one example, which was one of the reasons why this new design decision was made, is the new Protobuf user message system that Valve released with CS:GO, recently. If you look into the messages module, you will notice that the Python-side API currently has to use a try/except to see if Usermessages is importable from Source. Then, if it is, use the protobuf system built into the messages module, and if not, use the regular user message system. This new design decision for the interface will leave one way to interact with user messages, no matter which version of the engine the server is on.

Again, I do understand that if you choose to use the Source in situations instead of the Python API, you will notice these differences yourself. However, if you are using the Python API, you should not notice much, if any, difference.

Satoon

Return to “News & Announcements”

Who is online

Users browsing this forum: No registered users and 9 guests