THX u so mutch Ashley,

As you can see in the included cap,

the behaviour of the ball runs out off sync with the events.

This way a lot of the collissions escape.

There are 2 ways to solve this.

Use (1) a bullet behaviour and calculate the bounces in events yourself. Easy for the walls. Since they are BIG BIG cirkels we can assume the objects go trough the middlepoint when they aproach the walls. And bounce back mirrord arround the normals.

Thats (180 - .angle), (360 - . angle) and (0 - .angle) .

Must be not that difficult to do with the collisions with the cirkels. I know the size of the cirkel. I know the dx and dy between x1,y1 cirkel and x2,y2 aproaching object.

I think it bounces around the tangent.

I got to google this to be sure.

But.. oh man, not using all those nice behaviours ? Thats a shame eh ?

The other (2) solution is to start each block events with "flow" events. They are interruptable.

And to give the plugins (behaviours) events that can interrupt the other events (in a later stage of the developping)

Also, there is another advantage. Its important to make the dissicion to run a certain event or not, as early as possible in the event and with the fastes tools available. Only this way u build speed in big caps.

The fastest tools are the hardcoded system events, and as far as i can see, u did a great job on them.

I am sorry that i made the wrong statement about "global variables" beeing slower. I ofcourse had to test this out. And i was wrong.

About using more "tags", tags as in usernames.

Several times i gave up on this. Each time i gave the username a non existing e-mail and a random password. Thats for me as user the only way i can find to delete a username.

I was't gonna come back, each time.

But then a few days later, i took it up again. Made a .cap illustrating the things that i missed. And i knew its worth it all.

So ty for lookin into what i suggested.

I stil have this need in my veins to make this .cap that shows events combined in a way that should not be allowed by the wizzard. You gonna hate me (again) for it ? or is it um ok to do so ?

For one,

i do not hide, look in this treath

For two,

judge me on what i do with Construct.

and here it is .. uploaded again .. be so nice to read opening post to place the .cap in the right context.

ty

http://www.mediafire.com/?tnymthxlmlj

captain ?

do we agree that the cap you can download here ...

http://www.mediafire.com/?tmdltuje2n1

is "flow" driven ?

and would you be so nice to point out the limitations ?

besides the two that i know allready ..

1/ i can not interrupt the mouse down event ..

2/ i can not interrupt the balls behaviour to read out accurate collision dedection

well maybe you are so nice to teach me how,

your help is apriciated

Ashley,

I would like to suggest some comsmetic "changes", mainly for flattening the "learning-curve"

1/

A sprite is the grafical face of an object. At the moment it can be changed by changing the animation. (very powefull). But a sprite is not an object. The basename of an object is "sprite",

and it this "leakes" into the events sheet editor. Thats confusing.

2/

There are 3 kinds of events. And the conditions you use (in practice) with those events are very specific.

There (1) are events that dont pick objects (system events, keyboard events ... ) Lets call them the "flow events" IN practice the conditions paired with those, dont filter in the "picked objects", or should not. Doing so makes no sense.

There (2) are events that "pick objects" and feed them to the actions. Conditions paired to those events filter in the "picked group", or should do so.

There (3) are loops. At the moment u can pair up any condiion with a loop, wich i think makes no sense, less u can show me differend.

I really think this should be reflected in the way the wizzard picks objects and in the way u add events and conditions to the sheet.

An example of a nonsense .cap u find here ..

https://dshop.diino.net/getafile/ANGZIZ ... /onzin.cap

This makes no sense, because u can start every blok events with whatever. I personal thnk every blok of events can only start with a "flow event".

You take this as " lowering the possibiltys". And that is not true. Its like ...

Driving conventions say: drive on the road ! Thats not "lowering of posibiltys" (probaly bad english), because there are roads enough. Just like your concept has roads enough.

Restrict the start of a new bloks of events to "flow events" sure take out some unexpected bugs, and lowers the changes for bugs. The caps will be better readable.

And maybe more importand, they say now: the sheet runs "top down".

Wich would mean that a "On mouseclick" dont work as an interrupted? Thats a question. But if the answer is "yes" then i have my doubts by the whole concept of the sheet. Does a mouse event, a keyboard event, a system-object based collision dedection and all those "interrupts" really have to wait for the next "tick" to be "in account" and to be executed ?

