Jump to content
Rydygier

HETMAN - Artificial Commander

For HAC users: What is the maximum number of simultaneously used by you Leaders?  

63 members have voted

  1. 1. For HAC users: What is the maximum number of simultaneously used by you Leaders?

    • Only one
      3
    • Two
      18
    • Three
      9
    • Four of them
      15
    • Five
      0
    • Six
      6
    • Seven
      0
    • All eight!
      12


Recommended Posts

I thought classnames are registered in arrays instead of group names. I get it now, thanks.

And time compression would be welcome in older scenarios (WW2 and Vietnam - at least from US side) where night fighting wasn't really common (or at least wandering a Vietnam jungle in ArmA2 night, isn't really fun if you try to survive). Yeah, those commands were used in OFP time too. I just didn't write a script for too long. Actually this leads me to another idea: what about changing mission types depending on time of day? Stealth missions like recon would prefer night and lousy weather, while assault and CAS would prefer nice daytime weather? I have some weather randomizing script for Arma2 if you're interested. Relatively flexible.

Share this post


Link to post
Share on other sites

Well, I have some own simply weather dynamizer somewhere on HDD too, such things can be of course used together with the HAC, but will not become part of HAC, as HAC's purpose is different. But the point is... If you are asking for such missions kind distinction for the player, read spoiler, othewise - not needed. :)

For HAC there is always same goal, so from HAC's perspective there is one kind of mission: to win the battle. Rest of its activity is consequence of that. HAC is not kind of "dynamic mission generator for player". HAC will "use" player to own purpose (win battle), not serve to a player (is not player-centric) eg by generating especially for the player anything, including stealthy missions at nights and open fights at day. So daytime or weather condition should have only such impact on issued orders, as have on battle conduct. I admit, that currently these factors are mainly ignored during decision-making process. Their impact is limited to the obvious consequences, as lower chance for spotting enemy at night. Also at night defending troops may use flares (if have any) or call arty illumination on the foreground. That is all.

For better understanding HAC activities, here is, how this looks, simplified and in general (unless something is changed in init config):

1. If army stance is offensive (default), Leader will look for known enemy. If any is spotted, some groups are sent to flank and engage (if available, risk not too high and terrain is proper): max 3 inf, 2 armored, 1 aerial per enemy group. If enemy is not spotted, Leader will send up to three recon groups around current objective area. If recon will return info about enemy presence, attack of mentioned pattern is commenced, if not, or Leader has tendency to risky orders (depends on his personality), will send up to three groups at once to capture objective area. Also, in some moment, if enemy is known and reserve is available, Leader may sent some groups with "main flanking" mission, to outflank whole known enemy positions.

2. In defensive mode part of forces in two randomized possible manners will be deployed around HQ and/or taken objectives (randomly or all except recon on reverse slope relative to the expected enemy attack direction). Others will serve as reserve, any time ready to reinforce most threatened part of defense perimeter.

For some missions external cargo may be assigned, also battlefield is constantly watched, if somewhere is needed logistic support, as medevac, refuel etc. or if arty support is somewhere needed and possible. All this with many conditions, factors, and blurred by limited randomization.

There is also higher, BigBoss level, where goal is to take whole map, and where HAC can indepedently choose objectives for controlled Leaders, and in the future probably will be also very different guerilla mode, but this is another story.

Now, when we have this overall picture of HAC nature - which mission will be issued to the player depends on kind of his group, current need, group's position, terrain, group's condition, optional customization by init config etc. It is not dependent on weather or daytime. For example if you play as fuel truck driver - you can easy guess, what kind of missions you will get, regardless of daytime, if you play as infantry - possibilities are many.

Differences, that comes to my mind, because of weather/daytime factors is, perhaps, as you wrote, that at night may be sent more recon missions before proceeding towards objectives (slower advance) and when visibilty is poor, air support may be not so willingly used, as perhaps less effective. Maybe also safezone of arty missions should be bigger then. But this, as we see, will haven't direct impact on kind of missions for player. Only statistical - the more missions of given kind, the bigger chance, that also player will be sent with such order (if represents effective for that mission kind of force). So, I'll think, what is doable and what reasonable enough to burden scheduler with even more calculations, and we will see. :)

Edited by Rydygier

Share this post


Link to post
Share on other sites

I wouldn't restrict weather/daytime dependent mission selection to the player only, the whole battlefield should IMO at night use more scouts and less open conflict. Except what you mentioned, guerilla tactics, they would attack more at night and in lousy weather to avoid open conflict.

Oh, and I just talk ideas :) I like this concept very much, that's why I try to help make it even better.

When I get a couple debug missions finished, maybe I'll try to make a variation of your work. If I get the time. I've copied your BigBoss mission to Takistan, added some more units and it works like a charm.

Share this post


Link to post
Share on other sites

Rydygier, will you please make a demo mission on how to use "RydBB_MC"? If I understand the idea of the variable correctly, the user can tell BB where the battlefield is located. So, islands that may be difficult for BB to read are easier to play with HAC if we can see a demonstration of MC.

Thank you Rydygier.

Share this post


