Tldr: I appreciate your input and ideas. I believe I have studied and thought enough about this to know that using a “hit registration list” is the right way to go. The question was more how can I optimize this technically since “list” is not a native value type associated to active objects in CF2.5.
Let me describe a little bit how the system work. I apologize in advance if this is messy, I’m not sure to be able to properly explain things.
* For the purpose of explanation, let's forget for a moment that Player and Enemies are separated objects. The idea behind this engine is that it is as generic as possible to ensure that potentially any instance in the game could generate a “hitbox” and have a “hurtbox” attached to it, which implies that hit registration must be generic and cover many different cases. It is heavily influenced by how 2d fighters work with what is commonly called "frame data".
* Let’s call a “hurtbox” a zone in space attached to a given object which is used to know if that object was hit by an incoming attack. There is only one “hurtbox” active, and it’s linked to possibly any object using the Fixed Value as an identifier.
* Let’s call a “hitbox” a zone in space emitted by a given object (usually physically bound to it) which is used to store attack properties of the emitter (x/y translation upon impact / hit animation to trigger / damage amount / hit stun amount / elemental property, ...) . I do not want to determine in advance how many attacks there will be and how they work. These properties are stored in a config file and grouped under a specific hitbox ID. One given hitbox could be “single hit” or “multi hit”. This determines whether it can hit multiple times during its “active frame” time or only once. Of course, when I say “once” or “multiple”, I’m referring to hit registration on one specific “hurtbox” (or hittable object, if you will).
“hitbox” and “hurtbox” are visually rendered in my project exactly in the same way they are in Street Fighter 3, for example. Just colored square active objects, which are invisible (they work as collision mask).
* Let's call "Attacker" any object that can generate a "hitbox". It could be the main character, an enemy, a projectile (a bullet, a fire ball, an explosion ...), an environmental hazard (flames, thunder, etc). The Attacker has one or several attack animations. These animations have the usual "startup frames" (before the attack can do anything), the "active frames" (the time during which the attack can hit) and "recovery frames". Attackers could be players, enemies, environment, anything.
* During the first frame of the attacker’s "active frames", the hitbox active object is created and an ID is dynamically assigned to it (based on animation properties). The hitbox remains until the last “active frame”, then it is destroyed.
* During this time, if a “hitbox” collides with any “hurtbox”, it checks whether hit can be registered and if so, it impacts the owner of the corresponding hurtbox (x/y position, life, etc).
* To avoid a “hitbox” registering collision on the “hurtbox” of the attacker, I’m using the Fixed value of the attacker as the “owner_id”. Simply put, it the owner_id of the hitbox is the same as the owner_id of the hurtbox, hit will NOT register.
* Upon collision, the “hitbox” could still be active for some time but the hurtbox touched should not register collision from this specific hitbox (but could be touched by another one overlapping right after). In this regard, the “invincibility flag” is not a suitable solution because there could be different hitboxes (from different attackers) hitting the same hurtbox in a small time frame and I want to ensure all hit register.
As to storing the “last_hitbox_id” on the hurtbox upon collision, this could work in most cases, but it would not work for “multi hit” hitboxes as the first collision registration would cause the following ones to be ignored.
EDIT : after re-reading the solution suggested by GamesterX23, i think i'll try this as it can probably handle 95% of the cases if not more. I'm looking to do something that work 100% of the time but it's probably just an overkill...
The solution I have in mind (and I’m pretty sure is the only one which covers 100% of the cases in my current system) is to store on the “hitbox” the Fixed Values of the hurtbox it collided with within a list, and check upon collision between hit box and hurt box that the Fixed value of the hurt box is not yet in the “hit registration list “ of the hit box it collided with. This forces me to do look ups in the list since I have to use a string and parse it (which is definitely not a fast operation for the processor). For the case of “multi hit” hitboxes, I can simply clear the list whenever this hit box can hit anything again.
I hope the above makes it clearer and that you now understand what I want to achieve and how I’m planning on doing it.
It would be complex for me to submit a mfa example of this collision registration engine as it is currently very intricate and there are lots of cross references to other objects within it. Eventually, this is something I’d like to share with the community !
Cheers