If you think this trough, then the only logical aproach is to start each new event blok with a "flow event" ... where "top down" is the mainway of running it, with exeptions to events that need a inmediatly interrupt, as mouse events do. Those last events can be placed everywhere in the sheet then, but can be executed inmediatly.

Hope you see what i mean.

Ty fro reading.

oopz

Ashley i made this .cap to eventually go with a documentation about 'picking",

Its only the first few lines,

BUT,

it does something that i did't expect.

Familys act differend than instances ?

Did you meant it to work this way ?

There are 3 reasons i ask for it.

Most starters programmed at least some in object based languages.

They think in "loops"

That was the base of his question, u see ?

he asked about "for each object" to pick objects .. wich looks like a "loop"

and this kind of questions return regular.

Adding this object would

A/ make the system easyer to understand and more close to your initial target... namely make a visual "game constructor" by pick and drop, and the action wizzard is a very important concept in all this. So bring the "picked objects" to the action wizzard is a plus !

B/ make .caps easyer to read

C/ its easyer to imagine what happens behind the lines, and thats half of the debugging. right ? Especialy when u can see wich objects are "picked"

Asley plz write a document about the concept of "picked objects".

My english still sucks.

Captain struck me with the light to see.

But i still think it would be easyer to be able to to pick a system object in the actions wizzard thats holding the "picked objects"

You could give it usable propertys too, like

That u can pick one of the objects in the "picked group" in the action wizzard, like u pick private variables, in a drop down menu.

You could give it the property "picked count" ..

and so many things.

I posted a .cap, that till some level demonstrates what you seek, in the uploads section. (help3 page 2)

The presents of "for each" confused me for long time. Long time i tried 'loops' for picking objects. Wich is the wrong aproach.

Forget "for each ", its usaly not usable.

1/ Loops u need

to repeat an ACTION ... (x times) ... till the condition of the loop is met. You can use the loopcounter to alter variables in the loop.

Like building a row of objects spacing 20 pixels, 10 objects in total

for loop "ThisLoop" 1 to 10

_________set objects x to .X + ThisLoops' counter * 20

2/ Pickin objects you do with events.

Most events that pick an object, pick a group of objects. Pick specifiek object you do with an event combined with a condition. The condion works as a filter.

You can also only use a condition.

Concrete:

If u have 2000 of the same instances on your screen

an event like

Sprite: Value 'PrivateV' Equal to 1

Will set all Instances with private variable 'PrivateV' Equal to 1 as picked ..

Every Action with this event will only target the picked Instances

How u do that ?

Add an event ...

pick the object

click on the tab private variables (on bottom)

click on compare private variable

pick ur private variable

give the value u want to be compared.

So un ur case ..

the event

Enemy: Value 'walk' Equal to 1

Will "pick" out all Instances called "enemy" only those that have the private variable "walk" set to 1, and will pass "the picked objects" to the actions combined to the event.

Those private variables you can set when

A/bringin the object into the layout in the Layout editor.

B/When u create an object in an action, the created object is "picked". Create u do in an action. So every next line u put in the same action block, targets the just created object. (Its picked)

Including setting private variables and the use of "self" in expressions.

C/And ofcourse u can set a private variable in every action anywhere, by plain targeting (pick) the object and set a private variable. But this u know.

So in general. Think out of loops for picking objects. Thats the wrong aproach.

Pick Objects with events. Most events return a group of objects. And filter out the object you need by conditons. Most Events pick objects by default. By instance, the collision detection will set all involved objects as "picked". When u use an action after this, the action will target the 'picked objects', in this case those that are involved in the collision

You can use Condtions alone too.

It took me long time to understand this, its not in the docs, and ne one explained me.

Most poeple who onces programmed in another object-based language, think in LOOPS and LOOPS and LOOPS.

Ashley made the looops we need to "pick objects' buildin, fast and automaticaly, all you need to do is "filter" the objects u need by conditions. Usaly based on comparing to a private variable.

Try to avoid using GLobal Variables. THey are slow, and are not as accesable and flexible as Private variables. Even prefer to make a Control object, that you only use for holding variables as private variables, over using global variables.

Also Use the Family option to make groups of "clones" or differend "instances". Events targeting a family sets the whole group of objects in the family to "picked".

Al u need is a condition that filters out the objects you need.

Like

Always

event: Sprite "red balloons"

____conditon: "red Balloons" smaller then 5

_________________________________action: destroy

Hope this helped you.

j0h

...