soccerboy

Support System Package: Artillery [1.04] i've created this so i can edit and request artillery support during gameplay in a very dynamic way. Features in 1.10: -A fully functional GUI interface to customize an artillery fire mission during gameplay. -you can chose which battery you wish to shoot. -you can define [Mission type - Round Type - Rate of Fire - Number of Rounds]. -you can also define the dispersion field of the artillery. -you can pre-register fire mission to be executed by the artillery and start shooting much quicker than not pre-registering the mission. -you can set your target by either map clicking or with the help of your laser designator. -A working diagnosis system that if any of the initialization scripts run into an error it'll trigger and show you which script and if possible give you an error report. -Ammo Limitation of each ammo type. (once an ammo type has been depleted you can use the others until the battery is resupplied. the user can adjust the time for resupply or disable it all together in the options.sqf) -M270 MLRS Tracking Marker Option. Basically means if you use the high command module then the marker will follow the M270 around when it moves (you can enable this in options.sqf) the bellow has most probably been identified and eliminated as a bug/problem. Urgent Notice: during my testing i've noticed that 1 of my 3 coop missions seem to not work properly on a dedicated server. it doesn't reset the variables for shot,rounds complete and splash radio commands so they get spammed during the next fire mission. it works fine on singleplayer and non-dedicated server play should work aswell. i'm still working on a way to fix it but i already tried everything. that mission is running the same package as the others and i've recreated it 3 times and always differently. i couldn't fully test non-dedicated multiplayer because i have no one to test it out with, so if anybody would be so kind and test that out for me i would very grateful. i've noted any bugs into the readme. i hope you guys won't run into any serious bugs. if so please let me know and if possible even with the error report. Future Additions: Graphical User Interface: Coming to 1.10. PvP Support: Postponed. Virtual Artillery: Postponed. Custom Audio dialog: TBD. [script Version] Download V1.04 Hotfix1: Rapidshare Armaholic Download V1.10: (Coming Soon) [Addon Version] Download V1.10: (Coming Soon) any feedback or support from either scripting or otherwise would be appreciated. i'm not a professional scripter so please forgive me if it doesn't look professional. if you have any questions i will do my best to answer them to my knowledge. Currently working on: re-writing the bulk of the scripts to feel more realistic current todo list in correct priority order: Experimenting with FSM files to build a more believable FDC intelligence and if that works i'll be building an AI FSM for AI groups to call artillery on enemy contacts - 0% done teach FDC to tell the battery to optimally use illumination based on burning time - 0% done Construct the proper radio protocol - 30% done reconstruct: target setting, - 100% done firing, - 100% done server detection and client options scripts - 100% done update the functions and remove those not necessary - 50% done clean up old scripts of things that aren't needed - 50% done build new ammo limitation and deduction method with the eventhandlers - 0% done note: this list is updated regularly and things will be added as i don't know everything off of the top of my head. Changelog: Current V1.11 Added: GUI interface Added: X and Y correction areas in the GUI so that you're not punished for setting the marker wrong and having to wait forever for re-registration. [*]Added: Random fire mission solution error (the target impact zone is not 100% accurate anymore) [*]Added: Set your target with real map GRID coordinates [*]Added: Initialization Diagnostic system in the event of an error in any of the initialization scripts you can see which one failed and a possible error report is displayed. [*]Added: Functions to change certain options during gameplay for mission makers to be used for triggers, and to add a radio or laser designator automatically without fighting with commands like addweapon/removeweapon. [*]Added: JIP (Join in Progress) compatibility. when a user comes in fresh and the variables are undefined then the client will request an update from the server (i hope this will work) [*]Added: Compatibility for the ACE2 Radio Equipment. [*]Added: Ability to request artillery from inside or within 3m of a vehicle (HMMWV or MTRV). if you're inside or near a vehicle then you don't need the ACE radio if ACE mode is active. [*]Added: Option to define how many times the battery gets resupplied during a mission (battery won't be supplied until a certain amount of rounds have been fired already) [*]Added: Completely reworked Radio Dialogs. [*]Added: Every so often (time still unknown) you have to authenticate your request. example: Challenge: Alpha November. Response: Oscar. [*]Added: Various types of GUI Options for: "Number of Guns","Method of Control","Mission Types","Volleys","FDC","Target Designation Type","Mission Number", etc. [*]Changed: Structure of the scripts to be more generic to reduce calculation errors. [*]Changed: The menu item will now display if you can or can't use the GUI dialog, inability to use the dialog will be marked with a (Radio) tag. [*]Fixed: The Dispersion values should be used correctly now. [*]Fixed: Detection issue that could cause an error to the system. [*]Removed: Radio Sounds for Custom ones to be added later Postponed V1.10 Added: GUI interface Added: X and Y correction areas in the GUI so that you're not punished for setting the marker wrong and having to wait forever for re-registration. Added: Spot Round Ability to the GUI interface to have the battery fire a spot round without the need to change the number of rounds in the interface. [*]Added: Random fire mission solution error (the target impact zone is not 100% accurate anymore) [*]Added: Ability to set your target with either the traditional map clicking or with your laser designator. [*]Added: Pre-Registration option for less delay when calling in a fire mission. [*]Added: Initialization Diagnostic system in the event of an error in any of the initialization scripts you can see which one failed and a possible error report is displayed. [*]Added: Functions to change certain options during gameplay for mission makers to be used for triggers, and to add a radio or laser designator automatically without fighting with commands like addweapon/removeweapon. [*]Added: JIP (Join in Progress) compatibility. when a user comes in fresh and the variables are undefined then the client will request an update from the server (i hope this will work) [*]Added: Compatibility for the ACE2 Radio Equipment. [*]Added: Ability to request artillery from inside or within 3m of a vehicle (HMMWV or MTRV). if you're inside or near a vehicle then you don't need the ACE radio if ACE mode is active. [*]Added: Option to define how many times the battery gets resupplied during a mission (battery won't be supplied until a certain amount of rounds have been fired already) [*]Added: Support for the Virtual Artillery Modules [*]Added: Some additional radio text dialogs to the system to reflect different factors. [*]Added: East Artillery Batteries. [*]Changed: Structure of the scripts to be more generic to reduce calculation errors. [*]Changed: The menu item will now display if you can or can't use the GUI dialog, inability to use the dialog will be marked with a (Radio) tag. [*]Fixed: The Dispersion values should be used correctly now. [*]Fixed: Detection issue that could cause an error to the system. [*]Removed: Radio Sounds for Custom ones to be added later V1.04 Hotfix 1 Fixed: Dispersion values are now properly used. Changed: Dispersion values for M119 to 100m\200m\300m, M252 to 50m\100m\150m, M270 to 50m\100m\150m\200m\250m\300m. V1.04 Changed: Changed the format from SQS to SQF. Changed: Opened up the Artillery and Air Support to everybody with a first come first serve deployment Added: Option to turn off the Artillery for mission makers in the options.sqf Added: You can now either disable or enable respawn mode in the options.sqf for performace reasons. respawn mode is when the player respawns that he gets his menus back. Added: Option to limit the radio menu through execution of a script. Added: Auto Battery detection and classification through synchronization. Changed: Rate of Fire Menu chagned to Immediate\Fast\Semi-Fast\Slow which represent 0\1\2.5\5 Seconds. Changed: Mission Wording of Timed to Suppression. Changed: Duration Menu is dynamic now depending on which mission mode you're in. in Suppression the options are Short\Medium\Long\Very long which represent 10\15\25\35 Seconds. in Immediate its the traditional Add\Subtract. Changed: The duration menu for the M270 is dynamic depending on how many vehicles there are. max 15 duration. Changed: The batteries won't be resupplied until they run out of one ammo type. Changed: Now all 3 batteries can be what ever weapon you wish to choose (M119\M252\M270). example you can now have M119\M119\M252 or M270\M252\M252. etc. Changed: Dispersion Add and Subtract Menu have been replaced with set ranges of: for MLRS its 50\100\150\200\250\300 Meters. for all the others its 100\200\300\400\500 Meters. Added: Added an Option to cancel a fire mission in progress but only after the first shot. Added: A few voice Radio Dialogs for the FDC. V1.03 Hotfix 1 Fixed: Improved overall game performance caused by some scripts related to player disconnection or player respawn and now these scripts should only run in multiplayer. V1.03 Added: Ammo limitation and Ammo Resupply Interval. Resupply Interval is adjustable by the user in the options.sqs. the user can also disable resupply all together. Added: Ammo Readout to the Action Menu to view your current ammo pool for your current battery. Added: Dispersion Ability for 50m to 200m and have added the Dispersion to the Dialog on mission submission. Added: Ability to move the M270 MLRS and have the Unit Marker and Range Markers Follow it around. Added: Added Version Number to the Initialization Message so users know which version they are currently running. Fixed: Corrected some typos in the dialog. Fixed: Fix a problem with not being shown who is in charge of the battery you're trying to acquire. Changed: the Ability to set the rate of fire to 0 seconds so that all guns can fire almost all at once. Changed: increased preparation time between mission submission and shots by 2x. Removed: Reload text between fire missions. Removed: Unneeded code in some scripts. V1.02 Fixed: Fixed a Limited Detection issue with the M252 Mortars and M270 MLRS. V1.01 Changed: Removed the pings from the hints. Credits: Tester/Scripter: Soccerboy Testers:

yeah it would. sorry for the long absence. getting ready to move across the pond to live in the US so its getting a bit busy but i hope to at least start work on a tie to an object radio (From OA) AND a better radio simulation in a few weeks. whats planned is the ability to set frequencies, frequency strength, basically as much relevant data from the SINGARS manual to build a convincing radio simulation. i'll post back here with a demo as soon as i start getting the user interface together for a test run. so as of now the radio would have a higher priority than the artillery atm and i'll also build it so it can be used with other user created scripts/mods if they choose to use the simulation. until next time in a few weeks. take care everybody.

thanks for the hint. i'll drop Noubernou a line and see whats up. :)

hello everybody, sorry for the long MIA time, i've been taking a few breaks here and there going through ideas and thinking about how to build things that progress has slowed a bit but for the better because i'm making less mistakes now and having to rewrite things less frequent but anyways heres a new vid with a progress report again. Youtube video: <object width="980" height="765"><param name="movie" value="http://www.youtube.com/watch?v=ZLuRrreQIwk&hl=en_US&fs=1&hd=1&border=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=ZLuRrreQIwk&hl=en_US&fs=1&hd=1&border=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="980" height="765"></embed></object> the above video shows how to set up the artillery in the editor and how it works in the game world. i'm going to play the video and talk about the things i think could use a bit more detailed explaining so lets start with: you can see you don't group the batteries together and only use my custom modules. the BIS arty modules are still used but they are created through the initialization so i still use their scripts and modules for the shooting process. technically speaking each gun is its own battery and is treated as such. each FDC module can be synched to an unlimited number of Battery Modules (haven't tested if there are any errors if you add to many to the FDC. My Personal Max is 3 batteries so far.). when sending the fire mission request to the FDC, the FDC decides which battery is best suited for the mission and forwards your request to the battery. the GRID designation works either for the center of the area use 6 Digit GRID Designator or for a more precise Designation use an 8 Digit GRID. the 2 extra digits are the sub digit for each area block as illustrated in the following image: Followup Ammo is very interesting and still needs a bit of work however, i've built it so that only one gun out of the battery will execute an illumination mission and if more than 1 round is requested then it'll wait until the burn time of the previous flare expires before sending in the next for optimum illumination over an area. the other guns execute the normal ammo be it HE, Smoke, what ever. the impact area is calculated as follows: target location + random offset + battery formation. each gun will have its own unique target coordinates based on its formation so if you build the battery in a V formation then the impacts could/will happen in a V form. i'm still ironing a few things out like the glitching FDC battery selection script sometimes returns no battery which shouldn't happen. happened to me during my first version of the preview video and i have yet to figure out whats causing it. i think thats it for now i've said alot today and gave you guys a few things to look at :). i'm open for any questions or feedback. thank you for your time reading/watching and have a good day/night :) *edit* also i forgot to mention that this is an addon for now because it uses custom modules however i will bust my head to make a script package for you guys too and hopefully i'll figure it out too. at the time the modules was the quickest and easiest way of getting the job done :)

hello, just some creative input here: did you account for artillery units that will be further away from the player to be excluded from the caching? because if they get removed and cached aswell then that might break any artillery addon (mine :P) or even the BIS arty module alone since the unit doesn't exist on the playing ground.

hello all, i'm back with a new progress report. oh my where to start, a lot has changed and i think for the better. the most significant change is the option to call in mixed ammo missions like alternate between Smoke (example) and HE (example) the way that works is: each gun receives his very own version of the fire mission and each even numbered gun fires the alternate ammo. to illustrate it better: you can now choose how many guns are involved in the fire mission and how many volleys each gun does. i've already announced method of control for "At My Command" and "Time on Target". setting your target works in the form of GRID or Shift from a known Point. shifting works only if a target has been called before. each gun will get a target offset based their formation within the battery itself. *note this is still testing and am not 100% sure if it will actually work but it is planned. the new way this system is built is you exclusively talk to the FDC which governs over its batteries. when you call in a fire mission the FDC will choose the best Battery that suits the fire mission. i feel like i'm missing something but i can't think of anything else that i should or could talk about. if anything i can always edit this post :) anyways the todo list has been updated with more detailed info. EDIT: preview videos will follow in the next few days as soon as i make some :D

