zwobot

DAC 2 might also be an option when you want to have more control about what kind of enemies will be created in which part of the map.

Making a self-injecting addon out of it can't be too hard. I prefer scripted solutions as I mostly edit and play my own mission creations and don't want to install too many addons... I can't remember testing it with pre-set HC formations but it should work both ways with pre-set HC groups. You can test this yourself...

I made a quick demo mission with a script to split your group into HC groups and merge them back with your own group again. Download link.

You have to do this with at least two separate commands (untested code follows): _temp = player getVariable "money"; player setVariable ["money", _temp - 500]; Edit: kylania was faster and has psted correct code

That depends on the situation and the size of the squad or (color) team... I think there are scripts which enable the player to 'outsource' units from his own group into HC groups and vice versa. I can't recall the author or the exact name but I'm very sure it exists. You'll find it if you search around in the forums a bit (the best place to start would be the 'Mission Editing and Scripting' subforum).

Unfortunately it is not possible to assign different formations for color teams in the same group. There is only one formation allowed per group.

This should work (not tested) this addEventHandler ["Fired",{if (_this select 0=="M40A3") then {M40A3fired=true;};}] Regarding your third question Your code is almost correct but it should be more like that in the trigger's condition line: this && unit1 in thislist && unit2 in thisList

For this you need to use the hasWeapon command. You can use it in the condition field of a trigger or inside of an external script with a loop checking for the condition to be true every couple of seconds. You can find the name of the weapon in the CfgWeapons list for official weapons. If it is an addon weapon you need to consult the addon readme or use hint format["%1", weapons this]; in the init line of the unit with the weapon you want to check for. Add a 'fired' eventhandler to the unit which already has the weapon in its inventory like this: this addEventHandler ["fired", "hint format[""%1"",_this]"] It will display the required parameters (muzzle, magazine etc.) which you can then check for in a script called by the real eventhandler.

It's nice to see another effort to bring this theatre into Arma2. In which way is your team connected to previous Falklands/Malvinas mod teams from Arma and Ofp?

Thanks for your answers Pac and Canukausiuka. I'm really enjoying your mod and thank you very much for your latest release. I've spent the last week in the mission editor working on missions for my coop group featuring your nice modification. Does this mean the I44 artillery/mortar units cannot be used with scripted commands from the Arma2 artillery module at all? I frequently use the artillery module in SP and coop missions, so it is very important for me and hard to understand why it does not work anymore. Is there any workaround for mission designers? Regarding the Arma2OA based vs new I44 custom setup method for crew served weapons: with my limited config knowledge I assumed making a weapon compatible with the OA setup method was only a matter of one or two parameters in the config file of the weapon. Apparently this is not the case, is it? Another question regarding the camo patterns of the German Fallschirmjäger: why do they have another camo pattern now? It looks very winterish and does not fit well on non-winter islands. Are the previous camo patterns still available anywhere by any chance? Is it allowed to re-use the various fortification compositions you have in your I44 missions in other missions by the way?

That's right the AI does not do it on it's own but the player could conveniently order them to 1. drop the tripod 2. assemble the weapon 3. get in as gunner all with Arma2's own interface. There are considerably more steps involved to achieve this now because you have to teamswitch into every unit and use the custom interface. Can't the crew served weapons be configured to work both ways? This would be really nice! Oh, and the artillery units do not respond to scripted fire calls anymore, e. g. place a group of two Grw 34 units on the map, synch them with artillery module (named 'e_arty') and let them execute a fire mission [e_arty, 300] call BIS_ARTY_F_SetDispersion; [e_arty, getPosASL trp, ["TIMED", "HE", 0, 60]] call BIS_ARTY_F_ExecuteTemplateMission; They do not react. If you replace the Grw34 units with Podnos mortars, they execute the mission.

I hope it is not because it used to work for both AI and human players in 2.5 It would be a pity if it could only be used by human players now.

I don't think it has been asked before: How can I order the AI to assemble/disassemble crew served weapons like the MG42? Is this only available via the custom interface, i. e. not usable by AI?

