Bug #62500

Headless client AI issue when used for AI offloading (position discrepancies based on range from HC)

Added by dslyecxi almost 3 years ago. Updated almost 2 years ago.

Status:Closed Start date:10/31/2012
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:Server
Target version:-
Affected ArmA II version: First affected build:Please Specify...
Reproduced by another DH user:No First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

Preamble:

The headless client, when used on the same system as the game server, allows for vastly improved AI responsiveness and behavior regardless of server playercount/load. This is the future for high-playercount ArmA coop in my opinion.

When using the headless client for AI processing, all AI creation, waypointing, and other behavioral 'stuff' happens on the HC. All AI are local to it. This results in the AI being able to run many times faster than it would on a high-playercount server - 30-50 FPS, compared to a server that may be under 10fps due to high (100+) playercount.

The problem:

The only hitch we have found so far with this setup is that the headless client acts "too much" like a client when it comes to awareness of player locations and movement. The actual HC exists in a mission as a unit - accuracy of knowledge about player positions is relative to the distance a unit is from the HC's avatar. In short: The further away players are from the HC, the more of a discrepancy exists between what the players see, versus what the AI (simulated off of the HC's knowledge) is 'seeing'.

To illustrate:

Let's say we have a player who is 3 kilometers away from the HC. There is an enemy infantry AI near him. The player sees himself as behind cover - the AI, which is using information from the HC's knowledge of positions (which is inaccurate at longer distances), sees the player as being in a different position - 20 to 40 meters away. The AI fires at this position, hits the player from the AI's point of view, and the player sees an AI fire at an empty position 40m away and then mysteriously dies from it.

The solution:

A headless client should have perfect knowledge of all unit positions on the server at all times, the same as the server does. Since a HC used for AI distribution will be residing on the same system as the server itself, there is no concern re: bandwidth between the HC and the server.

If this change can be made, the HC is solidified as the most significant single thing to ever happen to ArmA AI in high-playercount multiplayer.

Repro:

On a server with a HC, and assuming the HC profile is named 'Administrator', begin a mission and run the following code (assumes you have @CBA):

dslyecxi = player; publicvariable "dslyecxi";  
admin_monitor_position = true; publicvariable "admin_monitor_position";

fn_admin_Broadcast_Position =
{
    waitUntil
    {
        admin_last_position = getpos dslyecxi;
        publicvariable "admin_last_position";
        sleep .01;
        !admin_monitor_position
    };
}; 

publicvariable "fn_admin_Broadcast_Position";

[-1, {if (name player == "Administrator") then {
    [] spawn fn_admin_Broadcast_Position;
}}] call CBA_fnc_globalExecute;

onMapSingleClick "player setPos _pos";  

[] spawn
{
    waitUntil 
    {
        clearRadio;
        hintSilent format["HC position discrepancy: %1m   Distance from HC: %2m",round (admin_last_position distance player), round (player distance (allunits select 1))];
        !admin_monitor_position
    };
}; 

At this point simply click on the map to move different distances from the HC, then move around and watch how the position error will grow and 'stick' longer the further you are from the HC. This becomes most severe at distances >1 kilometer. At 3 kilometers you can end up with a ~50m position error that can remain for 30 or more seconds. At extreme ranges you can end up with massive discrepancies - testing at 10 kilometers revealed a ~1 kilometer positioning offset.

Tested on server version 1.62.98443

Closing:

The HC's potential for AI distribution is incredible. I have never seen something as promising as this for coop gaming. I hope that this issue can become a high-priority fix, as it will mean a night-and-day difference for communities like mine if we can flawlessly use the HC for AI distribution tasks.

hcposrepro.Takistan.pbo (4.4 kB) zx64, 11/19/2012 22:49

HCDomina.7z (1.4 MB) Xeno, 11/26/2012 20:55

MSO_HC_Test.takistan.zip (2.4 MB) highhead, 11/28/2012 20:36


Related issues

