roguetrooper

Lol, you can't have 3000 units and 500 vehicles. At least not on a playable map. Further, you can't have more than 144 GROUPS per side/faction. The most important thing with such an amount of units would be (in init.sqs or in a trigger with condition "true"): enableSentences false; Otherwise every player would receive 100 messages per second ("reloading", "enemy on 11 o'clock", "wounded", "we have lost x", "where are you?","x move to"). Doesn't the default debriefing screen list up all losses and kills anyway? Edit: Code removed. Confusing due to being incomplete and not being practical in this situation.

{_x removeAction actionName} forEach allUnits; {_x removeAction actionName} forEach allDead; {_x removeAction actionName} forEach vehicles; Executing this on the server and all clients should totally and completely remove the action from the world.

_Pos already is a position (according to your script). You must use: unitname domove _Pos; or unitname domove position hostage;

Mkay, the unusual formation-behaviour results from forming the group by putting [this] joinSilent leaderx; into the init-line of all subordinates instead of making them a group within the editor. Nevertheless quite strange. Even when you join the player (who still has the lowest rank of all) later into the group, some or all subordinate AI use the player as formation reference (when the group is made by join and not within the editor).

Don't know where to put this... Is it a bug or a feature that AI units follow the player although the player has a lower rank? Situation: * group of 10, everything AI, except one player * leader rank is lieutenant * 8 other AI units are corporals * player is private Why do the eight corporals follow the player (i.e. use the player as formation reference), who has the lowest rank of the whole group?

Version 1.05 (only 250 kilobytes) -> DOWNLOAD -> DOWNLOAD -> fastest: Fun For Four Co-04 (@) No mods and custom addons required! Don't be afraid, just download, install and test it in solo-multiplayer-mode. Leave the lobby-settings as they are for your first try. Their default is solo-player compatible. RogueTrooper Production Proudly Presents :bounce3: Fun For Four (Coop 1-4). Requires ArmA 2 and OA. No custom mods or addons required. This is a sandbox map. It can be played in MP alone or in a group of 2-4. It can be played on any BIS map: Tchernarussia, Utes, Takistan, Zargabad, Shapur, Proving Grounds and Desert. A.I. group members can be disabled. The playergroup (leader/human with highest rank) can place an OPFOR group anywhere on the map. Then place themselves anywhere on the map. The Lobby allows to define 26 parameters: detailed weather- and environment settings, daytime, time limit, injury and healing options, enemy amount (= random between minimum and maximum), enemy equipment (tank, helicopter), OPFOR placement radius, time limit, player respawn limits, the task of the player group (destroy enemy officer or whole group) and several little other settings. The playergroup starts with a HMMV, a Little Bird helicopter, an unplayable optional pilot (players are allowed to fly, too) and a weapon box that contains ALL weapons, magazines, backpacks and items available so far in ArmA 2 OA. Respawn point is within the HMMV. The HMMV can optionally be indestructable. If it is set as destructable, it respawns near the place where it has been destroyed. The helicopter and the unplayable pilot do not respawn. There are no other things on the map than the enemy group and the players with their start equipment (helicopter, HMMV, total-weapon-box). In the desert however, there are ten random towns around the pipeline. Gameplay: (1.) The playergroup can equip themselves from the weapon box however they want. (2.) Then the human player with the highest rank can click anywhere on the map to create the hostile OPFOR group with the parameters from the lobby: amount, placement radius, equipment, skills. All OPFOR is placed randomly within the placement radius (formation or spread throughout lobby radius setting). (3.) At a second click anywhere on the map the whole player group is moved into the HMMV and the HMMV gets teleported to that clicked position. (4.) Do whatever and how you want to destroy the OPFOR target(s). With the lobby settings and the placement of OPFOR and BLUFOR, the players can play the map however they want: as snipers, as tank busters, as an infantry fight vs. OPFOR in a town, forest, desert, at night, rain, sunshine, fog... how and wherever you like. Everything can be selected in the lobby. The difficulty is influenced by *the enemy amount and skills selection in the lobby, *if the enemy has a tank (T-72) and/or a helicopter (Mi-24V which is quite a beast with its movable cannon), * the respawn limit for the playergroup. See the briefing for information. The 26 lobby parameters should be self-explaining. Installation: 1. Copy all pbo-files into \YourArmaFolder\mpmissions. 2. Select the map "Fun For Four" from the map you want in the MP-setup-lobby.

