oosyrag's Forum Posts

  • I believe the example I posted should work with any size/ratio tile. Just change the size of the sprite object for the tile. Let me know if it breaks and I'll take a look again.

  • What is the size of your tile?

    Edit: Never mind, here is an example with any size tile. It's a little messier to read though.

    dropbox.com/s/452gu6gpqbbi4ka/isoexample.c3p

    Some additional tweaks in this particular example include centering the origin tile 0,0 by ORIGINOFFSET, which is viewportwidth/2, and offsetting the mouse screen coordinate input by tile.height/2 to center the highlight, since the origin point of each tile is currently at the top of the tile instead of the center.

    Basically it's still "Get the nearest isometric tile coordinate from the mouse location, and set the object position to the screen coordinates corresponding to the tile coordinates".

    The main difference from orthographic projection is that any given x or y isometric position requires both an x and y input to get, while in an orthographic system you would only need an x input to map to an x coordinate, and y input for y coordinate.

  • Do you have an isometric grid already set up? Not all isometric grids are created at the same size/angle, so the exact way to do it would depend on what you've got.

    I'd assume any isometric grid set up already has a way to translate screen coordinates to grid locations, which means you should have a way to get/snap to the nearest grid. Then you would just set the position of the object to the nearest grid coordinate every tick instead of the mouse coordinate.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Moving up (up to 45 degree) diagonal slopes should work fine by default. Are your tile collision boxes set properly?

    Otherwise try using an invisible helper sprite set to solid and set it to 45 degrees aligned with the slope.

  • Edit: A triggered event cannot be a sub event.

  • Here's the same, with gradual filling. metermask.reserve is an instance variable used to keep track of how much/long to fill up. 

    + System: metermask.Height > 0
-> metermask: Set height to max(0,metermask.Height-0.05)

+ System: metermask.reserve > 0
-> metermask: Set reserve to max(0,metermask.reserve-1)
-> metermask: Set height to min(150,metermask.Height+1)

+ Touch: On any touch start
-> metermask: Set reserve to metermask.reserve+25

    You can add stuff like setting the reserve to 0 if fuel gets maxed out, if that is your desired behavior. Alternatively, you can set the reserve to min(25,fuelmax-currentfuel), to take the smaller of either 25 or the difference between max fuel and current fuel to prevent overfilling.

  • construct.net/en/tutorials/how-to-collaborate-on-projects-with-svn-321

    Github is probably the big one.

    Edit: Oops meant to post the link below. But this one is probably good to leave here too.

  • If they are acting differently when set up like that in an or block, you probably have an event somewhere else that also does something when the same button is pressed.

  • Use the advanced random plugin. construct.net/en/make-games/manuals/construct-3/plugin-reference/advanced-random

    Probability tables

    Advanced Random can also create probability tables, which are a way of generating weighted random numbers. For example if you add three items with a weight of 1, and then a fourth item with a weight of 2, that item is twice as likely to be picked as any other item. The value of a probability table entry can be either a number or a string, but the weight must be a number. This is useful for doing things like random pickups with lots of common cheap items, but also some rare valuable items.

  • Ah.

    The pixel rounding setting should still overwrite whatever you see as the canvas coordinate. That is it should only attempt to draw the nearest (rounded) "full" pixels, regardless if layer coordinate or canvas coordinate is not a whole number.

    Anyways you can see what exactly pixel rounding does in this project dropbox.com/s/cdw5a1e9agxk4jy/pixelroundingexample.c3p

    Try turning it on and off to see how it behaves when pressing the right arrow.

  • If you're going for smoothness and want to use tween, you'll need to define an "update period", as tween is something that happens over time.

    You wouldn't tween something every tick, since that is no different then setting the position directly.

    You also generally don't want to use multiple overlapping tweens unless there's some specific effect you are going for.

    So to prevent overlapping tweens, such as your fuel draining normally, and your fuel filling from pickup, you'll need some additional information. All tweens need a start point and an end point. Assuming your fuel is still draining during the time it takes to fill up, you'll want to find out how much fuel would have been drained during the time it takes for your fill up tween and subtract that from the end amount. When it's done filling, then start a new emptying tween from that point to 0. But then you would need to set a new time, based on the amount of fuel you currently have, since fuel drain should be constant...

    Anyways I still think tween isn't the way to go here.

    Just have a fuel variable that is subtracted from (dt amount) every tick for a constant smooth rate. And if you want your fill up to be smooth do the same thing, and add fuel at a constant rate every tick until the total amount added runs out (you can keep this in a separate variable).

  • I'm not too familiar with the relationship between the drawing canvas coordinates and layout coordinates.

    But at least pixel rounding doesn't have anything to do with behaviors or set position. You can see in debug mode even with pixel rounding on, if make an event for example on right button pressed, set sprite position to self.x+0.11, you can still increase the position of the by decimal amounts. But the rendering engine will not attempt to draw the sprite at sub pixel locations, so you won't visually see it move until it gets rounded to the next whole pixel. This preserves crisp edges for pixel art.

    I'm assuming if your canvas position is not a whole number, pixel rounding should still prevent drawing sub pixel locations, but if the drawing canvas plugin breaks that rule then I don't know.

  • At the end of your event sheet, every tick set object position to int(self.x), int(self.y). This may have performance implications depending on how heavy your game is to begin with. But it shouldn't be too bad in normal situations.

    On the other hand, it was my understanding that pixel rounding doesn't prevent objects from existing at sub pixel locations, it just rendered them at whole pixel locations. So I wouldn't think it would cause artifacts even if the object position had a decimal. There may be another issue you are overlooking.

    Edit, from the manual on the pixel rounding property:

    Note this does not affect their actual X and Y co-ordinates, which can still be between pixels - it only affects where they are drawn on the screen.