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.
How familiar works is that whenever a status (e.g. a buff that gives +1/+1) is given to an adjacent follower, a hidden status on the said follower will then transfer a copy of that status to familiar. However, the status being transfered can't remember what's going on before the transfer. Therefore, if we let a status being able to be transfered multiple time, it'll result in an infinite loop of 2 familiars transferring to same status to each other (since the status can't remember that the prior incarnation of itself has already being transfered to one of the familiar). So we just make it so that a transfered status can't be transfered again.
These raven interactions are all intended. How it works is that everything that happened simultaneously are considered the same effect. Therefore initiate + emissary will only proc raven once, while Initiate + obelisk will proc raven twice. Huntress and lightkeeper follows the same rule. I made it this way so that trigger effects will be easier to balance and for player to predict, but I guess if this rule turns out to be unintuitive for too many people, the alternative will be to have them based on numeric value (like deal 2 random damage for each point of faith gained)
I agree with the comments on endless mode. My intention is not to just brick some builds completely, but rather that player will need to identify and mitigate the weakness of their build rather than keep using the same strategy. It is probably a good idea to have some endless mode exclusive mobs with weaker version of those hunt mechanics.
Hmmm. I feel like that is probably too complicated as a single trait since it'll need to have a cap. There's probably some design space for summon on friendly death tho...
Yes. Unfortunately dragoon's trait don't work with fracturing due to how traits are coded. Essentially, dragoon will change their intrinsic trait into the first aspect their given, so their original intrinsic trait can't be an additional trait itself.
yes. Unfortunately the original sculptor is just too op and require too little investment. Now sculptor'll always summon 1 sculpture but it'll have more stats with more support; and we added beekeeper for the mass summon archetype.
Appreciate the report! That's a lot of things going wrong and I have no idea why any of them are happening...but also I'm kinda surprised the game didn't just explode at that depth.
Noted; appreciated the reported. Yeah there is possibly a bug related to having too many followers created and destroyed throughout a run, but I have yet to identify it...
Really solid feedback. I'm always very conflicted about reroll, but I think I have found a good way to implement it; and there are also other ways for player to influence their recruit pool in the work.
Supplicant is indeed sort of imbalanced. It theoretically should have 1 less health, but that will make the player lose the second combat if they recruit supplicant and put it at the front (which is the intuitive way to position it). That's the only reason I didn't nerf supplicant, and I've yet to come up a good solution for it.
Oh wow. I looked into my code and found out that after 20 turns of no one dying the game will force player to lose to avoid infinite loop. I must have coded it years ago when this feature made sense, and just forgot about it because it never triggered. Sorry about that...
Appreciate the report, I believe that it's indeed a bug and I'll definitely investigate and fix it.
I was just saying that this bug happens probably because when bees are being summoned, adjudicator has already (secretly) started their turn, at which point the bees are not registered in the follower list yet and their "aggro" value still extremely low. So, when adjudicator is choosing their target, they thought the bees are the back-most followers based on their aggro value, even though the bees are actually in the front. Probably all because I forgot to add a delay on beekeeper's death to stop adjudicator acting to early or something like that.
Oh wow. Failsafe is when the game can't generate enemies that meet all the requirements. I never tested it this far down because I thought it's impossible...
Yes. Found out that if you summoned too many followers at the same time, some of them will be skipped over and not registered into the followers list. Tomorrow's update will fix it!
Is everyone attacking simultaneously in your game? If so, that's not the intended behavior. Can you try if the build in this link https://zittacheng.itch.io/uploadtext (password: REDACTED) fix the problem for you?
That build (both web and PC version) should theoretically fix the problem, but I can't be sure because I can't find a PC with the correct culture setting to test it...If you have the time, can you check real quick whether the build works for you? You've been a great help, thanks for still sticking with this game!
Hey! Sorry to bother, but just a quick question: In your game, is there any delay between followers and enemies' attacks? Or are they just sort of attacking simultaneously?
Are you playing the download version? If so, can you send me the logs at C:\Users\username\AppData\LocalLow\DefaultCompany\HolderOfPlace\Player.log right after the death effect failed to trigger? Someone else reported this bug earlier but I think it has something to do with PC settings. It'll be super helpful if I can take a look at your logs!!
