oosyrag's Forum Posts

  • While I'm at it, here's how I would do it

  • Ok sorry, looks like you didn't need UID. You can pick by the instance variable as you originally intended -

    But here's how to use UID anyway if you were to do it that way.

  • The "Pick by unique id" goes in the function, so that the function actions only apply to that instance of the object. You don't need a separate instance variable for it and you don't need to set the uid.

  • It can be. Just pass the uid of the picked instance as a parameter to the function, and add a pick by uid condition into the function.

    Again though, it's just extra steps that you don't need to take to do the same thing, more easily, by just putting the actions in a "for each" event. (Or a "repeat object.count" times as in the example, which is the same thing)

  • Simply put, functions do not preserve picking from the event calling it, unless you pass that information as a parameter. So all the instances of button are being moved to the same position at the far right, overlapping each other, since there are no instances of the button being picked in the function event.

    One of the reasons when not to use a function unless you're doing something where a function specifically would benefit you.

  • igortyhon's example is solid.

    I just wanted to emphasize what he said about not running events every tick (60 times a second on most monitors). If something isn't expected to change every tick, then it's event should not run every tick. Only run the event as needed when something needs to be changed. Try to use triggered events for everything.

    In this example specifically, you don't need to update the buttons until you click to make a new button.

    Also in general, you don't need to use functions for most things in an event based system like Construct. They definitely have their uses, such as setting return values for what basically amounts to a custom expression, or repeating the exact same set of actions under different conditions, but when starting out I recommend working with the basic condition-action event blocks until you run into a situation you really NEED functions. Otherwise, it is just added complexity that you can get unnecessarily stuck on while learning.

  • Glad it made a difference. Especially true since modern hardware lets us get away with a lot, so it's easy to overlook things like this. It works fine, until it doesn't.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Wild guess is that you no longer have the correct event sheet assigned to the layout.

  • Images are loaded into memory at their original resolution, then scaled.

    So use native sized sprites whenever possible unless they need to grow significantly during runtime, then you probably want the higher resolution sprite.

    This is probably having a massive effect on your memory use.

  • Use loop and the loopindex system expression to repeat a set of events with an incrementing number value as a variable.

    Specifically if you're creating the buttons dynamically:

    Repeat n times

    Create button at margin+loopindex*(button.width+padding), y

    If they're existing on layout already, you can use for each instead of repeat. But then you might as well just use the layout editor align options to position your buttons.

  • Deleting all your events and any behaviors, objects, or effects that are not default ones should do the trick.

  • If your goal is to move the sprites, just delete the plugins and open in c3.

  • The solution for nearest wall is simply to design the level taking it into account. Basically no long stretches of walls. Alternatively, use a different type of wall for long sets of walls - just put the "cover" type wall at the ends or corners.

  • Nah my idea in that thread would have the exact same problem actually. It assumes empty space behind the target, otherwise the wall behind the target would be the first thing hit.

    A better system would probably have a bunch of potential "cover locations" at all times set by the player position, and the enemies would pick the one with lowest pathfinding cost, since the nearest point by distance may not always be the shortest path.

    Unfortunately I'm not seeing a way to get the path length with the built in pathfinder expressions, besides which it could get quite costly to find a path to every potential cover location just to check the distance.

    Getting the path length is possible by looping through all the generated nodes after finding a path, but it would still need to be calculated and compared with all potential pathfinding targets, which sounds awfully heavy to me.

  • Not really, not for a sprite with a donut shape like that.

    The most straightforward way would be to create a set of sprites of all the different sizes you want. Probably different animation frames of one sprite object, and you would choose the animation frame of the suitable size for any given planet.

    You might be able to use an html/form element with styled css, which can set fixed border sizes, but that's going to cause all sorts of other problems you won't want to deal with down the road.

    Edit: You could also probably draw them dynamically with the drawing canvas plugin