OFPEC Forum

Editors Depot - Mission Editing and Scripting => Arma2 - Editing/Scripting Resources Beta Testing & Submission => Topic started by: Rommel92 on 02 Dec 2009, 06:10:21

Title: RMM Reducer - Group Caching Made Easy
Post by: Rommel92 on 02 Dec 2009, 06:10:21

Description:
Kills about 67% of AI related lag issues for the server.
Eliminates up to 95% of AI related lag issues for the player (on a dedicated server).

How?
It removes all AI outside of specified ranges, and dependant on the players position, will spawn / de-spawn the AI groups when the player enters their radius. For example;

The mission editor has defined the Reducer to have a range of 800m to spawn, and 1000m to de-spawn. If the player enters within 800m of any AI groups position, it will 'fill' the group with its original number of AI, re-filling vehicle crew positions.
If the player then moves away and the distance between player and AI groups position is above 1000m, it will remove the AI again, leaving them with only drivers for their vehicles and their group leader.

This does not work perfectly for AI placed in specific positions (ie within buildings), it is designed for mission editors who want to put well over 500 enemy on the map, anywhere, without worrying about potential lag issues.

So it is perfect for roaming patrols, convoys, AI defending towns (but not static) etc.

Example mission provided.

Contents (mission folder):
init.sqf
mission.sqm
scripts\init_Reducer.sqf
fsm\Reducer.fsm
RMM_Core (http://forums.bistudio.com/showthread.php?t=91166)

Usage:

To use the reducer, simply place down an object (I've used a Game Logic - Location, which is best due to its server locality and synchronisations) and put the following in the initialisation line:

Code: [Select]

_h = [this, <Spawn range>, <De-spawn range>, <Debug mode>] execVM "scripts\init_Reducer.sqf"
Optimum values lie in between 700-900 for the spawn range, and 800-1000 for the de-spawn range. If the de-spawn range is lower than the spawn range, it will reverse the values.
The debug mode will enable the mission editor to see when groups are filled or reduced.

Then synchronise any groups you wish to enable for the reducer to handle, with the game logic. (Shown in example mission)

To use default values, simply use the following code in the game logic:

Code: [Select]

_h = this execVM "scripts\init_Reducer.sqf"
To add groups to the reducer during the mission, simply add the group to the RMM_Reducer_Groups array. Ie

Code: [Select]

[RMM_Reducer_Groups, <GROUP>] call BIS_fnc_arrayPush;
Dependencies:
RMM_Core Functions (http://"http://forums.bistudio.com/showthread.php?t=91166")
BIS Functions Module

Installation:
Simple installation; copy and paste the fsm and scripts folder (and its contents) into your mission directory.
Ensure the BIS Functions module is placed in your mission.
Ensure RMM_Core is loaded correctly.

Compatibility Issues:
If any groups are killed whilst not spawned, they will remain with a count of 0 and are viable for deletion, therefore a group cleaner may kill groups that are simply waiting to be spawned.
To get around this simply use the following code in your cleaner:

Code: [Select]

if (!isnil "RMM_Reducer_Groups") then {
_groupsToCheck = allGroups - (RMM_Reducer_Groups + RMM_Reducer_ReducedGroups);
} else {This is only important for mission makers whom are using a group cleaner (uncommon amongst low level missions).

Author: Rommel
Date: 02/12/2009 (thats 12/02/2009 for the yanks)
Revision: 1

------------- DOWNLOAD -------------

Size: 7KB
Type: 7zip | .7z
Unpacker: www.7-zip.org (http://www.7-zip.org)

Mirrors:
http://www.4shared.com/file/163887890/aa3cbcad/RMM_ReducerChernarus.html (http://www.4shared.com/file/163887890/aa3cbcad/RMM_ReducerChernarus.html)

Title: Re: RMM Reducer - Group Caching Made Easy
Post by: Fincuan on 20 Dec 2009, 01:43:42

Hey Rommel nice job with this one, I finally got around integrating it in one of my missions and the first impression is very good. The mission is 30 players and at least 15 AI squads handled by the FSM, so I had to edit it a bit to make things work properly:

• Having the distances of every group to all players checked every frame(in fsm "condition"-field) was too much. It killed server performance, instanly dropping fps down to the teens and below, as the groups had been reduced and the distance-checking started. Moving the check to an init-field in the FSM("3ms"-limit kicks in) cured this and doesn't seem to hamper the operation.
• I added a small sleep(2 sec was good for my mission) before starting a new round of checks.
• I changed all calls to "_fReduce" and "_fFill" to spawns

It remains to be seen how much these help when 30 human players put the mission through its paces, but a limited testing on my own dedi-server showed that the above steps helped performance a lot.

edit:
Ok first 30-player run is done, and I received zero reports on desync or bad performance. The yellow chain made a brief visit at the start, probably due to all the crap around spawn, but after that things were silky smooth. I'm not sure what effect each element has here, but I'm definitely going to keep Reducer in the mission.

Thanks!