Like I said, if on server, you do a
object1 setVariable ["object1_data", 3]
publicVariable "object1"
on a client, object1 getVariable "object1_data" should be objNull, because when you publicVariable an object, the variables attached to it are NOT passed.
You could, though, try to publicVariable the data themselves. But if it is to keep track of Mandoble missiles positions, velocity, etc... in real time in a loop, I would advise against that as it could very fast overload the network.
Now, why do you need this? To be sure that Mandoble scripts give the correct trajectories in MP to the projectiles?
In which case the problem is rather simple. I've not dug deep into Mandoble's scripts, just used them a few time (superb work, btw), but I guess he's using combinations of setPos, setVelocity, etc....
If you read the "Locality in MP" Biki article, you see that every object is local to one, and only one, PC on the game (PC can be the server
)
Being "local to PC P" means that decision on "what will object X do in the next frame?" is taken by P, and not any other PC in the MP game. Object can be a AI, in which case the PC where this AI is local will decide on the AI behavior (turn, run, aim here, fire, ....) then broadcast this information to all the clients and server so that all are aware of it and can render it synchronised.
Object can also be a bullet, for which trajectory must be calculated, by the PC where bullet is local, then positionnal and vector information is passed so that other PCs can render the bullet.
If a PC tries to "force the decision" for an object not local, it will not work. I guess for certain commands it can work somehow, but at the next frame, synchronization will be done again, and it will be re-synchronized with the situation on the PC where object is truely local.
As far as I've seen, each time I tried to setPos an object not local, or moveInCargo an AI not local, it never worked.
You can see the "re-sync" effect in action rather easily : make a mission with 1 player named "unit1", and 1 AI named "unit2", not grouped to player. Put 2 radio triggers, repetitive, the 1st doing "selectPlayer unit1"; the second doing "selectPlayer unit2". Save as MP mission
launch a dedicated server, then a client and connect to local dedi server. launch game. "Unit1" (player unit) is local to player's PC, of course. "Unit2" is local to the server, because it's not in player's group.
Then use radio 2 to switch to unit "unit2". By doing this, "unit2" is still "local to server", there is no transfert of locality. Try to move your character. It will move, then will quickly be switched back to its original position (re-synchronised with server's version of this unit). It's a very strange, but quite funny effect :p
I've not tested yet (but I'll do right after this post
), but my guess would be this :
when you make a AI unit join the player's group, this AI becomes local to player's PC (because it's in player's group), there is, this time, transfer of locality between server and PC. So, if, before doing the selectPlayer "unit2" in radio 2, I make unit2 join the player's group, then I launch the selectPlayer, I should not see any re-synchro effect occuring.
Anyway, I wouldn't bother too much about Mandoble's script. I would perhaps just check as much as I can that they are launched on PC where the guided missile/bomb/etc... is local.
As for Sickboy's use of "private", I think it's unrelated to MP locality issues, it's more about being sure of variable's scope in his scripts, which is another tricky subject, that has appeared with ArmA SQF. I've had much more problems in ArmA scripts because of variable scope issues than because of MP locality issues, lately.