Custom InnerNetObjects

[D1GQ]

Introducing Custom InnerNetObjects

---

This PR introduces a set of improvements to make working with custom InnerNetObject easier, and more intuitive. The changes include:

1. Comprehensive XML Documentation:

   • Added detailed documentation for key methods to improve code clarity and developer experience.
   • Examples and usage instructions are provided to help developers quickly integrate custom InnerNetObject prefabs.

2. Utility Methods for Prefab Handling:

   • Added methods like GetNetObjPrefab<T>, SpawnNewNetObject<T>, and SpawnNetObject to simplify the process of retrieving, instantiating, and spawning custom InnerNetObject prefabs.

---

Key Changes:

1. GetNetObjPrefab<T>

• Purpose: Retrieves the prefab for a custom InnerNetObject of type T.
• Usage:

  var prefab = InnerNetObjectManager.GetNetObjPrefab<MyCustomObject>();

2. SpawnNewNetObject<T>

• Purpose: Spawns a new InnerNetObject locally and on the network of type "T".
• Usage:

  var newObject = InnerNetObjectManager.SpawnNewNetObject<MyCustomObject>(ownerId: 1, spawnFlags: SpawnFlags.None);

3. SpawnNetObject<T> (Extension Method)

• Purpose: Spawns an existing InnerNetObject instance on the network.
• Usage:

  var existingObject = new MyCustomObject();
  existingObject.SpawnNetObject(ownerId: 1, spawnFlags: SpawnFlags.None);

---

[Pietrodjaowjao]

i just dont get the InnerNetObject attribute, it seems really unecessary since this can be done by checking subtypes in the assembly

[Galster-dev]

I think example class should be an actual simple example of what you can do with this instead of just a stub.

[D1GQ]

i just dont get the InnerNetObject attribute, it seems really unecessary since this can be done by checking subtypes in the assembly

The first reason is do to the issue with abstract monobehaviors and compiling it into il2cpp, second reason is I feel like it's more consistent using a attribute as the original class with Reactor, now I'm probably going to change the method of loading the prefab for it.

If y'all really want it to just be a custom subclass then I'll rework the logic.

[D1GQ]

i just dont get the InnerNetObject attribute, it seems really unecessary since this can be done by checking subtypes in the assembly

I've added some changes.

[miniduikboot]

Hey there, sorry for the lack of feedback. I've been busy and hoped other Reactor devs would've been active as well. I've read through the PR and made a few comments. I'm not fundamentally opposed to an API like this, but I think this has a few limitations that make it unsuitable for an environment where optional mods exist.

Let me know if you still want to push this PR forward

[miniduikboot]

Please handle the check warnings

[miniduikboot]

Why the decision to squash this error here? TOCTOU concerns?

InnerNetClient logs an error when AUClient.Instance.Spawn is called on clients

[D1GQ]

Thought it would be better to know that the warning is directly coming from reactor

[miniduikboot]

Is it possible for this object id to desync between clients? For example, when multiple mods add objects, they may load in a different order, or a mod that is declared optional declares a net object as well (which shouldn't happen, but I think it is reasonable foreseable misuse)

[D1GQ]

In theory it shouldn't be possible because in IgnoreInnerNetObjectAttribute Register collects all the valid innernet object with prefabs then on IL2CPPChainloader.Finished everything is loaded in alphabetical order to try to prevent this problem, as long as everyone has the same mods everything should be synced up.

[miniduikboot]

Should users of this API also declare this attribute?

[D1GQ]

Only to stop reactor automatically registering the innernet object