HETMAN - Artificial Commander

[Rydygier 1309]

Hmm. We, I and Squint, do not see problem in 738. This RPT report is somehow familiar to me. Something like that I see not first time, but can't remember, where this error occured earlier. I remember, that last time cause was very strange - was needed objective triggers deleting and placing again. Did that now, but not hepled. Tommorow will try check this more deeply.

[instagoat 133]

http://pastebin.com/S45PzqWn

http://pastebin.com/j08YNink

here are the two files. For some reason when doing BBb it stalls at the marked line (line 572 in the first one). I have replaced all Units of the B side again by copypasting and deleting them and putting them back in the same positions. I have also tried shifting the names of the commanders around, to no avail. Replacing the fronts or objectives didn´t do anything for me either. For some reason it seems to hang up when running boss.sqf? I´ve looked at the file that comes with the .rar, which is how I extracted the code to the hidden pastebins.

And again, no haste, I´m just keeping things up to date as I try to figure what is what here. A coder friend of mine is helping me a bit with it, maybe I can figure it out on my own.

[Rydygier 1309]

OK. Probably found source of this problem. This is code error, will try to remove it for next release.

EDIT: For now, to avoid this error, try to set BB strategic areas in such manner, that distance between each such area for given BB side is bigger than 400 meters. Error is probably part of procedure of "merging" strategic areas that are located closer than 400 meters. This is for 90%. Tests are pending.

---------- Post added at 12:41 ---------- Previous post was at 12:24 ----------

Meanwhile a quick fix for script version:

In Boss.sqf replace lines 261 - 304, that looks like here:

switch (_BBSide) do
{
case ("A") : {missionNameSpace setVariable ["A_SAreas",_strArea]};
case ("B") : {missionNameSpace setVariable ["B_SAreas",_strArea]};
};

for [{_k = 0},{_k < (count _strArea)},{_k = _k + 1}] do
{
_fAr = _strArea select _k;
_fPnt = _fAr select 0;
_fVal = _fAr select 1;
_fTkn = _fAr select 2;

_fX = _fPnt select 0;
_fY = _fPnt select 1;

for "_j" from 0 to ((count _strArea) - 1) do
	{
	_sAr = _strArea select _j;
	_sPnt = _sAr select 0;
	_sVal = _sAr select 1;
	_sTkn = _sAr select 2;

	_sX = _sPnt select 0;
	_sY = _sPnt select 1;

	if (((_fPnt distance _sPnt) < 400) and not ((_fPnt select 0) == (_sPnt select 0))) then 
		{
		if (_fVal > _sVal) then
			{
			_strArea set [_k,[[(_fX + _sX)/2,(_fY + _sY)/2,0],_fVal + _sVal,_fTkn]];
			_strArea set [_j,"deleteThis"]
			}
		else
			{
			_strArea set [_j,[[(_fX + _sX)/2,(_fY + _sY)/2,0],_fVal + _sVal,_sTkn]];
			_strArea set [_k,"deleteThis"]
			}
		}
	};

_strArea = _strArea - ["deleteThis"]
};
////////////////////////////////////////////////////////////////////

with this:

for [{_k = 0},{_k < (count _strArea)},{_k = _k + 1}] do
{
_fAr = _strArea select _k;
_fPnt = _fAr select 0;
_fVal = _fAr select 1;
_fTkn = _fAr select 2;

_fX = _fPnt select 0;
_fY = _fPnt select 1;

for "_j" from 0 to ((count _strArea) - 1) do
	{
	_sAr = _strArea select _j;
	_sPnt = _sAr select 0;
	_sVal = _sAr select 1;
	_sTkn = _sAr select 2;

	_sX = _sPnt select 0;
	_sY = _sPnt select 1;

	if (((_fPnt distance _sPnt) < 400) and not ((_fPnt select 0) == (_sPnt select 0))) then 
		{
		if (_fVal > _sVal) then
			{
			_strArea set [_k,[[(_fX + _sX)/2,(_fY + _sY)/2,0],_fVal + _sVal,_fTkn]];
			_strArea set [_j,"deleteThis"]
			}
		else
			{
			_strArea set [_j,[[(_fX + _sX)/2,(_fY + _sY)/2,0],_fVal + _sVal,_sTkn]];
			_strArea set [_k,"deleteThis"]
			}
		}
	};

_strArea = _strArea - ["deleteThis"]
};

switch (_BBSide) do
{
case ("A") : {missionNameSpace setVariable ["A_SAreas",_strArea]};
case ("B") : {missionNameSpace setVariable ["B_SAreas",_strArea]};
};

