Then you have an issue with the way you handle input itself as well. I am not even talking about enhanced input here. The most basic key down works for the above, and that’s without utilising Released:
Try it out with the suggested script.
Also, Timer works great if you need things to work really fast and be frame independent. As in consistently fire multiple shots in a single frame. The distribution over a single frame is somewhat weird but can be ignored in 99% of cases.
Not trying to convince anyone this is the best method evah. That’s the best method I know, because someone else did a lot of trial and even more errors, and settled for it. Worked for me, too.
I see what you mean about children not needing to know about the logic of their siblings, and I currently only plan to have the three firing modes listed in the first post for eight guns (Pistol, SMG, DMR, Assault Rifle, Shotgun, LMG, Sniper Rifle and Railgun). The enumerator was just all I could think of with my limited experience.
If that’s the scope and the guns cannot be modified drastically run-time, then I’d have a fire function in the parent and override in the child.
When it comes to actor components, folks do not give them nowhere near enough credit. Think of them as of chunks of functionality you add to or remove from actors, during run-time, too. An actor does not need to know upfront what it’s capable of doing later on. They support inheritance:
An actor can have many comps, each with a graph, variables and functions (not timelines, though):
You can even overrride a Static Mesh Component which are highly specialised Actor Component everybody is familiar with. This way each gun part can already handle a mesh, material, animations (skeletal), collision…
Let’s say you have 100 guns and 12 scopes, some guns have it, some don’t, we don’t know, not yet. The player holding a gun actor evokes Press X to Use Scope via an Interface:
- base gun class actor - do we even have a scope:
If this particular child has a scope, we use the scope’s functionality. If you now spawn 100 guns, only the 25 that have one of the 12 scopes will have the functionality.
If I have a grenade_class_gun, I will not even bother overriding UseScope, because the component that could perform the action make no sense for a grenade. But the grenade could have a component that deals splash damage a pistol would never care about. Your base gun actor should never care about what splash damage is.
What you end up with is a much lighter base gun class that has no idea what is going on, a child actor that knows a little bit more and functionality that is compartmentalised, encapsulated in a component and evoked only when needed.
Another good example is fantasy-like setup where the player can learn 600 spells. You do not want to spawn the player with 600 spells. You add spell component as the player learns them. You definitely do not want an enumerator with 600 entries.
The above is somewhat crude and still incomplete because you need the comps to talk back to the owning actors - another interface or dispatchers work great here.
Essentially, if you ever need to build a huge freaking robot, where limbs have sockets for multiple weapons and each one is different and moddable, actor components are an outlet for that.
