New Build!

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

New Build!

Postby your-name-here » Fri Mar 29, 2013 9:22 pm

Hello everyone.

We apologize for the slowness. I've uploaded the latest build of Source Python for both Windows and Linux.

You can grab that here.

Please note that this build is for CSGO only at the moment.

What this build contains:
This is the first build of Source Python on the source-python-2 branch, our core restructuring. Due to that, the "changelist" is essentially what you see on our Wiki. We have made a policy internally to always ensure our documentation stays in sync with our feature set, so everything in the binaries is on various wiki pages.

Short list of features:
  • Much more robust core interface.
  • Entity send prop support.
  • Better entity manipulation functions.
  • Changed module naming convention.

Cool stuff you can do:
We now have a CEdict class. This allows us to provide extremely useful wrappers around entity retrieval. Currently, you can retrieve entities in two ways. Here is how you can get an entity by index:

Syntax: Select all

#
# Imports
#
from Source import entity_C

#
# Functions
#
def some_function():
worldspawn = entity_C.CEdict(0)
print(worldspawn.get_class_name())

Here is how you can achieve the same result via entity name:

Syntax: Select all

#
# Imports
#
from Source import entity_C

#
# Functions
#
def some_function():
worldspawn = entity_C.CEdict("worldspawn")
print(worldspawn.get_index())


Note that in either case, you can call .get_index() to retrieve the index of that entity.

We also have the ability to do partial name matching. The default is to do an exact match, but if you pass in False as the second parameter to the CEdict constructor, it will return the first partial match:

Syntax: Select all

#
# Imports
#
from Source import entity_C

#
# Functions
#
def some_function():
worldspawn = entity_C.CEdict("worldsp", False)
print(worldspawn.get_index())

This version of Source.Python also adds in the ability to set entity send prop data. Currently, this is limited to strings, floats, and integers, but the next release will support all send property types. Here's how to set the health of a player. In the interest of getting people acquainted quickly, the following code assumes that you are alone on the server with no bots:

Syntax: Select all

#
# Imports
#
from Source import entity_C

#
# Functions
#
def some_function():
Player = entity_C.CEdict("player")
Health_Prop = Player.get_prop("m_iHealth")
Health_Prop.set_int(15)

We will be providing wrapper classes around the entity props so don't be too concerned about .set_<type>.
User avatar
Ayuto
Project Leader
Posts: 2193
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Postby Ayuto » Fri Mar 29, 2013 11:08 pm

Well done! But I wonder if you plan to change the name of the package Source to e.g. sp_C?
your-name-here
Developer
Posts: 168
Joined: Sat Jul 07, 2012 1:58 am

Postby your-name-here » Fri Mar 29, 2013 11:46 pm

Ayuto wrote:Well done! But I wonder if you plan to change the name of the package Source to e.g. sp_C?


Not really sure on this just yet. I prefer to think of 'Source' as a category of packages rather than a singular module for functionality. I'll talk this over with satoon101.
User avatar
satoon101
Project Leader
Posts: 2697
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Sat Mar 30, 2013 12:16 am

I likey this :) I will get right to work on modifying the current API to fit these changes.

I prefer Source, personally, to sp_C. We decided to go that route in the very beginning, and it still seems to work fine. It is definitely a collection of packages/modules much like the Python API is designed. The reason we decided to change the module names to use lower-case letters with "_c" was to differentiate between what is imported from the C++ side and to alleviate naming conflicts.

Satoon
User avatar
Ayuto
Project Leader
Posts: 2193
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Postby Ayuto » Sat Mar 30, 2013 12:42 am

I thought about the name "Source", because I think it is missleading. That package did not contain pure engine wrappers, but also "Binutils". So, my suggestion is to remove the package "Source" and export its modules as seperate modules (import entity_c instead of from Source import entity_c). Otherwise the differentiation doesn't make sense in my opinion.
User avatar
satoon101
Project Leader
Posts: 2697
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Sat Mar 30, 2013 1:01 am

It does make sense. Everything is in the namespace "Source". You import entity_c, engine_c, events_c, etc... from the overall Source package. They are their own separate modules, but you must import them from the main namespace and not directly. I think it works better this way and is more clear about where it is coming from. When Binutils gets added back in, it will likely be "from Source import binutils_c". Source does not just refer to the wrappers that directly interface with the SDK, but to all modules from the "Source" of Source.Python, basically anything that Boost itself exposes to Python.

Satoon
User avatar
Ayuto
Project Leader
Posts: 2193
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Postby Ayuto » Sat Mar 30, 2013 9:42 am

