AgentFox2

I agree with making it harder to aim at longer ranges, but unfortunately it is quite the opposite in JAM2. It is actually EASIER to hit targets farther away, at least with most of the newer addons, since in close, the bullets actually have a highly arced trajectory. The impacts are 1-2 meters higher than the aimpoint. I would personally prefer it, as a player, if with the new JAM we had more realistic SD rounds (ie supersonic for most) right out of the box. My meaning being that the more popular JAM-compatible addons out there (Earl's weapons, Laser's modifications of those, and similar) would be more realistic immediately, without having to edit ALL of those SD variants to fit a new supersonic magazine definition. How much of an affect can changing that have? How many addon weapons out there realistically would use subsonic ammunition? I don't think that changing the subsonic rounds to supersonic rounds (both in velocity and sound profile) would significantly affect mission playability. It seems like the advantages to changing to supersonic would be: More realism out of the box for the weapons that operationally use supersonic ammo. Most of the JAM-compatible SD weapons out there are M4s or variants. So MOST of the addons out there that would be used in missions would actually GAIN realism rather than lose it. Disadvantages: To change the sound profile may affect older mission's gameplay due to AI. I don't see how that works out logically...How would it affect the mission design? It would affect how the players play the mission. If mission designers could redesign around the new supersonic ammo, what changes would they make? I can't think of any as a mission designer. Advantages for staying with subsonic SD: Mission consistency. Disadvantages: With the more popular addons out there, there is going to be a serious zero problem (rounds impacting a meter above the aimpoint at ranges closer than 150m) Reduced realism for MOST JAM-Compatible addons Personally I think the advantages of changing to supersonic outweigh the drawbacks, but I guess it is not really my decision to make. Take care, all.

That could work, but only problem then is that many of the larger weapons packs now use the "subsonic" ammunition, when they should be using supersonic. The number of weapons that can use subsonic ammo are a bit fewer than those that use supersonic with a suppressor. So I think in the end the workload for authors who have to change to supersonic versus those who have to change to subsonic is significant. If you keep it as it is, then most suppressed weapons addons utilizing JAM will have to update themselves. If you make the SD mags supersonic, and add a subsonic class, then far less will have to update. But that's just my opinion.

That sounds great to me! I hadn't thought of the impact changing the firing signatures would make to existing missions. Good catch! I think creating the extra subsonic ammo for all the suppressed mags would be a great compromise. Additionally, I just had a thought about the initspeed value. I had forgotten that the 744 value might just be specific to the M4, so I rechecked the Marine config. M4 Non-SD Initspeed: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=874; M4 SD Initspeed: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=774; AK74 Non-SD Initspeed: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=899; AK74 SD Initspeed: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=764; AKS74U Non-SD AND SD BOTH Initspeed: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=735; Obviously not as many of calibers or munition types present in JAM, but there is something of a pattern, at least in the full rifles. M4 NSD-SD 874-774 = 130 AK74 NSD-SD 899-764 = 135 I dunno how useful that information is, or even if that difference was deliberate, but maybe supersonic SD ammo should be reduced by some approximate amount relative to the non-SD muzzle velocity? Perhaps some testing should be done with that to see if that is an acceptable concept. Take care.

