Animation frame triggers broken/unfinished?

Are animation triggers set by TSShapeConstructor not actually fully implemented contrary to this documentation https://torque-3d.readthedocs.io/en/latest/artist/playercharacter.html?highlight=trigger

This post from 2015 seems to suggest so : https://forums.torque3d.org/viewtopic.php?f=12&t=156&p=1712&hilit=animation+trigger#p1712

is this outdated or can you now actually define these supposedly available 30 triggers somewhere?

It says in the description what they are used for and how, where is the problem? I use them in my game, you set the frame to tell when the foot hits the ground to create a sound and a footprint. You set it in the player model script file where you also set the animations. For example :

%this.addTrigger("run", "4", "1");

%this.addTrigger("run", "14", "2");

That is my paintball player, left foot and right foot, animation is 21 frames long, foot hits the ground at frame 4 and 14.

"there can be up to 30 independent trigger states each with their respective on (1 to 30) and off (-1 to -30) states. You decide what each of those trigger states means"

But it seems states 1 and 2 are hard coded for footprints and you can't actually define any other states yourself. I was wanting to know if it was possible to actually define more states as the documentation says and have triggers that can do anything, not just make footprints/dust.

It seems to be as you mentioned, it is only for run animations, at least I have never seen triggers being used with anything else.

But what other animation could exist where you need triggers and what you need them for?

If you have enough time and motivation you can program something that will use 30 triggers, but I have no idea for what you could need them.

theres interesting stuff in "engine/source/t3d/components/animation/animationcomponents.cpp" . look for onAnimationTrigger maybe Itll help understand . I havent tried it but i guess I will soon . This at least makes me think Ill need a onAnimationTrigger callback (is call back the right word?)

Out of curiosity, what you want to use those triggers for? I hardly can imagine a field of application. I mean you could build a knight model with clunky armor and on every animation at certain frames you can play sounds as if the armor would make noise if you move in it.

But those animation triggers can be exploited, for example to avoid footstep sounds when moving, you could only move a bit, so that the animation never hits the point where it plays the sound, or when the sound is too early, you can mash the button a lot to make annoying noises.

I think the default Torque3D template has that problem, you can make skidmarks with the soldier by pressing the forward button a lot and ever time you press it will make a footstep decal on the ground, so essentially it looks like a vehicle with wheels had braked hard.

engine/source/t3d/player.cpp is where you will find the footprint stuff, around line 3949.

Those are some good points you bring up about animation triggers and looping animations. I am more interested in them for one shot action animations. My application that caused me to look into this was I wanted to use an animation trigger to create an empty mag "debris" object that would be created at a certain frame in a reload animation. Since I can't do that I just scheduled a function that does that with a delay in the weapon's reload state instead, but being able to use an animation trigger would have been nice because it takes the trial and error out of getting the timing right. I could see them being useful for knife/melee attack or grenade throwing as well in, where you want something to occur midway in an animation and not right at the beginning.

Ah yes I planned to implement that feature as well at some point in the future, but I did not do it so far, because it was so complicated.

I think even modern games in most cases don't have such features, I have seen it in old games, where it would simply spawn the clip and let it fall to the ground.

However I think you can better solve this with an out of the box thinking. For example, your reload animation should be two animations. The first animation will be the "eject mag" animation, after that is done, the magazine from the weapon will be de-spawned and a separate magazine will be spawned at exact the same location and it will become physical and fall to the ground.

Now when the weapon is empty, you can make another animation that will reload a new magazine into the weapon.

Advantages of this is, more realism, less glitches and easier to do, at least in theory.

I played games where all the reload is in one animation and you only had your weapon reloaded for real if the animation had finished 100%, if you only finished 99% and then switched to do something else, you in fact had a 0% reloaded weapon and had to start all over again. Some games even have you let exploit it and for example reload your weapon in an instant by pressing the right actions quick enough, to reset or skip the animations.

So I would say, if you want to have it realistic, then do it all the way. So each step of the process should be a physically separate animation and function, to prevent glitches and exploits. But I have no idea how hard it is to do this all properly, I only know some of the most modern and expensive games in history even cannot get this right.

In case you manage to do it I would be happy if you share it, so I can implement it myself.

