Changelog

Both sit in the Game Animation Sample code the demo is built on, and both appear only in a packaged Shipping build. The ragdoll works from a fresh boot and then stops part way through a session, after which triggering it leaves the character floating instead of falling. The slide misbehaves from the moment the build starts.

I spent a long evening on these and the useful part is what they are not, because the negative results are solid in a way none of my theories turned out to be.

Not the content I cut to shrink the demo. Every hard and soft dependency of all 2,297 cooked packages was checked against the shipped container, and the only things missing are editor-only classes, object redirectors, and the character-swap blueprints I removed deliberately, which nothing in the demo's own game mode references.

Not the cook. The same cooked data drives a working Development build, with matching container hashes and byte-identical staged config.

Not the physics control asset, whose runtime data the editor and a cooked build read through the same serialised map. Not the get-up montages either: the chooser names four and all four cook.

What I did find is a real trap worth passing on. GetConsoleVariableIntValue returns zero for a console variable it cannot find, and the sample's character fed that straight into a Select whose first entry was Kinematic. A kinematic mesh never simulates, so the ragdoll's pose blend spaces drove the skeleton with no physics underneath it. I have swapped that Select so a failed read lands on PhysicalAnimation. That is a guard rather than a cure: it removes one route to a frozen character and cannot make a shipped build worse, but it did not stop the mid-session failure, so the console variable was not what was causing that.

A second trap, found the hard way: declaring those variables in [ConsoleVariables] as well makes things worse, not better. That section is applied before most systems exist, so the engine creates a dummy variable for every name it does not recognise yet, and the real registration is then skipped because the dummy already answers to the name. It broke a build that had been working.

The demo ships with the guard in and both faults still present. They are demo faults, they do not touch anything you install, and with a submission already in, chasing them further was costing more than it was returning. The lead I would pick up next is a Test configuration build, which keeps Shipping's stripping and optimisation but also keeps a log, which is the one thing I never had at the moment the ragdoll went.

PCR_CinematicExploration wants a slide of about 360cm across and 410cm down at its arm length, against a Max Slide of 220. So it sits at its limit rather than at the framing it was authored with, and the screen target it names is not the one you get.

The plugin half of this is fixed. A saturated rig used to turn a blend into a sprint and a stop, and now blends between what each rig can actually reach. What is left is the rig itself, which is simply mis-authored: either the screen target is too far off centre for that arm, or Max Slide is too small for that target. Worth knowing generally: if a shot does not sit where its screen target says, check the target against Max Slide before looking anywhere else.

so twenty-six of them are no longer carried into shipping builds.

It returns early when nothing is published, which is nearly every frame.

instead of the same numbers repeated across five headers.

and hidden from the picker. Camera Cut's own Ease In already does this, and the two fought each other. Existing sections still work.

It could not tell a Preset that had accidentally inherited a device Rig from one deliberately given its own, so it flagged the shipped Third Person Preset for doing something correct. The ladder-ordering errors cover the real fault precisely.

It fired on all twenty shipped Rigs, every one of which is tuned and feels right. The threshold was a rule of thumb rather than anything measured, and the two filters are not really in series on one signal. Relaxed so it only speaks up when the lead smoother genuinely dominates.

Marked experimental with it. It threads a doorway properly for the first time: walk at a door frame off-centre and the shot lines up with the opening before you reach it, instead of trimming a shot that was nearly lined up already.

Every version before this measured in the wrong place, and each one reported "no gap seen" in a real level while its own debug probes visibly found the doorway. The camera trails the character by an arm, so a feeler at the camera end reaches a door frame only once the shot is already in it, which is when the correction should have finished. Measuring beside the character buys the whole arm length of warning, and it is the same place and axis the auto-shoulder whiskers use.

It measures from the pivot rather than the arm origin for a second reason. The arm origin carries the shoulder offset, so a shot authored over the right shoulder measured less room on the right and asked to move left, on flat ground, because of its own framing. Because the measurement no longer moves when the shot does, the correction is open loop: the ask is a fixed function of where the character stands in the gap, so there is nothing to hunt against.

What counts as a gap changed with it. It used to need two whiskers at a fixed spacing either side to be blocked at once, a signature that only matches when the camera is already inside the gap and near its middle. The correctable offset worked out at roughly Gap Whisker Spacing minus half the gap width, about 10cm in a 70cm doorway however high Gap Max Shift was set. Approaching a doorway off-centre, the case the feature exists for, left one whisker in open air and nothing fired. It now measures how much room there is either side and calls it a gap when both come in under Gap Max Shift + Gap Whisker Spacing. That needs no symmetry, so it works from anywhere in a tight space. Gap Whisker Spacing no longer positions anything; it sets how tight a space has to be before this speaks.

