Page MenuHomeFeedback Tracker

setObjectTextureGlobal causing "Cannot load texture" errors when used with valid mission files
Closed, ResolvedPublic


When a server is running a mission directly from a bare folder (without a PBO), and for all Steam Workshop missions, using the setObjectTextureGlobal command from the server to assign a texture from the mission files always results in a "Cannot load texture" error being displayed to all players connected to the server and anyone joining later as well.

This problem is caused by the fact that setObjectTextureGlobal is broadcasting the raw server-side MPMissions path resolving to the texture, which for example looks like "mpmissions\MyMission.Altis\textures\image.jpg". However, for clients, the MPMissions path is different from the server; in the cases described above, it often ends up being "mpmissions\__CUR_MP.Altis".

Therefore, whenever clients receive a broadcast from setObjectTextureGlobal called from the server, the game tries to resolves textures in "mpmissions\MyMission.Altis", while they are located in "mpmissions\__CUR_MP.Altis", which causes the "Cannot load texture" error being displayed, and the affected vehicles looking partially invisible.


Legacy ID
Operating System
Windows 10 x64
Steps To Reproduce

Additional Information

Event Timeline

AgentRev edited Steps To Reproduce. (Show Details)Jan 15 2015, 2:36 AM
AgentRev edited Additional Information. (Show Details)
AgentRev set Category to Scripting.
AgentRev set Reproducibility to Always.
AgentRev set Severity to None.
AgentRev set Resolution to Open.
AgentRev set Legacy ID to 1965644343.May 7 2016, 8:05 PM

Related: #19132

AgentRev updated the task description. (Show Details)Jun 25 2016, 4:51 PM
AgentRev edited Steps To Reproduce. (Show Details)
AgentRev set Operating System to Windows 7.
AgentRev edited Steps To Reproduce. (Show Details)
AgentRev changed Operating System from Windows 7 to Windows 10 x64.
PiepMGI added a subscriber: PiepMGI.Aug 2 2016, 6:07 AM

Ah OK, finally I found this topic. Sorry for asking this question recently on BI forum. Problem known since January 2015 ?

I'm pretty sure BIS are not aware of it, seeing how they've been ignoring pretty much every bug report that isn't a crash.

Timo added a subscriber: Timo.May 10 2017, 1:36 PM
Timo removed a subscriber: Timo.

I confirm this is still happening. In my case it is affecting custom insignias. On the server it works fine for host player and any AI team members. That is, it gives no error and insignias look great in-game. However, clients connecting (via Steamworkshop) receive this error "Cannot load texture steammpmission\__CUR_MP.Altis".

Example below:

  1. vop.paa is in my mission root folder.

description.ext has:

class cfgUnitInsignia
class vop

		displayName = "Vortex_of_Pain"; // Name displayed in Arsenal
		author = "Rictor_Scale"; // Author displayed in Arsenal
		texture = "vop.paa"; // Image path
		textureVehicle = ""; // Does nothing currently, reserved for future use


  1. In the player initUnit.sqf called for each player locally I have:

[_unit,"vop"] call BIS_fnc_setUnitInsignia;

This should really be fixed at some point

BIS_fnc_KK added a subscriber: BIS_fnc_KK.EditedApr 4 2020, 11:30 AM

try using getMissionPath

AgentRev added a comment.EditedApr 4 2020, 11:47 AM

try using getMissionPath

This bug is solely caused by what the engine is doing behind the scenes, not the input fed to the script command... The engine must be altered to stop auto-prepending the mission path to the input string before global broadcast, and have the receiving clients resolve the mission path on their own when needed.

BIS_fnc_KK changed the task status from New to Assigned.
dedmen raised the priority of this task from Wishlist to Normal.Apr 6 2020, 12:15 PM

fixed in the next dev

dedmen changed the task status from Assigned to Feedback.May 18 2020, 10:42 AM
BIS_fnc_KK closed this task as Resolved.May 18 2020, 11:28 PM
snov added a subscriber: snov.Oct 17 2020, 11:36 AM

this change is causing issues when trying to set object textures as transparent e.g. _x setObjectTextureGlobal[0,""]
using a transparent .paa texture from mission file does not solve it since this is displayed as full-black

hideObject is working as an alternative for some cases, but this additional check is limiting mission makers ability to hide certain selections with ease

I assume this wasn't done intentionally, because it worked for several years in the past

will be hotfixed, it is fixed in internal already