MDCCLXXVI

The side mission structure is designed for modular insertion of your own. When built there was expectation that communities would do just this, but sadly not many have taken the time to develop new side missions. The structure is reasonably laid out for the side missions in the actual scripts. For the basic "go here and destroy something" type, here is a basic guide: 0. Select location for the mission. Could be completely random or have geographic requirements (IE repeaters on hilltops, boats near water, etc) 1. Create the objective and any set-pieces, any other non-critical structures and decorations. 2. Create some guards/security for the objective. 3. Brief the players ... hints, notifications, chat messages, map markers, etc. 4. Set some variables that you'll need. (pre loop) 5. Monitor the variables and wait. (this is the evaluation loop) 6. After the mission is done, depending on the variable it will be success or fail. 7. Depending on #6, de-brief the players accordingly using existing structures. 8. Clean up time. Wait a few minutes (5-10 is best) for the players to depart the area and then remove all traces of the fight, to save FPS for the next battle. --- Some are more complicated than others, for instance the secureIntelX ones are slightly more complex, that just means there are more #4 and #5, with some behavior and logic scripted into the loop using common 'if then' structure. For more complex ones, on a public server learning from experience, the briefing and player awareness of what they are supposed to do and where that is supposed to happen, is more important than I had previously thought. Good luck and happy scripting.

The current safezone system was designed for performance, not flexibility. Over the long time that I&A has been running on public server, I found there was never a need for the flexibility of multiple safe zones, and of course this flexibility = more evaluations = less client FPS ultimately. So, over time this flexibility was stripped out to help increase the client FPS. You can build in the flexibility but I would say it may be difficult and would be a 1hr job for someone who knows what they're doing with the code.

The above issue will occur if the parameters (params_x) are not compiled properly for the client prior to running the code. Should be a line at the top of initPlayerLocal.sqf which compileFinal's the paramsArray from description.ext (missionConfigFile). If this is not being loaded on the client prior to any code which relies on paramsArray, you'll get a stack of errors similar to the above.

Ill take the blame ... Disabled 'no grass' long long ago, then after reports that the button was broken, I removed the button as well. Since then I can count the complaints I've heard about No-Grass on two hands. Simply put, IMO no-grass is unsportsmanlike in any game mode, even against AI. You may think COOP is not competitive, however if you are prone next to someone, both firing at the same target, the one with grass disabled has a much better chance of connecting with the target, and more safe too as they can shoot with less body exposed due to not having to fire through grass. Thus 'race to the bottom' occurs and you end up with everyone running 'No grass' to get their share of the action. Around the time I removed the button, I monitored everyones terrain setting on the server for awhile to see if/when they were using grass/no grass. Invariably, people would set up on a hill, go prone, then disable grass to start shooting. It's an 'easy mode' feature that sounds nice but when everyone has this 'easy mode' button just 2 clicks away, sadly it becomes the norm as it is easy to use and when the chips are down, it got used. For the same reason that a long time ago Rarek decided 40 players shouldnt be running around as rambo elite Sniper/AT beasts (most do if they are able to), I decided there should be at least some standard for difficulty in firing and choosing a firing position. Taking it off the action menu was a matter of performance and streamlining the action menu. Having it on the action menu consumes more resources than you'd think, and it also doesn't belong on the action menu. Would be better on a GUI interface, but never bothered to create the interfaces. Re performance, you'd have 50-60+ FPS if few/no AI in the session, regardless of your grass setting. Beside the FPS drag caused by AI, many other performance considerations--especially client-side ones--are naval gazing, consuming a lot of time/stress/thought/effort, with little to nil performance gain. cliffs: - grass has almost no effect on performance in I&A, compared to AI. - having grass on levels the small arms 'lay on a hilltop' tactic playing field. It's already extremely low-risk tactic, so at least the guy beside you is playing by the same rules and can't lay a few meters back exposing far less of himself, while having a better field of view. - Its a fallacy that AI can see through grass. They just notice small details (pixels) better than players. They are affected by grass and bushes, whatever claims are made to the contrary . On the other hand, they don't have Nightstalkers and generally don't shoot Katiba from 700m as players do. They also can't grab a quick resurrection from their buddy after you kill them. Just my two cents, I think your opinion is entirely legitimate and probably one held by many (dare I say, majority?). Unfortunately for you, I&A was developed for a time by someone who sought to make the scenario more difficult for you (and all players equally) in many small ways, and to remove easy crutches, and nudge the gameplay toward requiring cooperation, and making one-man-army play less rewarding ... for good or worse ... As for re-implementing a grass setting ... Its easier to pulll the existing system out and drop in a newer version, than to revert the current. That and the decision to (or not to) is up to Master Bacon. As for the menu not being on the pilot VAS, that was simply oversight. An update was rushed out at one point and that was simply forgotten in the chaos. -- Now a question for you ... Since according to you I&A not competitive .. How come 80% of players run around with: Nightstalkers instead of RCO... Titan AT instead of PCML ... Mk18 instead of MX ... Zafir 7.62 LMG instead of MX SW ... Carryall instead of Assault Pack ... Is that pure preference, or is there some other consideration?

