Yes, but did it respawn the second time you deserted it?

I'm running 1.76.142872 and it is not fixed. Both the problem and solution (now tested and verified) is like above.

The problem of vehicles only being desertable once seems to result from an undesirable interaction between lines 183-184:

This behaviour has existed in all the OPF/Arma games. You start with a specific rating, 0 for private, more if you are say, a major.

Killing enemies raise your rating. Destroy friends (or friendly equipment) lowers your rating. Your rating gets low enough and your are no longer BLUFOR or whatever you were before but are instead a Renegade, a faction that everybody is enemies with (including other renegades I think). Killing men lowers your rating a bit, killing vehicles lowers it much more.

If you find threads where people request a civilian hit counter they are sometimes baffled that it stops counting after a couple of civilians. That is because their scripts checks to see whether the killer was, say BLUFOR, and then increment the count. However, after some kills you become renegade so the counter stops for you.

In my missions I always add the following to my init to prevent this issue:
player addRating 999999;

You don't need to join the unit in the first syntax.

[quote]perhaps most people don't mix soldierclasses and sides, so nobody cares.
[/quote]
Well I care, but don't agree with your conclusions. I think the second syntax is broken.

Basically everything is a mess with sides. It is the side of the group that determines who is enemy and who is friend. But the side of the unit determines how it appears on the map and whether the 'built-in' trigger conditions apply.

Even having sides on a units themselves doesn't make sense. You can put civilian, blufor. opfor and independent units in the same group and they fight together, so why bother having sides on units; why not just limit sides to groups?

I think BI should completely restructure the side/factions system (for Arma 4, probably too late for 3 now), so that you can decide which factions are on which sides for a mission. Its a complete mess to create a joint NATO-Soviet mission at the moment.

This is affected very much by the terrain detail settings. If you look at a very steep hill and you set your terrain detail to low (e.g. setTerrainGrid 50) then terrain vertices are 'clipped away'. Depending on the location sometimes the tip of the hill is clipped of leaving anything near the top hovering in air.

I've done some thorough testing with synchronization and respawn and jip.

Setup:

Player, called 'TheLeader' is synchronized to grouped AI 'Subordinate' and ungrouped AI 'OtherDude' and object 'AnObject'. Two radio triggers, 'Client Perspective', and 'Server Perspective', hints what TheLeader (the player) is synchronized to, ServerPerspective using publicVariable to send it to player machine.

Third radio trigger resyncs TheLeader with all three units/objects. Basic respawn using 'base' is also incorporated. Finally another unit, HostedServerUnit, neither synced nor grouped to anything used to launch a hosted server.

Results:

Singleplayer:
Server Perspective: TheLeader synchronized to all 3 objects.
Client Perspective: TheLeader synchronized to all 3 objects.

Multiplayer:

Hosted Server (player join at start):
Server Perspective: TheLeader synchronized to all 3 objects.
Client Perspective: TheLeader is NOT synchronized to anything!

Hosted Server (player respawns):
Server Perspective: TheLeader synchronized to all 3 objects.
Client Perspective: TheLeader is NOT synchronized to anything!

Hosted Server (player JIPs):
Server Perspective: TheLeader is NOT synchronized to anything!
Client Perspective: TheLeader is NOT synchronized to anything!

Dedicated Server (player join at start):
Server Perspective: TheLeader synchronized to all 3 objects.
Client Perspective: TheLeader is NOT synchronized to anything!

Dedicated Server (player respawns):
Server Perspective: TheLeader synchronized to all 3 objects.
Client Perspective: TheLeader is NOT synchronized to anything!

Dedicated Server (player JIPs):
Server Perspective: TheLeader is NOT synchronized to anything!
Client Perspective: TheLeader is NOT synchronized to anything!

On respawn 'player' references another (new) object. This new object is attached to the name (editor name reference??) TheLeader. The old object reference is also attached to that editor name! That is both the old player object and the new player object is called 'TheLeader' if you output it, however, they are different objects. The new 'TheLeader' is synchronized to the objects, the old is no longer!.

Activating the resync triggers makes TheLeader syncronized to all 3 units again. (Since radio triggers run on all machines).

Issues:

Notice the symmetries in the cases for multiplayer.

Issues with modules and respawn are caused since player references another (new) object upon respawn. This new object is still synchronized on the server side, however, most module scripts will already have checked what they are synchronized to at this point.

Issues with modules and JIP are caused by JIP objects not being registered as synchronized. Even if they were the some module scripts will still have to be changed to check for new synchronizations. However, this would not suffice in JIP situations since you cannot discover any new synchronizations.

For proper respawn and JIP safe modules RE-synchronization needs to be implemented, at least on the serverside.

EDIT:
Should this be posted as a separate issue?

I think this is related to a problem with modules not fixed in Arma 2. This is some general issue with modules (tested some time ago in Arma 2):

• Most module scripts only do inititialization at start and only check what it is synchronized to at the beginning of the mission. The mission starts, the module check what it is synchronized to, and initializes. If something else is then later synchronized then it doesn't matter since the module has already checked what it is synced to.

• More severe. Synchronization only works in a limited fashion. Non-server players are only really synchronized at the beginning of the mission. If someone joins-in-progress (JIP) later, then it is not synchronized! Meaning synchronization lines are useless if you want to support JIP. I didn't actually test respawn but looks like the symptoms are the same as JIP.

Basically any module synced to a playable (or respawnable) object suffers from this, like High Commander, this (Task modules), support request (http://feedback.arma3.com/view.php?id=2547). I never really bother to use these kinds of module because of this. It is a real shame since I like the idea, however, they are inherently broken for (JIP and respawn). If the second point I made was fixed at least the community could create some useful modules.

---

One way to fix this could be to actually registers JIP and then raise some kind of event to be used by module scripters. Example in module script:
_myModuleObject addEventHandler ["Synchronized", {

//Add the unit to some internal list used by the script or something.
TAG_MyModule_Units set [count TAG_MyModule_Units, (_this select 0)];

}];

This is probably related to: http://feedback.arma3.com/view.php?id=2572