if (isServer) then { //CREATE ARTY AND FO,S //================================================== =============== _SpawnPos = toLower (_this select 0); //spawn position of group and patrol pos //================================================== =========================== //CREATE MORTAR _Object = "2b14_82mm" createVehicle (getMarkerPos "simbala_artybase"); //_VarName="mort1"; //_Object SetVehicleVarName _VarName; //_Object Call Compile Format ["%1=_This ; PublicVariable ""%1""",_VarName]; //================================================== =================================== //CREAT MORTAR SQUAD GroupSquad1 = CreateGroup resistance; _leader1 = GroupSquad1 createUnit ["ACE_Ins_2_1", [(getMarkerPos _SpawnPos) select 0,(getMarkerPos _SpawnPos) select 1,0], [], 3, "FORM"]; //_unit1 = GroupSquad1 createUnit ["ACE_Ins_2_2", [(getMarkerPos _SpawnPos) select 0,(getMarkerPos _SpawnPos) select 1,0], [], 3, "FORM"]; //_unit2 = GroupSquad1 createUnit ["ACE_Ins_2_3", [(getMarkerPos _SpawnPos) select 0,(getMarkerPos _SpawnPos) select 1,0], [], 3, "FORM"]; _leader1 = leader GroupSquad1; //=============================================== //NAME MORTAR SQUAD _VarName = "mortinf1"; _leader1 SetVehicleVarName _VarName; _leader1 Call Compile Format ["%1=_This ; PublicVariable ""%1""",_VarName]; //MOVE MORT SQUAD INTO GUNNER SEAT _leader1 moveInGunner _Object ; //================================================= //SYNCRONIZE MORTOR SQUAD WITH ARTY MODULE [color="SeaGreen"]_arty_module_name = arty_module; //name of arty module = arty_module _arty_module_name synchronizeObjectsAdd [_leader1];[/color] [_leader1] call BIS_ARTY_F_initVehicle; //this synchronizeObjectsAdd [unitUSMC_1Plt_ASL];"]; //================================================== ======================================== //create FO }; the changes are in green the problem you were running into is you defined the module and the leader as an array already so the game saw it as [[module_name]] and [[leader]] which shouldn't be. so now it should look like a single array and not an array in an array. also the arty module name is actually an object not a string. this should work now however i'm unable to test this atm. if it doesn't work feel free to PM me since i think we're hijacking the OP's thread with your problems LOL :P

i got the initvehicle function out of the arty module itself. sadly half of the functions inside of the module are undocumented like adding your own ammo type which i'll be using myself someday for my own artillery project. if i remember correctly as i can't check it at the moment is initvehicle sets a few variables for that vehicle. its one of the first things the module does after initializing itself. mortar_leader is just an example and should be the leader of the mortar battery. mortar_leader = leader's name arty_module = module's name both MYUNIT and _leader1 should work however i'm a total geek and would work with _leader1 :) also another thing to consider is if you're spawning multiple mortars for a single battery then you would have to group them together so only the leader is synched with the arty module.

how are the mortars spawned? by your own script? also if the module is already in existence then try: arty_module_name synchronizeObjectsAdd [mortar_leader]; [mortar_leader] call BIS_ARTY_F_initVehicle; now i'm not quite sure if this will actually work its just some function i found in the arty module a while back and thought it could help you with that issue. ============================================= and about units spawned by som getting synched with FA or any module for that matter i would use a double array method and periodically get the list of units on the entire battlefield with the help of a trigger kind of like: trigger and module should be named so synchronization can be done. make the trigger detection zone very large so it will cover the entire map. then you can create the scripts needed: init.sqf: unit_array = []; scan_time = 60; //this means every 60 seconds a new scan is conducted exec "loop.sqs"; loop.sqs: #start ~scan_time handle = [trigger_name,module_name] execvm "script_name.sqf" goto "start" script_name.sqf: _trigger = _this select 0; _module = _this select 1; _unit_list = list _trigger; _temp_array = []; //add new and alive units to a temporary array for [{_a = 0},{_a < (count _unit_list)},{_a = _a + 1}] do { private ["_unit"]; _unit = _unit_list select _a; if ((not (_unit in unit_array)) and (alive _unit) and ((leader group _unit) == (leader _unit))) then { _temp_array = _temp_array + [_unit]; }; }; //check which units are the same in both arrays and skip those that are for [{_u = 0},{_u > (count unit_array)},{_u = _u + 1}] do { private ["_unit"]; _unit = unit_array select _u; if (not (_unit in _temp_array)) then { _temp_array = _temp_array + [_unit]; }; }; //add synchronization to any units within the array that aren't synched yet and remove those that aren't alive anymore if ((count _temp_array) > 0) then { _synched_obj = synchronizedobjects _module; private ["_unit"]; for [{_s = 0},{_s > (count _temp_array)},{_s = _s + 1}] do { _unit = _temp_array select _s; if ((not (_unit in _synched_obj)) and (alive _unit)) then { _module synchronizeObjectsAdd _unit; }; if (not (alive _unit)) then { _temp_array = _temp_array - [_unit]; _module synchronizeobjectsremove _unit; }; }; }; //save units array unit_array = _temp_array; //add init code for module after this line (delete ----) ------------init code---------- (not MP Compatible as synchronization only works on the server machine) the above should keep a list of all units on the battlefield and add synchronization to the module if they haven't already been synched before and it'll remove any dead units from the synchronization list and unit list. i haven't tested it out myself as i just wrote this up without my script editor so if there are any forgotten () or {} or any other problems with it then i'm sorry. i hope those blocks of code can help or at least give you guys some good and better ideas because it is quite late and can't really think clearly anymore lol. edit: forgot that most modules only the group leader is needed.

hello and good question :), that aspect is still in development and i can say already that there will be no map clicking or laser designation, right now i'm using the CBA function to convert a 6 digit grid zone into map coordinates (thanks to the comment given on my youtube video who ever did that :). sorry if i don't remember your name off the top of my head). at the moment i'm playing around with the thought of one of two methods, or both. one is grid designation and another is shifting from a known point. the known point will probably be the prior transmission of a grid zone. i'm still unsure how i'm going to implement it yet or how the end result is supposed to look like as i'm still trying to get the FDC to function correctly and build a modular Radio dialog system to build a proper radio protocol with the choices you make with the dialog. so far i'm making good progress fairly quickly and i'll probably be done with the FDC and Radio dialogs in a day or two. then its off to ammo supply planning and build the fire script. also another thing that i'm thinking/going to experiment with is: alternating ammo. however that would require 2 or more guns inside a fire mission. one gun will shoot one ammo while the other shoots the other ammo. also today i found the FM (field manual) for the FDC operator so now i have both documentations to semi authentically build the FO experience. :) edit: also ToT will work in the sense of "...shoot in X minutes, over" max 60 minutes at the moment but thats subject to change if i think it needs changing.