related to ARMA2 Community Issue Tracker - Bug #6963: Remote AI calculated on the dedicated server still has a ... Rejected 12/15/2009 11/01/2010
related to ARMA2 Community Issue Tracker - Feature #14387: Ability to scale AI CPU use for mission designers Assigned 10/13/2010
related to ARMA2 Community Issue Tracker - Bug #22447: Positional information at a distance completely unreliabl... Feedback 07/17/2011
related to ARMA2 Community Issue Tracker - Feature #70536: Better (kick/ban) -security for headless client Assigned 01/26/2013
related to ARMA2 Community Issue Tracker - Feature #67648: Identifying Headless Client (isHC) Closed 12/14/2012

History

Updated by kju almost 3 years ago

  • Status changed from New to Feedback

I assume you need to share the implementation/provide a demo mission with exact repro steps for BI to evaluate.
Even better the same mission with the traditional setup to let them compare the differences.

Also please clarify what you mean with these statements:
  • should have perfect knowledge of all unit positions on the server at all times
  • the same as the server does

I think I know what you mean, yet it is better to make this more clear.

See also #6963

Updated by dslyecxi almost 3 years ago

Here is how I understand a client to work. A client is concerned about themselves, and the things around them that can influence their experience. Because of this, there are higher levels of precision for objects/units/etc closer to them, and lower precision for ones further away - both in position and frequency of updates. A player who is 10km away from a unit does not need to know their exact position updated x-many times a second, because it's not relevant to them. Thus, somewhere along the line presumably the server says "Client A is 10km from Client B, only send him an update every ten seconds and the precision can be +/- 500m". As the two clients get closer, the update frequency decreases and the precision becomes more accurate.

The server, on the other hand, does not have any concern about higher/lower precision for things. The server "knows all", it is not isolated to the experience of a single unit as the HC is. The server always knows precisely where a unit is and never loses that precision.

The problem described above is that the HC can be in control of AI that are operating at a distance that causes the AI to see the "low precision" states of units and such, and it can engage them at these "low precision" locations, which does not match up to what the server or the clients see.

The HC needs to have it's networking changed to have total knowledge of all player/vehicle/etc positions at all times, like how the server works.

Hopefully that clears it up.

An additional repro for this would be to do the following:
1. Spawn an AI on the HC's machine.
2. Act as an enemy unit to that AI.
3. Position the HC 2km from you and the AI, then move around while it attacks you (with allowDammage to prevent you dying).
4. Observe that the AI will fire at positions different from where you are and you will see damage effects from it.
5. Position the HC 4km from where you and the AI are, then move and observe how it tracks you.

etc etc

The further away the HC is, the more the AI will tend to engage positions you are not at (and you will still take damage from these 'false' attacks).

To see how it normally behaves, simply create another AI on the server itself and watch it engage you as normal.

Updated by kju almost 3 years ago

  • Status changed from Feedback to Assigned
  • Assignee set to Dwarden

Thanks. Lets see if Suma takes notice or Dwarden can bring this to their attention.

From what Suma was saying and what I know about the game, I am not sure if your description is correct.

Like your HC should be the owner of all the remote AI I would assume.
This should cause the same situation like at the server itself.
One main difference should be that the server does not do any rendering, while your HC probably still does to some degree.

Still don't get me wrong - I am not calling your observations into question. In the end only the BI devs actually know how it works.

Lets hope they will look into this.

PS: Still I believe you need to provide them a full working sample to improve your chances to get looked at it.

Updated by dslyecxi almost 3 years ago

kju wrote:

From what Suma was saying and what I know about the game, I am not sure if your description is correct.

Like your HC should be the owner of all the remote AI I would assume.
This should cause the same situation like at the server itself.
One main difference should be that the server does not do any rendering, while your HC probably still does to some degree.

No, the difference is that the server is a server and the HC is a client. This makes sense in that context. This is how the ArmA netcode behaves for any client and is easily demonstrated via the steps detailed above. The HC owns the AI, but it is using positional data that falls into the 'client' scheme of updates/proximity, not the server's method.

If you would like to see a video of this happening, which is what clued us in on it in the first place, take a look at this:
http://youtu.be/gAXohl5Ef1I?hd=1&t=35m36s

