Add Trap link

[mattman107]

Based on #21

Some things I want to look into:

1. I don't like the notification currently
2. Should I call the trap effects directly instead of collecting an ice trap?
3. I don't think this needs to be time-gated as receiving a trap link doesn't send another trap link.

Build Artifacts

• soh-mac.zip
• soh-linux.zip
• soh-windows.zip

[mattman107]

I updated the notification to look a little bit better. I think having the notification is helpful to let the player know this is a trap link.

I also had to update how the trap link was sent and received. I don't think the timing method of restricting outbound trap links is viable with queuing up the Ice Trap the way I have it. The player can sit on the Ice Trap text until the timer is up, then send the link when they shouldn't have been able to.

It now uses a bool to determine if the Ice Trap should be trap linked or not. It isn't perfect as if they thread the needle getting multiple trap links at once, they can still send out a link off of a link, but it catches 90% of cases.

To take this further I still think we could directly call the trap effects, but we would have to write our own thing to randomly choose traps they have selected and handle traps that occur over time like speed traps. Using the built in item queue, it also prevents traps from being shot off at inopportune times, like crawling. So it would be a much larger and trickier change to do.

[mattman107]

I think this is the best I know how to get it. This latest change goes back to the time based condition (dialed in to work with ice trap length) as well as directly uses the extra trap status effects instead of collecting an ice trap item.

The timing condition still allows someone to wait in an animation, accumulate received trap links, then send out a whole bunch at a time. I can't think of a better way to limit it. Lmk if you have any better ideas 😓

[mattman107]

I wound up thinking on this and I think this is the current best I can do to distinguish when a trap link should and shouldn't be sent.

How it works is counts up all received trap links, and when we check if a trap link should be sent, if any trap linked traps are still in the queue, wait to send the trap link.

This also comes with the side effect of not sending the trap link until all queued ice traps have been cleared. So when player A has an actual ice trap and an trap linked trap one after the other in that order, the actual ice trap will play out, then the trap linked one, then it will send the trap link for the actual ice trap they collected.