script evaluates conditions

would it be wise to have all logic off, except a manager, and somehow have the manager (in the same frame) activate the other python?

always--------------Python(bump to top of order)

trigger--------------other python

trigger 2------------other python

or am I missing something?

I don’t quite understand modules, or even threading yet, so bear with me.

It depends on the actual circumstances, and your overall goals, but I suspect the answer is no.

If you want to import a module, and use objects it provides, you can simply do that in the active python script:


import yourmodule # yourmodule.py in the text editor

yourmodule.your_add(2, 3) # 5

The imported modules don’t have to be referenced by a controller in order to be used.

PS:

Your question is poorly crafted. The title “script evaluates conditions” is not relevant to the content, and the content itself is extremely shallow - Saying that you don’t understand something is not enough information; You need to explain the specifics of your confusion, so that we can give you a specific answer.

What exactly don’t you understand about modules, in which context? You need to think about stuff like that, before you post.

Don’t disrespect our time - put some real effort into your posts.

Well, can I register a module, and then call it with another script?

like

def MoveThisThere(object,target,time):
{code}

and then call it using another script?

currently I do this by making a object, and then just adding it, and setting properties, the item runs it’s code and then ends itself.

what is the better way?

is my way good enough?

Can you add a object and then set what python it should run?

That’s what import statements are for. You don’t need to register your modules, you just need to make sure they’re in you current Python path. If your code is inside a blend file, it will already by in your path. You can import it using the file name (e.g. to import mymodule.py, just use import mymodule).

You can see the Python controller (regardless if Module mode or Script mode) as a “door to your Python logic of the current frame”.

From there you can do anything with Python you want. The most users (especially the beginners) try to keep everything in one file. The idea is that they can find everything there.

After a short while of adding one thing after the other the code grows and grows and turns into an un-manageable mess similar to lots of logic bricks. Script mode helps a little bit as you have just one “door” while module mode allows several “doors”.

It is a good idea to keep things that belong together in one place, while things that do not belong together are at another place. You can see it with the logic bricks. The property sensor cares about keyboard input only, while the property actuator manipulates a property. Two concerns = two separate objects. To get them combined into an higher level logic you simply connect them together at state level.

You can do a similar thing with Python code. You keep your low-level code separate and combine them at an higher level.
Especially here it is very important to avoid mixing code from different abstraction levels.

You have the option to separate code into:

  • functions
  • modules
  • packages

You combine functions by calling.


def shopping():
   driveTo(store)
   things = buy(wishlist)
   store(things, car)
   driveTo(home)

def driveTo(location):
   enter(car)
   switchOn(navigation)
   set(shopAdress, navigtion)
   start(car)
   follow(navigationCommands)
   ...

You combine modules and packages by importing them.


import car, buying.supermarket

def shopping():
   car.driveTo(store)
   things = buying.supermarket.buy(wishlist)
   car.store(things)
   car.driveTo(home)

This is very abstract code. Maybe you can see the concept. Keep the code on the level it belongs. e.g. starting the car is part of shopping, but at a very low level. If you tell someone how you do shopping, you will exclude it from the description. If the other wants to know the details of how you drive to the store … you can tell it.

Well, can I register a module, and then call it with another script?

You may want to consider using an external .py file to store some functions that you use in several different scripts. I know there is a better way to structure the file, but I keep many functions inside a file, such as “myLibrary.py”, then call it in a script like so:


from myLibrary import functionA

The .py file I use in my project is up to 4.8k lines now so it makes a noticable performance difference to use “from x import y” rather than “import x”.

A clear sign that it needs a redesign. This file is way to large.

i think is a pretty good idea
as performances is better anyway separate the logic of each object at least in 2/3 script

always -> init (should be the code more big)
always True -> update … the manager
state = patrolling -> patrol
state = idle -> idle
state = player -> player

this can be extended on different objects component, more or less with the same structure
anyway not using class and modules can be a bit more hard reuse code , anyway there thge advantage that not require big structure

Reusability is no unique property of classes and modules. There is no problem in reusing scripts, functions and code snippets.

The only problem is when you explicit design the code in a way that it can’t be used at another place [e.g. by hard-coding object names, caching context data out of context such as the current controller]. This belongs to any code and is not restricted to a specific architecture.

I would not recommend to separate code with game objects. It makes more sense to separate code with the purpose.

Example:
You can have several characters. There is no problem sharing the animation behavior.

You can collect several operations in one object. E.g. the camera can turn by mouse input (so called mouse look) and move via keyboard input. Both operations are different, but at a certain aspect they belong together.