At this point in the mission, our units are probably 3-4km from the HC. The HC has very poor knowledge of our exact position. You can see AI firing machineguns at a position down the hill at the bottom-left of the screen. Observe that you can see the bullets sparking in the air from hitting an invisible object (aka: Where the HC thinks our vehicle is). Observe that the AI fire one rocket at this invisible object, then a second rocket which causes our vehicle to explode, despite it clearly not having hit us. This behavior was seen by multiple people towards the end of the mission in different situations, and is something that I have never seen before in ArmA. It is consistent with the description given above.

Updated by dslyecxi almost 3 years ago

Repro code.

(findDisplay 46) displayRemoveAllEventHandlers "KeyDown";
moduleName_keyDownEHId = (findDisplay 46) displayAddEventHandler ["KeyDown", "_this call fn_dsl_keypress"];

dslyecxi = player; publicvariable "dslyecxi";
{if (name _x == "Administrator") then {the_hc = _x; publicvariable "the_hc"};} forEach allUnits;

[-2, {dslyecxi allowDammage false; the_Hc allowDammage false}] call CBA_fnc_globalExecute;

the_hc enableSimulation false;

fn_dsl_keypress =
{
    private ["_shift","_ctrl","_alt"]; 
    _shift = _this select 2;
    _ctrl = _this select 3;
    _alt = _this select 4;
    enableradio true;

    hintSilent str(_this);

    _suppress = false;

    switch (_this select 1) do
    {
        case 59: 
        {
            player sideChat "Spawning hostile AI on headless client to your front";

            [-2, {
                if (name player == "Administrator") then 
                {
                createcenter east;
                newgroup = creategroup east; 
                newguy = newgroup createUnit ["RU_Soldier", (dslyecxi modelToWorld [0,10,0]), [], 0, "FORM"]; 
                newguy reveal dslyecxi;
                };
            }] call CBA_fnc_globalExecute;
        }; 
        case 60:
        {
            player sideChat "Spawning hostile AI on server to your front"; 

            [-2, {if (isServer) then 
            {
                createcenter east;
                newgroup_server = creategroup east; 
                newguy_server = newgroup_server createUnit ["RU_Soldier", (dslyecxi modelToWorld [0,10,0]), [], 0, "FORM"]; 
                newguy_server reveal dslyecxi;
            };
            }] call CBA_fnc_globalExecute;
        };         

        case 61: {the_hc setPos (player modelToWorld [0,0,1000]); player groupChat "HC is 1km away"};
        case 62: {the_hc setPos (player modelToWorld [0,0,2000]); player groupChat "HC is 2km away"};
        case 63: {the_hc setPos (player modelToWorld [0,0,3000]); player groupChat "HC is 3km away"};
        case 64: {the_hc setPos (player modelToWorld [0,0,4000]); player groupChat "HC is 4km away"};
    };     
    _suppress
};

admin_monitor_position = true; publicvariable "admin_monitor_position";
hc_observed_position_visualizer = "Sign_arrow_down_large_EP1" createVehicleLocal position player;

fn_admin_Broadcast_Position =
{
    waitUntil
    {
        admin_last_position = getpos dslyecxi;

        publicvariable "admin_last_position";
        sleep .01;
        !admin_monitor_position
    };
}; 

publicvariable "fn_admin_Broadcast_Position";

[-1, {if (name player == "Administrator") then {
    [] spawn fn_admin_Broadcast_Position;
}}] call CBA_fnc_globalExecute;

onMapSingleClick "player setPos _pos";  

[] spawn
{
    waitUntil 
    {
        hintSilent format["HC position discrepancy: %1m   Distance from HC: %2m",round (admin_last_position distance player), round (player distance the_hc)];
        hc_observed_position_visualizer setPos admin_last_position;
        !admin_monitor_position
    };
}; 

Execute that in a dev console in whatever terrain you choose for MP. Have the HC and the player in different groups.

F1 will spawn an AI on the HC 10m to the front of where the HC believes you are oriented.
F2 will do the same, except from the server's POV and with the AI local to the server.
F3-F6 will set the HC 1000, 2000, etc meters away from you.

A red arrow will show where the HC believes you are.

