Editing, Expanding and Modifying Domination

[{SAS}Nutta 10]

Hmm, couldn't get it to work here - I set the respawn time to 0 seconds and the chopper was still there half an hour later when I checked back on the persistent server I was using for tests. Added the _startpos line and the choppers respawned within 5 mins.

Edited August 10, 2010 by {SAS}Nutta
rather critical typo

[beastybass 10]

It's not working because AH1Z_EP1 is not a valid vehicle class. EP1 denotes an Operation Arrowhead unit and the AH-1Z is not one of them. Change it to AH1Z and it should work.

Oh man i forgot that. Now its working. Thanks for your help.

[KC Grimes 79]

[ch2,302,false,10]

Even though it's abandoned for over 10 seconds, it does not respawn. I tried Nutta's fix, but I have the same issue.

It respawns on destruction, just not on abandonment. At that, I am not having any issues with helicopters not respawning when set to 'true' or when destroyed.

Edited August 10, 2010 by Grimes [3rd ID]

[{SAS}Nutta 10]

It'll take well over 10 seconds anyway - the script only scans one chopper every 20 odd seconds and has to scan a chopper twice before it will respawn so if you've got 6 choppers on the map you're looking at 2.5-5 mins before you can expect a respawn.

Edited August 10, 2010 by {SAS}Nutta
wrong timings...

[Ringosis 10]

Also could anyone tell me if I were to open the map in the in game editor and just delete all but 4 of the playable soldiers would that cause major problems?

Anyone know if this is a problem? I tried it out and it all seems to work but I'm getting random CTDs. Dunno if its the player slots or if it's something else.

[chefd261 0]

Great Idea for a thread Tank I will post a few of my modified scripts in here later when I get home.

Cheer's ChefD

[Ringosis 10]

I'm pretty sure the chopper return still doesn't work in 2.29. I flew a chopper out into the middle of no where and left it for a couple of hours. It's still out there as I speak.

[CarlGustaffa 4]

Having some problems with x_server\x_sabotage.sqf. I've replaced the "so called saboteurs" with a mixture of regular units in i_server.sqf: d_sabotage_E.

In x_sabotage.sqf, I keep the line:

{_x addMagazine "PipeBomb"} forEach (units _grp);

so that everyone has at least one satchel.

But my server.rpt is filled with the likes of:

Cannot use magazine 100Rnd_556x45_M249 in muzzle NVGoggles

Cannot use magazine HandGrenade_West in muzzle SmokeShellMuzzle

Cannot use magazine SmokeShellRed in muzzle IRStrobe

Cannot use magazine IR_Strobe_Target in muzzle TimeBombMuzzle

I assume the old line:

for "_i" from 1 to 3 do {

has something to do with it, where the units had two satchels and was given a third = 3 satchels, makes sense. But as far as I can see, nothing should happen if _one_shell does not match "PipeBomb" (from earlier forEach).

I'm going to try with only one loop to see what happens, but does anyone have any idea why I'm getting these errors?

[Durka-Durka 10]

Does anyone know how extensive the playerammobox.fsm and the x_client\playerammobox.sqf was changed? I have multiple ammo boxes and only one shows up so far. In 2.27 they all showed up.

I'm editing i_client, x_client\playerammobox.sqf, and fsm\playerammobox.sqf

I have additional files in x_client\ called playerammobox1.sqf all the way to 4. All are cross-referenced in i_client properly. Only the first one shows up (playerammobox.sqf) in-game though.

(I was editing 2.27 regular, and now trying to move everything over to 2.28_revive)

Edited August 11, 2010 by Durka-Durka

[{SAS}Nutta 10]

It doesn't look like anything has changed in playerammobox.fsm or playerammobox.sqf since 2.17 - you want to get file comparison program (winmerge isn't bad for a freebie) which will allow you to easily see what's changed between releases.

[Durka-Durka 10]

Thanks Nutta. It seems the issue isn't with the update in versions from 227 to 228, but between the regular dom and the west_r_Oa.pbo. That's the only place I can find different code.

[Ringosis 10]

Xeno fixed the timing logic but it's still missing the start position so never thinks the chopper left its pad.

In x_server/x_helirespawn2.sqf line 44:

