Shrugger! Unity!

[keith.lamothe]

Just saw your second post.

Do you need "simulation time units" that are of a fixed length?  Like "each must represent 1 second of 'game time' " (or 100 milliseconds of game time, or whatever).  This is how we did it in AI War, though the step-size varies by the Performance Profile option.  I think of this as the "sim frame" model, because the frames are defined units of time.

Or can they be whatever length and it just has more or less happen for large or small steps?  That's what we did in AVWW.  I think of this as the "sim step" model, because the steps are just whatever time elapsed since the last time we did it.

[Shrugging Khan]

So far I've been using the above method for just about everything from plant growth over plate tectonics to the AI.

But it really seems roundabout to me. So, boiling the question down a bit again...what way would you recommend to tell a script to  "do this every [length of real time]!"?


Edit: It took a moment, but I just got the

Code: [Select]

time = Time.time;
if (time >= frequency) {
   time -= frequency;
   DoThing();
}bit. Doesn't sound all that bad - but what if I had to call it, say, five thousand times per frame?

Edit2: Oh, and what about gimmicks like InvokeRepeating?

[Draco18s]

bit. Doesn't sound all that bad - but what if I had to call it, say, five thousand times per frame?

Edit2: Oh, and what about gimmicks like InvokeRepeating?

5000 times per frame is not an issue.  When DoThing() is the expensive part, the rest of it can be called a lot without impacting performance.

As for InvokeRepeating, that has function/event overhead, but it probably utilizes similar code.

Fake edit:

Oh:
http://answers.unity3d.com/questions/189917/any-costs-i-should-know-about-associated-with-invo.html

InvokeRepeating would actually be less than using the Update() function.  This is probably because it uses one central update function that invokes function calls in only the objects that need it, where as Update() is called for all objects, even the ones that don't need it (using up function call overhead).

[Shrugging Khan]

Bugger! Gotta dig into some InvokeRepeating documentation, now. Thanks!

I wonder if a script using InvokeRepeating stops doing so when its associated GameObject is destroyed. Hum...!

BTW, can anyone give me some tips on how to use classes to store information without having it clash with unity's GameObject-and-Component system?

[Draco18s]

BTW, can anyone give me some tips on how to use classes to store information without having it clash with unity's GameObject-and-Component system?

Scripts attached to objects are classes.  It's just implied if you leave the class definition part out.  If you want to explicitly type your scripts, they're a class that extends MonoBehaviour
(And no, I didn't spell that wrong, they're using the British spelling of "behaviour")

[Shrugging Khan]

So, if I wanted to have some sort of "CharacterInfo.cs" class, could I use it WITHOUT having to attach it to a Unity GameObject, but IN COMBINATION WITH scripts that are attached in such a way?

[Draco18s]

So, if I wanted to have some sort of "CharacterInfo.cs" class, could I use it WITHOUT having to attach it to a Unity GameObject, but IN COMBINATION WITH scripts that are attached in such a way?

Ok, yes.  You can create scripts that do not inherit MonoBehaviour and still use them (eg. utility scripts like Math, complex datatypes like Vector3, and interfaces like ISerializable).  You just can't extend them and attach the child class to a game object.  Any attached script MUST, at some point in its class hierarchy, extend MonoBehaviour.

[keith.lamothe]

One thing I should mention is that we only have one "object" in the Unity sense (the main camera) and its Update() method basically invokes our entire sim for the frame/step.

If you have multiple Unity-level objects, and especially if you have a _lot_ of them, then you're dealing with a very different "overhead ecosystem" than us.

[Shrugging Khan]

Well, if I had the slightest idea of how to do it the Arcen way, I probably would - if only so as to get around some of Unity's bad sides.

So...teach me the way, master? 

Edit: Then again, I'd have to code my own physics. Not sure if I'm up to that task.

[keith.lamothe]

Ha.  Master of Disaster, perhaps.


And yea, if these objects are all entities for which you want robust physics then Unity objects is probably the way to go with them.  At least for now, until you've accomplished your bigger goals.  Later on you may prefer doing your own physics, so you have more control over them.  But for now it would probably just bog down your project.

That said, if there's any significant chunk of these objects which are not really physical entities or otherwise can be handled with a very simple homebrew physics model (or none at all), then you perhaps could pull them under the umbrella of the camera object's Update function.

As for doing it, it's pretty easy, basically you just define a method on each "non-physics" object for "DoSimStep(float EffectiveDeltaTime)" or something like that, and then in the camera's Update logic you make sure all of those get called.  Often it makes sense to nest things inside each other, so you might call World.DoSimStep(effectiveDeltaTime), which then loops over all MetaMapNode's and calls node.DoSimStep(effectiveDeltaTime) and then loops over all RaceState's and calls race.DoSimStep(effectiveDeltaTime), etc.  To adapt some examples from what I'm working on currently.

[Shrugging Khan]

Been using InvokeRepeating(), and I'm very happy with the result. Cleaner code and improved performance!

But I need some of these repeating methods to be called at irregular intervals; would it be viable to Invoke() the method anew - with a random delay - at the end of itself, rather than to use InvokeRepeating(), or would that cost me the performance advantage?

[keith.lamothe]

You're off in strange lands where I don't think I can help you

That said, do you want those irregular bits to happen at intervals smaller than the time between two calls from InvokeRepeating, or larger than?

If smaller than, you could just have your logic that InvokeRepeating calls keep track of when you want those irregular bits to happen, and when time comes, do them.

[Shrugging Khan]

Gah, no thanks...keeping track of things is exactly what I did away with by switching to Invokeries. I guess I'll just try to have methods use Invoke("method", Random.Range(minDelay, maxDelay) to set up their next repetition. We'll see how it works out 

[Shrugging Khan]

Now, the weirdest thing is happening to me. I have an array of floats that determines the composition of the mantle, and in theory it's only set once and after that it's only read, never modified. But for some reason it gets reset to all zeroes at some point, and I can't for the life of me figure out why - it worked fine until I changed a few entirely unrelated things, then it suddenly went bonkers on me. I can't remember what exactly I last changed, but I already inserted Debug.Log() printing that array above and below every line that even just mentions it, but nothing - the array is fine for a few frames, then it suddenly gets reset.

Is there some less-known reason why an array might suddenly reset all its elements to 0?

EDIT: I managed to circumvent the issue by declaring a duplicate of the array and using it instead. This one never gets reset, and neither does the original. WTF?

EDIT2: Coincidentally stumbled across the explanation at the university today. "Side effect". Pah.

[Shrugging Khan]

Working on Overcomplicated3DSpaceRTS again, I'm currently digging into communications and reconnaissance. Obviously, I bit off a bit more than I could chew. The issue that presented itself concerns physics, and I hope someone here knows a thing about them.

Is there a difference in technological difficulty in detecting radiation of different wavelengths of the electromagnetic spectrum?
And if so, what is necessary to make it work?

As always I'm grateful for any help.