great guide bacon!

In my opinion that is too much. I'd just mention Rarek [AW] on the loading screen and then in the code/diary tab mention the others.

PMed. The gamemode and initial creative design are all Jack Williams [Rareks] work, with inspiration from earlier Domination gamemodes (such as Xeno A2 domination). AW is the core I&A community, though most of my part in the development occurred on the backs of an Australian community (allfps.com.au) which I am no longer affiliated with as of June. If familiar with development process, it is the players and community that bear the brunt of development, and do all the play-testing and endure all the ups and downs. I feel it is important that you mention Jack Williams is the primary author above all, and at least provide a general mention for the AW and allFPS communities for aiding and being there through thick and thin of the dev process. Without the players, none of it is possible and there would only be broken scenario. Also a mention for AW core staff for keeping I&A as a friendly experience for players and other editing communities alike, that is no easy feat. I do not need a mention, though it is up to you. If you are going to have my name there, please de-couple it from any mention of allFPS, I am not associated with them for 6 months JMO ... As for the loading screen image and text. Most communities like to personalize this stuff and edit the author line. I suppose it is frowned upon, although I blame BIS for not taking better care of server owners/communities on that loading screen. There should be a line like the author line, except for server/community admins and staff. Its a lot of work to maintain a mission and understandably everyone wants their stuff up front haha. That loading screen is a single player loading screen, not suited for the multiplayer ecosystem of content creators, server owners, and mission editors/modders. All deserve some credit for what the player experiences after the loading screen. Ahh well.

Yes I'm not sure what the issue is with UAV unable to re-arm. That was never the intention. The expectation was that the UAV would spawn dry (no bombs), and the operator would arm them and then take off. There are no issues with the code, it seems doing this inadvertently stumbled across another issue (cant rearm a remote vehicle unless its weapons start with full ammo?) that would be best swept under the rug by restoring how it was previously It's a 30 second fix, but you'll have to find staff who want to spend time sorting it out! I personally like players having to fight for what they have and wouldn't give unchallenged air superiority to NATO willingly. It was expected that the CAS pilot will have to manage his CAS missions and also providing route security for the frogmen in the helicopters. Nothing is up to me, you'll have to talk to BACON or Raz about it. Re the third UAV ... I dont think The Defense Committee is prepared to increase the budget for the combat operations occurring on Altis, there is public sentiment that the war seems to be endless and only to enrich those who manufacture and produce vehicles. The civilian death toll has also a contributing political factor and sadly I doubt funding will be approved for a third UAV asset. An appeal to the Defense Secretary may yield fruit, however.