hello all, i'm back with an announcement regarding this project. i'll start with the good news: i've been browsing around and i found the FM (Field Manual) for the FO (Forward Observer) and i'm incorporating things that i think would be useful or give a more believable feeling to be an FO. bad news: i'm going to have to rebuild it from the ground up however i think the end result will be a more believable experience. the concept: tell the FDC: target type how many volleys how many guns mission type method of control target location type ammo type and a few more that i don't recall off the top of my head. with that information the FDC will determine which battery would be best suited for the fire mission and send the fire information to that battery. description of the items above: NOTE: the above can change as i read more in the FM this is still experimental however i have a strong feeling that i can achieve this as i already have a basic FDC that can make the choice based on ammo, range and number of guns. with those given things to the FDC the FDC will then make the choice which battery is best suited to execute the fire mission and pass it on to the appropriate battery. current todo list in correct priority order: build FDC logic to be able to make the decisions he needs to make Construct the proper radio protocol reconstruct target setting, firing, server detection and client options scripts i'll be adding the "todo list" to the front post and update it regularly as things get finished to help you guys see progress being done. also more bad news: the new system works with custom modules so i can't support a script version. i'm sorry for the set back however the end result will be a much greater user experience than the previous system/idea. if i have forgotten anything i'll edit this post. PS: 1.10 hasn't been canceled just postponed for the time being.