BIS should have made ALL classnames either completely in capital letters or completely in non-capital letters. Don't know why they haven't introduced that convention even to their own advantage while creating the game. This would eliminate the necessarity to look up correct classnames over and over again while mapping/scripting. Mmmh, was that "m" there capital... and such. Some weapons start with capitals, some don't, some change the case inmidst of the word and so on. :(

Hm, been playing around with BIS_fnc_destroyCity and indeed it only damages/destroyes buildings after the map has already started. Should be an issue for a future patch. Map-internal buildings, plants, rocks and everything else should be deletable by a command/function so that the map starts right off with the object already being destroyed (ruin) or removed at all. ---------- Post added at 05:54 PM ---------- Previous post was at 05:29 PM ---------- Hey, I've found a workaround how to remove buildings from the map without the destruction animation Little testmap in Zargabad, wpc1 is a logic or invisible helipad or whatever: _center = wpc1; _radius = 5000; _keepobjs = [player]; _keeptypes = []; { if !(_x in _keepobjs) then {[b][color="Red"]_x hideobject true[/color][/b]} } forEach (position _center nearObjects _radius); exit; As you know, hidden objects are not only invisibly but actually not 'present', so you don't have invisible walls and such. Couriosly trees, market umbrellas, walls and the mosque are not affected. The hiding/deletion condition could be (enhanced to) _x iskindof "Building" to exclude everything that is not a building. Or add if (random(100)<50) to remove only half of the town etc..... In a MP map of course the server would have to define the (random) list of objects, then broadcast this array by publicVariable and have all clients use that array so that everyone has the same non-existing buildings ^^ Edit: Seemingly there are glitches with some buildings. E.g. the flight control tower at the airfield. It is still visible but you can walk through it.

Is it possible to have destroyed buildings right from the beginning, so that they are already destroyed before the player is actually ingame? When you destroy map-intern buildings with nearestObject(s) and setdamage, the building collapse when the map has already started and the player/s is/are already ingame and the player can/has to see how they actually are collapsing. In the first PMC map there are destroyed buildings, but I don't know whether they are destroyed while the player recovers/awakes from the shock.

I name all my files sqf (f like fox, with exceptions) and execute them with [] exec "file.sqf" (f like fox) and I never have problems because of this. I think my code is sqf(ox). I hate the unreadable sqs format with its ugly shortings && ??: and such. I always thought sqs (s like sigma) was the ugly unreadable code. I'm using sqf(ox) and the kind of code stated above and everything works fine...

When there are no units spawned during the mission: A trigger with activation: once condition: true code: {_x addEventHandler ["Killed", {if !(isPlayer (_this select 0)) then {removeallweapons (_this select 0); removebackpack (_this select 0)}}] } forEach allUnits; --------------------------------------------------------------------------------------------------------------------------------- When you have units spawned during the mission and want to remove their weapons when they are dead: Put into the init.sqs or into a trigger with the condition "true": [] exec "remove.sqf"; file remove.sqf: #start _deadlist = []; { if !(isPlayer _x) then {_deadlist = _deadlist + [_x]} } forEach allDead; ~5.0 {_x removeallweapons; removebackpack _x} forEach _deadlist; goto "start"; The workaround with the delayed _deadlist also removes the weapons some seconds after they have fallen to the ground. Otherwise it would look strange when their weapons suddenly and visibly blobbed away in the second they die. Edit: Nah, unplayable only :-/ Couldn't find a check for "is playable". You might add the condition "isPlayer"... this at least would keep the weapons of those corpses that CURRENTLY are a human player. I've tried to add it to my codes above. Hopefully distributing all the ( and [ and { correctly.

Is there a way to prevent units and vehicles that have been created by an ACM (Ambient Combat Manager Module) to be automatically deleted again? Especially those that are out of sight/range of the player/s.

I've been using this command, but it only influences in what radius the units spawn. By my own experience it does not prevent units from sudden un-pop.

I want to attach (http://community.bistudio.com/wiki/attachTo) a small ammobox under a helicopter (Little Bird). This works fine so far, it is exactly positioned and aligned as I want it. It is attached directly under the hull, it barely touches the hull and it does NOT touch the ground when the helicopter has landed. But seemingly this causes the helicopter to explode (even with "this allowdamage false") after few seconds flying :( (No, there are no hostile units around, it is a so far clear testing map). It makes the A.I. pilot lift up constantly a few centimeters per second and especially at maneuvers with the nose pointing downwards the helicopter explodes. Does attachTo influence the physics of an object? Has anyone experience with that or has a workaround at hand? Edit: Hm, there seems to be a clumsy workaround: triggers with (if height heli: > 0 then attachto + box hideobject false) and (if height heli == 0 then: detach box + box hideobject true). But such popping up and away of visible "physically existing" objects isn't very smooth...)

Does anyone know, which Arma2-tents (the common tents without any function) are included in Operation Arrowhead? Off-topic: When you own Arma2 and OA, you just can't make an OA-only compatible map without being carefull like hell and checking everything twice in weird and time consuming workarounds. :mad: Heck, even the editor-placable stuff has been some kind of messed up by the fact that OA is a stand-alone. There are even items that are totally identical (e.g. field lazaret, ladders...), but are listed twice with exactly the same name in the editor pull down menu, but have different class names (mission.sqf), eg. classname and classname_EP1 :mad: When there are two identical names in the editor pull down menu, you have to put both variants onto the map, give them different names, save the map, open mission.sqf and see, which object is Arma2 and which is OA and then remove the item-variant that does not belong to the game-part you are mapping for. And when there is only one item in the editor, you can't be sure wheather it is an Arma2-only item. Someone really had deactivated his brain when all this OA-stuff was decided. :(

I have a rectangle (trigger) with known position, length x, width y and angle z (not 0) and need a script that places objects on the border of that rectangle with a distance "d" (maybe 3 metres) to each other. Could one of you imagine that to be possible? Sure, I could place those objects manually in the editor, but according to variable settings that rectangle can have a variable position, x,y and angle. PS. For placing objects on the border on a CIRCLE I have script, which works fine.

Is there a way to return the real-life time/date? I've wikied around with "time" and such (expecting links) but found nothing so far.

Don't know where to put this. I have many MP maps playing in Takistan that also require Chernarus-stuff. In the server description I include clearly visible, maybe in fat big letters, "requires Chernarus" or "requires original Arma2" or something like that. Nevertheless all the time people who do not own Chernarus try to connect. Since I am using the addon enforcer by Deadfast, those who do not own Chernarus are thrown out at their connection attempt. Nevertheless of course the WHOLE chat window is spammed away at once by what original or custom mods the connector has/not has plus three lines for "connecting,connected and disconnected". [1.] Do many/most people who only have Arrowhead do not know that there exists another main Arma2 part? Maybe there should have been (or was there? - can't remember) an ad inlay in the OA-box that there is another Arma2 part. (Personally I can't understand how somebody who owns and likes OA can not have Arma2 as well - no, I do not have too much money). [2.] Are people more/only interested in Takistan than in Chernarus because the undercover war for oil has been the top topic in news and media since 2003? Are people artificially iraqi- and afghanified? [3.] Do many/most Arrowhead-only owners not know what "original Arma2/Chernarus" is? Can't they handle and interprete such a server description? Maybe this is related to question 1. [4.] Are people too stupid/lazy to read the server description in two seconds before they hit the connect-button? Off-topic: I still consider the fact that OA is a standalone to have been a wrong decision. It even artificially devides the no-custom-mod-users into two incompatible factions. At least OA should have contained all units, weapons and objects of Arma2 except the Isles. Further, as suggested before, there should be a threefold chat window: * one tab for system messages only (those that are independent from any scripted globalChat), including server command responses (#userlist etc) * one tab for human player typed chat * another tab for everything else (scripted chat and such) * maybe a fourth tab where you can chose (multiple choice) which of the other tabs are displayed in it * tabs must be up and down scrollable to keep all text that happens and tabs must automatically jump to the latest line when new text appears So you could keep track of all kinds of chat without missing anything, since a single failed connection spams away everything that can never looked upon again once it has gone.

Flashlights (not mounted to a weapon) would be fine. It would also be great if you could use them together with pistols: left hand holding flashlight and supporting the right hand that holds the pistol... as to be seen in movies :D Or torches with a flame - like campfires on a stick :D (not usable along with weapons).

One more proof that the addon/bundle politics has been a total failure. :(

Starting off with dialogs can be quite a fun... since it envolves description.ext that makes the whole game crash to the desktop when a single letter/number/symbol is wrong or missing or displaced.

I want a coloured box on the screen that the player can not remove and that has no impact on the player's controls. Usually, when you create a dialog, it can be removed by hitting Escape and the dialog disables other input (moving, inventory, action menu). This dialog from my description.ext is what I want; a box of desired colour and position: #define FontM "Zeppelin32" #define CT_STATIC 0 #define ST_LEFT 0x00 #define ST_CENTER 0x02 #define CT_BUTTON 1 class Dialog1 { idd = 100; type = CT_STATIC; style = ST_CENTER; movingEnable = false; enableSimulation = true; controlsBackground[] = { }; colorBackground[] = { 1, 1, 1, 1 }; objects[] = { }; controls[] = { Box1 }; class Box1 { idc = -1; moving = 0; type = CT_STATIC; style = ST_LEFT; text = ""; font = FontM; sizeEx = 0.03; colorBackground[] = { 0, 0, 0, 0.5 }; colorText[] = { 1, 1, 1, 1.0 }; x = -0.186; y = 0.677; w = 0.693; h = 0.24; }; }; The bad thing is, that it can be removed by the player and even worse, it disables player input until it has been closed (Escape or closeDialog). So what do I have to do to create boxes on the screen of certain sizes, colours and positions that cannot be removed by the player and that have no effect on the player? (Should be MP compatible) (found nothing at http://community.bistudio.com/wiki/Dialog_Control)

It's not a question of the dialog working or not, since it does work (copy & pasted from actual working usage). The code above is just meant to give a base of what might be changed so that it works in the way I described it.

You could define an area and command every A.I. unit with "move" to move back into the area when they are coming close to the border of the allowed area. My example: When you have an allowed area that is a circle with the radius "AREA", and the center "wpc1" you could have a loop checking all the time all units in concern: areacheck.sqf: the loop observing all units of the type "BAF_Soldier_L_DDPM": if !(isServer) then { exit }; ~1.0 _dist = AREA +1; _wpc = [(position wpc1 select 0),(position wpc1 select 1),0]; _ptype = "BAF_Soldier_L_DDPM"; #start _dist = AREA + 1 + random(3); _plist = []; { if ((typeof _x == _ptype) and (alive _x)) then {_plist = _plist + [_x]}} forEach allUnits; {if (([(position _x select 0),(position _x select 1),0] distance _wpc) > _dist) then {[_x] exec "areacheck2.sqf"}} forEach _plist; _wait = 1 + (random(2)); ~_wait goto "start"; exit; areacheck2.sqf: killing all players and A.I. that however leave the area: _man = _this select 0; if ( !(isServer) or !(alive _man) or ((_man distance wpc1) < AREA) ) then { exit }; _man allowdamage true; _bomb = createVehicle ["R_57mm_HE", position _man, [], 0, "NONE"]; _bomb setDamage 1; _man setdamage 1; exit; areacheck3.sqf: tries to command an A.I. unit back into the allowed area (a random point within the half radius of the area): _man = _this select 0; if ( !(alive _man) or !(local _man) or (isPlayer _man) ) then { exit }; _x = position wpc1 select 0; _y = position wpc1 select 1; _dir = random 360; _radius = AREA/2; _finalpos = [(_x + (random _radius) * sin _dir), (_y + (random _radius) * cos _dir), 0]; _man domove (_finalpos); exit; Of course that is no 100% guarantee. The domove-command may not be observed when the unit is in combat and currently engaging/hunting an enemy. But I noticed a lot less amount of A.I. leaving the allowed area. Edit: Think I mixed up something. Actually I have triggers observing the distance of every unit to the border of the allowed area. When they are closer than 5 meters to the border, they are commanded back into the central area: activation: multiple condition: (unit1 distance wpc1) > (AREA-5) on activation: [unit1] exec "areacheck3.sqf" So areacheck1 & 2 are just to kill any unit (player and ai) that makes it beyond the border. The triggers and areacheck3.sqf are responsibly for trying to keep A.I. inside. I also suggest to avoid "unnatural" processes like teleporting if possible. Seeing a unit disappear from its current position suddenly without "physical" or "logical" reason does not suit the world of ArmA. Off topic: It would be great to have some editor objects being configurable like triggers or markers that can be used as invisible walls that A.I. never leaves/enters/crosses. Not being really able to restrict A.I to or exclude from certain areas can be quite annyoing.

Is there a command/method for Arma(2) (seemingly not according to wiki) that returns all current markers? This VBS command however does not work in Arma: http://community.bistudio.com/wiki/markers_%28VBS2%29 NearObjects, nearEntities and all that has no effect on markers. And adding them to an array when they are created, will not work for my purpose. Could you think of another possibility to return all current markers?