Gap Probe Length now shapes the pair that decides. Centred on the pivot and laid along the arm, a capsule of length L keeps a jamb measured for half L before the character reaches it and half L after passing it. A swept sphere is a point with a radius, so it holds a jamb only while that jamb is within one radius of its line and loses it as soon as the character walks past. The shot then lets go of a gap the camera is still inside, which looks like unreliable centring when it is unreliable detection. The middle probe is deliberately still a sphere: it has to be clear rather than blocked, so length would make it hit sooner and drop the detection earlier.

The middle probe asks about the destination. It sweeps from the line the shift would put the arm on, not the line the arm is on now. Asking about the current line vetoed the case the feature exists for: a shot clipping a jamb because it is off-centre was told the arm was not clear, and the correction that would have cleared the jamb was refused by the jamb itself. It still catches what it was written for. A wall flat behind the shot blocks from every position within the clamp, so nothing moves, and that is a wall for the arm solve rather than a gap to thread.

Tested rather than eyeballed, because three plausible versions of this shipped doing nothing. A character is walked off-centre through a 90cm doorway in both lanes and the slide has to be a mirrored move towards the middle: 25cm off centre gives −24.5cm and +24.5cm, against an arithmetic expectation of 25. The same walk down the exact middle asks for nothing, and the same walk with no doorway invents nothing. Both come back 0.0. The suite is 30 tests and green. A 27cm figure quoted in this entry previously did not reproduce in a second geometry and has been removed.

The debug overlay now draws only what votes. It used to draw three parallel whiskers that had stopped deciding anything alongside the pair that actually decided. Watching those find a doorway perfectly while the readout said "no gap" sent three rounds of fixes at the wrong thing. The camera stack line now names which leg failed, middle clear|BLOCKED and sides bounded|open, and carries the room it measured either side in centimetres.

Why experimental, and where it is going. The thresholds have not been through enough real levels for the defaults to be trusted, and the architectural reason it is not finished is that gap centring and the auto-shoulder assist now take the same measurement, in the same place, on the same axis, and both move the shot sideways off the same asymmetry, so in a doorway they compound. That is not wrong, since the sliding shoulder crosses through centre and gap centring pulls there anyway, but it is two systems deciding one thing. The intended landing is to fold gap centring into the auto-shoulder mechanism: one measurement, one lateral decision, one place to tune. Until then, expect to tune Gap Whisker Spacing, and expect the property names to move.

Threading a doorway used to add its own sideways offset on top of whatever composition had decided, which is two systems deciding where the subject sits.

It now asks composition for the shift, by inverting composition's own projection: the correction in centimetres becomes the screen target that produces it. One thing still places the subject, and the correction goes through composition's limits and trim like everything else. A Rig with composition off keeps the old lateral slide.

The first version pulled the screen target towards centre frame instead of converting the distance. On a Rig already framed near centre that does nothing, and on any other it does an arbitrary fraction of what was asked. Gap centring is not a framing opinion. It measures how much room the camera has either side and asks to be put equidistant, which is a distance, and only coincides with "subject centre frame" when the character happens to be centred in the gap.

The pitch room limit on its own is a wall: you look down, the stick stops, and nothing else happens. The camera reads as arguing.

Pitch Room Frame Shift gives the shot somewhere to go first. As the room overhead runs out the screen target rises, so the subject sits a little higher in frame, which drops the arm origin by the same amount and buys real downward view without the camera climbing into anything. The limit still backs it up, but is reached less often.

Eased on the same clock as the limit, so the framing and the constraint move together. A shot that reframed ahead of the thing that caused it would look like the camera flinching at nothing. Composition does the moving, so it wants composition on. Zero turns it off and leaves the limit as the only response.

It always was in practice, with 19 of the 20 shipped Rigs carrying an authored composition block and none of them turning it off, but the default said otherwise and nothing in the editor said which of the two to reach for.

Composition and Shoulder Offset both look like they place the subject, and only one is ever in charge. With composition on, the offset is not consulted at all. It does not add, blend or fight, and the editor greys it out to say so. The one exception is auto shoulder swap, which still sizes its probe from the offset's Y, so the field stays editable there.

First person is skipped automatically now instead of relying on each Rig to opt out. A screen target is solved by inverse projection against the distance the subject sits at, and at first-person range there is no distance and no shoulder to place.

