HETMAN - Artificial Leader

[euly 0]

Thank you Rydygier. I'm looking for makers to provide context to the radio chatter, so anyone playing can see who is calling for support or anything else.

[Rydygier 1317]

So probably to the above code should be added text with unit name at each leader? With many groups this will make kind of mess on map though. Perhaps instead I'll try to add as very special kind of switchable debug temporary markers, that for eg 30 seconds or so after chat message will show on the map where was said what? So when player see chat message, may open map just after that to check who said that. Hmm. Looks like quite nice idea to me. :)

[euly 0]

So probably to the above code should be added text with unit name at each leader? With many groups this will make kind of mess on map though. Perhaps instead I'll try to add as very special kind of switchable debug temporary markers, that for eg 30 seconds or so after chat message will show on the map where was said what? So when player see chat message, may open map just after that to check who said that. Hmm. Looks like quite nice idea to me. :)

That would be perfect. I was able to set up a dedicated server for Hetman, so it seems to work very well in multiplayer. One complaint a friend of mine had is we cannot see where any of the units are that are in fights, so map markers indicating skirmishes would be nice.

For the unit markers, I set up the MARTA module, which is nice, but I wish it had the unit names, like Delta 1-1, and such.

[Rydygier 1317]

All right, I'll think about this. Meanwhile for markers with TLs' names use such modified code:

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
				{
				_ldr = leader _x;
				_pos = getPosATL (vehicle _ldr);

				_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];
					_myMark setMarkerText (str _ldr);

					_x setVariable ["RYD_ItsMyMark",_myMark]				
					}
				else
					{
					_myMark setMarkerPos _pos;
					_myMark setMarkerText (str _ldr);

					_nE = _ldr findNearestEnemy _ldr;

					if (isNull _nE) then
						{
						_myMark setMarkerType "mil_dot"
						}
					else
						{
						_myMark setMarkerType "mil_triangle"
						}
					}
				}
			}
		else
			{
			deleteMarker _myMark
			}
		}
	foreach AllGroups
	}
};

It will also mark TLs with the triangle, instead of the dot if group knows about any enemy (may be considered as "in fight").

Edited April 26, 2014 by Rydygier

[euly 0]

All right, I'll think about this. Meanwhile for markers with TLs' names use such modified code:

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
                   {
                   _ldr = leader _x;
                   _pos = getPosATL (vehicle _ldr);

                   _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];
                       _myMark setMarkerText (str _ldr);

                       _x setVariable ["RYD_ItsMyMark",_myMark]                
                       }
                   else
                       {
                       _myMark setMarkerPos _pos;
                       _myMark setMarkerText (str _ldr);

                       _nE = _ldr findNearestEnemy _ldr;

                       if (isNull _nE) then
                           {
                           _myMark setMarkerType "mil_dot"
                           }
                       else
                           {
                           _myMark setMarkerType "mil_triangle"
                           }
                       }
                   }
               }
           else
               {
               deleteMarker _myMark
               }
           }
       foreach AllGroups
       }
   };

It will also mark TLs with the triangle, instead of the dot if group knows about any enemy (may be considered as "in fight").

I used your code with the MARTA module and it is exactly what I want. Thank you Rydygier.

The unit markers are great and they seem like something that should be part of the debug options. Maybe next you could mark areas on the map that units are requesting support? That could clutter the map, but perhaps it could be option for time-out in the init?

By the way, on the dedicated server, we cannot hear the vocal radio chatter, so it must be localized to the server or breaking.

[Rydygier 1317]

Yes, whole thing, this feature included, was designed to be server side (in fact, to be precise, Hetman, as all my works, is designed to be SP, but for HAL added some crude MP compatibility patches, I was able to provide, to allow clients to see notifications for player). Although I'm not MP specialist, I do not know nor want to seek for, any way to generate sound client side without generating massive net traffic due to frequently sent through the net sound files (sounds should be duplicated on each client and synchronically locally played?). Anyone can try to do such thing for Hetman though.

Yes, I can integrate above code as yet another optional debug mode, but as for supported areas/showing temporary on the map where was said what will be separate thing too.

