dupuqub's Forum Posts

  • So, theres this cube moving linearly across the screen using a timeline, and it dislocates about 10 pixels in the X axis, and about 3.5 pixels in the Y axis.

    Consider these values represent timescale = 1.

    So, to my surprise, when I set timescale to 0.5, it actually makes the dislocation in both axes to be a quarter, and not half.

    I know my brain is probably not mathing right, but can someone explain to me why? Im very confused.

    For anyone interested in seeing the example running:

    drive.google.com/file/d/1kKKSs1NWihDnfvbXudm2XPHklDcwFRBG/view

    Thank you in advance

  • I believe this problem only happens when the mouse, while holding the sword, moves outside the viewport and then moves inside again. I don't know what internal processes are happening in the physics engine to make this weird glitch, but when you go fullscreen the issue is not present anymore (since the mouse can't leave the viewport), so maybe it is not a big problem.

    I couldn't find a way to solve it though, I'm sorry about that.

  • its the speed in the animation. Change it to zero.

    You ask to select only if "frame = 0", but the animation starts and changes to the frame 1.

    :) cheers

  • construct.net/en/make-games/manuals/construct-3/plugin-reference/filesystem

    This link is probably helpful since it deals with file manipulation.

    But feel free to ask any clarification, I just think it's worth to try and see what happens first.

  • The following file has a simple example that may help you understand the building blocks of what you are trying to do.

    drive.google.com/file/d/1jU1yCX-pjCu-le8eKszBk6FKRdu6TUr3/view

  • Ok, your point is valid for when the car goes crashing down, and it makes me think that, yes, you are approaching it the right way then.

    But considering this approach, the car is in fact moving up the layout, so instead of setting a timer to adjust the gravity intensity, I would be more inclined (lol) to use the player's Y position as a reference point for it.

    For the rest, it seems pretty interesting, I'd actually be stoked to see what you come up with.

  • Since it's topdown, I'd never use physics in a setting like this.

    Probably the best solution is just making a treadmill, where objects are moved from top to bottom, and the car stays in the middle. The apparent car speed is actually how fast parts travel the screen.

    Objects that go outside boudaries can be reused sending them to the top, or just destroy the bottoms and create new top parts to descend.

    To simulate the roughness of the terrain, personally I'd just add details to the art that suggest it, and make the terrain move slower to the bottom.

    If you like the physics for the visual appearance of the movements, I'd suggest combining my first suggestion with the Tween behavior to simulate the possible "skid" effects you'd get on physics.

  • hahah just realized theres a tiny game going on in my example, theres a way to stack the boxes so you can climb out of the walls lol

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I believe what you're looking for is making a top layer for your UI, and then you change its parallax to "0,0" so the text is always onscreen.

    Hope it helps

  • Ok, I had a deeper look in the code, but I had a lot of trouble following what was going on, so I tried to strip everything to the bare minimum.

    I made this version with a somewhat decent solution. I know it's not the droid you were looking for, but maybe there's some process here that's helpful.

    Concerning finding the error in your original code, while stripping everything, it came to mind that after you disable Platform and Solid, you should wait 0.1 or even 0.01 before moving the cube, so the engine can have a tick to compute the behavior change.

    I don't know if this is the real fix for the original code, but it is quite possibly it.

    drive.google.com/file/d/1g6BgxU0rej4YTsfpOFCy7St_l0aZaoBg/view

    EDIT: I'm also not using the "Push Out Solid" addon, the behavior "Custom" has the action "Push out solid" that fixes the edge case where you place a cube above you and then you get trapped inside it.

  • I was able to find the issue. With low "Jump strength" values, the issue occurs, but when I set it to the same value as the Vector Y I'm manually inputing, then the slopes start recognizing landings again.

    I'm currently posting this as a bug in the github repo.

  • I was able to fix it with this line, but I'm still thinking if it should be considered a bug? I mean, technically I am jumping, and I'm touching the floor, but the engine doesn't even recognize I'm touching the floor when it goes up the slope like that.

    As you can see, I changed the tracking line to recognize "on floor", but it goes up the slope thinking its not on the floor.

  • Instead of moving it, I destroyed and created another, it worked.

    Hope it helps

  • This is the super simple line that jumps.

    note: When I use "simulate jump" the issue is not present.

  • I just encountered this issue where when I start a jump on a slope, the engine still responds as if I'm still jumping, probably because Vector Y is still growing, but is this a known issue? am I doing something wrong?

    note: My jump is me setting Vector Y and not simulating jump. I need it to work this way because I have to reset jumps in walljumps, and the normal simulate jump doesnt have a "reset" like double jumps do.

    Tagged: