opusfmspol

The drag and carry part of First Aid, no addAction appears to drag the wounded unit, and there is no carrying since you first have to drag him. This occurs in missions when the First Aid modules are synched to units. It impacts on missions and the Basic Training medical aid scenarios. Thanks Goliath! -- edit: Running CO in beta mode. Occurs in A2 and OA.

Try removing the space between "=" and "@" maybe?

Maybe you mean the Commander View camera? Numpad period [ . ] is the default. But the camera stays with you (the Commander).

I don't know, on both counts. Somebody more knowledgeable would need to weigh in on that. Tested, and this works in an init.sqf: The magazine lines that are commented out, if you uncomment them the units will start with no magazines except the three ACE items. The lines are there for if you or somebody wants to try doing full magazine loadouts for each of the unit types. // edit -- ha, I edited as you were posting. Glad you worked it out.

Regarding the example you mention, BI has published most of the A2 PBO's on the Arma Licensed Data Pack (ALDP) webpage. The ACR missions PBO is part of the ALDP, and falls under the Arma Public License - Share Alike (APL-SA). The missions_acr.pbo is found in the ALDP_A2OADLC_PBOs_APL-SA.zip at the bottom of the ALDP webpage: https://community.bistudio.com/wiki/Arma_Licensed_Data_Pack https://community.bistudio.com/wiki/Licenses What it means is you -can- download, open, copy and modify missions from the PBO. It must be done under the terms of the APL-SA license. It mainly governs the sharing or releasing of what you make from the PBO. Once you have the mission, the script block posted above could go in the mission's init.sqf, or it could go into any script getting called, spawned, or execVM'd by another source. It could even go into an object's init line in editor, but you first would have to replace the _local variables with global ones since _local variables don't work in editor. (except the magic "_x" - they would remain the same. They have a special property involving scope :ph34r:) But first create a mission with a few units and run it using an init.sqf to see how it works. For vehicle crews, I would think inside the "forEach _units" you could add cycles for each crewmember (not tested): Scripting is a learning experience, and as with every learning experience, crawl... :confused: walk... :mellow: run... B) Ignore the grey hairs and rising blood pressure, it's both incidental and inevitable. :butbut:

This should cycle through each unit in each group to give infantry soldiers a medkit. It will only do so for infantry, not for mounted units (Air, Armor, Mech). They would need separate commands detailed for them. It also doesn't check the soldier's inventory space first, so it might not work if the unit doesn't have the space for it. Change the conditions, pile up and change the inventory commands as you wish, but basically your cycling each group, and each soldier in each group, to give or take away from them what you want. You could add a block for vehicles that cycled through the crew.

I'm thinking it has to do with this part of the "spawnvehicle.sqf" in the module: OLD: CURRENT: Maybe the SetPosASL needs the setVelocity command to following it. Or maybe SILVIE could benefit from execVM'ing Warfare's "Common_GetSafePosition.sqf" script prior to actually creating the vehicle. From _pos it would search within 25m radius for a position with no objects inside a 12m radius. And the defaults 25/12 are adjustable as params. If object collision is the cause, I don't know that either could eliminate the problem totally, but maybe they could help.

I've had the same with vehicles on all maps, but my own observation has been that some vehicles spawn in at ground level then launch into the air for having contact with something. It seems to depend on if they have contact after spawning, and maybe the way they have contact with some object while spawning. Like Mirek's image shows, vehicles often end up riding on objects. Most vehicles don't launch but sometimes they do.

It seems to affirm what I thought, with dedicated server the "waituntil {player == player}" in SSM's init results in clients getting their functions, but the server hangs and doesn't get its functions. I'll get you some edits which will hopefully clear it (and add a header to description.ext)

See if this works first: End after mission has run for 60 seconds while {time < 60} do { _aliveCount = count allUnits; _aliveSelect = _aliveCount - 1; _randomSelect = round random _aliveSelect; _newTarget = allUnits select _randomSelect; _camera camsettarget _newTarget; _randomX = (random 6); _randomY = (random 6); _camera camsetrelpos [_randomX,_randomY,4]; _camera camcommit 0; sleep (3 + (random 6)); }; Having {true} as the condition is what makes it keep running. It needs to be a condition that can return false if the condition is not met, and true when the condition is met. There are exceptions when you would want to use true; i.e. if you wanted it to end after a certain unit was viewed, that would get detected inside the loop, and then you would have to use an exitWith, or a scopeName with breakTo.

