About package architecture

[RicardoGuzmanVelasco]

Hi!
Really astonishing package you did. 😄

We've tried to integrate the way you implemented ScriptObjs' famous Unity 2017 talk into our workflow. We failed at first 'cause we were at Unity 2019 — didn't properly read Unity 2020 requirement, my bad. Then we upgraded to Unity 2020 LTS and I'm right now integrating your package.

The thing I don't really figure out is why the package take so long any new type of variable/event/constant/reference and so forth is declared in inspector, neither why a new dll is created into Plugins-based hierarchy instead of use code in your package. May I'm missing something about how you architecturize the package?

Thanks so much!

[SolidAlloy]

Hi, thanks for trying out the package :)

The basis of the package is GenericUnityObjects.
Starting from Unity 2020, it has become possible to serialize generic plain classes:

[Serializable]
public class PlainObject<T> { }

public class TestBehaviour : MonoBehaviour
{
    [SerializeField] private PlainObject<int> _plainObject;
}

However, we are still missing this feature for classes derived from Unity.Object, like MonoBehaviour and ScriptableObject. You have to implement a concrete class for each set of generic arguments you want to use:

public class GenericBehaviour<T> { }

// You can't add GenericBehaviour<int> to a game object directly.
public class GenericBehaviourInt : GenericBehaviour<int> { }

GenericUnityObjects package eliminates the need for implementing concrete classes manually by generating them for you. The generation of a concrete class happens when you use a set of generic arguments for the first time. For example, when you add the GenericBehaviour<int> component for the first time to a game object. That's when a domain reload happens and it takes some time to recompile. Once a concrete class is generated, the recompilation won't happen the second time you add GenericBehaviour<int> to another object.

Now, other packages based on Ryan Hipple's ScriptableObject talk have a number of concrete classes derived from ScriptableEvent<T>, Variable<T> prewritten in the package, e.g. Variable_bool, Variable_int. If you want to use a Variable of a type not implemented in the package - let's say Collider2D, you have to first write a concrete class derived from Variable<Collider2D>, then implement a bunch of supporting classes like ScriptableEvent_Collider2D, ScriptableEventListener_Collider2D, Reference_Collider2D. That's not a lot of work, but you need to do it every time you want to use a new type, and it makes the codebase unnecessarily larger.

With GenericScriptableArchitecture, you can use as many types as you want without writing a line of code - in the end, that's what generics are for! The project needs to recompile only once when you use the type for the first time. Besides, the type names will be more readable in the inspector and code editor: ScriptableEvent<bool, int> instead of ScriptableEvent_bool_int.

You can also expand the plugin more easily as there is only one Variable<T> class where a line of code needs to be added/changed, instead of multiple concrete classes that may break after a change.

Hopefully that answers your question :)

[RicardoGuzmanVelasco]

Indeed, I spent yesterday morning reading your documentation regarding that package. So smart and straightforward to use it is!

The thing we weren't able to figure out is why those dlls are endlessly updating its guids over our meta files. I herewith have attached a file showing so.

This is happening after the following steps:

• I create some dummy variables, eventlisteners and so forth of the main types, just to create the respective dlls.
• I push on the repo that set of dll-mdb-meta tuples.
• Someone pulls that.
• She opens Unity.
• Unity changes what you see in the picture: any dll-mdb-meta tuple which was created, has changes.

The problem is, this is turning out to be a nightmare when it comes to agile flow along branches.
There is something we have missed?

Thanks so much!

[SolidAlloy]

Hi, thanks for reporting the issue. I just checked it on my end and failed to reproduce it.

1. I generate a new .dll by creating a scriptable event of a new type.
   
2. Push the changes to the server.
3. Pull them to another location.
4. Open the editor.

The GUIDs do not change:

(Nevermind the Logs/ files, I created a repo for a quick test).

Now, a lot of details may affect this behavior. I tried it with GenericScriptableArchitecture 1.1.7 installed through OpenUPM, Unity 2020.3.19, and Windows. What are your and your colleague's setups?

[SolidAlloy]

Not only the .meta files change when your colleague pulls the changes. As I can see, .dll files are marked as changed too which means they were regenerated. Could it be that you pushed the generated .dll files but didn't push changes to Assets\Plugins\GenericUnityObjects\EditorResources\SOGenerationDatabase.asset in the same commit? Thinking of it, it's easy to mess up. A scriptable object file does not change until you press Ctrl+S in the Unity project, so it's easy to create a commit where the generated .dll files will be present, but SOGenerationDatabase won't.

I will fix it soon, thanks for pointing this out

[SolidAlloy]

Please upgrade to 1.1.8 and let me know should you still encounter this issue

[RicardoGuzmanVelasco]

I'll check it out tomorrow morning at the office, for sure.
I guess it's definitely related cause I don't remember the database asset. The “not-saving-project” issue on Unity strikes again!

Please let me try out and I'll be back here to report.
😄

[RicardoGuzmanVelasco]

First update: regeneration is not done anymore after upload database assets. Yep, you were right!
I'm upgrading 1.1.8 now to replicate it.
We're also testing if it has vanished some LogError which were appearing when any project script was selected.

[RicardoGuzmanVelasco]

Second update: those LogError I was referring to turned to be exceptions. We didn't get rid of those after upload database assets to the repo.
They appear whenever you select a script, as I have said.

They always have a first MissingMethodException —no info neither stack trace— and a bunch of NullReferenceException with the stack trace the picture shows.

Hope it helps! I'm updating to release 1.1.8 right now!

PS. Just in case you want any other test case before updating to 1.1.8, some of my colleagues will remain in so. :)

[SolidAlloy]

Sorry for the delay, I never received an email regarding your replies for some reason. Sure, upgrade to the latest version, no need to remain on the previous one to test other bugs. The MissingMethodException is a known bug I fixed before, so it shouldn't reproduce in 1.1.8