A non monobehaviour class is called in another script

Unity Engine
, , ,
1

help me understand how a non monobehaviour class is called in another script
without its declaration and without static fields, how does it work?

Screenshot_20241106-194511_1
Screenshot_20241106-194511_1720Ă—395 62.3 KB

Screenshot_20241106-194523_1
Screenshot_20241106-194523_1720Ă—387 74.4 KB

Check my best games :alien::video_game::anger:

2

What are you asking, how to get the reference over?

If the thing(); that you’re calling isn’t static, you do need a reference to the object, otherwise how would the computer know which object you’re calling the thing(); on ?

So you could:

  • make it yourself (new it up)
  • receive it in a function call from someone else
  • put it in a field of something that you CAN drag in

Also, nobody is squinting at photographs of code in 2024. Use code tags please. That’s what they’re there for in the forum.

1 Like
3

Your question it too broad to be answered.

The mechanism used to include classes that do not inherit from the MonoBehaviour class is the same for the one that do. A class is a class.

In C#, your code is eventually compiled and “packed” in what we call an Assembly:

About C# Assemblies with Unity.

  • The mechanism used by Unity to package scripting units is actually a Microsoft standard called Assembly packaging.
  • An Assembly in C# or Visual C++ is the equivalent of a compiled binary output of a C or C++ program, once every translation unit produced an object file and got linked together.
  • On Windows, an Assembly can either take the form of a .exe, .msi or .dll file.
  • Although they have different extensions, their core structure is the same, giving interoperability between different software components.
  • The key difference is in the set of tools provided by the OS that targets Assemblies by kind. Thus even though all three kinds share a common structure, certain extensions are used for certain use cases, the most straight forward example being the use of .exe for software and .dll for dynamically loaded libraries.
  • But to be clear, they are exactly the same, it is possible to have some sort of “main” function (a system entry point) in all three kinds.
  • Additionally, static libraries with the format .lib are not considered Assemblies as they end up linked to an actual Assembly and do not produce their own.
  • Unity allows multiple Assemblies to be packages with a game.
  • See the section Assembly definitions and Predefined assemblies in Unity’s manual to understand how it works.
  • Unity also prevents circular references between Assemblies. Thus if an Assembly A needs to call a function from an Assembly B, then B will not be able to call any API exposed by A.
  • For this reason, most of the code that could trigger circular references should be placed in only one main Assembly to prevent any design errors.
  • Then inside this main Assembly, namespaces should be used to properly draw the line between components.
  • It should not be done at the Assembly level (at least in Unity as of 2024, circular references are possible in standard dotnet, but Unity for now uses a custom integration of .NET that doesn’t allow it).
  • If there is code that is really not related to any Unity’s features and that can be dynamically loaded at runtime, it should be placed in an external self-contained Assembly that will go through a batch of unit tests before any deployment.
  • This can be done using the dotnet CLI.
  • For code that is non-external but self-contained with no possible circular references, it should be placed in a separate Assembly to avoid its re-compilation every time a change is made in the main Assembly.
1 Like
4

Thanks in future i try using markdown for code snippets, u answer help me do next step for understand Unity Engine :raised_hand_with_fingers_splayed::alien::milky_way::heart:

5

Thanks bro, very powerful information about basics, sometimes lazy win me… :sleepy:lazy

1 Like