HETMAN - Artificial Leader

[euly 0]

Wow. That sounds like awesome feature. Definitelly will try to utilize this in Hetman, thanks. Still - not sure, when exactly I'll back to Hetman itself, depends, maybe tommorow, maybe next year... :) Learned to not force myself to work on anything without genuine willingness and it's not possible to predict, when I'll get again such enthusiasm for pushing forward given project.

When you do get around to working on it again, one of the chat responses is "No possible - Over" when it should be "Not possible - Over"

"No possible" sounds strange, even though I'm sure everyone knows what the group meant. If you ever figure out a way to have the commander talk to those groups, it would be nice to know what he's ordering them to do. The only text I see him say is about artillery missions and "To all groups, perform Oscar Foxtrot! (or something like that)" What does that mean? Is he calling an audible? It doesn't make much sense without context.

[Rydygier 1309]

Thanks.

What does that mean?

Supposed to be kind of obvious code. OF like offensive DF like defensive. Said at stance change.

If you ever figure out a way to have the commander talk to those groups, it would be nice to know what he's ordering them to do.

That's easy part. I know, how to do this. Idea is cool, but problem is voice acting and English sentences. :) Especially, I long time ago forgotten, which audio filters and how set I was using to get that kind of radio distortions etc. And this must be cohesive with the rest. The more - can't even recall, whose voice was used for HQ (one of two, while one guy is hard to reach and second out of reach completely). So, the only choice I see is making whole voice acting from the scatch. Or leave additional HQ sentences voiceless...

[euly 0]

Thanks.

Supposed to be kind of obvious code. OF like offensive DF like defensive. Said at stance change.

That's easy part. I know, how to do this. Idea is cool, but problem is voice acting and English sentences. :) Especially, I long time ago forgotten, which audio filters and how set I was using to get that kind of radio distortions etc. And this must be cohesive with the rest. The more - can't even recall, whose voice was used for HQ (one of two, while one guy is hard to reach and second out of reach completely). So, the only choice I see is making whole voice acting from the scatch. Or leave additional HQ sentences voiceless...

Thank you for the update on the OF and DF.

I didn't mean like vocally talk, just text in the side chat. I really like the side chat/radio chatter. The chat is immersive while the commander and squads are acting and reacting to the situation.

[deleyt 13]

Link to ALTERNATIVE SOUND SETS FOR RADIO CHATTER is broken.

I'm not able to download the soundset.

[Rydygier 1309]

Oh, probably expired. I'll reupload it ASAP. EDIT: all right, works again. This link should not expire.

Edited November 13, 2014 by Rydygier

[deleyt 13]

Thanks for this awesome mod/script! I've been playing it for the last hour or so and I'm quite impressed with the effectiveness.

Rydygier, what lowlevel AI Enhancement (unit-level) would you recommend using with HETMAN?

[Rydygier 1309]

I'm not following closely developing of any, so can't be 100% sure. In general - all, that don't mess with waypoints (Hetman is controlling units mostly via waypoints). Personally used without any visible issues ASR_AI or bCombat.

[euly 0]

I use Vcomm when I want the AI to utilize the HMG/GMG units. It's better than ASR_AI in CQB environments and squad organization, but ASI_AI dynamically alters skill level by rank, so it's good for placing groups without much micromanagement. I don't think ASR_AI pushes as many instructions to the AI, so it's less demanding on the system.

[deleyt 13]

I'll give all threee of 'em a whirl then. Thanks.

[zorrobyte 30]

ZBE_Cache was created for A3 with HETMAN/HAL in mind.

Special features that are useful for use with HAL:

TLs stay uncached for dynamic group movement

AI uncache in AI vs AI engagements (not just for players)

Empty vehicles are cached so it's finally possible to spawn 100/1000s of empty vehicles on a map with minimal performance impact, very useful for HAL's Cargofind feature

Script version for inclusion in missions, distribute your HAL mission optimized with ZBE_Cache with no addons or end user configuration

Uses enablesimulation and hideobject and therefor doesn't impact HAL's morale calculation

ZBE_Cache

[Rydygier 1309]

I knew, you was working on something like that, but since then wasn't really back on HAL project, so haven't yet opportunity to try it. This may change soon. Sounds fantastic. :)

I'll check the code probably, but for now technical question: there is possible situation, when AI should be not cached despite lack of any opposition/player near. It's when group is about to be shelled by artillery. I suppose, this one would be hard to handle without some moves on my end. My idea is to maintain a global array of certain name, holding positions of currently pending arty fire missions, so it could be taken into account in the yours caching. Unless group is uncached, if any hostile knowledge is > 0 for it, in such case this may be not necessaary, as to be shelled group must be known to some enemy with artillery.

And how about handling another cases, like left far behind the front (thus (assigned) driver/pilot/vehicle itself cached unless he is a team leader) vehicle in some moment called as taxi, logistic support or for ammo drop or, if arty, for fire mission?

[zorrobyte 30]

Just before reading your post, I updated my thread with a fix for this reason.

I'll check the code probably, but for now technical question: there is possible situation, when AI should be not cached despite lack of any opposition/player near. It's when group is about to be shelled by artillery. I suppose, this one would be hard to handle without some moves on my end. My idea is to maintain a global array of certain name, holding positions of currently pending arty fire missions, so it could be taken into account in the yours caching. Unless group is uncached, if any hostile knowledge is > 0 for it, in such case this may be not necessaary, as to be shelled group must be known to some enemy with artillery.

It sounds like an in depth fix and would certainly work however I'd like to see if when I put in the damage check if the group can uncache quickly enough for the group to receive arty damage. It's unknown to me and needs testing if arty damage is instant or is over some milliseconds for this to work.

And how about handling another cases, like left far behind the front (thus (assigned) driver/pilot/vehicle itself cached unless he is a team leader) vehicle in some moment called as taxi, logistic support or for ammo drop or, if arty, for fire mission?

