-
-
Notifications
You must be signed in to change notification settings - Fork 499
Object sync - fixes and improvements #3405
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't need to sync static data
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Data is only sent if it has changed. If the object is created on the server side, you must first get its properties, which are available on the client side, otherwise the properties on the server and client side would be different
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But why do we need that?
If you create object on server, you should change properties on server.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is illogical. When creating an object on the server side, its properties will be default (-1, zero vector), and on the client side the properties will have some values.
When we create a vehicle on the server side, it also has handling, plate and other data just like on the client side. It's as if upgrades were only on the client side by default, and there were no upgrades on the server side because they had to be set on the server side as well.
This is strange behavior imo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When creating an object on the server side, its properties will be default (-1, zero vector)
So server should have a config. All object properties should be available for a new object immediately.
When we create a vehicle on the server side, it also has handling, plate and other data just like on the client side.
Server has configs for that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, your solution adds uninitialized state for server objects. So it's much complex, that the solution with serverside config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is normal behavior. The object has its properties set at the time of synchronization and this is normal, because on the client side if the object is not streamed, its properties are also default (-1, zero vector). The properties have the appropriate values when the object is streamed, and if the object is streamed, there is a good chance that it is also synchronized. I don't understand why you should complicate such a trivial thing as object properties. If this is really such a bad way, then I will remove access to the server-side properties, because implementing the same in a more difficult way requires investigation and a lot of work for the same effect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not normal and unnecessary complex
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not normal and unnecessary complex
Adding feedback label due to this, cc @FileEX to please provide counterarguments or chat with eachother in dev discord about your POV's. Only after that comes to a conclusion, this can be marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will work on it. Now I'm breaking the entire PR into several smaller ones to make it easier to review. One of them is already ready and waiting to be merged #3450
Ok, this is quite a large PR, so I decided to split it into several smaller PRs to make the review easier.
Maybe split this work into:
- Health and broken state of object sync.
- Position, velocity sync.
- Server controlled object properties.
This draft pull request is stale because it has been open for at least 90 days with no activity. Please continue on your draft pull request or it will be closed in 30 days automatically.
YSAFE
commented
Jan 20, 2025
Bump?
This draft pull request is stale because it has been open for at least 90 days with no activity. Please continue on your draft pull request or it will be closed in 30 days automatically.
This draft pull request was closed because it has been marked stale for 30 days with no activity.
Uh oh!
There was an error while loading. Please reload this page.
I undertook the repair and improvement of object synchronization, which has been disabled since 2011.
I was unable to reproduce the bugs described in #460
I realize that this is quite a big PR, so I will be very grateful for any kind of feedback and reliable tests to eliminate any bugs and to safely merge this PR. I tested everything myself on the local server and I don't have the opportunity to test it with other players, so I'm not sure if all the problems have been eliminated.
Changes
Fixes
New events
onObjectDamageevent based on synchronizationonObjectBreakevent based on synchronizationonObjectMoveStarteventonObjectMoveStopevent based on synchronizationChanges
setObjectProperty,getObjectPropertygetElementVelocity&getElementAngularVeloityfunctions for objects on the server-sideisElementInWaterfunction for objects (shared)eObjectPropertyenum to the sharedResolved issues: #460, #2752, #386 (probably)
Parts of this PR: