AgentFox2

Should be easy enough to do. The problem you will encounter, however, is that dog has a config issue which will make some of the SFP units have model errors (head and shoulders are stretched below pelvis).

Awesome work you've done, Laser. My cohorts and I have had a lot of fun with your addons! The news about the PJs also excites me, can't wait! Quick question; Are you planning on moving away from the Earl M4/M16 base model for your M16 series weapons? If so and it is a definite thing (not for discussion), then would it be possible to offer an alternative version of the new weapons pack that uses the older M4 and M16 models by Earl, instead of the newer CS or "shinier" models? Thanks for all your work and Best Regards.

Limitation: Lack of persistence in multiplayer. No inventory, mission progress, or any other kind of saving process as featured in the Resistance campaign. Broken by: CrashDome at Sinews of War. Continually bettered by several others including CrashDome, Rune, nubbin, and bn880.

Awesome. I tried out that tank for model testing that Przezdzieblo mentioned. The tank was actually harder to take out from the front than the back! It took two shots from an M1 Abrams to the back to explode and upwards of 7+ on the front! What are the chances this sort of model editing could become part of CAVS? Or maybe just providing addon makers with tutorials, etc. on how to give their addons this feature?

Awesome work, TermiPete and the rest of the CAVS contributors! The new vehicle config for JAM adds a lot to the gameplay. A CAVS-compliant EECP would give us a good starting point to base everything on. RHS, PUKF, etc. would be great, too, but that's up to them. Would it be possible to do these sort of calculations to cover other vehicles, as well? For example, with trucks or wheeled ICVs versus, say .50 SLAP or .50 inciendiary from an XM107? Thanks for all your efforts.

That should be relatively pain-free. Here's an example using the set of functions that was earlier linked to in the ITMS demo mission. To start with, spawn an invisible target like so: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">StrafeTarget = ["Man", "West", (getpos (leader _group))] call ITMSSpawn The type ("Man") can be changed to "Armor", "IR", or "Laser" for different weapon engagement types. This will take some trial and error. For example, let's say you wanted to start the aircraft strafing when West enters a certain trigger. Trigger settings: West - Present Condition: this Activation: [(MyGroup)] exec "StrafeStart.sqs" StrafeStart.sqs <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> private ["_group"] _group = _this select 0 StrafeStart = true StrafeTarget = ["Man", "West", (getpos (leader _group))] call ITMSSpawn [StrafeTarget, _group] exec "TargetUpdate.sqs" exit When the squad enters the trigger, the boolean variable StrafeStart is set to true. An invisible target is then spawned at the squad leader's position (make sure you set up the init.sqs for the ITMSSpawn function! ), and both the target (global variable StrafeTarget) and the group are passed to script "TargetUpdate.sqs" TargetUpdate.sqs <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> private ["_target", "_group"] _target = _this select 0 _group = _this select 1 #loop ? (StrafeStop) : deleteVehicle _target; exit _target setpos (getpos (leader _group)) ~1 goto "loop" exit This will move the invisible target to the squad leader's position every second until the boolean variable StrafeStop is set to true. At this point you can make a few triggers to control the boolean variables. Trigger 1 Countdown: .5 Condition: StrafeStart Activation: aircraft reveal StrafeTarget; aircraft doTarget StrafeTarget; aircraft doFire StrafeTarget This will tell the aircraft to target the invisible target once spawned. ---------- Trigger 2 Condition: StrafeStart AND !(alive man1) AND !(alive man2) AND !(alive man3) AND !(alive man4) etc... Activation: StrafeStop = true This sets StrafeStop to true if all of the men die, deleting the target and ending the update script. ---------- Trigger 3 West - Not Present Condition: StrafeStart AND this Activation: StrafeStop = true This last trigger would stop the script once the squad leaves. ---------- This is just an example of how you could get the effect you describe, assuming, of course, that you mean to use this at a single, pre-destined moment, with a certain group. Hopefully this helped in some way.

