Jamming script

[General Barron]

That's fine. Actually, I never really made a fully fleshed-out version of that script, with different weapons having different jamming rates. But I made enough to where I could see that it would work, and then I just put it on my "to do" list for the ECP. If you are going to 'release' the script publically, I'd just ask that you make it adjustable so that it works with any weapon.

[Kammak]

Well my intent was to make an addon as you described, but for use with Earl's magazines from the Marine Assault Pack.

The script would be contained in the addon, and the mission maker could choose to use it by plugging the script into a unit with an Event Handler.  I imagine numerous addons would be made, with the same script inside, slightly modified for the correct addon's magazines (LSR M14 mags, C8X M16, C8X M4, JAM2 E545_30mag, etc...)

So one addon would cover Earl's American Weapons, a second would cover Earl's Russian Weapons.  A different addon would cover default BIS magazines, etc....

That way the jam script/addon would not affect the bullet type, sounds, and other attributes of the various addons.   The jammed magazine would be identical to the addon's standard magazines, but with differing bullet counts.

How does that sound?

[Kammak]

To continue, I'm imaging the following:

Editor adds the following code to any unit using a weapon from Earl's Russian weapon pack:

[this,.03,0,.06] exec "\kmkC8XrussJamIt\initunit.sqs"

Params:

this - the unit
.03 - base jam rate for single fire
0 - base jam rate for burst (0 if N/A)
.06 - base jam rate for full auto

Only the first param would be required, the jam rates would have defaults which the editor could use instead of supplying his own.  But by adding the option for editor-set rates, you could simulate harsh climates, poorly trained units, or worn-out weapons.

The script "initunit.sqs" would be in the addon, and would add a fired EH to the unit and other startup tasks.

The fired EH would make sure the primary weapon was fired, then roll the dice based on the failure rates, and then swap out the mag with one contained in the addon with the correct bullet count (but same ammo type, sounds, config data as the regular mag) as you described.

Is this how you envisioned it?  Seems pretty straightforward, I think.

[Kammak]

Boy, you know what would make this much simpler?  Instead of removing magazines, just remove the weapon instead.

I've got it written now both ways, and the benefit of just removing the weapon is that you don't have to worry about figuring out what magazines are actually loaded, and how many he has (and the issue requiring an addon goes away too - no fiddling with bullet counts).

Instead of adding an action, I just have the EH remove the weapon, wait a random amount of time (2 to 10 seconds for now) then re-add the weapon back.  I also have hint text saying "Weapon Jammed!!" and then "Jam Cleared" when its over.

Then the script has identical code whether the unit is a player or AI (except for the hint text).  And there's no need to figure out how to pass a magazine name/weapon name to the action script so it can add it back to the inventroy.  

The only issue is having the weapon disappear...how much of a show stopper is that?

I don't mind it, as the benefit is a working weapon jam system that applies to both AI and human players, with adjustable jam rates and no magical bullet increases.


To reiterate, trying to work it with the magazines is a nightmare when you think about addons.  Or missions that use both standard/3rd party mags AND JAM2 magazines...you just can't tell what the player has loaded in the weapon at a given moment (can you?).  And without an explicit string comparison against every possible magazine in the mission, you can't really know which magazines in the inventory are for a primary weapon.

Just fiddling with the weapon instead makes these issues disappear.

One question for the General    Had you given any thought to the dual muzzle issue?  You don't want the jam code to apply to a grenade launcher, but without explicitly comparing the muzzle type from the EH against an array of grenade launcher muzzle names, you can't tell.  If only OFP had a primary/secondary muzzle indicator!

I'm thinking of creating an array, preloading it with lots of GL muzzle names from popular addons, then allowing the mission editor to add more to the array if necessary (the same way TactEvents works with bullet types).  But if there is a better know I'd love to know.

I always consider string comparisons a last resort...especially without string case functions.

[General Barron]

Whew! Lots here to reply to. I'll take it as it came:

Well my intent was to make an addon as you described, but for use with Earl's magazines from the Marine Assault Pack. The script would be contained in the addon... The jammed magazine would be identical to the addon's standard magazines, but with differing bullet counts.