Optics zero is controlled by <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">distanceZoomMin=400; distanceZoomMax=400; in the config of the weapon. The above value is what most of the BIS weapons are set to (M16, AK, etc), and JAM's demonstration weapons inherit directly from these classes without changing the value. So this value is largely outside of JAM's scope (because it is in the weapon code, not magazine). The problem is that with a low initspeed value (which is unrealistic for many of the weapons supported by JAM), OFP thinks that it HAS to get to whatever the scope distance is set to. So it's just that the initspeed needs adjusting. In JAM, the muzzle velocity (initspeed) for the 30 round 5.56 mag is <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=874; But the muzzle velocity for JAM's 30 round 5.56 SD mag is <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=350; Meanwhile, the muzzle velocity for Earl's non-suppressed M4 mag is the same as JAM's <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=874; while in Earl's M4 SD mag, this value is <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=744; You can use subsonic ammunition in the real M4, but the bolt has to be manually cycled for each shot. This is obviously not too acceptable for the role of an assault carbine, so most of the time the suppressed M4/M16s use supersonic bullets. The supersonic "crack" of the bullet is still there, but the shooter's firing position is not revealed. I think all you would need to do to fix it is change the init speed in most of JAM's suppressed magazines to the value in earl's suppressed mag (744). The other stuff like the range at which the shot can be heard and volume of the shot should probably be tweaked so that the change from subsonic to supersonic is apparent. The cool thing is that with the changes cornhelium has already made to JAM (sounds coming from bullets in flight) it actually comes pretty close to simulating the supersonic crack of the bullet's flight.

It's actually unrealistic, since most of the suppressed weapons which have magazines defined in JAM don't use subsonic ammunition, but supersonic. M16s, M4s, MP5s would not use subsonic munitions, and if they did, they would not be zeroed for 400 meters, as JAM's ammo is. The only assault rifle I can think of operationally using subsonic ammo would be the 7.62x39 for the AKM with PBS-1 suppressor, but even then those who operated that sort of weapon would not zero it for 400 meters. Like I mentioned previously, I think taking a look at the way the Digital Grenade team coded the suppressed M4s in the Marine Assault Pack would be a good reference on how to config the suppressed magazines in JAM. Hope everyone is doing well.

Great work, Laser! Can't wait to try them out! Have you considered adding some models with the EOTech Holosight to your US weapons pack? I think it might really fit the theme and round out the pack of M4s, and possibly M14s. And if not, I will still enjoy using them! Again, great work!

SFP 4.0 (Unreleased)

Well, I am working on such a feature! Hopefully with the changes I make it will make suppressive/covering fire an effective tool for the player (or enabled AI squads). Well, OFP's AI can take care of a lot of those type of things up close. In the editor, try setting up a battle between two squads, and then run back and forth right in front of your squad's firing line. You'll notice that as you pass each one, they stop firing and wait for you to pass. At further distances however the AI is less thoughtful, because by the time you are actually "inside" their direct firing line -- and they stop firing -- the previous rounds are already on the way. Obviously they cannot recall these rounds. As an illustration to my answer, an example: I was testing out the script by trying to assault a base with a heavy MG team. I had one fireteam of the 2nd fireteam leader, a heavy machine gunner, and an assistant machine gunner laying waste to one entrance to the base by telling them to target the entrance on that side of the perimeter wall. The second MG team and myself flanked a bit off to their left, and I set my machine gunners target as one of the wall sections, but kept him on hold fire. I took down that section with an AT-4 and let him go. As I ran into the opening with the assistant machine gunner, I told my machine gunner to hold it and fall in. As I was clearing the base, I rounded a house corner and then *KERPHAT!* I bit it. As the camera zoomed to my killer...it was none other than the other machine gun team, who I had forgot was firing into the base! Just a small example to show that yes, it is quite effective (even against friendlies )

Yes, that is correct. To put targets in windows you would have to pre-place them in the mission editor. The only way to do it dynamically would be to catalog every window or door position of every building in OFP. Then you would have to find the nearest building, find out which building it is, then figure out which pre-configured window you want to use. Obviously that would be a lot of tedius work for not much benefit. I have already done this. In the current test version of my script, you select the soldiers you want to lay down fire, and click on the map. The invisible target is spawned and the guys begin to spray the whole place! When I was testing it out, I had one fireteam stop and lay down fire while myself and the other fireteam flanked around. Then I'd make the second fireteam stop and target the same area, and advance the first fireteam past our position. Worked great and was great fun! Even without enemies to shoot at! I am also working on other functions. I should have a beta version for everyone to try out soon.

I've had that alt-tab problem before. Try messing with your resolution in OFP. Make sure it is not the same as your desktop. This fixed a similar problem with my system.

