Jump to content
Rydygier

HETMAN - Artificial Leader

Recommended Posts

BTW. getHQInside will do nothing if LRelocating is false. Not recommended in defensive mode - Leader will go to the last taken objective (as NObj = 5, last will be 4th). As UAVs - groups with such vehicle are treated as air units, usually recon air, if not CAS - unarmed. This may be changed by RHQs(ubtract) and moving classnames into other categories, but anyway HAL hasn't any special code to manage A3's infantry groups with UAVs and will issue orders to them as for ordinary aerial units.

HAL 1.12 released. Changelog:

- fixed code for relocating Leaders;

- fixed risk of infinite loop stuck in defensive mode.

Edited by Rydygier

Share this post


Link to post
Share on other sites

Wow, thanks for the quick fix.

Now, just to be clear.

If I have: RydHQC_Order = "DEFEND"; and RydHQC_NObj = 5; LeaderHQC will move himself and his group to RydHQC_Obj4 ?

Do I understand correctly by assuming that my empty trigger "RydHQC_Obj1" corresponds to "RydHQC_DefFront1 = ["S",""];" and thus, defending groups should be facing south at this trigger?

Does LeaderHQC's group face South East or West? Given that I have:

RydHQC_DefFrontL = ["S","E"];	//Leader's Defenders facing South East
RydHQC_DefFront1 = ["S",""];	//1st perimeter facing South
RydHQC_DefFront2 = ["E",""];	//2nd perimeter facing East
RydHQC_DefFront3 = ["N",""];	//3rd  perimeter facing North
RydHQC_DefFront4 = ["W",""];	//4th perimeter facing West

Or does HAL automatically assign perimeters without using the RydHQC_Objs locations at all?

Share this post


Link to post
Share on other sites
If I have: RydHQC_Order = "DEFEND"; and RydHQC_NObj = 5; LeaderHQC will move himself and his group to RydHQC_Obj4

Only, if you set as true RydHQC_LRelocating, which is not recommended in "defend". I mentioned about that, because noted, you set getHQInside for C leader, while this works only with LRelocating enabled.

Do I understand correctly by assuming that my empty trigger "RydHQC_Obj1" corresponds to "RydHQC_DefFront1 = ["S",""];" and thus, defending groups should be facing south at this trigger?

Yes.

Does LeaderHQC's group face South East or West? Given that I have:

HQ group is not considered as defender, so shouldn't be touched by this.

Or does HAL automatically assign perimeters without using the RydHQC_Objs locations at all?

No, HAL always takes as perimeter centers HQ position and each of taken objective positions.

Share this post


Link to post
Share on other sites
Guest

Thanks a lot for the headsup about the new version mate :cool:

Release frontpaged on the Armaholic homepage.

==================================================

We have also "connected" these pages to your account on Armaholic.

This means in the future you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

Share this post


Link to post
Share on other sites

Found this in my RPT while running the RydBB Demo:

Error in expression <(count RydxHQ_Handles),_handle];