That's a pretty good idea that I hadn't even thought of. I was thinking that the original addon maker would have to config all the magazines, but I never thought about just inheriting from the original addon in a whole new addon. That's also nice because you can "hard code" all the magazine type/muzzle type names into the scripts inside the addon, so the mission maker doesn't have to worry about setting stuff up himself (more on that later).

I'm imaging the following:
Editor adds the following code to any unit using a weapon from Earl's Russian weapon pack:
[this,.03,0,.06] exec "\kmkC8XrussJamIt\initunit.sqs"
   ....
The fired EH would make sure the primary weapon was fired, then roll the dice based on the failure rates, and then swap out the mag with one contained in the addon with the correct bullet count (but same ammo type, sounds, config data as the regular mag) as you described.

Is this how you envisioned it?  Seems pretty straightforward, I think.

Pretty much. However, the problem with that is when the player (or AI under his control) picks up a different weapon. So instead of passing the jam rates to the script on a per-unit basis, it seems that having a global variable of some sort that would have the jam-rates of each weapon would make more sense (or groupings of weapons, the specifics can be worked out for best performance). You could have a single parameter passed on a per-unit basis that would scale these jamming rates for that unit (to simulate his individual training level). So it would look more like this:

[this, <number from 0-1>] exec "jamscript.sqs"

Then there might be perhaps 3 global arrays:
low_jam_rate = ["m16","ak47","ak74"]
med_jam_rate = ["pk","m60"]
high_jam_rate = ["...."]

Then 3 more global numbers determining how often each of these catagories of weapons will jam in this specific mission. Any weapon not in one of these catagories would default to the lowest or something. Anyway, you get the idea, but the specifics could be changed. This was just how I was imagining putting it into the ECP.

I always consider string comparisons a last resort...especially without string case functions.

Actually, in the case of classnames, ofp ignores the case. Odd, undocumented, but helpful . So "M16" is equal to "m16", so there shouldn't be any problem using string comparisons in a script like this.

Boy, you know what would make this much simpler?  Instead of removing magazines, just remove the weapon instead.

Well, I never tried taking the weapon away for a long period of time. But when I removed it and put it back right away, the mag would stay loaded in the weapon.

Oh, nm, I see what you are saying.

The only issue is having the weapon disappear...how much of a show stopper is that?

If the choice is between having the weapon disappear for 3 seconds, and magically gaining bullets, I'd take the latter. I'm sure most others would say the same. Aside from the obvious visual weirdness, keep in mind that you move differently (slower) when you don't have a weapon.

To reiterate, trying to work it with the magazines is a nightmare when you think about addons.  Or missions that use both standard/3rd party mags AND JAM2 magazines...you just can't tell what the player has loaded in the weapon at a given moment (can you?).  And without an explicit string comparison against every possible magazine in the mission, you can't really know which magazines in the inventory are for a primary weapon.

Well, I suppose this script relies on the premise that for each weapon, there is only one magazine type. True, in some missions a player COULD have both HD and regular mags for the same weapon (for example), but in most missions that isn't the case.

Had you given any thought to the dual muzzle issue?

A little bit, but I'm not quite clear on how they work in terms of scripting or config. Perhaps the "mode" (burst, semi, etc) section of the EH can tell you if a GL was shot?

-------

So anyway, there are definately some *complications* in turning this into a reality. In the ECP, I was going to have to settle for gross-imperfection, because I have no control over either the mission or the addons used. However, if it were a script used by the mission maker, then he DOES have that control, and can configure certain global variables to match what is in his mission. If it is in an addon, then full control is there, because you know what classnames are in the addon.

So I think it could work out pretty well, especially for an addon. Perhaps we should work together and make this a reality? Both an imperfect script for editors to use w/o an addon, and an addon that uses the script to it's maximum potential?

Specifically, there is work on a new version of JAM (called MAAM). That's a great opportunity to work this script into a really good addon. Then hopefully other addonmakers will follow suit.

[Kammak]

No, all the string comparisons ARE case sensitive - its a real bugger.  Which is why I try to stay away from it as much as possible.

Ex: if ("m16" in magazines player) then {hint "Its there"}

