setElementSyncer

[Kayl]

A little while ago, before 1.0.4 was released, I was asked on IRC to see how well setElementSyncer worked by myself.

Since I didn't really want to try a non official release, I waited for 1.0.4 to be out.

Now that it's out.

I tried the following (server side) test:

local g_SyncTestData = nil
function syncTest(player, cmd)
local x, y, z = getElementPosition(player)
z = z + 3
if g_SyncTestData then
destroyElement(g_SyncTestData.object)
	g_SyncTestData = nil
end
g_SyncTestData = {}
g_SyncTestData.object = createObject(3082, x, y, z)
local bSyncerOk = setElementSyncer(g_SyncTestData.object, player)
if not bSyncerOk then
outputChatBox("setElementSyncer failed")
else
outputChatBox("setElementSyncer worked")
end
local syncer = getElementSyncer(g_SyncTestData.object)
outputChatBox(string.format("Syncer: %s", (syncer and getPlayerName(syncer)) or "N/A"))
end
addCommandHandler("sync", syncTest)

Problem 1: I was highly disappointed when I saw "setElementSyncer failed" in the chatbox.

Problem 2: I tried also with a vehicle and noticed that the syncer goes away by itself (onElementStopSync) way before the vehicle is actually streamed out for the syncer.

What's wrong with it?

[eAi]

setElementSyncer is only supported on peds and vehicles. Objects aren't synced by players (I believe).

The range that the sync happens at isn't the range that the element is streamed in - these are independent.

Vehicles are synced within 130m of the player, peds within 100m of the player.

[Kayl]

Ok thanks for the details on the vehicles and peds.

As for the objects I'm a bit disappointed but I guess I can live with it.

Is there any plan on doing it also on objects?

Because right now, we can emulate this from script with an invisible "rc cam" (for instance) to which the object we want to sync is attached. Then moving the rc cam client side will move the object too. But that's an ugly hack.

[eAi]

I don't really see why objects couldn't be synced in the same way - there might be issues when there are large numbers of them, say a stack of falling barrels.

[Kayl]

So, I have done more tests with setElementSyncer.

It indeed works in theory. When used, the syncer indeed can affect the position of an unoccupied vehicle directly from clientside code and others players can see the changes.

However in practice, I find that the sync of such vehicle is way off compared to the sync of the normal vehicles (controlled by distant players).

I have made a video to show the difference:

And the resource used can be found here http://www.megaupload.com/?d=MOXFS9U5

/sync to start syncing a ghost that is the copy of the vehicle you are in with 1.5 s delay (sync pos, rotation, velocity, turnvelocity).

As you can see in the video, in case 2, even if both vehicles are synced by the same distant player, the unoccupied one (setElementSyncer) is really poorly synced.

I'm not familiar with MTA code and I would like to stay on the resource creator side, but looking at SyncStructures.h and SUnoccupiedVehicleSync I can see that other parameters (rotation, velocity, turn velocity) are indeed considered. But are they correctly synced?

Are they synced as often as normal vehicle parameters?

Are they correctly interpolated?

From a resource creator point of view, using it seems setElementSyncer could/should provide a vehicle sync as good as normal vehicles. Any clues as to why it's not the case?

Thanks in advance.

On an other but related topic, if you use destroyElement(source) in an event handler for onElementStopSync (for instance removing an object when nobody is syncing it anymore) crashes the server. But I might post a bug on mantis about that.

My main concern here is the bad sync.

[Kayl]

I know bumping our own topic is not regarded as a good thing.

However I have spent time creating a test resource JUST to show the problem I have (or anyone using setElementSyncer would have) and also took some time making a video about it.

I would appreciate some feedback from MTA team about the status of the sync of non occupied vehicles.

[Gamesnert]

For as far as I know, it has yet to be reported at the bug tracker. You have an higher chance of getting this issue on the 1.1 TODO list if it's actually on there. I think you should try putting a ped behind the steering wheel, see if it improves anything. If it does not, you should report that peds should have more synchronization in a vehicle. You don't need a lot of sync with an unoccupied vehicle, as it's only a waste of valuable bandwidth. With a ped in it, however, it's usually your intention to actually make it drive, so the sync should be improved for peds.

And I think the unoccupied vehicle syncer syncs the correct data, but at a very slow rate. As I said before, unoccupied vehicles are usually just vehicle which are just sitting around, not doing much except for maybe driving down the hill because somebody forgot the handbrake. So it's usually simply not necessary to sync unoccupied vehicles in a not-poor way.

setElementSyncer won't create (much) better results, because they're still "unoccupied" vehicles. And MTA doesn't really care who the syncer is. All setElementSyncer does, is allowing the scripter to decide who syncs the vehicle. But MTA automatically picks a syncer by default. So it doesn't improve the sync a lot.

[Kayl]

Fair enough that might be a logical reason for it.

Thank you for explaining the sync policy with regards to unoccupied vehicles.

I have updated the test resource: http://www.megaupload.com/?d=J3PGQD1B

Now there is a ped driving the vehicle.

I haven't modified it so as to make the ped really use inputs and actually drive.

I'm only interested in the actual position/rotation/velocity in order to sync vehicles that don't obey normal GTA driving laws.

And I'm saddened to say that this didn't change anything.

I'll report this as a bug as you suggested even though I have already 3 tickets on mantis that are fairly ignored so I have doubts about this new request being considered at all.