0003839: T-72/T-90 vehicle number is set to random value every time a player JIPs

(0007174)
reyhard (administrator)
2017-12-04 16:42

only T-72 & T-90?

(0007175)
BlackHawk (reporter)
2017-12-04 17:07

Just tested all AFR vehicles and indeed it's T-72 and T-90 variants only.

(0007176)
reyhard (administrator)
2017-12-04 17:21
edited on: 2017-12-04 17:22

Can you attach. Rpt from client and server? Is it in some specific scenario?

(0007178)
BlackHawk (reporter)
2017-12-04 19:22

yes. no.

(0007180)
reyhard (administrator)
2017-12-04 19:49

hm, is it complete log? it seems like it's missing JIP part

(0007181)
BlackHawk (reporter)
2017-12-04 20:30

It bugged out without needing to JIP (value was different than one I set in editor).

(0007182)
reyhard (administrator)
2017-12-04 20:43

so it's not JIP issue then? were you inside of vehicle?

(0007187)
BlackHawk (reporter)
2017-12-05 19:24

So I've been debugging and the problem turned out to be way more complex than I expected. I found multiple issues, I will tackle them one by one below.

1.
How the decal system is supposed to work: decals are assigned on server only, then displayed for everybody via setObjectTextureGlobal.
Reality is that vehicle's init script (t72_init.sqf, inits for other vehicles too, etc.) is ran for EVERYONE, not only machine local to the vehicle (due to problem mentioned on this page https://community.bistudio.com/wiki/local [^]). What does that mean? Every client on the server tries to generate and assign a vehicle number. Since Eden attributes are local only to the server, clients generate random decal number and then set it for everyone via setObjectTextureGlobal.

2.
Why are only T-72/T-90 affected?
In t72_init.sqf on line 33 rhs_fnc_decalsInit is SPAWNED instead of called like for other vehicles. Here's why it makes a difference: if code is called, it runs in the same frame, code that is spawned will be ran over possibly multiple frames. Due to the fact that for unaffected vehicles code setting decals runs so early, their setObjectTextureGlobal is ovewritten by one received from the server, since it's all happening in one frame. For T-72/T-90 code is spawned, so it runs a few frames after receiving texture from the server, thus overwriting it's results.
Decals for all vehicles are randomized too, but the numbers textures are overwritten by the server. (you can check it by running cursorTarget getVariable "RHS_randomNumber" on any vehicle in dedicated multiplayer environment)

How to fix?
Best way would be to make sure vehicle's init is ran only once. I recommend using isServer instead of local _vehicle, since setObjectTextureGlobal doesn't require it's argument to be local.

Please take note that all vehicles are affected by this issue, but appear to be working correctly due to coincidence. (server overwriting incorrect textures)

(0007188)
reyhard (administrator)
2017-12-05 21:29

"fixed" it temporarily by changing it to call since we don't enough time with 0.45 release on the horizion and using isServer seems to bit risky. I will try test it more later with isServer

(0007244)
reyhard (administrator)
2017-12-19 09:24
edited on: 2017-12-19 09:25

[Public] Entity locality is set before the init script call
soon in Arma (should be on tomorrow devbranch)

Notes
(0007174) reyhard (administrator) 2017-12-04 16:42	only T-72 & T-90?

(0007175) BlackHawk (reporter) 2017-12-04 17:07	Just tested all AFR vehicles and indeed it's T-72 and T-90 variants only.

(0007176) reyhard (administrator) 2017-12-04 17:21 edited on: 2017-12-04 17:22	Can you attach. Rpt from client and server? Is it in some specific scenario?

(0007178) BlackHawk (reporter) 2017-12-04 19:22	yes. no.

(0007180) reyhard (administrator) 2017-12-04 19:49	hm, is it complete log? it seems like it's missing JIP part

(0007181) BlackHawk (reporter) 2017-12-04 20:30	It bugged out without needing to JIP (value was different than one I set in editor).

(0007182) reyhard (administrator) 2017-12-04 20:43	so it's not JIP issue then? were you inside of vehicle?

