99Instances2Go's Forum Posts

  • Ah ok. One of the many ways.

    https://www.dropbox.com/s/yx2fmprpiqdqy ... .capx?dl=0

    Using the MoveTo plugin, behavior-moveto_t63156

    I was a bit done with all the lerping 2day.

    As you see. You can not lock the interactivity of the player up in a loop. And you can not lock this moving (that takes time) up in a loop. A loop happens in the same tick. This movement happens over several ticks.

    Normally i wouldo this with instances of the same sprite for the player, but i feel that you learn more of it (for now) if i use two different sprites.

    Have fun coding.

  • Should work, if you only pin position (not angle). Else the pin will overturn.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • What do you mean by 'browser game' ?

  • You can use HSL. & Since your colors have all kinda the same brightness & luminosity, you only have to lerp the Hue.

    But, i have no idea how you gonna end up with the same color as the background colors, that way.

    The Hue is more like a clock.. Its units are rather in degrees on a color wheel. Should be.

    A hue of zero degrees color should be red. 60 degrees should be yellow. 120 should be green. 240 should be blue. 360 should be red again. This also means that if you change the hue from 240 to zero, you see the color change from blue, over green, over yellow, till it is red.

    But, we talk about an effect. An effect is changing the existing sprite (its existing color).

    So, the color is actually 'the existing hue of the sprite, as made in the sprite editor' + 'the hue in effect'.

    Again, should be.

    This would mean that ...

    If the sprite = blue

    ... the resulting color = hue for blue + hue in effect ..

    .. or

    the resulting color for hue for blue + 360 should be blue again.

    And that is not happening at all, test it and you will see.

    If you start with a blue sprite, and set the hue in the effect to 360, the resulting color is close to black.

    And that should for sure not happen, because that comes down to a change in the luminosity.

    Besides that. I dont understand the units for the hue in the effect.

    If you start with a red sprite, a hue of 30 gives already green as the resulting color.

    That should be (if hue is in degree units as used every where else, virtual everywhere else) red sprite + 120 as value in the effect.

    Now lets assume that 360 is scaled to 100. Or 100% = 360 degrees. This is done a lot in the effects.

    Then, starting from red ... green = a 33 hue in the effect. Okay, that seems to hold.

    But, then staring from red, a hue of 100 should give red again. Again. This is not happening.

    So the last 20 % of the range 0 to 100 % for the hue value is completely useless.

    I have the problem with luminosity. It is an effect. So the resulting luminosity = the existing luminosity *+-%/ the luminosity value in the effect. I just did not figure out this operator (*+-%/) yet. I have really no idea !

    So excuse me for not being a big help.

    Nevertheless, lets do it.

    https://www.dropbox.com/s/0mybm78ildju2 ... .capx?dl=0

    Same thing, but now with HSL.

    Notice 3 things.

    1/ the starting values for the 'dude' can not be 0,0,0. They must kinda match red. The color we start the 'dude' with.

    2 / I never get those nice pastel colors matched. Because i dont understand the luminosity values. Mayby you can. My understanding of color wheels dont match at all with this concept for luminosity.

    3 / purple is out of the box, because its matching hue value is bigger then 80. So its somewhere in the complete useless range hue = 80 - 100 %

    Hope this helped you, it did not help me, because i had to dive into this HSL effect that hate from my toes up into the unlimited sky.

  • It will always be a 'browser game'.

  • Are you rotating the layer/layout ?

  • Why would you do this in a loop ?

    Are you aware that the events already run in a 'big' loop ?

  • Is 'Fade' working for a 'text' object ? Can you show me that plz .?

  • let's say my first pick will be instance color 1 and we start from line 7 to make it easier

    -line 7: I overlap color 1 so we set it to touched and this is the one in the pick list

    -line 8: checks color 1 against "previousTouched" from line 5 wich at this moment its still -9 so is not the same then runs the code

    Next thick:

    line 5: we have still picked color 1 on the list so we set "previousTouched" to color 1

    line 6: set all touched to false so "previousTouched" becomes = -9 again Nope. Only 'touched' is set to 'false'. There is totally no action that is changing 'previousTouched' to anything in line 6

    So 'previousTouched' remains set to color 1

    line 7: I overlap color 2 now so we set it to touched and this is the one in the pick list

    line 8: checks color 2 against "previousTouched" from line 5 wich at this moment its still -9 because on line 6 we reset it -9 as all touched becomes false Nope, 'previousTouched' remains set to color 1

    etc.......all the thicks will be the same

    That's why I'm confused when on line 8 we compare against line 5 "previousTouched" because it looks for me like its always -9 before reach line 7, because it meets with line 6 before 7 and set them to -9 always

    I know I'm wrong with something but I don't know were

  • The 'Pick overlapping point' picks the 'color' that is under the touch. For this 'color' we set the state touched to true. This is a change. Because in the previous line we set 'touched' for all 'color' to false.

    Since it is a new pick, the expression color.UID returns the UID for that newly picked color.

    Now we compare that color.UID to previousTouched.

    previousTouched is set to the UID of the previous picked 'color', it is set before the color.UID is changed due the new pick, so it is the UID for 'color' that was picked in the previous tick.

    If we compare them, we compare previous against current. Read is as ...

    EVENT 5

    If there is a color picked in the previous tick (is there one 'color' with 'touched' = true) , set previousTouched to color.UID. If the condtion is true, the picklist contains that one 'color' with boolean 'touched' = true. And the action has a picked 'color' to run on.

    If the condtion is not true (there is no 'color' with 'touched' = true), then the default (- 9) is just unchanged. Because the actions in event 5 have no 'color' in the picklist, if there is not one 'color' with 'touched' = true. The picklist will be empty. And the action has totaly no picked 'color' to run on.

    So, if there is a touched 'color' then previousTouched = color.UID, if there is no touched 'color' then previousTouched = -9.

    Since at this point no boolean 'touched' changed yet, color.UID is also = UID for the 'color' that is picked in the previous tick.

    EVENT 6

    Sets the boolean 'touched' for all 'color' = false.

    EVENT 7

    Sets the boolean 'touched' according the new situation.

    Since touch changed position, it is possible that a different 'color' will be picked.

    'Pick overlapping point' looks what is under the touch. And sets the boolean 'touched' for the picked color to true. We need this boolean in the next tick, it will be the previous in the next tick.

    As this point we again have 1 'color' with the boolean 'touched' set to true, after we have we set the boolean for all 'color' to false in the previous event(7). That is just an easy a reliable sorta kinda 'else.

    In stead of

    ... If under touch .. set to true ... else .. set to false (that is so difficult to do)

    i do

    ... blindly set them all false .. set the only one under touch to true (so gd easy logic)

    Now we need to know if it is the same 'color' as in the previous tick, or is it a new 'color' ?

    EVENT 8

    So event 8 compares the UID of the PICKED color (color.UID) to UID of the color from before that pick in event 7 changed the situation.

    We only need the action to run if there is a new color choosen compared to the previous tick.

  • The moment that you spawn the bullet, it is not moving yet.

    The bullet acts like a car-in-reality.

    When the car stands still, turning steer will not change the direction of the car.

    Setting angle of motion action is like steering the bullet.

    But, the angle of motion aligns to the actual angle of the bullet, when the bullet is not moving.

    Same is true for the car, re position it with a forklift, and you can change its direction while it is not driving.

    So ...

    Spawn the bullet.

    Set its angle to ship.angle +- 45 (sprite > Set angle)

  • 'Make' a collision is not different.

    'Detect' a collision can by done by

    ... (sprite) On collision with (Sprite <-- same object)

    or (when you bring the sprite in to a family)

    ... (sprite) On collision with (family)

    Question is : what you wanna do after the collision ?

  • Text objects are form elements. They float above the game canvas.

    They do not know 'opacity', the fade behaviour has no effect on them.

  • Its Speed in pixels per second, so it is dt corrected.

    https://www.scirra.com/manual/92/custom-movement

  • Dont stop being a noob. I would not have learned 1 thing without being a noob myself + combined with all the other noobs on this forum. The main goal is to learn (for me it is)

    I acted (yeah my toes are to long, i apologise) as i did because i took you as 'no noob'.