What I usually do is just set a variable on a sprite, set time scale 0 and object time scale to 1 and then count that number down 1 every tick. I then do a check if the variable is less or equal to 0, then you can call whatever you would after your "wait" command. It's kind a of a pain, but the only way I've figured it out to work.

Beaverlicious - seems that way. Although one thing to note about construct (might be html, not sure) is that when you create more objects that take up memory, destroying them does nothing to your memory pool until you leave the layout. So if you base everything on a single level, everything you have contained in the level AS WELL as everything you create will be permanently added to the memory pool.

Ashley - I know for a fact is was before collision cells were added, so I'm sure that'll help immensely.

Colludium - I didn't think it did either, but just wanted to be sure.

C-7 - thanks - that's really good to know, actually!

Refeuh - correct me if I'm wrong, but there is no built-in sorting and distance-based functionality other than distance(x,y,x,y)?

I do have entities will follow-like behaviors, but it's as simple as "if x < player.x, follow player > that way". And I'm using line of sight in order to determine whether or not the chasing boolean is active. I could always just disable the platform behavior for enemies until you're close enough to them, though?

Colludium - thanks for the advice. Stupid question, but if an object has no collision events but has collision enabled, is it using any cpu/memory? I'm also wondering if distance between every object will run less cpu than overlapping a tile. I'd imagine at that level it's not a huge difference, but I want to be able to optimize to the fullest extent possible.

Refeuh - thanks for the reply. That does make a lot of sense. I tried something similar on Viktor, but ran into problems (probably because of my skill level in terms of coding), but I would "disable" things off screen and then re-enable them when they were on screen. However since there are so many of the same object type on screen simultaneously, it seemed to bug out if it was off screen, on screen, and then off screen again.

Could you technically do a

"For Each Sprite"

if Distance(Sprite X & Y and Player X & Y) < Layoutwidth+500 = ENABLE BEHAVIOR

Else = DISABLE BEHAVIOR

A while back when I first started Viktor, I made the first level into one layout. The level took about 5 minutes to beat, so it was relatively long (maybe 40,000 x 40,000 layout size). I had a friend who had a non web-gl pc to test the game, and his fps was in the low single digits. When I split the entire stage into 10 "mini stages", his fps dramatically improved (to the high teens; low 20s). So my question is this:

If you're not adding more "new" images by creating large layouts and instead reusing 90% of the sprites you're going to have in every mini stage anyway, is there a bad reason to have a super large layout like this? I did a test to see the memory and CPU usage, and the memory usage was virtually the same between the full size layout and the mini layout. The CPU, however, did seem to jump a fair amount (went from 30 to about 60), but I think that's normal given that a lot of sprites, even though being reused, all had sine behaviors, etc.

I personally have no way of testing this because I get 60 fps no matter what, but Viktor had some minor complaints on Steam that would experience certain framerate related issues that were otherwise untestable on my end. I'm assuming due to the fact that some pc gamers don't have a webgl-enabled graphics card.

hundredfold - what I'm trying to say is that, like the object list, if you're scrolled down in the list and edit an object, it sometimes selects the object at the top forcing you to scroll back down to find the object you were editing. I'm not sure if that makes any more sense?

I'm not sure if there's a preference I'm missing for this, but when dealing with lots of layers in the "Layers" panel (enough to create a scroll box), clicking things like "unlock all", "show all but this", renaming, etc. always go to the top of the layer list after doing so. It's a small thing, but I'm wondering if it's an easy fix?

korbaach - Of course! I always keep forgetting about the force texture settings.

Thank you!

I'm trying to play around with blend modes, and I'm having trouble figuring this out:

Ideally I'd like to have 2 sprites - one sprite as the "solid object", and one sprite as the blend mode sprite. I want the blend mode sprite to be completely transparent, but when it overlaps the "solid object" sprite, it makes the the bits of the "solid object" sprite that are overlapping transparent as well. Is this possible using blend modes, or does this require something more sophisticated?

KaMiZoTo - I've noticed somethign similar to this, too. I can't remember how long ago, but the platform behavior alone seemed to start racking up and enormous amount of collision checks a few updates ago. I'm not sure if it pertained to that, though.

Is there a way to enable/disable the persist behavior via events?