opusfmspol

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.

I think it's a matter of addons in the new update not relying on Corepatch filepath (or not relying much on Corepatch filepath), where addons used by the servers your trying to join are still relying on Corepatch filepath. And the new update has new keys for the updated addons. The servers with the older addons won't have the updated keys. I base the observation on the Corepatch pop-ups appearing in the SOM-Warfare mission I was building in beta prior to the current update. In beta A2 it gave me a corepatch pop-up like above, but not in beta OA. In A2 rpt it listed a number of Corepatch filepath errors. Then I realized, to customize the Warfare mission the mission borrowed scripts from beta prior to the current update - Warfare's Init_Client.sqf and Init_Server.sqf. Those two scripts defined functions using Corepatch file paths. Once I swapped those scripts with the current update's version of Warfare scripts, the pop-up stopped in beta A2. ----------------------- Starting a Warfare mission in beta A2, I do get this error: Error in expression <C_trashItFunc;};};} forEach entities "Man";{if (!alive _x) then { _dontCa> Error position: <"Man";{if (!alive _x) then { _dontCa> Error Missing ; It doesn't happen in beta OA. I don't know what it affects in beta A2, I haven't noticed anything from it yet.

I wholeheartedly agree, no new bugs wanted! A lot more playtesting is still needed, in MP SP and SOM-only missions. I considered that having SOM server send codebursts for clients to update their own menus would create more network traffic, but found the server was already sending codebursts for clients to toggle their comms menu; so all it did was swap one codeburst for another and put the menu update on the client, rather than the server updating each client's menu and broadcasting it (causing the fluctuating menus). Having the client create the Transport and Supply Drop aircraft works perfectly, but more testing is needed to ensure the transportService.fsm completes after the vehicle gets destroyed or deleted. I don't think it does right now. Regarding complexity, there were (9) scripts and (1) FSM worked with: Module: Script or FSM: Change Made: ------ ------------- ----------- Warfare Init_Client.sqf added: SOM SecOps menu Warfare Server_SupportUpdate.sqf codeburst to client for menu update SOM updateCommsMenu.sqf removed: menu PV's + codebursts to toggle comms SOM addSupportRequest.sqf codeburst to client for menu update SOM processEvent.sqf codeburst to client for menu update (2x) SOM registerTopic.sqf codeburst to client for menu update SOM unregisterTopic.sqf codeburst to client for menu update SOM [color="#A9A9A9"]fsms\secops\[/color]secop.fsm codeburst to client for menu update SOM [color="#A9A9A9"]transport\[/color]07_create_secop_assets.sqf client creates transport vehicle SOM [color="#A9A9A9"]supply_drop\[/color]07_create_secop_assets.sqf client creates supply drop vehicle I very much appreciate your considering of it, thank you quite much. I'll PM a write-up and a sample mission once I get all ironed out.

Goliath & Dwarden - http://forums.bistudio.com/showthread.php?73329-Secondary-Ops-Manager-Module-Discussion&p=2934285&viewfull=1#post2934285 I don't have full notes on these yet though I am putting them together; I was wondering however, would making SOM and Warfare "plop-and-play" compatible be considered worthy under Corepatch / Beta? It would mean the SecOps menu could be activated in Warfare. There are also some very, very few phase script nuisances occurring that might be addressed. kbTell needs player kbHasTopic checks before first speech; not all content/installs are removed under all three decisions (timeout, not accepted, accepted); and some such things, all of which only affect particular missions. ------------------------ There is one Warfare fix I'd like to suggest for now (correcting a 'less-than-perfect' fix I am responsible for): The Warfare script Server_SupportUpdate.sqf is only run when BIS_WF_OldSupportLevel = 1, indicating SOM is being used for supports. It runs a funds check to see if a leader can afford a support. Occasionally a bad funds check occurs when the leader has been killed. It uses player side to determine which funds to query, and player side is switched to civilian when killed. A delay was previously set up and included in Corepatch to allow the player time to respawn; however I have found it wasn't totally effective. Once in a while a bad funds check does still occur when the player side returns civilian for a moment or so after respawn. When the error occurs it effects gameplay because the affected player can't buy units or equipment. Respawn doesn't help, they have to disconnect and reconnect to reboot the funds variable. It ends the mission if the host has to disconnect. The player's side is registered in their SOM mainscope at game start, and the mainscope will always return side joined. The mainscope's side should be used instead of the player's side. It removes need for one of the added delays. Also, it would be good for the Player ID delay to have a small sleep, to take some pressure off the server: current: _leader = _this select 0; waitUntil {Alive _leader}; _clientID = _leader call GetClientID; While {_clientID < 1} do {_clientID = _leader call GetClientID;}; _side = [color="#FF0000"]side _leader[/color]; _sideText = WFSideText _side; _fundsVarName = format ["%1player%2funds", _sideText, _clientID]; //eg. eastplayer1funds _mainScope = _leader getVariable "mainScope"; suggested: [color="#808080"][i]_leader = _this select 0;[/i][/color] [color="#0000CD"]_mainScope = _leader getVariable "mainScope";[/color] [color="#808080"][i]_side = [/i][/color][color="#0000CD"]_mainScope getVariable "side";[/color] [i][color="#808080"]_sideText = WFSideText _side; _clientID = _leader call GetClientID; While {_clientID < 1} do {[/color][/i][color="#0000CD"]sleep 0.25;[/color][color="#808080"][i] _clientID = _leader call GetClientID;}; _fundsVarName = format ["%1player%2funds", _sideText, _clientID]; //eg. eastplayer1funds[/i][/color]

-- 17 Nov 2011 Yes, a very old post to respond to, sorry for that, but good findings for people to know. I'm working on a SOM-Warfare mission and have gotten things to work together very well thus far. --------- It would appear the SOM Transport and Supply Drop support requests don't work on dedi because they rely on the transportService.fsm in Functions. First defined variable in the FSM is "_clicker = player;". The clicker is passed in as select 0, I don't know why it's not used; but I'm only starting to work with the FSM so maybe I'll discover why. Clicker is relied on pretty much in the FSM, so clicker being player would lead to failure on a dedi. // edit: found the FSM was designed to be run by the calling client. --------- The communication menus fail in multiplayer because SOM server queries and builds a leader's menu and then PV's the menu, and all players reflect the menu of whichever leader the server was querying at the moment. The result is fluctuating menus. From one moment to the next everyone's menu reflects a different leader's menu, and in an adversarial mission it might not even reflect menu pertaining to side. I found a workable solution by removing the public variable from the comms menu update and having the SOM server send codebursts to clients instructing them to build their own menus. // edit: resolved in beta --------- The same "hover" bug affecting the transport support also affects the supply drop, which drops cargo before ever reaching the drop zone. Another issue related to the transport FSM, however the transport FSM itself is not actually at fault. The "unitReady" command is at fault. The FSM uses the unitReady command as condition to determine when the transport helo should land, and the supply drop aircraft should drop cargo. I found the unitReady command only gives an accurate return if run by the client to whom the object belongs. Anyone else running unitReady on an object will always return "true", even if the unit is not ready. The FSM is run by the calling player, but the support vehicle is created by the server. The calling player is running a unitReady command on an object that does not belong to them, and it will ALWAYS return true, which causes the FSM to advance before the aircraft have reached their destinations. This is also why the supports work for host, but not for joined players. I found a workable solution by modifying the phase scripts so that the server sends codeburst to calling client instructing them to create the vehicle, and return it as a public mainscope variable so that the server could continue to run scripts with it. // edit: resolved in beta. ---------------- I hope these are found useful.

Killed units are switched to side civilian. Maybe the respawn being instant isn't letting the player's side switch back to their side joined? Could test the thought with a small delay. Or a trigger querying and hinting player unit's side when the problem is noticed.

another consistent JIP error, this one spams host and JIP player continuously after the JIP player joins: Error in expression <esNew = _gainTimesNew - [-2]; _params = _params - [-1]; _mainScope setVariable> Error position: <_params - [-1]; _mainScope setVariable> Error Undefined variable in expression: _params File ca\missions\som\data\scripts\functions\isAvailableSupportRequest.sqf, line 64 - I'm running two machines with beta on LAN, local hosting, not dedicated. - The mission is a BIS Warfare CTI using custom client init (Corepatch beta version) only for Warfare with SecOps comms, and a SOM synched to each leader. - The host machine is spammed because of the server's support update, and the JIP machine is spammed because of the client's options update. Though generated by a SOM function script, the error originates in this line of the Warfare Server_SupportUpdate.sqf script: if ((_balance < _price) || _removeAll) then {//remove given support _mainScope setVariable ["gainTimes_" + _x, []]; //TODO: convert to BIS_SOM_removeSupportRequestFunc } else {//add support [color="#808080"][i]//*side note: "_x" is the support name. There is no "remove support" function, seems it was an intent.[/i][/color] Running it down I found SOM support checks need "gain times" and "params" set. The SOM function checks for both. At JIP, funds are low and a player can't afford supports. The line initializes the gain times, but not params. When a support can be afforded and gets added, the default params is generated if no param is passed. An empty array is the default params. Warfare doesn't pass params if adding a support, so default is okay to clear the error. This resolved the error: if ((_balance < _price) || _removeAll) then {//remove given support _mainScope setVariable ["gainTimes_" + _x, []]; //TODO: convert to BIS_SOM_removeSupportRequestFunc [color="#FF0000"] _mainScope setVariable ["params_" + _x, []];[/color] } else {//add support After working this out, I enjoyed hours of playing Warfare with SOM Secops thrown in. :627:It was great! :coop: :681:Each leader had his own call sign set up, no confusion there, each got their own SOM side missions as well as the regular Warfare missions. The only real nuisance was the "support comms over network" issue, which even before beta, they only ever worked for host, and the join player calls for support caused confusion in the SOMs. It's the only reason I haven't suggested having Secops Comms for Warfare added to Corepatch.

Günter, your script has: [color="#FF0000"]_PlaneGroup = creategroup WEST;[/color] _plane1 = createVehicle ["LIB_P47",_planespawnpos1,[], 0, "FLY"]; //plane class name goes here _plane1 setPos [(getPos _plane1 select 0),(getPos _plane1 select 1),300] ; _plane2 = createVehicle ["LIB_P47",_planespawnpos2,[], 0, "FLY"]; //plane class name goes here _plane2 setPos [(getPos _plane2 select 0),(getPos _plane2 select 1),350] ; _plngrppLeader = "LIB_US_pilot" createUnit [getMarkerPos "attack", [color="#FF0000"]_PlaneGroup,[/color] "plaleader=this"]; //pilot class name goes here _p2 = "LIB_US_pilot" createUnit [getMarkerPos "attack", [color="#FF0000"]_PlaneGroup,[/color] "pla2=this"]; Your pilots are on BLUFOR side, so they would be attacking whichever side BLUFOR is hostile towards.

Received this error on JIP. The error does not appear for host: Error in expression < = ["GUE", "RU", "INS", "CIV_RU"]; if (_faction in _westArr) then {_hq setIden> Error position: <_faction in _westArr) then {_hq setIden> Error Undefined variable in expression: _faction File CorePatch\CorePatch_SOM\data\scripts\init.sqf, line 184 I'm running two machines with beta on LAN, local hosting, not dedicated. The mission is a BIS Warfare CTI using all custom init scripts, with a SOM synched to each leader. The SOM's are running custom phase scripts for the supports, but rely on their init and FSM paths from beta. The JIP machine received an error for each SOM in the mission. Only guessing, but does the Corepatch SOM init need to wait for player to become local? I know Warfare's client init does, at one point it has: if (!Local player) then { WaitUntil {Local player}; };

For switching between beta and live, should Corepatch be removed from addons folder to run the beta, or just deactivated and left in folder? Just wondering if the engine would confuse any Corepatch addon files with the beta's files.

Example taken from the SOM "transport" support: _transportVehicle setCombatMode "BLUE"; _transportVehicle setBehaviour "CARELESS"; _transportVehicle allowFleeing 0; The transport helo flies in a straight line, and will fly into the teeth of an AA gun if one lies between the pick-up and drop-off points.

The error is telling you that you are using Count command against a string rather than an array. Variable (_worldspace select 1) is returning a string. You're running a count command on it as though it's expected to be a position array. Run a diag_log command on worldspace select 1 to see what it throws in the Arma2OA.rpt

Command "setFriend", used at mission start: https://community.bistudio.com/wiki/setFriend Side relations: https://community.bistudio.com/wiki/Side_relations In 3d Editor it's possible to create multiple BLUFOR and OPFOR centers with separate groups under them. The center's have the friend setting. Perhaps after a "fired" event handler goes off, transfer all units from groups under one center to groups under the other so the new friend setting filters down? Haven't tried it though, don't know if it would work. Could also try setCaptive. https://community.bistudio.com/wiki/setCaptive

Just encountered similar. The file line given was "C:\PROGRA~2\McAfee\SITEAD~1\sahook.dll". It blocked an extension file for McAfee's Site Advisor, an addon that gives green/yellow/red flags on website searches. This happened immediately after OA did a BattlEye update. It didn't effect startup or the server list populating though. Now have to see if it effects joining a server. -------------Edit ------------- Was able to join a public server with no problem

These videos by Dany Mitchel helped me out:

Give the Corepatch addon by goliath86 a try. http://forums.bistudio.com/showthread.php?184371-WIP-CorePatch-config-patch-for-ArmA-2-OA I don't have any experience with headless client so can't attest to how it will do. Headless client is basically a scripted AI dedicated client joined to a mission as a playable unit and running scripts which command a side in order to relieve script pressures off the server, is that correct or no? I would think Corepatch shouldn't hurt, and might help. It resolves most of the errors which resulted from v1.63. Even if your custom mission is designed to rely on the old method of nil variables held as placeholders, it could help. With v1.63 nil variables are removed entirely, there is no name as a placeholder anymore. That's what many of the "undefined variables" errors are about. Corepatch resolves errors generated by the modules and official missions, but those written into a custom mission.... It won't touch those; the mission scripts have to be addressed, and that's where -showScriptErrors and not running -noLogs helps. Corepatch removes a lot of the module errors so you can readily see the mission script errors. They won't be buried in the module errors like they normally are.

I don't know how to restrict it like that, but my own approach would be using the respawn point as an assessment site. Set the respawn marker off the map border somewhere and place another marker where the intended player respawn point would have been. When a unit respawns off map, an event handler would run something like: if (isPlayer _thisUnit) then {_thisUnit setPos (getMarkerPos _Marker1)} else {deleteVehicle _thisUnit}; So when players respawn they relocate to the base marker, and when AI's respawn they get deleted.

The SUV has no editor-placed waypoints. The scene uses motion capture saved to script as the means of moving the SUV. So it may be a script failure in your missions_e.pbo file. Try verifying integrity of the game cache in Steam. In Steam games library, right-click the game and select "properties" at the bottom. Select upper tab "Local Files". You'll see a button "Verify Integrity of Game Cache...". It'll check your files against what they should be.