soccerboy

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. :)