////////////////////////////////////////////////////////////////////

All worked fine after that.

Edited November 18, 2012 by Rydygier

[instagoat 133]

I´ve tried altering the code, however, it didn´t seem to change anything. This is the updated version of the mission I´ve been testing with, it runs no mods, only vanilla OA Units. I have added your altered code per instructions and am running (obviously) from script instead of addon now.

http://filesmelt.com/dl/OPDevoutpilgrim.rar

This is the error in the .rpt I am getting again:

...
"Big Boss A is looking for strategic objectives."
"Big Boss A is analyzing forces..."
"Big Boss A is checking own forces placement..."
"Big Boss A orients the flanks."
"Big Boss A assigns front sections to divisions."
"Assignment of Big Boss A : Left: [LeaderHQB] Right: [LeaderHQD] Front: [LeaderHQ] Reserve: [LeaderHQC]"
"Big Boss A issues orders."
"Side: A - Losses: 0 Number: 267 Value: 676 enValue: 0 enFactor: 676 lossFactor: 0"
"For Big Boss A cycle is completed: 1 (mission time: 141.104)"
"Big Boss A will now use some break for coffee and cigarette."
"Big Boss B awakes (time: 143.25)"
"Big Boss B is looking for strategic objectives."
"Big Boss B is analyzing forces..."
"Big Boss B is checking own forces placement..."
Protocol bin\config.bin/RadioProtocol_EP1_TK/: Missing word Message
Protocol bin\config.bin/RadioProtocol_EP1_TK/: Missing word ImOnIt
Error in expression <enAr) > 0) then
{
{
_eA = _x;
_eP = _eA select 0;
_eT = _eA select 2;

{
_sA = _>
 Error position: <select 0;
_eT = _eA select 2;

{
_sA = _>
 Error select: Typ Zeichenfolge, erwartet Array,Config entry
"Morale C (EAGER): 0 - losses: 0 percent (0)"
"Morale D (COMPETENT): 0 - losses: 0 percent (0)"
"Morale A (EAGER): 0 - losses: 0 percent (0)"
"Morale B (BRUTE): 0 - losses: 0 percent (0)"
...

I really have no clue. Again, the error highlighted in the .rpt is here: http://pastebin.com/S45PzqWn starting at line .572 and onwards. I do not know what it is trying to do and what is going wrong, though. Especially since this runs perfectly fine for BBa but then stalls for BBb.

Hope this helps in figuring out the problem.

[Rydygier 1309]

Checked. I found Boss.sqf inside without this fix (previous version). I made this fix there and tried the mission. All is fine, no error or stuck. So use this Boss.sqf:

http://www63.zippyshare.com/v/87634752/file.html

[instagoat 133]

Checked. I found Boss.sqf inside without this fix (previous version). I made this fix there and tried the mission. All is fine, no error or stuck. So use this Boss.sqf:

http://www63.zippyshare.com/v/87634752/file.html

Beautiful, now it works! Thanks a lot, I think I confused the fixed Boss.sqf and moved the one I corrected to the wrong folder while thinking I had it in the right one. On to do battle!

[Rydygier 1309]

HAC 1.31 released.

Changelog:

- fixed rare problems with arty missions;

- fixed morale and losses calculactions when new groups are placed under HAC control;

- improved reliability of air cargo system;

- improved choosing of positions for idle and rest orders;

- few other code fixes.

[Guest]

Thanks for keeping us up to date with your work :cool:

Version 1.31 frontpaged on the Armaholic homepage.

HETMAN - Artificial Commander v1.31



Community Base Addons

[Rydygier 1309]

Thanks. :)

[stupidwhitekid75 11]

Woohoo, awesome. Will be trying this out soon.

EDIT:

Hm...so I'm not getting any options for air transport after several different tries.

I have two helicopters, CDF Mi-17 and USMC MH-60, and one cargo truck at an airfield. The enemy is about half the map away (map is Chernarus if that helps) and is only composed of infantry units with rifles...no AA. When HETMAN activates he assigns me to recon on foot all the way across the map to the objective, and sends the helicopters there as well (separately without any troops). In the leaders init I have "RydHQ_CargoFind = 100" and "RydHQ_NoAirCargo = false". Am I doing something wrong? Or is it perhaps because the leader isn't sure if there is or is not any AA at the objective site and is hesitant to send troops via helicopter?

EDIT #2:

Well I took "RydHQ_NoAirCargo = false" out to see if it made a difference or if maybe I misread the manual or something and the same thing happened at the start. Helicopters both took off and flew away headed for the objective. HOWEVER. About half way to the objective, they stopped, turned around and came back to the airfield and picked up some of the other infantry groups waiting at the base. So I guess I'm doing everything right, it just takes awhile for them to want to pick you up and take you somewhere.

Edited November 26, 2012 by stupidwhitekid75

[Rydygier 1309]

Air cargo is assigned only for certain kinds of missions (eg not for recon). This is also dependent on distance (must be big enough). Also air units, especially if armed, can be busy with own combat/recon/whatever missions and unavailable for cargo (in debug mode map markers may be helpful to determine, where and why given chopper flies, in yours case this was probably recon mission for air units). If you want them only for cargo purpose, you can try to add their class to RHQ_NCAir category. Here is sample mission with such config, that should "stimulate" HAC to assign cargo for yours group quickly and every time to show air cargo mechanism with basic example. Your group should be assigned for capturing objective, but it is far away, so air cargo will arrive and will take you there. Use ctrl + space for better info, who is going where. Exact expected behaviour is: group is doing nothing until chopper arrives, then group goes towards chopper's position, then chopper lands, then group mounts, then chopper flies towards target area, then group is unloaded, chopper is going up, stays some seconds and flies back to the airfield, where lands.

AirCargoDemo

Edited November 26, 2012 by Rydygier

[euly 0]

Thank you Rydygier.

[mjolnir66 48]

Could you possibly look into making the commanders group up units that are low on strength to make ad-hoc units. Make it so all those 2 or 3 unit groups I have a tendancy to end up with useful.

[Rydygier 1309]

There is such mechanism, but works under certain circumstancies:

- RydHQ_Combining = true in init config (is false by default);

- Combining occurs only every reset (10 minutes by default);

-only for infantry without own vehicle (both groups);

- if two groups, that should be combined, are not more, than 200 meters away from each other (so called "exhausted" groups has tendency to gather rather close together, but not always).

Note, that this is rare thing, and this feature is practically not tested till now. So if you will test this and see any issues, tell me.

Edited November 28, 2012 by Rydygier

[PELZ 1]

sweet

[holyorangejuice 2]

Nice work. TY!

[kutya 0]

Hi guys,

I wanted to ask if anybody managed to make a decent combination of HAC and DAC? I know Orcinus mentioned it, but he never released his verion and he didn't answer my PM. I'm interested in this combination because some years ago I made something similar but much more primitive (GDCE). I wouldn't want to waste hours and hours on learning if someone already combined these two.

Thanks,

kutya

[1para{god-father} 105]

This look very very interesting

I normally use UPSMON and spawn them in and also create my markers all via script.

Is this possible to do this with DAC ? i.e. spawn them in , create the Marker objectives and move them around when needed all via script , or is this really for editor placed units & markers ?

Would DAC pick up spawned units ?

If so anyone have a demo ?

[Rydygier 1309]

Orcinus did it indeed. I saw some early, but playable test version of such mission. Some direct ingerention in DAC code was needed however (choppers case). If I'm not mistaken, last, hmm, months? he hasn't much time for Arma, so probably hence his silence. Shortly:

- HAC manipulates with existing groups;

- AFAIK DAC creates groups of units and then manipulates them too (I barely know DAC, never used it except some tests). In theory manipulation is optional, in fact, no always (I'm not DAC specialist, so this may be wrong, but this refers to mentioned choppers case, where DAC is doing some weird things to the spawned helicopters and their crew, including temporary removing of fuel, if I remember correctly);

So basic idea of Orcinus was to use DAC as advanced spawner, and HAC as later controller of that, what was spawned. All difficulty was to keep spawned units out of HAC, until become "released" from DAC's "charm". This is doable of course, but in my opinion worth of consideration is to use some simplier spawner, which the only purpose is creation, nothing else. In my opinion using DAC in such way is a bit like nailing with a microscope, unless this is about keeping some other DAC features, that I do not know.

I do not feel authorized to upload this test mission without Orcinus permission, I can only add to above, that in this case in init.sqf all HAC's init starts after releasing of DAC-spawned groups. As for later spawns, I think, that should be used limited HAC control mode, and adding new groups under HAC control (eg in RydHQ_Included array) via some script after releasing from DAC or keeping them from the creation moment till releasing excluded from HAC via RydHQ_ExcludedG array (some spawning script addition needed for adding just spawned group to that array) with unlimited, default HAC's control mode. There is several ways, I guess.

My knowledge about this ends here. :)

[kutya 0]

Thanks Ryd for your quick answer. Yeah, if DAC is only for spawning, then there are way easier methods. I thought HAC gives a task to a squad and then DAC tries to reach the waypoint (all with calling support, asking for help, helping other squads etc.).

[1para{god-father} 105]

I am so sorry I meant this Script HAC - sorry typoooo not DAC - Will HAC work with Spawned in groups etc... ( but now i know about DAC :) thanks)

[Rydygier 1309]

I thought HAC gives a task to a squad and then DAC tries to reach the waypoint (all with calling support, asking for help, helping other squads etc.).

That way will not work without really deep HAC reworking for this single purpose - to make DAC executional part of HAC.

Currently responsible for order execution are sqfs containing "Go" in their names. Also - HAC has built-in "brain" responsible for such decisions, as assigning support, help, cargo, arty, risk and forces calculation, withdrawal, stance (offensive/defensive), own morale system with chance for panic, or even surrender, combining weakened groups sometimes, reserves, etc, etc. Majority of this is operating on group/waypoint level. If you deprive all this, what is at least tricky, there will be no more HAC in fact, only routine, that sends some groups towards set objective area or known enemy. HAC's code is free, anyone can do with it what he like, so if you want, you may try achieve such replacement of HAC's execution part with DAC's routines, for sure not easy, as both, decisons and execution are deeply linked in HAC and partially "spread out" and mixed in several places. Easier way may be addition to the DAC own decision-making code linked with DAC - its "executor" instead of HAC.

EDIT: if you are still determined to use HAC as decision-making brain of DAC-executor, easiest way may be to concentrate on mentioned "Go" sqfs. Some parts must stay, as they tell to HAC some important in decision process info, eg,that given group is busy, but another may be removed and/or replaced with other code, that will use DAC somehow instead of direct waypoint assignment and waiting until is done... For example, in GoAttAir.sqf, probably lines from 53 to 130 (order execution itself - add waypoint, wait, check, if still operational, next waypoint (flanking for land, return to landing site for aerial), wait) may be replaced with something else. In some other "Go" files earlier also is part, that calculates flanking position, that may be replaced simply by enemy position.

Edited November 30, 2012 by Rydygier

[kutya 0]

No thanks, you convinced me it's fine just as it is :)

[kutya 0]

I'm pretty green to all of this, but I have two ideas. What about limiting the user to certain kinds of missions? I know classnames in the user group define possible missions. But what about explicitly defining the player group's role? For example I want to play a recon team, so my team would get only recon and patrol missions (and sure no frontal attacks). The purpose of this would be that there would be role specific gameplays.

The second idea is about implementing a wait option. So when I get garrisoned, I could fast forward until something happens. I know this could be CPU intensive, but if I recall correctly, Operation Flashpoint could be sped up more than x4 by script. If that can't be done, at least give a message (that pauses the game) that a new task arrived, so I can go walk the dog or else until I get a new mission (and the game waits for me). Actually, probably I could do this myself, but if you think it's ok, it could be implemented to the release (even if turned off by default).

[Rydygier 1309]

1. There are some possibilities in init config variables, that can be used for any group, including player's. Quote manual:

RydHQ_AOnly = [] - groups whose names are in this array will be used only for attack/defense/reserve/capture/flank missions (no recon);

RydHQ_ROnly = [] as above, but with recon and without attack missions;

RydHQ_NoFlank = [] - groups included there will be not used for flanking;

RydHQ_NoDef = [] - as above, but disables defense missions for included groups;

RydHQ_FirstToFight = [] - groups included in this array will be not considered as reserve. These groups will be constantly "attack available"; this does not mean however, that these groups always and immediately receive attack mission. This means only that such groups will be always in the pool from which a Leader takes groups for offensive missions as needed;

All these arrays are not exclusive, so given group can be in more than one array at once. Eg. If group wil be in all above except FirstToFight and idle orders will be disabled, then will be used almost solely for capturing, unless is logistic support or cargo-capable, also probably may be withdrawn when combat ineffective or overwhelmed by enemy.

2. Interesting idea, and doable too, even quite simple, I think. Thanks. This probably will be implemented in next release. I see this such way, that there will be an option turned off by default, that gives for player "faster" and "slower" menu actions and, as separate option, will be displayed hint with pause just before new order for player.

I think, that following commands will be useful :

setAccTime

hintC

"Accelerator" may be of course scripted also as separate thing, but "restrain" should be integrated. And, I suppose, after such stop-hint time should be automatically set to x1.

Edited December 1, 2012 by Rydygier