The way I see it there are several problems being discussed here:
- Fix my script (How do I add lots of objects?)
- Python or empties?
- How do you debug a python program?
- How do you structure a python program?
The first on I’ll cover really quickly:
cont = bge.logic.getCurrentController()
scene = bge.logic.getCurrentScene()
player = scene.objects ["player"]
obj = cont.owner #Not sure what this object is? Can we give it a better variable name?
if obj.getDistanceTo(player) > 29:
lung_1 = scene.addObject("lung", player, 0) #Because we're adding a lung, let's call it lung
lung_1.worldPosition = [2,8,9]
lung_2 = scene.addObject("lung", player, 0) #And because there's two of them, lets call this one lung_2!
lung_2.worldPosition = [2,8,3]
In module mode:
DISTANCE = 29
POS_1 = [2,8,9]
POS_2 = [2,8,3]
player = cont.owner.scene.objects['player']
if cont.owner.getDistanceTo(player) < DISTANCE:
def add_lung(ref_obj, pos):
scene = ref_obj.scene
lung = scene.addObject("lung", ref_obj, 0)
lung.worldPosition = pos
Python Or Empties
Whichever you like and are comfortable with. Empties are easy to manipulate, you drag them around in blender and they move. On the other hand, if you have lots of positions you want to store (hundreds), managing hundreds of empties is hard.
You can make vectors with:
vec = mathutils.Vector([0,0,0]) #Replace [0,0,0] with any 2-4 long list of whatever you like.
if you need to do vector operations (like adding or subtracting positions.
If you want rotations, you can store eulers or quaternions.
Or more generally, you could simply store a transformation matrix, which is all an empty actually is.
Where should I use empties
Where you have a few of something that may need to be tweaked.
Where it has to interact with other objects (eg parenting), it is often easier to do it in empties.
Where should I use some other storage medium
When maintaining the empties becomes hard (eg lots of them)
When you want to load different sets of them (eg from a text file)
How do you debug python
This is just the basics:
- Check for errors in the console. This is always the first step, but only picks up minor errors such as typos
- Print “I’m here” markers, so you can see if your code is getting to various places. This can be as simple as adding “print(1)” to one line and “print(2)” to another. Make sure you remove them afterwards though. You may place some around inside the if statements to see if they are getting exectuted.
- Print various variables. This one would pick up the error in the first script in this thread. It would show that for the first conditional, obj is the name of the object running the script, but for the second conditional, obj is the added object “lung”
- Check conditionals. Print out things like the obj.getDistanceTo(player) and see what it actually is.
- Read through the API
- Draw diagrams, and thing through your problem on paper
- Read through a physics textbook
- Ask your teacher/lecturer/dad/someone else who knows what you’re working on, and is likely to know the problems you’re having.
- Ask random people on the internet for help
How do you write python
- Get out pen and paper. Yar, I know every IT teacher says this, and they hammer you with it, and as a teenager you go “but I can think it all through in my head, it’s faster without paper,” but knowing what you are making before you start is a good plan. Draw flow charts, UML diagrams, wite down what you expect the program to do, figure out how to break it up into logical sections
- Test early, test often. When I make an object call a function, the first thing I do is make that function be:
print("Hello, I'm here")
return some_trivial_but_valid_output #eg 0 or false
That catches an amazing number of errors before they send me on wild goose chases through my code.
3) Test your code after every 3 lines of code. You don’t have to test it very thuroughly, but if you make small changes, things are less likely to end in a train-smash.
4) Keep consistent style. Use pylint and pep008. Force yourself to obey their rules. Yes, a 30 line function may seem managable, but split into smaller ones anyway. It means when your code throws an exception, you have fewer lines of code to hunt through.
5) Study physics (looking at you adrian)
6) Debug the mess you’ve made
7) use more paper
8) Cry a little about the horrible mess your neat code turned into
9) Realize no-one actually knows how to write good code
10) Get out more paper and try re-organize things
11) Realize you need more modules and functions