`NetworkList<T>` does not call `OnListChanged` with `ChangeEvent.Full`, making full changes untrackable.

[Yoraiz0r]

I recently hopped back for another NGO project, and am attempting to use a NetworkList<MyStruct> with a separate custom Tracker<MyStruct> class to make local behavior instances follow what the values in the NetworkList. In attempt to make sure all ChangeEvent types are handled correctly, I tried to figure out how to compare the new values to the old ones, when I stumbled upon a bigger problem reading the NetworkList's source....

It doesn't call OnListChanged with ChangeEvent.Full, ever.

I don't see any other callback either. It seems the only time this kind of event is called is if the list itself is Dirty. I don't know when will such a thing happen, but it concerns me that it is currently impossible to even know if the entire set of values in my list just ups and swaps itself.

The List itself does not seem to have a changed event for itself so there is no way to detect this Full change even separately...

Is there a way this could be better implemented on the whole? the goal is to have local stateful POCOs that are paired to each MyStruct in the list without needing to sync the POCOs.

Attached below is an example of a way this could work but as mentioned, EventType.Full is problematic...

I don't know if I'm missing something obvious but I've tried to read NetworkList's entire source, checked NetworkBehaviourBase for good measure, and went through the available documentation with no proper recourse on this problem. Help would be appreciated, please.

	public abstract class ANetworkListPairTracker<T> where  T : unmanaged, IEquatable<T>
	{
		public void Pair(NetworkList<T> list) => list.OnListChanged += TrackChange;
		public void Release(NetworkList<T> list) => list.OnListChanged -= TrackChange;

		private void TrackChange(NetworkListEvent<T> changeEvent)
		{
			switch (changeEvent.Type)
			{
				case NetworkListEvent<T>.EventType.Add:
				case NetworkListEvent<T>.EventType.Insert:
					Create(changeEvent.Index,  changeEvent.Value);
					break;
				case NetworkListEvent<T>.EventType.Remove:
				case NetworkListEvent<T>.EventType.RemoveAt:
					Remove(changeEvent.Index);
					break;
				case NetworkListEvent<T>.EventType.Value:
					Update(changeEvent.Index, changeEvent.Value);
					break;
				case NetworkListEvent<T>.EventType.Clear:
					Clear();
					break;
				case NetworkListEvent<T>.EventType.Full:
					// ???
					break;
			}
		}
		protected abstract void Create(int index, T record);
		protected abstract void Update(int index, T record);
		protected abstract void Remove(int index);
		protected abstract void Clear();
	}

	public class ExampleCardEffect
	{
		//details here
	}

	public class CardInstancePairTracker : ANetworkListPairTracker<CardRecord>
	{
		private List<ExampleCardEffect> _instances = new();
		private CardOwner _owner;

		public CardInstancePairTracker(CardOwner owner) => _owner = owner;

		protected override void Create(int index, CardRecord record)
		{
			var instance = CardFactory.CreateFrom(record.CardId);
			instance.SetOwner(_owner);
			_instances.Insert(index, instance);
		}

		protected override void Update(int index, CardRecord record)
		{
			if (_instances[index].TryUpdate(record))
				return;

			_instances[index].EndEffect();
			_instances[index] = CardFactory.CreateFrom(record.CardId);
			_instances[index].SetOwner(_owner);
		}

		protected override void Remove(int index)
		{
			_instances[index].EndEffect();
			_instances.RemoveAt(index);
		}

		protected override void Clear()
		{
			foreach (var instance in _instances)
				instance.EndEffect();
			_instances.Clear();
		}
	}

[Yoraiz0r]

Did further investigation,

I may be wrong - It seems that the only real situations in which you'd get a full event to happen for a NetworkList are

1. When the network object becomes visible
2. When the ownership changes

Realistically speaking, the name of the event is OnListChanged, and the contents of the list don't change in either of those circumstances - either it appears with all the elements included, or no meaningful change happens as far as the ownership swap goes. This only becomes problematic if the structs contains non-serialized and non-equatable fields, and wish to preserve them.

This also means that by binding to OnNetworkSpawn and on OnOwnershipChanged you can, at least, call updates to any auxiliary trackers on the NetworkList. It does mean more croft than just listening to the list resync, though.

If this assessment is correct, and is intentional, can anything be done to clarify that the Full enum of the change event type is not meant to be used with the event?

Alternatively, would it be desirable to have OnListChanged be called for Full when appearing on a network?

[NoelStephensUnity]

@Yoraiz0r
This is actually a pretty commonly requested feature to invoke any NetworkVariableBase derived class's OnValueChanged event upon the NetworkObject being spawned (or made "network visible") with the original implementation taking the approach that "relative" change only occurs after the NetworkObject has been spawned (and synchronized) on the client side with the general idea being:

• Prior to the NetworkObject spawning, the client has nothing to compare from (i.e. no instance exists)
• Upon the NetworkObject being spawned, the client is fully synchronized with the current state (including NetworkVariables/lists).
• Upon any change happening from that point forward, it would trigger the changed event.

This was the original design/intention, but doesn't mean it shouldn't be updated.

So, once the NetworkObject has been spawned on a client if you were to do a full NetworkList update one or two network ticks later then it should trigger the OnListChanged of type EventType.Full.

Just to confirm, do you see this behavior pattern on your side with your above implementation?

Regarding ownership changes:

either it appears with all the elements included, or no meaningful change happens as far as the ownership swap goes. This only becomes problematic if the structs contains non-serialized and non-equatable fields, and wish to preserve them.

