Rydygier

How is indicated target marker for this group? If "Rec", it is a reconnaissance mission, and to these missions cargo is not allocated, because vehicle too easily can be detected. Although I did a little test and think something is wrong here. Group sent to attack (marker "Inf A"), boarded the empty truck, but did not want to move. Hmm. (This was caused by changes that I made in the code today, after removal of this changes group boarded the empty truck and moved to the target) ---------- Post added at 18:32 ---------- Previous post was at 18:25 ---------- When this trigger is activated? Maybe try to move this code to init field of any unit or to init.sqf.

Yes, empty and crewed cargo units should be used, except, that there is no defined in HAC init config RydHQ_CargoFind variable or is defined with value 0 or less. Positive value of this variable means radius in meters for empty cargo searching around group leader. I recommend not to big values, eg. RydHQ_CargoFind = 100 should be enough, maybe up to 200, depends of needs, mission and CPU. Too big values will cause lags. If you want cargo system active, but without searching for empty vehicles, just define this variable with minimal value, eg. 0.5 or 1. Or maybe target point for this group was set too close (if distance is less than 1000 meters, there will be no cargo assigned).

I think, that "BigBoss" AI level should be perfect for such movements (changes of leaders and objectives positions). Of course this is also possible by external script. In current version LeaderHQ will enter "defend" mode on its position if: 1. It is manually set by RydHQ_Order = "DEFEND"; 2. There is also chance for autmatically setting "defend" mode calculated by formula: ((_gauss100 + RydHQ_Inertia + RydHQ_Morale) <= ((RydHQ_EValue/(RydHQ_FValue + 0.1)) * 60)) Where: _gauss100 - random value between 0 and 100 with Gaussian distribution (average values most probable) RydHQ_Inertia - factor of tendency to remain in the same mode as to avoid too frequent changes and simulating some psychological aspects. If chosen "attack" mode this factor becomes: RydHQ_Inertia = 30 * (0.5 + RydHQ_Consistency)*(0.5 + RydHQ_Activity); otherwise: RydHQ_Inertia = - (30 * (0.5 + RydHQ_Consistency))/(0.5 + RydHQ_Activity); RydHQ_Morale - factor changed and displayed every cycle, reflects commanders morale (faster cycles means more rapid morale changes, so slower commanders are also more patient and more resistant to decreasing of morale), rather not army morale, like is said in manual. Values between -50 to 0. RydHQ_EValue - estimated value of the known enemy forces, where units with higher firepower have greater value; RydHQ_FValue - ditto, for friendly units. Total reset of all global variables (ergo complete HAC reset) is also possible and I will try to add such option with special variable. This is, how it looks currently.

Terrain factor is extremely hard to implement. Complex topography scanner is itself a theme for big, standalone addon. And it will be heavy for CPU. About those "take objective" orders (with "Cap A/Cap B" markers)... It will happen when: 1. there was reconaissance completed or is advanced enough and there is only few or none enemy units founded; 2. When some, but not to numerous, enemy units are known at the beginning; And never in first cycle. it also depends on RydHQ_Recklessness personality attribute If equal 0 each known enemy unit reduce chance for such order per 10%, If equal 1, each known enemy unit reduce this chance per 2 %. For GENIUS this will be 3.(3) %, so if there are at least 30 enemy units known, chance for capturing order for genius is 0%. Will think, how to make some connection also with number of own forces. EDIT: I think, will also connect this chance with number of cycle. So with time chances will grow and will be minimal at beggining. EDIT2: Done. Now formula is far more complex and gives no chances for such order in first 5 cycles, with next cycles chances will slowly grow, it is also dependent on number of own groups compared with expected number of enemy groups, now I should test it.

Should be possible. Something like: RydHQ_Excluded = [supp1, Supp2, Supp3]; nul = [] execVM "RydHQInit.sqf"; sleep 500; RydHQ_Excluded = []; But setting at the beginninig support vehicles far from others, and generally all vehicles not to close to other group, especially far (above 100 meters I think) from infantry and especially choppers far from each other, should also help a bit or even a lot.

