A lot of the links aren't working because files weren't transferred from the old forum. Try the tutorial list here, which provides links to them: http://www.scirra.com/forum/examples-tutorials-list_topic41594.html

Thankfully, due to Construct 2's ability to transfer events and objects between caps, it's MUCH easier to reproduce the problem in an isolated cap.

Has that been fully implemented? I thought it wasn't finished yet.

No need to get exasperated, his thoughts and concerns are valid. People coming into the community haven't been following the forums as much, and often ask a question without thinking to use search first, not to mention the FAQ link at the top of the forums doesn't even go to the FAQ. :/

A simple, friendly message stating "Your concerns have been adressed in the faq/forums, here's a link" takes less time to write, and keeps people happier! :)

I recommend reading the indiegamer forums (forums.indiegamer.com), as they are geared towards the 'professional indie' and discuss this sort of thing often.

After reading it a lot, the most recommended course of action there seems to be: don't make a web portal, release your game on your website first, then if you want to, sell it on portals.

I think you misunderstood my suggestion - there's a option in my nvidia control panel that rotates the screen's content back, resulting in a 1080x1920 display, instead of the normal 1920x1080 with no head tilting necessary.

But as others have said, using groups and subevents is very effective as well.

Please stick to english on the forums, or at least provide a translation. Thanks!

Construct has a hidden feature that automatically does a lot of this.

To use it:

Put everything that acquires a health bar into a family.

Set the healthbar to destroy at startup.

Then, at the start of layout, for each member of that family, create a health bar.

Then in another event, set the position of the health bar to family.x, family.top-howevermuch.

Construct will automatically place a healthbar at each family member. You can also use this technique to set the width of the healthbar to family variables, such as family('hp'), and construct will automatically know which instance to use.

This is actually better than the container method, as it is simpler to set up, all automatic and doesn't require a different health bar object for each sprite.

Wow, that's a huge jump since the new site was launched! Looks like what you're doing is working quite well! :)

lol whoops

There's also setting the variable to 1-itself. If the variable was 0, it gets set to 1. If it was 1, it gets set to 0.

It does actually stay in the same spot, though it appears to move. Try switching to another frame then back again.

Every ms is not accurate at small levels, like 10 ms. For larger values, like 1000ms, it's plenty accurate, so using an every 1000 ms event to create something will work fine.

Timedelta is a measurement of time. It returns, in seconds, how long the previous frame took to calculate and render. So if you're getting 1 frame per second, timedelta returns 1. If you are getting 10 frames per second, it returns 0.1, as each frame is taking a tenth of a second for the computer to make.

Set X to .X + (r * TimeDelta)

So at 1 fps, to the computer, it becomes:

Set X to .X + (r * 1)

At 10 fps:

Set X to .X + (r * 0.1)

r is the rate. That's the value you choose for the speed. 100 will move it 100 pixels per second, regardless of the frame rate.

Set X to .X + (100 * TimeDelta)

If the current x position is 0:

At 1 fps:

Set X to .X + (100 * 1) = 100

At 10 fps:

Set X to .X + (100 * 0.1) = 10

Then after one second, the sprite will be in the same position regardless of the framerate.

Did that make sense?