Many of these settings have some form of simple commented documentation but this should help you understand better what they do:
Mode configures what kind of projectile this will be. 0 is basically 'not a projectile', while 1 and 2 are stated as dynamic (moving/changing) or static (nonmoving/changing).
Cachenumber controls the number of pre-cached projectiles. Over-caching can cause memory issues but does have value (as you will see later). I have cached at most 100 at a time. There are hard limits, however, that cannot be avoided which we will also see later.
object is your model id. The models appear to have a poly mesh scan done for physics as well so your model shape will matter as it doesn't use a simple physics box or capsule. I recommend a low poly model that meets your needs. Good choices can be found in the FPSC Classics folder, if you have that. Many of our examples will rely on those.
Texture D/N/S will control your DNIS textures. Please note, I never successfully achieved getting illumination working on projectiles. Assume it doesn't work until someone else proves me wrong
Scalemin/max (XYZ) controls the percent the projectile can scale when it comes out. This allows for variability in the projectile sizes. The default value is typically 100/100, ensuring it's a consistent size. Configuring it to 50/150 would give every projectile a size based on a random value in the range of 50 through 150.
Avoidplayerpenetration helps configure whether the projectile will start inside the player or not. Sometimes you may need to configure this value to higher unit levels to get it to start in the proper location. For instance, with my plasma thrower, setting it to 30 ensured it was 30 units out from the player. This corrected an issue where shots were emanating BEHIND the player to start.
Attach to weapon limb corresponds to the weapon limb used by the first-player model used.
AccuracyX/Y controls the inaccuracy of the projectile on an X/Y axis, similar to gunspec's configuration setting. While gunspec controls the point of origin for the initial shot, however, this controls the initial LAUNCH direction of the projectile.
Life and range are two very important settings. They control how long a projectile lives when isn't destroyed by other means (such as hitting an enemy or exploding). As far as I can tell, in both cases it ALWAYS explodes when it reaches maximum life or range. I recommend severely reducing the range value and life value. This is because if you are using many projectiles, you want as FEW ACTIVE PROJECTILES AS POSSIBLE. This will ensure minimum problems or wonkiness.
SpeedMin and speedMax act as a range in units per second of speed. Each projectile will come out between that variable range for it's INITIAL SPEED (pre-thrust). Very high values for speed can cause errors with the life/range detection, so be careful going over 800 or so. If you want a consistent speed, make these values matching.
Damage configures your raw 'damage on hit' value. This is modified by damagerandom, which should ALWAYS BE LESS THAN DAMAGE. Otherwise you leave the possibility of doing 0 damage on a hit.
Fulldamagerange is a weird setting. It causes damage to reduce as it approaches maximum range. This value acts as the high end range for that value and thus reduces damage at extreme range, if that's something you want to do.
Damageradius controls the radius of the unit's explosion upon the projectile's end of life. The FORCE of the blast, however, seems unmodified.
Thrusttime and thrustdelay allow interesting possibilities. They control how LONG a projectile will thrust forwards (adding velocity on top of speedmin/max) and WHEN it will begin (the delay after firing before it's initial speed is increased by the thrust value (which rapidly ramps up speed). The value of actual thrust is controlled later through thrustModifier. We'll get that one in a bit.
Next are the speedangmin/max (XYZ) settings. These are values that control the 'angular speed of a projectile'. Basically it will cause it to pitch/roll/yaw but not actually change the direction of travel.
Speedturnmin/max XYZ, however, DOES control the direction of travel and can allow you to create wildly random projectile arcs upon firing. Generally speaking you won't want much here for most projectiles, barring specific examples (see examples section below).
The physics settings are bundled into several pieces. First is 'userealphysics'. This uses a boolean flag (0 is off, 1 is on). Now bear in mind that physics are always partially enabled for projectiles, so what this does (as far as I can tell) is enable whether secondary physics effects beyond actual collisions work such as air friction, ground friction, etc.
Those settings are controlled via 'gravitymodifier' - which controls what % gravity will pull on the projectile. 1.0 = 100% and airfrictionmodifier which configures how much friction the 'air' has in the game on it as it flies forward (affecting forward velocity). Groundfrictionmodifier controls how much it skids or rolls along the ground.
Now we see 'thrustModifier' in the middle of the physics settings, for some inexplicable reason. This setting controls what % of the initial speed is added to the projectile per second while thrusting. For example, if you have an RPG with an initial speed of 150 and it's set to thrust for 3 seconds after launch at 1.0 (100%) thrust, it will start slow and end up very fast (150 --> 300 --> 450 --> 600!).
Bounceflag is a simple boolean flag for ANY projectile that determines if it will bounce when it hits something. Bounce modifier controls how much of it's original velocity is retained after the bounce as a percentage. The example for handgrenade shows .5, which is 50%. I prefer values between .15 and .30 (15 and 30%, respectively).
Sound, soundloopflag, sounddopplerflag, sounddopplerbasespeed, soundinterval, are all fairly well documented. Sounddeath is the 'death of the object' sound, or the explosion sound.
There are also many 'result' flags. These flags control the effect of the projectile upon reaching specific conditions. The flag can be a 0 for 'nothing', 1 for 'damage hit object' or '2 create explosion'. 0 and 2 work fairly reliably. 1, however, causes the object to 'disappear' upon dealing damage, removing it's persistence from the world.
Resultendoflife controls what happens when the life value is exceeded.
Resultifdamaged is if it gets hit by the enemies in mid-air. This, in my testing, seems ignored.
Resultifdamageddelay controls a delay on what happens after the hit in midair. Again, seems not to work.
Resultoninterval means this object can basically explode constantly on a set interval.
resultonintervaltime controls the time in MS that this occurs. I have not extensively tested this system.
Resultbounce controls the result if it detects a collision. In most cases, if you want your object to bounce, you'll leave this on 0.
There's also a simple particletype setting that is in the fireball/handgrenade/rpg folders you can apply to any of your custom projectiles based on these. Please bear in mind these use the OLD system which rely on the lackluster projectiles built into GG.
Please note that this system was DRASTICALLY overhauled in the upgraded new particle effects system which is demonstrated in the magicbolt projectile.
So the above is actually nothing new. If you've been monkeying with projectiles, as I have, for several years all of this is just introductory groundwork.