Version, that should prevent a bit mysterious undefined _myMark error (I hope):

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
				{
				_ldr = leader _x;
				_pos = getPosATL (vehicle _ldr);

				_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];
					_myMark setMarkerText (str _ldr);

					_x setVariable ["RYD_ItsMyMark",_myMark]				
					}
				else
					{
					_myMark setMarkerPos _pos;
					_myMark setMarkerText (str _ldr);

					_nE = _ldr findNearestEnemy _ldr;

					if (isNull _nE) then
						{
						_myMark setMarkerType "mil_dot"
						}
					else
						{
						_myMark setMarkerType "mil_triangle"
						}
					}
				}
			}
		else
			{
			if not (isNil "_myMark") then
				{
				deleteMarker _myMark
				}
			}
		}
	foreach AllGroups
	}
};

Edited April 27, 2014 by Rydygier

[euly 0]

It works, but now all the groups have the word "Remote" after their call signs.

[Rydygier 1317]

I don't know nothing about this. Probably some another MP issue such as adding "remote" word to the non-local AIs or something like that. No idea, what to do with that apart from CPU costly string manipulations, that are no go IMO.

[euly 0]

I don't know nothing about this. Probably some another MP issue such as adding "remote" word to the non-local AIs or something like that. No idea, what to do with that apart from CPU costly string manipulations, that are no go IMO.

It is isolated to the server, as Remote does not appear in SP.

[delta99 34]

I don't know nothing about this. Probably some another MP issue such as adding "remote" word to the non-local AIs or something like that. No idea, what to do with that apart from CPU costly string manipulations, that are no go IMO.

Must be something else. That shouldn't happen in MP.

[Rydygier 1317]

HAL 1.15 released. Changelog:

- optional, customizable group markers;

- optional radio chatter temporary map markers;

- artillery handler upgraded (reliability);

- manual updated.

Two new init variables introduced, both shared by all Leaders:

RydHQ_GroupMarks = [] – shared by all Leaders. Customizable, simple map markers showing current position of group leaders. To enable these markers for given side(s), include chosen side(s)s into this array. Include also number 0 if you want displayed at each marker name of marked unit. Color of the marker depends on side. Marker will be by default of dot shape if group doesn’t know about any enemy or triangle, if enemy is known (assumed as “group in combatâ€) Example: RydHQ_GroupMarks = [west,resistance,0]; – will show blue markers for west groups, green markers for independent side and no markers for east side. Name of group leader will be attached to each mark;

RydHQ_ChatDebug = false – if true, for each radio chatter message its sender’s position will be temporarily (30 seconds) marked by map marker with sent sentence. Shape and color of this marker depends on kind of the message. Thanks to this player will know, from where all radio communications come;

[Guest]

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

Release frontpaged on the Armaholic homepage.

HETMAN - Artificial Leader v1.15



Community Base addons A3

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

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!

[sonsalt6 105]

New update v1.15 available at withSIX. Download now by clicking:

[euly 0]

Well done Rydygier.

[Georilla 6]

Does anyone have a suggestion to simulate somekind of "whole island" warfare, without stressing too much on the CPU? I know ALIVE uses caching methodes, but I'd rather have more control of the exact composition of forces (realistic companies/batallions etc.) than letting it happen dynamically.

[euly 0]

Does anyone have a suggestion to simulate somekind of "whole island" warfare, without stressing too much on the CPU? I know ALIVE uses caching methodes, but I'd rather have more control of the exact composition of forces (realistic companies/batallions etc.) than letting it happen dynamically.

I have a number of whole-island missions that I'm always working on for just myself to play. I actually built a third computer to act as a server just to play singleplayer ArmA3/HAL missions. I figured out how to get my girlfriend's PC to be a Headless/Dedicated Client (off-loads AI calculations to another computer) and connect to my new server, so I have sort of isolated the performance issue to rule out HAL as solely responsible. Even with three computers on a LAN sharing various tasks, I still had performance issues related to ArmA 3 simply just not being fully optimized. 200 units seems to be around ArmA 3's performance ceiling. ArmA 2 OA could handle around 500 units, so we can see where BI's focus was this time around. With more than 200 units, performance drives off a cliff. The grade of the cliff depends on system specs, but frame-rate always tells the truth.

The biggest complication to whole island warfare, besides performance, is HAL working at a slow, methodical pace, without regard to problems compounded by time and distance. I set up my dedicated server so I could leave it running HAL missions for 5, 10, or even 20+ hours. The vast majority of that time is an absence of activity and agonizing performance. The units often become too far apart to to support each other effectively, or at least, aesthetically. Helicopter transportation is the only practical solution, but HAL is not always responsible with available transportation, so picking the island and area of operation becomes important.

