As you said, the loop option in the animation should make it loop.

Post the capx (upload it to dropbox).

There's probably an issue in the setup, or you used a "on animation end" event that "blocks" the animation or something.

For the 2.) I guess you're using the 8 directions behavior, and set you should set its "Set angle" property to "No".

I'm getting more confused, I just don't see why the events with pretty much the same code works for family 2 but not with family 1. Both sprite and sprite4 are both on the layout too.

OK Ive taken out everything now, press A and press B, what I'm trying to say is why does press A work but press B doesn't?

The events work as they are intended to work.

When pressing A the only text that does change is "Text19" which refers to "Sprite5", the only sprite that has only a single instance.

So the value of the instance variable "sprite5.test2" effectively changes.

When pressing B, you can see the value of Text17 change. (Text17 refers to Sprite3 which also have only one instance)

But the fact that the values changes indicates the event is executed and works.

And when you finaly arrive on the event "On every tick", you only access one instance of Sprite, the original one, which values are 0.

The code works.

I think that what you think it is supposed to do is wrong.

Consider this capx, you will see more values displayed for every new instance made.

The original instance is displayed twice (the first two 0 values of each line).

That's because each tick I need to clear the text object by clearing it first.

Then you see it loops through every instances, and add its own value to the the current line of text.

Ashley: thank you for the clarification.

RockmanZero: In your initial capx, you use a simple condition "On every tick".

Then you refer to a Sprite object.

Due to how events work it picks only the original instance of Sprite (the one that is already in your layout at edittime).

So it is normal that the values don't change.

Also, from one instance to another, you affect the very same values (You start from 0 and add X for each newly created instance)

I'm under the impression that you would expect the values from the instances variables to be different from an instance to another.

You have to code differently then, use some global variables/arrays as reference in between the instances creations.

Ashley: The previous message was for you.

I can assure you there is no limit on the number of variables you can use anywhere in Construct 2.

I have no doubt about it. I think the original issue here is about instance picking.

My concern is more about what happens in that event:

<img src="http://dl.dropbox.com/u/36472942/construct/forumhelp/FamilyPortrait.PNG" border="0" />

Considering that "Sprite" is a member of "Family1".

There's already an instance of Sprite on the layout which instance variable values are 0.

When I click on an instance of "Sprite" (a newly created one, with affected values to the instance variables (not 0)), the values are correctly displayed when using "Family1.VariableX"

But using "Sprite.VariableX" seems to display the values for the original instance only.

That's quite surprising, since it's in a "On Family1 clicked" and "Sprite" is a member of "Family1".

I'd expect, when I click "Sprite" (but that I used the event "On Family1 clicked"), that "Sprite.VariableX" refers to the instance variable values of the current picked Sprite, not the original instance.

It's obvious that clicking on "Family1", you should use "Family1" in the actions too, but after all, "Sprite" being a member of "Family1", I'd expect the actions with "Sprite" to act on the "Sprite" instances picked, in that case, the "Sprite" instance I clicked on, and refered to as member of "Family1" in the condition of the event.

Am I just missing the point of Families here ?

Are they considered as an object type in their own right meaning that you can pick the family but that doesn't pick the family members by default ?

1: like Physics, manually adjusting the Platform behavior's position confuses it. [...]

Solution: use 'simulate control' to control platform behavior, instead of manually setting position.

That's good to know, thanks.

2: 'is on screen' was always false for the first tick in a layout. So negated 'is on screen' was always true for the first tick. This is a bug and has been fixed for the next build.

3: OR blocks did not work correctly as subevents to 'for each' loops. This is a bug and should also be fixed for the next build.

Nice .capx, got two fixes out of it :)

Hehe glad I reported it then ^^

Good to know the "OR" block should be fixed too.

Capx

Are you sure you went through the Beginner's guide for C2 ?

The part about the HUD is pretty much the answer.

Edit: Oh yeah also, I didn't download your file, because of boring filehost which requires clicks and advertisment and 3.9mo, it's probably already too much as far as download size goes.

Commented capx

1) There's no "best", it just depends on what is the more practical for you as a maker.

For the end-user it changes about nothing.

2) It depends on the type of game, on the resolution of the game, on what's more practical for you and for the end-user in matter of download-size.

3) If the obstacle is not supposed to move, I guess you can use a single sprite which displays the image.

In the end, what matters in collision is the collision polygon. Hotspot don't exist in C2.

Using an invisible sprite/box over another textured sprite can be useful if you want several collision areas on your texture (since a collision polygon is limited to 8 points anyway).

So in the end, it depends on the game, the type of obstacle and the intent of the maker.

4) It is just what's more practical for you and your coding.

It also depends on the game you're making.

I strongly suggest you to read Ashley's blog article about optimization, it contains what really makes a difference.

In the end the "what is best" type of question is often answered by "it depends on your taste and abilities", what's more convenient to you as a maker and if it fits in the logic of the game you're currently making.

The code is simple enough, but it's not obvious what it is supposed to do.

Also, nowhere in your code do you refer to families, only object types.

Replace the event4 condition with

Mouse: on object clicked on Family1

and also replacing the actions that display the Sprite.VariableX to displaying Family1.VariableX

Modified capx

When you create a new instance of Sprite by drag-droping (strange way of doing to by the way, the drag drop behavior allows you to use a "on start of drag" and "on drop" conditions, suppressing the need for the mouse plugin) Sprite2 and then click on the newly created instance, it displays correctly the values of variableX.

You can notice in the code, I haven't switched all actions to Family1.VariableX, and those still relying on a direct call to Sprite only display a 0.

I don't know if it indeed displays a bug where a family variable is seemingly applied to an object type but can't be accessed directly from the object type, or if picking a family in condition is buggy and trying to access an object type amongst the picked instances doesn't work.

I hope Ashley can bring some clarification there and see if there is indeed a bug or just misunderstanding.

From what I've read on the internet along time, rebuilding from scratch is not something exceptionnal or rare.

A lot of developers tend to say by the end of their game that they rewrote it at least twice along the development process (from the prototype to the finish product), and it proves especialy true in my experience when, as you've mentionned, you learn new tricks and "good ways" along time.

You find yourself thinking about the game and the code of the game in the new light of the new knowledge/experience you have.

Arima's focus on refactoring is a way to cope with already a lot of written code when going back from scratch is hard on the moral/motivation level and that some of this code works as an engine or is good/stable/strong enough to be reused.

On the other hand, in C2, I've noticed that actualy the less code you have often means the better it is coded.

It might be the same in every code languages, but I only experienced it in C2.

On start of layout => Mouse set cursor style to invisible

Every tick => Sprite set position to mouse.x; mouse.y

Why would this be?

You never have tried to work in a team, have you.

A hundred people will have a hundred opinions and will discuss every last detail.

Even if there's a team leader whose role is to make the final decision in the end that the team will have to go by, it's just how design teamwork works and it makes it a lengthy process at times.

And of course, thank you Ashley & Tom, keep it up, C2 is awesome, etc...