Link to post
Share on other sites

Sure. Yes, you understood the idea correctly. Here you go:

MC Demo

Used is simplier mode, via trigger, so init is not important, only important for stricted battlefield is trigger on the map. Note, that it is square (as battlefield will be always square), also, that armies can stand outside, but will go and fight only inside this square area (that's way so big "fronts", as armies must go far).

This may be useful for strict scenario to given area only and also for quickening of map reading (obvious - smaller area to analyze), when only part of map should become a battlefield (so eg all sea may be excluded).

Edited by Rydygier

Share this post


Link to post
Share on other sites
Sure. Yes, you understood the idea correctly. Here you go:

MC Demo

Used is simplier mode, via trigger, so init is not important, only important for stricted battlefield is trigger on the map. Note, that it is square (as battlefield will be always square), also, that armies can stand outside, but will go and fight only inside this square area (that's way so big "fronts", as armies must go far).

This may be useful for strict scenario to given area only and also for quickening of map reading (obvious - smaller area to analyze), when only part of map should become a battlefield (so eg all sea may be excluded).

Thank you. Can the shape be a rectangle, or must it be a right-angle square?

Share this post


Link to post
Share on other sites

Shape and angle of the trigger can be any and this will work, however battlefield will be always square (edges length is taken from first trigger's dimension) and with angle = 0. Simply, if you set trigger as angle 0 square, you will get exact visualization of battlefield, this is of course useful. Otherwise battlefield will be created too at triger's position, but trigger's shape and/or angle will be no corresponding to battlefield's shape. Also, as stated in the manual, length should be divisible by 500 (recommended as optimal sector length, technically not necessary, I think).

Edited by Rydygier

Share this post


Link to post
Share on other sites

After experimenting a couple of days, I noticed an issue and I think it can be relatively easily fixed. When BB is used, the leaders are relocated even at start. I noticed, that on islands with water, the BB tends sometimes to relocate leaders to water areas. I remember DAC solved this issue by skipping position candidates that are below certain altitude (5m above sea level I think). Could this be added/fixed in HAC please? It's a game killer when you lose an entire HQ just because the leader relocated to a water area and all of them drowned. I'd do it myself, but I really don't get my way around HAC code. I've found the part that relocates, but dunno what to change.

BTW I know about restricting the battlefield area, but it's more a workaround. Imagine a map with two large separate islands for example. Or a narrow "ground bridge" between them, where probably most of the conflict would happen.

Oh, and if all goes well (which usually isn't) I'll probably release a couple variants of ready baked HAC missions, for Isla Duala, Lingor/Dingor and Unsung. Hopefully around new year time.

Share this post


Link to post
Share on other sites

Leader relocated at the start must be the one set as reserve. Just yesterday saw this problem with them too. There is

surfaceIsWater

I generally use this in HAC, but in this single case I just missed this check. It is already fixed, so in 1.32 reserve postion shouldn't be set on water (on the sea anyway, ponds are another matter).

BTW if you have a map with two separated islands, without any land link, and you set your army on one, and targets on second - army will go swim. I can make HAC to avoid set target area for groups on water, but do not know, how reasonably check, if to the given land position leads some land path (or at least a bridge) or not.

Share this post


Link to post
Share on other sites

Thanks for the info. You're probably right, because I've never seen more than one leader going swimming at start.

On Isla Duala they use bridges just fine (occasionally someone dies, but that's due to limited Arma2 pathfinding). I didn't mean completely separated islands, but "almost islands" with a narrow ground bridge, or islands that are connected with a regular bridge.

Yeah, islands can be tricky.

---------- Post added at 20:06 ---------- Previous post was at 19:15 ----------

I managed to somewhat localize a problem I have, please help.

I use 8 leaders in BB mode, all leaders having about 8-10 squads on them, so it's hardware heavy. Seems that there is some timing issue:

BB A awakes fine, leaders A-D awake too, but then Boss A starts thinking and no scripts run past "BB A is calculating frontline divisions" or such. I suppose I need to give more time for some script, but I don't know which.

On the map, interest points are marked, no leaders are marked and nothing happens (not even BB A's team gets orders).

Share this post


Link to post
Share on other sites

Hmm. If scheduler is overloaded, even big delays are possible. Seen this too sometimes. BTW. Leaders are initialized without wait for BB, but then all of them are waiting, until BB end his initial cycle (reading the map and rest), and only then Leaders start to issue own orders. Also possible is permanent stuck, if some error occured (check RPT file for error logs). For example thanks to Lucidity was able to fix one problem, that in rare, certain circumstanices permanently stops whole script.

Also, if mission doesn't need addons, that I haven't - I can check it as repro mission.

Share this post


Link to post
Share on other sites

Ok, I'll try to solve it. I currently use latest Isla Duala with Duala units, which is usual, nothing special. But if you want, I think I can reproduce this in vanilla too, but it would take time to revert.

Share this post


Link to post
Share on other sites

I have older Duala, do not know, if such mission will be compatibile with it, but I can try.

Share this post


Link to post
Share on other sites

Here's 002 which most of the times works fine for me:

http://www.filedropper.com/bbdualab002lightisladuala

Here's 003 which always break after "division" dialogue:

http://www.filedropper.com/bbdualab003lightisladuala

In 003, I added 6-7 air units and about 30-40 empty vehicles all around the map. Once the BB passed when I removed the empty vehicles. But as I know, they don't count to the Arma2 group limit. And I added some delays in Bigboss.sqf

Sorry for the messy post, but the BI forum displays in dialup version for me the whole day.

Share this post


Link to post
Share on other sites

I got this stuck. I know, where it happens. This is not code error, but rather some logic problem with one problematic while loop, where such problems was before. Apparently fix wasn't 100% effective, and in some circumstancies, that occurs on Duala, problem is back and "while" condition is never met. Tommorow will try fix this for next release. BTW, many things are randomized, so once mission was initialized properly (four times - no).

Share this post


Link to post
Share on other sites
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. :)

I used to use DAC to spawn for HAC. From memory I used to delay HAC init until DAC had spawned and released (I think I wrote a script to release from DAC, there are others available on this forum).

Share this post


Link to post
Share on other sites

Thanks jiltedjock, but now that I understand HAC more, I'm satisfied with a simple editor based force creation.

@Rydygier: what about implementing unit caching, like Silola did for DAC? That could boost performance on large maps with many units. I know it ain't easy to implement, but maybe you could look how Silola did it. When no enemies or player around, the group is reduced to the leader only. Once enemies or player gets close, the group is re-created. With large view distance the effect would be smaller of course.

Share this post


Link to post
Share on other sites

Caching is a topic, that returns from time to time. Understandable, as amount of units, that HAC "likes" to use is heavy for CPU, especially during combat, when multiple times danger.fsm is activated. Problem is the same. HAC calculates own decisions basing on units really present on map. Cached unit isn't present, is disappearing, removed from the map. For HAC this means KIA, morale drop and all other conseqences of massive losses. Preventing of that means rewriting big parts of HAC's code, so HAC could in many places check also some special variables where number and kind of cached units is stored till de-caching. Probably possible (rather in form of separate addon, compatibile with adapted HAC), but too complex and potentially too troublemaking, for now anyway. Maybe someday, when there will be nothing else to do... I heard once, that someone did some chaching compatibile with HAC, but don't remember who, where and if this is true indeed.

BTW yours stuck problem was just solved, I hope, tommorow I'll try to implement rest of features for 1.32, so Sunday-Monday-next week possible release.

Share this post


Link to post
Share on other sites

I dont mean to drag on about it and please forgive my complete lack of knowledge for code/scripting but there is already a great caching script created and available, could HAC somehow make all it's initial calculations and 'then' run the caching script... So HAC some how keeps initial group numbers in it's memory and continues to give waypoints accordingly, and only when caching script is activated (group respawns to full numbers) does hac do a re-check, and only on the re-activated groups.

Would this some how actually save on performance in another way as HAC would only need to recheck numbers/morale etc when the cache script activates? It will only activate when groups spot/engage each other or I believe when they are at a certain distance to each other.

I.e. HAC only checks group numbers when cache script activates, or HAC even manages the cache sript?

Of course that's the part that takes months of your life away lol, not requesting or anything, just thinking about it as the cache script is already made. Sorry if that's been discussed before, must get tiring answering same subject :)

Edited by Katipo66

Share this post


Link to post
Share on other sites

HAC makes such calculations every cycle (re-counts units, groups, known enemies, morale, stance). Also some other loops and checks needs full info about group, eg cargo place check for cargo system... The more I'm thinking about it, the more problems pop-up. Caching is good for player-centric situations/missions/addons, when interactions have place only around the player. But HAC's activities are not limited by players view distace. How to handle firefight between two distant (so cached) groups? How to calculate effects of arty shelling, if target is cached? And if cached is also battery, how to manage arty mission at all, as this relies on BIS_ARTY module, that must be synced with "physical" battery, that disappeared? How to check fuel consumption of cached vehicle for re-fuel logistic support? And so on, and so on.

Edited by Rydygier

Share this post


Link to post
Share on other sites

Hmm ok, anyway you have probably seen this script

Not all units cache, group leader is still on the board and moving in the real world, groups respawn to full strength before firefights... it only acts on infantry units not artillery/vehicles etc.

Anyway it's for the too hard basket and been discussed to death!! All good in ze hood.

Share this post


Link to post
Share on other sites

It's tough to implement, but here is the main idea. You need to store all data regarding cached units that you may need. Unit count in a group, unit class for each unit, unit gear etc. etc. So you would virtualize the whole faction except the leaders. Then there would be a "demand" trigger which would recreate the group based on the virtualized data. Demand could be "player is near", "enemy is near" "arty is firing near us" for most units, while arty would have "arty mission needed" additionally. Fuel consumption remains an issue. Maybe constant time based, though it would be far from accurate. There is a considerable overhead to this type of caching, but I think it would be still faster that to calculate all AI and collision for every unit the whole time. But it is really tough to write it correctly. To be honest, I wouldn't venture into this if I was in your place :)

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

×