I meant the ability to detect search and track emitters before launch, not after. If that exists in any released OFP addon, I haven't seen it. I think the current absence of any sort of pre-launch warning against SARH or ARH missile systems in OFP presents the worst gameplay drawback to longer ranges for SAM systems. Good to hear.

I agree with the "compromise" idea of 3-5 km for longer range SAMs. Any farther and I think you enter the realm of hindering gameplay, since there is currently no simulation of threat warning systems on aircraft in OFP. Now, if a script system were created whereby "radar-emitting" vehicles could be tagged, and then queried globally by each aircraft, you could set up a reasonable RWR type display using rotation animations and setobjecttexture, I think. This would make things a little more manageable for the player at longer ranges, and maybe even the AI, if coded right. Even better would be some way of coding anti-radiation missiles to guide in on these "tagged" vehicles, perhaps similar to the way the Chain of Command coded their torpedoes.

enableRadio false doesn't work for the multiplayer chat system, unfortunately. And even then, there's still outside message programs that could be used (such as Voice-Over-IP programs). If you really want to enforce a "dead men tell no tales" rule, then my suggestion would be to give the dead player a blank screen with titleCut. Add a "killed" eventhandler for each of the players and point it to a script that blanks the screen with TitleCut, perhaps with the words "YOU ARE DEAD" (maybe adding a delay before you cut to black so the player can watch the death animation and see who/what killed him).

Hey, ya'll. Just wanted to chime in to show you something I've been working on occasionally. *image removed due to unavailability* Very early image, but I think you get the idea. It doesn't look too swell at the moment, but hopefully I can refine it! I am hoping to create a pack of several MANPADS. I am still open to ideas and suggestions, so please, take this opportunity to give me your thoughts! What features would you like to see in a MANPADS?

In my opinion, the AIM-9s are cool, but they have a range of 5-10km. In OFP, you're not going to engage an aircraft farther than 2-3km, due to the viewdistance. The FIM-92s would fit this sort of range better, I think, especially considering they're only supposed to be self-defense weapons. Also, it would feel a bit weird with stingers or sidewinders hanging off the stubs in a tactical situation where there are no enemy aircraft left. That's why my vote is for the bog-standard versions to be without any air to air missiles, and then a separate version with the ATAS for self-defense. Just my humble opinion.

1700 Zulu - May 10th, 2008 - Somewhere in the Swedish countryside, an LvKv ADA unit has been alerted by a nearby early warning radar post that there are possible low-level contacts inbound for one of Sweden's more important dispersed runways. The ADA unit is cleared to engage any military threats that do not respond to IFF. 1024 1024 Suddenly a two-ship strike package of Su-25s appears on the horizon. Their objective is clear. They are attempting to destroy the aircraft refueling at the nearby runway. 1024 Unknown IFF signal, the LvKv90 is cleared to engage. 1024 1024 Splash one, danger close. 1024 Addons: SFP 4.0 (soon to be released)

This sounds great. I'd love to give it a try. Unfortunately, I can't seem to find any working links for the mod and its updates. I checked the website, but the ofpcentral.com download links are down for me. Does anyone have a working link?

Coming soon in SFP 4.0 Sorry for off-topic. Awesome work, Laser. Looking forward to using these!

Hey, everyone! Some time ago I began working on a script that would allow the player (and AI) to call for suppressive fire on a position. Over time, I wanted to do more with it, and the features just kept piling on and on. Anyway, I've come to a point where I think it's best to release what I have and get feedback before I continue updating it. I call it ITMS, or Invisible Target Management System, which is a really fancy name for a bunch of really sloppy code. Basically, this set of scripts allows you to spawn and manipulate a set of invisible objects (invisible targets) that the AI can target and attack. Four examples are included in the example mission; infantry suppressive fire, close air support, close air support (with smoke activation), and ground vehicle support. They are all pretty similar, with the main differences being in presentation. I also created a new set of invisible target objects, based on Lester's awesome work. The difference is that now there are also new units for engagement priority. Lester's targets were great, but the main problem was that if a "real" enemy attacked the firing units, they wouldn't take on the new threat, but rather focus on the invisible target. This new version solves that issue with multiple groupings of differing engagement priority, based on type. Anyway, I have submitted the script and addon to OFPEC, so it can be found there for those interested. I'd like to get as much feedback and bug reports as possible, especially concerning the new low and medium priority targets and experiences with "real" enemies. Thanks in advance.

