I think that the first is faster and easier.

Hello. I played first time with distortions and noticed two problems:

1) Distortions don't work unless distortion map has same amount of rows and columns. I just messes up and looks glitchy if there ar for example 4 rows and 10 columns. Edit: Filed a buf of this.

2) The collision mask doesn't update with distortions.

I tried to find workarounds for 2, but with little success. I tried to paste the sprite into a canvas, but I have no clue how to handle collisions with canvas. Is there a way?

Theoretically when conditions needed to make two objects are met, then you would have to make two parallel sub-events - both "always"-ed. First one will handle making first object and initializing it, second one: handle second object.

Yep :). That's because Selected Object Lists descend to subevents, but not back from subevent to parent event or sibiling event.

Recently, there has been a lot of discussion of things like that. If you have to do something to a independent instance, you must pick it. The actions in an event apply only to picked objects, so you must ensure that only the instance you want to manipulate gets picked. You can pick with Unique Identifer, for example. For each -condition is also a lifesaver, it loops through every instance of an object so that the event is performed once for each instance.

I'm in uni now and I should be studying (deadlines :S), so can't blabber more. Sorry :D

Jayjay: LABEL! Yes, that's the word that fits the purpose. Thanks for the term.

About multiple picking conditions: Lets have two Sprite1s, UID 2 with 'Size' 4 and UID 4 with 'Size' 7. that "Sprite1 (labelled A) Collides with Sprite1 (labelled B)" must work so that both A and B pick both UID 2 and UID 4... That's because if it picks directly one instance there is no way to test further differences between A and B in following events. So, after the collision condition A = (UID2, UID4) and B = (UID2, UID4), and after the "A.Value('Size') > B.Value('Size')" condition A = (UID4) and B = (UID2).

There's some problems if user wants to do so that whichever sprite destroys is chosen randomly... or something like that. If there's a "Pick randomly" condition to rule out other instance in A, how are we going to make so that the outruled instance is conserved in B and the other is ruled out?

My answer would be that there was an condition like "Exclude A from B". This would be useful tool in many other situations also, when it's easy to define what the other label consist of, and after that just make B to be "not A"...

Secondly, an idea about a faster, new type of loop, "For Each Pair". I got this idea when reading a thread about gravity simulation () In gravitation calculations, you must loop trough every object pair, because every object casts a force to every object. Traditionally you would do this with nested for each loop, which is unfortunately really slow. The gravitation simulation uses a loop where every object is tested with every object. This is a very common special case of nested loop, and I think that it could be TWICE faster!

A nested loop. Numbers are object instances and I means that the looping event is tested with instances of it's column and row.

  1 2 3 4 5
1 I I I I I
2 I I I I I
3 I I I I I
4 I I I I I
5 I I I I I
[/code:39e3huh9]

"For Each Pair" -loop. A new kind of loop which would perform about twice faster. O means that the looping event is not tested with the instances of it's column and row.
[code:39e3huh9]
  1 2 3 4 5
1 O I I I I
2 O O I I I
3 O O O I I
4 O O O O I
5 O O O O O
[/code:39e3huh9]

So, it runs through every PAIR of instances only one. I.e. if it has already tested and performed the event with instances 1 and 3, it won't do so again with instances 3 and 1. On top of that, it doesn't perform the loop with the instances 1 and 1, in other words, the same instance (well, this could be an optional choise). "For each pair" -loop could use "instance naming" described above.

[code:39e3huh9]For each pair of Asteroid (A and B)

Hello.

I posted already this: in uploads forum, but I got the feeling that people kind of ignored and missed it. So, I'll post now my instance picking ideas and some new thoughts here.

First of all, Consturct needs improved picking of object instances. The problem is currently that when there is two instances of the same object interracting in same event, user is unable point out which instance does he mean.

For simple example, let's have a game where there is creatures, and bigger creatures eat smaller, as they collide. The smaller thus destroys and the bigger gets even more bigger. A game this simple is relatively easy to make using different ways, but the most simple, intuive way would be addressing the two creatures with different names. We say that creature A is the bigger and B the smaller, and then describe that creature A does this and creature B does that. This is a feature that Construct doesn't currently support with different instances of same object.

A code example of would-be syntax:

Sprite1.A Collides with Sprite1.B
+Sprite1.A.Value('Size') > Sprite1.B.Value('Size')

Gah! Please post non-worksafe before images like that, some older ladies just got a heart attack when that... thing flashed onto my screen.

Nope, just kiddin' :D

I dont think you completely understand, the condition loop

Pair: Loop each

Would repeat the actions for each parent, and select the spaceships and turrets accordingly. So if you have 600 spaceships and 1200 turrets, it would loop 600 times, selecting the turrets for the one selected spaceship.

So it's a bit like container, but editable in runtime and capable of having many instances of same object per a parent object. That sounds like what I was originally hoping for containers to be, when Scirra released the first public builds :D. Great!

Mac uses package managed install system, so the install files aren't executable programs, they are .dmg files.

It's alright, the last build introduced support for space-time continuum recursions.

When is the long time ago much requested spag bol support being introduced?

Hm, I am not sure how well this works, but as a workaround you could make a invisible, non-rotateable detector with physics and set it's position always at a sprite which has the platform behavior.