triggers are global so they exist on all machines. so i don't think you can achieve what you're trying to do with a trigger because triggers don't pass unit information on who triggered it as far as i know. the way i imagine triggers work is the unit calling the trigger just transmits a global variable like for instance "alpha = true" so there is no real fingerprint on who called it however, i'm not 100% sure on this.

i haven't tried it out myself but once the artillery pieces respawn and you've resynched them with your script you'll have to reinitialize the init script of the module which is: _script = _this execVM "\ca\modules\arty\data\scripts\init.sqf"; or _script = NAME-OF-LOGIC execVM "\ca\modules\arty\data\scripts\init.sqf"; if that doesn't work then i have no idea why it won't let you use the artillery without doing much research of the artillery scripts.

you're correct, it is a locality issue. the helicopter you're trying to command is local to the server and not to the player so telling the helicopter where to go would have to be run on the server and not on the client. what i've read about locality is: player and his group is local to the client machine. AI units without any player and logics are local to the hosting machine. my suggestion is try to make it only execute on the server machine and pass the position on where its supposed to go with a publicvariable and try if it still goes crazy. EDIT: this will require either building two scripts to execute one on the client to get the position array and another to execute on the server to use that array and tell the helicopter where to go. or you can try and forge them into one script by making it check if the machine executing it is either a server or a player.