Since you added the "_c" we already know where they come from. Also, why do we need to import the C++ API from a package, but can import the Python API directly? I think consistency is more clear at this point.
your-name-here
Developer
Posts: 168
Joined: Sat Jul 07, 2012 1:58 am

Postby your-name-here » Sat Mar 30, 2013 4:39 pm

Ayuto wrote:Since you added the "_c" we already know where they come from. Also, why do we need to import the C++ API from a package, but can import the Python API directly? I think consistency is more clear at this point.

Because Source is the overall namespace of all engine related functions. Each submodule like entity_C provides a specific set of functionality. We'd prefer to keep it that way unless you want us to break backwards compatibility immediately after our first release in a long time :P

In regards to your other question, this is just how boost python is setup when exposing modules from C++ to Python. Not really sure how to change that.
User avatar
Ayuto
Project Leader
Posts: 2193
Joined: Sat Jul 07, 2012 8:17 am
Location: Germany

Postby Ayuto » Sat Mar 30, 2013 5:17 pm

Yes, break it! :P

However, at the end I have to use whatever you have decided. :D
your-name-here
Developer
Posts: 168
Joined: Sat Jul 07, 2012 1:58 am

Postby your-name-here » Sat Mar 30, 2013 6:19 pm

OK, let me know when you're ready to redo all our documentation :)
saul
Junior Member
Posts: 1
Joined: Sat Mar 30, 2013 6:52 pm

Postby saul » Sat Mar 30, 2013 6:54 pm

your-name-here wrote:OK, let me know when you're ready to redo all our documentation :)


It'd make more sense to follow PEP 8's guidelines on package/module naming: http://www.python.org/dev/peps/pep-0008/#package-and-module-names

So if we're gonna be nitpicky, then it should be more like:
from source import _entity

But seriously, awesome work guys :D
your-name-here
Developer
Posts: 168
Joined: Sat Jul 07, 2012 1:58 am

Postby your-name-here » Sat Mar 30, 2013 8:33 pm

saul wrote:It'd make more sense to follow PEP 8's guidelines on package/module naming: http://www.python.org/dev/peps/pep-0008/#package-and-module-names

So if we're gonna be nitpicky, then it should be more like:
from source import _entity

But seriously, awesome work guys :D


Saul! I didn't expect to see you around these parts o=

I'll talk to Satoon in that case. We have to keep documentation and other libraries in mind if we do this.
User avatar
satoon101
Project Leader
Posts: 2697
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Sun Mar 31, 2013 12:16 am

Technically, we "should" be using:

Syntax: Select all

# Source.Python Imports
# Engine_C
from engine_c import get_engine_interface
# Entity_C
from entity_c import CEdict
# Event_C
from event_c import CGameEventListener
We are discussing this internally to find the best solution and how to implement it.

Thanks for all the suggestions.

" wrote:Saul! I didn't expect to see you around these parts o=
I second this!! Welcome to the forums :)

Satoon
Omega_K2
Senior Member
Posts: 227
Joined: Sat Jul 07, 2012 3:05 am
Location: Europe
Contact:

Postby Omega_K2 » Sat Apr 20, 2013 3:05 pm

ETA on when the previously existing parts get into the new svn/build?
Libraries: k2tools
Plugins (any): GSRPG (soon) | Pretty Status List | MySQLAds (soon)
Plugins (game-specific): None atm

If you happen to find a bug or need help, either post in the release threads or contact me in IRC gamesurge.net:6667 / #sourcepython
User avatar
BackRaw
Senior Member
Posts: 537
Joined: Sun Jul 15, 2012 1:46 am
Location: Germany
Contact:

Postby BackRaw » Fri Apr 26, 2013 1:23 am

Well done! This should be a good foundation I might say, do ya thing :D

My opinion on the naming of things is: guys, this is still a dev-build, so for us (the addon writers), this shouldn't be a problem at all, because it works that way... Change can always come later, don't forget that :)
User avatar
satoon101
Project Leader
Posts: 2697
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Apr 26, 2013 11:28 am

There is no ETA, unfortunately. All of the C++ programmers are very busy with other projects and their lives. That is the only answer I can really give at the moment, sorry.

As far as the naming scheme, we have already removed the "Source" namespace, so now importing from the C++ side is what I wrote above. You can use either of the following:

Syntax: Select all

import engine_c

GameEngine = engine_c.get_engine_interface()

Syntax: Select all

from engine_c import get_engine_interface

GameEngine = get_engine_interface()
The Python API will utilize the second method to import only the objects needed within the specific module.

Satoon

Return to “News & Announcements”

Who is online

Users browsing this forum: No registered users and 11 guests