On upgrading: a Rig authored with composition ON is untouched, because that value was already saved. A Rig authored OFF and saved before this has no such record and will come back on. Worth one pass over anything deliberately opted out.

Two implementations of the same rules, producing one blend through one of them and two through the other. The volume is a subclass of the trigger now, so there is one implementation.

In split screen the first controller's pawn might not be carrying a Blendable camera, and every track then did nothing, silently.

so the pinch never fired on a wall the camera was already sliding into.

Three pieces of shared state carried on running, or froze at their last value, on Rigs that never read them. The follow ramp was the worst: a full second of ease-in by default, scaling every automatic voice, but advancing on any Rig where you weren't steering. It was always already spent by the time a Rig that needed it arrived.

both damper channels among them, so a blend changed how hard the camera followed without changing how it was smoothed.

The one-time fold of the old flat properties into the config struct was gated on a serialised flag defaulting to false, so a component authored after the fold, saved and loaded back, copied twenty-six untouched defaults over its own settings. Having a Preset assigned hid it; anything configured inline lost the lot.

ViewModePriority was 1 with InputProfilePriority at 2 and device detection on, so the input device Rig outranked every view mode and every Preset swap. This is the exact fault the Preset validator was written to catch, sitting in the shipped content the whole time. They are all at 5 now.

It compiled inside the project, because unity builds concatenate translation units and a neighbour happened to include what was missing. Built standalone the way the marketplace does it, eight files failed on missing includes and two headers used types they only forward-declared. Anyone whose unity grouping differed from mine would have hit the same thing.

PlayEngineShake hands off to the player camera manager, which is past our output stage, so those shakes could never be mixed or clamped with the rest, and nothing was scaling them either. The accessibility slider therefore worked on every shake except the ones from a marketplace pack. Comfort is now folded into the strength on the way out.

It scaled the direction towards zero and then normalised it, and PlayShake normalises what it is handed anyway, so every value above zero produced the same result. It blends against a random bearing now.

The settle test still ran alongside the envelope, so a double-hit curve retired at the dip between the two hits. The envelope owns retirement outright now.

Position was soft-clamped from the start and rotation was added raw, which is the wrong way round. Shakes are mostly rotation, so the one bus that could run away was the unbounded one. Clamped by magnitude now, so a pile-up leans the way it was already going instead of being squared off one axis at a time.

"Is the player steering?" was answered from a single frame's rotation divided by a single frame's time, an unfiltered derivative, then tested against a hard threshold. Mouse deltas arrive in packets, so a steady drag alternates between a frame of nothing and a frame of double, and dividing that by a variable delta widens the spread again. Around the threshold the answer flipped several times a second, and the look-at read that as the player alternately composing and letting go.

The rate is now filtered before anything decides on it. Instant to rise so steering registers on the frame it starts, about a sixth of a second to fall so one dropped packet is not read as having stopped, and the threshold has a band around it instead of an edge. The question is also asked once and shared, where it used to be asked twice from two copies of the same expression. LookAtSteerThreshold still means what it meant.

The band is the same idea and the same ratio the reacquire angle already used to stop the break chattering across its own boundary. It had never been applied to the rate.

The raw per-frame rate is untouched where it is genuinely wanted: the look overshoot needs the player's actual turn speed this instant.

A long-standing fault in decollide, triggerable by any low geometry over the character.

Decollide sweeps a sphere from the pivot out to the camera. When that sweep starts in penetration it cannot measure anything, and the code read the failure as a distance of zero and retreated the whole way to the anchor. The anchor is the pivot, which is the inside of the character's head.

The probe is also fat, 20cm by default, so standing underneath a beam makes the sphere at the anchor graze it while the character is in open space. The shot collapsed onto the pivot for as long as you stood there, which is the fault the block exists to prevent, caused by the block itself.

It abstains now, the same doctrine the feeler fan has always used: a sweep that begins inside something knows nothing about what is further along it. A genuinely buried anchor still retreats, told apart by a much smaller overlap test.

Found while chasing the above, and a separate fault. Shoulder Side is shared: it scales the Rig's shoulder offset and mirrors the composition target, for whatever Rig is in force. The assist simply stopped steering when a Rig had it switched off, leaving the last value it reached welded on. In the Slide response that value is continuous rather than a side, so it could strand the shot at any fraction of its authored shoulder.

A swap is left alone on purpose. Swapping is a decision about which side the shot lives on and survives the assist being switched off, exactly as a manual swap does. Only the continuous slide is released.

