#Mover: Wall Run & Testing

1 messages · Page 1 of 1 (latest)

hexed timber
hexed timber
#

Continued a bit with integrating a dash and the transitions between dashing/wallrunning/falling.

(ignore my skill issue at the first jump lol)

#

Mover: Wall Run & Testing

rocky flame
#

The inputs, Do they come from GAS?

hexed timber
#

They do yes, however I just use them as an intermediary to raise&lower the flags in a separate component that produces the Mover input

rocky flame
jagged venture
hexed timber
hexed timber
# 
void UBotaniAbilityTask_Jump::Activate()
{
[...]
    //@TODO: Check if we can jump ??? (mover also does this, so it might be a double-check)
    StartJumping();
[...]
{

void UBotaniAbilityTask_Jump::StartJumping()
{
    UBotaniMovementInputComponent* MovementInputs = GetMovementInputComponent();
    if (!IsValid(MovementInputs))
    {
        return;
    }

    // Only locally controlled pawns should trigger the actual jump action.
    if (IsLocallyControlled())
    {
        MovementInputs->Jump();
    }

    if (ShouldBroadcastAbilityTaskDelegates())
    {
        OnJumped.Broadcast();
    }
}
rocky flame
#

Makes sense, thanks ❤️

hexed timber
rocky flame
#

Do these ability tasks implement the IMoverProduceInput Interface?

hexed timber
#

no

#

but my UBotaniMovementInputComponent does

rocky flame
#

Aah I see, a custom component and the abilities are pulling off of that

hexed timber
# 
void UBotaniMovementInputComponent::Jump()
{
    // Is this the first frame we want to jump?
    bWantsToJump = !bIsJumpPressed;

    // Update the flag
    bIsJumpPressed = true;
}

void UBotaniMovementInputComponent::ProduceInput_Implementation(
    int32 SimTimeMs,
    FMoverInputCmdContext& InputCmdResult)
{
[.......]
        //Passing in the flags
    {
        // Set the jump flags
        BotaniAbilityInputs.bIsJumpPressed = bIsJumpPressed;
        BotaniAbilityInputs.bJumpPressedThisFrame = bWantsToJump;

        // Set the sprint flags
        BotaniAbilityInputs.bIsSprintPressed = bIsSprintPressed;
        BotaniAbilityInputs.bSprintPressedThisFrame = bWantsToSprint;

        // Set the crouch flag
        BotaniAbilityInputs.bIsCrouchPressed = bIsCrouchPressed;
        BotaniAbilityInputs.bCrouchPressedThisFrame = bWantsToCrouch;

        // Set the dash flag
        BotaniAbilityInputs.bIsDashPressed = bIsDashPressed;
        BotaniAbilityInputs.bDashPressedThisFrame = bWantsToDash;
    }
[.......]

pretty much this

hexed timber
rocky flame
#

That’s warranted

#

Lyra does that with hero comp

#

I think*

hexed timber
#

yeah might be, it just makes more sense for me as I have multiple actors ,that arent related, who need mover input

rocky flame
#

I was also planning on having very granular movement modes.

Like one for idle, one for starts, one for stops etc.

#

Do you think thats a bad idea

#

Each of these will be a bit different, because of the rotation

#

One for turn in place

#

Basically one for every leaf node in my abp statemachine

hexed timber
#

will be a lot of transitions to handle

#

right now i only have 4-5 different modes and its already quite a handful of transitions

#

why exactly would you need so many different ones?

#

I think MovementModifiers could be what you want

rocky flame
jagged venture
rocky flame
#

Itll be a bit hard to explain, but every state will follow slightly different rules for rotation and movement

jagged venture
rocky flame
#

Grounded -> Jump
Grounded.Idle -> Jump can inherit from the parent

hexed timber
rocky flame
#

Something like that so the logic can be inherited

hexed timber
jagged venture
hexed timber
#

Grounded should remain a single movement mode afterall.
If you want to modifiy it, use FMovementModifierBase

hexed timber
jagged venture
#

Since you're using GAS, have you explored anything regarding attributes and synced variables like that?

In CMC this is a big no-no, I'm assuming its the same here, but I also assume if I have a GAS ability that I want to use stamina, I can just subtract stamina when I activate it? 🤔

hexed timber
#

Well the best way to modify values such as stamina should be within the mover simulation.
For instance movement modes, layered moves, instant moves etc etc.

#

But it is still something on my TODO list how I can make use of GAS Attributes within Mover

#

My future goal would be to make MaxSpeed driven by a GameplayAttribute, but I havent put my hands on that yet

hexed timber
jagged venture
#

that seems weird

hexed timber
#

well just not directly

jagged venture
#

yeah i mean calling some function on mover or something like that is what i assumed

#

can layered moves affect state?

hexed timber
#

yes

hexed timber
#

which makes sense

jagged venture
#

pressing a button, to me, is 'external'

#

maybe 'directly' is the word?

hexed timber
#

oh yeah well, external in terms of directly

hexed timber
#

maybe

jagged venture
#

in any case, if layered moves can affect state, seems like you could use a layered move to adjust the stamina or whatever else?

hexed timber
jagged venture
#

just need to figure out a way to reduce stamina when doing a thing that isn't directly movement related

jagged venture
#

i really appreciate all this help btw

hexed timber
hexed timber
jagged venture
jagged venture
hexed timber
#

there is still a lot on my list to do

#

regarded to movement modes

hexed timber
jagged venture
# hexed timber regarded to movement modes

I am just interested in seeing how it works in general. I am trying to make a 3rd person action game and want to know the scalability of mover so I can compare it to GMCv2

hexed timber
#

Oh I see

#

well Mover still has its flaws, also when it comes to debugging

#

Visual Logger is my best friend pepesadgepray

jagged venture
#

im sure it'll get better lol. im really interested in seeing how they handle chaos physics, im impressed with it so far

#

inevitably id want to roll my own ECS based movement system, maybe using Mass, but replication for that seems awful so im going to wait a bit more for that side of things to cook

hexed timber
hexed timber
jagged venture
hexed timber
jagged venture
#

yeah same

hexed timber
#

with that little learning material available..

jagged venture
#

good enough it seems like

hexed timber
#

big of a task enough

mint forge
#

How is the state of mover as of 5.6?
What are the main features still missing to reach parity with cmc?
I cannot really find anything about it anywhere for some reason

mighty crest
#

can integrate advanced mover systems, inputs, transitions between dashing/wallrunning/falling, GAS and multiplayer support...

but cannot make a jump 😆

sorry i couldn't resist

jagged venture
#

otherwise it seems to be fine, still learning but you should check out Project Titan for additional examples

#

i know a YouTuber who will be doing a video on it relatively soon (next month or so I think)

mint forge
jagged venture
#

wish you luck!

jagged venture
# hexed timber well mover handles **a lot** of the replication side itself as it uses the Netwo...

I've been trying to figure out exactly what I need to account for in terms of replication

I noticed some classes have serialization and stuff. Am I correct in m understanding that as long as I do that appropriately, the rest of the replication is handled?

For instance, as long as i serialize the sync states and fill out the necessary function overrides, its just expected that it is there and automatically works with the rollback / prediction / etc?

rocky flame
hexed timber
#

Oh lol you mean my bad gameplay?

#

I mean..

#

Yeah...

#

Bad

hexed timber
# jagged venture I've been trying to figure out exactly what I need to account for in terms of re...

Well NPP does a lot of the heavy work for you,
as it already has builtin rollback support.

You have the InputCmd in which you can feed locally produced data, and from there on NPP processes that for you.
As long as you keep everything within that pipeline and dont try to modify it directly/externally you shouldn't have to worry too much about replication.

AFAIK thats also what mover intends to do, which is giving you more freedom for movement and less work in networking

hexed timber
#

If you are fine with not having multiplayer support, then sure go ahead

#

But otherwise it seems the work they did in Titan is pretty much a refactored version of stock mover

#

the only thing "new" would be the physics wok

#

however dont expect it to work in multiplayer

#

they detach the player from the mover simulation entirely, so when you exit the wok, NPP will just reset you to the last state in which the player still was attached to mover

#

(not forgetting that they treat Authority as LocalPlayer.............................. )

SPOILER_image.png
#

Dont want to blame them too much tho, as I think it was never meant to work in non-singleplayer environments

jagged venture
#

So did you subclass CharacterMoverComponent and such or did you just straight up make your own?

hexed timber
#

I dont like the way CharacterMoverComponent is setup

#

It comes with a few hardcoded things that you cant change which is really annoying

jagged venture
#

I think i agree tho, I think doing it yourself seems easier mentally

hexed timber
# jagged venture what were those things you didnt like?

well the helper methods for "IsFyling, IsFalling, etc" are quite nice.
But others like stance managing is not really extendable the way I would like.
They have a stance enum with just 2 entries, an existing FStanceModifier that I feel like is just for showcase purpose.

So to me it seems the CharacterMoverComponent is intended to represent the current CMC but using Mover framework instead.

#

I will also have stancing for my player, but it will be a few more than just the two that character mover comes with

jagged venture
#

Stances are things like jog / sprint within the grounded movement mode which doesnt require its own mode, is that right?

hexed timber
#

Yes

#

but not limited to ground movement tho

#

In case of CharacterMover it is Crouch and Prone

#

but thats it

jagged venture
#

I see yeah

#

Hmm

hexed timber
#

with Prone not even being implemented btw

jagged venture
#

it makes sense that its just an example

hexed timber
#

yes

#

same with CommonLegacyMovementSettings

jagged venture
#

Lyra had a ton of stuff like that

#

Hmm yeah

hexed timber
#

those settings purely exist for the sake of representing "CMC in mover"

#

so I make the same assumption about CharacterMoverComponent and StanceModifier

hexed timber
jagged venture
# hexed timber For instance ?

loading screen plugin, except it wasn't async so it would hitch and you couldn't play movies and such

Linked Anim Layers, except they didn't showcase unique logic in a layer, and instead just used them as a worse kind of data asset (at least to my knowledge, could be wrong)

Gameplay cues, except one ability replicated sound/animations manually (in the melee ability I think, its been a few years so its a bit harder to remember)

The modular UI was really awesome, but it wasn't setup to be extendable for all types of games

#

some of those are less because of the 'demo effect' and more about Lyra intending to be an example of a particular game done like that, as opposed to a universal and highly extensible framework for all types of games

hexed timber
jagged venture
#

A lot of it felt like it was more showcasing the underlying stuff, as opposed to being a representation of the best implementation you could do with the tech

jagged venture
hexed timber
#

haha yeah

#

funny thing is how often they forgot to rename things to ULyra_SomeName_, here and there are still leftovers being called UFort_SomeName_

jagged venture
#

oh really???

hexed timber
#

yep

jagged venture
#

thats so funny hahaha

hexed timber
#

UFortSignificanceManager for example

#

i think they fixed a few tho in later versions

hexed timber
#

there is a lot of those leftovers haha

#

but hey, we got partially source code access to some fortnite classes

jagged venture
#

I'll spend some time thinking about how I want to structure my own mover component for scalability. I feel like sync states would be a good place for generic speed boosts and such.

Would you have any suggestions for doing a data oriented approach to adding new states? I could just make a list of static values in some kind of 'MyMoverValues' somewhere, but I'm unsure.

Ideally, I'd want a system where later on in development I could just add in a new stance, and have that update a bunch of parameters. Like if in development I decided I wanted a 'tired' state, which slowed movement and prevented certain other kinds of movement.

A sync state is great for the tags, but I need somewhere to store 'this tag blocks this state' and such

#

is it a performance no-no to access a data asset on tick for all the mover components?

#

hmm i guess i also need to learn how to set defaults

hexed timber
jagged venture
#

i am mentally weak so seeing an example helps me get over that and start doing things lol

hexed timber
jagged venture
#

hmm i see

hexed timber
jagged venture
#

im mostly just unsure about where to store the data

#

and i guess default values

#

thats a bit unclear to me right now

hexed timber
jagged venture
#

So like if i wanted the tag system from GAS with blocking, enabling, etc

I would want a sync state of tags, but i wouldn't necessarily want to store what they block / enable right there would i? I feel like that should be stored somewhere else

jagged venture
#

i remember seeing that but didnt look deep on it

#

thank you!

hexed timber
#

yw yw

#

just let me know if you want to see anything specific from my code if it helps you

#

I dont want to share everything right now as its still a mess (hehe) but if i can help im happy

hexed timber
jagged venture
jagged venture
#

that makes sense actually

#

and is probably better, hmm

#

i was trying to think of a better way to do transitions, I almost wish there was like some 'utility ai' style thing where certain states get a priority based on context, and if i add a new state it can evaluate its own priority.

But that really ends up just feeling like you need to know all about the other potential states anyway and doesn't quite make as much sense here i think

hexed timber
#

I dont see why you should make transitions like that.
Transitions mostly only transition when an exact condition is met.
For instance my wall running starts if there is a wall, there is no need for any extra scoring/evaluation

hexed timber
#

for example

#

there are no required or blocked tags yet tho

jagged venture
hexed timber
#

I have WallRunning that owns WallJump transition

jagged venture
#

I see. WallRunning would also have a 'WallToGround' transition maybe? Like to go into falling if you just stop moving?

hexed timber
# jagged venture I see. WallRunning would also have a 'WallToGround' transition maybe? Like to go...

I actually have a transition for that, but I am not using it for the WallRunning.
The "WallToGround" transition would only exist to check if the current wall is valid or not, which i can easily check inside the WallRunning movement mode itself.
Also because while i am simulating the wall could be invalidated and i dont want to rely on the transition to detect that fast enough but rather just let the WallRunning mode handle it

hexed timber
jagged venture
#

Hmm okay

#

So if I had a flying mode for instance

#

I would need a dedicated transition for going into water (for swimming), a dedicated transition for hitting the ground (for grounded movement), etc. Suppose I had a grapple hook, I'd also need a transition for that if that was a dedicated mode for whatever reason

#

There's no way to just do like 'Exit this mode, go to a default mode, re-evaluate entry'?

#

i feel like that part is a bit clunky but it makes sense

#

I feel like there should be a way to add in forces or something so that you dont really have separate modes. Hmm.

#

You are manually calculating in gravity right? Like that's not a default thing?

hexed timber
# jagged venture I would need a dedicated transition for going into water (for swimming), a dedic...

Yes and No, well how do I formulate that now...
What I found is that it is best practice to only use dedicated transitions when it wont be fatal if the transition triggers not "fast enough".

From Falling->WallRunning I have a dedicated one, its okay if i slide for a few ms on that wall until i start running on it.
But not out of WallRunning, if the wall is gone mid-simulation then I need to react to that immediately and should not rely on a transition.
If there is no wall anymore, but a few ms of the simulation still "think" there is a wall, i get very bad results

jagged venture
#

I see. So how do you handle that?

hexed timber
hexed timber
# jagged venture I see. So how do you handle that?

Well essentially after every safe move in the WallRunning mode, I check if the wall I am running on is still valid.
If thats not the case, then I tell mover to trigger a new movement mode (falling) and refund the time that I didnt use, so that falling can use it

# 
...
OutputState.MovementEndState.NextModeName = GetFallingModeName();
OutputState.MovementEndState.RemainingMs = DeltaMs - WallMoveData.PercentTimeAppliedSoFar;
...
hexed timber
#

For instance I have curves to determine gravity over time over velocity

jagged venture
#

interesting

#

I see, hmm

#

This makes sense I think

#

Are you doing based movement at all, on moving platforms I mean?

#

I have not been able to figure that one out, and I probably just won't haha

#

like i just wont do that, probably..

hexed timber
#

It doesnt differ that much, except you need to check for current base and do with the bases velocity whatever you want

#

it is bigger of a hassel to make sure the base is in sync, as in multiplayer that can and will cause desyncs

jagged venture
#

so how do you ensure order? Like how do you know that the base has moved, so its safe to update your character?

#

and to propagate that?

#

Or is it just when the base moves, you propagate, even if you've calculated the character already?

hexed timber
#

Well you dont really need to check which moves first, base or character.
The movement logic remains mostly the same, except when it comes to finalizing the frame, in which you can tell that any movement you just did should be relative to certain base

#

also meaning that by default base velocity doesnt get taken into account

jagged venture
#

Hmm, im not sure how that makes sense.

What handles the propagation of the moving base to the character?

#

Like suppose your base was moving 10000 units in that one frame, just hypothetical

Your character moves 10 units

where is it handled that the character moves the 10,000 also?

hexed timber
#

First of all when you are standing still on a moving base your character itself has no velocity.

In the MoverDefaultSyncState when it comes to update the new position of your character you can provide a base which it will then use to propagate the bases location onto the character location

jagged venture
#

ohhhh

#

I see

#

so im sure somewhere when doing the calculations, it gets the base first / propagates it before doing the simulation tick of the other one?

#

or at some point in the tick it propagates it

hexed timber
#

it does it at the end of the simulation, at the part where it comes to updating the new position/velocity/etc into the sync state

jagged venture
#

i see i see, that makes sense

#

awesome

#

thats much more clear

#

this system is pretty cool

#

it feels like a good introduction to learning about movement models without having to worry about all the other stuff, like the hardest parts definitely seem to be handled

hexed timber
#

Yes thats true, which is also what mover is designed for

#

the only very very annoying thing is that due to its modularity, settings or other things you want to access can be very nested

#

which is also the reason I am using ScalableFloats for almost all my movement settings, as I can easily back them up via a registry then

#

so all my settings are in one place

jagged venture
#

have you stress tested your system at all?

#

curious about performance

hexed timber
#

Yes I sometimes do

#

But nothing unusual found so far

#

it indeed has a decent impact on the networking part, but thats fine

jagged venture
#

hmm okay

#

good to keep in mind

jagged venture
hexed timber
#

but it is interesting

jagged venture
#

im trying to figure out how hard it is

#

this kind of movement is extremely interesting to me

#

and also I think the chaos vehicles is really cool

mint forge
jagged venture
#

you should 100% look into GMC though if that's your concern, its pricey but well worth it I think

mint forge
hexed timber
hexed timber
jagged venture
#

well, in any case, you do you, i wish you luck 🙂

mint forge
mint forge
#

Next game tho, definitely wanna do something with physics

mint forge
hexed timber
mint forge
#

Yeah i remember that one, i just hoped they implemented it by now

jagged venture
#

I hope i can get there someday 🙏

#

@hexed timber yo yo, what considerations are there for applying instant movement effects and movement modifiers in a predictive way?

Suppose I have a gameplay element that sets a modifier, what would it look like to apply it?

hexed timber
# jagged venture <@959875236403220490> yo yo, what considerations are there for applying instant ...

Both should be applied through the QueueInstanceMoveEffect, QueueLayeredMove, Queue... function which will add them to a queued list in the movement mode state machine to be executed as soon as possible (on the next frame) in OnSimulationTick.
You would need to queue them on the local player and the server tho.
It makes sense to link it with a collision component, or through some input flags in the InputCmd

jagged venture
#

Maybe sprint is a bad example but

#

Some movement ability

#

That applies an instant effect, whatever that may be

hexed timber
#

For instance my mover component listens to the sprint flag, and if present, will activate a movement modifier

jagged venture
rocky flame
#

Got some velocity forward movement with mover

hexed timber
rocky flame
hexed timber
jagged venture
#

I'm trying to figure out the most appropriate place to store a replicated 'Mass' variable

#

I want the Mass variable to change during runtime, like an inventory system should be allowed to add to it

#

but i dont' necessarily want to make a sync state for it, as it seems unecessary to replicate all the time

#

if sync states automatically only replicated deltas, that would be one thing (that's not the case right?), but I don't want to replicate mass if it is remaining the same for 99.99% of frames

#

and only changing when I adjust my inventory and stuff

#

anyone have thoughts on this?

#

can I just do a regular 'on rep' variable on the mover component and set that normally when I equip an item and such?

#

ive not noticed this pattern anywhere else in mover which is why I was asking, unsure if there is a better pattern that i should stick to

jagged venture
#

also, any significant difference between having say 3 sync states with 1 variable, or 1 sync state with 3 variables?

jagged venture
#

(had a call with MajorT - didn't get ignored, posting here for others)

Summary of learning :

  • You can have a component with the input production interface on it, Mover will automatically check for that

  • You can make your input struct, and just pass / add it to input cmd collection.

  • Layered Moves generate proposed moves, which are mixed together and passed into the simulation tick for the current movement mode, which is the final arbiter of what happens. This is probably better than the array of forces sync state.

  • Movement modifiers modify a shared setting value. This is probably better than the mass sync state.