1. Some work was done on our end awhile ago to ahem, make them a little more feisty and make more use of the open sky, and BACON did lower the accuracy slightly. 2. Soldiers will usually receive a jet as an AO reward, as you said it can be used to good effect against enemy jets. 3. The CAS spawning regime was changed to optimize and improve the AI skill and decision making, but there is a mistake in the code allowing one (just one) to spawn after the radio tower has been destroyed. 4. The effectiveness of AI jets is something that warrants discussion by those interested. I like their effective cannon but dislike their AA missiles, especially after 1.34 update now Helo pilots cannot see the vector of incoming missile, to best avoid and land their soldiers safely. Without the AA missiles, however, they present little threat to NATO air traffic and lower that element of risk from air travel. Some things to ask, for annex and in whatever scenario such type of enemy CAS is utilized: - How should it re-arm, given limitations of AI? Should it land somewhere? Should it disappear for a time? Should they be active for a few minutes and then head back to the mainland? In effect, NATO has unlimited helicopters, should the AI jets be limited to just two AA missiles (or 4 for the AA buzzard)? - Should there be a cap on the total number per AO, or an adjustment of the delay between spawns? Should only one spawn? Usually jets do not operate solo but in pairs at least. There are never more than two at once currently unless curators are creating more. At the moment there is a certain robustness to prevent exploitation as was possible a long time ago against the jets. Now they hunt, and often in pairs, preying on the vulnerable helicopters. The new script has not had any rebalancing or tweaking aside from Bacon adjusting the accuracy/skill. 5. Do players have the capacity to adapt and respond given the tools provided, or should more script regulations be put in place to compensate for inability to adapt? I see players dedicating themselves to AT or medic, pilot or repair, but rarely see a player dedicate themselves to AA unless in the jet. 6. I do not know why a curator often blocks off the CAS jet, that was never the intention, especially givin the virility of the enemy jets. They may have good reasons though, who knows. 7. The CAS was indeed stripped of its ATGM due to unrelenting abuse and unsportsmanlike temptations. CAS was never overpowered, just the E-Z-Lock ATGM are. The bombs and cannon provide good combined arms experiences. 8. Will see about the UAVs. If you want the exploding issue addressed, vote here: http://feedback.arma3.com/view.php?id=21685 The UAV armament issue is my fault. The weapons are stripped from it when it spawns, as I had thought for a time the bombs were the cause of the explosion. Nope! Regarding UAVs, if there is interest in having them spawn in midair and just circle the base, that could be done to prevent the explosion issue, although they would be shot down and attacked far more often by enemy CAS.

As you might know, there are some... ahem ... Issues with the UAVs at the moment. The root of the issues is a BIS bug, and then there are some attempted fixes that didn't go so well and made it worse! As a result I decided to finally report the issue. http://feedback.arma3.com/view.php?id=21685 Up-vote please!!! Supporting vid: also posted here: http://forums.bistudio.com/showthread.php?168197-UAVs-Feedback-and-wishes/page20

http://feedback.arma3.com/view.php?id=21563&nbn=3 I for one support the adjustment, thought the magic radar was a bit cheap and easy-mode feature. It is still in place on the aircraft that have guided weapon systems, however. I think the better solution would have been to allow scenario designers the ability to manipulate this display, to determine which vehicles have magic radar, and when.

Warning: Wall of Text below!!! Sorry this is my fault, however I think BACONMOP has already published and uploaded the fix for it. The reason for the issue: During some of the development, the file related to UAV re-arm was not synced with the mission file. Result was no UAV re-arm-ability. Also the 'spawning without ammunition' was intended, for two reasons. 1. Stops the UGV Stomper from cutting loose at spawn sometimes and engaging friendy helicopters if the pilot had, say, performed a hard landing and injured friendly passengers. So the UAV Operator must manually and consciously arm the UGV Stomper. That was part of some 'vehicle responsibility' tweaks, along with the Turret Control for pilots of the turret-equipped helicopters.(credit baconmop for including the new Huron helicopter into it. was coded specifically for the ghosthawk) Basically coding in an element of "if you are the effective commander of the vehicle then any damage done is definitely your responsibility". 2. This is the real reason. An attempt at preventing UAV spontaneous explosion when UAV Operator connects to the Driver. A theory which wanted to test in MP was that perhaps when the UAV Operator connected to it, it 'spooked' the UAV into soiling itself via dropping its bombs, causing big boom. So perhaps removing its weapons on spawn would have mitigated this. NOPE! A failed attempt, but that was the reasoning. So that theory has been put to rest and now there is only one rational explanation for exploding UAVs. When a UAV Operator connects to the UAV Driver, if the UAV is local to the server (network). It gets briefly set to Position At Sea Level when the locality is transferred to the UAV Operator. Of course Sea Level is below ground (approx 17 meters below dirt at the airbase), so there is a collision between the ground and the UAV, and an explosion is usually the result. This is a Bohemia bug which they refuse to acknowledge, and I informed them of it almost a year ago. So don't expect that to change or be fixed. Basically in the engine code somewhere is a reference to Sea Level which they have to change to Terrain Level. The one way to bypass that crap is to spawn it in flight, orbiting the airfield. If that is agreeable, then it can be implemented without much trouble. It will get shot down often, crash often and collide with player vehicles sometimes, but that is the trade-off.

