Zenophon

Enemy troops are supposed to fast-rope, to avoid having to find good landing zones. The fastrope animations and process is a little clunky, but as long as they reach the ground unharmed, it's working as intended. The flares don't really do their job; I don't know if they help the AI at all. I'd hate to just cheat and give them NVG's when the alarm goes off; maybe I'll try tweaking their spotting skill. Ok, I'll add an explosion after all the players are a few hundred meters away. I can't guarantee that the buildings will be destroyed realistically; they are fixed map objects. The explosion will look good though. I like night and SF missions; I think that it makes sense to cast players in a SF role due to their skill advantage over the AI. Making the players guerrilla fighters and having them kill dozens of enemies just doesn't feel as immersive (I usually handicap them with inferior weapons and less ammo to mitigate this). I think fewer enemies gives a more realistic feel to the missions. Knowing that a mission will always boil down to a big fire-fight can get boring (of course, I provide a few of those missions as well). The ability to maneuver without running into an enemy every 50 meters encourages tactics in addition to just shooting skill. I guessed that most players would not want to hold 'W' and wait while they swim a few hundred meters; I try to minimize the time in which players are just moving without any challenge (Vendetta is a bit guilty of this though). If it's an infiltration with possible enemy contact, even if unlikely, I make the players go a decent distance to build tension. However, I can compromise and do something like a 50-100m swim to the SDV. That's not too long but provides a good wind-down to the mission.

Depending on what you want to change, you can modify the spawned objects by detecting them dynamically: { if ((alive _x) && {(side _x) == east}) then { _x forceAddUniform "<...>"; }; } forEach ((getPosATL OpforSite) nearEntities [["Man"], 100]); Just put whatever uniform you want in there, change OpforSite to the name of the module, and tweak 100 to whatever distance includes all the units.

So you're saying BIS_fnc_getTurrets cannot get only the FFV turrets, so you cannot just add "transportSoldier" and BIS_fnc_getTurrets FFV results? You can do this with my scripting library and framework (link in my sig): ((getNumber (_vehicle >> "transportSoldier")) + (count ([_vehicle, "CargoFFV"] call Zen_GetTurretPaths)) If you cannot/don't want to use my entire framework in your project, I can make a standalone implementation of Zen_GetTurretPaths for you. However, I would recommend also looking at the nearly 200 other functions my framework offers to see if any others can help you.

Does the task complete, i.e. you get a notification and a green check on the tasks screen? Then, a new resupply point appears as a task and on the map? That means your progressing through the mission. Destroying the box is not at all required, in fact it may prevent the task from completing (I never tested that). The blue marker with text should move to the next point, while a green check and circle will remain at all complete resupply points. That green check is left there so players can return to the box or see where they've been.

Overview Greetings fellow Armaholics, this release brings a new mission, Co-6 Pursuit, to the pack. It's a combined arms mission in open country; it might be a little too difficult, so I'd like some feedback on that from people who've played it with 4-5 other players. As always, a description has been added to the main post along with the next mission's tentative description, and the download links are updated. Sweep has receive several more changes, which should include all the user feedback and various things I've thought of. Civilians have been improved significantly. There are now civilians in houses with the Opfor, civilians running to hide in their houses, and civilians running away from the town. Garrisoned Opfor also either stand watch at random windows or patrol the building and street. The flares in Blackout are improved, but they're still not exactly what I wanted (i.e. very bright and floating with little parachutes). Shootout now has a briefing, which only contributes to the light-hearted fun of the mission. Changelog 7/24/15 New Mission: Co-6 Pursuit Blackout Improved: Flares are now stronger [*] Shootout Fixed: Added briefing text [*] Sweep Fixed: Too few houses were garrisoned in some random cases Fixed: Spotter now has the correct name on the role selection screen Fixed: Spotter now has the correct group name in side chat Fixed: Briefing text now includes the spotter Added: A random chance for civilians to be in the same houses as Opfor Improved: Some Opfor are stationed at windows in their houses, others still patrol the building Improved: Some civilians seek cover in a nearby building if they're close to the combat, others run for their lives

