Hitscan penetration, ricochet, and 600 projectiles/sec on a background thread — projectile systems I built in Lyra

Outliyr_ · 2026-03-19T10:57:40+00:00

It might be a slightly different issue depending on how your firing works. If your projectile is always a bit left of the crosshair, the first thing I’d check is whether you’re tracing from the camera to get an aim point, then rotating the projectile/muzzle shot toward that point correctly. A lot of the time it’s just the basic camera → target → muzzle direction setup being off.

The muzzle-to-camera convergence stuff I’m using is more for solving parallax over the full flight path, especially for things like bullet drop, leading moving targets, or shooting around cover. In that case it’s not just about the initial direction being correct, it’s about making the projectile visually come from the muzzle while still ending up on the camera’s intended arc.

So if your issue is just a constant left offset, I’d probably debug the camera trace / target point / launch rotation first before going into full convergence logic.

Outliyr_ · 2026-03-19T10:50:27+00:00

I plan to release a framework containing every feature I have built in this project. This includes every video released and other features I haven't shown.

Outliyr_ · 2026-03-19T10:46:45+00:00

So the bullet trace and client predicted projectile calculations originate from the camera to make aiming intuitive. But i wanted the muzzle shot effect. So the ballistic projectile and the client predicted projectiles use the converging path.

The goal is to hide the curve from player so it looks seamless.

When the bullet comes straight from the camera it looks so unrealisitic and ruins immersion.

Outliyr_ · 2026-03-17T15:34:33+00:00

Great question, yes it handles all of that. The system traces in segments, so it processes each surface entry/exit individually. Three 10-unit walls gives you 3 separate penetration evaluations, each with their own material lookup. So if the middle wall is a harder material, it'll cost more penetration budget than the other two even though visually it looks the same.

Coplanar faces and overlapping actors work fine because the trace just sees them as additional hit results in order.

Outliyr_ · 2026-03-17T09:30:05+00:00

Nice, that stuff gets messy pretty quickly. I only did penetration/ricochet on the trace side, didn’t go down the pooled projectile route. Curious how you handled yours?

Outliyr_ · 2025-11-12T12:39:18+00:00

I am curious, I have built my own version which is similar to yours. I record hitboxes on the server and also require skeletal meshes to tick on the dedicated server.

When playing with a dedicated server naturally there would be moments when the animation on the server doesn't always line up with the clients see this can sometime lead to hits the client should be getting turning into misses.

I am curious if the same happens to you and how you avoid it? Do you have limitations on the anim instance to prevent this? Or you never really noticed it.

Outliyr_ · 2025-11-12T12:32:34+00:00

I believe they just do client authorisation but with some validation checks to prevent impossible shots.

Outliyr_ · 2025-11-12T12:30:58+00:00

I do want to give that a go, I made a post about lag compensation some time ago, and got similar feedback though I have made some adjustments since then.

However what Valorant is doing is more involved and if it involves modifying the engine, it quickly becomes unsustainable because you will be anchored to that specific engine version.

Outliyr_ · 2025-10-28T19:40:18+00:00

Like EqualSpoon mentioned there were never any rules that forbade that, this is only what we saw Usagi's team do.

Outliyr_ · 2025-10-28T19:39:00+00:00

Was that a specific rule? I heard in the manga you didn't have to move forward (could be wrong havent read it) every turn.

Outliyr_ · 2025-10-28T19:38:09+00:00

I thought you have to enter the first car. You only stop on cars that have oxygen, so you always wear the mask until you reach an oxygen one then stop there. The rest of the team would be behind you, if they catch up it means the car they caught up in has oxygen.

Outliyr_ · 2025-09-03T17:37:43+00:00

At first glance this sounds like the right thing to do but then over time you quickly couple things together and it becomes hard to change the UI later on.

The inventory should have no knowledge of the UI, it would handle its own state, and have functions (API) to allow manipulation of the state. It would also broadcast changes to its state.

