Jesus4Lyf
Good Idea™
- Reaction score
- 397
It depends on design, y'know...
You can make an Event struct member, create it when you make the projectile, .chainDestroy() it when you destroy the projectile (instead of destroy, but I should fix that up some time) and then .fire() it when it hits a unit. Before calling fire, store any event responses in global variables and write little wrappers (SPS_GetTriggerProjectile(), SPS_GetProjectileX(proj), etc) that read em.
I would personally go with the module thing with defaults, and then just call the methods directly if they exist. More efficiency, and the data is right there for ya.
But this is the system design dilemmar I was speaking of. But I'd definitely do that if I could, it makes lots of sense.
Edit:
>EDIT: your edit confused me
I guess it was supposed to.
But if you remove the ...'s and implement that module in a struct, and call .startPeriodic() on it, you'll see if will spam call .onHit() 32 times a second if it exists in the struct. Think about the potential.
You can make an Event struct member, create it when you make the projectile, .chainDestroy() it when you destroy the projectile (instead of destroy, but I should fix that up some time) and then .fire() it when it hits a unit. Before calling fire, store any event responses in global variables and write little wrappers (SPS_GetTriggerProjectile(), SPS_GetProjectileX(proj), etc) that read em.
I would personally go with the module thing with defaults, and then just call the methods directly if they exist. More efficiency, and the data is right there for ya.
But this is the system design dilemmar I was speaking of. But I'd definitely do that if I could, it makes lots of sense.
Edit:
>EDIT: your edit confused me
I guess it was supposed to.
But if you remove the ...'s and implement that module in a struct, and call .startPeriodic() on it, you'll see if will spam call .onHit() 32 times a second if it exists in the struct. Think about the potential.