Rydygier

Good screen recorder is a problem. Fraps - 30 seconds without registration. Others - similar. Which do you use? Also when tried to make a movie light enough for my poor net connection, was too small to see anything. And too short... Also my graphic card often do strange things, when trying to watch anything on youtube. Pity, as I know, that people often prefer rather to see, how to do something instead of read about. Demos also not always are sufficient. So, whatever you do - should be helpul for some players. As HAC creator often forget, that not all, what is obvious and easy to me, will be same for other, who do not know the HAC's code, as I do.

Yeah, there are more things, that I must add to manual, when time will allow me. Recorded tutorial would be great help for many people as addition to manual and demo missions, I'm sure, but I can't do something like that personally.

I took quick look at chernaruss debugtest. You named "leaderHQ" a vehicle. But this must be a person. So if you want to have mobile, armored or air HQ, then do not name a vehicle as Leader, but instead in vehicle's init field use something like: leaderHQ = driver this; (or refer to commander or gunner or passenger (cargo), if is present). When I did that - debug was back.

If you want guaranteed 2D distance you can use something like: [(getPosATL _unit) select 0;(getPosATL _unit) select 1,0] distance (position _location); if in 3D between two points on ground level one where unit is, second, where location is, then: [(getPosASL _unit) distance [(position _location) select 0,(position _location) select 1,getTerrainHeightASL [(position _location) select 0,(position _location) select 1]];

Added new known issue to online manual: "Big Boss uses dividing map into square sectors for some calculations. For this is needed position of map center and/or map’s dimensions. I do not know 100% reliable method for retrieving this data. Used code works fine for typical, square-like or sea-less maps, but for islands of irregular shape (like Everon) or for archipelagos this method becomes not reliable. Even then BB will work, just some its initial decisions (assigning flanks to “divisionsâ€) will be made based on wrong intel." Problem is described also here: http://forums.bistudio.com/showthread.php?139264-How-to-obtain-via-script-map-s-true-center-position-%28or-map-s-size-values%29

This looks like SQS? There is no sleep command in this syntax. In SQS use ~0.5 instead. Anyway, better to use SQF.

Noticed, that currently presence of any recon, FO or sniper unit in the group will block most of garrisoning behavior except patrolling, while should to block only static defense manning, and only for these units. In next release this will be corrected, till then, if someone want to have fully operational garrison, remove from a group any recon, FO or sniper/marksman.

Often, and annoying - just after 1.2 release found one more issue, so hotfix was needed and was made.

Thanks, Foxhound! :)