For easiest repro, set the HC to 4000m and move around until the hint and arrow show a significant discrepancy between your actual and "HC" location. Press F1. Observe that the AI is created and begins engaging the arrow, which 'bleeds' when hit. It will continue engaging that arrow/position.

By comparison, press F2 to spawn a server AI. It will see and track you normally, as expected.

Video:
http://www.youtube.com/watch?v=UzXTAqT4DWg

Updated by Suma almost 3 years ago

solution
A headless client should have perfect knowledge of all unit positions on the server at all times, the same as the server does.

Technically this looks more like a description of "desired/expected" than a "solution" to me, but that is probably not important. :) The whole idea seems very clever to me and definitely deserves some work to be improved.

What still needs to be decided it how will the client learn all units positions. The easiest way seems to use the normal network protocol, only adjust it a bit. Currently the A2OA netcode is mostly designed for a situation where server-client bandwidth is limited. If a client is running on the same computer as the server (or to certain extent even over LAN), the bandwidth becomes more or less unlimited and a different strategy could be used.

How will server know a connection to a particular client is "infitely fast" and a different message selecting strategy (broadcast everything) should be used? Following ways seem possible:

- Rely on bandwidth measurement and if you see bandwidth high enough, declare it "infitely fast"
- Check the IP address, if you see 127.0.0.1 or a LAN address in a private range (like 192.168.x.x), declare it "infitely fast"
- Provide a server side setting, listing which IP addresses are "local" (127.0.0.1 would be included by default) and when seeing a client with such address, declare it "infitely fast"

The rest should be relatively easy: Once a client is known to be connected with "infitely fast" connection, no object sorting or selection would be done, and all objects position would be transmitted in each frame.

Updated by Xeno almost 3 years ago

@Suma
Question: How would it be possible to make sure that the HC always connects to a specifc slot in case of mission restart or if another mission is chosen ? I'm thinking about public servers...
Or even better, would it be possible that the HC is not visible at all and simply connects without using up a playable slot and creating a player entitiy ?

Plus, if you are going to implement it, some kind of scripting command like isHCServer or similar would also come in handy, just thinking out loud.

Updated by dslyecxi almost 3 years ago

Question: How would it be possible to make sure that the HC always connects to a specifc slot in case of mission restart or if another mission is chosen ? I'm thinking about public servers...

VBS2 has an -autoassign startup switch that could be ported over. I was assuming that was an ArmA command switch already, but the biki seems to indicate otherwise.

Or even better, would it be possible that the HC is not visible at all and simply connects without using up a playable slot and creating a player entitiy ?

How would you then hook it to take advantage of the improvements it allows? The fact that it's a unit/player allows you to easily run code from it.

Updated by Xeno almost 3 years ago

It doesn't need a unit or a player unit. A simple scripting command that tells you that it is a HC with unlimited bandwith should be enough.
Your mission scripts could easily check in that case if the unlimited HC is available and do all AI related stuff on the HC instead of the server.
If the additional variable says no HC available, then your scripts would use the normal way of creating AI on the server.

Updated by dslyecxi almost 3 years ago

It doesn't need a unit or a player unit. A simple scripting command that tells you that it is a HC with unlimited bandwith should be enough.

I assume you mean something like isHeadless and isHeadlessUnlimited?

I would be all for having it be done that way, w/o requiring a slot, and making it as easy as possible to integrate. However, in the mean time it would be great to have the current method 'fixed' as Suma described earlier. Seems like that is a quicker fix than adding additional scripting commands and changing the HC in a more fundamental way.

Updated by Suma almost 3 years ago

  • Assignee changed from Dwarden to Suma

We are also contemplating implementing this completely transparently inside of the server executable, by means of threads. This would however allow only offloading on the same computer, to scale across multiple CPUs. Can you clarify if you use this on the same computer, or across LAN as well?

As currently the server concurrency is very low, it seems to me multicore scaling should be enough, but before I pursue this futher, I would like to be sure if this meets your needs.

Updated by Tupolov almost 3 years ago

From our perspective (MSO) we currently distribute AI to clients in order to reduce the load on the server.