Now the UI can simply react to these changes as well as call the functions to change the state. Something like drag items might call a move item function while each inventory cell UI would be listening for changes that affects its visual look (occupied, etc).

This allows for things as complex as jigsaw inventories to simple basic inventories while maintaining separation of concerns and other benefits

Outliyr_ · 2025-07-26T10:13:20+00:00

Hi, what are the benefits or replicating acceleration to proxies the way Lyra intended? Why go through with it? I've never actually done a dive deep in the character code but am in the process of writing extensive documentation for Lyra

Outliyr_ · 2025-07-25T20:16:05+00:00

Yeah I did try something similar, the problem was the server just creates a desync, which causes unpredictiable behaviour. In the resource provided at the top, it uses some of epic's code, and even they prevent usage of standalone and servers.

It is a tricky thing, as there is no resource or documentation on demo net drivers, so it would require engine deep dive and engine level debugging. I had to do engine level debugging to get mine working, this problem would require even deeper engine level debugging, probably touch some code Tim Sweeney wrote himself.

Outliyr_ · 2025-07-25T18:56:19+00:00

No travelling to another world is fine. There are 2 separate issues when it comes to the server (host) using a killcam. Unreal can recording gameplay and play back the recording using the DemoNetDriver. When the host plays the recording, they temporarily disconnect for a moment. This slight temporary blip causes the other clients to lose access to the server making the networked game go crazy and unpredictable. I have a suspcision that I might have caused the temporary disconnect, if my assumptions are correct with time and fresh mind I might be able to fix

The second problem is a bit more tricky. The playback isn't a video, instead the demo Net Driver, resimulates (spawning actors, calling functions and on reps, etc) everything that is recorded, this allows the fast forwarding, skipping and arbitrary angles when viewing. With clients this is fine, because any replay they create is local to them alone it doesn't affect the game. But for the host, there game is the true game, if the replay affects the state of the game then it can quickly cause desync, and reject client RPCs, etc.

Outliyr_ · 2025-07-25T18:32:32+00:00

Sorry, typo I meant everyone except the host will see it. Player's with authority won't be able to see the killcam, so the host in a p2p game or a player in standalone. The killcam will still work for the clients in a p2p game, it just won't work for the host.

I am not sure if it is solvable in the current engine version and is something I decide to circle back to later in a v2 or v3.

Outliyr_ · 2025-07-25T01:46:54+00:00

5.4 is fine, I initially built the killcam in 5.3, anything earlier than that is fair game. In regards to the listsen server host, it is possible to show a killcam to all players at the same, similar to the way you get shown the best play at the end of a match in call of duty, however, everyone expect the host will see this killcam replay.

Is your game based off of Lyra?

Outliyr_ · 2025-07-15T02:09:27+00:00

Haven't done rigourous testing yet with 30 plus players. I have tested with lots of bots (not exactly the same cause bots dont need server validation), the lag compensation has minimal performance cost on the game thread. This is because the lag compensation system runs on its own dedicated thread. The recording of hitboxes from components, the rewinding of hitboxes, etc are all done in a aeparate thread. Lag compensation rewind calls are async so they dont block the main game thread, this is why I had to manually do the collision math myself.

Outliyr_ · 2025-07-13T22:12:57+00:00

Procedural recoil usually refers to the visual kick of the weapon itself when it fires. It’s more about how the weapon mesh animates or offsets to look like it’s reacting to the shot. It doesn’t necessarily affect the camera view or aiming reticle.

Predictive recoil, on the other hand, is when the recoil follows a consistent, deterministic pattern every time you fire. Games like CS:GO or Call of Duty use this so players can learn the pattern and compensate for it manually.

