A2/A2:OA beta CorePatch 01.03.2016

[pcc 14]

Some APCs manned by AI like tunguska and Shilka for some reason will not fire at enemy ground units but only maintain visual lock with clear line of sight doesn't matter how far or close.  They only fire after I've board the vehicle once.   I've tried issuing engage at will and told them attack specific targets but its only after I board the vehicle once then the AI will fire. 

I've only noticed this in warfare and tested with clean setup.

If I only add the units in editor without modules they fire on their own at enemy ground units no problem.

[opusfmspol 273]

Not just Tunguska and Shilka, but others like LAV, AAV, armor.  It wouldn't be combatMode, WF doesn't set one.  Units get created at default "YELLOW", Fire at will.  Wouldn't be locality either, the client creates the units for their team.

 

It's as if for units created during a mission, after the mission starts getting busy, something causes the vehicle team's "knowsAbout" to fail to link with the Player's "knowsAbout" unless the player is in the vehicle.  Once the player gets in the vehicle the vehicle team becomes aware of what the player knows and engages.  Which if not designed behavior, may not be a scripting or config issue but a maybe logic, processor load, or network, just to guess.

[pcc 14]

What's weird is that they seem to know where the target is as they point their turrets at the target but just refuses to fire.

It also occurs with AI squads that aren't part of player's squad or side.   With the tunguska and shilka, they will fire at air units, but against ground units, it might as well be a civilian vehicle.  The ural zu23 doesn't have this problem and can engage air and ground targets fine.

The BMP 2 seems to have very sensitive targeting, as it quickly wastes targets after target with its 30mm.   I've seen it own a lot m1 tanks due to its reaction time.

[pcc 14]

On map chernarus, the secop modules hangs especially long when first side mission comes in.  Tested with only secop module. 

[opusfmspol 273]

It happens on the server, for every map to some degree, longer lag for larger maps.

The lag will disappear by putting this in the init code of each SOM placed on the map:

if (isNil "SOM_Logic_Array") then {SOM_Logic_Array = []};
SOM_Logic_Array = SOM_Logic_Array + [this];

The lag would stop entirely if these two lines were in the beginning of SOM's init.sqf  (replacing "this" with "_this").

 

What causes it:

Spoiler

When the very first SecOp occurs the SecOps.fsm searches objects to build an array of SOM's.  It uses the SOM array to assign each a unique scope ID which won't cause map markers to disappear in multiplayer.  It only occurs at the onset of the very first SecOp.  But it won't occur if the array is already defined.

 

Each SOM uses its scope ID for map markers.  Markers were unexpectedly disappearing in multiplayer because there were times SOM's were sharing the same SecOp and scope ID, so when one deleted a SecOp marker it also deleted the marker of the other SOM.

 

But in searching the entire map for SOM's it uses nearObjects instead of allMissionObjects command, because SOM is an A2 logic.  allMissionObjects is an OA 1.57 command which won't work in A2.

 

nearObjects causes the lag.  Not having the two lines in SOM's init.sqf is what causes the nearObjects command to run.

 

I regret the fix I passed on failed to include those two lines for the init.sqf.

[Dwarden 1124]

@opusfmspol you run this in Arma 2 or Arma 2: Operation Arrowhead engine ?

because if module runs in A2OA engine (A2OA or A2CO mode (OA engine+OA data+A2 data) then is shall use fine the allMissionObjects

 

of course if you see problem with some changes using under A2 the new commands from OA engine just say

(those mistakes may happen when back-porting two fold changes (found some before) once for OA and must do it differently for A2 to not break either)

[opusfmspol 273]

21 hours ago, dwarden said:

@opusfmspol you run this in Arma 2 or Arma 2: Operation Arrowhead engine ?

because if module runs in A2OA engine (A2OA or A2CO mode (OA engine+OA data+A2 data) then is shall use fine the allMissionObjects

 

of course if you see problem with some changes using under A2 the new commands from OA engine just say

(those mistakes may happen when back-porting two fold changes (found some before) once for OA and must do it differently for A2 to not break either)

 

I run with CO, but also check SOM and WF in beta by launching A2 alone to check for backwards compatible.  The A2 campaign uses both.

 

That particular section of code for the secop.fsm should have been better, should have allowed allMissionObjects when OA is running.

 

I could PM or post here what better code for it might be, or a better method in SOM init.sqf (so that section of code in the fsm wouldn't be needed).

 

-- Edit:  --

This placed in the Server section of SOM's init.sqf should resolve the issue for both A2 and OA.
 

Spoiler

Where in init.sqf it has this:

	//Initialize SOM (server).
	private ["_ok"]; 
	_ok = _this execVM "ca\missions\som\data\scripts\main.sqf";
} 
else 

 

add section to assign new id's:
 

	//Initialize SOM (server).
	private ["_ok"]; 
	_ok = _this execVM "ca\missions\som\data\scripts\main.sqf";

	//When more than one SOM in the mission, give each a different scope ID (for marker names).
	Private ["_total"];
	if (isNil "SOM_Logic_Array") then {SOM_Logic_Array = []};
	SOM_Logic_Array = SOM_Logic_Array + [_this];
	_total = Count SOM_Logic_Array;

	if (Count SOM_Logic_Array > 1) then 
	{
		_niv = [_this,_total] spawn 
		{
			Private ["_logic","_total","_id"];
			_logic = _this select 0;
			_total = _this select 1;

			waitUntil {!isNil {_logic getVariable "curID"}};
			_id = ((_total - 1) * 1000);
			_logic setVariable ["curID", _id];
		};
	};
} 
else 

 

 

Tested this in beta with the init script copied to the mission file, and it worked fine.  Each SOM had unique scope ID's created at mission start before any secop ran.  The fsm bypassed the part using nearentities.

 

Playing through secops a few other things were happening:

Garbage collector errors kept occurring in both A2 and OA when SOM cleaned up:

Error in expression < {_queue = [];};if({if((_x select 0) == _object) exitWith {1}} count _queue >>
  Error position: <== _object) exitWith {1}} count _queue >>
  Error Generic error in expression