What I implemented to far (well not me, but Tim MGT rewrote the reload function for me) is a realistic reload system, where it would throw away the remaining bullets and put in a new magazine, like you would do in reality. Most games unload the remaining bullets from the current magazine and add them back to the pool, which is physically not possible in reality that quick.

This is the first stage, the second stage would be, where the current magazine that is dropped would fall to the ground in the game for real, the next stage would be that it would become an item others can pick up with exactly the same amount of bullets left in it as there were when it was ejected by the person before.

Only the final step would be what you suggested, having the cosmetic animations exactly match what is going on there, but I would set this as the lowest priority, first I would make it work in the game for real and not bother if it looks good.

Stopping glitches / exploits is pretty simple. I have a function called "DeniedStateCheck" that I use for many things, including reloads, to lock out certain behaviors like switching weapons in the middle of reloading for example. Basically it gets the player's weapon image state, loops through an array of state names to see if the name matches any of the denied state names, and then returns a 1 or 0. As in your example, if the player requests to change weapons and the current image state name matches "CombatReload" or "TacReload", the loop will return 0 to the changing weapon function that called it and the request will be denied. Otherwise, it returns a 1 and the request proceeds. It is a very useful function. My function currently looks like this:

function deniedStateCheck(%player)
{
	%stateName = %player.getImageState(0);
	%deniedState[0] = "FireBranch";
	%deniedState[1] = "Fire";
	%deniedState[2] = "AimFire";
	%deniedState[3] = "CombatReload";
	%deniedState[4] = "TacReload";
	%deniedState[5] = "ToKneeling";
	%deniedState[6] = "ToProne";
	%deniedState[7] = "Activate";
	%deniedState[8] = "Release";
	%deniedState[9] = "Draw";
	%deniedState[10] = "NoDraw";
 
	for(%i = 0; %i < 11; %i++)
    {
       if (%stateName $= %deniedState[%i])
       {	
       	   echo("Denied State: " @ %stateName);
       	   return 0;
       }
    }
    return 1;
}

Yeah you are a true genius:

In reality you just made things worse, now that you cannot skip or cancel the animation, pressing that button in certain situations like a battle, which occurs like all the time in a battle game can mean certain death and you will have to make a lot of functions to cancel out a lot of stuff, since gamers can be very creative to circumvent your measures, I mean it is not that professional game developers have not come up with things like you came up with, but gamers still managed to break it.

It's a good function. You always have to bitch, don't you?

I'm a hardcore gamer and I just tell you what is hardcore annoying as a gamer and what you describe is one of those things. I'm just telling you that you are opening a can of worms. I cannot reach the developers from those mega corporations, but I can try reaching smaller developers from committing such atrocities.

And it is not just my opinion, I was showing you a comedy clip of what almost every gamer knows about and knows that it is stupidly annoying.

Sir_Skurpsalot , THX

engine/source/t3d/player.cpp is where you will find the footprint stuff, around line 3949.

No problem fLUnKnhaXYU

https://github.com/GarageGames/Torque3D/commit/11ac92acccb4ca4ab7d26aed90487c3f21c5a02e#diff-ee63be9e1180cd38f5b10d798839b5f1 not frame numbers per-se, but there's also that as a notion. to riff off of. effectively lets you trip stuff in sequence with callbacks in between. case in point from the wip game

function KrystalGateData::onBounce1(%this,%obj)
{	
    %pos = getWords(%obj.getSlotTransform(1),0,2);
    ServerPlayExplosion(%pos, MetalEXPBig);
    %obj.playthread(0,"bounce2");
}
 
function KrystalGateData::onBounce2(%this,%obj)
{	
    %pos = getWords(%obj.getSlotTransform(2),0,2);
    ServerPlayExplosion(%pos, BrickEXPBig);
    %obj.playthread(0,"bounce3");
}

Interesting, thanks

for the sake of less experienced interested reader (like me) , I would suggest that you study the relationship between player::oncollision (scripts/server/player.cs)and shapeBase::Pickup (scripts/server/inventory.cs) , player on pickup is written in the engine c++ while onInventory , onPickup are "invoked" in the torqueScript scripting code .