Ashley,

Maybe you should rename all the "compare" conditions to something similar to:

Pick object with private variable ..

or

Find object with private variable

Find object with angle

Find object with opacity

Find object with colour filter

Find object with unique ID

Find object with X position

Find object with Y position

Find object with width

Find object with height

And it would be nice to have

Find object with behavior property

(compare behavior property)

I dont see any "Main Layout" in the posted .cap.

So i can not help you with the variable.

But i do see other things in the posted .cap.

1/ the for each conditions in the key assignments are unneeded.

Why ?

Well, the compare private variable condition you have in the key binding events are Pick Conditions already. Every "Compare" condition is a Pick Condition, its a hidden LOOP already.

It works as follow.

It takes ALL the tanks. Loops trough them 1 by 1, hidden and in the background. It will test the private variable (in your case 'TankID'), if it meets the test conditions (in your case if 'TankID is equal to a number), it will feed that object to its Sub Events and Actions.

So when you compare ALL the tanks private variable TankID to the value 1. It takes all the tanks, and only the tank with TankID 1 gets picked out. Or what i call, gets picked from the group.

All sub events and conditions will only work on/with that picked tank.

What you now do is this.

The for each condition loops trough all 8 tanks, and the Compare condition loops trough all 8 tanks.

So what you do you could write as :

Loop from 1 to 8 (the for each loop)

_____if anything and nothing

_______ do nothing with tank(loopcounter)

_________Loop from 1 to 8 (the compare loop)

___________if 'TankID' = 1 -------------------------------------------> do actions and subevents

___________end if

_________end loop

_____end if

end loop

Each tank is passing 64 times a loop, where only 1 time is needed. At the end your game will lag.

2/ I see you still do not use containers. You do not have to. But it will make your live a lot more simple

I wonder why you want to rush this.

It will grow a natural way, free products dont need settle marketing, there marketing lays in its quality.

And on that point Construct starts to score well. !starts! Yes sir, it is not out off beta yet.

As long as Construct is in beta, the games made with it are beta too.

At this moment the few games, and the big amount of produced caps, serve 3 targets.

1 (very important) To have just fun creating things. And Construct is fun !

2 You teach me, and i hope i teach you how to use construct. And the knowledge gatherd by this will be the base for docs.

3 To guide Ashley in finding and solving bugs. To guide Ashley in bringing new things into construct. And all this from out the point of a "constructor" not from out the point of "the programmer" that Ashley is.

It is actual very interesting to see how "creative" people try to go along with construct.

I think thats where Construct stands now, stable, firm and promissing.

Expect more from either the program ,or from yourself, is at this point *dreaming*.

Wich is not a bad thing, if you realize that this is what it is.

So plz, keep gooing. Dont share games, but share .caps. Dont be so protective. Dont be shy about your caps too. Trow them in. I learned more from inperfect caps then from perfect caps.

Oh, you need to hold spacebar, and let go to fire.

No one aligns animations ?

well

I was playing around this

then got caught up in bouncing, why i changed from a bullet behavior to a ball behavior,

and now its bedtime.

But both work to soften the hard sides of rough movement, as u see.

be good.

....

Take your time with this build.

I must beat everyone with this !!!

Device name: Intel(R) 82865G Graphics Controller

Pixel shader: 0

Estimated VRAM: 48 MB

Motion blur: No

Thats from a HP compac desktop, the 3th computer in my work office.

Looking good huh ?

Nope, thats kinda inevitable, when using a square to bounce like a ball. Hardly a bug.

And thats not the issue. The issue is about aligning the angle sub animations with directions.

In that specific example the players object gets moved by a sensor. Logic is to place the players object on the sensor. AND align the animation to the sensors directions. That is sensor driven in its pure form. Snap position and angle.

In the .cap that triggerd me to get my mind on this, the "top animation" is choosen independed from the sensors behavior. The angle sub animation gets choosen depending on key inputs and collsions between the "players object" and the enviriment. (i dont think it works, even with animations working fine, but that we will see)

And! Since i don seem to be able to figure this completely out on myself, i am asking if there is someone who is using a coherent system in this ?

Aligning to the sensor ? Or otherwise ? Align to the behavior ?

Oh and did you see the aniations line up fine with the "8 directions" ?

Be so nice to bring your ideas, and help me to develop a coherent, working, general system. And not only for me.

ThanX

I noticed you use Aligned and NonAligned animations mixed in the same system. Feels kinda *unnatural*.

In an attempt to make myself clear here are 3 caps.

1/ what i called NonAligned.

2/ what i call Aligned

Or another example, but this time aligned to a behavior driven sensor.

3/

Questions: Is there anyone having a coherent system in this matter ? Is there an official way for doing this ? What would be the best way to do this ?

....