Just to clarify, you use Always when you need to perform an action every tick. This is for behind-the-scenes game logic, for the most part. Ticks happen at different rates on different computers. You don't want any sort of time-sensitive actions happening every tick.

Any time that time is a variable in your actions, whether it's spawning enemies over time, moving objects (because speed is a calculation of distance and time), or simply counting seconds, you need to use Every X Milliseconds or TimeDelta to ensure that the rate stays constant across all systems.

Anywho, I wouldn't touch the "every X milliseconds" condition with a ten foot long clown pole.

WHAT?

THEN YOU ARE

DOING

IT

WRONG

Allow me to inform you of a little thing called framerate independence, forum member Oko. If you use Always, then what happens if you run the game on a very slow or very fast computer? The game will run slower or faster, that's what. People on slow machines will have an easier game, and people on fast machines will have a much harder game, because stuff is spawning at like, twice the speed or more.

When you use Every X Milliseconds, you GUARANTEE that it will spawn at the same rate on all computers. REMEMBER THIS WELL. SEAR IT INTO YOUR BRAIN WITH A HOT IRON. YOU HAD BETTER START USING EVERY X MILLISECONDS OR I WILL HUNT YOU DOWN AND CRUSH YOU.

Look up more info about this on the wiki.

Please. Please... please post how you did it.

I am saying please but what I really mean is "for the love of God and all that is holy I will twist off your head and throw it into the sun if you don't"

So... please?

Anyway, I'm sure any family picking issue can be solved with lucid's S plugin, since you can do the family picking trick with that too, only without families.

Mine's a Wacom Graphire, model CTE-430.

And as previously mentioned, your test works fine. I do have vanilla Python installed, but no other libraries.

Center View on Me is pretty much best for small, simple games or quick experiments. For flexibility though it's always a good idea to code your own camera movement instead, or use linkman's camera plugin.

P.S. - Nobody is going to "steal" your stuff. If they wanted to make a Mega Man clone they could just make the events on their own whether they're looking at your .cap or not. And it's not like they're going to steal "your" graphics... they're already stolen from Capcom.

Nah, forget it. I'm not just going to guess what your events are doing from a screenshot.

Reproduce the problem in a smaller .cap and upload that. Otherwise, someone else may be able to help.

Your picking conditions are probably incorrect. You should at least be able to get it working with a For Each Object loop.

Post your .cap so someone can see what's going wrong.

Well, this issue is bugging me in a big way, since most of my more accomplished stuff is broken now in post 99.7 versions.

Such is the way of large projects made with beta builds of Construct. I don't mean to sound harsh, but you can't say you weren't warned, and you can't claim that you weren't aware of the risks. Hopefully you can fix the issue by using a different method.

And it's not the first time a project was in jeopardy because new features or fixes caused game-breaking results for an individual. The goal though is to make things stable and usable for future generations of Construct users. The good of the many outweighs the good of the few, or the one*. I too have lost work to the inexorable march of progress. Your sacrifice is not in vain, as v1.0 will be all the better for it.

*Yes, I am a nerd who quotes Star Trek movies with a straight face.

QuaZi

It is kind of quivery though, like it's vibrating. Even if you take out he blood and the random() part of the force action it still looks like it's scared for it's life . My spring method might be cumbersome, but it does make for a more wibbly wobbly blob rather than a shaky quaky blob.

Yours is much simpler to construct, though.

I can't believe I'm posting this but maybe it's because you're sorting your height by whole numbers? You could try floats. Or having your height variables be multiples of however many pixels it is from one object's Y to the one above it. Er, does that make sense? I can't tell, I haven't had my coffee. Let me draw a picture:

<img src="http://i46.tinypic.com/mvqo2v.png">

Okay, the green box is on top of the red box. In regular 2d space they are 16px apart. So maybe their height variables should be multiples of 16. The red one's height value would be 16, and the green one would be 32, etc. That way you could easily calculate the player's height by it's base height + the distance in y it's jump is. Having fine increments of height like that might keep the player from "popping" to the front or the rear when it reaches the next height increment. Just a thought, I haven't tested it. And I'm not going to for the sake of my sanity

dl.dropbox.com/u/1010927/furry%20blood%20thing.cap

yay for no springs attached (it wont work in newer versions so open it in 98.9 or else it just asplodes, hingeing doesnt seem to work the same in new vers)

Actually, it works just fine in 0.99.82

You just need to click on each physics object in the object bar to populate the new property values that were added in recent builds. Anyway, your furry blood blob looks pretty neat