Analysis and Expansion of HC's

[JamesTheClarke]

https://www.carpenoctem.co/forums/m/26081621/viewthread/33492764-analysis-expansion-hcs/page/1

related to #6

Goal of this initiative:

1.) document how many HCs are currently set up on our server and how many are actually running per mission, if there's a discrepancy - deploy fix

2.) expand our HC capacity by adding 1 or 2 more HCs to the server

3.) investigate if compositions (Default Modules) require an update to initiate the added HCs in the missions

[Seb105]

3.) investigate if compositions (Default Modules) require an update to initiate the added HCs in the missions

Yes, more HC virtual entities will require adding to default modules.

[JamesTheClarke]

@freghar did you receive the VPN login I requested for you from Shiny? If yes, can I assign you to this issue, since you wrote the original HC PowerShelll scripts on our server?

[freghar]

I don't know what scripts the server uses now. I wrote the original batch (not PowerShell) scripts, which (if in use) should be easy to extend for a second HC and I can do that (unless serious problems arise). I see a second HC virtual entity in our module compositions, so those won't have to be changed. I'm not sure how to do the first goal, and maybe I'd leave that to somebody else.

I don't plan on doing any further work on this beyond just expanding 1 HC to 2, so if there's not enough RAM or if CPU scheduling starts slowing down the server exe, somebody else will have to debug that.

[JamesTheClarke]

Sry my bad, yes they are bat files, we adapted them once (Flo) for a repo addition but otherwise, they are probably the same as they were when you wrote them.

[freghar]

(copying from discord)

Done, was actually really easy. Just copy/pasting the arma3server.exe -client ... section a second time.

I've done it for main, main+dev, main+campaign bat files, but tested only with main ... seems to work as advertised, second HC slots in correctly on the training mission, and editor-spawned units get distributed across server / hc1 / hc2. Zeus-spawned units, curiously enough, get balanced in a round-robin fashion between HCs and the originating client, so at least some AI units remain on the client, which would explain some AI lagging and some not.

But that's ACEX logic, nothing to do with a second HC.

[freghar]

Feel free to close it if you consider it done (w.r.t. the first "goal" you mentioned).

[JamesTheClarke]

I've done it for main, main+dev, main+campaign bat files, but tested only with main ... seems to work as advertised, second HC slots in correctly on the training mission, and editor-spawned units get distributed across server / hc1 / hc2. Zeus-spawned units, curiously enough, get balanced in a round-robin fashion between HCs and the originating client, so at least some AI units remain on the client, which would explain some AI lagging and some not.

But that's ACEX logic, nothing to do with a second HC.

Question: would you then recommend to use A3AA locality transfer instead of ACEX and turning ACEX HC transfer off via CBA?

[freghar]

A3AA locality transfer doesn't care about Zeus-spawned units, it only works for the editor-placed ones, so they are not equivalent.

And the editor-placed ones are not an issue, since they get distributed between the server, hc1 and hc2, so even if the server still handles some AI, it's much better than a Zeus client doing it.

[JamesTheClarke]

Understood, that's good to know. Yet another reason why mission makers should invest more time into crafting the majority of the mission in EDEN rather than spawning 80% in via Zeus. :D

I'll leave this issue open until I wrote a very short documentation entry in the compositions repo (MMTs main GitHub repo) to note down relevant information regarding HC distribution, especially with concerns over Zeus.

[enrico-ghidoni]

@JamesTheClarke can we close this?