Fixed bola effect stacking

[impubbi]

About the PR

Bolas had a bug that allowed them to stack and apply to the same target (#34694)
I changed the shared ensnareable system to only allow one bola to be applied as mentioned in (#34694)

Fixes #34694

Why / Balance

Removes the ability to movelock and makes it less annoying to remove many bolas.

Technical details

Changed the checks in the SharedEnsnareableSystem's TryEnsnare method to only ensnare if they aren't already ensnared. (Try saying that 3 times fast lol)

Media

Requirements

• [X ] I have read and am following the Pull Request and Changelog Guidelines.
• [ X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog
🆑

• fix: Bolas will now only be applied once.

[lzk228]

you can link your pr to the issue so it could be autoclosed along with pr merging
https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue

[impubbi]

Thanks for the info!

[slarticodefast]

Now that I look a the code in more detail it does not seem to be a bug to be able to get ensnared more than once, and more like a design choice. Before it was limited to one bola for each leg (which will become more relevant once we have surgery). According to the linked issue it was possible to get ensnared 5 or 6 times, so this check is failing somewhere

[impubbi]

Thanks for the input!
It's now limited to the number of legs the target has as originally intended
This implementation had some weird network problems though:

So I also made the sprint and walk speeds AutoNetworkedFields in the ensnareable component:

Results:

[K-Dynamic]

Huge success

I still think the cumulative speed reduction from multiple bolas needs to be looked into at some point, but that's out of scope of this PR

Also bolas need to work on mobs like dogs or spiders but that's also out of scope

[keronshb]

Now that I look a the code in more detail it does not seem to be a bug to be able to get ensnared more than once, and more like a design choice. Before it was limited to one bola for each leg (which will become more relevant once we have surgery). According to the linked issue it was possible to get ensnared 5 or 6 times, so this check is failing somewhere

No, it should be a singular bola.

It doesnt matter if they have 2 legs or 1, the singular bola counts. It was never intended to be 1 bola per leg.

[keronshb]

It was always intended to be 1 bola per person. It's never meant to be 1 bola per leg, that's too overpowered.

[impubbi]

If it's still in scope for this PR, I can make the maximum number of ensnares a property in the ensnare component and let another PR handle the balance side of things. I'm not sure if the ensnare system will be used for something else.

[impubbi]

Thinking on it now, if another system wanted to use the ensnare component, it might get messy if the number of times an ensnare can be applied is hard-coded

[keronshb]

If it's still in scope for this PR, I can make the maximum number of ensnares a property in the ensnare component and let another PR handle the balance side of things. I'm not sure if the ensnare system will be used for something else.

It's not exclusive to bolas but I had designed it to be 1 ensnare at a time.

If you want to make a config in the ECS to allow multiple I think that's fine, but by default it should just be 1 per person.

[slarticodefast]

It's fine to change it to 1 bola per person, but this should be labeled as a balance change and not a bugfix then.

[keronshb]

It's fine to change it to 1 bola per person, but this should be labeled as a balance change and not a bugfix then.

Arguably it's a bugfix because it was never intended to work like that in the first place.
I feel it's a little minutia to discuss it any further and we can leave it as a balance change, but as the person who ported this from 13 it was never ever intended to have more than 1 at once.

[impubbi]

Should be working now

Addressed