Add conditional camera offset based on cursor - Hristov Rework, Part 1

[SlamBamActionman]

About the PR

This PR focuses on the implementation of cursor-based camera offset for entities, which is intended to be used to simulate a scope for the Hristov. This is part 1 of a two-part Hristov rework; part 2 will focus on bullet behavior, damage and balance tweaks.

When active, the cursor offset feature causes the player camera to be offset by a dynamic amount based on how far away the cursor is from the middle of the game window. This effectively makes it so that you see further in one direction and less in the opposite.

The main system that handles this is EyeCursorOffsetSystem; to activate this, a component CursorOffsetRequiresWieldComponent is also added. Systems are refactored to facilitate these (more under Technical Details).

Why / Balance

The Hristov rework is split up in two parts as they implement different features and it would be fairly overwhelming to do both at once. The two parts are also fairly disconnected from each other codewise, so it's easier to implement.

The cursor offset is set at a max of 3 tiles, which makes the Hristov a much more valuable weapon as a sniper since it now allows ranged shots from outside a normal player's view. The tradeoff of not being able to see as much behind you is relatively minor (more downsides will be introduced in Part 2) but keeps the gun from just being "zoom out" functionality.

The gun requires wielding for the offset to be applied, which is suitable since one-handing it would allow the added range to be used by other one-handed guns.

Technical details

The offset is calculated to be set between 0 and a max distance based on the mouse cursor's position around the player. This is based on a circle radius from the middle of the screen which reaches out to 90% of either the width or height of the game window, whichever is lowest (which is going to be the height most of the time). If the distance between the point the offset currently to where the mouse cursor has moved is greater than a set value, the movement is capped to prevent instant snapping which didn't feel great.

The camera offset behavior has been mildly refactored; it's now run in a central update loop instead of being spread out across multiple systems(SharedCameraRecoilSystem) and risking triggering multiple times in one frame.

WieldableSystem in Shared has been turned into SharedWieldableSystem. This is to allow the Client system to interact with EyeCursorOffsetSystem, which must be in Client due to using mouse cursor input.

Media

2024-08-29.21-01-27.mp4

Requirements

• I have read and I am following the Pull Request Guidelines. I understand that not doing so may get my pr closed at maintainer’s discretion
• I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

🆑

• tweak: Hristov now provides an increased view range of 3 tiles when wielded.

[Hanzdegloker]

It would be so nice to look 4 or so tiles farther in any direction in exchange for being way easier to sneak up behind. Make gunfights allot more dynamic in general. In a vein similiar to what is shown here.

[SlamBamActionman]

It would be so nice to look 4 or so tiles farther in any direction in exchange for being way easier to sneak up behind. Make gunfights allot more dynamic in general. In a vein similiar to what is shown here.

There's a soft limit involving the PVS range that makes it so you can't extend the offset too much. 3 is a decent number for general balance but it also keeps you from seeing pop-in

[slarticodefast]

Looks really cool. We also need binoculars as an item now. Any way to make it so that it is not bound to being wielded?

[Hanzdegloker]

It would be so nice to look 4 or so tiles farther in any direction in exchange for being way easier to sneak up behind. Make gunfights allot more dynamic in general. In a vein similiar to what is shown here.

There's a soft limit involving the PVS range that makes it so you can't extend the offset too much. 3 is a decent number for general balance but it also keeps you from seeing pop-in

Sounds about right, still any extra sight makes gun battles less shooting at the edge of your screen

[SlamBamActionman]

Looks really cool. We also need binoculars as an item now. Any way to make it so that it is not bound to being wielded?

Yes - you need a system that hooks up for when it should activate/deactivate, but the event for checking it has the boilerplate for both the hands system and the equip system. I haven't tried it but theoretically the effect is additative, so should be able to use two binoculars and get the effect of both!

[Everturning]

Looks really cool. We also need binoculars as an item now. Any way to make it so that it is not bound to being wielded?

Yes - you need a system that hooks up for when it should activate/deactivate, but the event for checking it has the boilerplate for both the hands system and the equip system. I haven't tried it but theoretically the effect is additative, so should be able to use two binoculars and get the effect of both!

but that is also - stupid, and dumb. is there any way you'd be able to make the system NOT require that?

[SlamBamActionman]

Yes - you need a system that hooks up for when it should activate/deactivate, but the event for checking it has the boilerplate for both the hands system and the equip system. I haven't tried it but theoretically the effect is additative, so should be able to use two binoculars and get the effect of both!

but that is also - stupid, and dumb. is there any way you'd be able to make the system NOT require that?

I am not sure what you mean? If you want to make the camera offset work for when you hold an item in your hand without wielding, you need to code a component that calls the camera offset code when not wielding. It's not difficult, but since I am not implementing that functionality I don't have a reason to take time to include that in this PR.

[KaiserMaus]

Still progressing?

[SlamBamActionman]

I've made some fairly major changes;
EyeCursorOffsetComponent have been split into a client and server component. This is to help split the functionalities of changing camera offset and camera PVS distance, which it now supports. This helps avoid situations where the offset extends beyond the PVS limit, which would cause pop-in.

[KaiserMaus]

Bulet .60 fly so slow(standard 25) if you zoom on enemy

[KaiserMaus]

I've made some fairly major changes; EyeCursorOffsetComponent have been split into a client and server component. This is to help split the functionalities of changing camera offset and camera PVS distance, which it now supports. This helps avoid situations where the offset extends beyond the PVS limit, which would cause pop-in.

Now i can increase distance "zoom" on rifle?

[SlamBamActionman]

I've made some fairly major changes; EyeCursorOffsetComponent have been split into a client and server component. This is to help split the functionalities of changing camera offset and camera PVS distance, which it now supports. This helps avoid situations where the offset extends beyond the PVS limit, which would cause pop-in.

Now i can increase distance "zoom" on rifle?

Yes, this should be possible now. Previously it was gated by the default PVS, but now that can be increased. Be aware that too much zoom may impact performance due to the amount of entities being loaded!

[KaiserMaus]

I've made some fairly major changes; EyeCursorOffsetComponent have been split into a client and server component. This is to help split the functionalities of changing camera offset and camera PVS distance, which it now supports. This helps avoid situations where the offset extends beyond the PVS limit, which would cause pop-in.

Now i can increase distance "zoom" on rifle?

Yes, this should be possible now. Previously it was gated by the default PVS, but now that can be increased. Be aware that too much zoom may impact performance due to the amount of entities being loaded!

You already finished required changes? Label on pr still "awaiting changes"

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[slarticodefast]

Keep the base calls

[Simyon264]

Ah. Noted. Weird, but makes sense.

Outdated

[KaiserMaus]

Finally!