ramones's Forum Posts

  • Took a while to find but I knew there was an old thread discussing why 0-100:

  • You can divide by 255 and multiply by 100. So, your orange value will be:

    parameter 0: 226 / 255 * 100

    parameter 1: 146 / 255 * 100

    parameter 2: 28 / 255 * 100

    I suppose if you use a value larger than 100 it just gets rounded down so (0,0,204) = (0,0,100) which is pure blue.

  • The color values should be between 0 and 100.

  • You're setting the webstorage value to the string "Score" instead of the variable Score.

  • Use 'System:Else' between the different animation frame conditions so that only one of them runs, like this:

  • Event 9: Set direction to "Right"

    Event 15: Check direction = "right"

    "Right" != "right"

  • Instead of having an array with empty values, start with an array of width 0 and only add the selected backgrounds to it. So if you select 3 backgrounds then the array width will be 3. Then you can select a random one with Array.At(floor(random(Array.Width))).

  • Push onto the front and pop from the back.

    [attachment=0:3k5pusn4][/attachment:3k5pusn4]

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Pick the A's that are overlapping B and then check A.PickedCount to see how many there are.

  • Make sure the score text is actually on the score layer.

    For the animation, events 6 and 7 are both true when the player is on the floor and moving so the animation will keep getting changed. You'd want to check that the player isn't moving before you set the animation to idle.

    *edit* Just saw the part about the score not updating.

    The collision in event 10 is never detected because you've already moved the player away from the red sprite in event 9. You should move the adding score actions to event 9.

  • The pathfinding behaviour takes time to turn and face the correct direction before it starts moving. You can increase the turn speed or set the angle directly to speed it up.

  • The problem here is that the state is "idle" for 1.25 seconds before it changes to "stop" and for every tick during those 1.25 seconds you are running those actions.

    So it's like:

    Tick 1: Set speed, wait 1 second, set movement enabled, wait 0.25 seconds, set movement disabled

    Tick 2: Set speed, wait 1 second, set movement enabled, wait 0.25 seconds, set movement disabled

    Tick 3: Set speed, wait 1 second, set movement enabled, wait 0.25 seconds, set movement disabled

    Tick 4: Set speed, wait 1 second, set movement enabled, wait 0.25 seconds, set movement disabled

    etc...

    1.25 seconds after the first tick where state was "idle", it will set the movement disabled and the state to "stop", but you still have 1.25 seconds worth of events queued up that will set it to enabled again. The movement is going to be set enabled - disabled - enabled - disabled until all those queued up actions finish running and you get that extra movement that you see.

    What you want is to only run this block of events once when the state becomes "idle" which you can do using "System: Trigger once".

    Here's a capx that highlights the problem:

  • Interesting. The line of sight looks for a clear path from the object's origin point. In the first capx the origin of the Enemy is at the bottom and it's overlapping the ground so the ground is blocking the line of sight.

  • Local variables are reset every tick unless you make them static. So timer will never reach 200.

  • Call 'Regenerate obstacle map' on start of layout.