Do you modify logic bricks via Python?

Game Engine Game Engine Support and Discussion
1

I am currently experimenting with a logic brick to Python converter. I need to know how common of a use case it is for people to use python to modify/access logic bricks. I am specifically referring to modifying or accessing data from any subclasses of SCA_ILogicBrick. Modifying/accessing game properties and the Python controller (minus any SCA API) are intended to work.

2

I edit steering actuator targets, for ai, and track to targets for missiles etc.

that is all I can think of for now.

I use logic to modify properties that the action actuator uses, or python, but it’s not editing the action actuator.

3

I’m tired, so I’m guessing I’m misreading / not completely understanding your post. Are you saying that you’re planning to add Python API to create logic bricks in Python? I’m not sure what a “logic brick to Python converter” is.

I usually use Python to edit logic bricks that have no Pythonic equivalent, like the 2D filter logic brick. If I used Navmeshes, then I think I’d use the Steering actuator as well.

4

Definitely some valid use cases, thanks BluePrintRandom and SolarLune. I may have to rethink the structure of this converter a bit.

The goal of the converter is to take an objects logic bricks and create an equivalent Python script. This Python script calls functions that correspond to the sensors and actuators. The idea is to be able to replace the files that define the sensor and actuator functions for different engines. This would allow some one to use logic bricks with another Python engine, such as Panda. Eventually this could be made more generic to generate files in different languages, such as C++ for Unreal Engine.

However, the more I look at logic breaks, the more difficult this task becomes. There are some inconsistencies in the behavior of some of the sensors and actuators that are going to require special cases and make things very error prone.

Thanks for the responses so far. I wouldn’t mind seeing more use cases where the the SCA Python API is used. This information can be useful beyond just this converter project.

5

Here you are sir

use the mouse to aim, and press space to fire missiles in Ray missile demo

Space and w in Steering demo

A solution to this with logic would be to store a objects key as a property for the steering,
as well as recall the property in a input field.

keypress-----------and-----------Steering target=property

a solution for the ray it to make to so a ray saves a property. as well as setting a property in an added item using add object.

Then I could do it without python,

Ray enemy-------and-------edit object - add missile with property target set

Attachments

RayGuidedMissile (4).blend (607 KB)SteeringPythonExample.blend (462 KB)

6

Thank you BluePrintRandom. I understood the use case from your previous explanation, so I may not take much of a look at these.

7

I don’t see the need for a “converter”.

You can simply write the Python equivalents for all logic bricks once. That code can call on well defined interface functions, which can then be supported by engine specific backends - There’s no need to generate the Python code, so there’s no need for a converter.

8

Indeed, defining python code that mimics the interface should be simple to drop in, save for when users check type information.

9

I do this pretty often on actuators:

  • setting value on PropertyActuators
  • setting object on AddObject Actuator
  • setting target, camera etc. …
  • the whole S2A is designed to do this.

On the other hand I rarely reconfigure sensors.
But there are use cases too:

  • e.g. the keyboard sensors to do a remapping of the key to listen to.
  • The same to mouse sensors (see mouseOrbiter).
10

I hate logic bricks the more I use them. Yes they are easy to learn but really hard to use. So I really support this idea, converting messy logic to a clean understandable python code can actually add a functionality to logic bricks in advanced game projects that are more python-friendly as it would speed up the workflow. (instead of writing like 6 lines of code, adding some bricks and converting them to python)

11

Some which I found to be useful are:

  • bge.types.SCA_ISensor.frequency
  • bge.types.SCA_ISensor.usePosPulseMode
  • bge.types.SCA_DelaySensor.delay
  • bge.types.SCA_ISensor.reset
  • bge.types.KX_CameraActuator.height
  • bge.types.KX_CameraActuator.max
  • bge.types.KX_CameraActuator.min
  • bge.types.KX_CameraActuator.object
  • …
12

Ok, I will certainly need to find a way to make the system less static.

Goran, I suppose converter might not be the best of words. It might be better to call it an exporter. The ultimate goal is to be able to export the logic bricks to other engines.

13

YAY!
we can port right over to bullet potentially? or Ogre?

14

Neither Bullet nor Ogre are complete engines. I believe Kupoman’s idea is to convert logic bricks into a format that would be easily loaded into other complete game engines like UDK or Unity, or possibly Panda3D or Godot (not really as complete as the others, but is a full game engine).

15

Indeed exporter shows your intentions much better. The general problem you will have is that you need a target format. Typically you would chose a target game engine and one of the supported formats to describe logic there.

I guess it would be easier to manually recreate the behavior in the target engine. There is not really much demand to do such things. If it is needed it, you do it once and that’s it.