Bug #19213

JIP players do not register on other clients at extreme ranges (6-10km+)

Added by jaynus over 4 years ago. Updated almost 3 years ago.

Status:Duplicate Start date:04/26/2011
Priority:High Due date:12/20/2011
Assignee:Suma % Done:

0%

Category:Multiplayer
Target version:-
Affected ArmA II version:1.60 BETA First affected build:
Reproduced by another DH user:Yes First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:MP Only
I am using:CO (OA+A2) BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

In scenarios where a player JIPs in at extreme range from other clients in the game, the current players in the game (non-JIP) who are far enough away will not register that play in playableUnits/allUnits.

repro steps:
1. Use the attached mission with 2 people.
2. Have the first person join the server, slot into the bottom slot, and then go all the way in game.
3. Have a second person then JIP, and slot into the top slot.
4. Once the JIP is all the way in, they will not register in allUnits/playableUnits until they run within a certain range of the other player.

The JIP player, however, does register all players currently in the game.

Tested with build 79600

jiptest_3.Chernarus.pbo - Example long-range JIP mission (2.4 kB) jaynus, 04/26/2011 19:57

jiptest_3.Takistan.rar (845 Bytes) ViperMaul, 12/19/2011 22:16


Related issues

related to ARMA2 Community Issue Tracker - Bug #7243: A2/OA - MP chat message author not visible. Duplicate 12/22/2009 06/01/2011
related to ARMA2 Community Issue Tracker - Bug #24898: When a player joins a server and spawns far away from oth... Closed 09/25/2011
related to ARMA2 Community Issue Tracker - Bug #14191: Object synchronization in Multiplayer at > 1.5km not prec... Closed 10/05/2010 12/01/2011
duplicates ARMA2 Community Issue Tracker - Bug #27200: JIP Players don't synchronise until they get close to you Closed 12/20/2011 12/20/2011
duplicated by ARMA2 Community Issue Tracker - Bug #18228: Randomly on JIP player objects fail to appropriately sync... Duplicate 03/13/2011 05/01/2011

History

Updated by jaynus over 4 years ago

Updating.

I believe this is also related to #18228

Updated by jaynus over 4 years ago

Oh. And #7243

Updated by Fireball over 4 years ago

  • Due date set to 07/26/2011
  • Status changed from New to Assigned
  • Assignee set to Dwarden

Good report, thanks!

Updated by Dwarden over 4 years ago

  • Priority changed from Normal to High
  • Target version set to Upcoming version
  • Reproduced by another DH user changed from No to Yes

Updated by jaynus about 4 years ago

As an addition to this - Because they do not register in allUnits/playableUnits, variables for the players also do not propagate. Example is that if you propagate the player object via a CBA event, the remote player will not see any variables on the object variables until it syncs correctly and enters the allUnits/playableUnits arrays.

Updated by Dwarden almost 4 years ago

  • Affected ArmA II version changed from 1.59 BETA to 1.60 BETA

Updated by Suma almost 4 years ago

Just as in #24898, I am unable to reproduce so far (build 86060). Does the repro really work with vanilla server / clients? Or perhaps the issue has expired somehow meanwhile?

if you propagate the player object via a CBA event

Perhaps it might be CBA/XEH related then (or to some older version of it)? See also http://dev-heaven.net/issues/25095#note-110:

1) The JIP delay turned out to be a XEH issue (extended_eventhandler.pbo).
Updating to the latest XEH.pbo seems to have worked

Updated by Suma almost 4 years ago

As I am debugging #24146 right now and I am learning more about how "playable" status is updated for units, I think it is quite likely it may be affected (not necessarily caused) by a combination of minErrorToSend and minErrorToSendNear settings, and it is quite possible having minErrorToSend=0.01 and minErrorToSendNear=0 could bring the previous behaviour back. I did not attempt to test this yet. If this does not show the issue, next thing would probably be to test some older version (1.59 stable first).

If anyone can spare some time experimenting with this (finding exact conditions when the issue shows, or finding which builds are affected), it will greatly help me fixing the issue.

