This shows up in in the Blender SVN builds: 19335, 19605 and 19633.
console window:
“Method isPositive() is deprecated, please use the read-only positive property instead”
Everything is deprecated, please use the ______ property instead?!
What’s going on and why is this changed.
no speculations.
That’s weird… O.o But I can’t help you… at all…
yep, blender 2.5 will have these functions removed.
http://wiki.blender.org/index.php/Dev:Source/GameEngine/Python_API_Clean_Up
THAT’TS A TERRIBLE IDEA!!!
This means that once 2.5 hits the web, all of the old games that have been made will be completely unplayable unless the makers (or some dedicated individual) completely re-writes the code for these games…
0_o
I think that will have a “converter script” for convert the 2.49 or oldest for 2.5 right?
It’s not really a terrible idea. It’s actually the way it should have been done to begin with. It’s unfortunate that it will break support for pre-2.5 games, but 2.49 can be used to find all deprecated methods and fix them, so it’s not a huge problem.
Sometimes large changes have to be made in the general interest of future productivity. This is a situation where that is the case. The updated API is going to take a bit of getting used to, but it will reduce script lengths significantly and increase readability. Nevermind that it could potentially cut out literally hours of typing from future BGE projects 
Not really, Blender uses a very outdated version of python. It’s about time that it got an upgrade. It’s worth breaking backwards compatibility if it means you can make better games/scripts in the future.
I’m ready to port all of my games to the new API once 2.49 comes out providing I have a porting guide to help me along.
I assume that instead of having like.
px, py, pz = ob.getPosition()
or
ob.newpos = ob.getPosition()
You’d have
px, py, pz = ob.position
or
ob.newpos = ob.position
which can be quite a bit more readable
CD, as far as I know the position will still be stored as a tuple, but it will simply be a direct property of the object instead of having to jump through “getPosition” and “setPosition” hoops to access and alter it. So
own.setPosition([newX, newY, newZ])
becomes
own.position = [newX, newY, newZ]
Still a tuple, but as you said, much more readable and much less awkward.
I’m meaning assigning 3 variables to each part of the tuple, like what you do now, like this I use so I have variables for the x, y, and z part of the object’s linear velocity
own.vx, own.vy, own.vz = own.getLinearVelocity()
So if you wanted to change the position only on the z-axis you would go
x, y, z = own.position
own.position = [x, y, z]
z += 0.05
Also, when using the set function for DLoc, and LinearVelocity now you can set it to be on the local or global axis as the last argument, will doing be still be just as easy?
I think that will have a “converter script” for convert the 2.49 or oldest for 2.5 right?
I doubt it.
It is inconvenient for current / older projects. However, I have to agree with blendenzo. The API needed to be cleaned up and it’s much better if backwards comparability is broken before 2.5 rather than after. The longer the devs wait to update the python API, the more damage will be inflicted on blender projects in the long run.
I agree that breaking compatibility at 2.5 is the best place to do it. If a conversion script is not on the agenda, I have no problem converting my scripts myself, if a consice guide on the new syntax is published.
However, I would ask the devs to please include the depreciation warnings in 2.5. I know they are in svn (and therefore 2.49) now, but I would assume that more changes will be made between 2.49 and 2.5 (meaning more functions may depreciate between the versions, making 2.49 not useful as a conversion-helper).
Oh, I see what you mean. I didn’t know you could auto-parse tuples like that. That’s rather handy information. Thanks for accidentally teaching me that 
Ok I understand now, Thanks for the information, and sorry for freaking out:D
Thanks (ben2610, cyborg_ar and Moguri) for your hard work in cleaning up the code,
this is simpler and easier to understand.
I tried what Cyborg Dragon was saying and it works,
plus here’s some more code tests.
to detect sensors you use
if sensor.positive == 1:
or
if sensor.positive == True:
g = GameLogic
c = g.getCurrentController()
owner = c.getOwner()
sensor = c.getSensor("space")
if sensor.triggered == 1 and sensor.positive == 1:
p = owner.position
p[2] += .5
# move the object
owner.position = p
x,y,z = owner.position
z += .5
# move the object
owner.position = [x,y,z]
The code I gave right off the top of my head without testing it or fully knowing its the right way to do it but just assuming so with the API cleanup works!?
The code is really that easy, that’s going to help out a lot, I have to say accessing these built in properties direct is very similar to how GameMaker does things in its easy-to-learn programming language.
I’ll wait until 2.49 is out before I start porting my scripts, just to make sure the API cleanup is complete before I start.
Now what about another porting tip, getting any object in the scene, like making every created object named ‘Box’ do a certain thing, what will be the new way as opposed to the old way of getting the current scene and the object list.
what? they are just that, warnings, you can disable them in the game menu if you don’t like them. 2.50 will be FULLY compatible with 2.49’s new api, if something has to change it will be deprecated again and the definitive change in the next version (2.51), so you ALWAYS have a version of blender that is compatible with both things and will help you to convert.
I don’t see whats to complain about, I just ported every script in my mini-golf game so they will work in 2.5, in other words I did changes until I no longer saw the deprecation warnings.
I still notice there isn’t such properties like act1.dloc, act1.force, and act4.linv, those could be helpful, you could probably have it output 4 values, the last one dictating whether it’s global axis or local axis movement.
I know that. It is very useful.
I guess I was under the impression that at some point (namely 2.5) the “old code” would just not work (maybe this is 2.49 instead?), and that the warnings were put in place for the transition period. It is impressive (and a nice effort by the devs) to make Blender understand when its users are behind the times, and help them out. Thanks for the info, this really clears it up!!