HAL works well on Stratis, but Altis is a different story. HAC had trouble with oddly shaped islands and water, so the best islands to use were symmetrical without rivers or lakes. I don't believe HAL is fundamentally different from HAC, so Altis must be limited to the larger land masses on the west and east sides. If you tried to use the entire island, you probably would not see a performance decrease, but HAL may not function properly, which would break the mission. Part of understanding how to help performance is how to best prevent HAL from wasting time and resources.

What I've found is that units must be placed very strategically to maximize their effectiveness in cooperation with the leader. I think that only having two leaders (with RydHQ_SubAll = true) should minimize the HAL workload, but I'm not sure. Rydygier can clarify. Placing units in the field, rather than at a starting location, facilitates HAL's recognition of unit placement. I prefer to place recon units and snipers far out into the map in places I hope HAL will utilize them, but HAL can often decide to just send them home or to locations that will not matter. That happens regardless of the leaders HAL personality, which is annoying. Units can sometimes take a very long time, such as hours, to finally be useful to HAL, so having convenient logistical support is vital, such as transport, ammo, and repair trucks tucked away in semi-safe places on the map (I place them under vehicle camo nets and hope for the best). Be careful of adding too many support/transport units, or you will have many trucks and helicopters sitting, wasting resources while HAL has them assigned as excess reserves. Each unit group is part of HAL's cycling process, so even if the group is not doing anything, the group is involved in HAL's matrix of processing. Support is one of HAL's weaknesses, though, so I'm hoping that with the upcoming Helicopter DLC and sling loading feature, Rydygier will incorporate helo transport/support truck delivery.

As for technical suggestions, one trick that works well is to minimize the mission.sqm file size by eliminating as much clutter as possible. This helps the game speed up the initial read time and following frame-rates. A lot of people don't know or care about this and it doesn't really matter for smaller missions, but with large missions with hundreds of units on the map, the game slows down dramatically when it has to take time to process every bit of detail for all those units.

Here are my tips:

Reduce or remove unnecessary objects and triggers from the map. Many people use triggers for things that can be added to the init.sqf, such as turning the grass off (setTerrainGrid 50).

All units must be facing north (0 degrees), have little or nothing in their init lines, and not be sync'd (so use RydHQ_SubAll = true, RydHQb_SubAll = true for the two leaders).

This is what a typical unit looks like in the mission.sqm:

       position[]={11209.946,38.736324,11755.095};
                   id=10;
                   side="WEST";
                   vehicle="B_soldier_AT_F";
                   leader=1;
                   rank="CAPTAIN";

When a unit is placed on the map, the unit's information in the mission.sqm is minimal because the game acknowledges defaults and only lists differing information. For example, by default, the units azimuth is 0 (the direction the unit is facing), but that is not listed in the mission.sqm because the game already knows some default information, so that is likely a component of optimization. If you change the direction the unit is facing, that information is added to the unit's details. HAL does not care about unit azimuth, so changing the direction units face is pointless unless a unit is static or has a purpose dependant on initial line of sight.

For example, in a mission which every unit is facing a non-default direction, has a non-default skill, is set to not be in formation, is sync'd to a commander, and has added info to their init lines, they would look like this in the mission.sqm:

       position[]={11209.946,38.736324,11755.095};
                   azimut=123.456789;
                   special="NONE";                    
                   id=10;
                   side="WEST";
                   vehicle="B_soldier_AT_F";
                   leader=1;
                   rank="CAPTAIN";
                   skill=0.60000002;
                   syncId=2;
                   synchronizations[]={0};
                   init="[group this,getPos this,210] call BIS_fnc_taskPatrol";

This doesn't look like much, but those six extra lines become multiplied over hundreds of units, which causes the game to take longer to read and respond and allow HAL to process.

Other tips:

When you are in game and you must change the direction of a unit, type in integer numbers for the unit's direction. If you rotate the unit with your mouse, you'll likely end up with a float (number with a decimal), which adds extra characters to the mission.sqm. The same issue affects skill too, but unfortunately, the slider bar is difficult to land on a whole number, so editing the mission.sqm may be necessary if you have modified skills at all.

