Hi, I have two doubts about modules in the game engine.
If I’ve got one object, and a module attached to it, and then I duplicate it in runtime, does the module get duplicated.
Suppose I have one object with a method getAttribute(), that returns a variable. If I duplicate it, does the second object return the same variable, or each object has its own variable.
My second doubt: can I call an object method from another object, with parameters. Example, form an object, I call object1.setAttribute(100), and object2.setAtributte(50)
The module is not duplicated. So any script-level variables are global across objects. Any in-fucntion variables are local to the function call, and thus to the object.
Just as with amscript, you can access everything from any object, but this can be bad code design.
What kind of objects are you talking about?
If yo mean game objects (the objects you select in Blender), then it is as sdfgeoff wrote. But I want to add:
Modules are not attached to game objects, nor game objects to modules.
The relation between these entities is different.
A game object has controllers (logic bricks).
A controller can be a Python controller.
A Python controller in Module mode refers to a Python modules function (I call it entry point).
This means the Python controller has the reference, but not the entry point, nor the module.
Who has the module? It is the Python interpreter which is called by the BGE. The Python interpreter knows about modules in the Python search path (including the text blocks of the .blend file)
If you copy the game object in the scene, you copy the reference to the entry point too. It is still the exact same entry point.
If you are talking to Python objects:
Modules are objects.
Modules can refer to other objects.
Objects can refer to modules.
Objects can refer to module methods.
Thanks for the answers. I’m slowly getting used to the BGE, which can be confusing when you come from a standard language.
I’m trying to have a clean structure in my program, so I was trying to call the methods between objects.
For example:
I have 10 objects, and one module as an interface to them. They can use their own methods from logic bricks, but to do so in python module, I should find which object has called the method, isn’t it? And then modify its variables, so I should have a list of attributes in the module, one for each blender object.
If another module wants to call one of this methods, do I have to pass the object that should be modified as parameter? ( ( (objectModule.setAttribute(objectId) )
No, you mix modules and game objects. Both are separate objects with different purposes. They have no relationship to each other unless you create one. It is up to you what relationship to establish.
The BGE is not designed that you control the game loop. Your Python code is a small part of the game loop. You can think of it as a “customized” part of a game.
A game object is (type KX_GameObject) is the Python representation of the object you see in Blender. Not really the one from Blender but a converted copy of it. It is a BGE game object. The object itself is native code. You can communicate with it via the BGE logic layer (logic bricks) or the Python API. The Python API will transfer your requests to the native object and return the results to you.
The module or script is just the container to keep your code.
Each call from a Python controller (regardless of Script mode or Module Mode) sets up a context. This context contains the controller that gets executed and the scene the object that has this controller belongs to. You get them via bge.logic.getCurrentController() and bge.logic.getCurrentScene().
There is much more in the context. Please check the BGE API for more information.
Object data is typically stored at the object itself (OOP approach). This means you store your data for example in a property of a GameObject. The KX_GameObject supports any kind of data as Property. You can even store instances of your own classes.
If you think of “managing” objects - which are objects that perform equal operations on other objects - you might want to store data somewhere else (e.g. a list of objects). In that case either the managing object or the managed objects are a good place.
If you think of accessing singletons it is indeed a good idea to use a module as storage. You can simply define module variables to keep them. For example bge.logic.globalDict is such a variable. You can define as much and as many module variables as you like.
Make sure the data they contain stay consistent. For example a list of object references will still be available after the scene they live in is removed. The objects in the list will all be invalid and operations on the m will fail.
Anyway to get into the BGE logic architecture I recommend you read the first couple of guides in my signature. I’m sure you will find it interesting.
Ah, I’ve just discovered your great guides, and its all clear now. The magic part is the cont parameter. With that, I can use the same code for different ‘blender objects’ (something like a ‘this’ or ‘self’ reference). And then I can store the attributes of the ‘blender objects’ in a list in the module, or in the logic properties.
Now ‘blender objects’ can be seen as instances of a python object defined in my module.