I have a singleton script to manage the state of a power level.
A coroutine within the script regenerates the power back to 100% every second or two if the power level falls below 100%.
From what I can tell you can't use a coroutine on a script unless attached to a GO.
I get the error "Coroutine couldn't be started because the the game object 'defaultProperties' is inactive!"
I attached the script to an empty GO but still have the error if it tries to run the coroutine. Is it possible to create a singleton that has coroutines?
public Singleton()
{
if (instance == null)
{
instance = this;
}
}
public static Singleton Instance
{
get
{
if (instance == null)
{
new Singleton();
}
return instance;
}
}
IEnumerator RegenPower()
{
yield return new WaitForSeconds(1);
AddPower(1);
StartCoroutine(RegenPower());
}
As SpikeX already pointed out calling a co-routine recursively might not be a good idea. Using Singletons for global Behaviour and states is a common software architecture. However, you can only start Coroutines from MonoBehaviours and you can't use the "correct" singleton pattern, as you are not supposed to call or change the constructor of a MonoBehaviour.
There are several ways to write a "pseudo-singleton" that is a MonoBehaviour to use with Unity.
public class EasySingleton {
private static EasySingleton instance = null;
public static EasySingleton Instance { get { return instance; } }
void Awake() {
instance = this;
}
}
That's the easiest way. However you will have to attach this to a GameObject manually in your Scene.
public class AdvancedSingleton : MonoBehaviour {
private static AdvancedSingleton instance = null;
public static AdvancedSingleton Instance {
get {
if (instance == null)
{
Debug.Log("instantiate");
GameObject go = new GameObject();
instance = go.AddComponent<AdvancedSingleton>();
go.name = "singleton";
}
return instance;
}
}
}
The advanced version will create its own GameObject and attach itself to it as soon as you call it for the first time. This is very convenient and keeps your scene small in the editor. You could also implement something that will remove the object from you scene once it isn't needed anymore (e.g. the coroutines have finished.)
I don't know why you're getting errors, but I see a lot of potential problems with this script. Let me point them out, and we'll hope that one of them was the problem.
I wouldn't call a coroutine from within a coroutine. Use a while(true) loop instead. It won't freeze your game because of the 1 second wait time. I do this all the time.
I don't think you implemented the Singleton pattern correctly. See the correct C# example here.. Your constructor needs to be private (and empty!), and you need a static reference to the Singleton class.
I don't think the singleton pattern will work for game objects that derive from MonoBehaviour. In fact, it's actually recommended that you DON'T have a constructor, and instead use Start() or Awake() for initialization. I can't even begin to wonder what kinds of problems you'd run into if you had a singleton attached to a game object.
If you went into a bit of detail as to why you thought you needed a singleton, someone here might be able to recommend the correct way of doing what you're trying to do.
if (instance)
Destroy(gameObject);
instance = this;
when using writing public methods, be sure to add "Instance." to your variables.
Also, make sure your public methods are static like this:
static public void someMethod()
{
Instance.someVar = 100;
}
Beware that i may have made a few mistakes/type-os, but this is how I have my singleton that uses co-routines setup, and it works as it should. If anybpdy sees a real issue with this, speak up, so we can get this solved once and for all.
BTW, I learned this code from looking at other peoples code, so its my turn to pay it forward.
Full explanation of the new “grid” system is now here …
Purely for convenience:
In almost all projects: it will be the case that you will have an empty game object attached on your opening scene, for clarity let’s call it “holdAll”.
“holdAll” is persistent throughout the game.
Attached to that, you will have many files such as Shopping.js, Analytics.js, Calculations.js … etc etc
Each of those uses coroutines. So they really are best as “normal” scripts attached to an game object.
Again, it’s inevitable that almost every Unity game has an empty game object (“holdAll”) which is persistent throughout the whole game, and you use those various
I’ve never seen a Unity project that does not have that.
So, this is all great and normal. But, each time you want to use a routine from shopping.js, you need to make a local variable which, annoyingly, you have to hook to shopping.js on holdAll.
Of course, it’s much easier to just call ordinary static libraries, like when you use Mathf or the like.
Is there a solution?
Yes, here’s what I do. Make a tiny little class called say “grid”:
class grid
{
static var shop:Shopping;
static var etc:Etc;
static var etc:Etc;
private static function grid()
{
shop = GameObject.Find("holdAll").GetComponent(Shopping);
etc = GameObject.Find("holdAll").GetComponent(Etc);
etc = GameObject.Find("holdAll").GetComponent(Etc);
}
// nb, grid() is indeed magically called (once only)
// when one of these vars is first accessed -
// you need do nothing, just use the vars at will.
}
then from anywhere at all in your project,
with no further effort,
you can just write
grid.shop.buy(..);
grid.shop.sell(..);
yield grid.shop.showDialog(...);
yield grid.shop.interactionUser(...);
x = grid.shop.count;
and so on. Same for all the others (Shopping.js, Analytics.js, Calculations.js etc etc)
I want the convenience of just being able to say
yield shop.whatever();
anywhere in the project WITHOUT needing an annoying hooked-up local variable “shopit” which leads to holdAll-Shopping.js.
But in my opinion there’s just no really good, bulletproof, way to make a static/singleton/etc, where it’s a “normal” coroutine-based Unity object.
So … for me, this seems to answer all those needs. The only downside is effectively one extra “.” when you type grid.shopping.