Add 'activate actuator' function (or method). #49171

New Issue

Vladislav · 2016-08-26T13:49:51+02:00

Vladislav commented

2016-08-26 13:49:51 +02:00

When I programmed several projects under BGE all times one moment corrupted me all the architecture. I could not activate actuator from not connected to it controller. So I suggest will be better to:

Remove necessity connecting actuators to controllers to activate actuators.
Why:

(a) if in scene will be hundreds of objects, physically will be difficult to connect all their actuators to controller.
(b) to simplify working with BGE: no need to make extra connections.
(c) this will increase amount objects, with which module can interact; this can make something like interface: object can have actuator with certain name, for example, 'wind_animation' and module will have no need to know: which keyframes will that animation have, what is it's name and etc. Module will be written once, than 3D artists could add objects with certain sign (or certain name, or certain parent), which will be processed automatically by the module.
Example:
controller_1.activate(scene.objects['sphere.008''].actuators['wind_animation'])

I thought about idea "interfaces" more time and then came to next suggestion:

Create for sensors, controllers, actuators method or function for activating them.
Details:
When we run activate(actuator) or actuator.activate(), the actuator of certain object will act like it was activated by controller.
Objects can be received dynamically at the runtime, 3D artists have no need to add lines to scripts or lines to logic bricks, they need just to create object with certain interface (for example, actuator with certain name) and BGE will proceed it.

Why to actuators:

(a) to expand the idea of "interfaces" and make it more easy to implement: no need to run contr.activate(), just object.actuators.activate() or activate(actuator_object).
(b) all like in 1.(c)

Why to controllers:

(c) What about the programmers? If a programmer will create some object which will have not actuator, but python script, which makes certain actions. Than he BGE will activate it and programmer will have no need adding lines to previous script\module or creating lines and adding lines to certain module.
Yes, the interface can be based on thesis that the object must have or controller or actuator with certain name. If object must do some complex logic - it can use Python controller instead of simple actuator.

Why to sensors:

(d) in a heap to rest.
(e) if object already has difficult logic, several sensors and each sensor is responsible for certain parameter. Than each script can change certain parameter (sensor) and object will analyze all itself.

This easy to implement solutions, as I think, will make BGE more convenient instrument for all people, who work with it.

P.S 1. Also with goal not to create extra connections between logic bricks of different objects can be implemented activate brick actuator.
This actuator can have three lines to choose in: 1. Object; 2. Type of logic brick to activate (sensor, controller, actuator). 3. Logic brick to activate (by name).
Why:

(a) this actuators can say "goodbye" to long connections between several objects and searching needed one between them.

P.S.2. I used to Github, so I don't know: can I add here such proposition. If I made something wrong - sorry, please write this to me.

What do you think about this? Maybe you can improve such decisions?
Thank you.

When I programmed several projects under BGE all times one moment corrupted me all the architecture. I could not activate actuator from not connected to it controller. So I suggest will be better to: 1. Remove necessity connecting actuators to controllers to activate actuators. Why: - (a) if in scene will be hundreds of objects, physically will be difficult to connect all their actuators to controller. - (b) to simplify working with BGE: no need to make extra connections. - (c) this will increase amount objects, with which module can interact; this can make something like interface: object can have actuator with certain name, for example, 'wind_animation' and module will have no need to know: which keyframes will that animation have, what is it's name and etc. Module will be written once, than 3D artists could add objects with certain sign (or certain name, or certain parent), which will be processed automatically by the module. Example: controller_1.activate(scene.objects['sphere.008''].actuators['wind_animation']) I thought about idea "interfaces" more time and then came to next suggestion: 2. Create for sensors, controllers, actuators method or function for activating them. Details: When we run activate(actuator) or actuator.activate(), the actuator of certain object will act like it was activated by controller. Objects can be received dynamically at the runtime, 3D artists have no need to add lines to scripts or lines to logic bricks, they need just to create object with certain interface (for example, actuator with certain name) and BGE will proceed it. Why to actuators: - (a) to expand the idea of "interfaces" and make it more easy to implement: no need to run contr.activate(), just object.actuators.activate() or activate(actuator_object). - (b) all like in 1.(c) Why to controllers: - (c) What about the programmers? If a programmer will create some object which will have not actuator, but python script, which makes certain actions. Than he BGE will activate it and programmer will have no need adding lines to previous script\module or creating lines and adding lines to certain module. Yes, the interface can be based on thesis that the object must have or controller or actuator with certain name. If object must do some complex logic - it can use Python controller instead of simple actuator. Why to sensors: - (d) in a heap to rest. - (e) if object already has difficult logic, several sensors and each sensor is responsible for certain parameter. Than each script can change certain parameter (sensor) and object will analyze all itself. This easy to implement solutions, as I think, will make BGE more convenient instrument for all people, who work with it. P.S 1. Also with goal not to create extra connections between logic bricks of different objects can be implemented activate brick actuator. This actuator can have three lines to choose in: 1. Object; 2. Type of logic brick to activate (sensor, controller, actuator). 3. Logic brick to activate (by name). Why: - (a) this actuators can say "goodbye" to long connections between several objects and searching needed one between them. P.S.2. I used to Github, so I don't know: can I add here such proposition. If I made something wrong - sorry, please write this to me. What do you think about this? Maybe you can improve such decisions? Thank you.

Vladislav commented

2016-08-26 13:49:51 +02:00

Changed status to: 'Open'

Vladislav commented

2016-08-26 13:49:51 +02:00

Added subscriber: @vlad1777d

Bastien Montagne commented

2016-08-26 16:21:33 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2016-08-26 16:21:33 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2016-08-26 16:21:33 +02:00

Bastien Montagne self-assigned this 2016-08-26 16:21:33 +02:00

Bastien Montagne commented

2016-08-26 16:21:33 +02:00

Thanks for the suggestion, but we do not accept feature requests or suggestions on this tracker (use forums or bf-funboard ML for that).
Please do not create design/todo tasks, they are reserved to developers.
Please do not set priority of tasks yourself, especially not to high priorities!

Thanks for the suggestion, but we do not accept feature requests or suggestions on this tracker (use forums or bf-funboard ML for that). Please do not create design/todo tasks, they are reserved to developers. Please do not set priority of tasks yourself, especially not to high priorities!

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Add 'activate actuator' function (or method). #49171