Updated by kju almost 4 years ago

  • Due date changed from 07/26/2011 to 11/14/2011
  • Status changed from Assigned to Feedback
  • Assignee changed from Dwarden to jaynus
  • Target version deleted (Upcoming version)

Jay can you please retest and provide more details.

Updated by jaynus almost 4 years ago

I will be able to retest next week (cant this week, on the road traveling).

Updated by Nou over 3 years ago

I don't think Jay ever got around to testing this but I can confirm from some huge testing the last week involving long distance retransmission in ACRE that this still exists in at least in self-hosted RC1 and clients using beta 55882. Players that JIP into the game are unable to be recongized in ACRE functionality nor will they appear in things like groups (verified using the Shacktac HUD).

The players instantly become available and appear in the group as soon as people teleport or move within a close distance of them, but this needs to occur for each player that was at a remote spot when the non-existent player JIP'd in.

It is very easy to reproduce. Make a mission on a large map, put two people in your group and enable JIP. Have one player join the server, and start the mission. Wait for a little bit, then teleport or drive to the other side of the map. Have the next player JIP. Check the contents of the group and you will see that the play who JIP'd is no visible. Teleport or drive back within a kilometer or two and the player will exist again and stay.

THIS BUG IS ALSO REPLICATED WHEN A PLAYER RESPAWNS FAR AWAY!

Updated by Fireball over 3 years ago

  • Due date changed from 11/14/2011 to 12/20/2011
  • Status changed from Feedback to Assigned
  • Assignee changed from jaynus to Suma

I just reproed it easily using attached repro mission using two client instances of OA:

After JiP'ing the second client, I used copyToClipboard str allUnits on the host, and it shows only:

[B 1-1-A:1 (Fireball),B 1-1-B:1 REMOTE,B 1-1-C:1,B 1-1-C:2]

After I move all players to the same position (e.g. on host rEXEC player setPosATL (getPosATL player)):

[B 1-1-A:1 (Fireball),B 1-1-B:1 (Fireball (2)) REMOTE,B 1-1-C:1,B 1-1-C:2]

This is a mod- and mission-breaker and its unfortunate nobody responded until to date.

Updated by Sickboy over 3 years ago

player setPosATL (getPosATL player)
doesn't make a lot of sense: Set the Player to the Pos of the same Player? :D

Updated by Sickboy over 3 years ago

Suma wrote:

As I am debugging #24146 right now and I am learning more about how "playable" status is updated for units, I think it is quite likely it may be affected (not necessarily caused) by a combination of minErrorToSend and minErrorToSendNear settings, and it is quite possible having minErrorToSend=0.01 and minErrorToSendNear=0 could bring the previous behaviour back. I did not attempt to test this yet. If this does not show the issue, next thing would probably be to test some older version (1.59 stable first).

The ticket is 8 months old, and it's initial version was set to 1.59 (beta), so I believe this is not a new bug, though perhaps it has been amplified / behavior has changed in 1.60.
According to Nou, this problem has been around for a long time (unclear about exact start date, might even date back to A1).

Updated by jaynus over 3 years ago

Nou's explanation of this bug may be a regression caused by the new JIP/sync changes. Currently, the way we worked around this bug in acre is we propagate player objects via CBA events on JIP to compensate for the fact that playableUnits is always completely broken and incorrect. So we build our own.