Multi-core AI would certainly help take advantage of the server resources and reduce the performance issues around AI that we see. This would be an awesome step for Arma and I think a priority over any HC implementation.

Saying that, it would also be useful to enable the distibution of AI to other machines. I don't think this should be limited to an "HC" but an open framework to any client machine running Arma. I think the critical request here is that we can tag a client as an AI host so that any AI running locally have accurate position/state data for other AI/players near its position in game. Whatever mechanism the server uses to update position data for AI, we should be able to instantiate on a client tagged as an "AI host". This would allow us to scale out the AI implementation in Arma regardless of server spec or performance.

Updated by Suma almost 3 years ago

we currently distribute AI to clients

Unless the clients are located very close to the server and have practically unlimited bandwidth, the approach described here cannot be used for them.

Updated by Xeno almost 3 years ago

Suma wrote:

We are also contemplating implementing this completely transparently inside of the server executable, by means of threads.

That would be awesome and of course the best solution.

This would however allow only offloading on the same computer, to scale across multiple CPUs. Can you clarify if you use this on the same computer, or across LAN as well?

See what dslyecxi wrote:
"The headless client, when used on the same system as the game server, allows for vastly improved AI responsiveness and behavior regardless of server playercount/load."

So it's already using the/running on the same CPU/computer as the server...

Updated by Sickboy almost 3 years ago

Being able to do it distributed would possibly open up even crazier avenues, though I would agree that on the same system probably suffices.
Maybe keep it for some future ;-)

Updated by Tupolov almost 3 years ago

Suma wrote:

we currently distribute AI to clients

Unless the clients are located very close to the server and have practically unlimited bandwidth, the approach described here cannot be used for them.

Ok, so providing accurate position data to AI on distributed clients causes too much bandwidth. In that case, while we wait for the multi-core feature for AI, can you elaborate on what position data is sent to AI hosted on clients, how often and why we see the inaccuracy?

Is it because lack of frequency of updates (so player moved since AI was last updated) or something else? Do updates to AI (hosted by client) reduce in frequency as the player (on the client) moves further away from them?

From our experience AI running on clients (in a WAN/LAN) scenario seem to be pretty damn good, but this issue seems to indicate it should be otherwise.

Updated by dslyecxi almost 3 years ago

Suma wrote:

We are also contemplating implementing this completely transparently inside of the server executable, by means of threads. This would however allow only offloading on the same computer, to scale across multiple CPUs. Can you clarify if you use this on the same computer, or across LAN as well?

As currently the server concurrency is very low, it seems to me multicore scaling should be enough, but before I pursue this futher, I would like to be sure if this meets your needs.

This would be ideal. Our only intended usage is on the same system as the server exe.

Updated by dslyecxi almost 3 years ago

One thing that would be ideal - if this is done transparently inside the server exe, it would be ideal to be able to see the FPS that the AI is being simulated as, in addition to the server FPS. This helps a mission designer optimize his AI counts when doing a HC mission currently.

Updated by tonci87 almost 3 years ago

Good idea

Updated by Tupolov almost 3 years ago

Keep in mind that not all AI need to target players and therefore its still very useful to be able to offload AI from the server and utilise other machines. Specifically, thinking in situations where you want to spawn civilian AI, traffic, animals,

Also, being able to distribute AI to other machines makes ARMA more scalable and not limited to a single server.

Updated by kju almost 3 years ago

A step by step approach seems most sensible to me.
Trying to achieve all in one go makes it more complex and we might miss our learning experiences.

Updated by zx64 almost 3 years ago

I think everyone will want to revisit their assumptions about what really does need to be distributed if/when the server gets these improvements and there's still the simulation costs for units regardless of where they're hosted (see an older ticket about client FPS vs AI quantity).

There's also the "who benefits" factor - anything which Just Works(TM) internally to the server automatically benefits every multiplayer mission that uses AI rather than only improving things for the very few missions that have done the legwork to do some form of distributed AI (be it same-machine-headless or player hosted).

Updated by Suma almost 3 years ago

I have implemented some optimization in the server code which should help a lot when there are many players on the server. The changes are unrelated to a headless client. As the changed were quite drastic internally, I will wait first for your feedback regarding 99125 performance and stabilitity before proceeding to any threading.

