Author Topic: Image slot 1 items failing to animate  (Read 2115 times)

I'm trying to make a two-handed weapon that reflects what the user's hands are (i.e. hooks vs hands). The system works, and when the weapon fires, both hands fire at the same time - the issue with it is that when the right hand fires, the left hand doesn't animate at all, despite firing correctly (its function for the fire state runs, so I know it's being fired). The image works correctly when used in slot 0.

Is there any reason why a slot 1 item wouldn't animate when it animates in slot 0?

If it's a player animation, you might be playing the wrong thread name (leftRecoil for left hand, shiftAway for right). If you're playing two different animations "at once" like you said, then they won't work simultaneously on the same slot (first argument of playThread) But if the names are right, then the fact it works fine in slot 0 makes me think you don't use a player animation unless you have code that can differentiate what hand the image is in. And the fact that playing them at the same time should make the right hand not fire if it's made the way I think it is.

So if it's an image animation, it will be triggered through the state system and not the scripted part specifically, with stateSequence[n] = "..." and should work so long as the state is executed which you made it sound like it does. If all that fails then toy around with the akimbo gun item, I know the left hand gun has an image animation AND a player animation that both work so it should help you solve either problem. Protip: altTrigger(1 or 0);

It isn't a player animation; it's a sequence animation. Sorry for not clarifying. It does use the state system as well, statesequence[n] is changed for all n that have corresponding animations, and the state is executed (assuming setimagetrigger(1, 1) is working right). I based most of the system off the akimbo guns anyway, but made sure they don't alternate but fire simultaneously.

I'll have a look at altTrigger - what's that from?

EDIT: Found altTrigger, gonna try to implement it into the weapon. Thanks a ton!
« Last Edit: December 17, 2017, 07:00:39 PM by irrel »

altTrigger(x) is just a client-sided function to set $mvTriggerCount1 to whatever you give it, so it's part of the move handling system. It is just like crouch(x) or mousefire(x), in this case it's equivalent to setImageTrigger(1, x) when the input reaches the server, and you probably know this is how the akimbo guns trigger the left hand gun to fire. So I only said it to help trigger the weapon directly and avoid anything else potentially getting in the way, I should have just said it was for debugging :P

It doesn't make sense for the animation to activate in slot 0 and not slot 1 if the state is transitioned. How do you know that the fire state works? If everything else like flash, smoke, etc works then you know it is... try the altTrigger(x) thing and see the left hand image's ::onFire is specifically being called, or whatever you set stateScript[n] to.

Okay, so altTrigger is for debugging - in any case, the onfire script runs (I tested that earlier with echo() in the onfire function).

altTrigger causes the animation, but setImageTrigger doesn't. Both run the onfire script successfully, which as you said doesn't make any sense. I'm going to test again with another echo() in the onFire function to make sure, though...

EDIT: Yeah, both hands are apparently running their onFire functions.
« Last Edit: December 17, 2017, 07:55:20 PM by irrel »

Be careful when using altTrigger(x) because if you call it with x = 1, then the trigger is "always" activated and will not cause a change in state until it sees a change from 0 to 1 again. Just like how repeating mouseFire(1) doesn't make you click more. I can see the potential mistake where entering altTrigger(1) makes it work, then entering player.setImageTrigger(1, 1) and observing it not working or the opposite effect of (1, 0) triggering it. Not that you did that or anything, I guess it's just a warning for anyone else reading.

There doesn't appear to be a difference whether altTrigger or setImageTrigger is used, as the server will just call the latter function when it gets the signal. There also isn't client sided image code that requires altTrigger to be used to "replicate" the state change visually and cause the animation, or the akimbo guns wouldn't work either. (Funny to think client sided weapon prediction is just a couple if statements away, though!)

If the animation names are all the same, try swapping out the model for the pistol dts the gun uses and see if the same thing happens. At least then you can narrow it down to some weird model error. An easier thing to do might be replicating the states in the akimbo addon and see where the left hand gun stops working, if anything..

Did you manually call setImageTrigger, ie fcbn(name).player.setImageTrigger(1, 1); ? (and getImageTrigger(1) was 0 before?) In the same environment you tried altTrigger in. Now that would 100% make no sense.

The only thing I can think of is that you have a transition on trigger up, which is immediately changing the state.
setImageTrigger on players only sets the trigger for one frame.

