brushfe's Forum Posts

  • That may be because pathfinding -> find path is one of the "asynchronous" actions.

    I believe these few special actions are designed a little differently. Calculating a path can take anywhere from one tick to five seconds depending on the layout, CPU speed, etc, so it needs to run in parallel or the program will hang until it's done. Each sprite looking for a path may take different times to find its path, or the same time.

    So it basically has a "for each Sprite" built into it. The timer trigger does not, like most triggers. So on a tick where multiple identical timers go off, your single timer trigger will be considered enabled, and it'll go off a single time.

    If all this is true, you should always use a "for each" condition on synchronous actions (like timer). Try putting a "for each sprites" condition on your timer trigger and see what happens.

  • There are much smarter folks on here than I, but I think conditions will pick a random instance from all possible objects that meet its criteria.

    So using For Each is a great way to ensure that every object that either triggered the condition or meets the condition are picked for the subsequent actions.

    I use the Browser log as an quick way to see what's getting triggered, especially when a function gets called. You can also put browser logs inside for/repeat loops, if you want to track what's being done within each loop. It's a really handy tool!

  • If I understand your question right, you can test this (and many situations like it) easily using the browser object.

    Try adding the browser object to your project. Then add the action Browser -> Log to your "on path found" trigger, and just log something like "path found“.

    Finally, run your project in a web browser and press F12 and view the console. You'll see it will have logged "path found" for every time that condition triggered.

    It's a quick way to test if your code is running as intended. In this case, my hunch is you'll need a "for each -> enemies" condition to your "on pathfinding path found" trigger, but this test should tell you for sure.

  • The problem is the same, looking backward or forward. Whatever time was spent, or will be spent, developing Animate could've been spent on C3.

    The expectation isn't that 10 years of features get quick action. We've all been told that Scirra's a small team, and that new features and improvements take time, and that's true. But now, any progress will take even more time—in exchange for an animation program.

    A chance for significant ROI is good for Scirra, and it's fun to experiment. But for people paying for C3 every month, excited and hoping for more C3, you have to understand why this will be problematic. We're getting less dev time on C3 and funding a gamble many won't use.

    But maybe we've got that wrong? If you can show people how this won't affect C3 in any way, as you said, I think it would go a long way.

  • Just a clarifying question - is all that code supposed to be part of the function "GoToNextLevel"? Or is it meant to run every tick?

    It looks like it's running every tick, because it's not a subevent of the function. But it seems like you want that code to only run when the function is called?

  • How many features in the suggestion platform will now be put off indefinitely because they now choose to focus on timeline / animation improvements, which will no doubt now get priority, of which may not even make it into C3 because their not "game related"?

    I really love C3 and the team behind it, but sadly I feel the same way, so far anyway. No matter how "manageable" the workload, the focus on C3 is still split. Even 10% of time away from C3 is tough to imagine, when there's enough ideas for C3 improvement to fill 300% of the time available.

    At best, it seems like compromise is inevitable: the features that affect both C3 and Animate will naturally become a way to make "both" sides happy, and show that there's no slowdown on C3 updates.

    One small thing about the forum update— it's a bit unfair to say "I am not aware of anyone who complained during that time that our usual rate of work had slowed down". I think most/all have assumed the team has been 100% focused on C3 the entire time, so of course there'd be no complaints. Had you asked last summer how users would feel if you spent even 10% of the dev time on a new animation product, you certainly would've heard those complaints.

    The list of mandatory features for Animate is already well outlined and a huge amount of effort or time. Adding my feature suggestion for Animate feels a bit moot considering the core work to be done.

    I suppose I'm still wondering — genuinely, not rhetorically — how does a small team for C3 not get smaller tackling this workload?

  • Glad it worked out!

  • There may be a more elegant way, but I put objects that can collide with themselves into a family, which lets you check if "family" is overlapping with "object".

  • I think someone here shared a cool example where the Text Input was made invisible with CSS, and displayed a Spritefont object that matched the text of the Text Input. So it kept the function of the Text Input object, but had the visual cohesion that the Spritefont allowed.

    Is that the kind of thing you're after?

  • I mentioned this briefly in the comments, but in case it gets lost there, I think you'll have to be very careful around feature-locking.

    Naturally the business appeal of 'suites' is the potential for both new users and more revenue from existing users. But the failure of many suites/brand families/etc is holding features hostage behind products.

    We're only seeing a sliver of the plans for Animate, but so far it does include this. Locking Export to Video behind Animate only makes sense from a business perspective. Asking C3 users to pay extra won't go over well with those who currently use C3 for any animation, and with the community on principle (since Animate is just Construct and there's no barrier to porting the feature.)

    It's a fine line that will need good communication to manage. In this case, it does seem like buying Photoshop just to save my Illustrator file as a JPG.

    That aside, I truly love how Construct has opened the doors to development for so many people, and I hope Animate brings more animators into the world.

  • You can also use an array to store the x/y coordinates (and other data), then draw/destroy the objects at any time.

    Here's a quick example (though it's not very elegant, I'm sure there's a nicer way to do this!)

    drive.google.com/file/d/1Jq5KyR5TYjuROt9JMqeb2ENaN2oPuFAU/view

  • Sure thing! The folks who were helping you out earlier gave far smarter and more useful advice—I'm happy to help with the obvious bits!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It sounds like the origin point of your Head sprite is in the wrong place. Try opening the Head sprite in the animation editor, clicking on the Image Point tool, and putting it in the center of the sprite (see image)

  • Ok thanks—if you can't share it, can you describe what's happening/what's supposed to happen?

  • It's hard to say why without seeing your code. Could you share your project? Or a screenshot?