HETMAN - Artificial Leader

[euly 0]

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

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

Hey, I'm not selling snake oil here. If you can prove me wrong, definitively, I would greatly appreciate it. If you have better suggestions that apply to whole-map warfare with HAL, we're all ears.

The opinion I hold has formed from thousands of hours of mission making over more than decade, you can see my join date. I obviously do more trials and playing than posting. That doesn't make me an expert with scripts or code, but I do tend to notice subtle differences in how the game responds to different configurations on the map. To your credit, though, I haven't noticed the performance hit as much after I built this system with an SSD, but it was prominent in Alpha with standard 7200rpm drives (16mb cache). I still maintain the habit, though, but I disagree that it's a waste of time, considering it's a habit that doesn't add excess lines of code in, opposed to laboriously removing lines of code. The performance hit is not throughout the playtime of the mission, but historically, the game's engine takes longer to recover from the initial read, which can be a few minutes, affecting other tasks. That is what I meant by it bleeding into the mission. Personally, I would rather see the mission perform optimally immediately, rather than hope it smooths out.

I believe the mission.sqm is partially read prior to the briefing and suspended at the briefing screen, which explains the absence of activity and why only addon related errors display on the briefing screen because those are listed at the top. Unit related errors display once the mission is continued, indicating that the game resumes reading the mission.sqm and executing all commands, such as unit placement, direction, etc..

[delta99 34]

Hey, I'm not selling snake oil here. If you can prove me wrong, definitively, I would greatly appreciate it. If you have better suggestions that apply to whole-map warfare with HAL, we're all ears.

I don't want to keep belabouring this discussion but it might be interesting to create a scenario with lets say 1000 units created in the editor and 1000 units created via script calls and see how long it takes both ways. Of course need to figure out how to time it properly.

I am pretty sure that mission.sqm is fully read during the briefing as I think the Alive folks have hooked into that so that they can do a lot of their Alive pre-loading before one actually gets into the mission.

In any event it might be worth trying to prove one way or the other.

Edited May 23, 2014 by Delta99
Delete double post that was made by accident.

[Vigil Vindex 64]

Quick request Ryd, would it be possible to try and make use of "Ryd_Path" variable to minimise the changes required when the file and folder structure changes. Something like:

Ryd_Path = "RYD_HAL";

Then when you need to use the path use:

format["%1\scriptname.sqf",Ryd_Path];

PS. And a clean way to disable the custom sounds so we can choose not to have all those large audio files in the mission.

PPS. Double quotation mark missing in File: RYD_HAL\HAL\HQOrdersEast.sqf Line 74: _attackAv = _attackAv - ["Del];

PPPS. I still see the Arma 3 classnames are duplicated in numerous places. Might be a good idea to isolate all the classnames into one file to manage better.

Edited May 24, 2014 by ssechaud

[Rydygier 1309]

Both are possible.

In fact, if you agree to loose text radio chatter along with audio chatter, then clean enough way should be to delete description.ext and "sound" folder, and disabling radio chatter. Otherwise, if you want to keep text chatter, slight code edition is required, and I can add config variable to avoid necessity of such edition indeed.

But not sure, when next update will appear.

[Vigil Vindex 64]

Thanks Ryd, you are a LEGEND! x

[Vigil Vindex 64]

Getting some errors, not tracked down what is causing them. Demo mission is not giving these errors. All I have changed is making all the AI side east and just one BB.

"Big Boss A issues orders."

"Side: A - Losses: 0 Number: 238 Value: 724 enValue: 0 enFactor: 724 lossFactor: 0"

Error in expression <[];

{

_points set [(count _points),(_x select 0)]

}

foreach _takenPoints;

_poi>

Error position: <select 0)]

}

foreach _takenPoints;

_poi>

Error select: Type String, expected Array,Config entry

Error in expression <RydHQ_Exhausted",[]];

_alliedForce = _alliedForce - (_alliedGarrisons + _alli>

Error position: <_alliedForce - (_alliedGarrisons + _alli>

Error Undefined variable in expression: _alliedforce

Error in expression <RydHQ_Exhausted",[]];

[Rydygier 1309]

If this is happening only in that scenario, and not in the demo, then most probably it is something, that differs these two. A typo in the init config or leader name? I have to see particular scenario to tell more.

[Rydygier 1309]

HAL 1.16 released. Changelog:

- "no sound" script version;

- RYD_Path config variable holding relative to mission folder path to the HAL's files;

- fixed an error breaking code flow if BB is used and two leaders of same BB side are designed as reserve;

- manual updated.

Regarding "no sound" version - removed all oggs and cleared paths to the sounds in Description.ext. This way user can still have text radio chatter, without the sound. Of course that chatter may be disabled too using proper config variable. That version exist only in the script form, as prepared rather for mission makers, if they want to include HAL's code directly into the mission pbo but do not want to make it so heavy due to sound files.

Regarding RYD_Path - of course there are also numerous paths inside Description.ext to the sound files, unless soundless version is used. Not sure, how to apply such kind of variable/constant there (tried and failed. Apparently combining strings not allowed there), so it is left, as is, anyway with decent code editor replacing constant part of the path in this file by find&replace with custom path should be easy and fast.

Edited May 27, 2014 by Rydygier

[Guest]

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

Release frontpaged on the Armaholic homepage.

HETMAN - Artificial Leader v1.16



Community Base addons A3

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

We have also "connected" these pages to your account on Armaholic.

This means in the future you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

[sonsalt6 105]

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

[kremator 1065]

Found a conflict between addon HAL and MCC. Investigating further.

[Vigil Vindex 64]

Thanks for the updates Ryd! :D

I can confirm that VCOM AI (http://forums.bistudio.com/showthread.php?176244-AI-Overhaul-Reactive-Squads) is what makes HAL give the following error in 1.15:

_alliedForce = _alliedForce - (_alliedGarrisons + _alli>

Error position: <_alliedForce - (_alliedGarrisons + _alli>

Error Undefined variable in expression: _alliedforce

Error in expression <RydHQ_Exhausted",[]];

With 1.16 and VCOM AI enabled I still get the above error and spotted this one too:

Error in expression <r ((damage _veh) > 0.5) or (((group _x) in (((_HQ getVariable ["RydHQ_AirG",[]])>

Error position: <in (((_HQ getVariable ["RydHQ_AirG",[]])>

Error in: Type Number, expected Array,Object,Location

Error in expression <RydHQ_Exhausted",[]];

I posted about these in the VCOM AI thread to see if we can find out why it is causing HAL to error in this way: http://forums.bistudio.com/showthread.php?176244-AI-Overhaul-Reactive-Squads

I disabled VCOM AI and tested out 1.16. Everything seems to be working fine except for this error:

Error in expression <0) exitWith {_getBack = true}

}

foreach _knownEG;

if (isNull _HQ) then

{

_onPl>

Error position: <_knownEG;

if (isNull _HQ) then

{

_onPl>

Error Undefined variable in expression: _knowneg

Edited May 27, 2014 by ssechaud

[Rydygier 1309]

Well, to fix such interference between two mods usually is needed to read and understand both of them. Do not know, if this will happen. I'm reading features list of that mod and seems, so at least partially is altering same aspects, as Hetman, so I do not know, if anyway it is reasonable to use both in the same time. But, I see, it is customizable/modular. So perhaps you could find troublemaking part of VCOM AI by selective switching single features.

_knownEG

I think, I see the problem. Why didn't encountered this earlier, that is the question. This was tested. It occurs inside separately spawned loop, so do not breaks the game, just breaks part of Leader's relocating code (that, which should make actually relocating towards newly taken objective Leader to turn back, if enemy is near). BB uses own relocating anyway, so probably you should turn off non-BB relocating for any Leader under BB control - it is said in chapter 6 of manual. _knownEG is a variable, not only one BTW, that I apparently forgot to pass into that loop. Hmm. Another update seems to be needed then. Pity, I do not like bother everyone involved with day by day updates, but oh well. :) Thanks.

---------- Post added at 09:41 ---------- Previous post was at 08:25 ----------

Hetman updated to 1.161. Changelog:

- fixed code error with Leader relocating;

- fixed not visible sentence text for chat debug marker in addon version.

Edited May 28, 2014 by Rydygier

[sonsalt6 105]

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

[Vigil Vindex 64]

Thanks for the updates Ryd. Every update is a step forward towards perfection ;)

In regards to VCOM AI I will look into it and see if we can figure out if it can play nice with HAL in the future.

[Guest]

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

Release frontpaged on the Armaholic homepage.

HETMAN - Artificial Leader v1.161



Community Base addons A3

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

We have also "connected" these pages to your account on Armaholic.

This means in the future you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

[taro8 806]

I must give HAL a go again. Does it read objectives set by ALIVE now?

My dream mission:

*ALIVE to put objectives and spawn enemies

*HAL for commanding friendly units and taking care of organizing all the little things

*I would be Zeus in a base able to only spawn stuff with resources gained by capping the objectives set up by ALIVE. Maybe even no control over units, all the "bought" units would be commanded by HAL, but as a Zeus I could use remote control over any units bought.

Now that would be interesting: minimal setup, maximum randomness and huge replay value. Also it would allow for a multi session missions without the need to save every minute as normally death would be the end of the game. With Remote Control you lose the ability to command a squad, but you can die without a problem. It will be fun to cooperate with AI, one would need to figure out what HAL needs right now and buy it. Watching how HAL would use stuff you gave it would be damn fun.

[Rydygier 1309]

I do not know well ALIVE (although I admire this project) nor Zeus (never tried, only saw a trailer), so can't tell, how this may work. Sadly, have very little time for actual playing Arma game. Well, maybe not "sadly", as this time I'm spending on developing things to play for Arma, which is even better. :) Anyway. HAL's objectives are empty triggers, means just kind of objects code-wise. If there is a way to obtain positions of ALIVE objectives, nothing will stop decent scripter-mission maker from moving HAL's objectives, where ALIVE's objectives are. Even simplier for taking control over any groups spawned in whatever way. As far, as I understood ALIVE concept, HAL in such mission should just replace the OPCOM in his role. Real problem is - ALIVE uses its splendid caching, that HAL, as any caching, doesn't tolerate so far.

[highhead 20]

I do not know well ALIVE (although I admire this project) nor Zeus (never tried, only saw a trailer), so can't tell, how this may work. Sadly, have very little time for actual playing Arma game. Well, maybe not "sadly", as this time I'm spending on developing things to play for Arma, which is even better. :) Anyway. HAL's objectives are empty triggers, means just kind of objects code-wise. If there is a way to obtain positions of ALIVE objectives, nothing will stop decent scripter-mission maker from moving HAL's objectives, where ALIVE's objectives are. Even simplier for taking control over any groups spawned in whatever way. As far, as I understood ALIVE concept, HAL in such mission should just replace the OPCOM in his role. Real problem is - ALIVE uses its splendid caching, that HAL, as any caching, doesn't tolerate so far.

RYD we should really pull our forces together - you are completely right, objectives were simple, but where I struggled was >>> making "virtual units" understand HAL and HAL read "virtual units"!

I had HAL completely ported to our OO structure, scalable with one click, but I knew that I would have to make so much changes to HAL that it wouldnt have been HAL anymore, so I started on OPCOM!

I so much would love to have HAL instead of OPCOM in ALiVE, its much more advanced - but im not able to do it alone - HAC/HAL is yours comrade, and I would have just broken it!

So, once you have enough time I would love to bring it over (if you wish), but its quite an amount of work that must not underestimated! Its an option, and I am pretty sure, it would take both of our projects to the next level! Just saying...

Really, loving your work and congrats what you have done with HAC/HAL!

Highhead

[Rydygier 1309]

Not sure, when exactly I'll be ready to start with this (I definitelly want that), but if you wish, you could anytime here, or via PM describe in details, including quoting of relevant code parts itself, a way, ALIVE's caching is working. This will speed up things. I can guess roughly the basis, and I can study the "virtual units" code myself, but thanks to such explanation I'll be able much faster to grasp the specifics.

Currently my main concern is eventuality, so I'll be forced to replace any instance of any command dealing with groups and units with a function, that would handle properly both, cached and not cached groups/AIs. That would be enormous work indeed.

[euly 0]

I really like Alive and the performance gains it has over HAL, but Alive seems too much like a total conversion mod that aims to change the fundamental nature of how the game is played. If HAL could be improved to tax the CPU less or somehow offload its processing to another computer, it would be superior in its simplicity.

[delta99 34]

I think HAL and Alive are two pretty separate beasts and I would actually rather see them be kept separate. I really like the fact that HAL can be used in a completely scripted version vs. a MOD as well. Because lets face it, putting out a mission out there that requires a MOD (even just 1) really limits the number of people that are going to bother with it. This is likely why we see almost NO missions out there for Alive.

Alive and HAL also seem to have completely different objectives on what they provide to a mission maker. Alive seems much more to provide a virtual battlefield and all the other mission components are built like one normally would in the editor etc. HAL on the other hand is more so of a tool for mission builders.

If I were Rydygier and really needed a caching type system I would look at potentially what is done in other systems. It really depends if you want caching OR virtual units that Alive uses. I think there are advantages and disadvantages to both approaches.

Right now I don't think HAL needs much of that. I've run some of the BIG BOSS demo's on a moderate system and performance seems to be very good. Its great to move all around the battlefield partaking in battles here and there and also to just let the BIS AI engine do what it does with the input from HAL. If folks haven't checked that out I highly suggest you do.

[Rydygier 1309]

No worries. It not about merging two projects into one. IMO it is simultanously about two separate things:

1. using HAL instead of OPCOM in the ALIVE;

2. using ALIVE's caching with the HAL standalone.

For HAL users the only change should be an optional possibility to use ALIVE's caching method for HAL missions.

AFAIK, as for simulation performance (amount of groups you may have at the same time on the map without performance issues), ALIVE's way of caching seems simply unmatched. Even if may prove to be more costly as for scripts scheduler usage. We'll see.

HAL is very demanding here and for me it is still not sure, if all this is doable. Each group have to be mobile, no matter, how far from the player it is, with all features of vanilla mobility (maintaining/assigning new waypoints of all kinds, garrisoning, retreating, groups transported by cargo vehicles, while both cached, sticking the roads or not depends on kind of the group and set behaviour, speed of movement etc). Each group have to keep its awareness, so will detect other near groups, cached or not. Each group have to be able to perform a fight with another group. Result of such fight must not differ from normal fight no matter, if both groups was cached, one of them or none - taking into account all factors, that are affecting course of battles of not cached groups, only in numerical/statistical, simplified way. Group must by properly affected by long range influences, like artillery fire. Cached artillery groups must be able to perform properly simulated fire missions both against cached and not cached targets. Change between cached/not cached form must be smooth and must not break anything, no matter, in what moment of code flow it happens. And more.

Things sometimes may be simplified a bit of course. Eg. groups may be temporary de-cached when comes to the fight between them, beeing under fire, so these things may be simulated by vanilla engine, then group is cached back. If not, what is to achieve, is scripted, numerical replacer of combat results simulation. And all this, together with HAL itself, must not to choke the scheduler.

That's difficulties I see, when I'm thinking about caching for Hetman. Now seems, so ALIVE has similar requirements. That means, system working with ALIVE should be in theory suitable also for HAL, although isn't certain to me for know, how far it goes as for simplifying things. Problem is, HAL's code, unlike ALIVE's, is not designed to work with cached/virtual groups and mentioned possible simplifications. There are probably many hundreds of instancies within HAL's code, where script performs things on the groups or even units directly. Waypoints assigning, waypoint status checks, checking ammunition, health... counting units, determining kind of units, obtaining a leader unit, driver unit, nearest known enemy... checking position, etc, etc, etc. For this are used scripting commands, that require actual groups/units/objects to work. For virtualized group there is a marker on the map and bunch of saved values (well, at least I'm imagining such ALIVE's way of doing that). So, for any place within HAL's code, where are executed commands working on actual groups/units/vehicles, I need to write a function, that will 1. determine, if given group is an actual group, or a virtual one and, depending on the answer, will apply usual scripting command or the code, that will give same result for virtual "group" (read or alter one of saved propereties of virtualized group).

Above is based only on my assumptions about ALIVE's caching architecture. Some things may be easier or harder depending on actual design of that code.

---------- Post added at 08:25 ---------- Previous post was at 07:55 ----------

Now I'm thinking about possible workarounds to simplify above. Let's say, inside mentioned functions there will be not separate scripted replacers for doing same thing to virtualized group, as usual command does with usual group. Instead, for HAL needs, such groups will be temporary de-virtualized, then HAL's things done to them normal way, handled by A3 engine, then virtualized in the new state back. Problem - constant spawning/despawning will kill performance.

Artillery groups may be excluded form caching, otherwise is needed code to spawn each salvo with proper ballistics (unless ALIVE's profiling system does even that?).

Edited June 5, 2014 by Rydygier

[SavageCDN 231]

That sounds very interesting RYD.. although it seems it will be a ton of work to get the two systems working together.

Have you looked at other caching methods that reduce the group to just the leader? DAC does an excellent job of this... perhaps there is a way to use both systems...

Please be gentle... I don't know nearly enough about this stuff and perhaps what I'm saying is just plain silly :p

PS: IIRC ALiVE no longer caches arty units by default

[Rydygier 1309]

Have you looked at other caching methods that reduce the group to just the leader?

That solution has two advantages:

- group as entity stays - scripting commands performed on groups can be applied (however empty, dummy groups may be kept also for full virtualization);

- group stays mobile and active - movement and (partially) awareness aspect is handled by vanilla (what costs performance of course).

But IMO gain is not as good, as could be. After all some resources are spent on leader unit (along with his vehicle and its crew, if this should make any sense). As said - ALIVE's system is unmatched here, allowing for much more. There also is problem with battles of such cached groups. If groups are fully virtualized, then battle result is emulated by pure juggling with numbers. If group isn't cached at all, then battle is simulated normally, by A3 engine. But how to handle battle between two groups reduced to the leader only, where leaders are fighting normally, and rest is virtual? Unless we decache group at fight, or make leaders invulnerable and results are obtained as for fully virtual group... Part of the problems described above stays - counting units, commands working on single units, losses (morale) calculation, ammo counting, health check, cargo space needed check, artillery fire from both points of view...

Anyway, half of this idea is making HAL compatibile with ALIVE, and ALIVE uses that method, not another.