@Taro8 Something else is impossible in this idea, not convoy formig itself. Hard to explain, beacuse of my poor English, but let's try. In fact, with yours idea of making behind front field support base, convoys seems to be in conflict with this; but there are other issues with convoys (eg this idea includes also ambushes, and how to combine idea of constant convoys with current support system, also from where and for what should support units moving all the time... there is many of such questions, and only known to me advantage of this idea is opportunity to ambushes, which are rather unreal to proper implement as part of all HAC actions and exactly this is impossible for me)... and + mentioned drivers AI... Nightmare when comes to implementation.

Orcinus, RHQ for Duala units is already done by me. Duala RHQs EDIT: but without RHQ_NCAir (no-combat air), and there are some choppers without weaponry. That is why I'm waitnig with this RHQ config thread for HAC 1.1.

Just tried. Haven't MH-6, so Razor got MH-60S. HAC starts as always (1.0 & newest 1.1 alpha, Razor both as AI-only team and led by me). ---------- Post added at 10:59 ---------- Previous post was at 10:57 ---------- MH-6 as troublemaker? Also odd. If RHQ are valid, should work as unit of given category (air, I suppose) under HAC, if not, should be simply ignored. ---------- Post added at 11:00 ---------- Previous post was at 10:59 ---------- Can you try to exclude MH-6 classname from RHQ and to try then? And with this chopper in RHQ and outside any other group?

@Orcinus There will appear some new categories probably, as RHQ_Bombers or RHQ_MArmor and with support handlig appeared additional to general RydHQ_Support RHQs for support of given kind only. Way to write additional classes of units for HAC will not change, I think. ---------- Post added at 10:39 ---------- Previous post was at 10:33 ---------- Odd indeed. Razor's units classnames are included into recon category and this is everything when it comes to connection between Razor and HAC. I should try this right away. RPT was clear?

Intriguing. Worrisome. Unclear. It would be better if this problem affected only 1.0, there are some serious code mistakes in 1.0, but none of them caused this problem for me. I still have no idea where it comes, so far I could not recreate it too, but I keep it in mind. EDIT: However you give to me some information, possibly significant. Especially that about the distance above which the problem dissipates and the moment of his appearance. Hmm. Hmm thrice.

This may prove useful: http://forums.bistudio.com/showpost.php?p=1400306&postcount=65 from: http://forums.bistudio.com/showthread.php?p=1400306#post1400306 In one of my missions, I needed a playing radio with looped few tracks, a jingle and with static noise in the background, but with distance sound disappearing too slowly, so I tried this third parameter. Effect was good. My Description.ext was looking like that: class CfgSounds { sounds[] = {}; class Bushes { name = "Bushes"; sound[] = {"sound\Bushes3.ogg", 20, 1, 150}; titles[] = {}; }; class Inter { name = "Inter"; sound[] = {"sound\InterC.ogg", 20, 1, 150}; titles[] = {}; }; class Vintner { name = "Vintner"; sound[] = {"sound\Vintner2.ogg", 20, 1, 150}; titles[] = {}; }; class autumn { name = "autumn"; sound[] = {"sound\autumn1.ogg", 20, 1, 150}; titles[] = {}; } }; Don't know, if it is optimal, but, again, effect was realistic and good. Fading occurs earlier.

@Tupolov That is great. Maybe I learn something about the implementation for MP. In this code, if I remember correctly, should be very few references to player, but some new will show up soon, because some people requested special info from HAC to player character. Maybe will be better to wait until I complete 1.1 version? @Snafu Thanks! I remember about special thread for RHQ configs, but I want previously to complete a new version of HAC.

Yes. Or in init.sqf, which may be most convenient. Of course added in act field of trigger will be initialized when triggers conditions will be met. Yes, with next cycle.

Sorry, I'm not sure: you mean 1. which HAC file contains used by HAC classnames, or 2. where you can find given unit classname itself? if 1.: SitRep.sqf/SitRepB.sqf (in alpha2 also "Supp" files (eg SuppFuel.sqf)) But to add some custom units under HAC control there is no need to modify these or any other files directly. Only should be defined (eg in init.sqf or init field of unit in editor, or on triggers act field etc) "RHQ" array variables, so, for example such init code should contain something like this: http://forums.bistudio.com/showpost.php?p=2077292&postcount=49 if 2.: depends. Many of them you may find there: http://forums.bistudio.com/showthread.php?t=73241 or in given unit-adding addons forum thread or readme, or in its config files (unPbo & patience needed) or you may to use editor and in init field of unit, which classname you want to know, to add something like: diag_log (typeOf this); (info to .RPT file) or hint (typeOf this); (info on screen) and preview in editor.