IMO that would be best implemented on-demand-and-when-appropriate by an admin/curator working alongside the person who is streaming/recording, to set them as side civilian and provide them the Journalist uniform and civilian assets (heli, car, etc)

should be fixed on EU1

This issue has been resolved for next I&A version. BIS changed some global marker stuff in the 1.32 update, which caused changes to global markers to not sync themselves between server and clients. When you first join the game, the server will send you the correct information on the marker. When the server updates the marker while you are ingame, it no longer sends the correct information to you on its own. Needs a little scripting nudge to send you the correct marker data. Naturally, had to go and fix what BIS broke . Behind the scenes: (with respect to global markers) setMarkerPos = still global setMarkerAlpha = still global setMarkerColor = still global setMarkerText = not global anymore, so we have to synchronize it with a publicVariable now. For what its worth, the sling has also been fixed for next version. However it is moot at this point due to BIS sling loading coming. However, there is a very real chance that BIS sling loading won't work/be buggy as hell for some time, so its handy to have a working spare! As far as performance, there is always a balance. Too many enemies = horrible FPS. Too few enemies = boring experience. When I was actively administrating/developing on one server, I used time as a yardstick, and aimed for AOs to take around 45 mins. to complete.

As the guys have said, there are a couple reasons. 1. Its uniquely Rareks version of the Domination gamemode. His choice to make, and his to submit. 2. Even he could not simply submit the current version of I&A in MANW, since there is just too much 3rd party content. Some time ago I added the Credits tab on the map as a courtesy to all the coders work who have gone into it. Press M, look left side, "Credits" tab, in which is a list of people who have made not insignificant contributions. For instance, the Vehicle Respawn system as of 2.79D is Tophe's work, not Jacks. The Group manager, that is aerosons work. View distance and VAS? Tonics work. Defend sequence and urban mission enemy spawning? Bangabob's work. Revive medical system? Author is Giallustio of Black Templars Clan. Not to mention the not-insignificant contributions by AW members. I think you would have to go back to a Stratis Beta version to find a version that only Rarek worked on, and even then he'd have to have removed the third party content before making a legitimate submission. It is unfortunate as I would like to see co-op or more milsim oriented missions contending in the contenst, and I think BIS would like to see those gamemodes as well, rather than Altis Life, Wasteland, A3L etc. simply because it is more in the spirit of the sim and actually showcases a lot of the work BIS put into the game. There are very very few other gamemodes where the BIS devs can see much of their work in action by 50+ players. Having spoken on and off to a couple BI devs in past few months, when they push AI changes onto Stable branch, they use I&A servers to assess the results. As for the MANW multiplayer gamemode winner(s)... I am confident from what I've seen that they will be well coded missions that no one will play unless some marketing massaging is done, aside from a few exceptions (KOTH).

They do obstruct map markers, that is an acknowledged reality of using Icons instead of Markers. They appear on a layer above markers, so a marker can be completely obscured if there are enough icons over it. http://www.armaholic.com/page.php?id=26993 Putting in a system where the player has some control over what is shown, depending on what information they require. Right now that script is still just a stable release build, with no added controls or complexity. It will get more advanced as time goes. In development version the code is in place to hide names and classes, but working on making it all GUI friendly. I have no idea what you mean by 'symbols'. At the end of the day, if you don't like something, change it on your copy and play on your server where you are in 100% control of the scripts Coming onto a community forum and acting snarky in your first post isn't the best delivery system for your--IMO--valid point.

Just a note, as of 2.79D there should be no more significant issues with revive gear. If you encounter any issues let BACONMOP know, and here is the BI forum thread with the currently (2.79) hosted BTC Revive working version. http://forums.bistudio.com/showthread.php?184298-BTC-Revive-working-version-code-dump

Back when static autonomous turrets were first introduce I set out to find out how effective a teamkilling/trolling tool they were. Shortly after, I reported the issue to Jester. Don't worry, it was on a different server

