koobas.hobune.stream
How to use yield within a class function
Im having an issue trying to implement yield within class functions, what im trying to do, is create classes that will contain the behavior of the player/enemies.
Here's an example of what i'd like to do:
class Body{
private var isStunned:boolean;
function Body(){
<constructor data>
}
function getStunned(stunTime:int)
{
isStunned=true;
yield WaitForSeconds(stunTime);
isStunned=false;
}
}
I've checked around looking for other questions, and what they seem to suggest is to call these functions from within a MonoBehavior script, but that doesn't let me achieve what I want to be able to do. Basically, i'm trying to make a base class that has basic functions that every enemy/player will have and then create aditional classes that extend from it for each.
class imAnEnemy{
private var myBody:body;
function imAnEnemy()
{myBody=new body()}
function isActive()
{<call other functions from body, which may include yield>}
}
From the example code above, i'd call the isActive() function in the Update Method, but sadly I havent found a way to make this work, is there any elegant alternatives to what I want to do? I know I could just brute-force everything into a MonoBehavior script, but to me that would seem to add too much redundancy.
You have to start them as coroutines - normally Unity does that if you call it from within a MonoBehaviour. If you want a utility class then you are going to need a utility MonoBehaviour script to run the coroutines on. In other words you need a script that's purpose in life it to execute your coroutines from your library.
It could be as simple as:
CoroutineSupport.js
static var instance : CoroutineSupport = this;
function RunCoroutine(coroutine : IEnumerator)
{
return StartCoroutine(coroutine);
}
Then to start a yielding library routine you would use:
CouroutineSupport.instance.StartCoroutine(someCoroutineFunction());
Hmmm, I just tried to do that, created a script pretty much exactly the same as you did (the CoroutineSupport.js), and attempted to call a function using CouroutineSupport.instance.StartCoroutine(someCoroutineFunction()); , but Unity gives me this error: BCE0020: An instance of type 'CoroutineSupport' is required to access non static member 'instance'.
@whydo, have a look at this ...
http://answers.unity3d.com/questions/17916/singletons-with-coroutines.html#answer-449919
(search to my answer which mentions "grid")
After years of struggle with this, I have found that to be the most workable real-life solution. Have you ever taken this approach? Can you see any gotchyas? What do you think?
It makes one's code look beautiful, well to me. All our code is riddled with "grid." ...
if ( weaponNumberIfPowerup == 0 )
{
grid.gamecenterstuff.whatever();
grid.funnyvoices.whatever();
multiplierRunOver( 2, generalPosition.position );
}
For me it just makes a lot of sense. it's not fighting Unity. Even in a way the "grid" Class (as in the link) becomes a handy kind of self-documenting "registry" if you will of those sorts of things, you can even look at it that way.
I dunno. I get really troubled by this issue.
I searched some more and found a solution for my issue. In case its of use to anyone else, here's the example code of what I found on the Unity forums:
// Coroutiner.js
// this class is just used to run coroutines and needs
// no further functionality
class Coroutiner extends MonoBehaviour
{
}
// Test.js
// a class inheriting from System.Object, using
// coroutines:
class Test extends System.Object
{
public static var coroutineRunner : Coroutiner = null;
function Test()
{
if (coroutineRunner == null)
{
var go = new GameObject("Coroutiner");
coroutineRunner = go.AddComponent(Coroutiner);
}
}
function Go()
{
coroutineRunner.StartCoroutine(MyCoroutine());
}
function MyCoroutine()
{
yield;
Debug.Log("it worked!");
}
}
Oh brother.
I am so wary of automatically making a game object.
You know it's true, a couple yrs ago in the endless search for "singleton coroutines" ... see the links I posted .. someone came up with this idea "hey, this code "automatically" does coroutines" ... i.e., the trick is it adds a gameObject.
I just dunno. It's such a disturbing idea.
{One point, if I had code to automatically add game objects man it would have to be robust. What about the na$$anonymous$$g issue, uniqueness, other routines you have that look through gameobjects for some reason, what if this starts running over and over, etc etc. I mean where does it add this coroutiner game object? to the current object, on the top of the scene, what? should this new object be dontdestryonload? all these issues are tricky and would need to be thought-out. my feeling on program$$anonymous$$s is anything that isn't instantly totally inevitably obvious and needs no thought -- is no good! heh}
I am definitely not a "language mechanic", I just want an expert to fix such issues for me. So I don't chime in much on such debates. But for me it's just very shoddy/scary this idea that you can automatically add a game object and that "solves" the singleton-coroutine problem.
I mean conceptually in the broad sense, there are things in your project that are coroutines, versus those that are not coroutines ....... it's a huge, tremendous gulf, they are really different sorts of "things". I'm troubled by trying to in a sense "make them all work together".
