This might be a useless post but I thought I could share this trick and to hear from you how useful it really is (or is it even that optimized?).
I had in mind of making a “while” style loop with the following rules:
No added or removed temportal objects
No enabled/disabled sensors
No True level triggering
So this is what I came up with.
I use a simple if check and the script send a message to itself as long as the statement is true
(or what ever you wish it to be).
The script will run, but what happens depends on the program itself.
If you have a condition that needs to be satisfied for a certain block of code to run, you can place that block under a proper conditional.
Or, if your execution is tied to a certain property, as in your demo, you can use the property sensor to specify the relevant value ranges for execution.
For a more complicated scenario, you should probably just use the built-in state machine.
I think all of those options would be better (because they’re more straightforward) than sending a message, to receive a message, to ultimately run the code.
Would you prefer this method? Camera sends a state change (press any key to trigger)
to the cube which has a always sensor.
So if I understand it current, the object will remain dorment unless it is on active state?
I apoligize, states are a bit of a new thing for me. I need to study them more.
I know I should not worry about optimizing too much so early on, but
I’m just thinking a good solution for active/inactive objects in my game and
I don’t like the idea of having unneeded code running on many objects when there’s no need to.
… These are exactly the kind of psychological issues that lead programmers into a dark void.
Solving problems that you don’t have is a waste of time -> Let the computer work for you, not the other way around.
That said, I’ve created a small demo, with three different scenes, showing three different methods:
Always: Yes, this script will always run, but which code runs depends on the number property, and how the given conditional directs execution flow - In terms of processing cost, the conditional statements are negligible, and centralizing your logic into a single Python script can have significant organizational benefits.
Property: With a specified interval, the script will only execute within the given range.
State: In state 1, you run, and then go to state2. In state 2 you reset the property, and go to state 1. Rinse and repeat.
I guess you want to activate the next execution of the controller dependent on the output of the previous run.
This is indeed a nice method, especially when most of the time the controller does not do anything (beside to check if it has to do something).
It is a often used with state machines and timers.
Unfortunately you method has just two outputs:
A) trigger the next frame …
B) do not trigger at all
B is only useful if you want to stop the controller (which means it must be triggered by an other external signal)
A is pretty much True pulse without delay.
Something that others have already mentioned is to use a Property sensor. Just hook it up to a property, like “active”, with the property being equal to True, and then set it to a positive pulse rate.
If the object’s active, it will run the script every frame (or as often as you need it to).
If you need to shut it off, just have it set the property to False.
If you need to turn it on externally from another object (i.e. the Player, or a “System Controller” object), just use Python to set the “active” property to True again.
jokes