self-made "while" loop (with blend file included)

Game Engine Game Engine Support and Discussion
#1

File: sendmessage_loop_test.blend (485 KB)

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).

Attachments

sendmessage_loop_test.blend (485 KB)

#2

This is a hack … in a bad way.

If you need a constant pulse, use an always sensor.

#3

What do you mean with constant pulse? That’s exactly what I’m trying to avoid.

#4

Why?

What’s the actual problem that you’re trying to solve?

#5

If I understand right:

  • Always sensor without True pulse will run the script once?
  • Always sensor with True pulse on will keep running the script forever unless I remove the whole object or disable the sensor somehow?
#6

Yes … and where’s the problem with that?

#7

In some cases that will leave me an active sensor looping a code when I don’t need it?

#8

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.

#9

New file (states): state_loop_test.blend (487 KB)

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.

#10

Are you actually having a speed issue running your code? Because if not, don’t try to optimize it.

#11

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.

#12

… 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.

Attachments

example.blend (492 KB)

#13

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.

For more details on sensors have a look at: Sensors - A Word on Pulses

#14

the more fast should be a empty no collision with :

state1 :
always(no pulse) -> and(no priority)-> setState(2)

state2 :
always(no pulse) -> and(no priority)-> setState(3) (accelleration)

state3 :
always(no pulse) -> and(priority max)-> endObject() (explosion)

state plasma(with pulse) -> more than 2000 FPS

:wink: jokes

really state of logic brick should be the method that cost less .on micro object as smokes or particles can worth do it

#15

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.