oosyrag's Forum Posts

  • That's a creative solution! Here is how I was thinking just FYI.

    I wouldn't use atan, as you have an extremely slim chance to divide by 0 and I'm not sure how C2 would handle that. Maybe there are safeguards built in and it would be ok, but I'm not sure. Use the angle() expression instead.

    I was thinking would be to set angle , then use the action move forward based on distance, or just move at angle.

    (I'm assuming axis 0 is x and 1 is y, swap them if I'm wrong)

    Angle = angle(0,0,gamepadaxis(0,0),gamepadaxis(0,1)

    Distance = distance (0,0,gamepadaxis(0,0),gamepadaxis(0,1)

    Optional - Multiply distance by a speed multiplier.

  • First your random problem:

    Else is a little bit tricky. The event sheet is read and each event executed in order from top to bottom, as long as the conditions match. Else means only run this if the event previously did NOT run (unless you have a series of elses, but that works as an extended if-else chain). So the way it is now, lets say your random picked 3, which would be dirt. The dirt event runs. The grass event does not run. The tree event DOES run because the grass event didn't, so it immediately covers your dirt with a tree.

    To solve -

    Explicitly define 4<=rng10<=6 in event 7

    Or Add Else to event 6 as well, to make it a proper if-else chain.

    Your terrain manipulation problem is similar. When you touch grass, event 12 runs and creates a tree. Then event 13 runs because a tree is now there where you touched, and then turns the tree to dirt. This is another bit of learning curve for the event sheet system because Triggers (the green arrow) don't follow the normal flow of top to bottom, and will run whenever the trigger happens. Thus you can't use Else with a trigger.

    This is a little troubling because when you turn one object into another, triggers will run on the new object and I can't think of a solution off the top of my head. The solution would be to use another system/approach, which I hate to bring up because you would have to mostly start over, but here goes. This is how I would normally approach a project of this type. Instead of using a unique object per tile type...

    1. (Better) Put all your tiles into one object called "Tile", and control look and properties by animation frame and instance variables. For example On Clicked Tile, with subevents If animation frame=1, do something, else if animation frame=2, do something ect. On generation, usually you want to save the tile x/y position as instance variables, and any other properties/identification you like. The type of tile is determined by the animation frame number.

    2. (Best) Learn/use the tilemap object and build a tilemap system. They are made for tile based games. https://www.scirra.com/manual/172/tilemap

  • You'll need 4 variables - lowestValue, Xindex, Yindex, and Zindex.

    For each XYZ

    Array.CurValue<lowestValue

    Set lowestValue to Array.CurValue

    Set Xindex to Array.CurX

    Set Yindex to Array.CurY

    Set Zindex to Array.CurZ

    So it will go through the whole array, and whenever it finds a lower value than the last lowest value, it will record that new value and also the XYZ position.

    With that first XYZ index, you can check the neighboring cells by adding or subtracting one from the appropriate index, with similar logic as before.

    If you don't need the index/location of the lowest value, you can do a simple event as follows:

    For each XYZ - Set lowestValue to min(Array.CurValue,lowestValue)

    This might be useful if the value of interest is your first X axis - you can then use Array.IndexOf(lowestValue) to get the position. But that only works on the X axis.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can mark each sprite block with an instance variable. When an object is created, it is "picked" automatically for the duration of that (sub)event. So if you create an object, and set an instance variable, it will only set it for the instance that was just created.

    You can use conditions such as Pick sprite by instance variable to pick "trees", then use pick nearest sprite to get the nearest tree.

  • To get the best restults, I would recommend using a custom system for movement with an analog stick rather than using the 8-direction behavior. You'll be using angle() and the axis 0 and 1 values to get the angle of the stick, and distance() for the amount with 0,0 as your first two values.

    The 8-direction plugin, after all, is meant 8 directions only.

  • It is possible.

    The most straightforward way would be to push the x/y coordinates of the input every tick into an array. To replay, just go through the array and draw from each saved coordinate instead of the mouse/touch input.

    I don't know if there would be performance issues without trying. You can trade resolution/accuracy for performance by adjusting how often you save a set of coordinates.

  • Check out the first example here -

    +1 "not easy".

  • You will use the min() expression. This will give you the smallest number out of the numbers you provide.

    So when you reload, you will subtract min(ammovariable,15) from ammovariable. If ammovariable is more than 15, it will subtract 15, if it is less, it will subtract ammovariable, leaving you with 0.

  • That just says the sprite can randomly start at a speed anywhere between myvariable and my variable+50. It is a small optimization, not required, to make it look better, as I am creating multiple instances per frame (due to the repeat). This way multiple sprites created the same frame don't all have the exact same speed, and there is some variation.

    The speed starts at 0 to represent the pressure/spray from a water gun. This is necessary as you requested that the spray gradually decrease after letting go of the fire button.

  • A simple method would be to use an invisible helper sprite pinned to your player. This helper sprite should be as big as whatever you determine "near" to be. Then you can use this helper sprite as a condition - when it overlaps an obstacle, do something to player sprite.

  • Never mind, looks like adjacent doesn't count as overlapping after all. Pretty much ignore everything I said in the last post. Experimented a bit and this seems to work: https://www.dropbox.com/s/xgmojljasm5e6 ... .capx?dl=0

  • That idea sounds about right. You'll want them as close to the edge as possible though, so they'll be able to help you "clear" the corner. If they are 4 pixels away, then you might get stuck on the 1-2 pixels where the helper sprite isn't colliding so you don't get nudged, but your main sprite is still colliding with the solid object.

    So the helper sprites should be just 1 pixel away from the sides as to prevent the "nudge event" collision conditions triggering from objects to the side, and the amount nudged should be at least 2 pixels to allow you to clear the corner of the object and continue moving forward. You might want 3, one dead center. If the center one is overlapping, then no nudge.

    Assuming you're using something similar to solids and 8-direction behavior.

  • myvariable is the base speed of the water. As you hold down fire, the base speed at which it is created increases. The expression min() returns the smallest of the two values, in this case either myvariable+50, or 2000. This constrains the maximum of myvariable to 2000. If myvariable is already 2000, myvariable+50=2050. So min(2050,2000) will give you the smaller number, or 2000.

    As a result, as long as the mouse is held down, myvariable will increase 50 every tick until 2000.