Hello,
What I have is a changing variable which is the direction the car is steering and that is stored in the variable ‘turn’. I want to make the steering wheel turn based on the variable. Like if turn equals 15 degrees then I want the steering wheel to turn 15 degrees. What is a rotation code that will do this? I probably worded this really badly but I tried to explain it the bet I could.
Thanks
-Matthew
edit: if you need a blend file I could post one
Create an action with rotational keys. Then play it with action actuator in property mode.
Activate the actuator each time the property changes.
This translates your property value into rotation.
Here is the blend file. I tried exactly what you said and it still doesn’t work and I don’t know why D:
PolyPackage.blend (1.63 MB)
Requirements
I had a look at your file. Before I can present any solution, I need some explanation what you want to achieve.
When I start the game and press <a> the properties “turn” and “turn2” start to count without an end. What is that good for?
I expected one property that tells the current turn angle of the wheels. If that is supposed to do that … I think you need to review your car controls (which is not topic of that thread).
Temporary workaround
Without correct property values you will never be able to tell if your setup works.
Therefore I add separate controls just for steering wheel that changes the property “turn”. This will help to show you how it works. The goal is to change “turn” within the values -1 (min) 0 (rest) +1 (max)
We define turn < 0 as left turning
and turn > 0 as right turning
The workaround use three states for toe-in/resting, steering left and steering right. All it does is to setup “turn” betweem -1.0 … +1.0.
A forth state defines the logic we are looking for:
When “turn” changed we transform it into “frame” which gets played. [You do not need a “transformation” script when you design your action that it already covers pthe -1.0 … 0.0 … +1.0 value range.]
By choosing a better action curve we just add +1. (this is due to the BGE sometimes does not like to play negative frames). Keep in mind, the BGE has no problem in playing frames with fractions (e.g. 1.334). The current animation plays from -30° … + 30°
You see it is not that difficult.
You can replace the states 1,2,3 with the copy property operation from the original file (indeed with an always triggering always sensor).
Note: With 2.76 I discovered strange lags when the steering wheel is parented to the car. This does not happen when it is parented to the road or to nothing.
Remarks:
PolyPackage_revised.blend (1.59 MB)
The turn property is the angle of the wheels and it stops at 750. What I wanted to do is that I created an animation that is 1500 frames long and the wheel is centered in the middle of the 1500 frames which is the 750th frame. The animation shows 750 to the right and -750 to the left. So my idea was that the angle of the wheels would determine the frame the animation is at thus making the wheel turn according to the wheels. The names are temporary. and the main() at the end is there when I use the template and I didn’t get rid of it. 
You do not need an animation that long. It is hard to handle (at least in my eyes). As said you can play fractions of frames.
The easiest is to use whatever you get as input (1:1). Somehow I doubt you get a turn of 750 from the wheels. As there might be technical problem s(e.g. like sometimes not playing negative frames) you can apply a conversion from what you get from wheels (turn angle) to what want to play (frames). Rather than a script you can use the mini language of the property actuator. Even your 0…750…1500 range would work that way “(turn*1500)+750”.
I know the template have some strange influence from some C developers. In Script mode everything is executed from top to button. That includes any function definition. Different than in other programming languages (like C) in Python a function can only be called after the function was defined. The result is the reader needs to jump other your function definitions to see what happens and than he needs to jump back. Due to the meaningless “main” he can’t even guess what it is supposed to do.
Here is how to write a proper script:
myScriptFromTemplate
some code
def main (): <- get rid of this line
code block <- unindent this code
main() <- get rid of this code
the result is
myPureScript
some code
code block
It is not just smaller. It is much easier to read.
Finally you do not need these templates. They might look like a good start-up, but only when you know nothing. I do not think they are good, as they teach the wrong things to beginners. It is good to see in this forum how that spreads around. Cryptic abbreviations and meaningless descriptors are not good for any code.
Keep in mind … scripts belong to small code blocks. If your code is supposed to do a lot of things, it is better to encapsulate the different operations in separate functions. Due to the above issues I strongly suggest to move them into a module. This allows to concepts:
A) use module mode
myModule.py
def demonstrateBgeCallableFunctionWithController(controller):
print("Callable from BGE controller. Called with", controller, "by", controller.owner)
def demonstrateBgeCallableFunctionWithoutController():
print("Callable from BGE controller. Called without argument if needed get it from context (bge.logic).")
def demonstrateNonCallableFunction(a, b, c=None):
print("Can't be called from a BGE controller, but any other Python code block")
B) place your functions in a different module file (moduleName.py) and import it into your script:
myUtilities.py
def demonstrateFunction():
print("demonstrating a function")
myscript
import myUtilities
demonstrateFunction()
The methods can be mixed. E.g. you can import a module from another module. It is the same code.
Be aware: you can 't import a script.