Reading through this whole topic I already wanted to purchase the pre order beta. Then I found out you need Steam :( Is there any information if there is going to be a version of this game which will not require Steam?

Both download links in this thread are broken...

You have to use assignTeam - not assignedTeam this assignTeam "RED"; this assignTeam "GREEN"; this assignTeam "BLUE"; this assignTeam "YELLOW"; It's not hard.

Use setRadioMsg to enable the radio alpha trigger only after a certain condition has been met before.

I think there will be an example script in Mr-Murray's editing guide for Arma. Furthermore a search in this forum should create plenty of useful results, e. g. http://forums.bistudio.com/showthread.php?t=124726&highlight=eject+script http://forums.bistudio.com/showthread.php?t=128749&highlight=eject+script http://forums.bistudio.com/showthread.php?t=125906&highlight=eject+script

Hi all I'm trying to add a diary record to my briefing in the middle of the mission. Because I'd like it to be multiplayer compatible and some calculations have to be done before updating the briefing I call a script which is only run on the server, the diary record should then be added to all clients' briefings via remote script execution This is the script which I call from a trigger in the editor: if(isServer) then { westCasualties = (countWestUnits - ({side _x == WEST} count allUnits)); eastCasualties = countEastUnits - ({side _x == RESISTANCE} count allUnits); [nil,nil,"per",rHINT, format[localize "STR_hint_aar", countEastUnits, eastCasualties, round (100*(eastCasualties / countEastUnits)), eastCasualties, objectivePointsEast, (objectivePointsEast + westCasualties) - eastCasualties, countWestUnits, westCasualties, round (100*(westCasualties / countWestUnits)), 2 * westCasualties, objectivePointsWest, (objectivePointsWest + eastCasualties) - 2 * westCasualties, floor (time / 60), timeLimit / 60]] call RE; [nil,nil,"per",rCreateDiaryRecord, "Diary", [localize "STR_diary_aar", format[localize "STR_briefing_aar", countEastUnits, eastCasualties, round (100*(eastCasualties / countEastUnits)), eastCasualties, objectivePointsEast, (objectivePointsEast + westCasualties) - eastCasualties, countWestUnits, westCasualties, round (100*(westCasualties / countWestUnits)), 2 * westCasualties, objectivePointsWest, (objectivePointsWest + eastCasualties) - 2 * westCasualties, floor (time / 60), timeLimit / 60]]] call RE; }; Unfortunately the diary record is not added to the briefing. The only reference I can find for this in the .RPT file is the line: DiaryParser: <br/> without corresponding <br> I have no clue what this line is trying to tell me; just to be safe I erased all <br/> tags from my stringtable.csv file but the message is still printed into the .RPT file. Using a stringtable.xml file instead of .csv does not show the message in the .RPT file but the briefing is still not updated... Does anyone have a clue how to get the diary record created properly? Is my RE call correct in the first place (I'm not too sure, since I haven't used it yet with createDiaryRecord)?

Is there a version of this which does not require an extra addon (apart from CBA), i. e. put a folder with your scripts into a custom mission and call it from init.sqf or something like that?

Do you know of any standalone invisible target addon?

suppressFor works when the executing unit knowsAbout the target unit. - Just saw that you already used this command. The mos reliable way to make a unit fire at a certain location or area for a longer time is to use an invisible target addon. Unfortunately there is no such addon for Arma2 / OA (yet) as far as I'm aware of. If you have basic knowledge of model editing and config scripting it should not be too hard to port one of the invisible target addons from Arma to Arma2 (when you have the originator's permission of course). Also be aware of the engagement ranges of the weapon(s) used to suppress. 600m might be too far away.

Since skipTime has local effects it should be executed on all clients in a multiplayer mission.

The dynamic object compositions article in the Biki answers your questions.

Depends on the situation. Could be that the released civilian wants to get back to his buddies quickly after having been released. On the other hand he/she might be a bit disoriented and clueless and just stand there... Follow up question: how does this feature connect with the ALICE module, i. e. are released civilians handed back to ALICE (I don't know if this is even possible). It would be nice to have it as optional setting if it wouldn't be too messy to keep track which group a civilian was detained from or would it be sufficient to only setVariable the original group of detained units on the unit itsself? I found the conversation system hard to get to grips with in the beginning. Once you understood how it works it is quite powerful and I think it is a pity that it is not working for Arma2 units anymore and that the default version was not thought through to the end, e. g. you cannot configure language skills of the units. So as Blufor Army unit you can not talk to Takistani civilians because they don't understand you. This could be fixed with a community made addon I reckon. Have you thought about a scripted version of your module which would not require an addon?