Walk into a hold volume, walk back out, and the camera settled somewhere it had no business being, tens of centimetres out and most often low, with no amount of standing still bringing it back. It read like a pivot offset that had failed to blend.

Composition solves in two parts: an analytic base that puts the subject on the screen target exactly, and a small dead-zoned trim for what the projection cannot know, such as pivot lag through a turn or look-ahead wobble. The base was always right. The trim had no way back to zero, so every transient it had ever absorbed stayed absorbed for the rest of the session.

Crossing a volume is a large transient. It wound the trim up on the way through and left it wound.

The trim now leaks, always. Leaking only once the correction had fallen to nothing was tried and does not work, because the soft zone scales the ask by a smoothstep of how far past the dead zone the subject is, so just outside the boundary the correction goes quadratically small while the error is still real. There is a band one soft zone wide where the loop neither corrects meaningfully nor releases. Measured mid-fault: an error of 0.152 against a 0.14 dead zone, asking for four ten-thousandths of a correction and holding 56cm of trim.

That band is a family of resting places, which is why the same walk finished somewhere different depending on whether it had been through the volume. A constant leak collapses it to one: the trim rests where the leak balances the ask, and the ask grows with the error, so one error means one answer and history cannot change it. Inside the dead zone the only answer is zero, so the shot returns to its authored framing instead of wherever it happened to be.

Released at a quarter of the correction rate, since absorbing something real is urgent and letting go of it never is. Verified across every shipped Rig: a walk that crosses a region volume now finishes within 0.06cm of the same walk that never entered one, against 6cm to 120cm before.

Blending to a Rig with a much longer arm pulled the shot back, and then, after the blend had finished, it kept going and the framing shifted again on its own schedule. Two faults on two different clocks, both a second filter standing between a blended value and the shot.

Predictive avoidance smoothed the arm rather than the shortening. SweepFeelers hands back the request unchanged when nothing is in the way, and that whole value was going through Feeler Smoothing, so the Rig's own arm length was damped by the feelers as well as blended by the blend. On a 0.5s blend the authored length arrived exactly on time and the arm was still 120cm short of it, finishing over the next 0.7s. It now smooths what the feelers took off, which is the only part they decide and which is zero when nothing is there. Arrival: 0.750s to 0.517s.

The composition base was blended and then clamped. Clamping is not linear, so it does not commute with a blend. Blending first and clamping after means the slide sets off at the speed of the whole gap, meets the limit part way through, and stops dead on it for the rest of the blend. Continuous in position, discontinuous in velocity, and the shot visibly changes its mind. Each Rig's base is now clamped against its own Max Slide and the two are blended, so the shot travels from where the old Rig sat to where the new one sits at one speed. The measured excursion went from 124cm to 5.8cm, and with the swing gone the two channels land 0.067s apart.

The general rule: over a blend, every value is a blend between what the two Rigs would each do. Where it passes through something non-linear on the way out, such as a clamp, a saturation or a threshold, the blend belongs on the far side of it. Only there is it a blend between two results either Rig would actually produce.

It drew every probe at last frame's arm length from this frame's origin, because CurrentArmLength is not solved until two hundred lines later. At a sprint that is a probe trailing the camera by a foot, which reads as collision lagging when only the drawing is behind. Moved to after the arm is solved.

Turning quickly beside geometry put the shot inside it, 18cm at 270 deg/s and 63cm at 540, and no collision setting made any difference, because collision was never what put it there.

The shot damper runs after collision. Collision solves a safe position, the damper publishes a smoothed one, and nothing required those to be the same point. Measured, up to 92cm between the position the probes approved and the position on screen. Rotation is the worst case because rotation deliberately passes through undamped, so the shot sweeps a wide arc while the damper is still catching up on the shape.

The damper may now lag inwards as much as it likes, and not outwards. Closer to the character than the shot asked for is a cosmetic error that resolves itself; further out is a wall. That is the asymmetry the arm damper has always run on, shortening urgent and lengthening cosmetic, applied to the one filter left out of it. Easing back out is untouched: when collision clears, the solved offset grows first and the damper is already the shorter of the two.

Turning at 540 deg/s beside a wall: 63cm inside it, to nothing. Worst approved-to-published gap across every case: 92cm to 7.6cm.