will always evaluate as false.  Change it to "M16" and it evaluates as true.

Only the hierarchy evals are case insensitive, in my experience (countType), but don't work on weapons/mags, only "vehicle" classes.

So the mag names have to be entered into the array EXACTLY the way OFP returns them, which is not the same as the way the config defines them, nor the same as the way the editor adds them in an init field.  I have no clue *how* OFP determines the case (when returned), but it has to match THAT.

RE: mags, the issue that can happen a lot is addon-specific magazines mixed with JAM magazines (standard, not HD).  Ex: 3 x c8xm16mags and 2 x  jam_w556_30bmag.  

And remember, the magazine has a lot of config entries tied to it, so *each* mag type has to be created 30 - 200 times if you do the mag swap.  (c8xm16mag 1-30, c8xm4mag 1-30, c8xm249mag 1 - 200, m60 1 - 100).

Instead of removing the weapon or creating a bajillion magazine entries, how about creating an addon with *weapons* which accept no magazines?!  The jam script would then replace the regular weapon with the new "dummy" weapon which can't fire.  The magazines are not removed.  Once the jam is cleared, the dummy weapon is removed and the real weapon added back in.  The dummy weapons would use the original weapon model, but not accept the magazines.

So a Marine Assault Pack weapon-jam addon would have one weapon for each weapon in the MAP pbo.  How about this - the dummy weapons would have the "strike" ammo, so the player could club people while its jammed!

That would uncomplicate the scripting a lot, and not have the visual weirdness of my first idea!  

[General Barron]

No, all the string comparisons ARE case sensitive - its a real bugger.  Which is why I try to stay away from it as much as possible.

Ex: if ("m16" in magazines player) then {hint "Its there"}

will always evaluate as false.  Change it to "M16" and it evaluates as true.

Hmm... I'll have to check this again. Perhaps it doesn't work with magazines, but I could have sworn that with vehicles, it didn't matter.

And remember, the magazine has a lot of config entries tied to it, so *each* mag type has to be created 30 - 200 times if you do the mag swap.

Not sure if I am missing something you are saying here... but yes, you would have to config a ton of magazines. However, each mag would just be like 2 lines:

Code: [Select]

class m16mag29: m16mag
{bullets = 29;}
class m16mag28: m16mag
{bullets = 28;}Well, not sure about the syntax, but you get the idea; inheritance makes it a snap.

Also, if you use the "define" command, you can make things even easier (see some of the ways BIS uses "define" in the anim config). For example, you set up one define for a 30 round mag, and then you just have 1 line calling that define for each individual magazine. So actually configging them isn't really a problem, IMO.

But, unless there is a way to determine what mag is loaded in the weapon (I suspect the order in the "magazines" array might tell that), then you are right, it is a moot point. The "dummy" weapon idea is a good one, aside from a few rare complications (dropping the weapon before clearing the jam, to name one). One thing I like about the mag method though, is that the player actually has to go "ah crap, I better fix this", and then take cover or what not, and then fix it. Plus you get the animations and all. I suppose it is quick/easy to fix many jams, like an m16, but are all weapons that easy to fix?

Plus you get the anims and everything

[Kammak]

The magazines array is a duplicate of the inventory screen - magazines select 0 == the first one on the top row.

With the weapon replacement, you would still get the anims - you're just changing what gets removed.  The reason I put everything into the Fired EH was I didn't want to have to figure out how to pass the weapon or magazine name to the action script...when there could be dozens of units involved.  Not an easy trick to solve.

As far as case sensitivity, I know unit class names are also case sensitive when doing a string comparison (x in [...], x == y, etc...) - but in that case the string always matches the config definition of the unit.  For my gear template scripts I just copy the string directly from the config.cpp and paste it into my template scripts.

Thinking more about the weapon swapout - I think writing this per addon makes life simpler regarding the muzzle too.  Each addon will have a fixed number of muzzles, so an array of GL muzzles could be easily defined per addon.

If multiple weapon addons are used in the mission (which I do a lot), the editor would just plug multiple fired EHs into the units, with each seperate EH covering weapons from one addon.  

RE: "not sure if I'm missing something here"

I was just saying that each magazine in  each addon would have to be duplicated between 30 and 200 times if you do the mag swap out, and you then have a mess if multiple mags are loaded on the unit, or cross-addon mags are loaded.  

By using a weapon replacement instead, you have a one-to-one duplication per weapon per addon, and NO mess trying to figure out what magazines are carried, and which magazine type was actually loaded in the weapon.  I think that task is impossible in OFP with the functions available, unless the player has only one item in his inventory.


RE: Skipping the per-unit jam rates, that's probably right.  However, I think it would be nice to have a rate defined per-weapon instead of bulk groups that each weapon is pigeonholed into.  The M16 should definitely have a much higher jam rate than an Ak47, especially on burst, for example.  Those kinds of numbers are fairly easy to find, and could be plugged right into a script array.  You also use this system to model other failures besides feed jams, such as the magazine-hold failures in the L85s.

This system would certainly devalue the M16A1 vs. the A2.  I think right now many kids prefer the A1 in-game with its full auto.  Once you have to deal with jam / mechanical failures, preferences would start mirroring historical opinions a little better.  

[Kammak]

Attached is a demo showing how it looks for a player and an AI unit.  The demo requires the Marine Assault Pack.

There is one pbo in the zip, which should go in your addon folder, the other files are the mission folders in editor form.

The addon only has the c8xm16 right now, just to demonstrate the "system".  Likewise, the jam rates are passed per unit for the demo only.  Obviously a more robust system will be done for the final product, assuming its made.

The script accepts three jam rates, one for each mode.  It only applies to primary weapon fire of a non-grenade launcher muzzle.

If the unit is player controlled, an action "Clear Jam" will appear in the action menu IF the weapon jams during firing.  The weapon will stay non-functional until the player executes the action.

The weapon says "M16A4 JAMMED" to remind you.  

If the unit is AI, then it will be unable to fire for 0 to 5 seconds.  After that random duration, the unit will stand up then perform the magazine reload animation.  He will then be able to fire again.  If an AI unit in the player's group has a jam, he will report "No Ammo".

Let me know what you think.  If its way off the track of what you had in mind, let me know.    I'm just having fun with this - however its implemented it will be a very cool addition to OFP.

[Sophion]

can you try using standard BIS units

[Kammak]

Well, that demo is using BIS units with Marine Assault Pack weapons.  

I won't be doing anything with BIS weapons, sorry.

[Kammak]

@General Barron - Did you lose interest in this or just been busy?  I was waiting for your input on the demo before finishing it.  I've got a guy offering to make custom animations for this too, which could be included in the addon with the changed weapons.

[Kammak]

bump

[Morglor9]

You could have a single parameter passed on a per-unit basis that would scale these jamming rates for that unit (to simulate his individual training level). So it would look more like this:

[this, <number from 0-1>] exec "jamscript.sqs"

Then there might be perhaps 3 global arrays:
low_jam_rate = ["m16","ak47","ak74"]
med_jam_rate = ["pk","m60"]
high_jam_rate = ["...."]

Just one thing I thought I'd point out to ya. After doing a small amount of research, most sources say that the M16 is actually VERY suseptable to jamming. It should be at the medium or high level, not low. A good thing to know for anyone who decides to tackle this thing.

[macguba]

Under normal conditions, what is a typical mean rounds between failure?    The new, fixed version of the British army's rifle, the SA80, fires an average of 8,000 rounds between failures in desert conditions, and 25,000 rounds in a variety of environments.   (At a rate of 150 rounds in 8m40s.)

In a typical OFP mission the player rarely fires more than a few hundred rounds.    

In other words even if you warn the player that jamming is likely you would still only expect a jam to occur in perhaps 1 mission in 20.

However, I can see that, from an intellectual perspective, creating a jamming routine is desirable.     The way to go is probably

hint "your weapon has jammed"
count and removeMagazines
addAction "clear weapon"

disableUserInput true
changing magazine animation
add back magazines
disableUseInput false

and live with the increase in ammo.   Or maybe add back one mag fewer (always leaving at least one) and make it a decrease in ammo.   You need a loop to check the player hasn't picked up any mags from an ammo crate or body.  Making the weapon disappear seems unneccessary.