I come bearing gifts Have been sitting on this bit of code for the past couple months, thought I'd wrap it up and release it. It should be seamless integration with I&A. Will replace the existing player markers code, with reasonable increase in performance and versatility. http://www.armaholic.com/page.php?id=26994 http://forums.bistudio.com/showthread.php?184108-Soldier-Tracker-(-Map-and-GPS-Icons-) cheers

I think first you have to tell us what version you are using For instance, in the AW hosted version and all 2.75/2.76/2.77/2.78/2.79 versions, there is already a prototype implementation of that. 3-4 AOs will spawn in the same region before cycling to the next region. This cuts down on the amount of cross-island road trips. As for distance from base ... At the time, it had been a plan (never implemented) to always cycle through the close region (Central Altis) first, after server restart, to build momentum while players are still sorting themselves into squads and settling into their roles. If someone is prodding at the code, that is a low-hanging fruit for something to slightly improve gameplay. Be careful with the JSOC fork. They have a pretty bad .RPT error spam due to altering some code with respect to the Virtual Arsenal, and there is a noticeable performance hit as a result. .. Re restrictions ... It comes up now and then on the forums re restricting player equipment. Be careful with this, if you do want to gain/retain players on your server . If it was implemented in 2013 then there would be less resistance to it, but now many players have grown accustomed to their gear, and would feel simple gear restrictions as being arbitrary and annoying. Just slapping on a "you cant use this because I said so" weapon restriction is too much Stick and not enough Carrot at this point in time. re Thermals ... The gameplay would undoubtedly be more satisfying if TIE was not in the mission, however restricting this in Oct 2014 is subject to the above comment. If you want to reduce the effects of TI on the battlefield, there is a subtle and simple tweak you can make. Set the month to December, rather than July. Thermal Imaging contrast is horrible when month is set to December. However, again careful, because the regulars users will notice and not be happy

The Islamic forces of CSAT are up in arms about the billboards, and attacks on the airbase will be re-doubled!

That is quite an old code base (a february build I think) you are working with, I would suggest either one of the later 2.75 builds or AW 2.77 build. IIRC that one you have was released during the re-structure, and there were still some scripts that were not properly partitioned between server and player. As for credit, do your best to leave Rarek and Ahoyworld with primary credits. I have made mistakes from time to time myself and always regret it when looking back. At the least, if you code something and it is inspired by the work of another, reference them in your work and since the I&A 2 design belongs to AW, even if you re-code it, the mission idea should still be credited to them.

I have tried to nudge a little more toward milsim and realism, without introducing some of the tedium and boredom that is associated with that reality. I do enjoy servers were co-operation is encourage, but I have joined some servers where I get banned for driving a hunter out of the parking lot . I think as ArmA 3 ages, the market for certain types of game-play will vary. Most 'gamers' won't stick around for the long haul with A3 (i know I sure wouldn't if I was), while mil-sim communities seem to have good staying power and last for years in flourishing communities. As the game ages, those who treat ArmA as just another video game, are melting away. AW is great community, is blessed with great staff. I have seen many communities fall apart due to abuse of the community/playerbase by staff, so be thankful!

Nice guide! One note I'd like to make: The 'Cycle UAV Crew' actoin is only visible to UAV Operator, so don't ask someone else to perform that service if you are deployed in the field. You must do it. alganthe, If you would like, write up a nice clear little guide (100 words) and submit to danne for inclusion in next hosted version. IIRC there is a UAV tab in the map diary, that you can point players to. The tips there are quite dated and never received proper formatting and not as clear as they could be. Was written when still learning about the problem For build I am working on, have deleted the contents of that UAV tab so it needs filling again, and if you would like to prepare and also put that 'alganthe' has written the guide. One question I have, why do you have to kill yourself after you cycle in new UAV crews? I am trying to streamline the process as much as possible. Have fixed the issue of UAVs spawning dead, but will leave that Cycle UAV Crew button in until it is no longer used. Have also addressed (too soon to pronounce it fixed) the issue of UAVs blowing up when connected-to. Just want to be aware of any issues originating from the UAV Operator rather than the UAV itself. edit: the decision to limit the Cycle UAV Crews action to UAV Operator only was to prevent trolling of the button. I suppose a UAV operator can still troll himself with it though And as you say, UAVs tend to troll the operator quite enough.