Which C file handles the action frame objects?

As you may know, I’m adding a feature to action frames that will allow them to set game properties. I’ve found the property actuators, so I know how to access game properties in C. Now I need to find the action frames, to discern how to best integrate the new functionality.

What I need to know, specifically, is which source- and header-files house the action frame objects. If there is more than one object that handles the overall process, which object is the main coordinator? Thanks in advance for any guidance you can provide. :slight_smile:

Could you explain how this differs from the frame property value in the actuator?

Take a punch, for example. In the first couple of frames, the punch is inert. Everything goes along as normal. Once the fist really starts moving forward, though, a game property within the fist (or a hitbox attached to it) holding an attack-power would be set from 0 to… whatever the strength of the punch would be. Once the fist stops thrusting forward, the property is reset to 0. The frame property just says which frame the animation is on.

What I’m building is a convenience tool for heavily data-driven projects that still has relevancy in smaller endeavors. A setup of logic bricks can be made for the same purpose, but I know from first-hand experience that it becomes unwieldy very quickly; and that can only get worse as the number of animations goes into the hundreds and the frames into the many thousands.

What Agoose77 means is - the frameProperty already gives you the currently played frame.

Could you explain that a little further? Is the frameProperty an object, or just a number? Where is it located? What processes it?

I’ve found a file/header-set called BL_Action, and that lead me to an object called AnimData. Am I on the right track, here?

Just have a look at the ActionActuator (in GUI). You see it there. If you hold cursor over it, you see a short documentation.

As the name says … it is a property.

The python method commands.


these functions are already implemented.

What I’m trying to do is not yet implemented in Blender.

The feature I’m imagining is attached to the process that determines which keyframe to use, at the point where that keyframe is first implemented. On top of Blender setting the physics of the object(s) being animated, specified game properties are also modified. The entire process is automatic. It’s an amendment to the current animation system, allowing for alteration of an object’s game-specific variables at arbitrary points; the data stored within the keyframes themselves.

how is this not breaking down an animation into separate parts, and doing the checking at intervals which is already given with the isActionPlaying & getActionFrame functions?

this is very simple stuff, mainly used for quicktime events in games for sequence changes.

i still dont see how the current api cant accomodate it, hell you can even do it with logic bricks if you have the time.

That’s way too abstruse and inefficient, especially when dealing with as many animations as I intend to. I’m aiming to develop a fighting-game, you see: that means dozens, if not hundreds, of actions; all of them with a plethora of unique, arbitrary conditions. Being able to set flags onto keyframes is practically necessary to do what I want to do.

why its easy.

A single Kick animation/action has 1000 frames.

10 x 100 frame loop variations of kicks.
you can call the frames you want.

its not abstruse and inefficient.

some people are just lazy.

Okay, we’re clearly operating off two different sets of priorities and values. This conversation needs to just come to a close now. ^^;

This sounds like high-level logic. I do not see why you want to implement that in the low-level BGE framework. I mean you can do that, but in my eyes it is needless effort as this is already possible in Python.

What you want to achieve cries for an FSM implementation. It is pretty easy with one Python controller and one ActionActuator.
I did that some years ago and it works pretty nifty. I know it is implemented by others and works well too.

From performance perspective there is no need to code this into the BGE. Such things are usually not time critical nor do they eat a lot of processing time.

Just my opinion
Good luck

If I was operating on a per-action basis, a brick-based solution would be best; but what I need and am implementing is that functionality on a per-frame basis. Storing and managing data on that level, and at the amounts I intend to do, outside of the frame itself is far more work than is necessary; for myself, and especially for any future users of the engine. I understand your concern, but this really is the best way, currently.