File ca\modules\garbage_collector\data\scripts\trashIt.sqf, line 28

The garbage collector was collecting, but SecOps wouldn't complete and kept having to be cancelled.  The errors occurred when the secops should have completed.

 

Phase 9 scripts call SOM's clean dynamic function, which calls garbage collector's trashit function.  I got the impression that when the trashit line failed the calls from phase 9 failed to complete, so secops wouldn't move to phase 10 debriefing (mission completion).

 

The SOM Airstrike Secop spammed errors in A2.  There's apparently OA data being used in its phase 7 script (an SSM script, and EP1 object:  "sign_sphere10cm_ep1").  Some airstrikes worked but others did not.
 

Edited March 5, 2017 by opusfmspol

[opusfmspol 273]

Confirmed that the GC error is the cause of SecOps not completing.  I moved a copy of trashIt script to mission file, replaced the error line with something else and the Secops began completing.

[samatra 85]

11 hours ago, opusfmspol said:

Confirmed that the GC error is the cause of SecOps not completing.  I moved a copy of trashIt script to mission file, replaced the error line with something else and the Secops began completing.

GC was fixed on beta branch (both A2 and OA), are you sure you're using latest modules.pbo?

[opusfmspol 273]

Pretty certain I did, will check again.

 

-- Edit: --

That was the problem, thanks @samatra.  Steam hadn't updated for whatever reason, though I have it set to auto update.

 

Deleted Steam files, reinstalled, verified integrity of cache and the new trashit script was there.  Removed the edited script from mission file and played SecOps in A2 again.

 

A few short rounds, no problems.  Another round and 4 secops completed before they failed to complete again, but no GC error was reported or logged.  Another round I played many SecOps without problems, just the Airstrike spammed the log.

 

This was found in the defend location SecOp phase 1 script, and could be an easy fix:

Spoiler

BIS_SOM_ahAvail is true when OA is used, and that's when the _e.bikb is used.

 

Where it has this:

//Make sure the current leader has the correct topic.
private ["_install", "_uninstall"];
_install = 
{
	if (BIS_SOM_ahAvail) then 
	{
		player kbAddTopic ["defend_loc", BIS_SOM_stdPath + "kbs\secops\defend_location\defend_location.bikb", ""];
	} 
	else 
	{
		player kbAddTopic ["defend_loc", BIS_SOM_stdPath + "kbs\secops\defend_location\defend_location_e.bikb", ""];
	};
};

 

the path scripts should be swapped:
 

//Make sure the current leader has the correct topic.
private ["_install", "_uninstall"];
_install = 
{
	if (BIS_SOM_ahAvail) then 
	{
		player kbAddTopic ["defend_loc", BIS_SOM_stdPath + "kbs\secops\defend_location\defend_location_e.bikb", ""];
	} 
	else 
	{
		player kbAddTopic ["defend_loc", BIS_SOM_stdPath + "kbs\secops\defend_location\defend_location.bikb", ""];
	};
};

 

 

I don't know that GC made the SecOps fail to complete on the one time it happened, but suspect it may be so if an object was submitted twice to trashit.  When an object is queued to trashit twice, the process_queue script will encounter an undefined variable (null object or null group) when processing the second time around, and that occurs in a switch.  Switches are notorious for not logging errors.

 

The line that caused error was a check added to see if the object submitted was already in queue.  The original trashit script is restored, which has no check, so objects/groups could end up being submitted to queue twice.

 