{

if (scriptDone _x) then

{

RydxHQ_Handles set>

Error position: <scriptDone _x) then

{

RydxHQ_Handles set>

Error scriptdone: Type Number, expected Script

Additionally in PDF:

optionally debug (RydBB_Debug), additional objectives’ arrays (RydBB(a/b)_Str) and if BB

should look for objectives on his own (RydBB(a/b)_CustomObjOnly).

When actually variable is (RydBB_CustomObjOnly):

if (RydBB_CustomObjOnly) then {_strArea = _BBStr};

Do you use GIThub or Bitbucket? I'd love to contribute. Check out SmartGIT as a client, really easy to use.

Share this post


Link to post
Share on other sites

Thanks for reporting. This first thing is known. Hopefully does not break anything. BTW it is interesting case - unless I miss something, theoretically this shouldn't happen. It is for the function, that collects all spawned threads to termiante all at once if requested. This function is run each time some thread has to be spawned. It looks like:

RYD_Spawn = 
{
private ["_arguments","_script","_handle"];

_arguments = _this select 0;
_script = _this select 1;

_handle = _arguments spawn _script;

RydxHQ_Handles set [(count RydxHQ_Handles),_handle];

	{
	if (scriptDone _x) then
		{
		RydxHQ_Handles set [_foreachIndex,0]
		}
	}
foreach RydxHQ_Handles;

RydxHQ_Handles = RydxHQ_Handles - [0];

//diag_log format ["New Handle - time: %1 count: %2",time,count RydxHQ_Handles];
};

As you can see it removes already ended threads from the array by replacing them with 0 and immediately after that it removes all zeroes from the array. Yet, in the next cycle sometimes it finds somehow preserved in the array 0. In such case this error is generated. At the moment no idea, how it is possible. Maybe you see here something, I don't? This function is called. Apart from this function, RydxHQ_Handles is only once defined as empty array and is used in the function, that "kills" Hetman - for terminating each contained handles.

My only theory for now it is due to scheduler overload (so this function is called again by another Leader's orders code before previous run is finished - now I have even some small idea to prevent scriptDone check on encountered zeroes...).

I think, main Hetman's problem now are his roots. It was my second serious script in life, first version was done when I knew perhaps 25% of my current scripting knowledge, for example had no idea about functions. Later code passed two or three fundamental overhauls, still in the core remained this poor designed architecture basing on many parallel threads. Thanks to this function I was able actually to count number of threads, HAL is running. Too many. Even after latest improvements. Also sometimes seems, there is more threads, that should be. But only in heavy scenarios, like BB demo, thus my theory about overload. Anyway, apart from RPT message this should be harmless.

Second thing seems to be plain mistake in the manual. I'll correct it at first opportunity (next update). Later in the same manual fortunately it is defined properly.

I checked once GITHub, but never convinced myself, I really need to use it. Hard to change old habits. :)

Edited by Rydygier

Share this post


Link to post
Share on other sites

HAL 1.13 released. Changelog:

- fixed issues with logistical support check that was spamming scheduler with numerous threads;

- improved detecting of vehicles that need reammo;

- fixed RPT error message;

- performance fix for BB debug.

Share this post


Link to post
Share on other sites
Guest

Thank you very much for the headsup about the new version mate :cool:

Release frontpaged on the Armaholic homepage.

==================================================

We have also "connected" these pages to your account on Armaholic.

This means in the future you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

Share this post


Link to post
Share on other sites

Fixed some bugs, classnames, etc for debug markers/BigBoss for HAL 1.13

Also fixed RydHQ_ForceAAO for leaderHQE

Please see:

Fixed RydHQ_ForceAAO to RydHQE_ForceAAO

Fixed RydHQ_AAO to RydHQE_AAO:

https://bitbucket.org/zorrobyte/hal-a3/commits/b31bed1aa24b6f10d26cbcf911a06e69655b3087

Fix for _HQPosMark (type group expected object):

https://bitbucket.org/zorrobyte/hal-a3/commits/30e570372a74d1e6f653d6580d5c8f548f8d22d5

Fix for _HQPosMark (type group expected object) in addition to above:

https://bitbucket.org/zorrobyte/hal-a3/commits/7ac3ffb7a970e2c58c42797c369c7484e5267c6a

Fixed "Arrow" to "mil_arrow":

https://bitbucket.org/zorrobyte/hal-a3/commits/d87272be053aac0922e96ff1d369fbc898a48812

Share this post


Link to post
Share on other sites

Hey, thanks a lot! :) I'll apply these fixes ASAP.

One thing about the second: you changed (group _x) for (leader _x), but this variable is obtained earlier from the group name space, as should be, not leader's, so this should be _x setVariable in fact, as _x is HQ group. Must test this though. Same for third, I suppose.

Edited by Rydygier

Share this post


Link to post
Share on other sites

HAL 1.14 released. Changelog:

- several code tweaks and fixes;

- fixed a mistake in manual.

Share this post


Link to post
Share on other sites
Hey, thanks a lot! :) I'll apply these fixes ASAP.

One thing about the second: you changed (group _x) for (leader _x), but this variable is obtained earlier from the group name space, as should be, not leader's, so this should be _x setVariable in fact, as _x is HQ group. Must test this though. Same for third, I suppose.

1.14 seems to have fixed the type group expected object for marker debug without (leader _x) Nice!

Question about RydHQ_AAO, as BB uses RydHQ_Obj1 only (as RydHQ_Obj1 is all Objs) does AAO work with BigBoss mode enabled? I have yet seen leaderHQ assign multiple Cap orders for more than one objective with BB on but have when manually setting Obj1,2,3,4.

