Alcemon's Forum Posts

  • When you create a new object it is automatically picked, so you can refer to it straight away in the loop.

    This doesn't seems to be the case when the sprite creator is the same as the created sprite (check out the cap on the first post for an example).

  • Unless I misunderstood the question you just need to run a loop.

    +For "" from 1 to 5

    -Create object at <x> + loopindex("") * <distance apart>

    then maybe set IDs to loop index and go from there.

    This would work handsomely (as per the link to the topic in my second post) if the X,Y of the instances was the only thing that I wanted to change (as position can be passed as a parameter to spawn and create).

    But if you want to change any of instance variables or things like mirrored/flipped, once again you run into the problem of not being able to pick the newly created instance.

  • Thanks for the replies guys, unfortunately is not as simple.

    Alcemon - have you tried using UID's and a variable somehow?

    This solution has two problems.

    1) I cannot pick the created instance (this is the main problem), so if try to get the UID by doing something like

    temp_var = Sprite1.UID

    I would end up storing the parent UID not the child

    2) The second problem is that last time I tried something similar I realized that the UID is not set until the cycle after something is created. So trying to store the UID right after something is spawned/created would not give you the correct value.

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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".