oosyrag's Recent Forum Activity

  • 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)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

  • 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

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

21/44
How to earn trophies