Assuming AAO doesn't work with BB (as only one combined RydHQ_Obj1/2/3/4), would it be possible to change BB in a coming version to assign RydHQ_Obj1,RydHQ_Obj2,RydHQ_Obj3,RydHQ_Obj4 for each leaderHQ instead of just one RydHQ_Obj1 for AAO to function with BB? Additionally if such a change were to be made, secondary objectives RydHQ_Sec1,RydHQ_Sec2 should also be set for additional dynamizing as some missions such as IDLE, etc can use RydHQ_Sec1. RydHQ_Sec1,RydHQ_Sec2 could be set for areas in which BB deems not primary but still strategic (areavalue less than 2, FO positions(hills/mountians), etc.

BB can/could iterate RydHQ_Obj1,2,3,4 from closest to furthest from leader with Sec1,2 from between Obj1->Obj4 as to not set distant Secondary Objectives far from the Objs in case enemy attack, support, etc in Primary Objective areas so sent units can be retasked back into Primary Objectives if needed.

I think Epic Battlefield System had limited (dumb) ability to set Objs; will put on todo list to experiment. Also MSO has a townmgr or other scan ability to find "important" areas, will experiment as well in time.

Share this post


Link to post
Share on other sites

Not remember for sure, but in BB difference made by AAO should be more groups sent at once to take an BB objective, as in fact Leader is sending portion of groups towards several of his objectives, just all are in the same location. I think, current way is OK. Making, so leader will try to reach many BB objectives at once IMO will stretch his forces too much due to relatively bigger distancies between BB objectives. And I can forsee many complications and deep changes to do for BB due to, what you suggest. Secondary objectives for BB is something to consider, but rather nothing, that will happen very soon.

BB was designed to be compatibile with MSO (MSO important places can be added to the BB via custom strategic areas array, I think, anyway thats the purpose of this array - ability to add areas found by custom code).

Share this post


Link to post
Share on other sites
Guest

Thank you very much for informing us about the new version :cool:

Release frontpaged on the Armaholic homepage.

==================================================

We have also "connected" these pages to your account on Armaholic.

This means in the future you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

Share this post


Link to post
Share on other sites

Can you release script version without radio sounds, please? :rolleyes:

Share this post


Link to post
Share on other sites

If you just want to disable any AI chat, set at init this: RydxHQ_AIChatDensity = 0;

If however you want to have version without sound files at all, because of size, then here you go: HAL 1.14 soundless. (tested briefly, so should work, I hope, without errors)

Edited by Rydygier

Share this post


Link to post
Share on other sites
Can you release script version without radio sounds, please? :rolleyes:

Easy for any version. Just delete RYD_HAL\sound folder, delete or remove sound entries in Description.ext and finally RydxHQ_AIChatDensity = 0; in init.

Share this post


Link to post
Share on other sites

Actually, i just deleted sound files (and in description) and put in comment one line of the code. But other people can not guess.

Share this post


Link to post
Share on other sites

Does anyone know of any good scripts or addon that would place map markers on the group leaders?

Share this post


Link to post
Share on other sites

If you are looking for something simplistic, paste this into any place in init.sqf (eg at the very end):

nul = [west,east,resistance] spawn
{
while {true} do
	{
	sleep 5;

		{
		_myMark = _x getVariable "RYD_ItsMyMark";
		if (({alive _x} count (units _x)) > 0) then
			{
			_side = side _x;
			if (_side in _this) then
				{
				_pos = getPosATL (vehicle (leader _x));

				_color = switch (_side) do
					{
					case (west) : {"ColorWEST"};
					case (east) : {"ColorEAST"};
					case (resistance) : {"ColorGUER"};
					default {"ColorCIV"};
					};

				if (isNil "_myMark") then
					{
					_myMark = "ItsMyMark_" + (str _x) + (str (random 100));
					_myMark = createMarker [_myMark,_pos];
					_myMark setMarkerColor _color;
					_myMark setMarkerShape "ICON";
					_myMark setMarkerType "mil_dot";
					_myMark setMarkerSize [0.75,0.75];

					_x setVariable ["RYD_ItsMyMark",_myMark]				
					}
				else
					{
					_myMark setMarkerPos _pos
					}
				}
			}
		else
			{
			deleteMarker _myMark
			}
		}
	foreach AllGroups
	}
};

here: [west,east,resistance] you may decide, which sides will be marked.

Otherwise there is still functional MARTA - military symbols module in A3.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×