OK, This is a early release but it would be helpful with a little feedback and please do test if Your components run in this implementation.
Comes with a box set up to Moguri’s third person component. It should be pretty clear from the cubes game properties how to set a component up but here is also a excerpt from the tick.py docstrings:
Usage
Add an always actuator, set it to pulse, connect to a python controller
and set it to module and calling “tick.update”. This will both load the
component system and generate the default ‘tick’ event.
To config a component, add to a game object these game properties:
- Components = “foo, bar” - A comma delimted list of freely choosen component short names, to isolate the components namespace from eachothers. Short name ‘foo’ asumed for the rest of the help.
- Comp foo class = “module.class” - The module and class name of the component.
- Comp foo event = “event” - Set what event the component is connected to. Defaults to ‘tick’ for running on every logic tick. Optional.
- Comp foo id = “ID” - Sets a id for easy runtime access to the component. Optional.
- foo Parameter Name = Value - The components own args. Don’t have the ‘Comp’ prefix to isolate them from the generic parameters. Optional.
Some excerpt from component.py docstring
A Python implementation capable of using components from Moguri’s system unchanged - So components can be used Now and distributed to the masses!
However it aim at being more flexible and powerful:
- Components can run from different events - not only logic ticks.
- Components and other code can add new custom events.
- Components can optionally have a id for easy runtime access.
- Events have Schedulers that call connected components in different ways.
- Events are compatible with components so they can be fired from other events scheduler.
- Components, events and scheduler can be added, replaced and removed runtime.
- Integrate well with existing stuff like logic bricks state.
Attachments
components.blend (484 KB)