The texture persists for units but not vehicles.

Create offroad and change texture on it, log out log in, old texture is back
Create another unit and change texture on it, log out log in, new texture is in place.

Here is the video: http://www.youtube.com/watch?v=cpm_Mn02nUQ

BTW Backpack texture is also NOT JIP compatible

Are you spawning the vehicles by script? Could you add the mission?

I have a problem to reproduce the issue.
What I did:

1. In editor, placed two playable soldiers and two vehicles (offroad).
2. started the game, joined by client
3. client used setObjectTextureGlobal on offroad -> texture changed for both players.
4. client leaves the session, reconnects, offroad has new texture.

@George

Try it with B_G_Offroad_01_armed_F

I retested it and it works with civ offroad but still fails with B_G_Offroad_01_armed_F

Also have you tried it with Backpacks. It doesn't seem to work with backpacks either. I haven't tested it with more objects, but I have sneaky suspicion it will be hit and miss too.

@George

I've done some other tests. I have spawned vehicles and immediately changed their textures. It worked for some. Some vehicles changed textures for a split second then went to default textures. Some never changed.

_car = "B_MRAP_01_gmg_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];
_car = "B_Quadbike_01_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];
_car = "B_Truck_01_transport_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];
_car = "B_UGV_01_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];
_car = "B_APC_Wheeled_01_cannon_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];
_car = "I_MRAP_03_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];

The above all changed textures immediately and remained JIP compatible.

_car = "B_G_Van_01_transport_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];
_car = "C_Offroad_01_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];
_car = "C_Hatchback_01_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];

The above changed textures for a split second then changed back to default. However when applied texture again separately would keep them for JIP

_car = "B_G_Offroad_01_F" createvehicle (player modelToWorld [0,10,0]); _car setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];

The above vehicle and its family never changed the texture not even for a split second. It would change texture if applied separately but would not keep it for JIP.

Thank you, I think I've found the problem, it's probably caused by init script that randomly changes the texture of the car (civil car, offroad...). The init scrip is called after the JIP messages are processed. I'll investigate more to confirm it.

@George

This still doesnt explain why backpack texture is not JIP. I think there are deeper issues at work here.

Quick test after today's update that claimed this issue fixed shows the same problem with armed offroad, texture doesn't stay.

It shouldn't be fixed yet, there are still some data changes that are not part of todays update. That list is generated from the code logs, there have been some changes in the code but to make it working completely, the init scripts for vehicles has to be changed as well.

BTW, I've been able to switch texture of the bag on the unit and it's JIP compatible. I was using the command:
backpackContainer player setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];

Backpack texture works

Ok, you have been a little bit faster than me :)

Not as fast as you are with your fixes! If only every one on dev team was that fast...

Resolved according to Dev CL.

LOL, since when are we marking issues resolved based on CL? It is not resolved.

Reopening, waiting for confirmation when new version will be released.

Should be fixed with game version greater than 113136 and addons with version greater than 60403 (soft_f, soft_f_beta, soft_f_gamma, could be found in rpt).

I'm always resolving based on developer/CL statements. You can still give feedback, but only if you're polite (hint!).

OTOH I'm only closing it, if it's confirmed.

I think feedback is more appropriate after it is marked resolved on CL i.e. need retesting.

As long we don't have committed community members re-testing everything immediately after something's announced resolved, I'll go down the path and resolve tickets immediately.

Many times there will be no feedback and tickets remain open indefinitely, if they're on "feedback". But if they're "resolved" and receive no feedback, we can safely assume that they're fixed for good and I will close them routinely using mass-close functions.

No worries, I'll monitor those tickets I set to resolved. I kindly ask you not to interfere by setting around states at will. George told you that the build isn't out yet, but the bug is supposedly resolved.

Dude, I could not close my own ticket if I wanted to let alone change the state of the ticket. Besides look at the log who changed what.

Edit what the? It says I chaged it to assigned? What is this sorcery?

fixed