So I'm trying to get all MOSParticles in a list to animate at a fixed rate regardless of the time of origin.

This should work, but isn't; it's giving me errors about comparing nil with number on particle.Frame. Any idea why?

edit well I shouldn't say why but how could I go about fixing it, it's pretty obviously thinking particle is not a good enough pointer

Try casting 'particle' to a MOSprite and see if that works.

In the past, I have had issues like this when using MovableMan.Actors and MovableMan.Particles. My guess is that the pointer in 'for <pointerHere> in MovableMan.Particles do' is not inheriting all the traits from its super classes. Dunno why. Might be a Lua and CC compatibility issue.

But, if that's not the problem, then I don't know what is.

Yea, they are funky.

Unfortunately, I would guess casting conflicts with editing variables, so you will need two pointers if you want to access some things and change variables.

I did some thinking about this, and I think I have some understanding of what's going on.

Several weeks ago, I learned that MovableMan.Particles is actually a function that returns a table, not a Lua table itself (see image way below). I didn't understand why until now.

My guess is that MovableMan.Particles references a function in CC's game engine, not a function in Lua. I am assuming this because Lua functions use a ':' when called, while functions from programming languages like C/C++ and Java use a '.'. I don't know what language CC's engine is written in, but it'll most likely be some C based language. Unlike Lua, these languages do not support dynamic type.

The pointers returned by MovableMan.Particles are classes of MOPixels, MOSParticles, and AEmitters. However, each of these particle classes have different properties from each other. Pointers returned by MovableMan.Particles can only have properties that are common to these three classes, since the language that MovableMan.Particles is written in does not support dynamic type. (The actual type that's returned is probably either a MovableObject, or some Particle interface).

When these pointers are passed to Lua, it then adds in the properties of that pointer's specific class. However, any traits from super classes in between get lost in translation, since these pointers did not have these values when CC's engine passed the pointers over. So, Lua just fills in the gaps with 'nil's.

Keep in mind, this is only a hunch. I might be wrong on some minor points, but I think it might accurately explain why Movable.Actors, MovableMan.Particles, and such act weird.

Yet, I could also be completely wrong and just blowing confetti out my ass.



@Grif: Yes, you shouldn't of said why

And therefore, try using ToMOSParticle(particle).Frame.

Kyred, that sounds about right - the engine is written in C++ and unless Data specifically made them dynamic classes, it would make sense that it would result in this kind of behavior. I think Piipu is also on the spot about using ToMOSParticle too. Make sure to check that it actually is an MOSParticle first, though.

I just found some hard proof! I tried setting MovableMan.Particles to nil, and it told me what the function's return type was. It returns a MovableObject.

I've never seen so many Sparkle Mages in one place.

I hope this helps grif, he's been stuck on this one for a few days now.