As long as the NetworkObject is already visible to the new owner and the new owner is already synchronized, then there would be no notification of a change in the list (based on the exact logic you are using above). If there is additional information that is not serialized that you want to have synchronized then you would want to include that information within your INetworkSerializable implementations.

Some Side Notes:
While you can use classes that implement INetworkSerializable, I would (maybe this is a personal preference) always first consider using structs for that as opposed to classes as there are some that can be easily overlooked when using classes (i.e. gc allocation, etc.).

Always remember you can use collections (and nested collections) with NetworkVariable with the caveat that you need to invoke NetworkVariable<T>.CheckDirtyState after making modifications to assure it is marked dirty and will be updated.

[Yoraiz0r]

Just to confirm, do you see this behavior pattern on your side with your above implementation?

I've not ran code to check this thoroughly enough yet. I'm still struggling with a good way to properly verify that I am catching all dirty states that lead to the event of Type Full between trying to solve other problems in my project. 🙏 I'm not sure what the best approach would be short of locally editing the NetworkList source to include a separate invocation and see that it matches my own OnNetworkSpawn + OnOwnershipChanged calls to simulate the Full change call. I've not built enough scenarios to test owner visibility etc in the project to test it reliably.

.

If there is additional information that is not serialized that you want to have synchronized then you would want to include that information within your INetworkSerializable implementations.

I understand that, my concern is that if I have a state that is locally handled that exists within the INetworkSerializable structs, and, the Full event happens, it replaces my entire list of objects without giving me time or a spot to do anything with the extra state they store. I also understand it is a hacky maladaptive thing to have a struct that is not fully identical on the sender/receiver, hence wanting a separate tracker.

To clarify - part of the 'problem' with the above attempt is that whenever OnListChanged occurs, the underlying INetworkSerializable is already a fresh new copy per

                    case NetworkListEvent<T>.EventType.Value:
                        {
                            ByteUnpacker.ReadValueBitPacked(reader, out int index);
                            var value = new T();
                            NetworkVariableSerialization<T>.Serializer.Read(reader, ref value);
                            if (index >= m_List.Length)
                            {
                                throw new Exception("Shouldn't be here, index is higher than list length");
                            }

                            var previousValue = m_List[index];
                            m_List[index] = value;

                            if (OnListChanged != null)
                            {
                                OnListChanged(new NetworkListEvent<T>
                                {
                                    Type = eventType,
                                    Index = index,
                                    Value = value,
                                    PreviousValue = previousValue
                                });
                            }

Because m_List[index] = value; occurs before OnListChanged, then, any locally handled (that is, not synced) state will already have perished. There was some potential of transferring it in OnListChanged such that we could do

case NetworkListEvent<ElementType>.EventType.Add:
case NetworkListEvent<ElementType>.EventType.Insert:
case NetworkListEvent<ElementType>.EventType.Value:
    TheList[changeEvent.Index].LocallyHandledMember = changeEvent.PreviousValue.LocallyHandledMember;

Purely a hack, and foiled by the Full event not providing a list of previous values nor being called at all to user code on 2.2.0

.

always first consider using structs

Absolutely! It's why my example in the original post goes with NetworkList<MyStruct>! The POCO management from the CardInstancePairTracker is purely so that heavy stateful scripts don't have to be synced or live within the NetworkList but still are able to be paired to their proper owner index / see when it changes. The original complaint is that there are situations where its not possible to keep track (as with OnNetworkSpawn without explicitly signing up to do it in OnNetworkSpawn, without registering in multiple places, effectively)

.

NetworkVariable with the caveat that you need to invoke NetworkVariable.CheckDirtyState after making modifications to assure it is marked dirty and will be updated.

Doesn't using NetworkVariable make a full new collection in every dirty case though?

[NoelStephensUnity]

Doesn't using NetworkVariable make a full new collection in every dirty case though?

It does not. It will always try to do delta synchronization unless it doesn't make sense and then a full update is performed which results in a full collection update.

• For a list, it will try to perform a delta synchronization unless 90% (or greater) of the list has changed.
• For a hashset, it will try to perform a delta synchronization unless it determines that more has changed than the original item count.
• For a dictionary, it will try to perform a delta synchronization unless it determines that more has changed than the original item count.

Similar checks are performed for native collections too.

[NoelStephensUnity]

I understand that, my concern is that if I have a state that is locally handled that exists within the INetworkSerializable structs, and, the Full event happens, it replaces my entire list of objects without giving me time or a spot to do anything with the extra state they store. I also understand it is a hacky maladaptive thing to have a struct that is not fully identical on the sender/receiver, hence wanting a separate tracker.

Having additional state being stored within a NetworkList of INetworkSerializable structs per client instance that varies between client instances is definitely not recommended as it can lead to the kinds of issues you are experiencing. Depending upon the type of states you are storing, you might think about having a unique identifier per state item and creating an alternate "local state" per unique item and using a look up table (i.e. dictionary) to link the two. This way, if you get a full state update you just need to "re-link" the local state to the identifiers when a full state update occurs. For any new states discovered, you would create new local state. For any state (based on the unique identifier) that is no longer present after the full update you can either delete that from your local table or handle it some other way...but yeah if you are trying to keep different local state relative information on non-authority/non-write clients you could run into issues.

Of course, you can always take the source (as you noted) and make your own NetworkList type that provides you with some additional functionality specific to your use case.

We most likely would not make an adjustment to NetworkList for this kind of use case scenario as it goes outside of the recommended/intended use window.

[NoelStephensUnity]

We are going to close this support issue. If you have additional related issues or feel the response did not help you resolve your issue please feel free to re-open the issue.