You should uncheck PlayAnimation task’s “ResetAnimationStateOnEnd” property
I think I have a fix for this but it may have to wait for the 4.26 patch. If you want to try a work around, duplicate your dodge (Let’s call it Dodge B), and have the original (Let’s call it Dodge A) branch to B, and B branch to A. I think the Remote Client isn’t seeing any change since you’re branching to the same ability. I have a potential fix (where remote clients always make sure they are running what the server expects them to), but again it may have to go in with the 4.26 support patch.
That’s ok, I will waiting for your 4.26 update
Hallelujah. Any chance of getting the offsets for targeting/collision queries made bindable, too? That’d be sick.
I’ve tracked my issues with input-based, client-channeled abilities to this. However, I can’t find the value “Can Client Cancel”. I see there’s a function override for it, but toggling the return does nothing to resolve the issue. Oddly enough, testing with a dedicated server causes the abilities to work as intended. When when testing with a listen server, channeled abilities the client activates that use an input condition immediately cancel. The project is primarily co-op and I intend for players to be able to host rather than using dedicated servers; I’m not worried about cheaters. I’ve tested in a packaged game and the problem persists.
Is there a fix I can do on my end or will I need to wait for an update?
I’ll look into that. Probably just something weird with Listen servers. If you can show an image of your channeling setup that would help.
Able is one of the first things I enable too, , and this video is a microcosm of all the reasons why.
Here’s a screenshot of my channeling setup. It’s only an input channel, eventually I’ll add stamina conditions but that’s not hooked up at all. I have a second “sprint” ability set up in this same manor and I’m getting the same result.
[ATTACH=JSON]{“data-align”:“none”,“data-size”:“custom”,“data-tempid”:“temp_206295_1604238248609_673”,“height”:“315”,“title”:“Block Conditions.PNG”,“width”:“446”}[/ATTACH]
It’s a looped passive ability with no stack decay:
Here is a video showing the erratic behavior. I hooked up strings Ability Start and Ability End. When the client uses the ability, the server seems to cancel it, but occasionally it remains on the client.
<3
Ah that video helps quite a bit! I’ll try and repro that locally.
Awesome! Glad the video helped. Keep me posted!
the function return value is the value not everything is a variable. so you found it right.
The dedicated server works fine as “client cancel” doesn’t refer to the server so player cant be the server. for that you have I think a second function “can be cancelled” - and this allows the server to cancel.
Most multiplayer games ends up with dedicated servers anyway
I have the same issue on my end though, and that bool is already unchecked.
It works if I use the montage version, but using the ability animation node the animation gets chopped up. I also made sure this issue is not due to my anim bp.
It might be related to an issue someone reported that has a fix going out with the 4.26 update. See if it still occurs when the next update hits.
@, a way to lock/freeze a task’s position on the timeline didn’t sneak into the update for 4.26, did it? I’d have so much <3 for something like that.
Locking? No, but it shouldn’t be hard to add. I’ll see what I can do but no promises.
It isn’t a pressing issue at all. It’d just be nice to have that extra layer of insulation from errant clicks.
While I’m here… I’m fiddling with something outside my typical wheelhouse today, and I’m sure I’m overlooking something obvious, but is a “traditional” first-person setup only possible by playing multiple animations on each mesh using a shared skeleton? “Traditional” here meaning “only-owner-see 1P mesh, owner-no-see 3P mesh” a la ShooterGame.
Using different skeletons throws up the expected warnings about skeleton/animation mismatches. Using the shared skeleton seems to be overriding whichever animation plays first with the second, regardless of slot setup or even discrete anim BPs, which is obviously going to cause problems in anything more developed than a very limited test scenario. I’ve seen mention of folks doing FPS with Able, so I’m fairly sure it’s just something I’ve missed in my experiments.
@
So I got some problems putting in animations.
I have a combo and the blending doesn’t work.
I’m using default blending settings, turned off “reset animation state on end” and my animation bp is using a “Blend by bool” node before the end output, which gets fed a bool using the “has ability animation” function.
Between combo attack 1 and combo attack 2, the idle combat pose is assumed, which then blends into the combo attack 2 animation.
Animation-wise, attack 2 starts with the same pose that attack 1 ends with, so blending should not be a problem at all.
Here is a gif that I recorded using the new animation insights:
The data is not on screen, but basically stated that nothing outside of the ability animation node was running. I also double checked to see if that bool was switching to ‘false’ for a frame between the two, which was not the case, so the animation BP is not the issue here.
Possibly noteworthy information:
I’m not using the ability node inside a normal animation state machine: I have a completely separate state machine called “AbilityStateMachine” with a single state called “Ability” with the ability animation node inside. I then cache that pose result to reuse it right at the end of the graph using the aforementioned method. It should not play a role, but since I don’t know specifics I felt like I should mention it.
EDIT:
I now added only the cached pose to the output pose, and also tried out doing it like it is in the tutorial, with the ability state inside the locomotion state machine. Same results.
I’m only using DynamicMontage for my montage, and everything is OK, you can try it.
Able doesn’t care about Skeletons, but it doesn’t know which skeleton to use if you somehow have multiples - so it tries to play it on all on them. So yes, in that case you would need a shared skeleton. I can look at a way to try and allow logic for both but I fear that might be a bit of a rabbit hole and make the task too complicated for people who don’t use multiple skeletons.
The bug I reference would affect blending too. It’s a pretty nasty bug, I was shocked I didn’t catch it and it wasn’t reported sooner. If you want to apply the fix locally, you can edit AnimNode_AbilityAnimPlayer.cpp and paste the following method over the current one:
void FAbilityAnimEntry::UpdateEntry(float deltaTime)
{
TimeAccumulator = FMath::Clamp(TimeAccumulator + deltaTime, 0.0f, AnimationSequence->SequenceLength);
}
The bug that currently exists is that the “+ deltaTime” was missing, so entries never progressed - which would screw up blending and a few other things.