hello, i'm still working hard on this. i've added a section on the first post that i update when ever something changes in the status of the scripts under the headline "currently working on". i hope to have it done and out before march ends.

thank you for your support :) i think i'm just about done with adding new features for v1.10 and i'll be testing it myself for a few days or a week if i find any bugs and then it'll go to closed MP beta stage for a few to catch a couple bugs i haven't found and after that passes it'll be released for all to enjoy. if there are any questions regarding anything in the changelog that anybody wants to know more about i'll gladly give out more information in my next progress report. until next time. :)

lol no the scripts simulate that each HMMWV has a radio which can be used by the leader of the group regardless if he has a radio or not. if you leave the vehicle you'll have to stay within 3 meters or else can't call in anything. if you have the radio then you can use artillery regardless if you're in a vehicle or not. EDIT: i forgot to add that in the video i put the radio in the HMMWV to illustrate the effect of not having a radio and you move away from the vehicle further than 3 meters then the GUI will be empty and unusable and the action menu item will have a (Radio) tag meaning you need a radio to use anything in the GUI :)

hello, i'm back with a new preview and today i'm going to talk the purpose of x and y corrections. when setting a target the map coordinates have some offset of a random value so that means that the battery might shoot right next to your target position or right on top of it if you're lucky. this randomization only happens when you set your target so you don't have to play a game of luck when you call in a new fire mission each time however you won't be able to know by how much its offset until you actually call in either a spot round or execute a fire mission. the time to set up a fire mission is based on several things. if the battery is preregistered to that mission number, if the battery has fired apon this target before or not. if it hasn't fired on this point before then the setup time will be quite long but, if it has fired on it before or if the mission has been pre-registered with the battery then you should see some rounds being shot very quickly after the request has been sent. once you see the rounds hitting and its not where you want them to be you can easily correct the coordinates with adding an X or Y correction into the dialog. once the request has been sent with the correction data then those new coordinates will be saved with the battery so you don't have to resend the same correction over and over. example: if i'm off by 100m to the left then i'll just send an x correction of 100 to the battery and it'll use the new coordinates to send those rounds to that location. if i need more rounds i send no correction data since its already been corrected and the battery is zeroed in on that target area. there is no cross information transmission between batteries so you would have to give each battery their very own correction information. here is the first of a two part video preview of the system's current state: <object width="640" height="505"><param name="movie" value="http://www.youtube.com/watch?v=GE4iRu3gNVU&hl=en_US&fs=1&hd=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=GE4iRu3gNVU&hl=en_US&fs=1&hd=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="505"></embed></object> here is the last of the two part video preview (youtube will take a while to process for higher definitions): <object width="640" height="505"><param name="movie" value="http://www.youtube.com/watch?v=F0qCsAePCBE&hl=en_US&fs=1&hd=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=F0qCsAePCBE&hl=en_US&fs=1&hd=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="505"></embed></object>