(0007187) BlackHawk (reporter) 2017-12-05 19:24	So I've been debugging and the problem turned out to be way more complex than I expected. I found multiple issues, I will tackle them one by one below. 1. How the decal system is supposed to work: decals are assigned on server only, then displayed for everybody via setObjectTextureGlobal. Reality is that vehicle's init script (t72_init.sqf, inits for other vehicles too, etc.) is ran for EVERYONE, not only machine local to the vehicle (due to problem mentioned on this page https://community.bistudio.com/wiki/local [^]). What does that mean? Every client on the server tries to generate and assign a vehicle number. Since Eden attributes are local only to the server, clients generate random decal number and then set it for everyone via setObjectTextureGlobal. 2. Why are only T-72/T-90 affected? In t72_init.sqf on line 33 rhs_fnc_decalsInit is SPAWNED instead of called like for other vehicles. Here's why it makes a difference: if code is called, it runs in the same frame, code that is spawned will be ran over possibly multiple frames. Due to the fact that for unaffected vehicles code setting decals runs so early, their setObjectTextureGlobal is ovewritten by one received from the server, since it's all happening in one frame. For T-72/T-90 code is spawned, so it runs a few frames after receiving texture from the server, thus overwriting it's results. Decals for all vehicles are randomized too, but the numbers textures are overwritten by the server. (you can check it by running cursorTarget getVariable "RHS_randomNumber" on any vehicle in dedicated multiplayer environment) How to fix? Best way would be to make sure vehicle's init is ran only once. I recommend using isServer instead of local _vehicle, since setObjectTextureGlobal doesn't require it's argument to be local. Please take note that all vehicles are affected by this issue, but appear to be working correctly due to coincidence. (server overwriting incorrect textures)

(0007188) reyhard (administrator) 2017-12-05 21:29	"fixed" it temporarily by changing it to call since we don't enough time with 0.45 release on the horizion and using isServer seems to bit risky. I will try test it more later with isServer

(0007244) reyhard (administrator) 2017-12-19 09:24 edited on: 2017-12-19 09:25	[Public] Entity locality is set before the init script call soon in Arma (should be on tomorrow devbranch)

Issue History
Date Modified	Username	Field	Change
2017-12-04 16:08	BlackHawk	New Issue
2017-12-04 16:42	reyhard	Note Added: 0007174
2017-12-04 16:42	reyhard	Assigned To	=> reyhard
2017-12-04 16:42	reyhard	Status	new => feedback
2017-12-04 17:07	BlackHawk	Note Added: 0007175
2017-12-04 17:07	BlackHawk	Status	feedback => new
2017-12-04 17:21	reyhard	Note Added: 0007176
2017-12-04 17:21	reyhard	Status	new => feedback
2017-12-04 17:22	reyhard	Note Edited: 0007176	View Revisions
2017-12-04 19:21	BlackHawk	File Added: Arma3_x64_2017-12-04_19-14-15.rpt
2017-12-04 19:21	BlackHawk	File Added: arma3server_x64_2017-12-04_19-15-09.rpt
2017-12-04 19:22	BlackHawk	Note Added: 0007178
2017-12-04 19:22	BlackHawk	Status	feedback => new
2017-12-04 19:49	reyhard	Note Added: 0007180
2017-12-04 19:49	reyhard	Status	new => feedback
2017-12-04 20:30	BlackHawk	Note Added: 0007181
2017-12-04 20:30	BlackHawk	Status	feedback => new
2017-12-04 20:43	reyhard	Note Added: 0007182
2017-12-04 20:43	reyhard	Status	new => feedback
2017-12-05 19:24	BlackHawk	Note Added: 0007187
2017-12-05 19:24	BlackHawk	Status	feedback => new
2017-12-05 21:29	reyhard	Note Added: 0007188
2017-12-05 21:29	reyhard	Status	new => resolved
2017-12-05 21:29	reyhard	Fixed in Version	=> 0.4.5
2017-12-05 21:29	reyhard	Resolution	open => fixed
2017-12-19 09:24	reyhard	Note Added: 0007244
2017-12-19 09:25	reyhard	Note Edited: 0007244	View Revisions

Relationships