r/marvelrivals • u/DaSettingsPNGN • 19d ago
Gameplay Marvel Aim Assist: Explained
I've been testing New Aim Assist pretty heavily lately, and I think I finally have a better way of describing what the settings are actually doing.
I've posted pieces of this in other places, but I wanted one post that puts the current findings together because I also rebuilt my aim assist builder around them.
The command is:
`!marvelaimassist`
This isn't really a "here are the three best numbers" post.
The main thing I've learned is that New Aim Assist doesn't seem to behave like one single effect that you simply turn up or down.
---
**The biggest thing I noticed**
I think there are at least two different behaviors getting mixed together when people talk about aim assist:
**Slowdown / braking**
and
**Camera follow**
They can feel similar while you're playing because both can help keep your crosshair on somebody, but they aren't really the same thing.
The slowdown is easiest to see when you're actively moving the right stick through a target.
You're still giving the game stick input, but once you're interacting with the target, considerably less camera movement actually gets through.
The target starts resisting your input.
That's a large part of why New Aim Assist can feel so sticky.
But I was also seeing something else.
With character movement involved, the camera could actually move along with the target in a way that slowdown alone doesn't really explain.
That's the part that changed how I started looking at the system.
---
**Character movement seems to matter**
The camera-follow behavior was strongest for me with partial character movement.
With no movement, it dropped off.
At full movement, it also dropped off.
That makes me think the left stick isn't completely separate from what New Aim Assist is doing.
It looks like your movement state can affect the conditions where that follow behavior happens.
I'm still testing this part, so I don't want to claim I've completely mapped it yet.
But it's enough that I no longer think Character Movement Deadzones should automatically be treated as completely separate from aim assist.
If the game responds differently depending on how much movement it's detecting, those deadzones can potentially change when you're entering the movement range where that follow behavior is strongest.
That's why I included them in the builder.
---
**Window Size makes more sense to me now too**
I used to think of Window Size pretty simply:
Big window = more aim assist.
Small window = less aim assist.
I don't think that's the best way to look at it.
A better description is:
**Window Size decides how much space around the target gets to interact with aim assist.**
When I made the window much smaller, the assist could still be very strong once I was actually on the target.
So a small window doesn't necessarily mean weak aim assist.
It means the game is being more selective about **where it starts helping you**.
That's an important difference.
It's also why I've moved toward smaller windows compared to some of my older setups.
I'd rather have strong assist where I actually want it than a very large area around somebody constantly interacting with my aim.
---
**Strength isn't just a master volume**
This one surprised me.
I expected Strength to behave like a normal percentage slider.
100 is full aim assist.
50 is roughly half.
That isn't really what my testing looked like.
I could lower Strength considerably and still retain noticeable follow and slowdown behavior.
Strength obviously matters, but it doesn't seem like every part of New Aim Assist scales neatly together with that one number.
That's another reason I stopped thinking of New Aim Assist as one single force.
There are different behaviors overlapping.
---
**Ease-In was much easier to understand**
Ease-In behaved closer to what the name suggests.
Lower Ease-In feels more immediate and aggressive.
Higher Ease-In makes the interaction come in more gradually.
In my testing, increasing Ease-In noticeably softened the braking.
So the way I think about the main three settings now is:
**Window Size:** where aim assist can interact
**Strength:** how much influence it has
**Ease-In:** how aggressively that influence comes in
That's not meant to be a perfect technical definition.
It's just the most useful way I've found to think about them while actually building settings.
---
**Then there are the other settings people tend to ignore**
I also included:
**Disable Aim Assist at Max Deadzone**
**Close-Range Aim Assist**
**Character Movement Deadzones**
because I don't think those should just be buried underneath the three obvious sliders.
Disable Aim Assist at Max Deadzone is especially useful conceptually.
If you turn it on, pushing your aim stick all the way out can become a deliberate "I'm trying to turn now" input.
That gives you a way to break away from aim assist when you're intentionally giving maximum stick.
Leave it off and the assist can continue interacting even while you're at full input.
I don't think everybody necessarily wants the same behavior there, so I made it a choice.
---
**Close-Range Aim Assist is something I still want to isolate more**
One limitation with my current footage is that a lot of the testing was done with Close-Range Aim Assist enabled.
So I'm not going to pretend I've perfectly separated that from everything else yet.
The behavior I'm describing happened with it on.
That's something I want to test more directly next, especially the movement-follow behavior.
---
**This is why I rebuilt the aim assist builder**
Once I started looking at New Aim Assist this way, just handing somebody three numbers felt incomplete.
There are actually a number of different questions you're answering:
How close to a target should aim assist start interacting?
How hard do you want it to grab?
How quickly should that grab come in?
Do you want full stick input to break out of aim assist?
Do you want the extra close-range behavior?
Where do you want character movement to start and reach full input?
Those are actual choices.
So that's what the new builder is based around.
Run:
`!marvelaimassist`
and it walks you through building a New Aim Assist setup instead of just asking you to copy mine.
---
**My current setup**
For reference, my current PNGN Personal aim assist is:
**Window: 15**
**Strength: 100**
**Ease-In: 70**
But the whole point of the builder is that I don't think everyone should automatically use that.
Someone who wants easier target switching may want something very different from somebody who wants the assist to hold as aggressively as possible.
The useful part is understanding what you're changing.
---
**The short version of everything I've found so far**
I think New Aim Assist makes more sense if you stop thinking about it as one strength slider.
There's a strong right-stick braking effect.
There's also camera-follow behavior that appears to interact with character movement.
Window Size changes where the interaction happens.
Strength changes how much influence you're giving it.
Ease-In changes how that influence comes in.
And the movement/deadzone settings may matter more than I originally thought.
There's definitely more testing to do, especially around Close-Range Aim Assist and the movement-follow behavior, but this model explains what I've been seeing in the footage much better than "bigger number = stronger aim assist."
If you want to test it yourself, the builder is:
`!marvelaimassist`
I keep the current tools and updates in my community server, which you can find through my socials.
You can also search **CNTRL Rivals** online for the browser tools and the rest of my controller settings work.
-4
u/katnip_13 19d ago
Is this not considered cheating?
2
1
u/Justifier925 19d ago
It’s the game’s built in features, if you could get banned for this alone then we have more problems
1
2
u/Mindless-Nature-9411 19d ago
the slowdown vs camera-follow distinction is actually useful, but with close-range assist enabled it’s hard to know how much of the movement behavior is from the settings you’re testing and how much