try the updated. if that doesn't work then i think i'll have to dig deeper lol :) i think i would go and write a script though go into a much more detailed effects like: trigger: BLUFOR - Present Name - IED1 Cond - this OnAct - [thislist] execvm "script.sqf" script.sqf: _units_array = _this select 0; _result = false; for [{_u = 0},{_u < (count _units_array)},{_u = _u + 1}] do { _unit = _units_array select _u; if (_unit hasweapon "WEAPON CHOICE") exitwith {_result = true}; }; if not (_result) then { _ied = "R_57mm_HE" createvehicle getpos obj1 }; however i'm not 100% sure if my trigger+script method is going to work yet unless i try it out.

lol sorry i screwed up. check the updated post above yours. also the IED_Armed value won't work unless you define it as a true or false value so leave the green part out for now and try the red set of code

i've been updating the first post's changelog while i was working on the project and this is what i've gotten so far. some things have been tested already however not on a dedicated server yet. V1.10 Added: GUI interface Added: X and Y correction areas in the GUI so that you're not punished for setting the marker wrong and having to wait forever for re-registration. Added: Spot Round Ability to the GUI interface to have the battery fire a spot round without the need to change the number of rounds in the interface. [*]Added: Random fire mission solution error (the target impact zone is not 100% accurate anymore) [*]Added: Ability to set your target with either the traditional map clicking or with your laser designator. [*]Added: Pre-Registration option for less delay when calling in a fire mission. [*]Added: Initialization Diagnostic system in the event of an error in any of the initialization scripts you can see which one failed and a possible error report is displayed. [*]Added: Functions to change certain options during gameplay for mission makers to be used for triggers, and to add a radio or laser designator automatically without fighting with commands like addweapon/removeweapon. [*]Added: JIP (Join in Progress) compatibility. when a user comes in fresh and the variables are undefined then the client will request an update from the server (i hope this will work) [*]Added: Compatibility for the ACE2 Radio Equipment. [*]Added: Ability to request artillery from inside or within 3m of a vehicle (HMMWV or MTRV). if you're inside or near a vehicle then you don't need the ACE radio if ACE mode is active. [*]Added: Option to define how many times the battery gets resupplied during a mission (battery won't be supplied until a certain amount of rounds have been fired already) [*]Added: Support for the Virtual Artillery Modules [*]Added: Some additional radio text dialogs to the system to reflect different factors. [*]Changed: Structure of the scripts to be more generic to reduce calculation errors. [*]Changed: The menu item will now display if you can or can't use the GUI dialog, inability to use the dialog will be marked with a (Radio) tag. [*]Fixed: The Dispersion values should be used correctly now. [*]Fixed: Detection issue that could cause an error to the system. [*]Removed: Radio Sounds for Custom ones to be added later *More to Come and subjected to changes*

i would combine all that into one trigger so to say Triggers :- ( FOR THE IED ) BLUFOR - Present Name - IED1 Cond - [color="Red"](!(player hasWeapon " CHOICE WEAPON ")) && (player in thislist)[/color] [color="SeaGreen"]&& (IED_Armed)[/color] OnAct - ied1 = "R_57mm_HE" createvehicle getpos obj1 ... ! = not - meaning if you don't have the weapon then that condition will become true and it should go off. i would be real dirty too and set it to repeated activation so if you still left the zone and dropped the weapon it'll still go off in your face. :) i would also create an IDE variable to go either true or flase on either disarm or detonation so it won't go off if its been disarmed/detonated already which i marked in green now the armed variable would take a bit more scripting and i can give ya more input if needed :) i'll be using something similar in my missions that i'll be working on after i'm done with my artillery project however i'll be going a different route so to say i'll define if detonation should occur depending on the number of units in the kill zone :)

