Bug #15222

units & allUnits are missing units on JIP clients after group changes

Added by Dr_Eyeball over 4 years ago. Updated about 4 years ago.

Status:Closed Start date:11/18/2010
Priority:Normal Due date:
Assignee:Dwarden % Done:

100%

Category:Scripting: Problem
Target version:1.57.76815
Affected ArmA II version:1.56.76134 First affected build:
Reproduced by another DH user:Yes First affected ArmA II version:
I am using some Mods:Yes Single / Multi Player?:
I am using:CO (A2+OA) BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

The commands: "units" & "allUnits" are missing certain units on any JIP clients if group changes have occured.

What I suspect is happening is that the JIP client can only see groups that existed by mission design, so I believe the problem lies with the designated group of each unit, not the units themselves, although to determine team members it obviously depends on groups being correct.

The problem affects developing any form of a basic squad management systems (joining/leaving groups).

  • Category: MP network objects (units/groups).
  • Related commands: join, joinSilent, selectLeader.
  • The problem is always reproducable.
  • Test mission supplied. Test mission uses some AI slots, but they could be changed to playerable slots.
  • No players are dead during this test, which is a known limitation of some of these commands.
  • You need at least 2 players.
  • The non-JIP clients will see everything correctly. Only the JIP client is affected.
  • It doesn't affect things like triggers, but the general side effects to any missions using the "units" command could be drastic.

Workarounds:
It's fairly easy to work around the bug to simulate groups, but that would mean either losing or having to totally replicate any group/unit functionality that already exists for other commands (eg: waypoints, etc).

Example scenario:
  • Mission has multiple player slots, each in their own group.
  • 6 players join: p1,p2,p3,p4,p5,p6
  • player p2 joins group p1
  • player p4 joins group p3
  • player p6 disconnects from server (exits mission, then exits MP lobby)
  • player p6 reconnects, same slot (or probably any player slot)
  • player p6 will now not see 2 of the units and some 2 player groups will now appear to have 1 player.

I have included a very basic mod independent test mission which logs the output to the log.

I wanted to get some early feedback on what people already know about this. I have never read about this problem anywhere, but the more people I talk to, the more who seem to know about it but couldn't/didn't isolate the cause or report it. I also heard players have apparently seen the same problem in Team Status Dialog from Domination, but it was never mentioned.

As a minimum, the "units" command should be fixed, since you can work around not using allUnits & allGroups by using triggers.

Test Results:

Errors are marked as "ERROR:"

Player p1 joins.
Player p6 joins.
Mission started.
which results in the following log output, which is all entirely correct.

    43521    Starting: test_unitsBug
    43522    == 1 ========================
    43523    allUnits=[p1,p2,p3,p4,p5,p6]
    43524    allGroups=[B 1-1-A,B 1-1-B,B 1-1-C,B 1-1-D,B 1-1-E,B 1-1-F]
    43525    
    43526    forEach allGroups:
    43527    group=B 1-1-A, units=[p1,p2]
    43528    group=B 1-1-B, units=[]
    43529    group=B 1-1-C, units=[p3,p4]
    43530    group=B 1-1-D, units=[]
    43531    group=B 1-1-E, units=[p5]
    43532    group=B 1-1-F, units=[p6]
    43533    
    43534    forEach _units:
    43535    unit=p1, group=B 1-1-A, units=[p1,p2], isPlayer=true
    43536    unit=p2, group=B 1-1-A, units=[p1,p2], isPlayer=false
    43537    unit=p3, group=B 1-1-C, units=[p3,p4], isPlayer=false
    43538    unit=p4, group=B 1-1-C, units=[p3,p4], isPlayer=false
    43539    unit=p5, group=B 1-1-E, units=[p5], isPlayer=false
    43540    unit=p6, group=B 1-1-F, units=[p6], isPlayer=true
    43541    == 2 ========================