Man, I'm so terrible at documenting my own work. I'll admit it right up front. The covering fire example has the features you want, manhunter. The express purpose, infact, of keeping track of who all the groups who and their targets is so you can delete them when you're done. In the case of Covering Fire, the leader will get an action menu item saying "CEASE FIRE!" which simply deletes all of the group's targets. For other stuff (including your own target spawned using the function ITMSSpawn), there are other options. If you want to delete all targets in a ITMS-tracked group array, you can use the function ITMSClear, called like so: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[group index, group type] call ITMSClear Group index is its index in the global ITMS_**Groups array Group type is the two-letter string signifier for whichever example system the group is using. "CF" for covering fire "AS" for Air Support "AS2" for Air Support (w/ smoke activation) "VS" for Vehicle support Otherwise, there is also an option life duration argument for ITMSSpawn, which is called like so: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[Type ("Man" or "Armor" or "IR" or "Laser"), Side ("West", "East", "Res"), position, <duration>, <priority level>] call ITMSSpawn Most of that is pretty self-explanatory. Duration and priority level are both optional, so if not defined, the target will default to indefinite life and low priority against "real" enemies. For example, using this line in a radio activation field: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">["Laser", "East", (getpos bunker1), 30] call ITMSSpawn This would generate a laser target that all capable West aircraft would attempt to attack for 30 seconds. After 30 seconds, the target is deleted. You might use this as a scripted command to order a friendly aircraft to take out the enemy bunker position. As for dispersion, the script also does this. The execution line for the infantry covering fire example is like so: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[unit array, position, target side, map click shift key, random dispersion offset, ROF boolean, <rate of fire>, <rate of non-fire>] exec "FOX2_ITMS\ITMS_CoverFire.sqs" The 5th element there defines the random movement of spawned targets. In the example mission it is set at 5 meters, but setting it to 20 would result in a pretty random spread. This is how the rate-of-fire function of the Covering Fire example works. You must pass "ROF boolean" as true and then define the rate of fire and "non-fire". The first being how long for the units to fire and how long between firings. This was added a t the request of one of the testers, since it ate up a lot of ammo otherwise. The problem with this is that to do so I had to move the target far away, occasionally, then move it back and tell the soldiers to re-target. The problem is that doing so makes the AI act quirky, and since you're telling him to re-target the same object repeatedly, it makes his targeting a bit inflexible. Again, sorry for my lack of proper documentation originally. Hopefully I'll smarten up in the next update. If anyone has any questions in the meantime, feel free to post them.

Thanks, I appreciate it. As far as I've tested it, the firing AI reacts to the targets like they would to any enemy. That is, an AI squad will probably move to engage. But in testing, the player's squad did not. Units using any of the examples should have a little more leeway than usual with range. Just after the script spawns the target it shoves it right in the gunner's face, then once he recognizes it as an enemy, the script moves the target to the position originally passed to the script. This takes advantage of the knowsAbout only gradually reducing after losing sight. I've been able to get machine gunners to light up targets almost 700m away with this. Only with direct line of sight to the position. Truly indirect fire would probably be better handled by Barron's awesome script. I should mention that the examples I supplied in the demo are very simple. But I am hoping that some users will try and use some of the basic functions in new and better ways than I could have thought up. The key thing to remember is that AI reacts to the targets exactly as if they were enemy units. Bug report (for myself ): Just realized I left in a hint for the life duration script. Woops. That'll be fixed in the next update. If it's really annoying to anyone, the offending line is in ITMS_Timer.sqs Just delete this line: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">hint format ["Time Limit: %1\n\nTime elapsed: %2", _tLimit, _counter] Thanks again for your questions and comments, keep 'em comin'.