if(_x != leader _this && {!(isPlayer _x)} && {!("driver" in assignedVehicleRole _x)}) then {

Pilots/drivers do not get cached meaning they are free to continue dynamic movement. As of now, there is a bug in A3 that AI in vehicles do not cache or can have commands run on them but even when fixed should still work. For clarity, the TL of each group is always uncached and mobile on the battlefield as it is now.

As for the empty vehicle caching script, this was created for Hetman in mind. Only empty vehicles far from AI/Player range are cached (much outside cargo finding distance). Vehicles are also immediately uncached if any unit enters any position of them by any means, script or otherwise. This way, one can spawn 100/1000s of empty vehicles around the map for AI to "find" and use. I have a crude script for testing this but eventually want to create a release ready module. Same goes for dynamically spawning static weapons, fortifications based on building class name so AI can dynamically garrison areas and have some static weapons to use. But for now, I'm concentrating on the caching module ;)

[euly 0]

Hey Zorrobyte, I follow some of the work you do, so I'm very glad to see you here participating with Hetman. HAL could definitely benefit from caching units, but it seems all focused on the player. Could the caching be based on the AI leader instead?

[zorrobyte 30]

Uncaching for AI to AI interactions is exactly what ZBE_Cache does. AI groups uncache for other enemy AI groups, not all other AI groups.

if ((((side _x) getFriend (side _ZBE_leader)) <= 0.6)) then {

[Rydygier 1309]

The AI is pretty good about loading things. I gave one of the new choppers a "Lift Cargo" waypoint that I place directly on top of a truck and placed a "Drop Cargo" waypoint a few kilometers away. When I previewed it, the chopper automatically grabbed the truck and dropped it off. Very simple. I tried an ammo box and it worked the same.

So tried:

1. Hummingbird lifting basic weapons box - not working (chopper does maneuvers, but no ropes, no attaching);

2. Ghost Hawk with same box - not working;

3. Ghost Hawk with basic ammo box - not working;

4. Huron with basic weapons box - not working (+ weird maneuvers);

5. Huron with empty Hunter - working;

6. Ghost Hawk with empty Hunter - not working (expected).

Additionally tried also to put waypoint not at the box, but near. Game freezed and I had to ctrl+alt+del.

Anyone has demo mission presenting, how it works with ammo boxes?

There are also scripting command, that may be tried to make this procedure manually, via scripts (assuming, are working), but in general it seems not fully ready/working/implemented yet, anyway not stable enough to implement this into Hetman.

Well, canSlingLoad command return true for Huron and "cargo net" box. But obviously not for Ghost Hawk, the more Hummingbird - too big. And not for other ammo boxes. Thing is, for Hetman chopper of any size has to be able to deliver all kinds of simple ammo boxes, which slingload can't handle. Seems, we're staying on spawned chutes at least for now. Anyway, chutes seems better choice for ammo drops in hot combat zones of unknown terrain (faster - less maneuvring, so shorter exposure on enemy fire, and no need to have area, where chopper can lower enough to release the ropes).

Edited December 3, 2014 by Rydygier

[Teddybear1 11]

Why can`t you just use the ropes with attached parachutes onto the cargo, attaching the cargo to the nett with a proxy to the rope? "Attach_to" command.

[Rydygier 1309]

So far didn't tested yet scripted approach, only plain waypoints. When I try, I could tell, if possible. I like the idea, but thing is, current way is simple and working, and IMO fits better the situation. Switching to the ropes may happen, if good result is possible without too much hassle. Those waypoints was promising, sadly, they can't provide, what I need.

[Rydygier 1309]

So far created small script that does as follows:

1. A chopper gets "lift" waypoint, that is the only reasonable way, I know, to mimic pre-lifting maneuvers over the box;

2. When the chopper is on the lowest position above the box, rope is created, box is attached. Tried smooth rope unwinding, but seems, end of the rope is sticky (maybe because of waypoint...), and box will be attached to it right away, without any delay needed for unwinding, so it looks wrong. Thus rope is created at once on the full length;

3. Box is attached to the rope;

4. Chopper moves at drop position;

5. Box is detached, rope destroyed;

6. Here problems start. If at this point I would try to attach parachute to the free-falling box, falling stops, box does some small, weird jumps, parachute acts, like ground is touched (gets flat and disappears), and only then box continues the fall, but looking weird (too fast, and no physX reaction on ground collision, kinda Arma 2 way). Looks like some game bug. So I can let the box just fall, no parachute, or abandon whole slingloading thingy, until workaround is found or bug fixed...

BTW tried above with two other choppers, according to scripts able to lift chosen box in Huron way, (Taru and Orca) but for those "lift" waypoint seems broken - they start to make weird maneuvers around the box instead of expected behaviour.

So for choppers-other-than-Huron-theoretically-able-to-lift-the-box I may be forced to use current ammo drop way. Oh, and above fails for ammo boxes other than "cargo net" - chopper won't lower before lift... :/

As you can see, feature is still pretty bugged, and its implementation seems premature at current state, but I think, I'll do it in the best possible way and make it optional...

Edited December 5, 2014 by Rydygier

[Rydygier 1309]

All right, seems it's implemented and somewhat working. Now there will be two ammo drop modes, not sure yet, which set as default, old one (fixed some issue with too early vanishing parachute due to a bit different falling behavior), and new, roughly described above: if chopper can slingload given box, lift/drop waypoonts way is used, otherwise is used my scripted solution for slingload. In the latter case chopper in most cases will drop the box before it touch the ground (few/several meters of free falling, no parachute in this case - flight is too low in this method and parachute here, unlike old method, have to be spawned beneath the chopper, which ends with collisions and damage). Looks fine to me.

So, seems maybe next week I'll be able to push out new Hetman (HWS' changes and fixes added, new classes added, RHQ autofiller, still experimental, added, slingload added, HQ orders messages are the last feature to add for this version). We'll see.

Edited December 6, 2014 by Rydygier

[dht78 10]

So, here are coming the RHQ autofiller, HQ orders messages! Will be a party playing with those features.:cool:

[bumgie 49]

I did these before I knew RHQ autofiller was coming but I think it is good to post them anyway.

Note: these are not yet tested, there may be typos or missclassed units in there!

IF you improve upon these, please post back here!

EDIT!: I combined the both sides since there was a very large chance people would overwrite one or the other.

RHS RHQ arrays

RHQ_snipers =
[
"rhs_vdv_marksman",
"rhs_msv_marksman",
"rhsusf_army_ucp_marksman",
"rhsusf_army_ocp_marksman"
];

RHQ_ATinf =
[
"rhs_vdv_LAT",
"rhs_vdv_RShG2",
"rhs_vdv_at",
"rhs_msv_at",
"rhs_msv_LAT",
"rhs_msv_RShG2",
"rhsusf_army_ocp_javelin",
"rhsusf_army_ucp_javelin",
"rhsusf_army_ucp_riflemanat",
"rhsusf_army_ocp_riflemanat"
];

RHQ_AAinf =
[
"rhs_msv_aa",
"rhs_vdv_aa",
"rhsusf_army_ocp_aa",
"rhsusf_army_ucp_aa"
];

RHQ_Inf =
[
"rhs_vdv_crew",
"rhs_vdv_armoredcrew",
"rhs_vdv_combatcrew",
"rhs_vdv_crew_commander",
"rhs_vdv_driver",
"rhs_vdv_driver_armored",
"rhs_msv_crew",
"rhs_msv_armoredcrew",
"rhs_msv_combatcrew",
"rhs_msv_crew_commander",
"rhs_msv_driver",
"rhs_msv_driver_armored",
"rhs_pilot",
"rhs_pilot_combat_heli",
"rhs_pilot_transport_heli",
"rhs_vdv_LAT",
"rhs_vdv_RShG2",
"rhs_vdv_at",
"rhs_msv_at",
"rhs_msv_LAT",
"rhs_msv_RShG2",
"rhs_vdv_marksman",
"rhs_msv_marksman",
"rhs_msv_aa",
"rhs_vdv_aa",
"rhs_msv_efreitor",
"rhs_msv_grenadier",
"rhs_msv_strelok_rpg_assist",
"rhs_msv_junior_sergeant",
"rhs_msv_machinegunner",
"rhs_msv_machinegunner_assistant",
"rhs_msv_medic",
"rhs_msv_officer",
"rhs_msv_officer_armored",
"rhs_msv_rifleman",
"rhs_msv_sergeant",
"rhs_vdv_efreitor",
"rhs_vdv_grenadier",
"rhs_vdv_strelok_rpg_assist",
"rhs_vdv_junior_sergeant",
"rhs_vdv_machinegunner",
"rhs_vdv_machinegunner_assistant",
"rhs_vdv_officer",
"rhs_vdv_medic",
"rhs_vdv_officer_armored",
"rhs_vdv_rifleman",
"rhs_vdv_sergeant",
"rhs_vdv_engineer",
"rhs_msv_engineer",
"rhsusf_army_ocp_rifleman",
"rhsusf_army_ocp_aa",
"rhsusf_army_ucp_aa",
"rhsusf_army_ocp_javelin",
"rhsusf_army_ucp_javelin",
"rhsusf_army_ucp_riflemanat",
"rhsusf_army_ocp_riflemanat",
"rhsusf_army_ocp_crewman",
"rhsusf_army_ocp_combatcrewman",
"rhsusf_army_ocp_driver",
"rhsusf_army_ocp_helicrew",
"rhsusf_army_ocp_helipilot",
"rhsusf_army_ucp_crewman",
"rhsusf_army_ucp_combatcrewman",
"rhsusf_army_ucp_driver",
"rhsusf_army_ucp_helicrew",
"rhsusf_army_ucp_helipilot",
"rhsusf_army_ocp_autorifleman",
"rhsusf_army_ocp_engineer",
"rhsusf_army_ocp_machinegunner",
"rhsusf_army_ocp_grenadier",
"rhsusf_army_ocp_machinegunnera",
"rhsusf_army_ocp_medic",
"rhsusf_army_ocp_riflemanl",
"rhsusf_army_ocp_squadleader",
"rhsusf_army_ocp_teamleader",
"rhsusf_army_ucp_autorifleman",
"rhsusf_army_ucp_engineer",
"rhsusf_army_ucp_grenadier",
"rhsusf_army_ucp_machinegunner",
"rhsusf_army_ucp_machinegunnera",
"rhsusf_army_ucp_medic",
"rhsusf_army_ucp_rifleman",
"rhsusf_army_ucp_riflemanl",
"rhsusf_army_ucp_squadleader",
"rhsusf_army_ucp_teamleader",
"rhsusf_army_ucp_marksman",
"rhsusf_army_ocp_marksman"
];

RHQ_Crew =
[
"rhs_vdv_crew",
"rhs_vdv_armoredcrew",
"rhs_vdv_combatcrew",
"rhs_vdv_crew_commander",
"rhs_vdv_driver",
"rhs_vdv_driver_armored",
"rhs_msv_crew",
"rhs_msv_armoredcrew",
"rhs_msv_combatcrew",
"rhs_msv_crew_commander",
"rhs_msv_driver",
"rhs_msv_driver_armored",
"rhs_pilot",
"rhs_pilot_combat_heli",
"rhs_pilot_transport_heli",
"rhsusf_army_ocp_crewman",
"rhsusf_army_ocp_combatcrewman",
"rhsusf_army_ocp_driver",
"rhsusf_army_ocp_helicrew",
"rhsusf_army_ocp_helipilot",
"rhsusf_army_ucp_crewman",
"rhsusf_army_ucp_combatcrewman",
"rhsusf_army_ucp_driver",
"rhsusf_army_ucp_helicrew",
"rhsusf_army_ucp_helipilot"
];

RHQ_Art =
[
"RHS_BM21_VV_01",
"RHS_BM21_VDV_01",
"RHS_BM21_VMF_01",
"RHS_BM21_MSV_01",
"rhs_2s3_tv",
"rhsusf_m109d_usarmy",
"rhsusf_m109_usarmy"
];

RHQ_RocketArty =
[
"RHS_BM21_VV_01",
"RHS_BM21_VDV_01",
"RHS_BM21_VMF_01",
"RHS_BM21_MSV_01"
];

RHQ_SPMortars =
[
"rhs_2s3_tv",
"rhsusf_m109d_usarmy",
"rhsusf_m109_usarmy"
];

RHQ_MArmor =
[
"rhs_btr80a_vv",
"rhs_btr80a_vdv",
"rhs_btr80a_vmf",
"rhs_btr80a_msv",
"rhs_brm1k_vdv",
"rhs_brm1k_vmf",
"rhs_brm1k_msv",
"rhs_brm1k_vv",
"rhs_brm1k_tv",
"rhs_bmp1d_tv",
"rhs_bmp1p_tv",
"rhs_bmp1p_msv",
"rhs_bmp1_vv",
"rhs_bmp1d_vv",
"rhs_bmp1k_vv",
"rhs_bmp1p_vv",
"rhs_bmp2_vv",
"rhs_bmp2e_vv",
"rhs_bmp2d_vv",
"rhs_bmp2k_vv",
"rhs_bmd1",
"rhs_bmd1k",
"rhs_bmd1p",
"rhs_bmd1pk",
"rhs_bmd1r",
"rhs_bmd2",
"rhs_bmd2k",
"rhs_bmd2m",
"rhs_bmd4_vdv",
"rhs_bmd4m_vdv",
"rhs_bmd4ma_vdv",
"rhs_bmp1_vdv",
"rhs_bmp1d_vdv",
"rhs_bmp1k_vdv",
"rhs_bmp1p_vdv",
"rhs_bmp2_vdv",
"rhs_bmp2e_vdv",
"rhs_bmp2d_vdv",
"rhs_bmp2k_vdv",
"rhs_bmp1_vmf",
"rhs_bmp1d_vmf",
"rhs_bmp1p_vmf",
"rhs_bmp2_vmf",
"rhs_bmp2e_vmf",
"rhs_bmp2d_vmf",
"rhs_bmp2k_vmf",
"rhs_bmp1_msv",
"rhs_bmp1d_msv",
"rhs_bmp1k_msv",
"rhs_bmp2_msv",
"rhs_bmp2e_msv",
"rhs_bmp2d_msv",
"rhs_bmp2k_msv",
"rhs_bmp1_tv",
"rhs_bmp1k_tv",
"rhs_bmp2_tv",
"rhs_bmp2e_tv",
"rhs_bmp2d_tv",
"rhs_bmp2k_tv",
"rhs_zsu234_aa",
"rhs_sprut_vdv",
"RHS_M6_wd",
"RHS_M2A2_wd",
"RHS_M2A2_BUSKI_WD",
"RHS_M2A3_wd",
"RHS_M2A3_BUSKI_wd",
"RHS_M2A3_BUSKIII_wd",
"RHS_M6",
"RHS_M2A2",
"RHS_M2A2_BUSKI",
"RHS_M2A3",
"RHS_M2A3_BUSKI",
"RHS_M2A3_BUSKIII"
];

RHQ_HArmor =
[
"rhs_t80bk",
"rhs_t80bvk",
"rhs_t80a",
"rhs_t72bc_tv",
"rhs_t72bb_tv",
"rhs_t72ba_tv",
"rhs_t80",
"rhs_t80b",
"rhs_t80bv",
"rhs_t80u",
"rhs_sprut_vdv",
"rhsusf_m1a1aimwd_usarmy",
"rhsusf_m1a1aim_tuski_wd",
"rhsusf_m1a2sep1wd_usarmy",
"rhsusf_m1a2sep1tuskiwd_usarmy",
"rhsusf_m1a1aimd_usarmy",
"rhsusf_m1a1aim_tuski_d",
"rhsusf_m1a2sep1d_usarmy",
"rhsusf_m1a2sep1tuskid_usarmy",
"rhsusf_m1a1hc_d"
];

RHQ_LArmor =
[
"rhs_btr60_vv",
"rhs_btr70_vv",
"rhs_btr80_vv",
"rhs_btr80a_vv",
"rhs_btr60_vdv",
"rhs_btr70_vdv",
"rhs_btr80_vdv",
"rhs_btr80a_vdv",
"rhs_btr60_vmf",
"rhs_btr70_vmf",
"rhs_btr80_vmf",
"rhs_btr80a_vmf",
"rhs_btr60_msv",
"rhs_btr70_msv",
"rhs_btr80_msv",
"rhs_btr80a_msv",
"rhs_brm1k_vdv",
"rhs_brm1k_vmf",
"rhs_brm1k_msv",
"rhs_brm1k_vv",
"rhs_brm1k_tv",
"rhs_prp3_vdv",
"rhs_prp3_vmf",
"rhs_prp3_tv",
"rhs_prp3_vv",
"rhs_prp3_msv",
"rhs_bmp1d_tv",
"rhs_bmp1p_tv",
"rhs_bmp1p_msv",
"rhs_bmp1_vv",
"rhs_bmp1d_vv",
"rhs_bmp1k_vv",
"rhs_bmp1p_vv",
"rhs_bmp2_vv",
"rhs_bmp2e_vv",
"rhs_bmp2d_vv",
"rhs_bmp2k_vv",
"rhs_bmd1",
"rhs_bmd1k",
"rhs_bmd1p",
"rhs_bmd1pk",
"rhs_bmd1r",
"rhs_bmd2",
"rhs_bmd2k",
"rhs_bmd2m",
"rhs_bmd4_vdv",
"rhs_bmd4m_vdv",
"rhs_bmd4ma_vdv",
"rhs_bmp1_vdv",
"rhs_bmp1d_vdv",
"rhs_bmp1k_vdv",
"rhs_bmp1p_vdv",
"rhs_bmp2_vdv",
"rhs_bmp2e_vdv",
"rhs_bmp2d_vdv",
"rhs_bmp2k_vdv",
"rhs_bmp1_vmf",
"rhs_bmp1d_vmf",
"rhs_bmp1p_vmf",
"rhs_bmp2_vmf",
"rhs_bmp2e_vmf",
"rhs_bmp2d_vmf",
"rhs_bmp2k_vmf",
"rhs_bmp1_msv",
"rhs_bmp1d_msv",
"rhs_bmp1k_msv",
"rhs_bmp2_msv",
"rhs_bmp2e_msv",
"rhs_bmp2d_msv",
"rhs_bmp2k_msv",
"rhs_bmp1_tv",
"rhs_bmp1k_tv",
"rhs_bmp2_tv",
"rhs_bmp2e_tv",
"rhs_bmp2d_tv",
"rhs_bmp2k_tv",
"rhs_zsu234_aa",
"RHS_M6_wd",
"rhsusf_m113_usarmy",
"RHS_M2A2_wd",
"RHS_M2A2_BUSKI_WD",
"RHS_M2A3_wd",
"RHS_M2A3_BUSKI_wd",
"RHS_M2A3_BUSKIII_wd",
"RHS_M6",
"rhsusf_m113d_usarmy",
"RHS_M2A2",
"RHS_M2A2_BUSKI",
"RHS_M2A3",
"RHS_M2A3_BUSKI",
"RHS_M2A3_BUSKIII"
];

RHQ_LarmorAT =
[
"rhs_bmp1d_tv",
"rhs_bmp1p_tv",
"rhs_bmp1p_msv",
"rhs_bmp1_vv",
"rhs_bmp1d_vv",
"rhs_bmp1k_vv",
"rhs_bmp1p_vv",
"rhs_bmp2_vv",
"rhs_bmp2e_vv",
"rhs_bmp2d_vv",
"rhs_bmp2k_vv",
"rhs_bmd1",
"rhs_bmd1p",
"rhs_bmd1r",
"rhs_bmd2",
"rhs_bmd2k",
"rhs_bmd2m",
"rhs_bmd4_vdv",
"rhs_bmd4m_vdv",
"rhs_bmd4ma_vdv",
"rhs_bmp1_vdv",
"rhs_bmp1d_vdv",
"rhs_bmp1k_vdv",
"rhs_bmp1p_vdv",
"rhs_bmp2_vdv",
"rhs_bmp2e_vdv",
"rhs_bmp2d_vdv",
"rhs_bmp2k_vdv",
"rhs_bmp1_vmf",
"rhs_bmp1d_vmf",
"rhs_bmp1p_vmf",
"rhs_bmp2_vmf",
"rhs_bmp2e_vmf",
"rhs_bmp2d_vmf",
"rhs_bmp2k_vmf",
"rhs_bmp1_msv",
"rhs_bmp1d_msv",
"rhs_bmp1k_msv",
"rhs_bmp2_msv",
"rhs_bmp2e_msv",
"rhs_bmp2d_msv",
"rhs_bmp2k_msv",
"rhs_bmp1_tv",
"rhs_bmp1k_tv",
"rhs_bmp2_tv",
"rhs_bmp2e_tv",
"rhs_bmp2d_tv",
"rhs_bmp2k_tv",
"RHS_M2A2_wd",
"RHS_M2A2_BUSKI_WD",
"RHS_M2A3_wd",
"RHS_M2A3_BUSKI_wd",
"RHS_M2A3_BUSKIII_wd",
"RHS_M2A2",
"RHS_M2A2_BUSKI",
"RHS_M2A3",
"RHS_M2A3_BUSKI",
"RHS_M2A3_BUSKIII"
];

RHQ_Cars =
[
"rhs_tigr_vv",
"rhs_uaz_vv",
"rhs_uaz_open_vv",
"rhs_tigr_vdv",
"rhs_uaz_vdv",
"rhs_uaz_open_vdv",
"rhs_tigr_vmf",
"rhs_uaz_vmf",
"rhs_uaz_open_vmf",
"rhs_tigr_msv",
"RHS_UAZ_MSV_01",
"rhs_uaz_open_MSV_01",
"rhs_gaz66_vv",
"rhs_gaz66o_vv",
"rhs_gaz66_r142_vv",
"rhs_gaz66_ap2_vv",
"rhs_gaz66_repair_vv",
"RHS_Ural_VV_01",
"RHS_Ural_Open_VV_01",
"RHS_Ural_Fuel_VV_01",
"rhs_gaz66_vdv",
"rhs_gaz66o_vdv",
"rhs_gaz66_r142_vdv",
"rhs_gaz66_ap2_vdv",
"rhs_gaz66_repair_vdv",
"rhs_typhoon_vdv",
"RHS_Ural_VDV_01",
"RHS_Ural_Fuel_VDV_01",
"RHS_Ural_Open_VDV_01",
"rhs_gaz66_vmf",
"rhs_gaz66o_vmf",
"rhs_gaz66_r142_vmf",
"rhs_gaz66_ap2_vmf",
"rhs_gaz66_repair_vmf",
"RHS_Ural_VMF_01",
"RHS_Ural_Fuel_VMF_01",
"RHS_Ural_Open_VMF_01",
"rhs_gaz66_msv",
"rhs_gaz66o_msv",
"rhs_gaz66_r142_msv",
"rhs_gaz66_ap2_msv",
"rhs_gaz66_repair_msv",
"RHS_Ural_MSV_01",
"RHS_Ural_Fuel_MSV_01",
"RHS_Ural_Open_MSV_01",
"RHS_BM21_VV_01",
"RHS_BM21_VDV_01",
"RHS_BM21_VMF_01",
"RHS_BM21_MSV_01",
"rhsusf_m1025_w",
"rhsusf_m998_w_2dr_fulltop",
"rhsusf_m998_w_2dr_halftop",
"rhsusf_m998_w_2dr",
"rhsusf_m998_w_4dr_fulltop",
"rhsusf_m998_w_4dr_halftop",
"rhsusf_m998_w_4dr",
"rhsusf_m1025_d",
"rhsusf_m998_d_2dr_fulltop",
"rhsusf_m998_d_2dr",
"rhsusf_m998_d_4dr_fulltop",
"rhsusf_m998_d_4dr_halftop",
"rhsusf_m998_d_4dr",
"rhsusf_m998_d_2dr_halftop",
"rhsusf_m1025_w_s",
"rhsusf_m998_w_s_2dr_halftop",
"rhsusf_m998_w_s_2dr",
"rhsusf_m998_w_s_2dr_fulltop",
"rhsusf_m998_w_s_4dr_halftop",
"rhsusf_m998_w_s_4dr",
"rhsusf_m998_w_s_4dr_fulltop",
"rhsusf_m1025_d_s",
"rhsusf_m998_d_s_2dr_halftop",
"rhsusf_m998_d_s_2dr",
"rhsusf_m998_d_s_2dr_fulltop",
"rhsusf_m998_d_s_4dr_halftop",
"rhsusf_m998_d_s_4dr",
"rhsusf_m998_d_s_4dr_fulltop"
];

RHQ_Air =
[
"RHS_Su25SM_vvs",
"RHS_Ka52_vvs",
"rhs_ka60_grey",
"RHS_Mi24P_vvs",
"RHS_Mi24V_vvs",
"RHS_Mi8AMT_vvs",
"RHS_Mi8AMTSh_vvs",
"RHS_Mi8mt_vvs",
"RHS_Mi8MTV3_vvs",
"RHS_Su25SM_vvsc",
"RHS_Ka52_vvsc",
"rhs_ka60_c",
"RHS_Mi24P_vvsc",
"RHS_Mi24V_vvsc",
"RHS_Mi8AMT_vvsc",
"RHS_Mi8AMTSh_vvsc",
"RHS_Mi8mt_vvsc",
"RHS_Mi8MTV3_vvsc",
"RHS_AH64D_wd",
"RHS_CH_47F",
"RHS_UH60M",
"RHS_UH60M_MEV",
"RHS_AH64D",
"RHS_CH_47F_light",
"RHS_UH60M_d",
"RHS_UH60M_MEV_d",
"RHS_A10"
];

RHQ_BAir =
[
"RHS_Su25SM_vvs",
"RHS_Su25SM_vvsc",
"RHS_A10"
];

RHQ_NCAir =
[
"rhs_ka60_grey",
"rhs_ka60_c",
"RHS_Mi8AMT_vvs",
"RHS_Mi8AMT_vvsc",
"RHS_Mi8mt_vvs",
"RHS_Mi8mt_vvsc",
"RHS_CH_47F",
"RHS_UH60M",
"RHS_UH60M_MEV",
"RHS_CH_47F_light",
"RHS_UH60M_d",
"RHS_UH60M_MEV_d"
];

RHQ_Support =
[
"rhs_gaz66_ap2_vv",
"rhs_gaz66_repair_vv",
"RHS_Ural_Fuel_VV_01",
"rhs_gaz66_ap2_vdv",
"rhs_gaz66_repair_vdv",
"RHS_Ural_Fuel_VDV_01",
"rhs_gaz66_ap2_vmf",
"rhs_gaz66_repair_vmf",
"RHS_Ural_Fuel_VMF_01",
"rhs_gaz66_ap2_msv",
"rhs_gaz66_repair_msv",
"RHS_Ural_Fuel_MSV_01",
"RHS_Mi8AMT_vvs",
"RHS_Mi8AMT_vvsc",
"RHS_UH60M_MEV",
"RHS_UH60M_MEV_d"
];

RHQ_Cargo =
[
"rhs_btr60_vv",
"rhs_btr70_vv",
"rhs_btr80_vv",
"rhs_btr80a_vv",
"rhs_btr60_vdv",
"rhs_btr70_vdv",
"rhs_btr80_vdv",
"rhs_btr80a_vdv",
"rhs_btr60_vmf",
"rhs_btr70_vmf",
"rhs_btr80_vmf",
"rhs_btr80a_vmf",
"rhs_btr60_msv",
"rhs_btr70_msv",
"rhs_btr80_msv",
"rhs_btr80a_msv",
"rhs_brm1k_vdv",
"rhs_brm1k_vmf",
"rhs_brm1k_msv",
"rhs_brm1k_vv",
"rhs_brm1k_tv",
"rhs_prp3_vdv",
"rhs_prp3_vmf",
"rhs_prp3_tv",
"rhs_prp3_vv",
"rhs_prp3_msv",
"rhs_bmp1d_tv",
"rhs_bmp1p_tv",
"rhs_bmp1p_msv",
"rhs_bmp1_vv",
"rhs_bmp1d_vv",
"rhs_bmp1k_vv",
"rhs_bmp1p_vv",
"rhs_bmp2_vv",
"rhs_bmp2e_vv",
"rhs_bmp2d_vv",
"rhs_bmp2k_vv",
"rhs_bmd1",
"rhs_bmd1k",
"rhs_bmd1p",
"rhs_bmd1pk",
"rhs_bmd1r",
"rhs_bmd2",
"rhs_bmd2k",
"rhs_bmd2m",
"rhs_bmd4_vdv",
"rhs_bmd4m_vdv",
"rhs_bmd4ma_vdv",
"rhs_bmp1_vdv",
"rhs_bmp1d_vdv",
"rhs_bmp1k_vdv",
"rhs_bmp1p_vdv",
"rhs_bmp2_vdv",
"rhs_bmp2e_vdv",
"rhs_bmp2d_vdv",
"rhs_bmp2k_vdv",
"rhs_bmp1_vmf",
"rhs_bmp1d_vmf",
"rhs_bmp1p_vmf",
"rhs_bmp2_vmf",
"rhs_bmp2e_vmf",
"rhs_bmp2d_vmf",
"rhs_bmp2k_vmf",
"rhs_bmp1_msv",
"rhs_bmp1d_msv",
"rhs_bmp1k_msv",
"rhs_bmp2_msv",
"rhs_bmp2e_msv",
"rhs_bmp2d_msv",
"rhs_bmp2k_msv",
"rhs_bmp1_tv",
"rhs_bmp1k_tv",
"rhs_bmp2_tv",
"rhs_bmp2e_tv",
"rhs_bmp2d_tv",
"rhs_bmp2k_tv",
"RHS_Ka52_vvs",
"rhs_ka60_grey",
"RHS_Mi24P_vvs",
"RHS_Mi24V_vvs",
"RHS_Mi8AMT_vvs",
"RHS_Mi8AMTSh_vvs",
"RHS_Mi8mt_vvs",
"RHS_Mi8MTV3_vvs",
"RHS_Ka52_vvsc",
"rhs_ka60_c",
"RHS_Mi24P_vvsc",
"RHS_Mi24V_vvsc",
"RHS_Mi8AMT_vvsc",
"RHS_Mi8AMTSh_vvsc",
"RHS_Mi8mt_vvsc",
"RHS_Mi8MTV3_vvsc",
"RHS_M6_wd",
"rhsusf_m113_usarmy",
"RHS_M2A2_wd",
"RHS_M2A2_BUSKI_WD",
"RHS_M2A3_wd",
"RHS_M2A3_BUSKI_wd",
"RHS_M2A3_BUSKIII_wd",
"RHS_M6",
"rhsusf_m113d_usarmy",
"RHS_M2A2",
"RHS_M2A2_BUSKI",
"RHS_M2A3",
"RHS_M2A3_BUSKI",
"RHS_M2A3_BUSKIII",
"rhsusf_m1025_w",
"rhsusf_m998_w_2dr_fulltop",
"rhsusf_m998_w_2dr_halftop",
"rhsusf_m998_w_2dr",
"rhsusf_m998_w_4dr_fulltop",
"rhsusf_m998_w_4dr_halftop",
"rhsusf_m998_w_4dr",
"rhsusf_m1025_d",
"rhsusf_m998_d_2dr_fulltop",
"rhsusf_m998_d_2dr",
"rhsusf_m998_d_4dr_fulltop",
"rhsusf_m998_d_4dr_halftop",
"rhsusf_m998_d_4dr",
"rhsusf_m998_d_2dr_halftop",
"rhsusf_m1025_w_s",
"rhsusf_m998_w_s_2dr_halftop",
"rhsusf_m998_w_s_2dr",
"rhsusf_m998_w_s_2dr_fulltop",
"rhsusf_m998_w_s_4dr_halftop",
"rhsusf_m998_w_s_4dr",
"rhsusf_m998_w_s_4dr_fulltop",
"rhsusf_m1025_d_s",
"rhsusf_m998_d_s_2dr_halftop",
"rhsusf_m998_d_s_2dr",
"rhsusf_m998_d_s_2dr_fulltop",
"rhsusf_m998_d_s_4dr_halftop",
"rhsusf_m998_d_s_4dr",
"rhsusf_m998_d_s_4dr_fulltop",
"RHS_CH_47F",
"RHS_UH60M",
"RHS_UH60M_MEV",
"RHS_CH_47F_light",
"RHS_UH60M_d",
"RHS_UH60M_MEV_d"
];

RHQ_NCCargo =
[
"rhs_gaz66_vv",
"RHS_Ural_VV_01",
"RHS_Ural_Open_VV_01",
"rhs_gaz66_vdv",
"rhs_gaz66o_vdv",
"RHS_Ural_VDV_01",
"RHS_Ural_Open_VDV_01",
"rhs_gaz66_vmf",
"rhs_gaz66o_vmf",
"RHS_Ural_VMF_01",
"RHS_Ural_Open_VMF_01",
"rhs_gaz66_msv",
"rhs_gaz66o_msv",
"RHS_Ural_MSV_01",
"RHS_Ural_Open_MSV_01",
"rhs_tigr_vv",
"rhs_uaz_vv",
"rhs_uaz_open_vv",
"rhs_tigr_vdv",
"rhs_uaz_vdv",
"rhs_uaz_open_vdv",
"rhs_tigr_vmf",
"rhs_uaz_vmf",
"rhs_uaz_open_vmf",
"rhs_tigr_msv",
"RHS_UAZ_MSV_01",
"rhs_uaz_open_MSV_01",
"rhsusf_m1025_w",
"rhsusf_m998_w_2dr_fulltop",
"rhsusf_m998_w_2dr_halftop",
"rhsusf_m998_w_2dr",
"rhsusf_m998_w_4dr_fulltop",
"rhsusf_m998_w_4dr_halftop",
"rhsusf_m998_w_4dr",
"rhsusf_m1025_d",
"rhsusf_m998_d_2dr_fulltop",
"rhsusf_m998_d_2dr",
"rhsusf_m998_d_4dr_fulltop",
"rhsusf_m998_d_4dr_halftop",
"rhsusf_m998_d_4dr",
"rhsusf_m998_d_2dr_halftop",
"rhsusf_m1025_w_s",
"rhsusf_m998_w_s_2dr_halftop",
"rhsusf_m998_w_s_2dr",
"rhsusf_m998_w_s_2dr_fulltop",
"rhsusf_m998_w_s_4dr_halftop",
"rhsusf_m998_w_s_4dr",
"rhsusf_m998_w_s_4dr_fulltop",
"rhsusf_m1025_d_s",
"rhsusf_m998_d_s_2dr_halftop",
"rhsusf_m998_d_s_2dr",
"rhsusf_m998_d_s_2dr_fulltop",
"rhsusf_m998_d_s_4dr_halftop",
"rhsusf_m998_d_s_4dr",
"rhsusf_m998_d_s_4dr_fulltop",
"RHS_CH_47F",
"RHS_UH60M",
"RHS_UH60M_MEV",
"RHS_CH_47F_light",
"RHS_UH60M_d",
"RHS_UH60M_MEV_d"
];

RHQ_Fuel =
[
"RHS_Ural_Fuel_VV_01",
"RHS_Ural_Fuel_VDV_01",
"RHS_Ural_Fuel_VMF_01",
"RHS_Ural_Fuel_MSV_01"
];

RHQ_Rep =
[
"rhs_gaz66_repair_vv",
"rhs_gaz66_repair_vdv",
"rhs_gaz66_repair_vmf",
"rhs_gaz66_repair_msv"
];

RHQ_Med =
[
"rhs_gaz66_ap2_vv",
"rhs_gaz66_ap2_vdv",
"rhs_gaz66_ap2_vmf",
"rhs_gaz66_ap2_msv",
"RHS_Mi8AMT_vvs",
"RHS_Mi8AMT_vvsc",
"RHS_UH60M_MEV",
"RHS_UH60M_MEV_d"
];

Anxiously waiting for the new HAL release. I wonder if we might be getting different doctrines anytime soon for HAL (Guerilla, Soviet Rush, Delaying defence etc.). These would be godsent and would open up even more diverse uses for HAL.

Edited December 7, 2014 by Bumgie

[kremator 1065]

Used the latest HAL yesterday alongside Zorrobyte's ZBE_cache and it was great ! Had > 25 FPS the whole time with around 450 units on the field (of which about 280 were cached). I use MCC as well to monitor the tactics of the Big Bosses and I noticed that they really do order a shedload of WPs for groups (I think it was around 15-20 WPs). It didn't look like the WPs were doing anything specific, ie all MOVE, nor did they look like they were avoiding obstacles, or flanking.

Towards the middle stages of the battle, 2x OPFOR tanks ran right through enemy lines without being tackled (or tasked by Big Bosses). It did look like a glaring tactical blunder by BLUFOR, as they then nearly wiped out everything else :(

Is there a 'spotted' function that could then retask troops?

I really enjoyed watching in MCC camera the battle unfolding. Good job Ryd !

[Rydygier 1309]

Alternative doctrine is so delaying (as far from ready as half year ago) because proven to be very troublesome to inject smoothly into existing HAL's routines. HAL's code is vaste and focused on certain doctrine, thus the problems. It is doable, but I wonder, if woulnd't be even easier to write separate script than making it one of the HAL's features. Stil, HAL provides too many useful things, so after all I'm still for making it inside Hetman. But it's about only one, Soviet. Even more different, like guerilla, are most probably too far from Hetman to be reasonably incorporated.

Autofiller will be, but it's experimental and fragile on exotic configs or changes in the vanilla config (it's all about complex mining through config values to determine, what is what regarding HAL's categories). So manual RHQ is still valid alternative existing apart from autoRHQ, that may be used instead (if for certain mod autofiller fails somehow) or together, as supplement. Autofiller is meant to construct RHQ set basing only on units found on the map at init (mostly due to performance reasons - avoiding huge class arrays to mess with every cycle, while most of their contnet isn't used). If any other clasess would be spawned later, also in such case these must be added via manual RHQ. Vanilla classes still are on place by default.

and I noticed that they really do order a shedload of WPs for groups (I think it was around 15-20 WPs). It didn't look like the WPs were doing anything specific, ie all MOVE, nor did they look like they were avoiding obstacles, or flanking.

That would be optional pathfinding mode for infantry groups. It divides route into sections, and uses selectBestPlaces to place each mid-waypoint in the as infatry-friendly terrain as possible in certain radius around the route line. So, basically, with this infantry tends to move along well covered area if possible or from one covered area to another. Manual:

RydHQ_PathFinding = 0 – this variable is shared by all Leaders. If set with positive value, experimental path finding based on terrain is turned on for non-motorized infantry. It is on waypoints level. Value controls “resolution†in meters – on how long sections route will be splitted for assigning mid-waypoints. Recommended values are 100 - 400. Not motorized groups will choose path preferably through good covered areas, as forests, urban areas or mountains, if near to route. NOTE: use with caution, this is experimental feature and can make troubles sometimes;

Is there a 'spotted' function that could then retask troops?

Retasking is something, I'm thinking about, but it's though to resolve in script, when already busy group should abandon current task, and when should stick the plan. In other words, not easy to create reliable prioritizing code determining, which task is more important at the moment (what's obvious for human mind often is extremely hard to script). Currently busy group rarely is touched (except has to withdraw for some reason), and only some idle group may be sent towars newly spotted threat. Possibly I could base it on danger factor used by Hetman combined with distance check from closest group that possibly ould help. In similar way works reserve in defensive mode, so we have some routines. But I need to be carefull. Main thing about Hetman, it acts according to plan. I shouldn't turn it into simple danger-reacting script.

Edited December 7, 2014 by Rydygier

[bumgie 49]

Also a little help for anyone who might need to do vast amount of RHQ arrays in the future...

Use this as it posts a nice list to RPT of the units used in the mission.

RydHQ_RHQCheck = true;

I for example placed all the infantry units of USAF in the editor and then read the RPT and got this data.

11:45:14 "rhsusf_army_ocp_rifleman"
11:45:14 "rhsusf_army_ocp_aa"
11:45:14 "rhsusf_army_ucp_aa"
11:45:14 "rhsusf_army_ocp_javelin"
11:45:14 "rhsusf_army_ucp_javelin"
11:45:14 "rhsusf_army_ucp_riflemanat"
11:45:14 "rhsusf_army_ocp_riflemanat"
11:45:14 "rhsusf_army_ocp_crewman"
11:45:14 "rhsusf_army_ocp_combatcrewman"
11:45:14 "rhsusf_army_ocp_driver"
11:45:14 "rhsusf_army_ocp_helicrew"
11:45:14 "rhsusf_army_ocp_helipilot"
11:45:14 "rhsusf_army_ucp_crewman"
11:45:14 "rhsusf_army_ucp_combatcrewman"
11:45:14 "rhsusf_army_ucp_driver"
11:45:14 "rhsusf_army_ucp_helicrew"
11:45:14 "rhsusf_army_ucp_helipilot"
11:45:14 "rhsusf_army_ocp_autorifleman"
11:45:14 "rhsusf_army_ocp_engineer"
11:45:14 "rhsusf_army_ocp_machinegunner"
11:45:14 "rhsusf_army_ocp_grenadier"
11:45:14 "rhsusf_army_ocp_machinegunnera"
11:45:14 "rhsusf_army_ocp_medic"
11:45:14 "rhsusf_army_ocp_riflemanl"
11:45:14 "rhsusf_army_ocp_squadleader"
11:45:14 "rhsusf_army_ocp_teamleader"
11:45:14 "rhsusf_army_ucp_autorifleman"
11:45:14 "rhsusf_army_ucp_engineer"
11:45:14 "rhsusf_army_ucp_grenadier"
11:45:14 "rhsusf_army_ucp_machinegunner"
11:45:14 "rhsusf_army_ucp_machinegunnera"
11:45:14 "rhsusf_army_ucp_medic"
11:45:14 "rhsusf_army_ucp_rifleman"
11:45:14 "rhsusf_army_ucp_riflemanl"
11:45:14 "rhsusf_army_ucp_squadleader"
11:45:14 "rhsusf_army_ucp_teamleader"
11:45:14 "rhsusf_army_ucp_marksman"
11:45:14 "rhsusf_army_ocp_marksman"

From here I picked these lines including the time stamps and pasted them in the RHQ correct categories.

In the end I used RegExp commands in Poseidon to remove the time stamps and add a , at the end.

Replace what: ..:..:.. (".*")

Replace with:\1,

This way I ended up with one extra , at the end of the array that had to be removed to make the array work ingame.

[Rydygier 1309]

Seems, HQ chat is mostly ready for testing and debugging (tommorow?). It's done via custom radio channels, so I can set callsign text and color and control, who exactly would see the chat. Each order will get own order phrase. Final shape of the chat:

Dynamic callsign or type of TL's vehicle. Do something at location name if present, Grid: 024577. Over.

Dynamic callsign is something, I not decided yet. I can define (and make it customizable, so user could set own instead or disable the feature by leaving them empty) two arrays of strings, one full of cool adjectives and second, full of nice nouns. Like:

_adj = ["Red","White","Black"];

_nou = ["Eagle","Hawk","Serpent"];

With those I can combine many (9 in this case, eg "White Serpent") unique callsigns and assign one per group via setVariable. Those callsigns could be used in HQ chat and maybe also in the AI chat map markers (not sidechat, as this uses radio command to add voice, for which sentence is sadly hardcoded in the description.ext). Just have to figure out reliable code managing callsign assignment taking into account groups spawned mid-game and keeping callsigns unique.

So, what do you think, people? Good idea?

HQ chat is optional, but one obligatory change has to come together. It's about cycle duration. Till now, assuming amount of troops to manage, HQ, even the slowest personalities, was inhumanly fast (like about 1 sec per group). It's to little time to show given orders in believeable pace. From the other hand, full realism here would make HQ too sluggish as for game conditions. So I could show only some of the orders, like in the current radio chat, or prolong the cycle. I've chosen the latter. Decided, it will be 3-5 sec. per order, thus cycle delay, for all personalities, will be now longer per 5 * amount of controlled groups (-12.5 though, so for 1-2 groups it is even faster).

Along with that tasking flow consequently will be more realistic. Till now it looks like:

CYCLE START, order,order,order................................................CYCLE END

After this change it should be more like:

CYCLE START................order................order...............order...............CYCLE END

I wonder, how it will look in tests... :)

Any quick ideas?

Edited December 8, 2014 by Rydygier