this is actually caused by a glitch where blockland decides that it doesnt need to update the image states on the client side I'm still not 100% sure what causes it and it plagues me all the time, could you show your image states and code and I can give you some ideas on how to make it update

this is actually caused by a glitch where blockland decides that it doesnt need to update the image states on the client side I'm still not 100% sure what causes it and it plagues me all the time, could you show your image states and code and I can give you some ideas on how to make it update

Absolutely, here are the image states:

Code: [Select]
stateName[0]                     = "Activate";
stateTimeoutValue[0]             = 0.2;
stateTransitionOnTimeout[0]      = "Ready";

stateName[1]                     = "Ready";
stateTransitionOnTriggerDown[1]  = "Fire";
stateAllowImageChange[1]         = true;

stateName[2]                     = "Fire";
stateSequence[2]                 = "fire";
stateTransitionOnTriggerDown[0]  = "FireDelay";
stateScript[2]                   = "onFire";
stateTimeoutValue[2]             = 0.05;
stateTransitionOnTimeout[2]      = "Reload";

stateName[3]                     = "FireDelay";
stateTransitionOnTimeout[3]      = "Fire";
stateTimeoutValue[3]             = 0.1;

stateName[4]                     = "Reload";
stateSequence[4]                 = "reload";
stateScript[4]                   = "onReload";
stateTimeoutValue[4]             = 1.0;
stateTransitionOnTimeout[4]      = "Rack";

stateName[5]                     = "Rack";
stateSequence[5]                 = "rack";
stateTransitionOnTimeout[5]      = "Ready";
stateTimeoutValue[5]             = 0.5;

And the function that executes when the right gun is fired:

Code: [Select]
function blueSMGHandsImage::onFire(%this, %obj, %slot)
{
%obj.setImageTrigger(1, 1);
echo("Right hand fired");
}

The echo is there for testing and will be removed later.

... If the animation names are all the same...

They are, and they use almost exactly the same code. The only thing I added was to eject shells when the right hand fires.

I did some more looking and the reason it breaks is pretty dumb. I said both altTrigger and setImageTrigger will do the same thing as far as the server is concerned, but it turns out the way the game orders events it will cause setImageTrigger to execute before player trigger processing executes. So you can try and set trigger 1 to on, and the server will treat it just like the player sent the input, but input processing will cuck it back to off later in the same tick... lol

BUT that doesn't explain why the akimbo guns work just fine. There's also a state field called stateFire[n] that has to be true for the firing animation state, with that set setImageTrigger will still go through the motion of being set back to whatever the client has it, however there's something left over that is still sent to the client that will actuate the state change in a different way. This means stateFire[2] = true should fix it.

The whole image state system seems pretty slapped together/concrete so I'm not surprised there turns out to be a billion ways to do a specific thing that work just fine abstract... it's pretty disappointing how limited it turned out despite what looks like an attempt to add cool functionality to certain weapon states.

OH, and you have stateTransitionOnTriggerDown[0] where you define all the info that otherwise uses [2].
« Last Edit: December 18, 2017, 09:07:35 PM by Val »

I did some more looking and the reason it breaks is pretty dumb. I said both altTrigger and setImageTrigger will do the same thing as far as the server is concerned, but it turns out the way the game orders events it will cause setImageTrigger to execute before player trigger processing executes. So you can try and set trigger 1 to on, and the server will treat it just like the player sent the input, but input processing will cuck it back to off later in the same tick... lol

BUT that doesn't explain why the akimbo guns work just fine. There's also a state field called stateFire[n] that has to be true for the firing animation state, with that set setImageTrigger will still go through the motion of being set back to whatever the client has it, however there's something left over that is still sent to the client that will actuate the state change in a different way. This means stateFire[2] = true should fix it.

The whole image state system seems pretty slapped together/concrete so I'm not surprised there turns out to be a billion ways to do a specific thing that work just fine abstract... it's pretty disappointing how limited it turned out despite what looks like an attempt to add cool functionality to certain weapon states.

OH, and you have stateTransitionOnTriggerDown[0] where you define all the info that otherwise uses [2].

Thanks for all your help! stateFire[2] worked perfectly (and that was a good catch on stateTransitionOnTriggerDown[0], that fixed another problem I had)!

I'll leave the thread open in case you guys figure anything out about the akimbo guns.

Oh, that's just rhetoric... I meant to illustrate the contradiction of the akimbo guns working fine despite the glitch I just described. They use the stateFire thing, which is why I brought them up! :P