Let me know if that helps.

Edited May 19, 2014 by Lucidity
more info

[Rydygier 1317]

I think that only having two leaders (with sub-all=true) should minimize the HAL workload, but I'm not sure. Rydygier can clarify.

Indeed, although it was seriously optimized through few latest versions, the more Leaders in game, the more additional loops even if amount of groups on map is not changed. This will not affect FPS, but increases load of the CPU computational power allocated for scripts.

Fact is, the more AI doing things on map, the more CPU load, so hard to not overload CPU with "whole map warfare" (hundreds of units, whole batallions etc.) without caching/dynamic spawning (what ALiVE does, is very special kind of "total" caching too, I suppose groups become fully virtual, when far, without any "physical" representation, still active. That saves FPS and overal CPU load at cost of more scripts needed to handle virtual "groups").

Headless Client may be an answer for some, as I heard.

[kremator 1065]

Zorrobyte has a solution for whole island warfare, with cached AI. Looks promising so far.

[Georilla 6]

Interesting read Lucidity, I didn't realise the engine would take things so far as even letting a simple unit direction in many numbers take a toll on CPU power. I will take that in consideration better now, same as the skills bar. I will see where I get. I realise Altis is a tricky island for ai, but I still hope to accomplish somewhat of a realistic invasion/war going on.

I grew up with war simulations and other coop-like shooters, and AI has always been my biggest issue in trying to create realistic things. OFP, Armed Assault, ArmA 2, ArmA 3. While definitely improving bit by but, I am still disapointed that we are still not there where I hoped we would be now. I guess the real issue is raw cpu power, for getting to the amazing humanlike ai we all want, on lower squad levels and also higher hq level. With good performance and high number of entities. That is still the dream.

Edited May 19, 2014 by Georilla

[delta99 34]

Interesting read Lucidity, I didn't realise the engine would take things so far as even letting a simple unit direction in many numbers take a toll on CPU power. I will take that in consideration better now, same as the skills bar. I will see where I get. I realise Altis is a tricky island for ai, but I still hope to accomplish somewhat of a realistic invasion/war going on.

I don't think this is a useful optimization whatsoever. It is not like the mission.sqm is read over and over and over again. It is read at mission start and likely never referenced again. So this optimization would only be relevant to initial loading time. Doing it likely shaves off a couple hundred milliseconds or MAYBE seconds with 100's or 1000's of units. In other words this would be the absolute last thing you would even think about optimizing. And then at that point you still wouldn't bother!!

[euly 0]

I don't think this is a useful optimization whatsoever. It is not like the mission.sqm is read over and over and over again. It is read at mission start and likely never referenced again. So this optimization would only be relevant to initial loading time. Doing it likely shaves off a couple hundred milliseconds or MAYBE seconds with 100's or 1000's of units. In other words this would be the absolute last thing you would even think about optimizing. And then at that point you still wouldn't bother!!

I discovered this playing OFP years ago while using scripts such as the first GroupLink, Improved AI by Bremmer, and others like USPMON. I realize that my suggestion does sound like BS, but the way the game works with what seems like Page Filing, the read time on the mission.sqm is significant because the initial read bleeds into following performance, which is why spawning units on an empty map has less of an impact on performance than loading those units from the mission.sqm, but we can't do that with HAL. This is why best piece of hardware to improve overall performance in ArmA is an Solid State hard drive or a ram drive (a virtual hard drive loaded to memory). If this were not the case, then all that would be needed would be a better CPU, GPU, and more memory, but it's not because the game is constantly going back to read the drive, which is the bottleneck. The game may only read the mission.sqm once, but for whatever reason, tens of thousands of lines and hundreds of thousands of characters in a mission.sqm drastically affect load time, which overlaps into everything else. Like I said, with smaller mission.sqm's (or without HAL), this is all irrelevant.

[Rydygier 1317]

which is why spawning units on an empty map has less of an impact on performance than loading those units from the mission.sqm, but we can't do that with HAL.