Updated by dslyecxi almost 3 years ago

What specifically should we be looking for? Higher server FPS at high playercount? More responsive AI at lower server FPS? Some combination of those, or something new entirely? Always happy to test, just would like to know what we're looking for.

Updated by Suma almost 3 years ago

Expect improved server fps with high player counts. As a result, improved AI should be seen as well as a result of the higher fps.

Updated by Xeno almost 3 years ago

Is there anything people who make MP content have to look for or probably have to change ?
Or is it just a change like for example reduced simulation update distance for clients ?
Just curious.

Updated by kraze almost 3 years ago

How is AI in MP with headless client compared to AI in SP under the same conditions e.g. same FPS?

Updated by Ayger almost 3 years ago

AI is better on a (decent->good) dedicated server (COOP mission) even under current configuration (without HC) because all (not under your command) A.I. calculations are done is server's hardware-while in SP mission AAAALL calculations are done in YOUR machine..

Updated by dslyecxi almost 3 years ago

Suma wrote:

Expect improved server fps with high player counts. As a result, improved AI should be seen as well as a result of the higher fps.

It does seem to be higher, particularly at <100 players.

At 74 players we saw a server FPS of 35-40, quite nice - this was in an adv mission. At ~110 players in a coop (using the headless client method for AI), we had a server FPS of 8-9. Prior attempts of a similar mission and playercount, before this change, would have been 2-4fps. We played a 124 player adversarial that has ~10fps during the fighting, which was a nice improvement.

One thing that still seems to cause server FPS drops is #27001. When a player is losing connection or has high packetloss, the server FPS noticeably degrades, desync increases, and you get red/yellow chain periods.

Overall, this seems like a positive improvement. I am hopeful that #27001 will help a lot as well, and curious if there might be other things in the works to allow for higher playercount ArmA? Are there any optimizations that might be able to happen at >80 players? I would love to see a 200-player server run smoothly without issue, via multithreading or whatever other magic might help. Something like what the Headless Client can do for AI, but for server performance and handling larger playercounts. Communities like mine certainly have the server horsepower for it.

Updated by Suma almost 3 years ago

To avoid "Perfect is enemy good" trap, the functionality requested originally is implemented in 99184. To mark all clients connecting from a local machine as having unlimited bandwith, use following line in your server.cfg:

localClient[]={127.0.0.1};

You can also add other addresses, e.g.

localClient[]={127.0.0.1,192.168.2.1,192.168.2.2};

All clients marked with corresponding addresses should be sent all information, with no bandwidth limitations.

If this works well, we may use 127.0.0.1 as a localClient default value later, with the possibility to use localClient[]={} to turn this off if needed.

Updated by neokika almost 3 years ago

Thank you Suma, is there any way to detect the localClient machine already or not yet implemented?

Updated by zx64 almost 3 years ago

First of all, is it good to assume that getPosATL is the correct value to be comparing when we're primarily concerned with AI targeting?

Unfortunately I'm still seeing some issues with far away objects even though I can confirm the HC connecting via the localClient mechanism (i.e. bandwidth being shown as roughly 2^24).

Throughout this comment I've used the term "position error" which is probably a bit of an abuse of terminology but hopefully it should be clear - it is the delta between the player's position and the position observed (and broadcast) remotely. This is expected to be higher than any internal "error" values because of additional latencies introduced.

I've attached a (hopefully) OA-only test mp mission implementing the position error visualisation bits above. This is to make it easier to see when the HC and the server have different error values (the helper arrow for the server is blue).

Mission also has an altitude preserving map click teleport to make it easier for you to test aircraft.

Set up for repros:

1) Host the mission on a dedicated server, configured appropriately
2) Connect a normal client to the server and pick the mission. Choose the first role.
3) Connect a headless client to the server and confirm that it has chosen the second role.
4) Start the mission, observe error values and arrows.
5) Use the map click teleport to examine how the errors diverge when moving at a distance in different vehicles.

Observed:

