opusfmspol

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.

Regarding this post in "Troubleshooting" forum: https://forums.bistudio.com/topic/97526-basic-training-bugs/#entry2957819 I can confirm that the drag action is not working with the Battlefield Clearance module. The action to drag fails to appear, which also leads to no carrying. Affects A2 and OA. Might be in the BC module's "BC_AddActions.sqf", where this is found: The "draggerStart.sqf" is not found in the FA module, where the FA path leads. It's found in the BC module. I would suspect it should be: But I could be wrong, I can't test it since the modules set a hard path.

The USMC/Russian base defense units and CDF M16 rifles are WF doing config defaults. The mission uses a custom common script and custom structures config, but doesn't use a custom teams or loadouts config to change those particular things. The end-of-game loop may be a dedicated server issue. Are you encountering that on a dedicated server? I ask because the server update condition to end the loop (checking victory conditions) has always been variable "gameOver" being made true. But it seems the variable gets set true locally on clients. I don't find it getting set true in the server update, which on a DS would continue looping since a DS doesn't process the client scripts. If fixed for 2-sided missions, it would have to be conditioned on only one side remaining active (for 3-sided missions, where one side gets defeated but two sides keep battling it out). There are a couple other considerations I can think of where 2-sided v. 3-sided would have to be accounted for.

@ theduke77 - You can save the .rpt as another file for continued review, clear the text from the remaining .rpt and save, and when you play the game it generates new stuff. and @ Hork - What you say it sounds like, is what the process has been. BI focused fully on A3 after release of OA v1.63, and the patch began as a gamer mod to resolve bug issues. The mod was so good at fixing many bugs and improving gameplay that BI took notice, allowed it to become a beta, and after a lengthy beta period it became a patch. The problem is complex, and should become a college thesis some day. People play to their own styles and flavor. Mods enhance what the game can do. Many buy the game and play it for certain mods, and some come to view their favorite mod content as being "the game". Various gamers modify mods for their personal use. The mod/beta centered on the base game, which is A2, and the game expansion, which is OA. Various servers didn't use the mod, and when it became beta they wouldn't use the beta. It becomes a patch and then issues which were not reported from mod and beta period get raised, with anger showing in various posts. part is over mod conflict, part is over realism enhancement affecting gameplay style. Reading this whole thread shows that. Many play with mods that originated being written around game bugs which the mod/beta/patch later resolved, and while I won't say various mods were abandoned, various mods were left behind by their creator(s) for more current projects, creator(s) of whom permissions would have to be obtained for anyone else to update where a conflict from a bug fix occurs. And that's not even scratching the surface, but I'm not gonna write a thesis. Suffice it to say nobody who helped with the patch wants to screw up the gameplay, or impact any mods, it's been an honest effort to improve the game, and more mod/beta servers & players would have made a difference, as more modders attending to their mods would have made a tremendous difference. There are some modders who did attend their mods, they know who they are. And I don't fault modders for setting aside mods, they too are passionate players who follow their own style and flavor of gameplay. I'm not posting this to become a grand discussion, because this thread is for feedback that will help make fixes. The grand discussion truly belongs here: https://forums.bistudio.com/topic/186780-following-on-from-the-recent-patch-issues/ I'm posting this for newer forum readers to have some background awareness. If you have the many hours to spare, read through the Corepatch and Beta threads to create a college thesis, or a post for the thread above: https://forums.bistudio.com/topic/169736-arma-2-oa-beta-build-125548-steam-mp-lobby-163-build-steam-only/ https://forums.bistudio.com/topic/174206-wip-corepatch-config-patch-for-arma-2-oa/ https://forums.bistudio.com/topic/181515-arma-2-oa-beta-build-131129-163-mp-compatible-steam-only/ https://forums.bistudio.com/topic/180156-todays-new-steam-update-to-beta/ https://forums.bistudio.com/topic/181435-a2a2oa-beta-patches-pre-final-patch/ <and this thread, from start to finish>

Spam is gone yes, <yay, thank you>. Still encountering some intermittent ones. They generate after the mission is in progress. Not many though.

You don't have a semicolon before the "default". -- edit: actually it looks like the "}" before default might be the problem, it doesn't belong... try removing it? It could be more than that, switches are notorious for not logging errors in the .rpt log. They require close inspection of everything in their code.

Posting a spam .rpt would be helpful. When rather long it's helpful to: 1) Post the .rpt text in a code block to make it simpler to review, and 2) Put the code block behind a "Spoiler" button to save space for more people to comment; 3) Redacting portions of the .rpt spam, so it doesn't overwhelm but people can still see how it is spamming. It's likely you already know, but for those who might not, the spoiler button is generated by typing ["SPOILER"] before the block and ["/SPOILER"] after the block, but remove the "" from inside the brackets (they're included for visibility here, so this sentence wouldn't generate the spoiler button).

Noma, have you tried the suggestion from this post by eggbeast, or did it not help? https://forums.bistudio.com/topic/186695-a2a2oa-patch-18122015/page-9#entry2953906

This is wisdom and brings up a very, very good point; nobody should risk any country's laws to improve realistic 'realism' for the game. https://en.wikipedia.org/wiki/Bohemia_Interactive#Staff_arrest_on_Lemnos Due to such laws, certain things can only be expected to reach a more 'realistic' WIKI (What I Know Is) level... i.e. real use field experience, and not much more.