Summary Greetings fellow scripters, I've added some new usabilty improvements to this script. All of the arguments are now checked for the correct type. If the first two arguments aren't right (or aren't given), the script stops and prints an error. For the rest of the arguments, the script will substitute a default value if necessary and continue onwards. It will also print an error (to local chat and to the log) and stop if no buildings have been found, this should tell users why things aren't working in some cases. Finally, thanks to a suggestion by JohnnyBoy, the AI no longer respond to orders from their group leader to move from their positions and attack enemy units (they'll stil target and fire individually). The new version is already hosted on Google Drive, and will be on Armaholic soon. All relevant sections of the original post have been updated. Changelog 7/21/15 Added: Error reporting for invalid position and unit array arguments Added: Error report if no buildings are found Improved: Parameters 3, 4, and 5 are now optional and check for the correct type Improved: Parameters 6 and 7 check for the correct type Improved: AI should now stay in place better (thanks to JohnnyBoy) Feedback I think the '_units' thing must be the error; append is working on stable branch for me (it was only on dev branch for a while).

'Target' is group leader orders and 'AutoTarget' is the AI's own individual attack logic, so your code will solve the issue of them receiving attack orders while walking to the position as well as try to move away from their position. I'm going to update the script with your suggestion as well as use the new param/params commands on the arguments; the new params commands will be much faster than a scripted solution and make the script easier to use. Do you have an example of how do that? Not sure if you can use spawnGroup in array. I have about 6 groups doing this. _grp13 = [_markerPos, _side, (configfile >> "CfgGroups" >> "West" >> "Guerilla" >> "Infantry" >> "IRG_InfAssault")] call BIS_fnc_spawnGroup; nul = [(getPosATL leader _grp13),units _grp13,(random(300)+25), true, true, true] execVM "scripts\Zen_OccupyHouse.sqf"; {_units pushBack _x} forEach units _grp13; Something like this: _units = []; for "_i" from 1 to 6 do { _grp = [_markerPos, _side, (configfile >> "CfgGroups" >> "West" >> "Guerilla" >> "Infantry" >> "IRG_InfAssault")] call BIS_fnc_spawnGroup; _units append (units _grp); }; nul = [_markerPos, units,(random(300)+25), true, true, true] execVM "scripts\Zen_OccupyHouse.sqf"; If you need more features than simple repetition (e.g. the group changes each iteration), I can add that. If _markerPos is changing, that requires a different approach.

Try -1 as the distance. The exact position of the building may not be within 10 meters of the group leader. Also, can you give me the exact value of _markerPos, so I can test this on the same building. If only there was a true/false switch to make the AI smart...unfortunately, I don't have control over the AI at a low enough level to change their tactics like that. Units moving to a position are monitored by the script and told to stop once they get there; however, being unitReady at the correct position isn't a sure thing, especially in combat. If they decide to run off before they get to the final position and are forced to stop by the script, it's difficult to detect that. You can try: { _x disableAI "FSM"; } forEach _units; to stop them from doing some things, but the group leader will likely still give targeting and attack orders. There's also things like setCombatMode and setBehaviour that are able to control their aggressiveness. I don't use those commands in the script, so they'll remain in effect if you apply them before/after the script runs.

Yes, IRL civilians are a concern right when a firefight starts (if they don't know it's going to happen) and when enemy combatants start taking over houses with civilians in them. I can put civilians in the same houses as the Opfor are occupying as well as have wandering civilians get to the nearest building once someone near them is firing. This way, you'll have to use realistic tactics and caution when entering a building, and the sniper will still have to watch out for civilians that haven't hidden yet.

'this' is the special value for the current object in an editor init field. Within a script/function run with execVM/call/spawn, '_this' is the arguments given; you just need to change the first argument to Occupy House to the position of the group: _grp13 = [_markerPos, _side, (configfile >> "CfgGroups" >> "West" >> "Guerilla" >> "Infantry" >> "IRG_InfAssault")] call BIS_fnc_spawnGroup; nul = [_markerPos, units _grp13, 10, false, false] execVM "scripts\Zen_OccupyHouse.sqf"; You can also use (getPosATL leader _grp13), which should be very close to _markerPos.

Overview Greetings fellow Armaholics, I have updated this mission to use my latest framework. All of the improvements are the result of changes in my framework Changelog 7/13/15 Improved: Various improvements and fixes included in my latest framework

Overview Greetings fellow Armaholics, I have updated this mission to use my latest framework. Most of the improvements are the result of changes in my framework, and I've updated the JIP code accordingly. All three map versions have been updated. Also, those three versions are now packaged into a single 7-zip file, for ease of download (15 times smaller); that new link has been added to the main post (previous links are still valid and updated). I'm not sure if the bug with putting players in the insertion helicopter is fixed; I still cannot reproduce that bug. I've done everything I can think of that might fix this, but I cannot guarantee it will work for everyone. If it was failing before, give it another try and tell me what happens. Changelog 7/13/15 Fixed: JIP players now get fire support correctly Improved: Various improvements and fixes included in my latest framework

What exactly doesn't work? No units are moved or they're moved to the wrong building? The building distance is a little tricky, because buildings are detected from their center point. Even if the building appears to be within 10m of the group, the engine may not see it that way. In last line: [this, units group this, -1, false, false] execVM "Zen_OccupyHouse.sqf" the -1 will tell the script to use nearestBuilding, so it's guaranteed to find a building. This is better for filling just one building. The large office buildings (like in Kavala) are working; I use those to test the roof placement. However, it seems to not work with an airport control tower; nearestBuilding picks the next building away from that. nearestObjects is getting that building, as well as some airport lights (apparently those are a type of house). It looks like nearestBuilding misses some buildings, but nearestObjects detects some things that are not proper buildings.

1. I see how that could be confusing...I'll fix that typo. 2. They should appear 50% of the time (2 possible types of each scope). Since the mission has an approach part and an urban part, having some close ranges sights makes sense. The sniper should be the one providing long-range fire. I prefer to makes some things random rather than let players choose because it makes the mission harder and forces players to adapt. 3. This is a known bug and there's nothing I can do about it. The AI isn't correctly affected by vehicle seat assignments as they used to be. I'm waiting for BIS to fix the 'assignAs*' commands. I also cannot prevent the helicopter from landing once the group leader gives the order. 4. I know the action menu can be annoying; I used to use the communication menu for the supports. Unfortunately, that menu has some technical issues with locality and AI units that make the action menu a better choice from the scripting side. A cancel action is possible, I'll work on adding that in the future. 5. No gear as in naked or the default loadout for their role? If they're in the helicopter, the loadout code is running for them. I'll try to reproduce this. I strongly agree with this and except for a few marksman and sniper roles (and with VAS in Abduction), the missions give non-magnifying scopes. I also like to give SMGs or even just pistols to encourage tactics and good positioning over just shooting everything. Good scopes really give players a big advantage in range, accuracy, and spotting ability over the AI. It makes the AI look stupid if they can't hit something at 500m like the players can, but IRL that would be an amazingly good shot in combat (5.56 NATO maximum effective point shooting range is 500m). In Sweep, as I said above, there's a 50% chance of a scope appearing for the assault loadouts (except the automatic rifleman). Since the mission already has a sniper, I don't think it hurts the balance too much. The urban area, Opfor vehicles, etc. offset the advantage against infantry.

The first 5 parameters are required; only the last two are not. So you'd need something like: null = [this, units group this, -1, false, false] execVM "Zen_OccupyHouse.sqf"; They are intentionally required so that the user makes a decision about the argument and is aware of what it does, rather than accepting whatever default value I put there. The last two are only optional because I don't want to break people's code after nearly 1 year if they get the new version just for the optimizations.

Overview Greetings fellow Armaholics, a new mission, Co-6 Shootout, enters the pack this week. It's aimed at providing some fun and relaxation with a simple fire-fight. Due to some great user feedback (thanks to Cyprus), Sweep has gotten some major improvements, including a spotter who has access to a UAV and an airstrike. The loadouts have been tweaked and Opfor in buildings should act a little less dumb. Abduction, Specter, and Sweep also received a medic role. Be aware, if the medic picks a different loadout, they won't have any medical equipment. This is especially important for Abduction; the other missions will provide the correct loadout as the default to the medic. Blackout should be more challenging once the players are detected; unfortantely, the flares are currently very wimpy. I'm going to try to find some better flares for next release. Changelog 7/10/15 New Mission: Co-6 Shootout Abduction Improved: One player role changed to medic [*] Blackout Improved: Opfor now use flares if the players are detected [*] Specter Added: Medic loadout Improved: One player role changed to medic [*] Sweep Fixed: Increased damage did not apply to all units Added: Spotter playable role Added: Team leader and medic loadouts Improved: Civilians killed by the Opfor do not count against players Improved: Insertion helicopter will avoid flying over the town Improved: One player role changed to medic Improved: Opfor in houses now patrol their building and the street outside Removed: Enemy markers Tweaked: Insertion helicopter cargo Tweaked: Loadout equipment Feedback Civilians are actually on the resistance side; otherwise they run away and just lie on the ground. I want them to ignore the combat and walk around like nothing is happening; it makes it more of a challenge not to kill them (you can't just shoot anything that moves). ArmA does not come anywhere close to simulating real body armor. IRL a level IV vest will stop dozens of 5.56/6.5/7.62 FMJ rounds (so long as the steel plate is hit); the soldier will experience minor bruising, discomfort, etc. but will remain combat-effective. In ArmA, it just decreases the overall damage done to the unit, so it takes 5-6 shots to kill them instead of 2-3. IRL casualties are caused mostly by rounds not hitting the armor, IEDs, grenades, etc. Also, taking e.g. 50% damage doesn't reduce combat effectiveness in a meaningful way (especially for AI); they can take multiple rounds and return fire instantly. You could say that adrenaline plays a large part (which it does, especially in CQB), but soldiers caught off-guard can't just spin around and return accurate fire (IRL anyone would sprint to cover even if they weren't hit). It's a combination of unrealistic AI and poor wounding simulation. I prefer the old-school tactical shooter (original Ghost Recon, old Rainbow Six, etc.) 1-2 shot kills (even to the arm or leg). Simulating being unable to move and shoot as being dead in-game is fine; it's much more realistic than letting that soldier operate at 90% effectiveness. The maximum view distance is just controlled by some SQF commands, setViewDistance, setObjectViewDistance, and setShadowDistance. I use my function, Zen_SetViewDistance, to set that to the same value on all clients. All the missions in this pack are at 4000 view and object distance; you can set it lower than that in the options menu (higher values have no effect).

Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the links to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog In case you didn't know, today is the framework's 1 year release anniversary (it also happens to be Nikola Tesla's birthday). As an updated accounting, there have been 561 total changes since public release, which have brought us to 184 public functions and 87 preprocessor macros; all of this is done by about 14300 lines of code (including blank lines). It's been a lot of fun working on the framework, and I'm confident the future holds more interesting things for it. Unfortantely, I do not have any massive, awe-inspiring new features to deliver in this release, but I can offer several new function and improvements. The largest change is actually internal; the fire support actions system has been rewritten with server and client data (in the style of the task system). The functions themselves have changed very little (just Zen_UpdateFireSupportAction has some new parameters), but now fire support actions are handled very differently. The actions are assigned a random string identifier (like tasks, custom loadouts, etc.) that will be used to refer to them. This string ID is different that a fire support template ID; mixing them up will result in errors. You can update and remove the data of this action more easily now. For example, it's now possible to change the fire support template that is called by the action. All of this greatly helps with JIP, the demonstration of which has been properly updated. Amidst various reports of issues with Zen_MoveInVehicle (which I still cannot reproduce), the function has been completely rewritten. The function now assigns seats to the units before attempt to put them in and is more patient if it takes longer for high ping clients to respond. The new Zen_MoveInVehicle also used the code in Zen_GetFreeSeats, so I made that a new public function. Thanks to a user request, the new function Zen_GetCurrentTask will return the task that any object has selected. This lets your mission respond based upon which task players have selected as current. Zen_ArrayGetRandom can now remove the element it selected; this is similar to Zen_ArrayGetRandomSequence's remove parameter, but it is more efficient for just one element. Zen_FindValidDirection had a slight error in its math, which could allow a few angles that crossed the avoided area. 7/10/15 Feedback As m0nkey said, the number after the marker name means the minimum distance from the center of the marker (in your code points must be more than 250 meters away). If the marker is smaller than 250 meters, there are no possible points. An area marker is interpreted as its true geometric shape, while a point or object requires a distance because it's not already an area. If you have e.g. 10 markers (named sequentially like "mkArea0", "mkArea1", etc.) and you want to do something in e.g. 6 of them, you can get those 6 at random and them iterate over them: _markers = []; for "_i" from 0 to 9 do { _markers pushBack ("mkArea" + str _i); }; _selectedMarkers = [_markers, 6] call Zen_ArrayGetRandomSequence; { _pos = [_x] call Zen_FindGroundPosition; // etc... } forEach _selectedMarkers;

Can you post or PM me the arguments used and the full text of the error? The script does not check its arguments for the correct type or format, so giving the wrong thing will result in errors.

After someone reported that the AI can move when in combat (danger.fsm I'm guessing), I added 'forceSpeed 0' on the unit. disableAI 'Move' is also an option, but forceSpeed seems a little less severe. disableAI 'FSM' will make them stupid, so it's a last resort.

It's all good, we're both just trying to help folks make missions. The world size preset is only used if you don't give an area to calculate the position within (or enter 0 for that argument). No valid position means one or more of the filters (arguments 3 to 12) cannot be satisfied. To check that the function works, just put down an area marker (I'm calling it 'mkTestArea') and give only that as an argument: // in the init.sqf _pos = ["mkTestArea"] call Zen_FindGroundPosition; player sideChat str _pos; Can you post the full call to Zen_FindGroundPosition? Unfortantely, it's quite possible to make a logical error with the argument that can never return a valid position. It's not possible for a function to always ensure its arguments make sense.

That's why I have to test ACE and maybe even look at its source code. For example, does it add medical equipment automatically (what if I overwrite a loadout), is there a conflict between the code, etc. The AI in buildings is to prevent the sniper from completing the mission alone. I could make them patrol the buildings or use my occupy house script to put them at windows; that might make things more interesting. Removing the fake UAV in favor of a spotter with a real UAV seems like the best solution. The fake UAV is just to give the players some help, since they're outnumbered 5 to 1 in an urban area. I can make it so civilian kills only count against the players (or their fire support) did it. The Opfor probably do kill some civilians with their vehicles, grenades, etc. I've been trying to fix the helicopter landing for a long time, by getting them to touch down and keep the engines on. There's always a chance that they'll move while players (especially if the player commands an AI group) get out. I'd rather have them take 30 seconds longer than have insertions fail some the time. In Blackout, constant randomly placed flares after detection is a great idea. The two teams are to encourage the players to do the objectives simultaneously, rather than just crowd one. I intend for the two-man teams to just work with their partners. Increased weapon damage is done by a handle damage eventhandler. It works well, but reduces compatibilty with medical/revive addons (they use same EH). The other solution to this is making an addon to adjust ammo config damage values, but that won't work with ammo from other addons. That last option is to include those config changes within the mission itself, which would only be an issue in Abduction (addon weapons can be chosen in VA). The dedicated server accuracy is an issue because missions depend upon a certain AI skill and precision level (in profile) for balance. If the mission make is playing at e.g. 0.5 AI precision, but the server is at 0.8, the AI are now much more accurate. My server and user profiles have: aiLevelPreset=3; skillAI=1; precisionAI=0.5; The best values are AI skill 1 and AI precision 0.5; those give the true values the mission maker set. Anything else will apply an equation to scale the true skill (skillFinal). I don't know if BIS has changed the current defaults or preset value since the date of the post you linked.

I could just have the sniper pick between loadouts; same for the assault team. I can also put in some heavier vests with a different chance of appearing for certain loadouts. I didn't include a spotter because a lot of what they do IRL isn't applicable to a game. They calculate the scope adjustments for every shot based upon range, elevation, temperature, humidity, etc.; ArmA doesn't even have wind deflection. Even the role of providing extra firepower to protect the sniper (as in Vendetta) is reduced because the assault team is there. It just seems to me that the spotter would bored because an experienced ArmA player can be a sniper alone. I'll think about it though; if I can give the spotter something interesting to do (call in fire support, mark enemies on the map), the added element of teamwork will make this mission more fun. I hesitate to commit to a medical system and say the mission requires it; it seems like that would reduce the potential player base. A script-based solution is limited because it cannot add new objects like an addon can (bandages, tourniquets, morphine, etc.). I'll look at the different medical system mods that are available and see if the mission works with them. Supporting both vanilla and a realism mod like ACE with the same mission would be ideal.

Summary Greetings fellow scripters. Due to some user feedback and contributions, I am able to add some new features. Thanks to JohnnyBoy, the AI will now take cover when fired upon; all credit goes to him for this feature. I've also added a parameter to make the AI move to their positions. Unfortunately, this does not always work perfectly due to AI pathfinding. Also, when filling multiple buildings, the order they are filled is now random. Finally, I've made a few more slight optimizations to the code. The new version is already hosted on Google Drive, and will be on Armaholic soon. All relevant sections of the original post have been updated. Changelog 7/6/15 Added: AI now take cover when fired upon (credit to JohnnyBoy) Added: Parameter to order the AI to move to their position Improved: The order of buildings filled is now random Improved: A few minor optimizations

Thanks, this is a great addition. I'll include your code and credit you for the next release (which is in probably 1 or 2 days). As the script is just a single SQF file, I'll have to put your code into the eventhandler directly.

I can add better optics for the assault team with a 50%, 30%, etc. chance of getting a magnified optic. A different loadout for the squad leader also makes sense with a rangefinder and smoke. I can also put things in the helicopter for players to choose from. The Mk18 (and M14 and others, if the sniper has Marksman DLC), are there for variety and to let the sniper use slightly different tactics. For example, using semi-auto fire from 500m at 4 Opfor lined up in a street is very effective. IRL the Mk14 is effective to about 700-800m (against a stationary, exposed target). I'm aware that ArmA's lack of realistic scope adjustments can be an issue, but the sniper can still stay out of range of the Opfor using this rifle. It also depends upon the terrain and layout of the town; some will force closer range shots from certain angles. I'm encouraging the sniper to use the strengths of his weapon. If you really can't stand this rifle, you can un-pbo the mission and replace the 'Sniper' loadout in CustomLoadouts.sqf with: I have complete control over the insertion direction. I'll add some code to make sure the helicopter doesn't cross the town on approach. A medic is good idea for some of the other missions as well. I just dislike the arcade medical system in vanilla ArmA; it feels more realistic to me to have no system at all than that one. If it was entirely up to me, I'd remove the first aid kits too. However, I'm aware that most players wouldn't find that very fun. The difference is only between 80% and 100% health after heal, so I'll add a medic slot and equipment next release.