I am told that callStaticFunctionX() does not exist in the storeMng namespace.
I have tried different pointers, accessors to the STORE_MNG, thisname.storeMng, STORE_MNGâŚ, Nothing is allowing btn to access the static function in STORE_MNG.
Firstly, your capitalisation is a bit off, in C# itâs common to use PascalCase for namespaces, classes and methods.
So, storeMng is your namespace, you canât call a function in a namespace, you need to call a function in the class. So in your example, it would be thisname.storeMng.STORE_MNG.callStaticFunctionX()
If you put a âusing thisname.storeMngâ at the beginning of your file, you can use just STORE_MNG.callStaticFunctionX()
Hi,
So I am having some difficulty again in regards to namespace. I believe I got it working last time as the script I was calling from, is somewhat lower on the totem pole than what I am trying to call from now, which is at the top.
I have example.store as the main name space, class STORE
I then have example.store.mng as the next, class STORE_MNG
I have placed a call in STORE, example.store to STORE_MNG, example.store.mng via many variations ofâŚ
//in STORE, example.store
example.store.mng.dothis();
///also have tried....
example.store.mg.STORE_MNG.dothis();
///and this.....
STORE_MNG.dothis(); ///with do this as a static function
all inform me that the name âmngâ does not exist in example.store.
so example.store and example.store.mng are both namespaces? With the classes example.store.STORE and example.store.mng.STORE_MNG ? And you want to call the static function dothis on the STORE_MNG class?
If so, then you would do example.store.mng.STORE_MNG.dothis(); or you would use using example.store.mng; and then STORE_MNG.dothis();
Also, I would strongly suggest you adopt the standard capitalisation of namespaces and classes in C# â for example Example.Store.Store and Example.Store.Mng.StoreMng
Ok great.
Hopefully I will never need to ask about this again.
Many thanks!!!
Edit. So would you build a project around namespaces? Example, player manager, enemy manager, score manager, using namespaces? Potentially, I could see each one having a namespace. For instanceâŚ
Root
Root.Player
Root.EnemyManager
Root.Score
And so on. In my mind, Root, would subscribe to all major functions in each manager. So, player dead, game start, pause⌠And so on.
Namespaces are just a tool to keep your code organised, so feel free to create them how you want to. Once youâve used them for a while, youâll quickly see for yourself how itâs logical to group your code.
That being said, donât create too many of them. If you only have 1 or maybe 2-3 classes in a namespace, it probably doesnât need its own namespace. For a small game for example, itâs probably enough to have just one namespace for all your code. If you start with one, and it becomes unmanageable, you can look at the classes you have and see which naturally fits in a group, and create a separate namespace for these.
If it helps, you can think of namespaces like you think of folders in a regular file system. If a few scripts are related in a meaningful way, put them in a single namespace ⌠just like you would put a few related documents together in a folder.
In fact, a lot of the big IDEâs out there (think: Eclipse, Visual Studio, etcâŚ) use this convention implicitly. If I create a folder in my project called Eisenpony.SpellingGame.AI and use the IDE to create a new class inside of that folder, Visual Studio will automatically put the class into the Eisenpony.SpellingGame.AI namespace for me.
I think this might help you get a better feeling for how to use namespacing. No need for a new namespace for each class.
If that doesnât help, well⌠then just carry on with how you are doing things; experience is the best way to understand.
So, for my games, usually I have a RootMng at the head whom each the PlayerMng, EnemyMng, and ScoreMng each report to the RootMng on a major event. Something like when the player dies, passes a level, bring in new enemy⌠etc.
So, would a single namespace handle this? If I have a namespace âRootâ, I would certainly place that in the RootMng script, now, for each sub manager, how would the naming process occur? Would each also be under namespace âRootâ, or would each have its own, example, âRoot.Playerâ, âRoot.Enemyâ⌠and so on.
I think youâre misunderstanding namespaces and thatâs where the confusion comes from. Namespaces have nothing to do with events and no effect on what a class does. You can create 1 namespace or 10000 namespaces it doesnât matter. Theyâre really just folders to organize your classes. In my game, I only have about 3-4 namespaces I think.
No, you donât put namespaces in scripts, it is the other way around: scripts get placed in namespaces.
Also hereâs something that may help you.
Letâ say you have this line:
System.Collections.Generic.List myList;
System.Collections.Generic is the name of the namespace. List is the name of the class. The namespace + the name of the class is called the fully qualified name.
Ok, I was thinking namespaces would allow me to reference other scripts via code much more easily.
So, exampleâŚ
Root
Root.PlayerMng
Root.EnemyMng
All fall under the Root namespace. As such I could call any member under this namespace, from any other member under the namespace simply by doing this for exampleâŚ
///in player mng at player death
Root.PlayerDied();
then in the Root Mng, I could do thisâŚ
Root.EnemyMng.PlayerDied();
I was thinking it was an easier way to access ones component.
Honestly, until you start running into issues with your script names becoming too cluttered and similar⌠just donât use them at all. They serve very little practical purpose, at least on the scale of a Unity game. They mostly serve to help you understand the organization of your code better, and theyâre clearly not doing that for you. Just donât use them at all.
Let me give you a practical example of one of the very few times that youâll actually find namespaces serving a real purpose. Thereâs a Unity plugin called Vuforia (has to do with AR), and within Vuforia, there was a class called Image. For a long time, this was fine. But then, Unity 4.6 came along and introduced the new UI, including, among other things, its own class called Image. Now, anytime I typed âImageâ into a script, the compiler didnât really know whether I meant Vuforiaâs Image class, or Unityâs Image class. Unityâs class was within UnityEngine.UI, and so could always be accessed as UnityEngine.UI.Image, but typing just Image would make the compiler think that I wanted the namespace-less Vuforia Image class. Naturally, this caused problems, but mostly annoyances - I had to use the full namespace âpathâ to reference Unityâs Image class, every time.
In a more recent version of the plugin, Vuforia stared putting its classes under its own âVuforiaâ namespace. And the world was happy again; Iâd add âusing Vuforiaâ to the top of my scripts that used that, and âusing UnityEngine.UIâ to the top of my scripts that used that, and all was well.
Itâs important to note one thing: nothing that Vuforia did with namespaces is necessary. They could have renamed the Image class to VuforiaImage, and achieved exactly the same effect, with the only exception being that typing in the class names would have been more annoying. And that is the entire use case of namespaces - to prevent collisions of names by organizating classes into sensible clusters.
If doThis is static then that will work but this has absolutely nothing to do with namespaces. Namespaces arenât access gates. You could just as easily not namespace RootMngClass (which is a terrible name by the way) and just type RootMngClass.doThis()