tarek2's Forum Posts

  • tarek2, yeah, took me a while to figure out that after you do "Simulate control", condition "Is moving" will still be false until the end of the tick. Not sure if this is a bug, but other behaviors (8direction, platform) start moving in the same tick.

    I see, it makes sense now why it doesn't work when is at the bottom but I still think is a bit unintuitive especially for new beginners but hey the behaviour its been around for some time now and no one reported it, so looks like no one has a problem with it lol )

    I don't use it normally I use "MoveTo" behaviour most of the time so for me doesn't bother me much.

    Also, another thing that I notice is that the Condition "is Not moving" is a bit misleading because it behaves more as "MoveTo >>>> on Hit Target"

    Example:

    Right Key its Down >>> MoveRight

    If you keep moving right none stop then still the "is Not moving" condition it will fire up on each tile even if you didn't stop moving so its look more like on "Hit Target" condition

    I will instead do it like MoveTo where it has the same thing but separated into two conditions:

    1-Is Moving

    2-Oh Hit Target

    The "MoveTo" >>>>("is Moving" << Inverted) condition it will not run unless you stop moving

    That's why the "TileMovement"-- "is Not Moving" it feels like they have both conditions in one

    Anyway, it was a good thread to refresh everything about "TileMovement" as I didn't use it since it came out.

  • Good Catch dop2000 "TileMoevement" is Not Moving on the Top of the other Events.

    That's why it worked some times yes and some times not, while I was moving the Events until I decided to replace it by distance.

    It looks like a bug to me as it doesn't make sense, it shouldn't matter the order where you place that "condition" either above or below, is gonna confuse many people and they gonna end up creating extra events unnecessarily, like me yesterday I had a very short time so I couldn't debug properly and I ended up adding distance to make it safe.

  • Np steve1984 glad it's sorted out)

    Ho yeah, I didn't even look on the Animation sorry, I thought you still have to work it out because it looked unfinished the events.

    However, if you want to count for every possible situation to get the right animation and Direction + Smoothenes you are gonna need to rework a bit more the events for that.

    I had to remove all the events because it didn't count for some situations

    Example:

    If you are in a corner-blocked by solids from the (Top & Right) and the player is looking up but you start pressing right it will not change the animation to "Idle_Right" it will just stay on "Idle_Up", this is just an example of many situations that you need to count for.

    If you want to see what I mean check the last Example from dop2000 it has those problems swell

    ========================

    Another Example:

    Will be if you going Left and you stop in a Tile and below you have two rocks on the next two tiles down so you start pressing down you cannot move because the path is blocked by the rocks but the animation still keeps looking Left even you are pressing Down.

    Basically, you want the player to look always on the direction it's pressing even if he cannot move to that Direction.

    Here is the new one with the Animation fixed:

    Check it properly because Not sure if it's 100% Bug-free:

    Construct 3 Project:

    https://www.dropbox.com/s/b9quj5d24613lnr/pushblocktest6.c3p?dl=0

  • steve1984

    Ho sorry I though the player needed to push first the rock, I see what you need now, see if this is what you need, this Tile buy Tile

    https://www.dropbox.com/s/rdkwpgcemiq40yv/pushblocktest3.c3p?dl=0

    ====================

    mm not sure what's going on but If you try to do a continuous movement instead of Tile by Tile like my last Example :

    It looks like there is a bug with the condition is not moving I think is triggering before the rock stops moving and sets the solid before time? this makes the player do small stuttering.

    The only way I managed to fix it it's by setting the solids manually adding a boolean and few more variables but it shouldn't need to add those extra things.

    https://www.dropbox.com/s/bxd4d7envpp5lu6/pushblocktest4.c3p?dl=0

    So you have two now, one continuous Moving and the other Tile by Tile, Pick the one you like

  • Interesting When The "TileMovement" Behaviour was released first-time I'm pretty sure that you couldn't move the object if it had the solid active but now I think that has been updated and you can move it even if the solid is active, which works much better now, you can move it without doing extra events.

    Or maybe I mistook for another behaviour, not sure now.

  • When you stand next to any rock the overlap its always true, if you stand next to 3 rocks it will pick 3 of them this is without pushing and just standing next to them.

    If you look at your gift, the first rock you push to the right then you go away to go around to the Second rock when you move away from the first rock you give space of one tile and that's enough to no overlap any rock so the "Event 26" can be true and make all the rocks solid.

    But when you coming back of pushing the second rock you never stop overlapping the rocks you pass next of both of them making them None solid because "Event 9" is true for each of them because you oberlap one by one, that's why when you push the last rock to the right both of the rocks are no solid, if you want to make them no solid you need to go away at least one tile far like when you first push.

    So the Logic is wrong plus you checking for collision constantly unnecessary when you are next to any rock even if you don't push, you could save collisions check for better performance.

    Maybe by doing something like this:

    Capx: dropbox.com/s/o2gq5furliw8hsp/pushblocktest2.c3p

  • tarek2 Oh, I missed the link to the project file. Disabling Sine fixes this, good catch!

    Oddly, this only happens in r190, it works fine in r189. Seems like a bug to me, two behaviors should be able to work together.

    Thanks, I thought the same shouldn't go that far to freeze the Game I think its a bug also, it should let you have both behaviours active, Though not sure what would be the end results of the object with both behaviours active probably will be flying around jeje

  • Event 19:

    when you create "LogOBJ" you make the object move with "MoveTo" behaviour but that object has always active the Sine behaviour and that causes the bug that freezes the Game, both behaviours are active at the same time and they try to manipulate the (X,Y) of the object creating conflict

    Solution: when you create that object before you make it move with "MoveTo" deactivate the sine behaviour

    ====================

    Bug:

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hi Tarek, thank you for the info. I'll look more into fullscreen modes. I'm new to Construct so I left it on the default. Changing the mode to Scale Inner does reduce the flickering on the player, but like you say it is transferred to the background. Maybe resizing the layout to fit the background exactly may help. I will try that next. What are the modes you use most often when building your projects?

    Hi DFORMS

    I use Scale outer or Inner for mobile Apps but this is for normal Games and for pixel art like you have I'm not sure what they use exactly I know they use different Mode and few more tweaks but I can't remember which one they use as I never did anything with pixel art, maybe someone that has more experience with pixel art and sees this post can give you the right Settings I definitely have no clue sorry for that.

  • Normally there is no problem using Lerp on the Camera but it looks like the problem is that your using "Letterbox Integer Scale" if you change the Full-Screen mode to "Scale Inner" it doesn't do that flickering on the Player but again the whole Background Graphics doesn't look that smooth, not sure what could be the solution.

  • Thanks a lot for the quick fix :)

    ============

    Since this is a world instance plugin, with a position, size, etc.. It takes ZOrdering into account.

    It might be useful to create a top layer called DEBUG, and put Renderbug inside of it. But yeah, the issue there is z ordering.

    Ho good to know Thanks

    Also, nice update to the Line Of Sight looks way much better now keep it up!!

  • Not sure if this is a bug but I think it should Draw the whole Rectangle of the sprite

    Picture:

    C3:

    https://www.dropbox.com/s/iziaafkqqhbj2t2/debugplug_test.c3p?dl=0

    Thanks for the plug is gonna be really useful, I use to do these things manually using events, its nice to have everything in one plug and ready to go

  • Thank you for your input. Your Layout seems chronological

    > 619_RM try this one see if it helps

    >

    >

    > https://www.dropbox.com/s/yz0nx7dthyes1s3/go%20back%20previous%20layout.capx?dl=0

    When you press buttons to go directly to the Levels yes is chronological just for simplicity but you are not interested in that, if you look again you are only interested in Event (4 & 6) I deliberately left it not chronological so you can implement it easily with your events, it's just two lines of code sudden be hard.

    I think probably you are looking for something else perhaps a full history? and not just the last layout you visited

  • Awesome, this definitely is gone a be really helpful, thanks for sharing

  • Really cool style

    I like how the Level design is clean and at the same time alive with the right combination of colours, you can visualize the whole Level view on the Screen in the first look without any distractions effects and explosions and all those kind of things

    Congrats and Good luck with the Game