_empty_respawn = _vec_a select 3;
if (_empty && _vehicle distance _startpos > 10 && _empty_respawn == -1) then {

change to:

_empty_respawn = _vec_a select 3;
_startpos = _vec_a select 4;
if (_empty && _vehicle distance _startpos > 10 && _empty_respawn == -1) then {

and all should be well.

Pretty sure this is required to get the chopper recall to work. I flew every chopper to random points on the map with 2.29 and left the game running for several hours overnight, none were returned to base.

Added that line and tried again. They all respawned within a couple of minutes of when they were supposed to.

[Durka-Durka 10]

Has anyone found a way to get multiple ammo boxes on startup to work with the west_revive mission?

[KC Grimes 79]

Has anyone found a way to get multiple ammo boxes on startup to work with the west_revive mission?

What are you trying to do with them? If you want to be simple, just placing the ammo boxes works fine. Or you can use an ammo crate filler.

PS: The bug that crashed/lagged computers when you opened the client side ammo crate is fixed in the beta patches a while back.

[SnowCleaner 10]

anywhere to download 2.29?

[CarlGustaffa 4]

Pretty sure this is required to get the chopper recall to work. I flew every chopper to random points on the map with 2.29 and left the game running for several hours overnight, none were returned to base.

Added that line and tried again. They all respawned within a couple of minutes of when they were supposed to.

Uhm, all choppers? Isn't the recall thing only supposed to happen for choppers "on a timer"? It used to be only lifter 2, not sure what it is now, but myself I'm only using that feature on the Hueys. And the default time is 25 minutes iirc, not "a couple of minutes".

And yes, I'm not getting them back on the base as well after I put in the updated 2.29 script. Will have to add back this thingy.

Didn't deployed HQs used to get locked? I noticed mine weren't and I thought "now what did I mess up (I'm using different vehicle)?" So I joined a 2.28 server last night to find out, and even there the MHQs can now be driven around while deployed. Did something change, or is my mind playing tricks on me?

[Strikor 10]

I've seen that happen ever since 2.0. Same with the admin lock always having been a bit flaky.

[CarlGustaffa 4]

In case someone wants to try to make a normal OA version using the updated scripting functions to get vanilla backpacks back in play instead of that scripted version, which have some (imho, rather serious exploit) issues.

x_client\x_playerspawn.sqf:

//Get the contents and store them for respawn, almost at the top of script:
#ifdef __OA__
_ubackp = "";
_ruckmags = [];
_ruckweapons = [];
_ubackp = if (!isNull (unitBackpack _p)) then {typeOf (unitBackpack _p)};
if (!isNull (unitBackpack _p)) then {
_ubackp = typeOf (unitBackpack _p);
_ruckmags = getMagazineCargo (unitBackpack _p);
_ruckweapons = getWeaponCargo (unitBackpack _p);
};
#endif

//Read back the variables, put backpack on player, and fill hit ruck, approx at the center of script:
#ifdef __OA__
if (_ubackp != "") then {
	_p addBackpack _ubackp;
	for "_i" from 0 to count (_ruckmags select 0) - 1 do {
		(unitBackpack _p) addMagazineCargo [(_ruckmags select 0) select _i, (_ruckmags select 1) select _i];
	};
	for "_i" from 0 to count (_ruckweapons select 0) - 1 do {
		(unitBackpack _p) addWeaponCargo [(_ruckweapons select 0) select _i, (_ruckweapons select 1) select _i];
	};
};
#endif

Seems to work for me at least in singleplayer, but you might want to check clients version. Haven't checked how to do that yet, but it should be possible. If he is prior to todays beta build, he could either use old scripted approach or none at all. You do want to avoid scripting errors in this one, as errors here could possibly cripple his game.

[Durka-Durka 10]

Hey guys, it's me again :) I'm brainstorming here and wondering if there's a way to have some sort of "countdown" or timer so that a group has a finite time to take each Main Target. I'm thinking that if the timer reaches 0:00, a message comes up and tells everyone they failed and the red circle turns blue or something. That way, when the domination mission is over, one can see how many Main Targets they took successfully and how many they didn't.

Just a quick brainstorming, probably too much work...

[OrdeaL 10]

Is anyone having the issue with the scud launcher side mission not completing?

[CarlGustaffa 4]

I didn't really try to complete it, sorry. All I noticed was that there was only two guys up there with a weapon - rest had dropped theirs in the pond (unless there are several scud side missions).

[Decoy 10]

Is anyone having the issue with the scud launcher side mission not completing?

We have the same issue in 2.28.

[{SAS}Nutta 10]

Just encountered the problem with the scud launcher earlier today (it's ok if you fail the mission but will never end if you destroy the scud). Fixed version follows. I also moved the launch to a more sensible place as I took pity on the AI spending all their time swimming in the lake...

Replace contents of x_missions\moa\x_m7.sqf with:

// by Xeno
private ["_vehicle", "_poss", "_ogroup", "_unit", "_officer", "_endtime", "_MissionCompleted"];
#include "x_setup.sqf"

x_sm_pos = [[700,10450,0]]; //  destroy scud
x_sm_type = "normal";

#ifdef __SMMISSIONS_MARKER__
if (true) exitWith {};
#endif

if (X_Client) then {
d_current_mission_text = "The enemy is preparing a Scud launch near Mulladost to attack a neighbour country. Find the Scud before they can fire the missile, hurry...";
d_current_mission_resolved_text = "Good job. You have destroyed the Scud!";
};

_MissionCompleted = {
#ifndef __TT__
d_side_mission_winner=2;
#else
if (sm_points_west > sm_points_east) then {
	d_side_mission_winner = 2;
} else {
	if (sm_points_east > sm_points_west) then {
		d_side_mission_winner = 1;
	} else {
		if (sm_points_east == sm_points_west) then {
			d_side_mission_winner = 123;
		};
	};
};
#endif
d_side_mission_resolved = true;
};

if (isServer) then {
__PossAndOther
_vehicle = "MAZ_543_SCUD_TK_EP1" createvehicle (_poss);
_vehicle setDir 285;
_vehicle setFuel 0;
_vehicle addEventHandler ["killed", {_this call XfAddSMPoints}];
__GetEGrp(_ogroup)
_unit = _ogroup createUnit ["TK_Soldier_EP1", _poss, [], 0, "FORM"];
_unit setVariable ["BIS_noCoreConversations", true];
__addDead(_unit)
_unit moveInDriver _vehicle;
__AddToExtraVec(_unit)
__AddToExtraVec(_vehicle)
sleep 2.123;
["specops", 2, "basic", 2, _poss,200,true] spawn XCreateInf;
sleep 2.321;
["shilka", 1, "bmp", 1, "tank", 0, _poss,1,250,true] spawn XCreateArmor;

_endtime = time + 900 + random 100;
waitUntil {sleep 0.321;!alive _vehicle || time > _endtime};

if (!alive _vehicle) exitWith {
	call _MissionCompleted;
};

if (alive _vehicle) then {
	["d_smsg"] call XNetCallEvent;
	_vehicle action ["ScudLaunch",_vehicle];
};
sleep 10;
if (!alive _vehicle) exitWith {
	call _MissionCompleted;
};
sleep 10;
if (!alive _vehicle) exitWith {
	call _MissionCompleted;
};
sleep 10;
if (!alive _vehicle) exitWith {
	call _MissionCompleted;
};
_vehicle action ["ScudStart",_vehicle];
d_side_mission_winner = -879;
d_side_mission_resolved = true;
};

[Tankbuster 1733]

Thanks Nutta. :)

[CarlGustaffa 4]

Implemented without looking :) It's a shame about AI/water and that original place, because the place rocks...

Can you give a go on optimizing (and possibly officially implement, or completely rewrite) the following mess? I feel I'm out of my league on this one, even if it appears to work okay in multiplayer at least with only one client connecting.

The general idea is to create a list of main targets that instead of being fully random, picks a random place that is more than x km away and less than y km away. The point is to create a list of targets that is more friendly to driving vehicles on, instead of having to constantly rely on lifting.

It probably have some bugs, but here is what I came up with so far based on resorting (ruebe's shellsort, maybe too complex for the job, but the code evaluator was the kicker for me) the list.

x_server\x_f\x_serverfuncs.sqf

XfShellSort = {
/*
Author:
rübe

Description:
Generic shell sort implementation. The original list does 
NOT get altered.

Shellsort is not sensitive to the initial ordering of the
given list. Hard to compare to other sorting methods but
shellsort is often the method of choice for many sorting
applications:

- acceptable runtime even for moderately large lists,
(Sedgewick says up to "five thousand elements")
- yet very easy algorithm.

Parameter(s):
_this select 0: the list to be sorted (array of any)
_this select 1: sort value selector/calculator (string or code; optional)
	- gets passed a list item, must return scalar
	- if a string gets passed, we compile it first

	->	if the list does not consist of numbers but a complex 
		data structure (like arrays), you may pass a simple
	 	function, that accesses (or calculates) the "value" 
	 	in this structure the list will be sorted on. Advanced example:
		tt = [["d",[11,11]],["a",[3,-3]],["c",[-8,6]],["b",[-5,-5]]];
		player setPos [0,0];
		qq = [tt,{getPos player distance [(_this select 1) select 0,(_this select 1) select 1]}] call fn_shellsort;
		hint str qq; //Sorts the list based on distance from player to position array within the array

	->	to simply invert the sort order, pass {_this * -1} as
		second parameter (for numbers).

		default sorting order is ASCENDING

Returns:
sorted list
*/
private ["_list", "_selectSortValue", "_n", "_cols", "_i", "_j", "_k", "_h", "_t"];
_list = +(_this select 0);
_selectSortValue = {_this};
if ((count _this) > 1) then	{
	if ((typeName (_this select 1)) == "CODE") then {
		_selectSortValue = _this select 1;
	} else {
		_selectSortValue = compile (_this select 1);
	};
};
_n = count _list;
_cols = [3501671, 1355339, 543749, 213331, 84801, 27901, 11969, 4711, 1968, 815, 271, 111, 41, 13, 4, 1];
for "_k" from 0 to ((count _cols) - 1) do {
	_h = _cols select _k;
	for [{_i = _h}, {_i < _n}, {_i = _i + 1}] do {
		_t = _list select _i;
		_j = _i;
		while {(_j >= _h)} do {
			if (!(((_list select (_j - _h)) call _selectSortValue) > (_t call _selectSortValue))) exitWith {};
			_list set [_j, (_list select (_j - _h))];
			_j = _j - _h;
		};
		_list set [_j, _t];
	};
};
_list
};

XfArrayFindDeep = {
/*
Author: Philipp Pilhofer (raedor)
Purpose: This function searches an element in an array and returns the first occurence
Arguments: [array, element]
Return: anything

Revision History:
24/11/06 0.1 - First cut
*/
private["_c","_i","_r","_v","_a"];
_a=_this select 0;
_v=_this select 1;
_r=-1;

_i=0; _c=count _a;
while {_i<_c && _r in [-1]} do {
	if (typeName _a == "ARRAY") then {
		if (str _v == str (_a select _i)) then {
			_r=[_i];
		} else {
			_i=_i+1;
		};
	} else {
		_r = [_a select _i,_v] call XfArrayFindDeep;
		if !(_r in [-1]) then {
			_r=[_i]+_r;
		} else {
			_i=_i+1;
		};
	};
};
_r
};

XfArrangeTargets = {
private ["_res","_count","_find","_origin","_check","_candidate","_i","_delay","_random"];
_res = [];
_count = _this;
_sorted = [d_target_names,{(d_base_array select 0) distance [(_this select 0) select 0, (_this select 0) select 1]}] call XfShellSort;
waitUntil {count _sorted == _count};
//	_random = floor(random 3); //Too close to base actually, but I have more targets than default
_random = 3 + floor(random 6);
_find = [d_target_names, _sorted select _random] call XfArrayFindDeep;
_find = if(typeName _find == "ARRAY") then {_find select 0} else {_find};
_res set [count _res, _find];
//	_name = "New" + format ["%1", count _res];
//	_pos = ((d_target_names select _find) select 0);
//	[_name,_pos,"ICON","COLORRED",[0.5,0.5],format ["%1", count _res],0,"mil_dot"] call XfCreateMarkerGlobal;
while {count _res < d_number_targets_h} do {
	_origin = (d_target_names select _find) select 0;
	_sorted = [d_target_names,{_origin distance [(_this select 0) select 0, (_this select 0) select 1]}] call XfShellSort;
	_check = false;
	_i = 0;
	while {!_check} do {
		_random = (_i + floor(random 3)) min (_count - 1);
		_candidate = _sorted select _random;
		_distance = _candidate select 0 distance ((d_target_names select _find) select 0);
		if (_distance > 2000 && _distance < 4000) then {
			_find = [d_target_names, _sorted select _random] call XfArrayFindDeep;
			_find = if(typeName _find == "ARRAY") then {_find select 0} else {_find};
			if !(_find in _res) then {
				_check = true;
				_i = 0;
				_res set [count _res, _find];
//					_name = "New" + format ["%1", count _res];
//					_pos = ((d_target_names select _find) select 0);
//					[_name,_pos,"ICON","COLORRED",[0.5,0.5],format ["%1", count _res],0,"mil_dot"] call XfCreateMarkerGlobal;
			};
		} else {
			if (_i == (count d_target_names) - 1) then {
				_i = 0;
			} else {
				_i = _i + 1;
			};
		};
	};
	_i = 0;
};
_sorted = nil;
_res
};

init.sqf:

//		d_maintargets_list = (count d_target_names) call XfRandomIndexArray;
	d_maintargets_list = (count d_target_names) call XfArrangeTargets;

XfArrayFindDeep could probably be precompiled from the original (Xeno does that other places), I only changed indenting and how curly bracers were placed (into the way I prefer). It's in the regular BIS functions, under arrays I guess.

But, although it appears to work, I get the feeling it's overly complicated, and looks utterly horrible :D But I've gone blind, every fresh attempt ends up with the same kind of system. Feel free to have a laugh on my account, I don't mind :D

Edited August 15, 2010 by CarlGustaffa
Commented lines needed only for debugging markers