Ability To Mark SyncVars Dirty

[AhmetDmr02]

Currently, SyncVar hooks are only called when the value is changed. This can lead to some issues on hooks if you're not familiar with how SyncVars work. I think it would be great to have the ability to mark them as 'dirty', so that even if the value is not changed, the hook will still be called. This would add more ways to implement a certain system, especially for board games that involve dice.

[FirstGearGames]

Why would you need the hook to call if the value hasn't changed though?

…

On Mon, May 1, 2023, 11:45 AM AhmetDmr02 ***@***.***> wrote: Currently, SyncVar hooks are only called when the value is changed. This can lead to some issues on hooks if you're not familiar with how SyncVars work. I think it would be great to have the ability to mark them as 'dirty', so that even if the value is not changed, the hook will still be called. This would add more ways to implement a certain system, especially for board games that involve dice. — Reply to this email directly, view it on GitHub <#353>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGPJC3QULZ6TAIBGFSQDCGLXD7LDNANCNFSM6AAAAAAXR4RZ2I> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[AhmetDmr02]

Let's say I'm making a board game and in my game, characters will move based on the dice roll. If a player rolls the dice and the value is the same as before, the client will not move the character because the hook is not called. This is a pretty basic example. Yes, it can be done with RPCs, but in my opinion, it's much cleaner with SyncVars. Additionally, it provides an alternative way to solve this kind of problem.

[FirstGearGames]

Gotcha. Use RPCs and if you want the last value send to late joiners use BufferLast on the RPC.

…

On Mon, May 1, 2023, 11:45 AM AhmetDmr02 ***@***.***> wrote: Currently, SyncVar hooks are only called when the value is changed. This can lead to some issues on hooks if you're not familiar with how SyncVars work. I think it would be great to have the ability to mark them as 'dirty', so that even if the value is not changed, the hook will still be called. This would add more ways to implement a certain system, especially for board games that involve dice. — Reply to this email directly, view it on GitHub <#353>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGPJC3QULZ6TAIBGFSQDCGLXD7LDNANCNFSM6AAAAAAXR4RZ2I> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[AhmetDmr02]

I actually ended up using RPCs in the end, but if I could mark SyncVars as dirty in the first place, it would be better and easier to implement for my codebase. However, I can understand your point.

[FirstGearGames]

You cannot directly access syncvars from user code since they're generated at compile time. I've been considering doing something about this for awhile now but haven't quite got around to it because it would either require the user declaring SyncVar as their variable, which isn't supported yet and makes the work flow harder for the user, as well because looking up the syncvar to dirty or alter isn't quite as simple.

The work flow would have to be something like this...

base.DirtySyncVar(nameof(_urSyncVarVariable));```

This could get costly if done frequently which is primarily why I have not implemented it yet. But just as such I could probably add in something of this sort...
```cs
[SyncVar]
private int _mySV;
private SyncBase _syncVarReference;

private void Awake()
{
   _syncVarReference = base.GetSyncBase(nameof(_mySV));
}

//some other part of code...
_syncVarReference.Dirty();```
The above would work and be just as efficient as it is now. Allowing the reference to be set could also let me expose other features of the sync type such as dynamic read permissions, interval, ect.

[AhmetDmr02]

Understood. I appreciate the response you provided. Thank you!

[FirstGearGames]

Per discussion here the rework/improved syncvar will have this feature. Because of this, the old syncvar will not be getting an update.
You can view the discussion here https://discord.com/channels/424284635074134018/1118545895764533359

Marking as denied because current syncvars will not be getting anymore enhancements, as the new technique for using syncvars will be considerably better (and include this feature).