Larrow

As mentioned above index 0 is not the first move, it is their initial starting point. If you set the group's current waypoint to the waypoint just added then they will ignore trying to reach their current, as it is no longer their current, you have just overridden this by changing their current. params[ "_grp" ]; //Give group an unreachable waypoint _wp1 = _grp addWaypoint[ /*some unreachable pos*/, 0 ]; //Give group a secondary waypoint _wp2 = _grp addWaypoint[ /*some other pos*/, 0 ]; //Group will ignore _wp1 and move straight to _wp2 _grp setCurrentWaypoint _wp2; Again, use setCurrentWaypoint. No need to try and make the group reach their current one by changing the completion radius, just skip it completely by giving them a new current.

The waypoint at index 0 is not an added waypoint per se. Just the act of placing a group in the editor/spawning automatically gives the group an index 0 waypoint relative to the position they were placed/spawned. Adding a single waypoint to a group would in fact add index 1. I have seen deleting every waypoint including index 0 cause oddities before, I am not sure I've ever read anything official just based on my own experiences.

What does this entail? Never ever delete the waypoint at index 0. In fact, I'd say never delete the waypoints at all. Instead, give the group new waypoints and then set their current to the first new one you want them to follow.

Ive already done this and is available here... ...your welcome to go through it see what helps.

// Creating cosmetic impact craters with smokes: if ( ETH_cosmeticSmokesUXO ) then { // Looping: for "_i" from 1 to 10 do { // each crater and debris: _impactPos = [_kzPos, _kzRadius] call THY_fnc_ETH_cosmetic_UXO_impact_area_crater; //you cannot spawn it as you require a return value of impact pos // local particle effect for all clients [_impactPos] remoteExec [ "THY_fnc_ETH_cosmetic_UXO_impact_area_smoke", [ 0, -2 ] select isDedicated ]; }; }; Remote execute the particle function on all machines (0) or every client (-2) if it's a dedicated server. May want to include JIP? EDIT: Not the tidiest way to achieve it as each time you are creating 10 remote calls (and possibly 10 items in the JIP queue) but quickest as an example using your code. No need to know the player in the function so removed from the above remoteExec for THY_fnc_ETH_cosmetic_UXO_impact_area_smoke, so function params need to change to match... THY_fnc_ETH_cosmetic_UXO_impact_area_smoke = { // This function creates a smoke source in a limited area pre-configured. Smoke templates: https://community.bistudio.com/wiki/Particles_Tutorial#Full_examples // Returns nothing. params ["_impactPos"]; //snip [_impactPos] remoteExec [ "THY_fnc_ETH_cosmetic_UXO_impact_area_smoke", [ 0, -2 ] select isDedicated, true ]; passed params function to call where to call also for JIP

There is no need for the trigger if you want, you can get sectors to run an event when they change owner... //initServer.sqf //For each sector in the mission { //Add a owner changed event to the sector [ _x, "ownerChanged", { params[ "_sector", "_owner" ]; //If the sector changed owner to west if ( _owner == west ) then { //And west now own 10 sectors if ( [ west ] call BIS_fnc_moduleSector == 10 ) then { //Do what ever here }; }; } ] call BIS_fnc_addScriptedEventHandler; }forEach ( [ true ] call BIS_fnc_moduleSector );

[ west ] call BIS_fnc_moduleSector == 10

Be careful here if adding to remote units. Take note of the warning on the events page... FiredMan Event

Not mentioned in Code Goal As per your initial code there would be nothing to review as the variable is local and would be destroyed at the scope end. If you remove the markers, what's left over to review? So you don't actually want to remove(delete) markers just make a list of all "mark_" markers that are not area markers. Code Goal: Make a list of all markers named in the editor starting with "mark_" that are not area markers. copyToClipboard format[ "Non area 'mark_' markers: %1", allMapMarkers select { _x find "mark_" == 0 && { !( markerShape _x in [ "ELLIPSE", "RECTANGLE" ] ) } } ];

See my post in this thread, which also includes an example, may be of help.

Erm, you all missed the specs.😀 Ambiguous, on == ? in/from ? All named markers from Eden Editor ( ie in a mission )... { deleteMarker _x } forEach ( allMapMarkers select { _x find "mark_" == 0 && { !( markerShape _x in [ "ELLIPSE", "RECTANGLE" ] ) } } ); All named markers in Eden Editor ( ie in the editor )... delete3DENEntities ( all3DENEntities #5 select{ (_x get3DENAttribute "markerName") #0 find "mark_" == 0 && { !(( _x get3DENAttribute "markerType" ) #0 in [0,1] ) } } )

Although this suggests that the option should be added if the player (_this) said to the NPC (_from) "first_response". Would really need to see your setup (example mission) to provide better help.

I just use the Arma tools FSM editor

As the function does absolutely nothing with those settings, CustomWeapon, CustomMagazine and CustomTarget. Never mind was looking at the old version of the script, it was overwritten in modules_f_curator. Posted below... I know I'm replying to an old thread but what you have done here does not remove all the other stuff the module creates. ( vehicle, group, unit ) In fact, even the module's own removal option does not remove all the objects it creates.

person kbAddTopic [topicName, conversationFile, fsmFile, eventHandler] topicName - Anything STRING, a name to reference the topic by. "myTest" is fine conversationFile - bikb file that holds class Sentences. "kb/talk.bikb is correct. fsmFile - FSM for AI auto response to received sentences. Missing. FSM editor is available in Arma Tools download. See ALSO links under Conversation FSM on conversation page for more info eventHandler - code for PLAYER auto response/conv menu additions. Should be { compile preprocessFileLineNumbers "kb\talk.sqf" } Quotes from Conversation page... fsmFile eventHandler See my example MISSION here. From my init.sqf... //Add sentences and FSM flow to informant AI informant kbAddTopic ["informer", "informer\informer.bikb", "informer\informer.fsm"]; //Add sentences and SQF flow to player //no need for FSM, hence the empty quotes player kbAddTopic ["informer", "informer\informer.bikb", "", { call compile preprocessFileLineNumbers "informer\informer.sqf"}]; Otherwise, every thing looks correct from a cursory glance.

You have too many nested scheduled code blocks( spawn, execVM ), just use the original execVM to return a handle to the spawned script. Then you can use the terminate command on the handle to prematurely disable the countdown. Also, there is no need for the For loop to monitor the time remaining as this can be queried from BIS_fnc_countDown.

Yes, GetInMan and SeatSwitchedMan eventhandlers.

MP Support Module See MP_supportModule.VR\LARs\MPSupports\MPSupportsSettings.data for settings. Quickly tested SP, MP, Dedicated, JIP all with teamSwitch and still seems to work ok. This was initially written 10 days after my previous post in this thread back in May of 2018. You need to make sure when teamSwitching in MP that the _to unit is local before doing changes. I have updated the code in my previous post to reflect this.

You might as well use the conversation system, then it's ready to add voice lines when you do them. Conversations

Hopefully, I have put a comment in the tracker on the assignedVehicles request pointing out that BIS_fnc_spawnGroup needs changes. I also don't have dev installed atm so not sure if they have already fixed it.

As of A3 2.12 you should be able to find this definitively by assignedVehicles. Rather than just vehicles units are in. Also, don't forget to delete the actual group as well.

Most likely getArtilleryAmmo is returning [] so select 0 is nil( undefined ). Try getArtilleryAmmo from the debug console and see what return you are getting. There is also no need for the remoteExec(unless the trigger is server only and gun_1 is not local to the server). Make sure that gun_1 is local or remoteExec where gun_1 is local rather than everywhere.

See startLoadingScreen and BIS_fnc_startLoadingScreen

From testing it seems to be related to autoReport setting. I don't know whether to flag this as a bug or not. Surely autoReport is just meant to stop the "Enemy 100m" when you cursor over an enemy, much like the suggested NoVoice for AI. Actually breaking the knowsAbout command seems a little stupid. Even using the Reveal keybind, which you would think overrides autoReporting, does not change the status of knowsAbout.

Yes, even the debug remoteExec hint and systemChat showed detection was working when I ran my test mission on a dedicated server.