synchronizedObjects will return an empty array if e.g. an empty vehicle is synced to another empty vehicle.
Description
Description
Details
Details
- Severity
- Major
- Resolution
- Open
- Reproducibility
- Always
- Operating System
- Windows 10 x64
- Category
- Eden Editor
Steps To Reproduce
- Place two empty vehicles
- Sync one vehicle to the other
- call synchronizedObjects vehicle1 from the debug console
Expected: vehicle2 is listed as a synced object
Observed: synchronizedObjects list is empty
Additional Information
Such restrictions do not make any sense. It prevents, for example, using synchronization as a means to couple the fate of one vehicle to another. For example, trying to destroy a barricade by having an invisible quad bike and syncing the quad bike to all parts of the barricade will not work since the result is an empty list. This is counterintuitive to the fact that the Eden Editor allows you to make such synchronization, it doesn't reject them.
Event Timeline
Comment Actions
If I remember correctly, this used to work in previous arma versions.
However it does not work anymore.
It is no longer not possible to use synchronizedObjects for empty vehicles or buildings.
This is an undocumented change and possibly a bug.
When syncing a game-logic to a building (or empty vehicle), synchronizedObjects will only return a non-empty array for the game-logic. This is a weird non-symmetric property that is not documented and used to work differently.
Comment Actions
Hello.
Thank you for the report. Talked to guys responsible for this and they say that this is "correct". There needs to be an AIBrain within an object for it to synchronize. At least one of the objects should be an AI or a game logic/module.
Comment Actions
Hi, thank you very much for looking into this!
I should probably rephrase this:
When syncing a game-logic to a building (or empty vehicle), synchronizedObjects will only return a non-empty array for the game-logic.
Assuming we have an ai_unit and a building.
When using something like ai_unit synchronizedObjects it will return [building],
however building synchronizedObjects will return an empty array even though "one of the objects" is an AI.
So this statement is not entirely correct:
At least one of the objects should be an AI or a game logic/module.
Even if this is the intended "correct" behaviour, it is
- not documented as such.
and
- the 3DEN command which is equivalent to synchronizedObjects get3DENConnections building select 1 returns [ai_unit].
So get3DENConnections does not need an object to have an AIBrain, whereas synchronizedObjects does.
I know that this behaviour will not change, however it would be nice to document the limitations of synchronizedObjects and define which object types have an AIBrain.
Comment Actions
Also, if this is intended behavior (which I don't really understand the reason for) then Eden should reject the synchronization, and not create one that will deliver a completely useless result.
Comment Actions
Only entities with AIBrain can hold information about synchronization. From this presumption comes the limitation - you cannot connect 2 objects without AIBrain and that's also why in your case synchronizedObjects ai_unit works, but synchronizedObjects building does not. Checking the https://community.bistudio.com/wiki/synchronizedObjects there is clearly stated unit not object.
About get3DENConnections it is a different case. The command works only in EDEN, where the info is stored differently, I guess. Check the wiki, you can even create your own connection types (synchronization is only one of the possibilities). However if you need to read the connection data during the scenario runtime, you need to use synchronization. Custom EDEN connections cannot be accessed outside of EDEN and so you need to abide the limitations about the AIBrain.
As Wulf properly stated, the only entities that have the AIBrain are units and game logics and modules.