Jamming script

[Sophion]

I searched the forums and found no link to get this. I was spoken on the forums before but i can't find the actual scipt.

[1shottokill]

Yes mate, it was discussed but it just died, like threads do ;D. I'm sure someone would help you if you wanted to start it up in the recruitment depot. (just not me, i'm useless at scripting  )

[Triggerhappy]

i can probably help out with scripting (i'm rying to do as much of this as i can so i learn it really well) but it depends on what you want... could you give details on what the script should do?

[General Barron]

I remember looking into this a while back, and I decided the best way to simulate a weapons jam was to remove the player's magazine, then add it back in again right away. This basically has the effect of "emptying" the weapon, forcing the player to "clear it" by reloading. Of course you would detect when the player shoots his weapon via an EH.

The upside to this method is that it lets the player decide when to clear the jam, instead of forcing him to do it right away via switchmove. The player doesn't see anything "funny" (like his weapon disapearing); his ammo count just drops to 0 all the sudden (of course, you can script in a message or sound indicating what happened). The mainside though, is that when you add a mag back into the player's inventory, you add a FULL mag. So if he had 1 round left in an m16 mag, when his weapon jams, he will get 29 free bullets.

This downside could be very nicely avoided if you were making an addon; you would just need to make 30 different magazines (one with 30 rounds, one with 29 rounds, one with 28, etc).

But even without that (pure script form, no addons), it still is a good compromise, IMO.

[Sophion]

Yeah... The big problem of not able to add rounds in OFP. That looks like it might work. I was looking for something a whole lot advanced.

-Jam if a unit passes by the player < 5m while the player is prone on sand
-Jam randomly if it is raining
-Jam if a unit passes by the player < 5m while the player is prone on snow

As you can see it will be very dificult.

[Triggerhappy]

not sure you can even do the prone thing, because they are just textures, and i don't think the game engine recognizes them to be grass, sand etc

[General Barron]

Triggerhappy  is right; there isn't really a way to tell if the player is prone, and there isn't really a way to tell what type of surface someone is walking on. Actually, I'm not sure WHY those things would even cause a jam though. I mean, a why would a guy walking 10 feet away from you do anything to your weapon? If you are going to add in some "conditions" for jamming, I'd say these things should make a jam more likely to occur:

-Firing lots of rounds rapidly, one after the other
-Crawling around prone a bunch (i.e. dragging your weapon through the mud)
-Generic "environmental" modifier set by the mission editor (i.e. in dusty environments he could up it)

The first one might be easy to do, but the second might not be possible at all.

[Sophion]

You can just put a trigger or an object to simulate the sand and snow. Then you can put an object at 2m (? don't know how high a man is standing) and make it to be a set hight like "Crouch Hight" and another can be "Prone Hight" So if the player goes lower than them it would activate. Name the AI players and make it so if they get close to him it will execute.

I don't know but i think that the above can be used for crawing a lot.


You have to remember, the M16 has an open chaft. It is easy for sand and snow to get into it and jam the weapon.

[General Barron]

Unfortunately, you can't really detect if the player is prone or standing by checking his "altitude" like that; because the same number is returned no matter what position he is in.

Not sure what a "chaft" is, but I assume you mean the ejection port (Where the cartridge casings come out of after being fired)? Well, first off there is a cover you can close there, and second, I don't see how dirt would get in there just because someone is running past you like 15 feet away, and third, I don't see how a little snow would jam the weapon.

[Sophion]

Ok. ok... I'll let you have it.

I'm not sure how you can detect if a unit is fireing rapidly. But then again i'm not used to event handlers.

[Homefry31464]

I remember looking into this a while back, and I decided the best way to simulate a weapons jam was to remove the player's magazine, then add it back in again right away. This basically has the effect of "emptying" the weapon, forcing the player to "clear it" by reloading. Of course you would detect when the player shoots his weapon via an EH.

The upside to this method is that it lets the player decide when to clear the jam, instead of forcing him to do it right away via switchmove. The player doesn't see anything "funny" (like his weapon disapearing); his ammo count just drops to 0 all the sudden (of course, you can script in a message or sound indicating what happened). The mainside though, is that when you add a mag back into the player's inventory, you add a FULL mag. So if he had 1 round left in an m16 mag, when his weapon jams, he will get 29 free bullets.

This downside could be very nicely avoided if you were making an addon; you would just need to make 30 different magazines (one with 30 rounds, one with 29 rounds, one with 28, etc).

But even without that (pure script form, no addons), it still is a good compromise, IMO.

So, if you were making a weapon addon... this could work?  When you return the amount of ammo left, does this give you a number of bullets or just magazines?

[Triggerhappy]

i'm not sure there is any way of knowing how many rounds are left in a mag, unless there is a way of telling if they reloaded.
if you can do that, then you can use a "fired" EH and count how many times the gun was fired and use that to findout what to give the person, resetting the count when the player reloads

[General Barron]

This could work if you were making an addon. You can check how many rounds are in a unit's current magazine with the "ammo" command. Then you remove his magazine, and add back in a magazine that is configured to have that many bullets in it.

[Sophion]

I was thinking about that to. But i don't have any exp with cpp files (?). Some one else would have to do that.

[Kammak]

That's beautifully simple, Gen. Barron.  I love it.  Only problem I see is with addons...I never use default BIS mags at all.  Do you care if I make this for the Marine Assault Pack magazines?  Give you equal billing as the creator?

[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.

[Cooba]

Ok, then i have one noob problem. I dont know how to write correct script (command) which check number of magazines in player (AI) slots.
Help please.

sorry for uncorrect english

[Sophion]

*cough*

you can check the Command Reference for commands first, if that doesn't help then ask here (after you search of course). but this is a topic loosely related to your question. so... please ask at appropriate places  

[Terox]

check this out
A weapon jamming system i made

http://www.ofpec.com/yabbse/index.php?board=8;action=display;threadid=21893

[Shalashaska]

You were talking about jammed magazines, and I have aquestion, related in some way with this forum:
using a M249 (example), can I take out an Ammo-Box and load a common STANAG magazine?
The problem is to have this shown (in an old addon you could do something similar, but you kept seeing the previous magazine, even if it was different).

I already have the Model with the STANAG magazine loaded, but that's a single weapon, no match with different mags (Ammo-box included).

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

M16 is between LOW and MED, M4 is MED and AK47 is (very) LOW -unless you're a terrorist (they always manage to jam an AK47, dunno why...)

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.)

Yeah, he's right.
the AWM (Artic Warfare Magnum) can fire at least 50.000 rounds before a check. In OFP you will NEVER shoot so many rounds, LOL !

FOR ANIMATIONS, ask to Sanctuary, he made very beautifull ones.

Finally, I have another question: in some guns, you can see the full recoil, with the slide which goes back, the hammer goes down and so on.
How do I realize something similar? I saw a .p3d model, and I noticed two slides... waht does it mean?  

[Terox]

The magazines that a weapon can use are stated in the weapon's config

and as for the anims that are played they are also config entries

[Shalashaska]

Ok... The magazine can be put in the .cpp file, but what about changing Type of magazine and have it shown (BOX ---> STANAG) ?  

[Terox]

the visible magazine is part of the weapon model

there isnt a weapon model without a magazine and then a magazine bolted to the model so as to speak, its all one thing

otherwise you would have to use a very fast setpos looping script and with lag it would look odd

what you could do is have hidden selections, eg, hide a texture and replace with another texture to make the mag look different.

dont know whether or not that is dynamically possible

[Shalashaska]

where shall I look so?

[Terox]

these are all config entries, you will need to de pbo the addon to access these.

The hidden selections are basically textures that can be hidden from view and are created during the addon design

, eg have to have  a short and long barreled version of "myweapon"

you would create 2 config entries

Use the same model
have 2 hidden selections
Barrel_long
Barrel_short

and then have 2 config classes

class tx_mylongbarrelweapon: riffle
{
..... model="myweapon.p3d";
..... hiddenSelections[]={"Barrel_short"};
..... displayName="Longbarrel myweapon";
}

class tx_myshortbarrelweapon: riffle
{
..... model="myweapon.p3d";
..... hiddenSelections[]={"Barrel_long"};
..... displayName="shortbarrelbarrel myweapon";
}

[nmanjar]

well assume the soldier has been maintaining his weapon and leave m16 under low