yeah, it's just in project properties bar under 'online multiplayer'

just set it to 'massive'

+touch | on object touched

+object| pick top most instance

destroy object

the condition is near the bottom.. under Z order

I've tried a bunch of different stuff to make the physics movement behave similarly with different frame rates but it's pretty awkward

a lower frame rate means the resulting velocity from apply force/impulse is much bigger, so you jump higher for example

something I experimented with and ended up keeping was making instance variables on each physics object, 'forceX' and 'forceY' and instead of 'apply force..' i use 'add to forceX'/add to forceY instead. and at the very end of the events sheet, it sets the velocity X to it's current velocity X plus the forceX value.. and then sets the forceX variable back to 0 for the next tick. Same for ForceY

now I dont know for sure whats going on under the hood, but i guess this means it's not doing a bunch of force iterations each tick, just one. The effect this has is that a lower frame rate means you jump slightly lower instead of higher (the difference is lessened too). Which is arguably better.. just try your best to make the game run at a consistent 60 fps. and maybe let the player know that 60 fps is really how it should be played.

Joannesalfa

Didn't the dev of GDT just release a slightly different version of his game on the pirate bay, on release, on his own accord?

That's how it got pirated so much..

It's important to know that a pirated copy does not equate to a lost sale.. statistics like 90% of copies were pirated does not mean that all, if not any of those copies would have been an actual sale if the option to pirate was not there.

In fact, if he hadn't put this modified version on tbp, and then made the article on piracy.. relatively much fewer people would have even heard of his game. The whole thing was to get publicity from other articles, which would lead to more actual sales.

If the fog is like a rectangular area (i have 'zones' in my game), you can for each fog/zone check that the players x coordinate is between the fogs left and right edge x, and then the same for Y.

I used to do it with overlap, but with a bunch of objects than can move between all the zones, it could slow down.

the downsides are that the condition is met only when the players origin passes into the fog, also you can't rotate the fog without .. maths

basic implementation

preview, click anywhere

capx

if you check out the technique used in the 'lighting' example inside program files>c2>examples

you can replace that light sprite with a solid circle that starts bigger than the screen and then gets ever smaller

7Soul

after ordering by the variable ascending.. you can just put in a 'stop loop' action and it won't repeat for the others.

sounds like a pretty awkward problem, but you can find coordinates of objects' positions on any layer using layertocanvasX/Y and canvastolayerX/Y expressions.

Unfortunately there is no direct LayertoLayerX/Y to make it easier, but it's a start at least.

anyway, you'll see them listed in the expressions panel, and the manual will do a better job at explaining than me

GeometriX

fassFlash

using round(random(4)) will give a slight bias to numbers 1,2,3

for example to return 0, it needs to be between 0 and 0.5, but to return 1 it needs to be between 0.5 and 1.5.. which is more likely

doing int(random(5)) will give the same chance for each number 0 to 4

VonKarma's cap worked for me, it did not fall.

with this many joints, I think the results can vary with your cpu speed

that's what i meant by this:

as long as you only run that action when the player is heard or seen it should work..

as long as the action to find the path to player.x/player.y is only run when the player is heard or seen.. aka not every tick