Python 2.2.1 Support for TGE

#21

Quote:
No more cheesy string representations of vectors/transforms

At last! Good work Joshua.

#22 I just uploaded:

---------
TGEPython - an industrial strength TGE/Python binding
v.1a
---------

As a code resource... watch out :)

EDIT:

A nifty feature since v.1a ... you can now get TGEObjects in Python by name(and not just by id):

Python:

pd=TGEObject("LightMaleHumanArmor")
pd.jumpForce = 50.3 * 90

-J

#23 Woah awsome! ONe question though that i've halways had about python.. is there a way to hide your code?

--KallDrexx

#24 Delete your .py and ship with .pyc ... pretty much like .cs and .dso

There's still a lot of work to do... but the code resource should give an idea of where it is headed... Note that the resource has a couple bugs that have since been squashed... the interface is being tightened and cleaned too

Work has mostly centered around the C++ connection between Torque and Python... I am now getting to the Python framework...

Onward!

EDIT:

I uploaded a new version and stuck the docs in my .plan

Enjoy! :)

-J

#25 awsome!

--KallDrexx

#26 That is remarkable :)

#27 Sorry folks, I perhaps jumped the gun by uploading this as a resource without a license... there is a bit of a discussion on the licensing options for this code in my .plan...

I've decided to give it away...

I've resubmitted this as a resource under a very liberal license... hopefully it works...

EDIT

Kudos on the AIPlayer class... it is a blast...

Holy fun! I just made a weapon that launches bots... now if these bots wandered around until you vacuumed them up... had a chicken graphic, clucked, and exploded when they hit the ground... that would make a nice demo :)

EDIT a bit later Alright I made a Python AIPlayer Class and have a server tick spawning a new one every 4 seconds... they then hunt the player by getting an updated position... I have blasted around 200 of these in a single session using a modified (rapid fire) version of the crossbow gun which launches python created projectiles (would have been hundreds of these over the course of the session)... no memory creep/etc... the only addition I made was a _tgedeleted field set to True in the SimObject (python) classes unregisterObject() call... so that the list of spawns I used could detect and remove that element when it updated...

LATER YET!!! Whoa.. spawning an AI player every second... blasting blasting blasting... yeah! yeah!! yeah!!!!!! I'm not quite calling TGEPython bulletproof.. but awfully stable... gawd... TORQUE ROCKS!!!!!

I NEED to get that Generator based simulation going! Sometimes excitement can make it so hard to breathe!!!!

*Spit* *Drool* *Spooge*

-J

#28 Alright, that's quite enough bodily fluids from you.

Thanks for providing this for the community. While I think you and anyone else is fully entitled to charge people for additions to TGE, I don't think it's entirely fair to do so if they've been teasing people about their cool new thing for a while *grin*

I'm going to have to get back into Python, I haven't touched it for a while. One of the fun things I did with it was a script for trueSpace4 (which first added Python scripting, though honestly it doesn't utilize it that well) that logged mesh objects onto IRC and reported their position every few seconds ("[10:02] I am at 0,0,1"). Until it crashed. But still.

#29 It occured to me that what I really want is a way to develop new SimObject and SimDataBlock types in script and not have to resort to C++ for new ones... of course, for time criticial sections, C++ would need a way to be accessed... though script and this work is meant primarily for GAME LOGIC and not time critical rendering/physics/etc stuff...

This would help greatly with code seperation (see my DLL rant from a number of month ago *grin*)... allow diverse game functionality to be created in pure Python, and free up the whole C++ -> script layer... dynamic and quick... with minimal coding effort...

I want to stay as far away from C++ and mucking around in Torque Demo as much as I can... besides, most of the functionality is already there... I just want an efficient way to USE it...

This may or may not be the way to go...

Perhaps NetEvents are enough... or maybe there is a Python distributed library i can latch onto... maybe a new NetObject which can just zing Python class instances around...

-J

#30 Today I realized I'm much better at programming than before--I actually understood everything in this thread! :)

#31 stupid question I figured out a minute or two after posting removed.

Sane question now for the new to Python converts.

Does the Python interpreter get embedded into Torque wtih this code, or will the end user have to install it also???

Also what is the big deal about Single Threaded vs Multithreaded DLL?

#32 Kind of an offhand thought: Can QuArK's python code be used for a Torque Editor? Or is its python version too old anyway?

Or is there a better solution?

-Eric Forhan MRT

#33 Python can live inside your game's folder... python22.dll and whatever standard library files are all you need...

Multithreaded and Single threaded libraries have problems operating together ... no magic.

One note, You CAN do threads in Python with Torque... just don't have those threads simultaneously calling back into TGE (boom)...

-J

#34 Joshua this is probably the single most important advancement to Torque from a rapid development standpoint.
If this is as useful as it looks, I can see it completely replacing TorqueScript in my project.

What I was asking about the Single Threaded vs Multithreaded DLL. You said "it should have been this way all along". I was just wondering why other than compatibility with the Python .dll?

Is there a security risk with someone being able to wedge another .dll between Torque and the python22.dll like is done in Half-Life. 99% of all the cheats in HL are solely because of .dll wedges.

Forgive me if any of this seems naive, I usually do C++ in a different environment than Visual Studio and Windows.

#35 Brilliant! Just brilliant. I had begun to look at what it would take to embed Python into Torque, and somebody has already done it! Do you know if anyone has gotten this working any place other than Windows? Our development environments are OS X and Linux. I'll take a look at it under OS X tonight.

#36 I've been working on getting it build on Linux. There were a couple of capitilization errors, but that was it. The problem I'm having now is I keep getting an "Invalid TGECallback" assert from PyInit(). Something along the lines of "tgepython.console.simobject" not found. I'll have to boot back up into Linux and find the exact error.

#37 It would be cool for people to get this up under Linux and Mac... I don't have the resources currently to keep up/do this...

This thread has some interesting stuff in it if you wade thru it... I should wrap the info and present it more clearly on TGEPython's home at some point.

I am currently knee-deep in gore... I spent the end of last week and the entire weekend getting the next game gold and to the duplicator...

now... back to MMP land for me...

-J

#38 Ok, here is the error I'm getting. This code:

// Install a mechanism to redirect stdout and the TGECall python entry point
PyRun_SimpleString("import sys\n"
"import tgenative\n"
"import tgepython.console.simobject as TGE\n"

"sys.oldstdout = sys.stdout\n"
"sys.oldstderr = sys.stderr\n"
"class TGEWriter:\n"
" def write(self, text):\n"
" tgenative.TGEPrint(text)\n"
" def __del__(self):\n"
" sys.stdout = sys.oldstdout\n"
" sys.stderr = sys.oldstderr\n"
"sys.stdout = TGEWriter()\n"
"sys.stderr = TGEWriter()\n"
"sys.stdout.write(\"Python \"+sys.version+\"\\n\")\n"
"tgenative.TGEInit(TGE.TGECallback,TGE.TGEDelete)\n");




breaks and gives me this.

Traceback (most recent call last):
File "", line 3, in ?
ImportError: No module named tgepython.console.simobject

#39 Make sure you have tgepython in the working directory you are running in... that is a python import error, standard module import rules apply... www.python.org

-J

#40 Yeah, I know that. Nothing is different from the codebase from Win32 and Linux. It works fine in Windows. Linux doesn't like it...