CMC / Movement GAS Driven

[hardy mirage]

Interwined is good IMO.

I personnally like to have an attribute that is the custom movement type. Helps a lot with GEs with captures

Next is movement speed / acceleration etc.

That can, and I do advise to, have connection to GAS with attributes / tags

GetMaxSpeed() and GetMaxAcceleration in CMC both read attributes. Those can even be cached for better perf

Last are tags.

Movement types coded as tags is a base requirement imo.

they can and should be stored as enums within the CMC, but should be translated into tags.

GAS is relying a lot on tags to enable / disable, trigger stuff. So you'll do yourself a massive favor by adding them

[grizzled relic]

Thanks a lot, this has put my mind at ease a bit with how I was / planning on doing it so I'll be using this as a good reference point thank you! :)

[hardy mirage]

@grizzled relic have a look at Narxim's in the pinned links

I implemented the GetMaxSpeed like this

[grizzled relic]

Will do

[hardy mirage]

Have fun 🙂

[fresh gyro]

Hey, I am currently struggeling how to interface gas with the cmc for more complex interactions. I read through Narxims repo but only found this.
There were no Saved Move overrides or custom movmeent modes.
Is this the custom implementation you meant or did I not find the right implementation?😄

[hardy mirage]

That's it

Movementspeedmultiplier is updated by GAS

And you can basically do anything on it, the CMC will get the value

Now, you could replace yhe multiplier with the end speed you want

Whatever you choose, you would have to configure and define your movement modes

Narxim's is about GAS example, not CMC custom movement config 🙂

MovementSpeedMultiplier attribute can be changed in any way, with infinite or instant effects, with conditional tags etc ....

[hardy mirage]

AbilitySystemComponent->GetGameplayAttributeValueChangeDelegate(UMovementAttributeSet::GetMovementSpeedMultiplierAttribute()).AddUObject(this, &ThisClass::MovementSpeedMultiplierChanged);

that's the rest of it

Sprint is just applying / enabled an effect increasing MovementSpeedMult by X

[hardy mirage]

CMC / Movement GAS Driven

have a look at this playlist.
It is very good and well regarded.
https://youtube.com/playlist?list=PLXJlkahwiwPmeABEhjwIALvxRSZkzoQpk&si=orHQW8vHO5eFyMQx

[fresh gyro]

Ah ok I see, when I would react to a CC state change like stunned or root I would basically set the multiplier to 0 depending on Gameplaytags. Which essentially blocks the general movement input.
Then I would do all the disabling of movement related abilities via the GAS system.

[fresh gyro]

Yes it is a good playlist, I already went over it and got a basic understanding how prediction works for the cmc. Thats why I wonder how you would interface gas with the cmc for more complex interactions.

For example something like a knockback effect. For this I thought that maybe a custom movement mode would fit well. But the problem I have is how can I stitch gameplaytag state into movementsafe state. For example the client is moving locally and has a ping of like 100. He will generate his saved moves and sent them to the server. The server received those and replays those, but on the server he is currently affected by a knockback or some cc. In my head this will cause desyncs and a correction since the server does not have the gameplaytag state at the time of the older saved moves, since they get batched and sent at a later time by the client. Like how could the server validate those then when it replays the saved moves when It only has the current gameplaytag state to check.

Also I looked a little bit in movement related ability tasks, would you say that they are the way to go for things like dashes, jumping mechanics, etc. What about a grabbling hook.

[hardy mirage]

@fresh gyro

• Knockback: We have a GAS workflow that just use "LaunchCharacter" from CMC. I think we do it on source client to targets locally too.

Custom mode is probably too much and too complex

[hardy mirage]

RootMotion task yeah ?

They are pretty good, and I do recommend using them

Note that player won't be able to control the player while they are active

meaning no air control, no movement, no rotation

and by defaullt, the engine is missing a pure rotation task. RN the only way to make it work is to use the movement one with a rotation

[fresh gyro]

Thank you for your help.
Ah ok I see, so I overcomplicated things in my head. So basically the customization on the CMC is minimally and most stuff is controlled over GAS workflows.

What would happen in the following scenario. You as the local client press your dash ability using a RootMotion task, which is locally predicted, assume this dash is rather fast. Now it takes some time to send the ability activation as well as the RootMotion of your character to the server. This movement gets then replicated to another enemy players machine. Now he wants to interrupt your dash and applies a root GameplayEffect to you.

Here I have 2 questions:
1.)
When the enemy player applies the root GameplayEffect, is there a way that the enemy sees a direct stop of the simulated proxies movement from the dash, or does the enemy player first sees the stop after the server ackes the GameplayEffect application.

2.)
In the time until you receive the root GameplayEffect from the Server, the dash on your local machine may already be finished.

From my understanding in this case you will get a correction and on the next server update snapback to the position where the server acked the GameplayEffect application of the other enemy player. How would the server stop the RootMotion of your dash ability at the correct time, over GAS corrections or CMC corrections?

In my head the CMC will correct and there is always a desync since RootMotionSources get predictively applied through the CMC pipeline by the client and the client did not know about the root GameplayEffect. So the client buffers SavedMoves without knowing about the root GameplayEffect. When the Server receives the SavedMoves, he will resimulate them but only has the current gamestate to check for the root tag.

[hardy mirage]

1. I don't think you'll be able to see the "predicted" Root GE on the enemy client.
   Let's get the term straight:
   CLI 1, and 2.
   CLI 1 is an autonomous proxy on his machine, and a simulated proxy on CLI2

IIRC you can't predict GEs on simulated proxies. it will always go to the server first and come back

you CAN predict stuff on autonomous because you're the owning client. You don't have full authority, but it's close. And prediction is exactly for this use case

2. Yeah, there might be desync.
   At 5 ms ping, it will be very minimal.
   At high pings it will be noticeable ... but such is the reality with MP games

You could make your GE root effect "predicted" by doing it manually, if you wish.

like apply GE:

• Do I have authority ?
  No.
• Do I want to block the players movement ?
  Yes because I tag "State.Block.Movement".

In this case, get the CMC from the simulated proxy CLI1 and cancel all root motions tasks on CLI2

I don't say it will work, but that would be a way

You're exposing yourself to cheats and inverse corrections where this GE is rejected, so the root motion was fine ... but was killed locally ...

It's always a trade off you have to live with

Btw, corrections can be tailored for your game, and while I haven't changed them myself, I know that making them a bit more broad is a good idea.