oosyrag's Forum Posts

  • The angle of the surface you are jumping from would be the origin, and the angle of the surface you are jumping to would be the target.

    I can put together an example when I get a chance.

  • Try the Set Canvas Size system action.

  • Depending on your painting system...

    A tilemap utilizing 1 pixel tile sizes is a good way to manipulate and access information about the state of any given pixel. You can make it invisible and just use it to record and check tile states.

    Otherwise if you actually want to check the color of each pixel, you can use the drawing canvas plugin, take a snapshot, and loop through every pixel to check the snapshot RGBa on every pixel. Unless your paintable area is very small, I don't recommend this as a feasible solution, as it would probably be too resource intensive.

  • I would normally use the System - Set layout scale action to zoom.

    The viewport size can be changed by using the System - Set canvas size action. This is usually done to change the aspect ratio of the viewable area.

  • Turn on pixel rounding in project properties.

  • In that case you simply take the difference in angle between the origin object and the target object, (assuming they all used the same origin angle and are rotated after), and add that to your pointer object's angle.

    You'll need some way to pick the origin and target surface to be able to get the angle expressions from them. First thing that comes to mind is to use a invisible helper sprite on overlap to get the right surfaces to get numbers from, but there are probably a few other ways to go about this as well.

  • unixtime/1000 = seconds

    unixtime/60000 = minutes

    unixtime/3600000 = hours

    unixtime/86400000 = days

    You can use the % (modulo) operator to get the remainder after dividing.

  • As I said before, you need to lower the cell size, change the border to 0, and increase the rotation speed.

  • You won't be needing the "Object Has Line of Sight of another Object" condition.

    In your drawing, it looks like when you jump to another surface, the angle will be set to go back the way you came from, so if you jump you'll go back to where you started. This is simply a 180 degree turn from the previous heading upon landing, or collision with target platform. However, that is independent of target platform rotation or angle, so the target platform orientation doesn't matter.

    In the event that you wanted the new angle to be a reflection off of the target platform surface (like a ball ricocheting off a wall on a pool table), which is what I understand from your written description, you'll want to do the following:

    Upon jumping, use the cast ray action from the player object towards the direction you are jumping.

    In the following event, use the Ray Intersected condition to check if it hits a destination surface. Then you can get the reflection angle with the ReflectionAngle expression, plug that into the action where you set the new angle, upon colliding the wall or right after you jump or whenever you want.

    Check your cell size, reduce it if necessary. Check the cell padding as well, I believe it defaults to -1, which could allow your object to move into a wall and have overlapping problems. If you're using move along path to move your object, try increasing your rotation speed from 100 to 1000 or even higher - this will let you get more direct movement between nodes, depending on the scale of your project and speeds involved.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • To make it seamless, you might need to clone the edges of your layout (half a viewport's worth) on each opposing side, left/right and top/bottom.

  • You may have changed your viewport numbers around. The number within the parenthesis in the ViewportLeft()/ViewportRight() expressions reference the layer number, or I believe you can reference a layer by name if you put it in quotations.

  • Ok there are two issues here - one is that your cell border is set to -1, this effectively shrinks your solid walls to basically nothing since your cell size is larger than your wall size. Try setting this to 0, and lowering your cell size to 16 or so.

    Problem two is the slow rotate speed - This will cause your object to float around corners and cut through what should be solid walls. This is amplified by the fact that you are updating your path every second. If the pathfinding has to turn around or pick a new route, then your object has to slowly rotate and turn around. You can increase this to 1000 or 2000 for a tighter turn.

    Remember the solid behavior doesn't affect the movement portion of the pathfinding behavior, only the pathfinding part of it. So as your object was trying to get back on the path, with a slow rotation speed, it would go ahead and go through solid walls. Also with the cell border set to -1, there were basically no solids at all on your layout as far as the pathfinding behavior is concerned.

    If you're making a pacman type game, I suggest building your levels and walls with standard tile sizes, things will run much more smoothly.

  • QWOP was a physics based game about running, where due to the physics based controls, the character was more or less impossible to control.

  • To get the behavior you are describing you might be interested in the Custom Movement Behavior. For every solid object you have, also add a Custom Movement Behavior and use the Push Out Solid action every tick or on overlap with another object.