GameGuru needs to have a top-notch weapon system if it is to remain relevant. It already has a really good foundation which is easy to work with and remarkably robust. However, there are some areas which are incomplete, poorly designed or just plain buggy at this time. This post seeks to address those issues and discrepancies. If I were to put a number on it, I would say that this list is probably 70% bugs and 30% feature creep... So, it's being posted here on the Bug Reports board. These are, to me, all real issues which are holding me back from publishing weapon content for GG.
I am posting this here rather than simply forwarding to the devs in hopes that others might see the importance of resolving some of these issues because, as we know, TGC is more keen to address talked about issues than ones that many might not realize even exist. That said, feel free to post more weapon related issues you may find in this thread.
Note: This only covers raycast weapons. Issues relating to flak are not discussed in this writing because I have yet to thoroughly test flak systems.
In most cases I try to list out all state variants of settings but I have likely missed some. If referring to a setting that needs alteration, it should be assumed that this includes all derivative states ie: alt, empty, alt empty.
I have attempted to list in order of importance but a few are known to be out of order.
Now onto business...
Issues:
FIXED! 1. Gunspec readable lines limit too low. Currently reads up to 300 lines. It needs to read up to 400 as a minimum. No more than 500 should be ever needed unless there are significant future changes (such as addition of dual wielding).
FIXED! 2. Key bindings for melee (melee key=x) and fire mode selection (switchtoalt=x) currently defined in gunspec should be moved to setup.ini. (or whatever future equivalent will be) along with the other global bindings.
3. GUN HUD status panel system is far too restrictive. As-is we only have access to a limited, hard-coded set of options. We must be able to use custom icons for weapon and ammo as well as alt mode weapon and alt mode ammo is applicable.
FIXED! 4. Muzzle flash instanced light is positioned behind the weapon (likely at the player world position) causing the weapon to be illuminated from the rear when firing. The light position needs to be forward of the weapon and ideally instanced at the position of the FIRESPOT limb.
FIXED! 5. Muzzlecolor not working. muzzlecolorR=x,muzzlecolorG=x,muzzlecolorB=x,alt muzzlecolorR=x,alt muzzlecolorG=x,alt muzzlecolorB=x settings are not currently working. These settings are meant to change the color of the dynamic light which is instanced when firing.
FIXED! 6. Unable to fix jam when ammo pool is depleted. Need to be able to fix jam as long as ammo remains in the gun.
FIXED! 7. Jamming probability code needs adjustment. Currently, it seems that
overheatafter=x is checked continually (every loop?) as long as the fire button is depressed once the value threshold has been met. It should only check to see if it can jam (die roll against the
jamchance=x value) once per bullet and once per fire button click. Currently, if using a semi-automatic gun (Ex: pistol), you can jam the weapon every time simply by shooting once and keeping the fire button held down until it fails a jamchance roll. Likewise, an automatic fire weapon will almost always jam after the same number of bullets if holding down the trigger. If a machinegun (automatic fire weapon) has the stats of
overheatafter=2,
cooldown=400 and
jamchance=20; it should have a 20% jam chance for each bullet fired after 2 seconds of continual fire unless the trigger is released and the weapon is allowed to cool for 400ms. As soon as the fire button is no longer pressed, the 400ms cooldown timer should begin counting down. If the player clicks again before the 400ms cooldown expires, then the weapon will should check jamchance once for the premature click and then again for each bullet fired thereafter. For semiautomatic weapons (no automatic fire), the system basically performs the same where unless the cooldown time has expired, jamchance is checked once for each click an once for each bullet fired. The difference with non automatic fire weapons is that
overheatafter=x should not be applied and instead should only consider
cooldown=x when rolling against
jamchance. This way, avoiding jamming becomes a strategic skill which only punishes players who spam click faster than the weapon allows or spray-and-pray excessively. This emulates real life in the sense that you can jam with a pistol by manipulating the trigger faster than it can mechanically reset, jam a pump shotgun by "short-stroking", or jam a machinegun by letting it overheat.
*Yes, I realize these types of failures aren't technically "jams" but they are nonetheless operational failures.
FIXED! 8. Dryfire sound not playing when out of ammo or weapon is jammed and player is clicking fire button. The dryfire sound should play *once per click* (please note that if the weapon is automatic firing it should *not* loop the sound) if the weapon is in jammed or empty states. The audio clue helps the player know something is wrong with their gun. Strangely enough, the dryfire will play once per click while running and empty if the weapon uses
disablerunandshoot= 1. Ironically, weapons with sprint shooting disabled should not be able to dryfire.
9. Dryfire sound plays when attempting to reload and no ammo remains in ammo pool. This is just sort of daft. If a sound is to be played to alert the player that a reload is not possible, it should be like a voice that communicates "I'm out of ammo" or something. This audio cue would be tied to the soundset assigned to the player start marker.
10. Cocking animation not playing when it should. On weapons which utilize
cock or
alt cock animations, when aiming down sights (simplezoom) and the weapon runs out of loaded ammo, the weapon does not play the cocking animation before leaving simplezoom. I'm not even sure if it plays the end fire animation before exiting simplezoom. The cocking animation should be allowed to play before being forced out of simple zoom.
11. Need support for empty altto and empty altfrom animations. GG currently uses
altto and
altfrom for both normal and empty states. Lack of support makes for visual inconsistencies on some weapons.
12. zoomaccuracy=x and alt zoomaccuracy=x appear to be non functional in GG (I have tried values up to 200 to check is sensitivity has simply been changed as is the case with accuracy). In Classic, this function caused a breathing effect when using simplezoom or vanilla zoom. For additional depth of gameplay, a "hold breath" mechanic could be employed to temporarily stall the breathing effect while an assigned key is pressed. Such a system would decrease zoomaccuracy value by 75% or more for a short duration while the key is depressed. Maybe around 10 seconds and then the character would breath more heavily (at around 200% base zoomaccuracy value) for a couple of seconds before reverting to the base value at which time the player could reinitialize breath holding by pressing the appropriate key again.
13. Audio playback for automatic fire weapons is glitchy and awful. Currently it will abruptly cut off as soon as the firing stops. The firing sound need to be able to overlap at least one previous shot and must to be allowed to finish playing the last shot sound completely. This conccession was likely made in GG because the uzi has a fire sound which is a string of shots. There is no logical reason for this. Gunshot audio should be singular and their rate of playback either defined by the
fire loop=x setting (as in classic) or ideally tied to the actual firerate. It may be important to note that
fireloop=x in conjunction with
iterate=x was originally for simulating higher rates of fire for weapons in v1 Classic FPSC because back then the actual fire rate was a fixed interval. We now have the functionality to vary rate of fire via
firerate=x and
alt firerate=x.
14. Audio playback of putaway sound is abruptly cut off as soon as the weapon is changed. The sound must be allowed to finish playing. It's perfectly OK for the end of putaway sound to overlap the beginning of retrieve sound of next weapon.
15. Melee attack recoil needs to be decoupled from host fire mode and allowed it's own recoil settings. Ex:
melee recoily=x,
meleerecoilyreturn=x, etc. While it may be desirable and more robust to support separate melee recoil settings for normal, empty, alt and alt empty states, it's not critically necessary. The main point of decoupling melee recoil is for weapons where the recoil camera motion of the weapon firing is not suitable for melee attacks.
FIXED! 16. bullethidemod needs an aditional in-gun ammo check after [b]bullethidereset=x is called.[/b] Currently it only checks if it should be hiding limbs after a shot is fired. This can lead to instances where, for example, you have a machinegun with 13 visible bullets which use the bullethidemod and when reaching the end of the ammo pool a reload is only able to replentish 6 bullets. However, after the bullethidereset frame all 13 will be shown and these will remain visible until you shoot once and then it will update showing the correct amount of 5 visible bullets.
17. bullethidemod needs the ability to specify multiple frame values for bullethidereset. Ex.
bullethidereset=x,y. This is necessecary to facilitate use of both (tactical) reload and empty reload animations. Currently it only accepts a single reset frame value. Bullethidemod is a terrific feature which is hindered from reaching its full potential by this small oversight.
18. Weapons need settings for player movement speed modifiers. Currently, player can run the same speed with revolver or RPG. Not only is this daft, it robs the GG platform of important strategic balancing. Modifiers should be presented as something like
plrmovespeedmod=x (and not of course, alt plrmovespeedmod as well. empty state derivatives should not be needed) where x is a percentile applied to the the speed setting in the player start marker. If no plrmovespeedmod value is specified in gunspec.txt, then it should default to 1 or 100% speed. If
plrmovespeedmod=0.5 then player movement speed is reduced 50% from the marker setting. If
plrmovespeedmod=1.5 then player movement is 150% of the player start marker speed value. Additional pre-existing speed modifications such as
zoomwalkspeed should be calculated from player speed after the
plrmovespeedmod multiplier has been applied. So, if a weapon has
plrmovespeedmod=0.5,
zoomwalkspeed=0.5 and a player marker speed setting of 100 then the player would move at a speed of 25 when aiming down sights with this weapon equipped. Using the same system, turning speed and jumpspeed could also be modified per weapon with
plrturnspeedmod=x and
plrjumpspeedmod=x.
19. There ought to be setting options for melee force=x (plus empty, alt and empty alt ofc) . GG currently supports
force=x and
alt force=x. Melee force should be added for consistency and gameplay depth. From a philosophical point of view, the melee function of a weapon could be used as a low damage/high force attack to effectively shove enemies or dynamic obstacles. Currently, it's mostly usable as an interim attack alternative when out of ammo or as a sort of super attack. Adding support for melee force would increase the usability of this already existing feature.
20. Move and run animation should be suspended when airborne. Looks bad when leaping and the gun is moving as if walking or running. Ideally, support could be added jump, alt jump, empty jump and alt empty jump animations. Such animations would only need to be idle breath poses which the engine blends to when airborne. In weapons where such animation is not included, the engine should default to simply suspending the animation or using the appropriate idle animation.
21. brass=x and alt brass=x should accept alphanumeric values. Currently, they only accept numeric values. As-is, there is risk of 3rd party artists overwriting each other's brass. Currently, this can be somewhat avoided by adding a numeric ownership prefix (example: If I create my own .45 brass I might name it "brass31445" to avoid conflicts. However it would be "easier" and with less potential for conflict if I could name it something like "brass45eai").
22. muzzleflash=x and alt muzzleflash=x should accept alphanumeric values for the same reasons listed above in #21.
23. A better grenade/throwing mechanic is needed (OK, I lied about not talking about flak). We need a system for "cooking" grenades where the grenade isn't thrown as soon as fire button is clicked. This is another example of a strategic opportunity. The system should facilitate holding down the fire button to unpin a grenade (starting it's fuse timer) and hold it in a ready to throw state until fire button is released at which point the grenade is thrown. This will allow the player to effectively shorten the fuse time so that an enemy has less time to react. With good timing, a grenade can be made to "airburst" which is good for reaching enemies behind cover in elevated positions. With bad timing, you can blow yourself up.
24. A reworked blocking/parrying system is needed. This is mostly critical for fantasy and brawler type genres but usable in modern genres as well. The GG implementation of old Airmod
simpleblock code is not currently very broken (you can initiate a block but only once and necessitates rebooting GG to block again). I advise removing the code for it as it was initially designed only for single player use against only enemies and without the presence of allies (as it predated Dark AI integration). It should be reworked from the ground up and possibly be made to emulate the compound blocking feature from the Project Blue Classic Mod which allowed a blocking manoeuvre to be sustained and deflect incoming raycast attacks within a specified angle. The system, designed and coded by Plystire, included support for
blockstart, blockidle and
blockend animations as well as additional animations for block reactions when struck during blockidle. Unlike Airmod's simpleblock system, it was not reliant on complementary blocking check prerequisites in enemy scripts. It simply blocked incoming raycast attacks as one would expect such a feature to work. Ideally, a damage soak value should be added to any blocking mechanic in GG. Basically set a
blockdamage=x amount in gunspec and incoming, blocked damage would be checked against the blockdamage value. Any damage over the value would then be deducted from player health.
25. Empty state transition animation support needed. It would be good to be able to support some kind of transition animation between regular and empty weapon states. At the minimum it should take the form as an
emptyto=startframe,endframe gunspec entry. Ideally, an
empty end fire animation would be added which is played when the last bullet has been fired.
The above issues were compiled over three days and primarily with v1.00.015Gigabyte P67A-UD4-B3, Intel Core i7 2600K, 16GB Corsair DDR3, EVGA GTX 970 SC, Win7 Pro 64-bit SP1, Primary monitor @ 1920x1080, secondary monitor @ 1024x1280