oh that's just an example as to what the array would look like to the computer, if you're trying to get the units from a group you would use array_name = units groupname or if you only know one units name then array_name = units group unitname the breakdown of it is "units" means get the units of a known group name into an array "group" means get the known unit's group name i'm going to take your script for example the way you have it setup is you're unit's group name will be "_newgroup" so to get the units name in a global array it would be array_name = units _newgroup Group Units i hope that clarifies things a bit better :)

ah i totally forgot about that command :) glad i could help somewhere. over the past few weeks/months i've become very proficient with arrays and i love using them to pass information around :) when it comes to that kind of things i like to use a "For loop" because i just find it to be easier readable as to what you're really doing and its better if you want to include ascending or descending number variables to your commands. like if you're passing an array of units to check if those units are still alive you would go: here and here is some info on for loops. for both examples we'll call the unit array "array = [unit1, unit2]". now we can check those units. for [{_u = 0},{_u < (count (array))},{_u = _u + 1}] do { _unit = array select _u; if (alive _unit) then { _unit setdamage 1; }; }; you could also probably do it with a foreach command that i don't have much experience with but i'm guessing it would look like this (foreach is good if you're not trying to add other information like ascending or descending numbers. i can be wrong however since i don't use much of foreach commands): here is some info on the foreach command. { if (alive _x) then { _x setdamage 1; }; } foreach array; the way i understand how foreach works is "{code} foreach array" so i can only assume that my foreach demo is correct however i can't try that out at this moment but i will at a later time. if you need more help or have more questions feel free to PM me or post in this topic. i'll be keeping my eye on this one for a while to help out where i can :)

what exactly are you trying to do with the unit names? you could just save the names in a global array like for instance "group_array = (units _newgroup)" then you could easily access the names with "select (index number)" without () :) lets imagine your script creates two units then it'll be "group_array = [unit1, unit2]" then if you want to check if they're still alive or set damage or what ever you just select the index of the unit you want to access and do what ever you want to him like "_unit = group_array select 0". you also can put that command anywhere after the group has been created before the script exits. if you need more info about arrays here is a nice page to read up on them