There is a great deal of flexibility already built into the decorator system in GTAV, and the decorators are synced between clients.
Setting them server-side might not be practical, but for a great many uses it is enough to read decorators already set on entities.
My suggestion is that time is put into finding the decorator sync packets and making the information available server-side for OneSync servers.
An example use case is to issue a “ticket” to a client, like a permission to create one networked prop, and then have the client set that “ticket” as a decorator on the created object. The first sync of that object would then presumably carry this decorator, and it could be read by the server to verify that it is an approved networked prop creation.
The same thing goes for checking the location of a vehicle against some parking location, and if it has the decorator Player_Owner determines what player gets it returned to their “garage” (or whatever).
Decorators is still a very convenient way to tell what entities are relevant for certain things.
The use case might not be great, but the fact remains that Decorators are useful and are synced. Perhaps you’re right, and it is stupid, but I still think it would be very convenient to have access to reading decorators server-side.
Please don’t judge it as entirely stupid just because one of the use cases can be accomplished a different way.
The whole idea is to open up access to things server-side that the client can do, and that are already synced, right?
decors are horribly limited and even though parsing lots of game state is the goal i don’t think it’s a good thing to promote people using them even more especially when servers would be unable to set any state in a non-conflicting way themselves (as opposed to the state bag concept)