Well, perhaps I meant to define it in terms of what it does: it makes events that are true for several ticks only run on the first tick they're true. I don't think it's clear what it ought to do when in a subevent to a loop, since the definition of "true for several ticks" no longer really makes any sense. So I'm happy to leave it doing whatever it happens to do with the current implementation.Well for a "For Each" loop wouldn't it be based on instance where if it did that action last tick for that specific instance instead of checking if that part of the loop ran at all? Unless I'm misunderstanding the implied For-Each in the code if you removed the loop condition.

If so then I'll have to be more careful with those loops and have learned my lesson on what they don't do. (Sometimes I add them to make sure something runs for every instance)

I got around it by using functions and disabling previous boolean after it has ran so it only triggered once. instead of every tick.

Ashley Well even if it's supposed to be "Run this tick if it did not run last tick", it does that but only for the first instance. The instances other than the first go "Run every tick", ignoring the trigger once.

Understandable if it's an issue not worth fixing as it's a bug that happens with crappy code.

Colludium

It's an obscure problem and I was doing quick code when I came across it. There are better ways to do it (as what I already have done), but it just looked broken due to that without the "For Each Text", the events runs for each Text and function as expected.

When you have a 2 condition event like that running every tick, it's implying the "For Each" in it's picking (as far as I know). I wanted to pick 1 object and run a group of events for that specific object for every instance of that object. Without the For-Each it was breaking as when I trying to select other objects linked to it, it affected many things I did not want.

Using UID and functions I segmented the code, and forced picking by UID through the function instead of picking by Current Instance in For-Each loop. Still using a For-each for the first part, but since it's for-each I just grab the UID and have it run the function when I have it set to turn off the boolean as an action rather than looking to see if the boolean was just turned off.

Link to .capx file (required!):

dl.dropboxusercontent.com/u/73774002/foreach-triggeronce.capx

Steps to reproduce:

1. Hit any key

2. Hit any key again

Observed result:

First instance behaves properly, triggers once.

Second instance does not.

Expected result:

All instances should trigger once.

Operating system & service pack: Win7x64sp1

Construct 2 version:r154

=====

With how it's setup, it should trigger once per instance that is TRUE. It only triggers once for the first instance that is TRUE, but every tick for the rest of the instances.

If you remove the For-Each, it functions as expected.

=====

I'm currently using For Each along with Trigger Once because I need it to trigger once per object that has the boolean, and half of the code breaks if I remove the for-each, and the other half breaks with the for-each.

Ashley

Any plans on expanding asm.js support to other plugins in the future?

pakl

Thanks again for sharing the love.

Now we just have to have Ashley and crew to take a look at it.

Steam version verifies with your steam account, and does not use the regular license verification

Actually another way is to do the coding yourself, and have your events check tile numbers for each tile

If tilenumber=4 then wait 1sec and set tilenumber at tilelocation to 5

and etc,

Well seeing how the tilemap object spawns a bunch of tiledBG and other objects for placement of tiles while ripping from a tilesheet, I don't think it wouldn't be too hard to impliment

I know some people have used "Load from URL" on "TiledBG" to make it emulate being animated. If we use this then the object would have to have a behavior that animated only certain tiles. There could be instance variables that determine which tiles animate and have their frames progress at a fixed interval to the end, and start over from the beginning. (Although with the introduction of tile-collisionboxes, probably up to the user to make sure all tiles have the hitbox they want it to have)

Would probably be tricky to code it and have it check for it, or even use unnecessary processing power even though you may not use the animation feature. (if that is the case, an option to enable animations in the object properties)

I don't think tilemaps should be the end all for things as then the sprite object would not be used as much.

I think a better way to refer to the sprite object is calling it an entity.

Tilemaps are the environment, so you want to modify the environment. However in major games the base environment is static while the environmental objects that are not static are entities.

There is a couple ways to do what you want

1) Use a 2nd tilemap (you said it was inflexible)

2) Use tiles that are blank/bright colored and have the game on load check for those tiles in the tilemap, change the tiles, and spawn entities there.

This makes it so you automate the entity creation and can modify and re-parse the tilemap accordingly during runtime.

3) Manually place the entities.

Ashley

Is it possible to force DT to be greater than/equal to 29ms instead of skipping? When you say skipping it sounds like it either still does the same calculations but skips rendering, or it ignores the processing for that tick.

Maybe make a "End of Tick" check, where if by the time it's done processing that tick, if 29ms has passed it goes through, but if not then it waits. This way you'll have some potential idling on the processing side, but it should never stutter on it's own if it can run at any framerate above 30fps smoothly as you're not halving a rate but just waiting until the rate is a certain amount. Well theoretically, but as far as I know you might be doing that already. :P

Other than that I do not know. IMO if you can't get it to work smoothly in a week you can always come back to it at a later time, as there are more important features to work on.

Ashley

Glad to see that it's being attempted.

I know it's not optimal and is a way to downgrade the game's load VS optimization of the game/engine. Hopefully it can be worked with to make it a way to smooth the framerate for some people.

If it doesn't work well with a lot of things and requires a bunch of rework, I assume we would understand if it was temporarily removed for such work. If they know there is plans for a better way to halve the load for performance I think that'd be okay.

---

Also for the thing about crappy framerate in flash games, a lot of people put up with it until computes caught up but a lot of people also didn't start making very complex/high quality games until computers could handle it.

While the PC market can handle pretty much everything C2 throws at it, especially with Node-Webkit, I think at least planning for it was a good idea because people probably don't want to wait to the mobile market to upgrade their devices to near nexus-5 specs.

Hopefully Tizen and FirefoxOS function well and take hold in the market, or someone makes a good wrapper that can optimize how C2 accesses the device so it can have more frames processed smoothly. There seem to be too many problems with the current wrapper solutions. Framerate limitation is just a stop-gap.

Another issue we might not be thinking of is the amount of work to even do it, as it might be something they can't implement without tearing up a lot of other things.

I think that it should be done whenever the next major render engine work happens.