Yes, we can, AFAIK. You can do all spawning, and then run the Hetman to controll all, what was spawned, and all should work same, as when groups are editor placed (unless I'm not awared about something specific for A3, that makes it impossible). You can even spawn and add new group under HAL's control in the middle of HAL activities, although this will impact HAL's morale like reinforcements. For example there was working (mostly) combinations of DAC as a spawner and HAC as controller in A2. The problem was, releasing groups from DAC's control wasn't 100% reliable, but that's BTW.

HAL only doesn't tolerate caching of groups already under his control, as he can't handle cached groups properly and these groups are frozen, so no responding on HAL's orders. ALiVE (and maybe Zorrobyte's) solution combines caching with keeping some representation of the group active (cached groups still are doing things), so at least group is theoretically still responding on the issued orders, also perhaps may be even affected by long range events like beeing under artillery fire, but teaching HAL handling properly groups cached in ALiVE manner (if I'm guessing right this manner, not studied that) or tolerate without sewere issues groups cached in any way is extremely laborious task, that possibly may vastly increase weight (size and used CPU) of the HAL's code, which already is heavy.

Of course, if, what you described about mission.sqm performance impact is still a case in A3, the main problem lies on the Arma devs side - it looks like major area in need of optimization.

Edited May 22, 2014 by Rydygier

[euly 0]

Yes, we can, AFAIK. You can do all spawning, and then run the Hetman to controll all, what was spawned, and all should work same, as when groups are editor placed (unless I'm not awared about something specific for A3, that makes it impossible). You can even spawn and add new group under HAL's control in the middle of HAL activities, although this will impact HAL's morale like reinforcements. For example there was working (mostly) combinations of DAC as a spawner and HAC as controller in A2. The problem was, releasing groups from DAC's control wasn't 100% reliable, but that's BTW.

HAL only doesn't tolerate caching of groups already under his control, as he can't handle cached groups properly and these groups are frozen, so no responding on HAL's orders. ALiVE (and maybe Zorrobyte's) solution combines caching with keeping some representation of the group active (cached groups still are doing things), so at least group is theoretically still responding on the issued orders, also perhaps may be even affected by long range events like beeing under artillery fire, but teaching HAL handling properly groups cached in ALiVE manner (if I'm guessing right this manner, not studied that) or tolerate without sewere issues groups cached in any way is extremely laborious task, that possibly may vastly increase weight (size and used CPU) of the HAL's code, which already is heavy.

Of course, if, what you described about mission.sqm performance impact is still a case in A3, the main problem lies on the Arma devs side - it looks like major area in need of optimization.

So HAL will recognize newly spawned units mid game, or are you talking about delaying the start of HAL after units have been spawned?

BIS has made a lot of improvements to the engine, so the problem was more pronounced in A2 and prior, but I still believe that placing units in a default fashion is good practice in combination of other methods to help HAL.

[Rydygier 1317]

So HAL will recognize newly spawned units mid game, or are you talking about delaying the start of HAL after units have been spawned?

Both possible. Of course, if limited control is used, newly spawned group mid game must be included into pool of controlled by the Leader groups in one of available ways. Spawned or not, these are groups same, as editor placed, thus HAL may handle them same way.

[delta99 34]

I discovered this playing OFP years ago while using scripts such as the first GroupLink, Improved AI by Bremmer, and others like USPMON. I realize that my suggestion does sound like BS, but the way the game works with what seems like Page Filing, the read time on the mission.sqm is significant because the initial read bleeds into following performance, which is why spawning units on an empty map has less of an impact on performance than loading those units from the mission.sqm, but we can't do that with HAL. This is why best piece of hardware to improve overall performance in ArmA is an Solid State hard drive or a ram drive (a virtual hard drive loaded to memory). If this were not the case, then all that would be needed would be a better CPU, GPU, and more memory, but it's not because the game is constantly going back to read the drive, which is the bottleneck. The game may only read the mission.sqm once, but for whatever reason, tens of thousands of lines and hundreds of thousands of characters in a mission.sqm drastically affect load time, which overlaps into everything else. Like I said, with smaller mission.sqm's (or without HAL), this is all irrelevant.

Once again even if this were true it certainly isn't worth anyone's time to strip out a few characters here and there to increase loading time. And again this is NOT going to affect anything post loading so its completely a waste of time in my opinion. Further, I'm pretty sure that loading of mission.sqm takes place while you are looking at the briefing screen before you actually launch into the game. So, the majority of the time the difference here will be zero.

Your initial post seemed to suggest this is a big performance hit throughout the mission and I simply believe it is not.