server will now execute:
    [p2] join p1;
    [p4] join p3;

    43542    == 3 ========================
    43543    allUnits=[p1,p2,p3,p4,p5,p6]
    43544    allGroups=[B 1-1-A,B 1-1-B,B 1-1-C,B 1-1-D,B 1-1-E,B 1-1-F]
    43545    
    43546    forEach allGroups:
    43547    group=B 1-1-A, units=[p1,p2]
    43548    group=B 1-1-B, units=[]
    43549    group=B 1-1-C, units=[p3,p4]
    43550    group=B 1-1-D, units=[]
    43551    group=B 1-1-E, units=[p5]
    43552    group=B 1-1-F, units=[p6]
    43553    
    43554    forEach _units:
    43555    unit=p1, group=B 1-1-A, units=[p1,p2], isPlayer=true
    43556    unit=p2, group=B 1-1-A, units=[p1,p2], isPlayer=false
    43557    unit=p3, group=B 1-1-C, units=[p3,p4], isPlayer=false
    43558    unit=p4, group=B 1-1-C, units=[p3,p4], isPlayer=false
    43559    unit=p5, group=B 1-1-E, units=[p5], isPlayer=false
    43560    unit=p6, group=B 1-1-F, units=[p6], isPlayer=true
    43561    == 4 ========================
    43562    Client: Object 3:1 (type Type_268) not found.
    43563    Client: Object 3:1 (type Type_268) not found.
    43564    Client: Object 3:1 (type Type_268) not found.

Player p6 disconnects entirely.
Player p6 reconnects into p6 slot.
which results in the following log output, which contains a bunch of errors, tagged with "ERROR"

    43565    Creating debriefing
    43568    == 1 ========================
    43569    allUnits=[p2,p4,p5,p6] - ERROR: should be [p1,p2,p3,p4,p5,p6] (allUnits command faulty)
    43570    allGroups=[B 1-1-A,B 1-1-C,B 1-1-E,B 1-1-F]
    43571    
    43572    forEach allGroups:
    43573    group=B 1-1-A, units=[p2] - ERROR: should be units=[p1,p2] (units command faulty)
    43574    group=B 1-1-C, units=[p4] - ERROR: should be units=[p3,p4] (units command faulty)
    43575    group=B 1-1-E, units=[p5]
    43576    group=B 1-1-F, units=[p6]
    43577    
    43578    forEach _units:
    43579    unit=p1, group=B 1-1-A, units=[p2], isPlayer=true - ERROR: should be units=[p1,p2] (units command faulty)
    43580    unit=p2, group=B 1-1-A, units=[p2], isPlayer=false - ERROR: should be units=[p1,p2] (units command faulty)
    43581    unit=p3, group=B 1-1-C, units=[p4], isPlayer=false - ERROR: should be units=[p3,p4] (units command faulty)
    43582    unit=p4, group=B 1-1-C, units=[p4], isPlayer=false - ERROR: should be units=[p3,p4] (units command faulty)
    43583    unit=p5, group=B 1-1-E, units=[p5], isPlayer=false
    43584    unit=p6, group=B 1-1-F, units=[p6], isPlayer=false - ERROR: isPlayer=true (new, never noticed that before)
    43585    == 2 ========================

no group changes or server changes are made, since server is still running.
the rest of this should be identicle to the part just above.

    43586    == 3 ========================
    43587    allUnits=[p2,p4,p5,p6] - ERROR
    43588    allGroups=[B 1-1-A,B 1-1-C,B 1-1-E,B 1-1-F]
    43589    
    43590    forEach allGroups:
    43591    group=B 1-1-A, units=[p2] - ERROR
    43592    group=B 1-1-C, units=[p4] - ERROR
    43593    group=B 1-1-E, units=[p5]
    43594    group=B 1-1-F, units=[p6]
    43595    
    43596    forEach _units:
    43597    unit=p1, group=B 1-1-A, units=[p2], isPlayer=true - ERROR
    43598    unit=p2, group=B 1-1-A, units=[p2], isPlayer=false - ERROR
    43599    unit=p3, group=B 1-1-C, units=[p4], isPlayer=false - ERROR
    43600    unit=p4, group=B 1-1-C, units=[p4], isPlayer=false - ERROR
    43601    unit=p5, group=B 1-1-E, units=[p5], isPlayer=false
    43602    unit=p6, group=B 1-1-F, units=[p6], isPlayer=false - ERROR
    43603    == 4 ========================

test_unitsBug.Takistan.pbo - test mission to reproduce units JIP bug (4.6 kB) Dr_Eyeball, 11/18/2010 04:11


Related issues

related to ARMA2 Community Issue Tracker - Bug #15198: Error Type_268 filling up the buffer Closed 11/17/2010

History

Updated by Dr_Eyeball over 4 years ago

Extra info/corrections to above info:
  • It looks like you can replicate the problem with just 1 player using a dedicated server and 1 client.

