simplify some things

hey !

oopz .. since Captain orderd me to stay on topic ! Ha ! i guess i make my Own.

(Big smile)

because, i have a suggestion.

Oh now AGAIN, you think? LOL .. sorry ?

Ok lets build this up a lil, starting from an easy example.

the "for each object (ordered)" event loops trough objects you picked and based on an expression you choose.

All ok, and i so like that event. But then ...

Then you come to make an action. And the first thing the action wizzard does is ask you "wich object"?

And then i have something like. Uhhhh, staring at the screen, why do you ask Sir Wizard ?

All the objects the "For each" loops trough, ofcours !

But the Wizz will insist that you pick an object.

When u change this later, you have to change the event AND the action.

And this is general for a lot of event/action configurations.

Ofcours it is inpossible to leave the 'pick an object" out of the wizzard.

When u dedect a collission between 2 objects, or between an object and a family,

the action must be able to adress the right object.

And yet,

i have something like, this is a lot "not meat, not fish"

now to adress this, and to simplify things. Can i suggest 2 thngs.

1/

For the actions, the possibility to leave the "pick an object" field blanc.

Knowing the action then will do its thing on every object picked by the event.

This will be very handy when the event is made with several conditions. And when the event picks more objects, not certainly beeing the same instances.

2/

A little more power to the event to compensate. Just 1 event more.

"pick object (x) "

to use like this

(event) on collision between "bottom" and "ball"

___(sub event) pick "ball"

________________________________________(action) .x = .x * -1

___(sub event) pick "bottom"

_____________"bottom" y < 100

________________________________________(action) flash 8 times 2 frames

This will also make the way to events that we dont have yet without obstacles.

We have no way to pick every object on a certain layer yet. And make an action adressing all those if we could pick em.

There is no "any object" yet.

1/

For the actions, the possibility to leave the "pick an object" field blanc.

Knowing the action then will do its thing on every object picked by the event.

This will be very handy when the event is made with several conditions. And when the event picks more objects, not certainly beeing the same instances.

This would quickly become annoying, consider if I wanted to use some System actions in a 'For each ordered', the object field wouldn't be there.

2/

A little more power to the event to compensate. Just 1 event more.

"pick object (x) "

to use like this

(event) on collision between "bottom" and "ball"

___(sub event) pick "ball"

________________________________________(action) .x = .x * -1

___(sub event) pick "bottom"

_____________"bottom" y < 100

________________________________________(action) flash 8 times 2 frames

Why not just do:

Collision between "Bottom" and "Ball"

Ball: .x = .x * -1

(subevent) "Bottom" y < 100

Bottom: Flash 8 times 2 frames

Or am I missing something? These objects picked in the collision will be accessible in the subevents too.

We have no way to pick every object on a certain layer yet. And make an action adressing all those if we could pick em.

You can use 'Object is on layer' to select every object on a layer.

the "for each object (ordered)" event loops trough objects

...

Then you come to make an action. And the first thing the action wizzard does is ask you "wich object"?

You just pick the same object as you are looping through! Is there something difficult about that?

This is like any other scripting language, where the object is mentioned twice in the loop, eg:

for (ObjectA in ObjectAInstances)
	ObjectA.X *= -1;[/code:3at97xq8]

Note the two references to "ObjectA" there.  Making it automatically pick the object currently being looped is impossible, because one event can loop two objects, iterating every combination of the instances:

+ For Each ObjectA
+ For Each ObjectB
-> An action MUST pick an object - Construct doesn't know on its own!

If you choose an object which is NOT being looped in the object picker, it is like doing this in a script:

[code:3at97xq8]for (ObjectA in ObjectAInstances)
	OtherObject.X *= -1;[/code:3at97xq8]

In other words, the action is simply done as many times as there are ObjectA instances.  In my opinion, this makes perfect sense and is completely logical!  It's impossible to leave the 'pick an object' field blank.

[quote:3at97xq8]"pick object (x) "

As Rich said, this condition has no effect.  The 'On collision' event already picks the two objects.  Rich's example is identical, and exactly what you need.

for "object on layer" you will have to pick an object.

Its not "any object" on layer.

To launch the "object on layer" event ...

You do

new event/condition

pick an object

choose "on layer" (for the object u picked in the wizard)

thats not close to "any object" on layer x

right ?

Annoyend ?

The object field in the actions wizzard would be still there. We need it in some circumstances.

But it would be so much easyer to leave it blanco when combined with loops that pick more objects.

Mostly loop events, collision events, overlap events and (more importand) behaviour events. Knowing the action will adress to all the objects picked. And in case of a loop , the objects picked by the loop and in order of the loop.

You say its possible to pick all objects on layer (x) by an event.

Now how do you attach an action to that ? To adress all those objects ? When the action is forced to pick One certain object .. or instance of an object ?

(besides give ALL the objects a family name)

it is ofcourse possible this way ...

Assuming there are only 4 objects and there instances in the game, namely ...

"right_block"

"left_block"

"top_block"

"bottom_block"

then this

(event) "right_block" on layer 7

_______or