After a third bughunting season and long BB test without any RPT error on new demo mission I decided, that HAC 1.2 is ready to be no-more-beta. So 1.2 released. Apart from fixes and code improvements added: - improved morale calculation (good balanced, I hope, with quite complex formula, that takes in sofisticated manner into account overall losses, last losses, reinforcements, time factor and actual force balance, but I'll still watch this in my gameplays (if any, heh), so further adjustments possible). Previous formula was imperfect, as in long-term morale always increased to maximal value; - new "debugII" markers with "!" and "!!!" markings for indicating of panicked and suurrendered groups; - improved risk calculation of attack orders for armor and air, when AT (AA) weaponry is known - now distance factor along the entire planned route is taken into account, so man with RPG five kilometers away will no longer affect sending tanks anywhere, if far from him; - changed demo for BigBoss, also added new one for BB, but nearly as simple, as possible, for addon version, to facilitate the understanding of the fundamentals of BB concept before studying of its advanced features. Note, that in demos for BB are used some "haste" init configs. I think, that these may be conisdered as recommended for BB, as with full process, including recon, conquest of whole map may last more than a day... Any ideas, bug reports, questions and impressions, as always, appreciated. :) My TO DO list contains still further BB developing, guerilla mode and full arty handling integration. Last mentioned should be the first done, but not sure, how long this will take, as "Lack of Time" phenomenon may occur in the nearest future. Also other projects are awaiting my attention... EDIT: re-uploaded file, as forgot to add to manual two new config variables: (the only change is in manual content)

RHQs makes, that given class is removed from given category, that's all. This means, that groups, that consist unit of this class will be no longer considered as group of this category, unless some else unit of other class in this group belongs to same category. If you remove crewman from crew category: 1. It sitll wil be in eg. Inf category. Even, if you also remove it from any other categories: 2. Class of its vehicle still is present in some categories. Even, if you remove also this class from all categories: 3. Some tasks HAC will assign even for units, which classes was removed totally, as idle orders, capturing, sometimes recon. For this tasks he must only know, if unit's side is proper. So, what to do? Generaly fo yours purpose is used RydHQ_ExcludedG init config array. But these contain groups, not classes. So you need a script launched before HAC, that will add each group, that contains unit of chosen class, to excluded array. If such groups will be spawned later, this must be constant, separate loop. Not tested example: while {true} do { { if ((side _x) == west) then { if not (_x in RydHQ_ExcludedG) then { _gp = _x; { if (_x isKindOf "US_Soldier_Pilot_EP1") exitWith {RydHQ_ExcludedG set [(count RydHQ_ExcludedG),_gp]} } foreach (units _x) } } } foreach AllGroups; sleep 10 }; Run this as separate sqf eg from the beginning of init.sqf. Like [] execVM "ExLoop.sqf";. This will check every 10 seconds, if there is any new western group, that contains pilot class unit and isn't yet added to excluded array, if found, then will be added to this array. EDIT: Of course, if you know exactly, which group should be excluded, just... exclude it with this variable, without any scripting.

Yeah, I definitely want to update, but can't. Not with my connection and monthly transfer limit. So I played this several times (really, I44 is one of the best mods), HAC works fine, although is quite tight fo A here :). Failed to see this "ignoring" issue so far, as I'm for sure NOT ignored and killed quite quickly. :). Anyway, at 7:13 Morale of A drops to -15 due to massive losses, A is in defend mode due to low morale and enemy numbers advantage, and tends to stay with such morale value because of respawns, that raises it a bit. Groups dies so quickly, that nearly none of them even tries to follow HAC's orders, too busy with dying. At 7:13 I had first cases of panic. It is probable that some groups can be ignored, as surrendered, still didn't saw this. I think, that problem with this mission isn't a bug, but simply fact, that allies are here stopped, pinned down under fire and exterminated continously. Even if the get some waypoints, they not follow, as usually in Arma, when under fire. All this is obviously bad for morale... :) After 7:16 I see, that morale of A tends to raise very slowly (spawns make more good, that casaulties bad), and B morale starts to drop due to some casaulties. A sometimes is back to attack stance. So I think, that evetually allies will win, if will be respawned continuolsy. 7:22 - noted strange thing. I have HC module on map, so I can see markers for each group. Noticed, that after Nth respawn one of the groups got yellow marker, what means civilian side. This may be another reason of being ignored. Progress near to zero, all still die on sand. Morale of A stays on -10, B - about -1. Bodies everywhere. And that's all for know, haven't more time currently to watch more of this slaughter. :) I also learned again, what is main Arma 2 problem. The main Arma 2 problem is, that there is around far too many too great mods and addons for this too great game. Life is far too short for all of them. :)

Frankly - I do not know. If unit surrender, then become a captive. Only then HAC gives a reason to not shoot at given unit (still they will probably shoot anyway :( ). But then captive will also drop its weapons (so you can easily see, who is surrendering). Sometimes also groups may panic and flee. If fleeing, probably also will not shoot. I heard (and saw), that when units are very numerous, enough to overload CPU, AI becomes "retarded" somehow, but id they fire without HAC then this rather isn't this. You know what? I have previous I44 version, so if classes are same, you can give this mission, so I can see, what is hapening, but probably there are another classes in newest I44? Alas! My weak, limited net connection! ---------- Post added at 12:45 ---------- Previous post was at 12:41 ---------- Hey this was thousandth entry in this thread. Should we to celebrate this event somehow? :)

In "triggerCreation.sqf" used is in setTriggerStatements this without quotes. Isn't this wrong syntax? This will be the last, I think, rest are gcam erros (variables not in scope and such). OK. Thanks for sharing, I'll explore this furher later, when time will allow me. Most fascinating experiment. :)

Confirmed on empty LAN. Works. Hm. This will be too heavy for my weak CPU, I afraid. Anyway, here is some useful RPT syntax/logic error messages (played about two minutes):

Necessarily have to try it out. Explores the very interesting issues here. Genetics algorithms? Yeah! Personally thought, how to make in arma some kind of viruses contra antibodies "war", or some evolution (natural selection plus mutations) sim, but till now had no time to concentrate on such ideas...

This is possible. Of course, not easy task to convince HAC, that eg. attack with one group against ten is good idea, but, with some little scripting... Two global variables are crucial here: RydHQ_Morale and RydHQ_Inertia. First can have value in range -50 to 0, second - unlimited. The higher these values are, the more sure is, that attack will be chosen. So need to launch along with HAC a simple loop to keep one or both of them with high values, as these are recalculated every HAC's cycle. Eg: while {(true)} do { sleep 10; RydHQ_Inertia = 10000; RydHQ_Morale = 0 }; This can be part of new morale simulation. If morale is low, fleeing in panic and even surrendering may occur here and there. Perhaps is not optimal calibrated yet. Depends on exact tactical situation in this mission. If you do not want to see such behavior, use RydHQ_Flee = false in yours init config to turn this off totally, or manipulate RydHQ_Muu config variable (cowardice factor multiplier) to set chances for that smoothly. Default is 1. 0.5 means 50% lower chances for fleeing/panic and so on, but in certain limits, cowardice factor is always from 0 to 1 range. This also can be result of added in 1.2 withdrawing given group in face of overwhelming enemy (see RydHQ_DebugII option - additional markings - dots with numbers at each group position indicates value of this factor). In such situations is possible, that group will get "go rest" order, so will wthdraw to certain position, but then will be fully available again. EDIT: Hmm. Actually, if you want, I can think about special config variable, that will keep HAC in attack mode regardless of circumstancies and maybe to make withdrawing optional... EDIT2: OK. Added both. In the next release will be possible to set special "berserk"/"ура, вперед!" mode to keep Leader in offesive stance always. Threat level needed for withdrawal given group will be multiplied by cusomizable variable (default 1), if set to 0 - this feature will be inactive (no such withdrawal). No, this part wasn't touched by me quite long time, since one of first 1.1wips, when added RHQs for subtraction default classes. Is same, as in first beta, so copy&paste is fine. ---------- Post added at 09:13 ---------- Previous post was at 09:06 ---------- I'll appreciate, if such mission do not needs heavy addons, if you give me it, so I can see, what is wrong - yours mistake (so I can help and explain), or a bug (so I can hunt it down).

Thanks Mikey74. :) However - 1.2 beta2 released. Found several bugs in first beta, so here is next one, fixed, plus some additional code improvements. Note, that corrected is also name of init config variable for chance for omission recon stage: was RydHQ_NoRecon (wrongly) is: RydHQ_NoRec. Note also additional debug for BB ("offensive path" for each leader shown as blacks quares linked by pink lines, and blue square, that indicates current target. This, I hope, will allow to understand better BB's work flow). Also - one change in BB config - now for BB RydHQ_LRelocating should be left inactive, as is by default. HAC's Leader relocator not worked with BB, so replaced it with BB's own solution for that. Link to first beta stays for now, in case, if I removing these errors introduced new, worse. :) BB still needs more testing, so still is beta.

:D Yeah, finally... And yes, I like it a lot. :) ---------- Post added at 11:36 ---------- Previous post was at 10:19 ---------- @InstaGoat After first test - indeed, all stuck in defensive mode, that's wrong of course. First, I had to remove from .sqm ACR content, so there was lack of some units, but this shouldn't affect. Second, I found, thanks to RPT file, Squint and own eye four syntax errors in RHQ config: 1. First array, class: PCDF_CDF_Soldier_Sniper_Night had wrong quote mark (some stylish, diagonal, as pasted from Word or something); 2. Lines 107 and 115 - lack of semicolon at end of the line; 3. HArmor RHQ: comma at end of array. Still, after corrections, problem with defensive stance occurs. So now I'll make furter test. :) ---------- Post added at 12:56 ---------- Previous post was at 11:36 ---------- After second test - noted, that "B" forces have far to low value (300 units, but only 12 value points, where each troop should to add 1 point at least). So checked RHQ with some tool, that I made for this purpose earlier, here is its report: Crucial are first and third part, second not. So I added these, not sure if all is in good category, I hope so, now RHQ looks like this: Wow. That is huge. Almost 1000 classes! Found also and removed one more syntax problem. Anyway - problem with defensive stance persist still, so time for next tests. :) ---------- Post added at 14:19 ---------- Previous post was at 12:56 ---------- Shortly: I found problem in this mission, that causes this defense issue. This is strange however. Code was fine. Problem was objective triggers. These look fine, but for some reason was invisible for script. When I deleted them and placed again, all is working now. Ah, also edited mission.sqm and replaced two ACR vehicles with some else. Maybe this was about it? But then shouldn't happen to you... Anyway, now will check this front issue. BTW Changed by me mission is here: http://www22.zippyshare.com/v/47434969/file.html ---------- Post added at 14:52 ---------- Previous post was at 14:19 ---------- No "luck" - failed to reproduce this issue. Fronts are formed properly also for maximal scattered E forces. I'm not sure, what behavior of this way spread out forces you expect, but this probably will look this way, that most of them will move slowly towards it's Leader or current objective/attacked enemy inside Front E, which is usually quite small, near center of map... If these should be kind of guerilla across the country, then maybe better will be to exclude them from HAC and make them handled by another, more suitable for partizan behavior script? Guerilla style Leader's mode is planned, but not exist yet. Leaders currently act like regular commander, that has own objectives to take in typical manner of regular army (well. At least, kind of :)). ---------- Post added at 15:55 ---------- Previous post was at 14:52 ---------- Thanks to Foxhoud link is restored and works. :)

You mean link from armaholic's HAC page? Indeed, just checked. Leads to somewhere, but there is info, that file was deleted or something. I think, that this link should be just removed. I'll take care of it. Not a problem, same demo, as "simple demo" is available directly in HAC' package, in demo missions folder. Thanks for reporting that. This is good idea, but there is a problem - I have far too weak, limited connection for uploading anything bigger than a few MB. :( Plus, I never made any film for youtube and simply not sure, how to do that. Maybe someone else will be helpful with this? For the good start just check mentioned simple demo. It contains all, what is necessary, and nearly nothing more (except optional debug). It is for addon version of HAC. If there will be any furhter questions - do not hesitate to bother me. :) How to express it? Hmm. If the question contains words like "dedicated server", "cores" and such MP or hardware related stuff, my answer is: "Huh?". Yeah, that's my creative and analytical mind. :) Yes, HAC could be heavy for CPU, but it is sqf. So there will be no any lags (fps drops) because of HAC, unless some net lags? As for sqfs game's engine makes available only certain part of CPU power. So no lags, but instead overloads means delays in code execution, sometimes big. For HAC isn't a big problem, as his work doesn't needs "rapid reflexes", just some orders will be issued later. You can easly name it a simulation of comm delays and such. :) Still, some other sqf-based scripts may have problem with this delays. Problem is, that I do know nothing about MP environmernt specificity. I'm pure SP-guy. HAC wasn't made for MP at all. Some guys however used it in their MP project, you can ask them, how the did that: MSO ---------- Post added at 09:49 ---------- Previous post was at 09:33 ---------- It's not necessarily your fault. You see, this is first release of BB, and this is still beta. BB passed tests, but I never had a time to run it more than 2, 3 houres at once. In fact I expect some bugs and problems at this stage. Too complex code to avoiding that sad inconvenience. I'll check, what is going on in yours mission. I partially predicted possible problems with too passive stance in long-term run, so added a few config variables to "dynamize" Leader's offensive: RydHQ_Rush = false – variable shared by all Leaders. If true, groups will never move slowly, but always with normal speed and aware behavior instead of safe. One of “dynamising†variables; 24 RydHQ_NoRec = 1 – Percentage chance for omission recon stage – another “dynamising†variable. NOTE: is multiplied by (RydHQ_Recklessness + 0.01); Above should be rather used with this: RydHQ_RapidCapt = 10 – Percentage chance for capturing objectives “for all costâ€, means immediate and regardless of enemy presence capturing missions. Can be rised, when taking land should be of higher priority than defeating known enemy. Another “dynamizationâ€. NOTE: is multiplied by (RydHQ_Recklessness + 0.01); Rush - true, both other eg 10000, and things should "roll" quicker. Still, getting stuck in defensive mode is a problem here. Hmm. Not tested BB with units spreaded out on whole map, but still code should handle this situation - if didn't, I'll consider this as a bug. Thanks for reporting. I'll check this. EDIT: Sorry, man, I waited some minutes for download this mission, but then just get message: "The file you have requested does not exists." :( Worked on second try. :)

