feat!: Add overloads for AddItem using AttachmentName

[Unbistrackted]

Description

Describe the changes

Added check inside of Firearm::AddAttachment to prevent missmatches

Added overload methods for Player when giving weapon with attachments using AttachmentName

Fixed AttachmentIdentifier.TryParse giving wrong attachment by creating another overload that takes the weapon type

What is the current behavior? (You can also link to an open issue here)
AttachmentIdentifier.TryParse gives wrong AttachmentIdentifier for certain weapons due to them having the same attachment name with different codes

What is the new behavior? (if this is a feature change)

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:
Moved some of the methods to be closer to each other so it's easy to find

Props to @PUDGE133 for finding the bug

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentations

Submission checklist

• I have checked the project can be compiled
• I have tested my changes and it worked as expected

Patches (if there are any changes related to Harmony patches)

• I have checked no IL patching errors in the console

Other

• Still requires more testing

[Someone-193]

PR generally looks good, I just have a few nitpicks here and there. Just to confirm, you haven't removed or significantly changed any important methods right? Just making sure for Exiled 10 I don't get pinged with people being mad they cant find a method that used to exist lol

[Unbistrackted]

PR generally looks good, I just have a few nitpicks here and there. Just to confirm, you haven't removed or significantly changed any important methods right? Just making sure for Exiled 10 I don't get pinged with people being mad they cant find a method that used to exist lol

The only thing I can see ppl being upset is the Firearm::AddAttachment checking for AttachmentIdentifier code's missmatches using the AttachmentName, since if you manually created the AttachmentIdentifier (which is bad) with a hard coded attachment code but didn't care abt AttachmentName, it will only take into consideration the AttachmentName to get the right one

I mean AttachmentName should be the correct way of getting a specific attachment, but ppl do whatever they want with their code so idk

[Unbistrackted]

Also do you know if a method for getting the AttachmentIdentifier via the attachment's code exists? Didn't find it but I'm legally blind lmao. If it doesn't exists, might be useful for those ppl that I talked abt

[Someone-193]

Seems legit

[PUDGE133]

As I understand it, this pull request turned out to be quite complex if you're still making changes. When you made your solution, I immediately pointed out that it still had issues, but you didn't believe me, pointing out my supposed incompetence.

[Unbistrackted]

As I understand it, this pull request turned out to be quite complex if you're still making changes. When you made your solution, I immediately pointed out that it still had issues, but you didn't believe me, pointing out my supposed incompetence.

no it's not complex, and I don't think we are doing any more change + Yes the bug is fixed, as I said in some early comments, you should not create attachments by their id, which is exactly what you are doing instead of using the attachment name

I'm not quite sure what's your issue, but the pr isn't merged yet cause Exiled 10 will take while, so there's literally no rush

pointing out my supposed incompetence. I only said that if you don't know how to code or how things work, just report the bug

[Unbistrackted]

Just create a class that has the FirearmType and a list of AttachmentName, and parse based on that

You don't need the entire AttachmentIdentifier to add it to the firearm

[Unbistrackted]

Also forgot to say, AttachmentIdentifier wasn't "parsing" before cause, as I said, the collection that has them is populated some time after the plugins load

Next time, instead of feeling offended, pay more attention to what I actually had to say