______ "left_block" on layer7

_______or

_______"top_block" on layer 7

_______or

_______"bottom_block" on layer 7

_____________________________(action) ?????????????????????

wich action would you attach adressing all objects picked by the evening blok ?

I think ... the rigth answer is ...

In the event sheet .. click on "add action"

Pick any object .. but be able to leave this field blanco ...

code the actions ... as needed

but since the actions "object" field is blanco, it will run on every object picked, ..

in this case

adressing

all

"right_block"

"left_block"

"top_block"

"bottom_block"

's

on layer 7

wich action would you attach to this ? I could be wrong, and in fact that would be nice !

Ofcourse, i could return to the solutions that i suggested in earlyer posts ...

and now i think about it ...

would't that be easyer ? rich ?

to have an system object "event picked objects"

then it would be so easy

(event) "right_block" on layer 7

_______or

______ "left_block" on layer7

_______or

_______"top_block" on layer 7

_______or

_______"bottom_block" on layer 7

_____________________________(action) event picked objects.x +1

and be done ...

and Major inprovement !!! would be !!!

when i later in the developping of the game, decide to take the object "bottom" out ...

i take it out the event, but i dont have to reprogramm all the actions.

hope u see what i mean . or that some one writes it in good english ..

j0h

j0h, you are describing exactly what families do and what they're for. Why wouldn't you put "Left_block", "Right_block", "Top_block" and "Bottom_block" in a family "Blocks", and use the event

+ "Blocks" on layer 7

--> Set X to ...

You may argue you'd have to put every Sprite in your game in to one family, but this is necessary. Any large, complex game will have sprites for completely different purposes, ranging from the player, enemies, interface, terrain and effects. Applying events indiscriminately to all of them would not be useful, and you would want to specify exactly which, by using a family.

If there WAS an 'All sprites' type family automatically built in, you'd probably run in to some serious problems quickly. If you code 100 events using 'All sprites', then you add another Sprite you don't want to be affected by all these events, you have to add a family to all the objects you want to affect, then edit 100 events! It might be boring going through adding a family to a lot of objects (perhaps a Family Manager dialog could be added to make this process quicker, eg. mass-selecting objects and adding them all to a family in one go), but I think it's the best solution, because it gives you the option of not having a Sprite affected by those events.

Point taken.

And i agree, about the running into problems when having 100 "all sprites" running.

Yes i can see that.

But.

You can not adress behaviours by pickin a family in the wizard.

In other words,

the tabs that represent the behaviours attached to an object,

when pickin that object trough its family in the wizzard,

dissapear when u adress that object in the wizzard trough its family.

This made me run in more problems then those u point to.

Yet i think its normal that the behaviour tabs dissapear when u adress the object via its family.

Thats correct and logic.

Stays the problem that Familys are not a full substitute to adress a group of objects in an action to do something with.

On the other hand.

If i understand the way construct is made a little.

Somewhere in the code that makes up construct. You have a pointer that points to "the objects picked" by the events.

Am i right by this ?

So all u have to do is give that pointer an accesable state ? And let it show into the wizzard ?

This pointer i think, is always there, is needed and essential for the working of the events.

Just at this moment it is for me as "constructor" working behind the scenes and not acessable.

Am i right by this ?

Its there allready, make it accessable and nothing changed in the risk for running into problems ?

At this moment it acts like. Picture this: You made a nice physics system. When the objects fall, they do this by a build in gravity. But you dont give me acces to the force of gravity !!!

Thats would be the same situation.

And TY for giving me acces to that force. Its there. Its needed to make the system work. So yes you can as well give me acces to it, to use it and to alter it.

And yeah i am a stubborn, lol .. sorry ?

Well, there's a bit of an undocumented feature here. If every object in a family has the same behavior - ie. family 'Friendly' consists objects A, B and C, all of which have the 'Bullet' movement - then the 'bullet' tab appears for the family as well in the dialog. If one of them has it missing, it won't appear - if it were there, a 'Set speed' action for the bullet can't be applied to an object that doesn't have a bullet movement, hence the requirement that all objects in a family have the same behaviors for this to work.

I think it might crash in the current build, but if it does, it's fixed for the next build.

I haven't documented this feature anywhere yet. But I hope when/if it works, it satisfies you

Well I be danged !

When did u change this ? Cuz last time i needed this, the behaviour tabs where not present in the Familys.

And it was the 1st thing i checked in 95.2.

Um uhh .. of course i check b4 gooing against you, and yes they are there at this moment.

Guess i did something wrong earlyer.

I test them trough when i am done with this "game".

At the moment i am cloning pac-man, to illustrate ..

grid based movements ..

grid based decissions .. and the speed boost they bring

turret based tracking

And because i agree with you that cloning old classic games is a good way to learn and teach.

its up to you to use my .caps as tutorials.

If you clean up my tetris, dont think its a bad tutorial, but its dooing work-arrounds that are not

needed in 95.2. I might pick that back up soon. Mah girl is happy with it as it is now.

now if you have time, solve this too for me ?

it keeps bothering me .. it erks me to hell !!!