Alternative simplified example scenario:

  • 1 player joins either: slot 1 (p1), or slot 3 (p6)
  • player disconnects back to MP Setup lobby (seems sufficient, no need to exit, but exiting would be the more likely case)
  • player rejoins using same slot or other slot (p1 or p6), (or probably any player slot)
  • player will now not see 2 of the units and some 2 player groups will now appear to have 1 player (as in previous scenario).

Also, it seems to cause this kind of error a lot:

Client: Object 2:95 (type Type_268) not found.

I don't know what the Type_268 codes mean. Can't find any reference for their meaning.
(Same codes are used in mpStatistics.log so it would be good to know their meaning.)

Updated by Sickboy over 4 years ago

I can confirm the problem.

Re Type_268, see #15198

Updated by kju over 4 years ago

  • Due date set to 12/01/2010
  • Status changed from New to Assigned
  • Assignee set to Dwarden

Thanks

Updated by wormeaten over 4 years ago

Nice find Dr_Eyeball.
This bug bothering us in ArmA2 for long time but no one really localize it and be specific like you do.

This is major issue.

Thanks a lot Doc.

Updated by jaynus over 4 years ago

This is definitely a big deal. This is our one remaining ACRE-breaking bug with ACRE that we just cant fix with our addon; specifically it occurs massively inside Domi (for obvious reasons).

Would love to see this fixed before the PMC release - it would fix an amazing amounts of bugs across the board, in many addons.

Updated by defunkt over 4 years ago

I have encountered (or rather I have been tearing my hair out over) behaviours which I believe are probably related to this, in my case I have playable slots configured in groups under a non-playable squad leader, this was necessary to present identifiable squads in the mission lobby. As I don't actually want AI commanding players ("Get out of that tank!" - I'd love to see that removed too BTW) the players then leave that group with ([player] JoinSilent grpnull) on joining the mission.

Since defining this group structure in the mission I have noticed that during the course of the mission for no apparent reason some player entities are no-longer considered players by the server or even by the client still controlling them, IsPlayer returns false, Name returns an auto-generated AI name and they have 0 score. In testing this I am using unit = MissionNamespace GetVariable "WEST1"; to return a current reference to the playable entity where WEST1 is the unit's name as defined in mission.sqm. Different clients appear to see the player status for that unit differently at any given time (though the server and the controlling client usually agree). Our server log also contains a LOT of Client: Object 2:95 (type Type_268) not found messages for this mission.

Updated by Dwarden over 4 years ago

  • Target version set to Upcoming version

Updated by Rommel over 4 years ago

Also occurs with playableunits

Updated by kju over 4 years ago

  • Due date changed from 12/01/2010 to 03/01/2011
  • Affected ArmA II version changed from 1.55.75445 to 1.56.76134

Updated by Dwarden over 4 years ago

  • Status changed from Assigned to In progress
  • % Done changed from 0 to 50

Updated by Dwarden over 4 years ago

  • Target version changed from Upcoming version to Upcoming version OA
  • % Done changed from 50 to 90

fixed most of issues since build 76709

except

43584 unit=p6, group=B 1-1-F, units=[p6], isPlayer=false - ERROR: isPlayer=true (new, never noticed that before)

this needs further investigation

@rommel please re-check playableunits too

Updated by Dwarden over 4 years ago

  • Status changed from In progress to Resolved
  • % Done changed from 90 to 100

so related to the above, that's there always (most likely but i can be wrong) and it's as intended
thus IsPlayer isn't working in init (e.g. player should not be able control his unit while reading briefing)

so unless someone objects that it was working before ... this is resolved

Updated by Dr_Eyeball over 4 years ago

Good news. That's a major one.
A quick test with 1 player & a dedi using supplied mission indicates it works.
Will test more thoroughly in the coming days.

The only difference noticed was that the returned list of units wasn't sorted anymore, but can deal with that for now. Can't quite remember, but I think this is one of the commands that normally sorts the result. It just means that any displayed information won't be in the most logical order.

Regarding:
43584 unit=p6, group=B 1-1-F, units=[p6], isPlayer=false - ERROR: isPlayer=true (new, never noticed that before)
it was just an on the spot observation during reporting and I didn't post an update to indicate it was probably just due to 'player' value not being ready during JIP, which is normal behaviour. Sorry about that.

Updated by kju over 4 years ago

  • Due date deleted (03/01/2011)
  • Target version changed from Upcoming version OA to 1.57.76815

Please confirm fixed in 1.57.

Updated by kju about 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF