Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

name other_player == "Error: No unit" #1096

Open
aeroson opened this issue Aug 7, 2016 · 11 comments

Comments

Projects
None yet
4 participants
@aeroson
Copy link
Contributor

commented Aug 7, 2016

Sometimes for some client computers, the following is true.

{ name _x == "Error: No unit" } count allPlayers > 0

This results in some clients hearing some players as if they had TFAR disabled.
For the affected clients, this happens:

name bugged_player == "Error: No unit"
isPlayer bugged_player == false  // for this reason isPlayer should not be used
bugged_player in allPlayers == true // this should be used everywhere instead of isPlayer

TFAR thinks bugged_player is not a player and thus not sends his position to plugin.
So i recommend we make new function TFAR_fnc_isPlayer which uses _x in allPlayers and use that everywhere instead of isPlayer.

related #95 ?

@aeroson aeroson changed the title Error: No unit name other_player == "Error: No unit" Aug 7, 2016

@commy2

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2016

name is a very broken command in Arma 3. It will print error messages if the target unit is dead. It will also fail to report a valid name and print "Error: No unit" if the unit is dead for a certain amount of time or when executed in the same frame the unit was created
This last one could be the cause of this problem

@aeroson

This comment has been minimized.

Copy link
Contributor Author

commented Aug 8, 2016

In rare cases it seems that for some computers some players are bugged in this way:
name bugged_player == "Error: No unit" regardless of position, distance, respawn, time.
This happens during entire game session.
It seems to appear after bugged_player respawns.
It seems bugged_player can temporary fix it (until he respawns) by rejoining the server.
bugged_player is always fresh, taken from allPlayers.

Isn't the following expected to always be true ?
isPlayer bugged_player && bugged_player in allPlayers
For bugged_player it was false.

See: Code used & results

@commy2

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2016

As I said, the name command cannot be used in the frame the unit is created. This includes respawning.
The best would be to completely avoid relying on name (or vehicleVarName for that matter) in scripting and only use object references.

@aeroson

This comment has been minimized.

Copy link
Contributor Author

commented Aug 9, 2016

name command was used after the unit was created (unless one frame takes up several minutes, which is not the case since TFAR did change audio position of other players), the name command was used few times over several seconds, with the same result, the issue here is not name command

The issue is that every player in allPlayers command should (in my opinion) return true if used with isPlayer command, which is not the case, some of the allPlayers are actually not players according to isPlayer, that is the problem iam talking about.

Respawn was set to 0 seconds.
This does not happen just one single frame, it does happen continuously during entire 2 hour game.

@aeroson

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2016

Better report: this happens on Cloudstalker's PC, his PC just thinks Dennes is not a player, yet he is in allPlayers. The array was executed (on Cloudstalker's PC) then stored into setVeriable and then shown on my PC.

_x  =>  B Alpha 2-3:5 (Denness [AM 2FL]) REMOTE  
_x in allPlayers    =>  true
_x in allUnits  =>  false
_x in playableUnits =>  false
_x in (allMissionObjects "")    =>  true
typeof _x   =>  "B_Soldier_TL_F"
str _x  =>  "def1e040# 1686468: ia_soldier_01.p3d REMOTE"
name _x =>  "Error: No unit"
group _x    =>  <NULL-group>
side _x =>  WEST
uniform _x  =>  "AOR2_Camo"
weapons _x  =>  ["rhs_weap_hk416d10_m320","rhs_weap_m72a7","Laserdesignator_03"]
alive _x    =>  true
isPlayer _x =>  false
getPlayerUID _x =>  ""
backpack _x =>  "B_Parachute"
vest _x =>  "AOR2_Vest_1"
netId _x    =>  "32:76"
getPos _x   =>  [7903.53,13361.6,1.22747]
owner _x    =>  0

Notice the isPlayer _x and _x in allPlayer. Am I missing something ?

@dedmen

This comment has been minimized.

Copy link
Collaborator

commented Sep 15, 2016

_x in allPlayers can be a big performance problem with many players.
Are you experiencing this issue frequently? And are you running 0.9.11? (Currently only available on steam workshop)
So the problem here is not that "name player" returns "No Unit" the problem is isPlayer returns false.
We could work around that using "player in allPlayers" but.. Im not sure about the performance of that.
How often does this happen? This issue never happened to me in any bigger mission (10-40 players).
The only time i hear players as there werent using TFAR is when their Arma freezes/crashes and their Teamspeak looses connection to Arma.
This issue may be better placed at the Arma bugtracker than here. Can you please create an issue there if it doesnt exist yet?

@dedmen dedmen added the info needed label Sep 19, 2016

@dedmen

This comment has been minimized.

Copy link
Collaborator

commented Sep 12, 2017

Still experiencing this?

@aeroson

This comment has been minimized.

Copy link
Contributor Author

commented Sep 12, 2017

unknown,
didn't create any ticket in Arma bugtracker

@kripto202

This comment has been minimized.

Copy link

commented Sep 13, 2018

Recently been experiencing some people having error: no unit and they have to reload to have this fixed. There are others that doesn't see the issue and can talk to him normal. The ones that are affected, can't hear the person at all.

@aeroson

This comment has been minimized.

Copy link
Contributor Author

commented Sep 14, 2018

The two players that had this happen between them were real life located almost on the opposites of earth.
I think this has something to do with how Arma 3 optimizes it's network usage, like if the ping is too high and if the players are too far from each other ingame, it sends reduced player information.

@commy2

This comment has been minimized.

Copy link
Contributor

commented Sep 29, 2018

I think this has something to do with how Arma 3 optimizes it's network usage, like if the ping is too high and if the players are too far from each other ingame, it sends reduced player information.

No.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.