Sorry guys, if anything is too confusing. I'm trying to make examples clear, but isn't easy, as HAC just becomes more and more complex. I sometimes even do not understand why he does what he does. :) Good thing is, that most of all these HAC's complications are pure optional. Bad thing is, that because of numerous optional complications, even init config became quite complex itself (still nothing new became necessary, simple demo is same, as in the beginning). I'm here to answer, if I can, to any doubt and question. That is true, BB demo contains almost all possible BB's funcionalities to show, how to use all of them. I realize, that all this may be a bit difficult to grasp at once. Of course all, what was placed on map, can be re-placed, wherever you want. Statics and support, if should be controlled by Leader in limited "synchro" control mode, should be treated as any other unit, and synchronized with their Leader. With SAL (Strategic Areas Logic) logics however should be synced only custom strategic objectives "flags" (another logics), if used, nothing else. If played with FAW, arty will work even, when out of HAC's control (not synced in "synchro" limited control mode, in default mode, as always, all units of given side goes under Leader's control, nothing was changed here). Of course without this control there will be no smoke and illum from HAC's arty handler. FAW (or similar script) is still needed, if you want some bigger "boom". Internal arty handlig is for now only for smoke and illum (both, FAW and this, should work togheter fine, I hope), as these needs strict coordination with maneuvers, that cannot be provided by external arty handler. However I have on my "to do" list FAW's code modernization and full incorporation into HAC. No. Reasons I explained earier, when Lucidity asked same question. Generally the bigger default class arrays, the heavier code is. So best, if implemented are only classnames for currently used units, therefore optimal solution is, I think, RHQ config, that allows flexible adaptation of these arrays. This version needs OA beacause of used some script commands, introduced with OA patches. PS. Believe, or not, but just today I first time truly made for myself mission actually to play with HAC, not to test. :) This is variant of metalcraze's idea. BLUFOR attacks OPFOR's defensive positions on wide front. All eight Leaders on map, but without BB. Debug off, except FAW's. Of course you can play anybody, only need to change player's unit. Action isn't to intensive, but there is present this nice feel of being involved in something bigger. Also FAW is used there, and some modified version of TPW's "Simple Breath Fog" script for flavour. Contains all, what is needed. So, if someone interested - enjoy. Of course, if you by a chance get stuck with some boring idle order, you can just ignore it and go to get some action. :)

Number of subordinated to BB Leaders can be any from range 1 to 8. Depending on number of subordinated Leaders, BB has lesser or bigger "room for maneuver", is more flexible, when has at his disposal several "divisions". He distinguish center, left and right flank, and reserve. First, he will try to assign Leader to front (center), if there is only one Leader, that's it. If there is more Leaders available for given BB, he also may "fill" flank(s) (not necessarily symmetrically), and, if 4 Leaders at least - also will use one of them as reserve, which gives him additional strategy possibilities. If there is more, that four Leaders - some parts of front will be filled with two Leaders (for eight Leaders,to center, both flanks and reserve will be assigned two Leaders). If you want to change assigned to BB Leaders, use one of such arrays: RydBBa_HQs = [leaderHQ,leaderHQB,leaderHQC,leaderHQD]; For only one subordinated Leader this will look this way: RydBBa_HQs = [leaderHQ]; Same for BB "B". (RydBBb). True. BB will decide on his own. Custom objectives (both methods, via synced logics or via init array) are for those, who wants to force BB to take into account apart from own-choosed objecitves (not randomly, but via specific locations search) also chosen by mission maker spots as strategic targets. There is also another optional config value that will make, that BB will become "blind" by itself, and will take into account only custom added objectives. It is all up to mission maker's config... To be precise: BB, if not "blinded" via config, will always mark as "targets to take" certain points over whole map. And will, "portionwise" assign logically chosen groups of these targets (usually not so far from Leader's position, unless some far objective has very high "temptation" value) to his Leaders as long, as will take whole map or loose combat effectiveness. When given Leader will take all the objectives assigned to him, receives another portion, and so on. Portions are defined as follows: For each Leader BB will look for objective, that will have maximal value calculated via formula, where is used target's value and distance between it and Leader. The greater distance, the lesser chance for choosing this target as main target of given "portion". The bigger value of target - the bigger chances. When main target of given "portion" is known, to this portion are added also all targets, that lays "on the way" towards main target (if any). Objectives from given portion are taken in distance order. Assignment to given part of front (center, flanks) decides, from which side BB will search for "portion" for given Leader. Reserve generally will follow center divisions, and, if needed, will reinforce threatened parts of whole front, and from reserve divisions in the first place can be chosen infantry groups for garrisoning taken objectives (proportional to numbers of division's infantry and objective value, if division has a little infantry, most likely garrisions will be not assigned, unless another, closest to given objective Leader has many infantry to spent). Assignment of given part of front line depends on division's numbers and composition. More numerous divisions will more often be assigned to "bigger" flanks - where is more square sectors (500x500 meters), to which BB divides whole map, and by topographical criterion - if army consist more than average vehicles number, is more probably, that will be assigned to that part of front, where vehicles will better perform (more flat, not covered areas, best with many roads). Divisions with dominant infantry - on the contrary (except roads). If divisions are similar in numbers and composition - their assignment will be quite random.

Yes, it is possible. Question of adequate init config and objectives placement.

I only heard about WICT. Never use it, so do not know, if is possible, and to what extend, to combine it with HAC with good result. Better to ask MSO team indeed. As far, as I know currently MSO uses first, old HAC version. "Rudiments" are same, but really many and deep changes was made since then, lots of new features and enhancements added. When reading current manual, need to realize that a lot of functionalities described there does not exist in 1.0 version. Also - MSO HAC code is modified to work in MP environment. However new HAC, thanks to Big Boss, may find his place in some future MSO versions as general AI opponent, Big Boss was designed in consultation with MSO team also for that purpose, but there is nothing sure yet.

Thanks! :)