Ares
Ares copied to clipboard
astruyk
Experimental - Add setting to spawn AI units on server (or HC) instead of locally to zeus
Running Zeus with AI mods sucks because you have to be sure to have everything setup. I think if we were able to manually dump ownership of spawned units to the server we could remove that requirement. Also, it would be nice to support Headless Clients. I don't have an HC setup to test with though, so maybe that's future work.
Tried running the following today as a module:
#include "\ares_zeusExtensions\module_header.hpp"
if (isNil "ARES_Set_Owner_To_Server") then
{
ARES_Set_Owner_To_Server =
{
_unitsToAdd = _this select 0;
{
diag_log format["Pre-change owner '%1' = %2 (isLocal? %3)", name _x, owner _x, local _x];
diag_log format["Result: %1", (_x setOwner 1)];
diag_log format["Post-change owner '%1' = %2 (isLocal? %3)", name _x, owner _x, local _x];
} forEach _unitsToAdd;
};
publicVariable "ARES_Set_Owner_To_Server";
};
_unitUnderCursor = [_logic] call Ares_fnc_GetUnitUnderCursor;
[[(units (group _unitUnderCursor))], "ARES_Set_Owner_To_Server", false] call BIS_fnc_MP;
#include "\ares_zeusExtensions\module_footer.hpp"
In an attempt to move AI that was spawned over to the server. It doesn't seem like this works. The Pre and post-change owner is the same, and 'setOwner' is always returning false. I'm not sure why it doesn't work. If I disconnect and reconnect then dropping the module gives the expected output (that the unit is now local to the server).
Needs more investigation. Might work to transfer to another client (i.e. HC) - but I don't have a setup to test w/ that ATM.
@astruyk, something like this is badly needed.
Transfering the units to the server would be great, but I may have an alternative in case that doesn't work: Add a command in Ares to clone the selected unit on then server and then delete the former one.
It could work like this: 1- You create local units with Zeus
2- You use that eventual ares command to:
- Create a similar unit on the server (at least the same class, possibly more)
- Add it to Zeus control using addCuratorEditableObjects
- Delete the original unit
3 - Then give orders as usual.
Should that be possible?
To expand on the above, I suggest checking out how AI Caching and Distribution script does it. During mission init it removes all AI from the Dedicated Server and creates new ones on Headless Client. Sadly it doesn't work dynamically and you can't do it during the mission, it only runs during mission init. Making this into a Zeus module would just be so perfect.
Basically doing setOwner removes the waypoints and scripts associated with that unit stop functioning if I understand that correctly. I am sure you can see more than me on what exactly that script does, it's on GitHub as well.
I think that AI Caching script is basically doing what @esteldunedain described - at least from my cursory glance at the code and your description of the limitations. It sounds like it's going to have to be done by re-creating the unit on the server as described above.
That sucks because all of the state on the unit is going to be lost if it's not re-created manually. Things like group compositions and waypoints might not be too bad, but for things like garrisoned units or anything with state stored in a 'setVariable [...]' call it'll basically bork the unit.
Still, even with those caveats I think it's still worth pursuing.
I might take a look and see how terrible it would be to intercept the unit at creation time (i.e. right after you drop it into the map) and do the transfer then. Presumably then there'd be less of an issue with preserving state (since the unit just got created in a fresh state anyways). That was where I wanted to end up at some point anyways - generally if you want units on the server/HC you're going to want ALL units to be spawned there instead of the local machine. It'd definetly have to be an opt-in behaviour though.
Great @astruyk. Any related approach certainly would work; in any case the users should be aware of this issue and adviced to run the command as soon as possible after creation.
But, keep in mind that after I posted this, others from AGM pointed out that apparently setOwner is currently working for transfering units from client to server, providing that:
- It is run on the server
- The server's "client ID" (it does have one!) is correctly determined. Apparently it's not always 0, but it can easily be obtained by running the
ownercommand on some known to be object local to the server.
This is being used in AGM currently, apparently without issues.
If you go the way AI Caching script works, waypoints work perfectly with it as well as everything else EXCEPT init fields from the editor, they get wiped when the unit is recreated and that's the biggest hold-back. It sometimes has weird issues with Zeus control, but nothing big.
Interception is a good idea to test, but I believe it won't work effectively. Looking forward to results though.
setOwner removes all waypoints by itself correct? So another function for waypoints and whatever else is necessary are still needed?
Can you confirm that AI is always local to Zeus? I've did some limited tests and got differing results (local returning false etc.)
I am positive, I can run some tests if you wish thought. The AI also changes locality when reconnecting. Unless BIS changed something in the last updated...
AI created by Zeus is local to the machine running zeus. AI placed in a mission file (i.e. in the editor) or created on OTHER zeus clients (if more than one) will be local to the server or another zeus client (respectivley). If you have scripts running that create units, the units will be local to the machine that executes the script.
Very odd, maybe I fudged my tests but I distinctly remember creating a unit and local returning false. How is it for units which are under the control of several ZEUS?
AI placed in a mission file (i.e. in the editor) will be local to the server
To clarify: Placed in the mission and under zeus control or simply present? What about AI under the control of several ZEUS? What happens if a zeus creates units and then disconnects?
@Wolfenswan, maybe this will help: wherever the locality of the unit is (server, other clients, etc), any Zeus can control it if the addCuratorEditableObjects command is run. So having one or many curators controlling a unit doesn't change the locality of the unit.
As @astruyk and @jonpas said, units are always local to the Zeus or script that created them, until either that client disconnects (units are transfered to the server) or (I believe) a player joins the unit group (units are transfered to that client).
What are the advantages to that design decision in Zeus? I can only think of negatives; network latency on the client, underpowered machine on the client, resulting in a poor experience for all others.
Why wouldn't all units spawn on the server by default? Perhaps a little off topic sorry, I'm just really curious about why they would ever be run on the clients machine instead of the powerful server designed for it!
@esteldunedain I knew the method, as @alexcroox points out it just feels counter-intuitive and as of yet I wouldn't know of an official documentation to ZEUS and locality.
@alexcroox As locality dates back to OFP there is a chance that a lot of legacy stuff is involved. But the only good reason at the moment (at least I can think of) to not create AI local to the server is when a Headless Client is present.
@alexcroox The only advantage I can see to having the units local to the Zeus is offloading processing from the server to the Zeus a la headless client. Given that you cannot guarantee the performance of the Zeus's computer (or their connection speed to the server) in the same way that you can of the server, it's an interesting choice. The fact that it transfers ownership of the units to the server instead of killing them on Zeus disconnect implies to me that this was very much intentional.
Do any of you have the ability to test with a headless client set up? I doubt it would be the case, but I am curious to see if Zeus instead creates units local to the headless client if it is present.
The fact that it transfers ownership of the units to the server instead of killing them on Zeus disconnect implies to me that this was very much intentional.
I don't think so. Transfering of orphan units to the server has been done in the arma series for a long time, probably since Flashpoint. It's just standard engine behaviour. For example, without that vehicles would disappear if the driver disconnects.
IMO it's probably because it was the easiest solution, specially if unit creation was prototyped in sqf.
Zeus functions exactly the same as a headless client when it comes to handling AI. When headless client disconnects it also returns all AI on it back to server. AI is local to Zeus because the 'internal engine script' (let's call it that) spawns AI local to where the script is ran, but if you ask me it's just poor implementation on BIS' part. They were saying something about making headless client much more automatic with automatic AI transfers...etc. but you know, that might never come. :P
Do any of you have the ability to test with a headless client set up? I doubt it would be the case, but I am curious to see if Zeus instead creates units local to the headless client if it is present.
I do, and no it doesn't, current headless client integrations is kinda shitty, you still have to use scripts to transfer AI to headless, even on mission start.
Ares has the ability to take server spawned and controlled units and add them to zeus, I presume it doesn't work so simply in reverse?
No no, that's totally different. You can control any unit wherever it's located, meaning you can control a unit whether it's on server, headless client or local to another Zeus. But that won't change their locality (until you start remote controlling a unit I believe).
Some setting owner between client/DS fixes in latest update post, not sure if any of it is useful or relevant to this http://dev.arma3.com/post/spotrep-00039
From what I gathered, setGroupOwner command should work perfectly for this issue after this update.
setGroupOwner is supposed to work perfectly for any change of locality, a good round-robin AI balancing across headless clients has actually already been written: http://www.reddit.com/r/armadev/comments/2wm2xs/roundrobin_load_balancing_of_ai_across_up_to/
I am thinking at least 2 modules:
- Spawn Settings (can be in the basic settings module as described on another issue)
- Change Locality (drop on AI group)
This would be still be very useful, I can use HC scripts with Zeus but I can't edit the group format/skill etc after placing because it's immediately transferred away. A module to drop on the group to transfer as you suggested @jonpas would fix that!
This is now easily possible with setGroupOwner command, can transfer to any client, HC or server, this was tested couple of days ago.
I get the impression @astruyk isn't developing this mod anymore? A damn shame, easily the most useful Arma mod week in week out :(
Anton's alive and well but he's been pretty busy lately. I might be able to prod him about this, because with setGroupOwner available, it should be an easy enough module.
Since this feature is not available at the time could someone provide a script or an idea how to do this?
I think I get how the setGroupOwner command would work. But my question is how I will ensure to always get the right server owner id.
There is a script to be found here: http://www.reddit.com/r/armadev/comments/33pzt1/simple_headless_script/
Didnt test it yet. Seems a bit too much to call on every frame imho.
This is what we are using currently (not latest version): https://gist.github.com/jonpas/b3d2e9a50d50aefbdca8
I am planning to rewrite it using CBA PFHs or even events.
Yer that's the one we've been using for a while now too @jonpas. Do get some strange behaviour with Zeus and this combined though. Once the units are transferred you loose the ability to set skill levels, formations etc of AI group leaders. Which can be pretty annoying if the re-balance timer triggers just as you place the units!