If the behavior of actual object propagation (e.g. remote JIPs just don't HAVE that object we are passing via CBA events) than the behavior would re-exhibit itself. This might be exhibited by different behavior with variables and JIP prop that have now regressed due to latest beta changes.

Updated by Fireball over 3 years ago

Sickboy wrote:

player setPosATL (getPosATL player)
doesn't make a lot of sense: Set the Player to the Pos of the same Player? :D

Well, I know what you mean, but it worked for me somehow, as it seemed to use the position of the local player and used it on every player through MP framework.

Updated by Nou over 3 years ago

This bug also causes people who respawn far away to not be able to be heard when firing, even when they come back to the people that were far away from them at the time of respawn.

Updated by tyrspawn over 3 years ago

This is perhaps the most significant bug in ARMA 2 at this time.

We have been attempting to make workarounds for this bug for about a week at unitedoperations.net - it is impacting the quality of our events on islands which are larger than 8km or so.

Updated by jaynus over 3 years ago

Server configs below.

language="English";
adapter=-1;
3D_Performance=10000;
Resolution_W=160;
Resolution_H=120;
Resolution_Bpp=16;
viewDistance=10000;
MinBandwidth=10000000;
MaxBandwidth=2147483647;
MaxMsgSend=1024;
MaxSizeGuaranteed=1024;
MaxSizeNonguaranteed=64;
MinErrorToSend=0.0040000002;
maxCustomFileSize=0;
Windowed=0;

Updated by Dwarden over 3 years ago

  • Target version set to 1.60.87580
  • Single / Multi Player? set to MP Only

as i hear more and more complains about this issue:
is there even simpler repro case-mission than attached one ?

Updated by Sickboy over 3 years ago

Jaynus/Nou: Able to repro it with out any mods, just vanilla? Which beta versions specifically?
At least fireball seems to have though.

Dwarden wrote:

as i hear more and more complains about this issue:
is there even simpler repro case-mission than attached one ?

The attached one is an empty mission with 5 players in 3 groups - there is no simpler repro case-mission than that.
Have the developers tested it with the dedicated server settings Jaynus posted it?
AFAIK it's also reproducable with an ingame-server (non deddy).

Updated by Nou over 3 years ago

I have not tried sick, but Fireball sounds like he was able to easily.

Updated by Xeno over 3 years ago

I was also able to reproduce it with the attached mission without a problem.

I've also tried with disabledAI = 1, but the same result (even worse, while with the first version the second client did show up after some time without changing the position this did not happen in the disabledAI version at all, though it might be just pure luck that the second client showed up in playableUnits and allUnits in the first version).

Edit: server and clients were both using beta patch 87469, no special server config.

Edit2: Once the second client is connected a "name (allunits/playableunits select 1)" returns "Cameron Adams" instead of "Xeno (2)" (disabledAI = 1 version)

Edit3: Probably related (client) RPT entries:

Group B 1-1-B (0xeeccc700) - network ID 2:13
 - no main subgroup
Network simulation, time = 149.535
Group B 1-1-B (0xeeccc700) - network ID 2:13
 - no main subgroup
Group B 1-1-B (0xeeccc700) - network ID 2:13
 - no main subgroup
Group B 1-1-B (0xeeccc700) - network ID 2:13
 - no main subgroup
Group B 1-1-B (0xeeccc700) - network ID 2:13
 - no main subgroup
Group B 1-1-B (0xeeccc700) - network ID 2:13
 - no main subgroup
Group B 1-1-B (0xeeccc700) - network ID 2:13
 - no main subgroup

Edit4: If client one, who was connected right away from mission start, writes something in the chat it does not get displayed on the screen of the second (JIP) client. If the second client writes something the first client can read it but the name is missing (side chat).

Edit5: "isPlayer (allunits/playableunits select 1)" returns false on the first (non JIP) client. But that was to be expected when "name (allunits/playableunits select 1)" already returns an AI name.

Updated by ViperMaul over 3 years ago

As suggested by Dwarden, I converted the repo mission to Takistan.

Updated by Dwarden over 3 years ago

now one more important question: are the repros done on LAN or over some delay on internet (non-LAN) ?

Updated by Xeno over 3 years ago

At least my tests were done over LAN. Server and clients (up to 3 clients) running on the same machine, so no "internet delay".
I've tried about 6 times I guess (server and clients completely restarted after each test), always with the same result.

Edit: the only addon I've used was a modded gaia debug console with MP support (clients only).

Updated by zGuba over 3 years ago

#27200 should be new ticket for that issue.

Updated by Fireball over 3 years ago

  • Status changed from Assigned to Duplicate

Duping it then.

Updated by kju over 3 years ago

  • Target version deleted (1.60.87580)

Also available in: Atom PDF