It had only ever been built on 5.8, and three things had drifted. deg/s is not a recognised unit before 5.4, so one property carries the unit in its display name instead. ISequencerTrackEditor gained a pure-virtual GetDisplayName in 5.6, so the two track editors implement it only from there. And two headers relied on includes that 5.8 supplies transitively: without DrawDebugHelpers.h, ENABLE_DRAW_DEBUG was undefined on 5.4 and the debug-draw half of the camera component silently fell out of the class. Verified by building on 5.4, 5.6 and 5.8 with strict includes; 5.3 and 5.5 by inference from either side of each change.

Bind two actors and it frames both.

The automatic follows stay quiet while a blend runs, then ease back in.

under the Blendable filter.

Saving a Preset checks the claim ladder is ordered correctly, the fault that produces a camera which silently does nothing when you change Preset.

for the comfort default on new sections, the camera probe channel, a fallback Preset, and whether the stack readout starts on.

Draws the Preset in force, both claim ladders with the winner arrowed, the blend in progress and any Sequencer weights.

covering the ambient handheld bus as well as transient shakes.

on the Sequencer subsystem. Drops every claim and gives input back first.

Blends the shot back to gameplay across a section, taking position, rotation, FOV and post process with it. The engine's own end-of-cut restore is an unblended SetViewTarget, so this covers a real gap instead of duplicating Camera Cut.

Six track types under one Blendable submenu: Transition, Shake, Preset, Look At, Effects Scale and Cinematic Mode. Everything a section publishes expires on its own, so playing out, scrubbing away and closing the sequence all clean up the same way.

Unreal only exposes eye-adaptation speed on post process volumes, which makes how fast your eyes adjust a property of where you are standing. On a Rig it becomes a property of what you are looking through and crosses with everything else, so a Preset that adapts slowly eases into adapting slowly instead of switching the instant a volume boundary goes past. Up and down are separate, because eyes are not symmetric about it. Off by default and defaulted to the engine's own 3 and 1.

on the main toolbar. Shows every setting that differs between two data assets, side by side and grouped the way the details panel groups them, and lets you tick rows and pull them across. It shows the diff first, because copying a block you cannot see the contents of is not a decision anyone can make well. Values are copied rather than linked, so nothing about it exists at runtime. The whole import is one undo step and the asset is validated straight after, since partial imports are how you get a resting pitch outside its own limits.

Works across all of Blendable's asset types, comparing whatever class two assets have in common. The picker is limited to assets declared by the plugin, decided by module rather than by a list of type names, so a type added later is included with no maintenance. Built on reflection throughout, so a setting added next year turns up in it for free.

in the content browser, so a folder of them is scannable instead of ten identical grey tiles. Registered as ClassIcon/ClassThumbnail in the plugin's own style set, where FSlateIconFinder looks, so nothing about the editor's style is touched.

both as a billboard in the viewport and in the outliner, so a level with a dozen of them reads at a glance instead of being a dozen unlabelled spheres.

Triggers, preset volumes, tooltips and Director actors all carry the plugin mark on a billboard, and the wireframe shapes default to a line thickness of 5 instead of the engine's hairline. A camera region is placed by eye against level geometry, and at the distance you stand to judge one, a one-pixel box against anything busy is invisible. The mark is screen-size scaled and on absolute scale, so stretching a trigger across a corridor does not smear its icon.

Editor-only throughout. The billboards are editor-only subobjects and nothing reaches a cooked build. The Director actor already had a billboard but had never been given a texture, so it drew the engine's fallback.

Adaptation speed was already a Rig property. How far it is allowed to adapt was not, and that is the half that decides whether a dark room reads as dark. Unreal's floor is -10, which with the default extended luminance range means adapt to starlight, and it is why an unlit room so often looks much like a lit one. Raise the floor and the eye stops opening, so darkness survives while both still settle fast.

All of it now sits behind Allow Rigs To Control Exposure in project settings, off by default. A Rig with every exposure box ticked is ignored until that is on. Everything else here changes how a shot looks; exposure changes whether the game is readable, and a project has already answered it in its own volumes and defaults. The gate covers the exposure bias and speed settings too, which were previously opt-in per Rig but ungated at the project level.

An inverted range is put in order rather than trusted. Unreal does not complain when the minimum is above the maximum. It pins the exposure, which looks exactly like adaptation having died.

Four pages covering authoring, spatial shakes, mixing and the ambient blend, plus the feedback interface that lets gameplay ask for a shake without naming the camera.

Priority on the asset now means something: while a higher-priority shake plays, lower ones are ducked by the mixer's ShakeDuckAmount, so an earthquake flattens the footstep rumble under it instead of the two adding. Off by default and equal priorities never duck, so an untouched project cannot tell the feature exists.