You need a condition. What has to happen for the loop to stop?

The "Bear Rising" mission.sqm has an airport object which is attempting to execVM the CorePatch_WF\Scripts\Server\Server_UpdateAirport.sqf. But the WF updates are in the WF module now. The mission's airport object needs to be set to execVM on the WF module script again.

Do you have a test .pbo of the mission which is sharing the same folder name as the editor mission perhaps? That gave me similar problems with editing campaign missions, I couldn't figure out why edits I was making to mission in editor wouldn't work. Example: 1) edit a mission in editor. 2) save editor mission to multiplayer, it creates a .pbo. 3) test the .pbo, identify corrections to make. 4) edit the mission in editor a little more. 5) if you launch the editor mission, the .pbo will run instead, since it uses the same folder name inside. In this situation, the tested .pbo has to be moved or deleted before the editor mission will run again.

I can attest that this particular error is not a patch regression, it is a rare error of the First Aid (FA) module "healer.sqf" that has been logging since v1.63 came out. It occurs when FA and Battlefield Clearance (BC) modules are both used. It seems to occur when a dragger is releasing a wounded unit, and the variable "BIS_BC_dragger" is nil. The error is so rare in my own missions I never figured out why "BIS_BC_dragger" would be nil. This is what I think is happening: in "healer.sqf": _healerIsAlreadyDragger = _healer getVariable "BIS_BC_dragger";if (isNil "_healerIsAlreadyDragger") then {_healer setVariable ["BIS_BC_dragger",false]}; _healerInAgony = _healer getVariable "BIS_IS_inAgony";if (isNil "_healerInAgony") then {_healer setVariable ["BIS_IS_inAgony",false]}; //if (_healerIsAlreadyDragger) exitWith {textLogFormat["FA_HEALER_ EXIT _healerIsAlreadyDragger %1",[_injured, _healer]];}; //cannot be dragger-healer if (_healerIsAlreadyDragger) then { //stop drag //see (BIS_BC_Path + BIS_PATH_SQF + "draggerStop.sqf") ... this block should correspond detach _injured; In the script, if unit's variable "BIS_BC_dragger" is defined, it gets used to define _healerIsAlreadyDragger. When unit's variable "BIS_BC_dragger" is not defined, it gets defined as false. But _healerIsAlreadyDragger is not defined again after the unit's variable returned nil. The script continues on with the _healerIsAlreadyDragger undefined, which causes the error. The same would seem to happen with _healerInAgony if "BIS_IS_inAgony" was undefined, but I never encountered that error. The _healerIsAlreadyDragger error was rare.

Forum FAQ: https://forums.bistudio.com/topic/86676-frequently-asked-questionsrequests/ Armaholic FAQ: http://www.armaholic.com/forums.php?m=posts&p=54512#54512 Modules: https://community.bistudio.com/wiki/Category:ArmA_2:_Editor_Modules Triggers: https://community.bistudio.com/wiki?title=2D_Editor:_Triggers Warfare: https://community.bistudio.com/wiki/Warfare_2_Manual Scripting Commands: https://community.bistudio.com/wiki/Category:Scripting_Commands_ArmA2 Object ClassNames: https://community.bistudio.com/wiki/ArmA_2:_CfgVehicles Some good stuff to know: https://community.bistudio.com/wiki/6thSense.eu:EG Also YouTube when searched has lots of videos on how to do different things in editor. When logged in here the search function at top will list postings that it believes is related to the searched topic

To delete a marker you need its name; so if you have or can get the array of names, then yes, otherwise no.

Aha.... I just realized the "BIS_ACM_0", "BIS_ACM_1", etc., markers will NOT affect all of the ACM's, only one. They're only good for a mission with one ACM. I amended previous post. During initialization, after the marker blacklist gets registered, the marker gets deleted... which means the blacklisting only occurs for the first ACM that initializes. When the second and third ACM's initialize, the marker is gone. Makes me think that adding the blacklist to each ACM after the modules have initialized and mission starts would be the better way to go.

The SOM does not have blacklisting of areas. I know exactly what your talking about, in one testing mission I had SecOps taking me further and further into no man's land. I eventually got annoyed and kept declining SecOps until I returned to the operations area. The ACM does have blacklisting of areas though. You place markers in editor to create the beginning blacklisted areas. You number the markers upward from 0, i.e.: "BIS_ACM_0", "BIS_ACM_1", "BIS_ACM_2", "BIS_ACM_3", etc., etc. Keep in mind these marker blacklisted areas will affect all of the ACM's. Correction: These markers only affect one ACM. After the game starts, markers, triggers, and arrays with [top-left,bottom-right] position coordinates can be used to add blacklisted areas to any specific ACM during the mission. But you cannot remove blacklisted areas unless you can identify which array you want to remove from the list (it's a bunch of coordinates). To add a blacklist area, you use "getVariable" to get the current list, then add to it the marker, trigger or array. You then use "BIS_ACM_blacklistAreaFunc" to update the list in the ACM: EXAMPLE: Blacklisted areas will only stop units from spawning there. It will not stop the created units from wandering into the zone. Unfortunately, adding blacklist ability to SOM doesn't look feasible for the patch for a few different reasons. It's something best left to mission makers, using custom phase scripts in their mission folder. I'm sorry, in earlier posts I don't know why I was reading "ACM" as "SSM". Getting old and senile maybe? Anyway, I looked through the ACM with dedicated server in mind, but all I could find was that the Garbage Collector would fail. When GC processes its list of bodies, it checks group player to see if player is near. But I didn't get the impression that it would stop the ACM.

I will look at those. There might be a way of using markers? But I don't recall right away. In the meantime, I sent you a PM about trying to make the SSM work for a dedicated server.

Expanding on Mirek's suggestion, I would suggest placing markers, designated for a side, at the possible group locations and in "init.sqf" run something like: { _chance = random 1; if (_chance > .5) then { [getMarkerPos _x, East, ...etc, ... etc. ] call BIS_fnc_spawnGroup; }; } forEach ["eastMarker1","eastMarker2","eastMarker3","eastMarker4","eastMarker5","eastMarker6"]; Groups won't start spawning until the game actually begins, but each group won't be created unless their random chance is met. Could also put it in a trigger but be sure to place the trigger after all markers are placed and saved. If the trigger initializes before a marker being used, it would cause a failure.

Try setting it to Countdown instead of Timeout: https://community.bistudio.com/wiki?title=2D_Editor:_Triggers&redirect=no#Countdown.2FTimeout_Counters Countdown - Once the trigger's conditions are met, the trigger will activate after the specified amount of time has elapsed. The activation conditions do not need to remain satisfied during this time. Timeout - The trigger's conditions must be satisfied for the entirety of specified amount of time for the trigger to activate. For example, if a soldier walks into a <side> Present type trigger but leaves the area before the timeout is complete, the trigger will not activate.

SSM: - Place only one on the map. No synchronizing is done. It is 'drop-and-play' like the ALICE module. ACM: - Place as many as you want on the map. Only synch one unit to each ACM and it doesn't have to be a leader. Any unit can have more than one ACM, but an ACM cannot have more than one unit. Each ACM generates its own combat based on its settings. SOM: - You can place as many as you have group leaders for on the map. Synchronize to any group member, but should prefer the group leader. A group gets a SOM of its own. Only the groups that have a SOM will receive SecOps. Each SOM will provide its own SecOps. When SOM initializes it registers the leader as the person to receive the missions, and registers the group members as well to track who is dead and who is alive. The SOM terminates when the group is empty. Yes. Each has to have their own settings. With SOM it is important to give each group a separate call sign of their own, otherwise everybody is 'Alpha' and it's hard to know who a mission is called for. Each SOM can have the same pool set ("settings"). But the modules will work independently. Each will give the missions separately. The only way to have two SOM's do the same mission at the same time is to have both call an immediate SecOp using params; but then you have duplicate radio calls, convoys, bad guys, etc. Each ACM will respond to its own intensity setting, and stacking does occur like that. It's always random against the intensity setting whether anything generates.

Each SOM only allows one group to be synched to it. If it has more than one group, it will select the first group and discard the others. Each group can have their own SOM in multiplayer. That's one of the patch fixes. before the patch, having more than one SOM in a mission caused each player's menus to fluctuate. But now the menus are updated by client instead of server, so they won't fluctuate. Each leader sees only their own menu. Keep in mind that if each group has their own SOM, they will receive their missions separately. Each SOM works independently. The leader installs were fixed as well, so that leadership will transfer to a subordinate when the group leader gets badly wounded or killed. It transfers back if the group leader is healed or respawned. If a person disconnects and their unit becomes an AI leader, the SOM should only stop working until a player fills the slot. The AI no longer receive SecOps, they were never scripted to accept them or carry them out. The mission calls to them would always time out.

I see lines in SSM that would seem to be player/objnull issues for a dedicated server. Also, the SSM follows a hard path to its "init.sqf" script, which has almost all of the code, variables and functions. To work the issues one would first have to recreate it as an addon. (Correct me if that is incorrect.) The SOM takes a soft path to its "init.sqf", making it easy to work with in editor missions. Where a DS problem is found in a SOM script, the problem script can be copied to the mission folder, using a recreated folder path, or as custom phase scripts, and worked with until the issue resolves. It's how I could work on hosted MP issues. - Under Legacy, both SSM and SOM will still have the same dedicated server issues as before. - Under None and Beta, the SSM looks like it would still have the same dedicated server issues as before. - I don't know if SOM will work on a dedicated server under None or Beta. Fixes for hosted multiplayer and to be Warfare compatible were included as part of the patch. ---- Edit: Made a correction above, forgot "none" means the patched version; also - Observation: ----------- From your OP it would appear you use the SOM for transport support with a "TSS_vehicle_custom" editor vehicle? Even under Beta, the SOM Transport support will have issues with a TSS_vehicle_custom when called by a joined client (but see suggestion below). Information: ----------- One issue that both Transport and Supply Drop supports had was that the aircraft belonged to the server, but the client must run the "transport.fsm" which controls them. The supports always worked for the host, but not for joined clients. The transport.fsm uses command "UnitReady" on the aircraft as a condition to advance scripts; but "UnitReady" only returns an accurate result when done on the machine the unit belongs to. On any other machine it will always returns "true", even when the unit is not ready. The joined client was running "unitReady" on an aircraft belonging to the server, and it would always return "true" even when the aircraft was not ready. The issue was resolved for dynamic vehicles (spawned by the SOM scripts) by having them created by the client rather than the server. In this way, the aircraft belongs to the client running the FSM, and the "UnitReady" command returns an accurate result. The aircraft responds properly for host and client. But in the patch it could not be resolved for a TSS_vehicle_custom, since editor objects belong to the server from start. The "setOwner" command does not exist in A2. It only exists in OA after v1.62, and any changes to the SOM had to be A2 compatible. With the patch, the TSS_vehicle_custom will still work properly for the host, but encounter the issue of landing before arriving, and then when it does arrive, hovering high where players cannot board, when it is called by a joined client. But the aircraft spawned dynamically by the scripts should respond properly. Suggestion: ---------- If your mission is run using OA, you could copy over the SOM Phase Script #7 for Transport Support to the mission file, and insert a "setOwner" command for the TSS_vehicle_custom. That might get it to respond properly after someone calls it (untested). But the command will not work in a mission run using A2. And it only works from server to client, not client to server. The vehicle would somehow have to return to server before the command could be run again (maybe moving a server AI into pilot seat could work). https://community.bistudio.com/wiki/setOwner

SOM and SSM both have their history of issues with a dedicated server. https://dev.withsix.com/issues/26368 https://dev.withsix.com/issues/15096 Also a conflict. https://forums.bistudio.com/topic/98206-how-to-simple-support-module-oa/page-2#entry1655043 Are you running on Beta, Legacy or None? I helped with the SOM during the Beta addressing multiplayer issues, but don't have a DS. I could only address issues that showed up in hosted missions. There were a couple of obvious DS items, having to do with player being null, which were found and addressed. But with not having a DS to work with, all I could do was hope that getting the hosted missions working would help with the dedicated server issues.