Awesome pack! I love it! Would it be possible to make the model for these soldiers work similarly to the Generic OPFOR pack? Using hidden selections and setobjecttexture to randomly clothe them? That's the only thing I can think of that would make this pack any better! Again, awesome work, Munk, WheresMyRabbit, and of course JJR!

Object1 = "classname" createVehicle [3-element position array]

Welcome to the real meat and potatoes of the OFP experience! Here are some resources from the site that Nubbin posted that may help you: MacGuba's Guide to Mission Editing for Beginners There are many other tutorials here in the Getting Started section that will help you out as well: OFPEC Getting Started Happy editing!

I'm having some issues with a config of mine, and can't for the life of me figure out why. At the moment the config has a few weapons included, and some soldier unit entries, simply for the purpose of testing those weapons out. The weapons, however, are not the problem, as I can add all of those standard BIS soldiers, with no problems. So, that narrows it down to the unit config. The error I get is like this; I place down my placeholder unit within the editor, and then hit preview. It hangs on "Get ready..." for about 15-20 minutes, and then crashes to the desktop, sometimes with the error message "Out of reserved memory...", sometimes without any message at all. I am running OFP with no other addons other than the test addon, so I can't imagine it is the amount of addons loaded. Here's the unit part of the config: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">// some basic defines #define TEast 0 #define TWest 1 #define TGuerrila 2 #define TCivilian 3 #define TSideUnknown 4 #define TEnemy 5 #define TFriendly 6 #define TLogic 7 #define true 1 #define false 0 // type scope #define private 0 #define protected 1 #define public 2 #define WeaponNoSlot 0// dummy weapons #define WeaponSlotPrimary 1// primary weapons #define WeaponSlotSecondary 16// secondary weapons #define WeaponSlotItem 256// items #define WeaponSlotBinocular 4096// binocular #define WeaponHardMounted 65536 ... class CfgVehicles { class All{}; class AllVehicles:All{}; class Land:AllVehicles{}; class Man:Land{}; class Soldier:Man{}; class SoldierWB:Soldier{}; class SoldierWAA:SoldierWB{}; class FOX2_SoldierWAA : SoldierWAA { displayName="AA Soldier (Stinger)"; vehicleClass="FOX2 - Men"; accuracy=1.5; weapons[]={"M16","FOX2_Stinger","Throw","Put"}; magazines[]={"M16", "M16", "M16", "M16", "M16", "FOX2_FIM92Amag"}; }; class FOX2_SoldierWAA2 : FOX2_SoldierWAA { displayName="AA Soldier (Stinger-RMP Block I)"; weapons[]={"M16","FOX2_StingerRMP","Throw","Put"}; magazines[]={"M16", "M16", "M16", "M16", "M16", "FOX2_FIM92Emag"}; }; }; I've racked my brain on this, and can't seem to find a solution. Anyone out there who might know what the problem is? Thanks and Regards

Howdy, grunt. Wow! What a coincidence. I am currently in the process of writing a system of scripts to do just what you described! Maybe we could work together?

Hope all is going well with everyone. I have some additional thoughts apart from what I already mentioned about grenade vests...These are just suggestions, but I think they would really enhance JAM as a whole. With the current JAM code, 200 rounds of 7.62 links take up the same amount of inventory space as the same amount of 5.56. This is obviously not representative of reality, as in real life, 7.62 rounds weigh much more than 5.56, meaning you can carry less of them. Currently you can load up an M240 or FN MAG machine gunner with 1,000 7.62x51mm rounds!! I think that in the future, the space ammunition takes should be taken into account for realism. Perhaps it would be better to have a system like so: 50 round 7.62 belt - 1 space 100 round 7.62 belt - 2 spaces 200 round 7.62 belt - 4 spaces with 200 round 5.56 belts still taking 2 spaces The second issue I'd like to suggest fixing is the problem with the suppressed magazines. They seem to have too low of a velocity for many weapons, especially 5.56mm, as most of the common 5.56 weapons cannot use subsonic rounds without manually cycling the bolt (which means they are not used). This causes quite an arced and unpredictable trajectory anywhere below 400 meters with JAM. Maybe it would be best if the suppressed rounds in JAM were similar in config values (trajectory, sound config) to Earl's M4 mags, as those are one of the most well done examples of suppressed weapons in OFP, in my humble opinion.

