Borghi's Forum Posts

  • well, i just tried this. the simpler way I found is to program the whole set of actions with the condition being "every 1 second". each event takes places between a wait of 0.25 second, and it's 4 events, so the total gives 1 second. So every second the set repeats giving the illusion that it loops.

  • hi!

    I have an sprite that must make this things over and over when created:

    wait a second, rotate 180°, wait again, flip

    and then repeat from the begining until the end of the world.

    So, I have all those actions programed one under the other and lack one last action that says "start again from the begining".

    how do i do that?

  • Thanks!

    yes, it spawned in the same direction.

    Just to know: Couldn't find how to use the second option you mentioned. can't find a way to refer to a parent object. Is it through expressions? when i am writing an expression it never suggests the word "parent".

  • Hi!

    This is not exactly as the title says but comes close.

    I have an object that creates another object when it hits a solid. What I want is the new object to have the same angle set (when created) that the father object has. how do I do that?

  • well! finally i had time to try this. Sorry for the huge delay.

    I still doesn't work. I've tried both methods suggested here.

    First, I did this:

    -when "PLAYER", is olverlapping the sprite "ZOOM1", set layerscale:

    -layer 1

    -scale:

    clamp(LayoutScale-1, 0.6,LayoutScale)

    This was the result: when the player stepped inside that sprite the scale went to 0,6, but did it instanctly, without a smooth zooming, and when the player got out of the zone it returned to the normal scale.

    then I did the other one:

    -when "PLAYER", is olverlapping the sprite "ZOOM1", set layerscale:

    -layer 1

    -scale:

    lerp(layoutscale, 0.9, 1*dt)

    It did the exact same result. the change was instant.

    What am I doing wrong?

  • thanks! but I search that (or some varibale) and nothing appears.

  • Hi!

    I'm making a sidescrolling "contra "game.

    what i want is the game to have a different zoom value in different parts of the stage.

    something like this:

    when the character is in contact with the "zoom value 1" (invisible) sprite and walks right, the zoom slowly scales to a certain value to stay like that until the char hits another zoom value sprite. in this case, "zoom value 2" would scale it to a bigger scale. is that possible?

  • somehow I can't make that file work. Construct says it was made using version 165, but 163 is the newest I can find here.

  • great!

    I even managed to make the scroll X work only when walking right by creating a sprite that follows the position of the player but only if it walks right. when the player goes left it leaves the sprite behind so it gives the illusion that the player "pushes" the scroll sprite. By making the screen scroll to that sprite it gives the same sensation of contra, where you can go right but the screen won't follow if you go left.

    now I want to see if i can do the same but with zoom. I mean, make the layer go smaller progresivelly as you advance. Just the same thing you helped me with regarding the Y scroll but with zooming. But I think I'll create another topic on that in case i can't pull it off.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • you're right!

    the problem was the collision condition.

    now, regarding the PLATORM IS MOVING condition, the problem is that if you stand still and jump (without going forward), the scrolling will still happen. I've tried changing it for "compare speed" but it doesn't discern between X or Y speed. the ideal would be to replace the PLATFORM IS MOVING with something like: "sprite X speed is not zero". Any ideas?

  • damn, somehow I can't make it work.

    This is what I've done.

    My player sprite is called PLAYERBOX and the scrolling sprite is called SCROLLY

    I set this event:

    PLAYERBOX on collision with SCROLLY/PLAYERBOX platform is moving =

    lerp(CanvasToLayerY(0, WindowWidth/2, WindowHeight/2), PLAYERBOX.Y, 0.05)

    To all that I added an everytick event to scroll X to playerbox X

    What happens is that once the playerbox touches the scrollY the screen scrolls a little to the downside and stays there. it also does it instanctly, no transition. If you get out of the collision area and enter again this happens again, so every time you do it the screen goes lower.

    I've tried taking out the platform condition but nothing changed. I've also tried replacing the PLAYERBOX element in the expression with the SCROLLY but still doesn't work.

  • How do I keep my character inside the screen?

    let's say this is a game like CONTRA where you walk to the right and the scroll follows you. but then you go back to the left and the screen doesn't scroll in that direction to keep you advancing, and you can't go beyond the screen to the left.

    How do I keep my character from going beyond the screen to the left?

  • oh gawd. I really didn't get a thing.

    But thanks, really, for trying to explain it

    maybe some day I'll get it.

  • works!!

    Thanks a lot.

    how would this work?

    I mean, you have this expression:

    lerp(CanvasToLayerY(0, WindowWidth/2, WindowHeight/2), Sprite.Y, 0.05)

    I've searched on the help files of construct but it doesn't mention "lerp", or I couldn't find it. What is it used for? how would be the overall meaning of this expression?

  • It works

    thanks a lot!

    I wanna ask 1 more thing (I don't know if it's possible to do):

    Is it possible to have the scroll shit only as the player moves? I mean: when he gets to a certain zone the Y scroll shifts but only if the player keeps avanzing.

    Maybe it's something like having a path made of the same sprite over and over and telling construct to keep those sprites out of the screen. so, the camera would adjust going down, let's say, to keep those sprites beyond the upper limit of the screen. So, that way you can mantain the camera in the height you desire. Is this too weird?