Once teleported to the Loy Manara airbase area (roughly 10km distance from the HC object), significant differences in position "error" between the server and the headless client can be observed.
The severity of the differences depends on vehicle used.
When flying the MH6, the red arrow (HC perceived position) can be seen updating very slowly or e.g. flying into the ground.
When flying the Albatross, the errors diverge when making turns.

Even when stationary and map clicking around, the HC error takes a long time to stabilise to zero.

Expected:

The HC and server error values stay consistent. (Note that I'm not expecting that error values are zero during movement for reasons stated above)

Versions tested: Player client 1.62.95248 (1.62 stable) and 1.62.99202, Server 1.62.99202, Headless Client 1.62.99202.
This was tested entirely locally (all three run on my machine) and with the server/HC remote (ShackTac server).

Updated by Suma almost 3 years ago

HC was still handled differently from a server in that it considered a camera position when deciding what to transfer. This should no longer be the case with 99262.

Updated by Xeno almost 3 years ago

Suma, would it be possible to block a specific slot for the HC ? (as long as the server itself does not provide the extension, if still planned)

Maybe by using

__HC__

or similar in the unit description field or var name.

If such a slot exists in the mission the first local HC, if available, would be automatically moved into that slot and no one else would be able to take that slot. The slot should simply spoken be completely blocked except for a HC. Similar to what

__SERVER__

does in some BAF MP scenarios (I think it was BAF, those slots are blocked for players if you play the missions on a dedicated server).

Would make things much easier on public servers and also for everybody else who will make use of it.

Edit: And of course nobody should be able to kick or ban a HC, not even Battleye :)

Updated by zx64 almost 3 years ago

Spent a bit of time testing 99343 with just me+1x HC on the server (both locally hosted and remote) - looking good so far. Should be able to check it with lots more players later on this week with our next scheduled session.

Updated by Xeno almost 3 years ago

For those who are interested to test a HC on the server and don't know how I've made a special Domina version.
Mission is attached, check the readme inside the 7z file.
If no HC is available the mission should run on the normal server. If a HC is available and disconnects then there is no fallback code for the AI that did run on HC. But the mission will spawn all new AI again on the server

Contrary to the OP the HC check is done in onPlayerConnected.

Updated by SavageCDN almost 3 years ago

^ thank you Xeno!!

(and highhead)

Updated by highhead almost 3 years ago

I also made an experimental HC version for MSO, not as well implemented as Xeno did (HC needs to stay connected) but for those who are interested please find the file attached and instructions inside.

Updated by zx64 over 2 years ago

This particular issue seems resolved by now, we've tested it in a coop with 105 players spread around north Takistan and seemed to be behaving as expected.

I was also monitoring relative positional error reported by getPosATL (using a more advanced version of the attached repro) during a 110 player adversarial on Podagorsk and rarely saw more than one metre of error, most units were below 0.5m difference when moving which can easily be "measurement error".

Not seen any other feedback from anyone else that's relevant to this specific issue.

Updated by Suma over 2 years ago

  • Status changed from Assigned to Resolved

Marking as resolved, and I think it can be marked as Closed soon if there are no objections.

Updated by Xeno over 2 years ago

zx64 wrote:

Not seen any other feedback from anyone else that's relevant to this specific issue.

Probably because the feature itself is not much usable outside closed groups in its current stage. And except one closed group no other group seems to invest time into it or is interested in it.

Updated by SavageCDN over 2 years ago

We are most interested and have the servers to do it with... just not the time at the moment.

Updated by zx64 over 2 years ago

One final thing, the server optimisations have been really beneficial for improving the AI's performance in unmodified coops, even with 70ish players on and it has made our adversarial missions smoother too.
Many thanks for that.

Updated by tonci87 over 2 years ago

We are very interested, the new feature just lacks proper documentation/Setup Turtorial

Updated by kju over 2 years ago

The lack of information/documentation and sharing of those already know about it, is the main problem.

Updated by Suma over 2 years ago

  • Assignee deleted (Suma)

Updated by dslyecxi over 2 years ago

  • Status changed from Resolved to Closed

Closing this, we've seen no issues since the last bugfix.

Also available in: Atom PDF