A looping shake is state rather than an event. "This is a rumbling shot" is a property of the shot in the same way its arm length is, and only one can be true at a time. So Rigs can carry an ambient shake and a weight, and it crosses on the Rig's own alpha: the camera pulling in and the rumble arriving are one move. Parameters interpolated, one solver, one continuous phase. Crossfading two loops would run two noise generators at different rates and let them beat against each other for the length of the overlap. One-shots are untouched: two grenades are two grenades, and an explosion must not fade because you changed Rig.

The channel also integrates the noise rate instead of sampling at Time × Rate, which only holds while the rate never changes. Blending is what breaks that.

Director ambient shakes keep the old stop-and-restart behaviour unless you turn on Director Ambient Shake Blends, so nothing changes on upgrade and the two are easy to compare.

All three were implemented but reachable only through the feedback interface, so a Blueprint could not trigger any of them. They now have the same public front door the other five verbs had, and the interface forwards to it.

Single Instance refreshes the shake already running instead of starting a second, which every looping charge-up wants: two copies at double amplitude with two noise seeds beat against each other. Max Concurrent caps the stack and drops the oldest, because twenty summed gunshots read as a blur. Both only compare a shake against copies of the same asset. Suppressing a different one would be a mixing decision, and mixing belongs downstream.

The spring says how a shake oscillates; the envelope says how loud it is while it does. Without one, ring-down is the only shape available, so a sharp crack with a long tail means making the whole thing sluggish. Retires on the envelope rather than on settling, or a curve ending at zero would sit there contributing nothing until the spring agreed.

for looping shakes, as a multiplier on NoiseFrequency. One rate across all three axes reads as texture, and a heavy engine wants slow vertical heave underneath a fast lateral buzz. A multiplier rather than three absolute rates, so the one dial that makes the whole thing faster still exists.

PlayWorldShake takes an epicentre and works out the strength from distance: inner and outer radii on the asset, three falloff shapes, and a bias for how much of the kick's direction comes from the blast. Out of range plays nothing rather than playing silently at zero, so a firefight on the far side of the level costs no active shakes. Distance is measured from the pawn rather than the camera, because the camera swings about and the same explosion should not change strength with which way you face.

instead of a spring and a noise generator with an asset in front of them. Everything below is additive with a default that reproduces the old behaviour. No property changed type and none moved, so the ten shipped shake assets load untouched and there is no migration to get wrong.

The feelers, the occlusion wait and the buried-origin hold had no page between them.

Looking down swings the camera up behind you, so under a low ceiling the stick can drive the shot into geometry and leave collision to rescue it. The player caused the pull-in and cannot see why. Pitch Room Limit measures the room above the camera and narrows how far down the stick may look, so it stops before the problem.

Only that direction. Looking up swings the camera down towards ground that is always there, so that limit would always be close, and a limit that is always close reads as the stick being taken away. Collision already handles the camera meeting the ground.

It only tightens the Rig's authored limits and only stops further travel. It is clamped against the current pitch, so it can never move to where the view already is and shove it back. It narrows the same clamp the authored limits use, so PitchConstraintTolerance softens it too and the stick decelerates into the limit instead of hitting a stop.

Measured from last frame's camera position. Solving it from this frame's pitch would be circular.

On by default and on every shipped Rig except aim and ragdoll. It narrows limits that already exist rather than adding one, rides the softening those limits already have, and with nothing overhead it measures full clearance and does nothing.

Sliding moves the shot sideways and leaves the aim where it was, which lines the shot up with a doorway but not the arm. Turning points the whole arm down it, and that is what keeps the camera off the jambs on the way through. Gap Yaw Assist, off by default and paired with gap centring.

It behaves like every other automatic aim here. It only speaks while the character is moving, only after Yaw Follow Delay of no look input, eases in over Follow Ramp Time, and stops the moment the stick is touched or a recentre starts. It is a voice in the same weighted blend as travel follow and slope follow, so it cannot fight them, only outvote them. Gap Yaw Urgency is how hard it argues.

The turn and the slide share one correction. Whatever the turn has taken comes off the slide's ask, and never past zero, so a turn that overshoots cannot make the slide push back. On the camera stack line they read as slide and turn, in centimetres. A growing turn against a shrinking slide is the pair working as intended.

Experimental alongside gap centring, and the less settled half of it, because this one moves the player's aim. Left off on aiming Rigs, where the player owns the yaw outright.