megatronx's Recent Forum Activity

  • Yes it would be nice to have. Have a look in to expressions, as there are some, and then use one of compering actions. I personally just make my own counter: every tick - add dt to variable, variable > then x - set variable to 0.

  • Disabling groups can help improve performance, since all the events in the group must still test their conditions against (possibly many) instances to determine that nothing meets the condition. It can keep executing through to later conditions in the same event as well before it determines the event won't run. So disabling the event can save all that work from happening. Or, it might make no difference at all. As ever you should measure it to determine if it's worthwhile.

    Thanks for the answer. Could I ask you one more question re this. What would be best way of toggling groups with single chain events like this one: For each Door, boo = 1? I'd think toggling based on distance, but that again would require to check all Door objects.

  • The main difference is how they are run: a function will call the "On function" event, run it to completion, and then return to the "call function" action and continue from there. In other words it calls other events from within an action.

    Activating a group just enables a bunch of events so that they can be read the next tick. It doesn't actually run anything at the point you say "activate group".

    Is it worth toggling groups to gain performance, or as I remember conditions that are not met just don't run?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Please reshare

  • Can't check it cause you saved it in latest beta. But basically, it is a opacity shader effect to be used instead of c2 opacity, right?

  • This one's cool too!

  • Really cool! Yeah, speed and depth params are definitely desirable! Then share please!

    I actually have a suggestion for C3

    Ashley Imagine a maze with loads of doors and even more buttons opening those doors, spread throughout the whole maze. It becomes difficult to keep track of which object representing button is connected to which door. So I thought that it would be very neat to have a connector in C3 which would work like this: in editor you click on an object you'd like to connect while holding a shortcut key. A line is being created and you pull it with mouse to the object you want to connect it to. Now in events you have ability to create conditions using those connectors, for example For each button connected to doors, or for each doors connected to buttons, following by standards like doors variable = x: etc. would speed things up as well as make things in the editor easier to see.

    i just going to use unity + blox and it seems like construct1000 !

    It looks cool, but it seam very complex in compare to construct.

  • so you use pin to make an object follow yours but when it gets on some distance it changes it's physics on and off ?

    why not just leave physics on for it? or is the physics for player?

    if you can't do it any other way - check every 200ms, that's about 5x a second, seemed to work best for me in my game when i did rotation (360 frames, each 0.2sec instead of each tick for 1°) worked like a charm and saved a lot of processing

    Cool. That gives me a good idea of how to use it. Thanks.

    I ave loads of objects that change opacity depending on the distance as well as objects that change their physics depending on players virtual z position.

  • setting position by x and y coordinates with system expression seems a bit pricey to me. why not use just some movement behaviours to do it? (custom or bullet), i think they're more optimized for performance then setting x and y every z miliseconds.

    Heya, I do use pin if I want object to follow. Now, I really should have be more precised, because I am mostly turning physics on and off as well as set opacity, both depending on the distance from the player, every x ms, however I am not sure if that's necessary ( although my levels have floors, so I'm checking z position of the player based on other events, from which I turn on or of tiles physics).

  • It can, and does in instances where you have LOADS of objects updating position - particularly container objects (or shadow caster).

    It can also reduce the fluidity of motion though, and make it "feel" janky even though it's not janky. Also be aware that there is a minimum time for a tick to process (I think it's 0.16 seconds) so setting your timer to less than that means it's running the same as "every tick".

    ~Sol

    Thanks. Yeah, I do notice a stutter, either way thought. I have set every x s between 79ms and 120ms originally. I did ask about position, but actually it was a general question, cause I use that to check distance between player and object and turn physics on and off as well as opacity. Maybe there is a better way. Or maybe some of it isn't even necessary?

megatronx's avatar

megatronx

Member since 25 Sep, 2008

Twitter
megatronx has 1 followers

Connect with megatronx

Trophy Case

  • 16-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
  • RTFM Read the fabulous manual
  • Email Verified

Progress

23/44
How to earn trophies