Ronin Storm

I've been looking to see if I can figure out the names of locations around Zargabad. I found and modified the following script that draws markers on the various locations on the map, with my modifications adding a label to the markers for the location name. However, in Zargabad, all those location names appear to be blank... is that really supposed to be that way? if (!isServer) exitWith{}; waitUntil {!isNil "bis_fnc_init"}; _i = 0; markLoc = { _loc_type = _this select 0; _color = _this select 1; _locs = [_loc_type, [[0,0,0],1000000], true] call BIS_fnc_locations; { _i = _i + 1; _n = format["x_%1", _i]; _m = createMarker [_n, position _x]; _m setMarkerType "Dot"; _m setMarkerColor _color; _l = nearestLocation [getPos _x, _loc_type]; _name = name _l; _m setMarkerText _name; } forEach _locs; }; ["CityCenter", "ColorBlack"] call markLoc; ["StrongpointArea", "ColorRed"] call markLoc; ["FlatArea", "ColorBlue"] call markLoc; ["FlatAreaCity", "ColorGreen"] call markLoc; ["FlatAreaCitySmall", "Default"] call markLoc; ["Airport", "ColorWhite"] call markLoc; ["HQ", "ColorOrange"] call markLoc; ["Name", "Default"] call markLoc; ["Strategic", "Default"] call markLoc; ["NameMarine", "Default"] call markLoc; ["NameCityCapital", "Default"] call markLoc; ["NameCity", "Default"] call markLoc; ["NameVillage", "Default"] call markLoc; ["NameLocal", "Default"] call markLoc; ["Hill", "Default"] call markLoc; ["ViewPoint", "Default"] call markLoc; ["RockArea", "Default"] call markLoc; ["BorderCrossing", "Default"] call markLoc; ["VegetationBroadleaf", "Default"] call markLoc; ["VegetationFir", "Default"] call markLoc; ["VegetationPalm", "Default"] call markLoc; ["VegetationVineyard", "Default"] call markLoc; ["fak", "Default"] call markLoc; processInitCommands; finishMissionInit; All the above in init.sqf.

Confirmed. I have uninstalled BitDefender 2011 and now successfully installed both British Armed Forces and Private Military Company. I've had occasional oddities with BitDefender anyway so I'm prepared to squarely lay the blame at their doorstep and search for a different antivirus provider. Thanks everyone for the help!

Congo: Thanks for that investigation! I'll give the same thing a try tomorrow and report back, though given other comments I'm hopeful for success.

I'm apparently having the exact same issue as Congo Toey. Windows 7 SP1 64bit BitDefender 2011, fully updated Trying to install both/either British Armed Forces and Private Military Company, both purchased and downloaded from SprocketIdea. My copies of ArmA and OA are both physical DVDs. ArmA and OA work fine. I just get the following error message after file extraction has occured immediately that the patch is "loading": I've (re)installed the Microsoft Visual C++ Runtime Library 2010 for x64 platforms and this has made no difference. I've disabled BitDefender (insofar as it's possible to do so), which has also made no difference. I've tried contacting SprocketIdea by email towards the beginning of this week but had no response from them. Any suggestions?

Personally, I only ever make missions for my group using ACE2. However, I'm not entirely sure how much of my group will pick up OA, so retaining support for ArmA2 base + ACE2 is very helpful for me. That said, given that I have working missions in current versions of F2, maybe F2 should move to focusing on OA as primary and then offering whatever alternatives you have time and energy for. Thanks!

Right, so the implication of that is that if I'd made the presence condition for rus_helo2 more like: (not alive rus_helo1) ... then that would have worked?

You're welcome. :)

I suspect that your request can only be answered by the explanatory text of "learn how to script". I realise that's exceedingly difficult without some guidance but, personally, I'd prefer that Fer concentrate on good base functionality as opposed to generic coding documentation. Ultimately, I don't think it's realistic to expect a "no coding experience" version of F2 or similar frameworks.

Just been fighting with a similar issue, but I believe I have a solution that fits the original poster's requirements. Just to be clear, here's my requirement and then my resolution: Requirement: I want my coop team to be uncertain as to exactly what they're going to face, even if they've played the mission before. However, I want to be certain that there's going to be some enemy and not, by chance, no enemy (or, just as bad, so many enemies that the mission is not possible). For example, my coop team are intercepting and destroying a convoy. The convoy will call for help if it gets chance. On standby is a helicopter. Most of the time, I want it to be an armed passenger helicopter but around 25% of the time I want it to be a lean and mean attack helo. Attempts (that didn't work): Taking the helicopter example, I have two named helicopters called "rus_helo1" and "rus_helo2". rus_helo1 has a probability of presence of 75% and a condition of presence of "true". I want rus_helo2 to only but always appear when rus_helo1 does not appear. I tried a probability of presence for rus_helo2 of 100% and a condition of presence of: (!alive rus_helo1) rus_helo2 will never appear, even when rus_helo1 is not in play. Successful solution: Setting rus_helo2 condition of presence appears to be an incorrect approach (maybe due to a bug?) as, apparently, rus_helo1 is always alive when the check occurs. Instead, setup rus_helo1 exactly as above, then do the following for rus_helo2: Condition of presence: true Probability of presence: 100% Initialisation: if (alive rus_helo1) then { deleteVehicle this } I guess that speaks for itself but for the newbie coders this means that rus_helo2 will always be placed initially, but when it comes to actually setting it up (i.e initialising it) it'll make another check to see if rus_helo1 is in play. If rus_helo1 does exist, rus_helo2 will delete itself as if it never existed. This means that I always get one helo or the other but never both. This also avoids the waypoint issues identified with previous solutions as each helo has its own waypoints. A slight issue is that, in this case, I need to wire both helo's Hold waypoints up to a Switch trigger, which essentially means I have a maintenance complication. That's just a design consideration, though, not a flaw with the approach for conditional presence. Hope that helps.