However there are special .sqf files in Arty module for LASER (probably (?) looks for point illuminated by laser beam of proper side and directs HE shell in this place, I'm not sure) and SADARM (with parachute deploying, slow falling and seeking for suitable targets around and deploying burst of attack munitions if target is found). I tried WP ammo when working wit FAW addon and for me (Arma2 1.10) this ammo works fine - nearby infantry gets injuries and dies.

Yes. Of course, if you become a tank crewman, even "Idiot" commander will not send you on reconnaissance mission except if not find any better unit. And vice versa, scout unit will be probably reserved for recon. @friznit2 Great. Thanks for info. If I not stuck somewhere, completion of version 1.1 is a matter of 2 weeks, I think. @postman84 Just like Orcinus said. FAW should work fine with HAC. With FAW&HAC both, artillery and air support are controlled only by AI. There will not be arty shelling or air bombing on players request, unless you give it yourself by separate script. However, if player notice an enemy target (here appear to be very useful binoculars or optical sights), which HAC/FAW commander considers tempting, then HAC will order artillery and/or will send some air units, if he has any free units at the moment.

But why you can't make missions?

If I knew, that this "written on the knee", very provisional units counter proves so useful to you, I would more carefully refined it. :)

Situation with counterU was identical. In fact, RydHQ_Obj does not must be a trigger at all. It can be any object. Its only job is "to have position", and serves as a reference point (markers are not suitable, as far as I know). Triggers are simply handy, because they are invisible in the game, but such RydHQ_Obj may be also an unit, vehicle, building, a rock or whatever object.

@ friznit2 1.0 beta 2 is last official version for now, but released only in this thread for testing purpose 1.1 alpha 1 and alpha 2 versions are without some bugs founded in 1.0 beta2. Of course, because these are alpha versions, may include entirely new bugs, that currently are successively removed. Hmm. Your choice. :) HAC 1.1 alpha 1 HAC 1.1 alpha 2 ---------- Post added at 17:17 ---------- Previous post was at 17:11 ---------- This code should be initialized only once, to run whole HAC, both sides. If I included this into RydHQB_Obj trigger, it is because I needed some trigger with radio channel to easy init HAC by radio and did not want to add another trigger on map, since there were already two triggers,only as totally passive objects, that indicating objectives. Simply by the way I used them also for another purpose. Trigger with this code wasn't launched with presence of B-side forces, but only by radio.

Thanks. Hmm. I simply forgot about "known enemy AA weapons" factor when implemented support handling. Degree of caution in attack depends on several factors, so perhaps it was justified, and perhaps I too restrictive set elimination routine for units, that are unfit to fight, I will check this.

"I do have a theory" (like would say Scotty). This error occurs every time or only sometimes? I know you have to wait long to be sure, but maybe someone will have time and willingness to check it out a few times. If I am right, this problem will appear more quickly, if one side will have a big advantage and if at the beginning some troops on both sides see each other, but only a few, team, or two. (to skip reconnaissance phase). In these circumstances, commander should quickly to send an order to acquire objective, and I suspect that in these procedures is the problem. Will try too.

Well, looks like it's a more serious bug. It is good that is found, bad, that it is. Currently I have no idea what might cause the script to stop after such a long time, but I will look. Thank you.

That's great. :)

Generally this way HAC should works. Hard to tell, what is wrong. Need more info. My demo mission on Utes works fine for you? Are there any errors in rpt file? If so, can you quote them? Can you maybe prepare mission on Utes on Chernarus with only generic units and with occuring of these problems (only Arma 2 1.10 here)? There are RHQ arrays maded, if used non-generic units (eg from OA or from some addon)? Have you used addon, or script version of HAC? 1.0 or maybe 1.1 alpha 1 or alpha 2? It may also prove helpful to see HAC config used by you, or maybe at least some printscreen with prepared troublemaking mission in editor...