opusfmspol

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.

Don't know about the lights. The vehicle has a driver, so he's going to drive regardless of what's attached. You could have the driver disembark. You could try commandStop or doStop on the vehicle driver. You could try disableAI "MOVE" on the vehicle driver. Use commands on "driver convoy1" and not "convoy1", so the command doesn't affect the gunner. Use assignAsCargo along with ordergetIn to have them board the vehicle afterward.

_this refers to whatever was passed into the script from the execVM array. It likely fails because execVM passes an empty array [], so nothing is passed into the script for "getPos _this" to use. https://community.bistudio.com/wiki/Arma2:_Startup_Parameters Use launch options -showScriptErrors and do not use -noLogs. You will see errors on screen when they occur, and have the error generated in the .rpt file for review. Quite often the -showScriptErrors box will display a "[#]" in front of the command or variable that generated the error. Also, the line: _grp = createGroup west; is not needed, the BIS_fnc_spawnGroup does that inside the function using the side designated in the call array.

Make sure of the file extension. If you have "show file extensions" turned off you wont see that notepad saved it as spawneastgroup1.sqf.txt. Have file extensions show and be sure to save as "all files".

The Warfare scripts for Server_SupportUpdate in A2 and Arrowhead don't match. The A2 script contains an incorrect fix causing error, but the Arrowhead script contains the correct fix, no error received. I started rebuilding the Secops-Warfare mission from scratch in editor, relying only upon scripts from current beta release. To insert custom phase scripts the WF Server_SupportUpdate was borrowed from the A2 .pbo. When the support update began running, this error occurred and no supports became available (used a funds trigger to afford the supports): Error in expression <le "mainScope";[color="#0000FF"]_side =[/color] [color="#FF0000"]side[/color] [color="#0000FF"]_mainScope getVariable "side";[/color]_sideText = WFSideTe> Error position: <getVariable "side";_sideText = WFSideTe> Error getvariable: Type Side, expected Namespace,Object,Group,Control,Team member,Task,Location File C:\Users\<redacted>\Documents\ArmA 2\mpmissions\betaTestBasicSOMWF.Chernarus\Server\Functions\Server_SupportUpdate.sqf, line 60 I found in Arrowhead expansion's .pbo, the line was correct there, so I borrowed from it instead. No error occurred and supports became available. (The correct line is _side = _mainScope getVariable "side"; ) I checked with another basic editor placed mission, no scripts, and confirmed that running the mission in A2 the error occurs, but running in Arrowhead it doesn't.

(Oops, sorry, wrong thread. Moved to here. Admin can delete.)

I suspect the options are switching between beta and current release, and using Corepatch addon from Expansions when running current release version. My thought is that activating Corepatch addon from Expansions wouldn't work in beta, but I honestly don't know which would take priority over the other or if they would create conflict. Dwarden's comment above on obsolete Corepatch files leads me to think they would. I was able to switch between beta and current release version, then back to beta pretty quickly on my machine. A couple minutes for the update to kick in, about a minute for the update to occur. I ran Steam as administrator since that seems to be important when downloading and doing first launch. I was able to join a public Domination server from both current release and beta. I got the current release errors when not running Corepatch addon from Expansions. Switching to beta I was still able to join the server and only saw a couple mission-related errors appear. No filepath pop-ups occurred, likely because the server's mission didn't rely on Corepatch filepaths within its own scripts. When first trying I got forever "wait for host", but GameTracker revealed the server was joined by a certain group for a few hours. Maybe the host had a clan event going on or something. Once GameTracker showed usage spikes again I was able to join the server with no problems.

I noticed in Warfare that the data fixes are implemented in the warfare2.pbo scripts, so what were diversions to Corepatch filepaths have been returned to the original file paths. For beta A2 I did have to replace the Init_Client and Init_Server borrowed from Corepatch once I realized the ones I used to customize my Warfare mission still contained the Corepatch diversions. Current beta A2 doesn't include Corepatch? Ran nicely in A2 then. One unknown script error occurred as noted here.

I added an observation to the thread above. With the new update, if a mission being run in beta A2 has borrowed scripts that define functions relying on Corepatch filepath, Corepatch filepath errors will occur.