Frostbite: Thanks. How did I do it? The answer is simple. I used a time machine. Seriously, though, what I did was I set up a Game Logic as the base position for the camera (so it wouldn't change). I took the the scene with Suchey's Marine first. Once I took the first picture, I went into the editor and switched the unit to the WW2 USMC unit, then took second nearly identical picture. In PSP, I just used a mask, removing the water from the Modern picture so that the reflection from the WW2 one (which was a layer below) could be seen. I'm glad someone liked it.

Reflections Addons used: Suchey and Earl Marines, Pacific War USMC

Awesome initiative, I can't wait! As far as suggestions for new ammo types, etc., all I want is a couple more types of grenade vests. I really like the 24 round vests we have now, but one drawback is that it takes up 5 whole ammo slots, only leaving room for 5 magazines for the ballistic component of the weapon. Would it be possible to have a larger variety, with different number of rounds, and corresponding slot space? For example, perhaps something like this for the M203: 24 round vest - 5 spaces 12 round vest - 3 spaces and of course the single round taking up 1 space What do ya'll think?

It should, although you may want to add a parenthesis or two to that condition (simply for protocol's sake) Like so: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? not (Player In myTriggerList) : Exit I'm not sure what you're trying to do. Could you explain it for me? If you're trying to make a list of player units, and give them variable IDs, I think an array would serve you better for your global variable. After declaring the global variable VARIABLE as an array, by writing "VARIABLE = []" without quotes somewhere early (like init.sqs), your above code might look like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? not Player In myTriggerList : Exit VARIABLE = VARIABLE + [PLAYER_IDX] I think you might want to check out the Chain of Command's Network Services script suite, which can be found here. Also, you can find documents and other neat scripts at this link. You are suffering from a mild case of scriptotitis. If you begin to speak in script code to your family members and friends, please seek a doctor.

I am definitely not a source of knowledge on all that is scripting, but I think I may have some hints to the solutions for some of your questions. Not quite sure about this one. Someone more knowledgeable than I might know. But I think it would be the same as writing VARIABLE = true in a script that executed on all clients (including the server). As far as I know, on a non-dedicated server, player will refer to the host's player unit. On a dedicated server, I don't think player will refer to anything on the host computer (may be wrong on this). On all the clients, player will refer to the local client's player unit. The player variable will be different for each client (corresponding to their own local player units). Triggers are global or executed on each client, I believe. Game logics are only local to the server. So if you put a line of code into the init field of a game logic, that code will only execute on the server, as far as I know. (although I think it may have a global effect; for instance, CreateVehicle. I may be wrong on that one.) I would say those are some pretty tough questions. I'm sorry if I misunderstood any of them and gave a misleading answer.

Some USAF aircraft (especially fighters) have tailhooks in case of emergencies. They aren't used on naval aircraft carriers, rather they are used on a regular old runway, except that there are arresting wires laid across the runway. Great work, Footmunch!

Gotcha. Thanks for the quick response.

Awesome to hear about this! Thanks to Avon, Cornhelium, BAS, and everyone else involved! I have one question: Would it be possible for the final JAM3 to not use the current sound folder system, but rather the .pbo? I understand the purpose of it (flexibility), but I fear the use for those who would cheat with it. (ie. replace a silenced round's sound with a very loud one, etc.) I think to offer the sound flexibility, you could just do as you did with this thread (offer multiple sound .pbos, etc) Thanks for everything!

Here's a temporary link to Zayfod's awesome script w/ demo mission from way back. (Cheers, Zayfod) http://s16.yousendit.com/d.aspx?id=0VOYWND1GQB5U0L86GWUSHOMAU