A suggested possible check to replace the one that errored:

// Check if already in queue
if (isNull _object) exitWith {false};
if (isNil "_object") exitWith {false};
if (!isNil {_object getVariable "GCtrashIt"}) exitWith {false};
_object setVariable ["GCtrashIt", str _object, true];

 

Edited March 7, 2017 by opusfmspol

[pcc 14]

Feature requests:

The secop mission escort set to auto fail when the squad is wiped out like the defend mission.

Enable AI MLRS and Grad units ability to directly fire on targets like they can in m119 and d30. 

[Dwarden 1124]

yesterday there was small update to A2OA beta corepatch with some fixes ...

[samatra 85]

On 01.03.2017 at 5:08 PM, reconteam said:

"guided" dumb bombs were made for gameplay purposes and not to be realistic.

I'm not sure about this change myself, should we revert it?

[OMAC 254]

2 hours ago, samatra said:

I'm not sure about this change myself, should we revert it?

 

Could the change deleteriously affect official campaigns or scenarios?  Is there a CIT ticket on the issue?

[samatra 85]

Just now, OMAC said:

 

Could the change deleteriously affect official campaigns or scenarios?  Is there a CIT ticket on the issue?

Can't really say but there is indeed good chance it will break something somewhere.

 

Implemented tickets:

http://dev.withsix.com/issues/46056

http://dev.withsix.com/issues/24887

http://dev.withsix.com/issues/24957

[OMAC 254]

IMO, the change should be maintained unless breakages of official missions caused by the change are identified. 

 

Are Mk82 iron bombs standard loadout on a vanilla A2CO plane?  What about modded planes?

[samatra 85]

The thing is that although bombs are unguided, they are not dropped simply by intuition or by chance, there should be aiming devices that calculate when to drop the bomb to hit the target. I'd suggest to try to bring locking back but decrease maneuvrability so you still have to manually aim the plane\helicopter but locking will help it only a little bit.

[OMAC 254]

18 minutes ago, samatra said:

The thing is that although bombs are unguided, they are not dropped simply by intuition or by chance, there should be aiming devices that calculate when to drop the bomb to hit the target. I'd suggest to try to bring locking back but decrease maneuvrability so you still have to manually aim the plane\helicopter but locking will help it only a little bit.

 

That sounds like a good compromise.
 

Quote

You will see the bomb point its nose towards the targets and speed up like a missile. (http://dev.withsix.com/issues/46056)

 

 

But the "speeding up like missile" should be removed for sure, eh?

[samatra 85]

Just now, OMAC said:

 

But the "speeding up like missile" should be removed for sure, eh?

Bombs ARE missiles in the game, except they have lower speed but much higher maneuvrability. The longer bomb falls, the move maneuvrable it becomes making it impossible to dodge it even in fast moving vehicle, I'll do tests to see if lower maneuvrability solves it.

[OMAC 254]

Yes.  The question is the RATE of "speeding up" of the falling bomb.  If the acceleration rate is faster than that of normal free fall, then that would be a problem.  But maneuverability appears to be the key, as you wrote.

[pcc 14]

7 hours ago, samatra said:

Bombs ARE missiles in the game, except they have lower speed but much higher maneuvrability. The longer bomb falls, the move maneuvrable it becomes making it impossible to dodge it even in fast moving vehicle, I'll do tests to see if lower maneuvrability solves it.

What about making the bomb from more to less maneuverable the longer it falls?  I'm not sure how it is in real life but I'd think once the bomb falls below a certain height it wouldn't be able to change its impact location as much as when its at a higher height.

[samatra 85]

3 hours ago, pcc said:

What about making the bomb from more to less maneuverable the longer it falls?  I'm not sure how it is in real life but I'd think once the bomb falls below a certain height it wouldn't be able to change its impact location as much as when its at a higher height.

We cannot control any of this, its all hardcoded in the engine.

[samatra 85]

So I did few tests with unguided-guided bombs, I set trackLead to 0 so bombs no longer lead moving targets and decreased maneuvrability from 20 to 5 for FAB-250 and Mk.82, so they change their trajectory much less. I did some tests with AV8B, Su-25 and Mi-24P, you still have to mostly rely on your vehicle's speed and orientation to succesfully drop bombs but locking can sometimes help you with that. GBU-12 still has huge maneuvrability value of 20 so it is very effective when bombing laser targets.

[OMAC 254]

5 hours ago, samatra said:

So I did few tests with unguided-guided bombs, ...

 

 

[Kalkhin 0]

Is it possible to add in BETA-patch magazines only with tracers for all types of hand weapons? Sometimes you just need to mark the target. There will be more variety in the gameplay, think about it.