1024 1024 1024 1024 1024 1024 SFP 4.0 (unreleased), PC Cargo Ship, LlaumaX pack, DXDLL

Thanks for the comments. I had to tweak the gamma/contrast due to OFP darkening it, but other than that they are unedited. I'll post the others in a second.

1024 1024 1024 1024 This is your wake-up call. SFP 4.0 (unreleased), PC Cargo Ship

Awesome stuff, guys. I am really in awe of your knowledge and research. Will CAVS also standardize sensor/AI sensitivity and ranges? What I mean is differentiating between a tank that has at the most light amplification or day sights, and one that has thermal imaging. Or even further, differentiating between 1st Generation and 3rd Generation thermal imagers. Nowdays, this is much more important in an armored engagement than which armor is slightly better than the other. A fight between two modern MBTs, with modern ammunition, would most likely come down to which one can see and successfully hit the other first, because the first shot will probably be the last. Would there be any way of standardizing the sensitivity, radar, and camouflage values to reflect different types of sensors? Best Regards

Yes, I think this should work. If an aircraft is on final, you do not want anyone taxiing across its path. If it were on the downwind leg, or at the latest base leg, then I can imagine an aircraft being cleared to taxi across. This is, of course, assuming that there will be a traffic pattern simulated. This can vary a lot, but I was taught to keep an aircraft's length between each aircraft when taxiing. Obviously this spacing can change depending on the size of the aircraft. A line of Boeing 707s would need a lot more room to maneuver than a bunch of Cessna 152s. As far as I know, aircraft are usually taxied to a ramp (holding area) first. If they need to be stored in a hangar, I believe that is done by the ground crew, using towing vehicles, after the post-flight procedures and shutdown. Many times you will see general aviation aircraft, like small recreational aircraft (e.g. Cessnas), parked on a large asphalt parking area, with their wings and tails secured by ropes to the concrete. (example image: Airliners.net Image) This is done to keep the plane from being dragged around by the wind. I am not in the military, so perhaps someone else can correct me, but as far as I know most military aircraft are taxied to a ramp/holding area first, rather than directly taxied into a hangar. The ground crew does the post-flight checks and procedures, and then will tow the aircraft to the hangar if they need to. As for how to do this in the script; since at the moment there is no such towing apparatus available, it would probably be best to just have the aircraft taxi to the next available spot on the ramp. Best Regards

Just what it sounds like. A propane tank (like the ones you use for a gas grill) with explosives attached.

Sounds good to me.

Just tried this out Unnamed, and it rocks! I LOVE IT! I tried it out on PMC_Euro with a two-ship of F-16s returning from a CAP. I placed myself as the wingman, with the AI leader in the ATC-enabled version. I wasn't expecting it to work, since PMC_Euro isn't in the list of supported islands, but it did! All I had to do was place an invisible runway and run the ATC_Land function! How awesome is that? I have a few questions: <ul> [*]When you say that a certain island is supported, what do you mean? I could get the system to work on an island without any of the island-specific ATC definitions, infact I don't think it has any regular runway definitions. [*]What do the different ILS/runway objects actually do? [*]Does one have to have the ILS object on the map in order for the runway objects to function? [*]Can you use any old object as the "runway" passed to the land function, or must it be the ones supplied by the pack? [*]How is the direction of the runway defined? For example, if you wanted a plane to land on a runway with a heading of 120, how would you do that? Once again, awesome work! Can't wait for MP compatibility and some documentation! If that happens, I may just ask you to bear my offspring.