Firearms system rewrite

[MindVisceral]

The weapons system requires a small rewrite to be as reliable, modular, and easy to use as possible moving forward. This won't neccessairly be much of a rework, as the system only consists of bare essentails at the moment, sporting a singular Hitscan weapon.

But this will take work, especially considering that it will require animations. This will probably necessitate first person arms Inverse Kinematics for more ease of use. I would prefer that to importing animations made in Blender and it would, potentially, allow for better in-world interactions. See: Scorn and its puzzle interactions. That might be more work than I can handle though...

This system will rely on classes. There will be the Base Firearms class which all the other classes will inherit. For example, here's how inheritance would work for a theoretical laser pistol: FirearmsBase -> FirearmsHitscan / FirearmsProjectile / [...] -> Pistols / Shotguns / Rifles / [...] -> Laser Pistol / Lead Pistol / [...]

[MindVisceral]

Added two firing_modes to the FirearmBase class - Single-shot (for pistols, rifles, shotguns, etc.) and Automatic (for Automatic weapons). This distinction was made to allow the Player to hold down the primary_action button when they wield an Automatic weapon.

Also added a shot_cooldown variable, which limits the weapon's firing speed.

[MindVisceral]

Added a bullet hole decal. It rotates depending on the surface normal of the bullet. Very basic stuff.

[MindVisceral]

Added a Shot Effect When the primary fire button is pressed, a Node with a Particles child is instantiated, which simulates smoke coming out of the barrel of a gun.

[MindVisceral]

Added a 'fire' shot effect, but this one is a Sprite3D instead of a Particles Node

[MindVisceral]

Added shooting sounds. This is just an AudioStreamPlayer3D with an AudioStreamRandomizer. Besides playing a random shooting sound out of the ones that are attached, it allows for random pitch shifting too.

[MindVisceral]

The LMB-21 shotgun model has been added, which necessitates adding: an option for more bullets per shot in a gun, bullet spread, and maybe even variable damage per bullet.

[MindVisceral]

Added Shotgun functionality after a short hiatus.

Now the code which casts Bullets (just Rays for now) is ran however high the 'number_of_bullets' variable is. Just a simple 'for' loop. Surprising effective. I though there would be a huge performance issue, but the game runs fine with even 30 separate rays fired, and all those effects like Trails and a Shot Effect added. There's a big FPS hitch with more than 30 rays, but that is almost certainly due to all those particles - that's 450 unoptimized particles at just 30 rays fired, and they're all instantiated at the exact same frame. No wonder there's lag. I think I could put up a particles limit around here?

So that was just making more than 1 bullets work. For the shotgun at least, these bullets also must have some spread added to them. This one was simple; the end_pos Vector3 has a random value between 0 and bullet_spread added per each X, Y, and Z component. The problem with this is that this makes the bullet_spread variable work in Godot units (that's either meters or pixels here?) instead of degrees. Quite unintuitive. No easy way around it, I think? We're firing space_state RayCasts here, not regular Node RayCasts, and as such they cannot just be rotated. This must be some Basis or Translate shenanigans. Unless the engine thinks bullet_spread is written in radians? That would explain these weird values. Probably not, though. And I have yet to check if randomizing the 'rotation' on Z axis has any effect. I don't think it should. Needs a few minutes of testing.

NOTE: The shotgun doesn't have a separate Script made for it yet, like the Pistol has. I'm not sure if weapon-specific scripts will even be needed if this system continues to work on Inspector-only basis. It may be that each weapon only requires some variable changes in the Editor. That would be great to work with in the future. But it may be that some weapons will require unique animations, which will necessitate adding unique scripts. We'll see when we get there.

[MindVisceral]

Update on that last comment;

According to the Visual Profiler in the Debugger tab, that inital lag spike when shooting too many Rays mostly comes from the "Setup 3D Scene" calls. So this is an issue with instantiating too many Scenes at once, probably all those Partcle Nodes since they're the most numerous. But the falling particles themselves seem to perform just fine.

I have no solution for that spread degrees issue yet, so I just increased the maximum bullet_spread value to 2000. This is approximately full 90° from the center of bullet_start_point Node.

Another issue; you can increase bullet spread, but if the number of bullets remains the same, the bullets will be very spread apart. Nothing development-ruining, but it might be worth adding a variable that controls Bullet density. Not sure how to do that, but it would make tweaking these values a little easier.

Weird thing, setting spread on one of the axes to 0 makes the Bullets shot in a straight line when faced along other axes. This bug forces me to always randomize spread on all axes because it breaks otherwise. This shouldn't be happening - the Bullets must be relative to the Player, not the World. I made a new Issue for this (#44)

[MindVisceral]

Another issue; you can increase bullet spread, but if the number of bullets remains the same, the bullets will be very spread apart. Nothing development-ruining, but it might be worth adding a variable that controls Bullet density. Not sure how to do that, but it would make tweaking these values a little easier.

And another issue: spread is dependant on max_distance - smaller distance, bigger spread. This wouldn't be happening if just rotating the Ray by a few degrees worked. Related to #44

[MindVisceral]

The LMB-21 shotgun model has been added, which necessitates adding: an option for more bullets per shot in a gun, bullet spread, and maybe even variable damage per bullet.

Done as of #44. I'm not sure on that variable damage idea, so I'll leave it be for now. It should be very easy to implement, because we're already doing some calculations for each Bullet separately.