Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Double Muzzle Flash #33981

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

sleepyyapril
Copy link
Contributor

About the PR

Fixes the double muzzle flash from guns shooting by providing the user to all effect functions.

Why / Balance

The gun is meant to give off one muzzle flash per bullet, not two.

Technical details

Added a User field to the MuzzleFlashEvent to properly send the user to the CreateEffect method.

Media

Before
After

Requirements

Breaking changes

Changelog

🆑

  • fix: Fixed double muzzle flash for the user.

@github-actions github-actions bot added size/S Denotes a PR that changes 10-99 lines. S: Untriaged Status: Indicates an item has not been triaged and doesn't have appropriate labels. S: Needs Review Status: Requires additional reviews before being fully accepted labels Dec 21, 2024
@TheShuEd
Copy link
Member

We have guns that can fire without the user (shuttle big guns for example), have you checked how it works with them? If possible can you attach media with them?

@sleepyyapril
Copy link
Contributor Author

We have guns that can fire without the user (shuttle big guns for example), have you checked how it works with them? If possible can you attach media with them?

While it seemingly worked fine, I'm going to err on the side of safety and make it use the gun uid when user is null.

@metalgearsloth
Copy link
Contributor

Do we really need to network the user? It should be getting filtered before getting sent to the client and not after.

@sleepyyapril
Copy link
Contributor Author

sleepyyapril commented Dec 21, 2024

Do we really need to network the user? It should be getting filtered before getting sent to the client and not after.

You don't technically need to, no, considering that filtering does happen server-side, but I wanted to be careful because client-side CreateEffect does contain a "TrackUserComponent" portion where, if a user is supplied, it's put in there. I have no knowledge of what that is used for, so if it's nothing I can just remove the networking part entirely.

@beck-thompson beck-thompson added T: Bugfix Type: Bugs and/or bugfixes P2: Raised Priority: Item has a raised priority, indicating it might get increased maintainer attention. D2: Medium Difficulty: A good amount of codebase knowledge required. A: General Interactions Area: General in-game interactions that don't relate to another area. and removed S: Untriaged Status: Indicates an item has not been triaged and doesn't have appropriate labels. labels Dec 22, 2024
Copy link
Contributor

@beck-thompson beck-thompson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a nasty one... Good job on finding this! I did a little more digging and I think you could simplify this logic. I'm going to do a quick explanation here:

The reason the event is getting triggered twice is because the client is running the event itself, and then its getting sent an event from the server to run it again.

CreateEffect is an overloaded function whose fields are actually different depending if your server or client. On client, the third field tells you the location of the muzzle flash, on server, the third field is the user sending the event (It wont the message to the user as they already ran the command).

This means, whenever the client runs we want the third field to be the gun, and on server we want it to be the user who shot it (Or null if its emplaced).

Your code works here because:

Shooting static emplaced gun has no user, so the location is the gun which works on client. The "user" in server is the gun which is also fine because the gun isn't an actor so it just ignores it.

A user shooting the gun, it also works because on client the location is the user which is is fine (The user and gun are in the same location).
On server, the person not to send a message to is the user which is correct.

It is also probably a good idea to comment the CreateEffect functions in client, server, and shared, to explain the differences!

Also, there is another (I'm pretty sure unrelated) bug:
image

To reproduce: drag a cannon in space and then fire it, while moving (If you stand still its fine)

Content.Client/Weapons/Ranged/Systems/GunSystem.cs Outdated Show resolved Hide resolved
Content.Shared/Weapons/Ranged/Events/MuzzleFlashEvent.cs Outdated Show resolved Hide resolved
Content.Shared/Weapons/Ranged/Systems/SharedGunSystem.cs Outdated Show resolved Hide resolved
@github-actions github-actions bot added size/XS Denotes a PR that changes 0-9 lines. and removed size/S Denotes a PR that changes 10-99 lines. labels Jan 19, 2025
Copy link
Contributor

@beck-thompson beck-thompson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Tested and everything seems to work. I'll add the comments in another PR (We talked on discord) 🫡

@beck-thompson beck-thompson added the S: Approved Status: Reviewed and approved by at least one maintainer; a PR may require another approval. label Jan 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A: General Interactions Area: General in-game interactions that don't relate to another area. D2: Medium Difficulty: A good amount of codebase knowledge required. P2: Raised Priority: Item has a raised priority, indicating it might get increased maintainer attention. S: Approved Status: Reviewed and approved by at least one maintainer; a PR may require another approval. S: Needs Review Status: Requires additional reviews before being fully accepted size/XS Denotes a PR that changes 0-9 lines. T: Bugfix Type: Bugs and/or bugfixes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants