opusfmspol

BIS_fnc_spawnVehicle will always spawn in aircraft and helicopters in flying mode: _veh = createVehicle [_type, _pos, [], 0, "FLY"]; So you''ll probably want to use createVehicle, then follow it with BIS_fnc_spawnCrew, addVehicle and selectLeader.

It means your _suspect needs a Global variable name, not a _local variable name. Editor triggers don't use local variables unless contained within a scope, like a forEach command. Scripted triggers can use local variables though. for an editor trigger you would just use "captive Suspect" in the Condition field. The Condition field itself is "if ( __ )", and the On Activation field is "then { __ }". The code goes in the On Activation field.

Hi goliath86 - Sorry I didn't catch this sooner (I had the fixed scripts in my mission folder and didn't notice until removing them). The three scripts mentioned in my last post were updated in the warfare2.pbo in A2 addons, but not in the warfare2.pbo that is in OA's expansion\addons. The error from Init_Defense.sqf still occurs when JIP joins a Warfare mission in OA. And again, THANK YOU for all your great work!

The JIP problem in Warfare might be related to Bug #15222 (Resolved). I duplicated the test mission given with the report into A2, and for comparison to Dr_Eyeball's posted log in the bug report, here are the .rpt log results in A2: Host (server) initializes the mission as unit 'p1', .rpt log: JIP joins as unit 'p6', then disconnects out to lobby, and rejoins as unit 'p3', .rpt log: It appears the bug is affecting A2. I can't say the bug is the actual cause of the JIP problem in A2 Warfare; but everything I've tried in debugging the scripts has failed. Here is what I found in attempts to debug the problem: So I'm beaten. If it's not the bug, I don't know what it is. I'm returning to SOM-WF compatibility and just accepting that I can only test it while playing on host side for A2 JIP. I did come across some easy script fixes along the way though: (1). Server runs processInitCommands at startup, and JIP players end up processing init script for defenses before their "sideJoinedText" is defined in the Init_Client. Init_Defense.sqf From this: To this: (2). Commas missing between last 2 items in GUI Private arrays. (I don't know if these GUI's are used though? I've never seen a mission selection GUI in game.) GUI_UpdateCommanderViewMission.sqf From this: to this: GUI_UpdateViewMission.sqf From this: To this:

It's part of the SOM initialization and there's no "hide the diary" option.

There's no simple switch on or off for the 'SecOps' diary. You'd have to script it away. The diary entries get initialized in the "hints" portion of the secopmanager.fsm. It's run using soft path "ca\", so you could copy the FSM to your mission file and then comment away the initial diary setup. To run, the FSM would have to be in a folder that follows it's path in SOM. Then you could use custom phase scripts and comment away the diary entries for each SecOp. Phase Script "02_Briefing.sqf" seems to be where they're usually run at. The above will work in beta or in current stable version without Corepatch. But if running stable version with Corepatch addon, the FSM part won't work. The Corepatch sets a hard path "\ca" for the fixes to take effect, so only the Corepatch FSM will run. But the custom phase scripts can still be done.

I found that the server will detect JIP as a player up until side placement occurs. The final portion of the "BIS_WF_PlaceSides" function is causing the server to not recognize JIP as a player when joined to another side than the host: Server_PlaceSides.sqf ("_x" in these lines is a group for each unit synchronized with the WF logic.) Looking for a solution now that doesn't impact OA, which seems to run fine with it.

Definitely A2 WF only. Does not affect MP outside WF.

goliath86, I've been able to narrow the A2 MP Warfare issue down to this: In A2, if JIP joins host side, JIP name will be reflected in PlayableUnits array. In A2, If JIP does not join host side, JIP name will not be reflected in PlayableUnits array, the AI name remains. - Because JIP name is not reflected in PlayableUnits array, WF's OnPlayerConnected script does not find JIP's name as a group leader and the predefined null for team is returned. - The JIP is not recognized as a player by the server unless JIP joins the Host side. That's why the Team_Update script continues to run on the JIP's unit. It runs when JIP joins another side but not when JIP joins the host side. - The JIP player does have full control over their unit, but cannot vote. Clicking a vote will not register. In OA, the JIP name is reflected in PlayableUnits array and server recognizes JIP as a player, regardless what side host or JIP joins. This is tested in Warfare using a customized OnPlayerConnected script, where side was not a tested factor. isPlayer on the PlayableUnits was the tested factor. The test thus far has only been with Factions USMC, RU, and GUE. And I take Groove_C as correct at his word, because the desynch movement was still noticed even when the server registered the JIP player in playable units. Tomorrow I'll start setting up a test outside Warfare with a simple editor mission and OnPlayerConnected script. That should help determine if it's A2 Warfare specific or not.

No, digging through the WF scripts I've come up empty (but still digging). It might be something else, and Warfare just makes it noticeable. Of the four observations: 1 - Choppy AI movement (like continuous desynch) 2 - Units auto-joining 3 - Joined unit vehicles belonging to server 4 - AI fast travel Items# 2, 3 and 4 are observed due to a Warfare script, but item# 1 - the choppy movement - occurs outside Warfare. It's not script-related. It occurs with ping of 2 or 3, and there's no desynch chain. I placed three large groups, about 30 guys, running around an airfield in circular waypoints. Host and JIP stood by on the side watching. in OA stable they ran smoothly for host and JIP. In A2 stable they were observed on JIP machine making the same choppy movements seen in WF. It was not observed on host. The logs again showed "remote object not found" every time the JIP player joined. Each time joined, the object ID indexed up by one. It's present in both, A2 stable and beta. The prior logs were from beta, and here are logs from a run in stable: A2: OA: - For whatever reason, OA always finds the JIP player's group, but in A2 the group is never found. - In every instance when the JIP player joins, a "remote object not found" occurs and the ID indexes up by one for each time joined. - While the same indexing "not found" occurs in A2 and OA, no problem occurs in OA, but in A2 the problem occurs. I tell you, the way it effects A2 stable and beta, and does not effect OA, leaves me wondering if it isn't somehow related to "GameSpy" shutdown? (As I said before, I hadn't JIP'd in A2 in a really long time. The SOM-WF compatibility testing brought me back to it.) And again, we thank you goliath86, you and Dwarden both, for your support! As in :ok:"Awesome!!":respekt:

The A2 WF JIP problem might be associated with group being null. In a bare-bones editor WF mission I used a custom Server_PlayerConnected.sqf and ran "diag_log format" commands in it. Running the mission in A2 and in OA, these are the results from the .rpt logs that appear relevant: arma2.rpt: ArmA2OA.rpt: I'm still chasing down when or where the "Remote object not found" originates. It's seems persistent in OA's .rpt, but not always in A2. A2's .rpt tends to throw different results at times. I looked closely at Garbage Collector, couldn't find anything there that appeared to be a cause. I can't test the MPF because it uses a hard path ("\ca") rather than soft ("ca\"). I have no addon experience to try running a custom. I do have an oddball question about it though:

You might try something like this (not tested): _trg = createTrigger ["EmptyDetector", getMarkerPos "site"]; _trg synchronizeObjectsAdd [TeamLeader1]; _trg setTriggerArea [25, 25, 0, false]; _trg setTriggerActivation ["MEMBER", "PRESENT", true]; _trg setTriggerStatements ["this && (TeamLeader1 in thisList) && isServer", "hint 'trigger activated'", "hint 'deactivated'"];

The WF issue is happening in A2 beta and A2 stable. It does not happen in OA at all, stable or beta. I run CO, so when OA runs the A2 content is included. The JIPtest was hasty and flawed, and I don't know if it was a worthless test or not: - Forgot triggers run on all machines, - Failed to add isServer and !isServer checks, and - Was unaware when a group is created it will only exist until added units are removed. Once made empty, it becomes grpNull. (Wiki said in A1 empty groups remained, and in A3 they are removed. It didn't say about A2) I had to revise the JIP test to be much more reliable. Once I got it working correctly I found that empty groups in game do not carry to a JIP player. An empty group created by the server in game was nil for the JIP player joining the mission. It happened in A2, A2 beta, OA and OA beta, so I figure it must be a known issue. The only apparent value of it was that the test showed the server did recognize JIP as a player, which again left me wondering what's happening in A2 WF JIP, why the team update acts like JIP is not a player. I'm thinking about doing an uninstall and reinstall this weekend, just to see if that changes anything.

onMapSingleClick { _waypoint = patrol1 addWaypoint [[_pos select 0, _pos select 1, 0], 0, 1]; _waypoint [color="#FF0000"]setWaypointType[/color] "MOVE"; // [color="#FF0000"]Should work.[/color] _waypoint setWaypointStatements ["true", "deleteWaypoint [patrol1, 1]"]; };

goliath86 responded to similar in this post: http://forums.bistudio.com/showthread.php?184371-WIP-CorePatch-config-patch-for-ArmA-2-OA&p=2937186&viewfull=1#post2937186 The current beta is under regular OA, it is not the "beta (obsolete)" which I think was prior version's beta. To get the current beta, in OA right-click the game in library and select "properties" at the bottom. Select the "Betas" tab on the pop-up. Hit the drop-down and there are three selections: beta, none - opt-out of beta, and prior release version.

It definitely has an effect outside Warfare. Tested using an editor mission. Interesting results. Placed two units, Host1 (player) and JIP1 (playable). Also placed two repeating radio triggers, to create units to join each caller. - Radio Alpha: "Create Unit (Host1)" - Radio Bravo: "Create Unit (JIP1)" Observations: - JIP could not join after Host created a unit. JIP went straight from unit selection to debriefing. - JIP could join so long as Host hadn't created a unit. That's where it was interesting....

Also remember to: 1) Run Steam as administrator. 2) Download A2 first, and launch. You only need to go to the main screen, then exit. 3) Download OA and launch. Some have had issues from not running as administrator. Some have had issues from not launching A2 before installing OA.

I'm experiencing something weird with A2 Multiplayer CTI Warfare missions. It appears as if the server does not recognize a JIP as being a player. It was first experienced yesterday during a mission test using beta (but should admit I haven't done a JIP in A2 for a long while, if ever), then switched both machines over to current release and the same issue continued to occur there. - I figure it's not the mission. I had a custom mission, then I ran one of the game's MP missions, then laid down a simple editor MP Warfare mission, and the same occurred in all three. - I figure it's not the machine. I have two machines on LAN and regardless which machine was used for server or JIP player, the same occurred. - The JIP player was the one experiencing the problems, the host was not affected. - This is experienced in A2 (not OA), in beta and in "reverted-back-to" release version. To reproduce, go into A2 and launch a multiplayer CTI Warfare mission, like "When Diplomacy Fails". Vote for commander AI and wait for missions to be assigned. Then have a JIP player join in on the opposing side. The observations: 1) Stuttering movement of units and objects. Like two sessions in one occuring with a very slight desynch. The units fluctuate back and forth a few inches or a foot. 2) JIP player automatically receives units from the barracks, and calls them out to join (AI reinforce action) 3) If one of the units is mounted, JIP player cannot board or order them to disembark (response is "No can do", indicating belongs to server) 3) After all units appear, JIP player automatically teleports to nearby location, if available (AI fast travel). For #'s 2), 3) and 4), I'm sure it results from the server running the AI Team_Update.sqf, which in a number of places is suspended when the leader becomes a player. The script continues to run, as though the server doesn't recognize the JIP player is a player. It's also supposed to run the OldSupportUpdate every few seconds when the leader is a player, and in my custom mission the OldSupportUpdate did not run, again supporting the thought that the server is not recognizing JIP player as a player. I'm hoping someone can post back saying they don't experience it, though it would leave me clueless as to a cause. ---EDIT -------- Reverted back to beta. Found it doesn't happen for player joining at start, only for JIP, so I can at least continue the mission testing using join at start. I'm positive the server is reading the JIP player as an AI. I did one run using "disable AI." Upon JIP there was no base, on map there were no markers. Approaching a town held by Resistance, the outer camp signboard showed West flag (<Host side... JIP was East). Also, the custom mission had SOM synched to each playable unit with SecOps in the pools, but is scripted so that only players get SecOp assignments, not AI. The support function is scripted to run only for players, not AI. For host and joined player the Secops and supports occurred. For a JIP player, they did not. This appears to affirm the server considers the JIP player to be an AI.

A group must be empty to be deleted. I'm just guessing it's dependencies. A unit is dependent on its group, like a group is dependent on its side (center). You can have a group without units, but not a unit without group.

BIS_fnc_spawnvehicle returns an array containing: [vehicleUnit, [unitOne, unitTwoIfPresent, unitThreeIfPresent], Group] This will delete all: deleteVehicle FC1veh; deleteVehicle FC2veh; {deleteVehicle _x} forEach units FC1grp; {deleteVehicle _x} forEach units convoyGuardFC; deleteGroup FC1grp; deleteGroup FC2grp; deleteGroup convoyGuardFC; Deleting the vehicle first leaves dismounts, cleaned up using 'forEach Units'. Then the group is removed. The FC2 unit doesn't need to be deleted, because it's only the driver and deleting the vehicle deletes the driver as well. Your issue with the driver has to do with the vehicle object reference. BIS_fnc_spawnvehicle does not return the vehicle's object reference, it returns the vehicle's unit reference - which is the driver. When the driver dismounts, the unit reference goes with him. To get the vehicle object reference, you might try running 'nearObjects' for the vehicle type (after the driver has dismounted): FC1vehObj = FC1veh nearObjects ["HMMWV_M1151_M2_DES_EP1", 100]; FC2vehObj = FC1veh nearObjects ["MtvrRefuel_DES_EP1", 100];

mrtinkerjeep on Steam discussions pointed this out, and I can verify it having encountered it myself.... Running A2 Beta alone without OA, the "Harvest Red" Campaign failed at start of mission: "Manhattan". On the previous mission, "Razor Two", this pop-up message occurred at start: The UAV terminal in the mission was unusable. When starting "Manhattan", this pop-up occurred repeatedly and the mission would not launch: It appears something in the A2 campaign is looking for OA content?

{unassignVehicle _x} forEach units convoyGuard; {doGetOut _x} forEach units convoyGuard;

try this: {_x assignAsCargo convoy1} forEach units convoyGuard; units convoyGuard orderGetIn true; Works in an editor trigger.

I restarted the campaign and ran the mission (running beta on my machine). It didn't happen, so I don't know what to tell you. What I did observe was when we moved away, over time the map marker of the vehicles disappeared. I guess knowledge timed out, or they became 'unassigned', or whatever. But when we completed and came back they were still in place.

Running beta 1.63.130810. script error occurred in the OA Alice module: Error in expression <_e\alice2\data\scripts\init-alice2.sqf' _logic = _this select 0; _logic setpos [> Error position: <_logic = _this select 0; _logic setpos [> Error Missing ; File ca\modules_e\alice2\data\scripts\main.sqf, line 14 Was running the BAF campaign mission 02: Lancers. The error occurred only once at mission start. No Alice civilians appeared that I saw, only the mission ones did. Then I went to SP editor and placed only a unit and OA Alice module. The error spammed the .rpt file.