Here is a link to a related topic but it's not quite the same.

scirra.com/forum/instance-spawn-another-instance-of-itself_topic48162.html

The problem I am having is related to picking the created instance when spawning from that same sprite.

Hello all,

As the title says I want to spawn several instances of the same sprite (say Sprite1 from the example projects).

While just spawning instances of the same sprite in succession has been covered in another post in the forums, I am interested in spawning a chain of exactly 5 sprite instances.

To do this we need a an instance variable ("piece" in the example projects) that gets incremented in each spawn.

The problem is, I cannot pick the newly spawned instance! When I try to increment the "piece" instance variable of the spawned instance, I actually increment it on the spawner.

I have even tried to create a sprite family with only Sprite1 as a member (Family1 in the example 2) to use as an alias but this did not work.

Example projects

Instance chain

Family instance chain

Any help would be appreciated

I see, in a more conventional programming language an exception would be raised when checking the condition on nonexistent Sprite2 instances (so we would not even reach the "else" part).

Thanks! Changing the topic title to "not a bug", hopefully it will get moved somewhere better.

Link to .capx file (required!):

docs.google.com/file/d/0B20uobjbjbtgeFR0eldEQjN1Y2c/edit

Steps to reproduce:

1. Run the capx, press any key

2. Despite the fact that Sprite2 was destroyed on pressing a key, it will still keep adding "-"s to the textbox (forever, this is not a single cycle thing)

3. A zombie Sprite2 Object with UID 0 and its "death" instance variable = "" (empty) is the cause of the previous behavior

Observed result:

Sprites (or objects more generally) keep entering events even though they were destroyed.

Expected result:

Once destroyed sprites should not enter events.

Browsers affected:

ALL

Operating system & service pack:

Win 7 Enterprise SP1

Construct 2 version:

R116

Thanks for the answer.

It's probably worth to explain this fact to newcomers somewhere to save them some debug time and to make their lives easier.

Well...at least this forum thread should pop up now when searching for the issue <img src="smileys/smiley1.gif" border="0" align="middle" />

Yes, I figured as much.

If you use only functions/methods specifically aimed at angles you should never run into this problem but as soon as you start treating angles as a "normal number" you will probably run into unexpected behaviors like this one.

The problem is that I cannot figure out if this is a bug or intended. At least I could not find any reference or warning to this behavior.

My apologies if this is a documented/normal behaviour. I could not find anything about this in the Manual/Forums.

Work around is to use anglediff instead of simply comparing with operators.

Link to .capx file (required!):

docs.google.com/file/d/0B20uobjbjbtgbjRaa2d1ZTdWOEE/edit

Steps to reproduce:

1. Run the capx

2. Notice that the result of the first comparison is "1" (true) and the second is "0" (false)

3. Check the objects angle and the comparison code

Observed result:

The first comparison is true, and the second is false

Expected result:

Both should be true

Browsers affected:

This is most likely browser independent

Operating system & service pack:

Windows 7 Enterprise SP1

Construct 2 version:

116 (64bit)

Thanks a lot for all the hard work.

Hello, just wanted to confirm that indeed Pin does not interact with the scaling of the sprite (probably it only does with position and angle).

I was planing to pin a parent object to a "long bar" sprite and then pin the bar to a child object. Once this was set, I thought I would be able to increase the distance between parent and child only by increasing the length of my long bar sprite.

No such luck though, going to use trigonometry + the 'update at each frame' method to achieve this.

A final tip for this.

If there is an effect that does not preserve alpha and you want it to preserve alpha, go into your effect directory and find the name effect you want to edit.

1) Open <effect_name>.fx

2) See if you can find any of the following lines of javascript code:

   front.rgb /= front.a;

   front.rgb *= front.a;

3) Comment them by adding "//" to the beginning of that line

4) Save with a different name

5) Open <effect_name>.xml and make sure to change the id that its found between "<id>" and "/<id>" to another value (each effect is required to have a different id).

6) Save with the same name as your .fx file

7) Close and Open C2 and use your new alpha preserving effect

Of course, this does not work with every effect but I could at the least apply it to the "brightness" and the "vignette" effects that I wanted to use in my project.

When the speed is 0, the angle of motion = 0 so you have to set the speed before setting the angle of motion.

Sorry for necroing this thread but I just wanted to bump it up to request this important detail to be included in the manual at

Bullet Behavior

Lost a good hour testing and looking at the manual and trying stuff before trying finding it in the forums <img src="smileys/smiley19.gif" border="0" align="middle">

Thanks for the reply. Set color is slightly different though, as there is no value in which the object is presented as it would be normally (Brightness = 100 means no change applied).

In any case, is there some sort of rule or reason for preserving alpha on some color effects and not in others?

No biggie though, worst case scenario I would create another effect "alpha preserving brightness" on my own.

Thanks again and happy new year!

In the meantime, the "exposure" effect seems to also do something similar and it does preserve alpha. Hopefully this is not that much computationally intensive than the regular "brightness effect".