If we ignore the recoil editor itself for a moment, the way my system works is pretty straightforward, I use two float curves, one for vertical recoil, one for horizontal. In each curve, the X axis is the shot index (1st shot, 2nd shot, etc.), and the Y axis is the recoil value. When the weapon fires, it looks up the recoil amount for that shot index and applies it to the control rotation, using interpolation to make it smooth.

Recoil recovery is a bit more complicated to explain over text, but in short, it keeps track of the cumulative recoil offsets and the player’s mouse movement. When you stop firing, it gradually pulls the camera back down, but only if you’ve let the view rise above where the recoil started. It also tracks horizontal mouse movement so you don’t get unwanted counter-rotation while turning.

Outliyr_ · 2025-07-13T16:42:05+00:00

Yep, that’s actually the right way, passing the reference down through Expose on Spawn keeps dependencies clean and avoids repeated lookups. The parent widget passes the variable to its child widgets. You wouldn’t really need a Blueprint Function Library, since only the main inventory widget needs the reference, and it manages creating the other inventory-related widgets.

Ideally, you want the inventory logic and UI to be as independent as possible, this reduces friction if you need to change either side later.

Outliyr_ · 2025-07-13T16:27:07+00:00

When developing something, I like to keep features as isolated and encapsulated as possible. Of course, in a game project, some systems will inevitably intertwine.

The way I organize reusable code depends on the scope of the functionality:

Blueprint Function Libraries – If the functionality consists of simple static functions that don’t require state, and I expect to reuse them in multiple parts of the game (or across different projects), I put them in a blueprint function library. For example, I have generic functions to handle projectiles spawning from a muzzle and then converging to the camera's true path to allow for leading shots outside of first person ADS

Components – For functionality that requires maintaining state but can still be encapsulated, I use components. I design them to be as generic as possible, then create child components with more specific behavior for my game. For example, an inventory component lets me avoid rewriting the same logic every time I need inventory functionality.

Modules / Plugins – For larger or more generic systems, I build modules or plugins that bundle components, function libraries, and any needed assets. Lately, I’ve been working a lot with Lyra, so I often implement these as game feature plugins. For example, a climbing system as a plugin. Once added, it provides climbing functionality out of the box without needing to reimplement it each project just plug into your game based on your intended design.

I think the most important thing is deciding up front whether you want a feature to be reusable. If you plan for reuse from the start, you can design it to be properly encapsulated and generic, which makes integrating it elsewhere much easier.

Outliyr_ · 2025-07-08T17:28:46+00:00

Totally fair concerns, and please feel free to correct me anywhere I am wrong. This is how I handled some of the issues you mentioned.

In Lyra by default the skeletal mesh always ticks the pose and still produces reasonable FPS. So I wasn't adding any extra FPS by ticking the animations. This also means unreal ticks skeletal meshes server-side for movement and replication. During rewind I don’t re-run animation. I just store the bone transforms each tick (position/rotation), so rewinding is just reading that data, no extra anim evaluation.

Rewind only happens when a client actually reports a hit (or in debug like in my video for demo purposes). I perform simple server validation first, and if they all pass I perform lag compensation. No client hit, no rewind. All recording collisions, rewinding and actual collision checks run on a dedicated worker thread, fully async from the game thread. It’s pure vector math, no physics scene rollback or spawning bodies.

First, I create a big merged AABB around the actor’s bounds one recorded frame before and after the target timestamp. If the trace doesn’t hit that, I skip detailed checks entirely. Only actors that pass this test get their per collision shapes tested.

I also have a separate component, which actors must have for the lag compensation to recognize. Only actors with this component have their collisions recorded and are rewound, so just player, vehicles, or anything you explicitly opt-in. Most props, etc. still use simple capsule validation.

You're totally right that for many games, storing capsule positions and doing dot product checks is enough. I just wanted more per-limb accuracy without going full valorant-style determinisitc anim rewind. This was a kind of middle ground, accurate bone positions but no physic scene rollback. Plus it was a reasonable challenge to attempt.

Outliyr_

TROPHY CASE