itch.io

Yes, except that that's not how status works in this game at all. To get into more details, almost all interactions in the game is done through "signals", and each follower will have a bunch of "status" to interact with those signals. Each signal is consisting of a signal type, whatever object reference required from that signal type, and a bunch of float variable. for example, a signal can be something like "deal 3 damage" or "gain +1/+1"; "deal 3 damage" signal will have the signal type of "damage" with variable "damage = 3"; "gain +1/+1" signal will have the signal type of "create status", with a reference to a generic stat status, and variable "AddDamage = 1; AddLife = 1". Each status can be more complicated; some status will passively modify a follower's stats or have interaction with specific signals, like the status "this follower will gain double stats"; How signal and status works in action is: when a follower receive the "gain +1/+1" signal, the signal will inform all status on that follower of the signal's existence, and if the follower has the "this follower will gain double stats" status, the status will then modify the "AddDamage = 1; AddLife = 1" variables of the signal to "AddDamage = 2; AddLife = 2"; after that, the signal will execute its proper function to add a new generic stat status to the follower, and modify the new status base on the AddDamage and AddLife variables; maybe the follower also have a status that says "deal 3 random damage on stats gain" status, in which case, when the status is aware of the "gain +1/+1" signal, it will send another signal "deal 3 random damage" to the same follower, which will then go through this entire process again.

How familiar works is that it'll create a special "adjacent stat status link" status to all followers before the start of combat. This adjacent stat status link is a status that, whenever the source follower receives a "create status" signal, the status will check whether the "create status" signal is creating a stat status, whether the "create status" signal can be interacted by status (whether it has "IgnoreTrigger = 1"), whether the source follower is adjacent to the follower that created the status link (the caster, which, in this case, should be a familiar), and whether the caster is alive. If all conditions are met, the status link will then force another copy of the status are to be created by "create status" signal to the caster. And here's the problem. If the status link then create a new "create status" signal and send it to the caster, then that new signal will also go through the same process. That means that if 2 familiars each have created a status link on each other, then familiar 1 will gain a stat status and send "create status" signal to familiar 2, which will go through the same process and end up sending a copy of the same "create status" signal to familiar 1. To avoid this, the "create status" signal sent from familiar 1 to familiar 2 will need to include the information that "this signal is created by a status link from familiar 1, and therefore should not trigger any other status link that are created by familiar 1", which is really troublesome to implement because signals are coded to only carry float variables and not extra reference to objects. What we end up doing is to just mark the new create status signal with "IgnoreTrigger", making it unable to interact with other status link status.

I guess this is just a really complicated way to say that yes, such a propagation iteration does make sense in a vacuum, but it doesn't really work with the process of how all signals and status are processed in this game. To make familiar being able to trigger other familiar, we'll need to change how signal or status are coded, which is just a bit over-scoped at the moment.