[BSTRhino]

The implicit ID is just an auto-incremented number actually, it's not anything too special. That means, if you have a loop, the component has the same ID each time and gets replaced. That is a feature, not a bug. So this code snippet will keep replacing the text sprite with a new one, counting from 1 to 10:

for i in RangeInclusive(1, 10) { TextSprite(i) }

Yes, you found the right place in the documentation. Thanks, yes I worked very hard on the documentation!

[svieira]

Ah, so you don't do parallel with implicit IDs right now, I'm guessing. Or you do, but it has some interesting bugs as the IDs shift around? Or the scope of the auto-incrementing number is lower than "the entire program" so parallel works?

[BSTRhino]

It sounds like you are asking, if auto-incrementing IDs are assigned in parallel at runtime, then order of execution of the threads must affect which ID gets assigned to what, and that must make some interesting bugs?

The IDs are assigned at compile time by the Easel compiler. So they don’t change in any way at runtime. Does that answer your question?

[svieira]

Mostly - if the IDs are assigned at compile time, how do you deal with _runtime_ locations like "the fifth iteration of a For loop"?

[BSTRhino]

Actually, all iterations of the for loop have the same ID. This is the design. So the second iteration has the same ID as the first iteration, which means it replaces the sprite created by the first. The fifth iteration has the same ID as the fourth iteration, so it replaces the sprite. So all the iterations keep replacing the same sprite. And that is how you animate sprites!

If you are actually trying to make multiple sprites and not keep replacing them, what you do is you spawn a new entity to hold your extra sprite:

for i in Range(0,10) { Subspawn { TextSprite(i) } }

That code creates 10 sprites and achieves what I think you are thinking of.