Same goes for threads... if you delete the OP of your thread, it leaves all the replies behind. That's even worse than just deleting single posts because the thread REALLY doesn't make sense any more.

If your thread has no replies then that's okay I guess. Otherwise, leave it be.

In doing my own tests with this (using that same formula), the lerp causes the door to lag behind the image point on the player when the player is moving, even if the lerp amount is large.

I even tried to change it up so that all the calculations for door movement were "local" and relative to player space, rather than targeting the player image points in world space. It was a little better, but still laggy.

I'm sure there is a formula out there that will do this perfectly, and I am also sure that formula is way out of range of my math skills. So as I mentioned before, I think the simplest and most accurate method would be to make door opening and door closing animations for your door sprite.

(If Construct had any sort of parenting ability, you could parent the player to the door and move the door child locally along it's own Y axis relative to the player. All other positioning and rotation of the player parent would be automatically transferred to the door. Unfortunately, Construct doesn't do that... so, uh, this is a moot point I guess )

Please do not delete your posts. It breaks the forum. You get threads and replies that don't mean anything any more.

If your files are missing, just update your posts stating they are no longer available.

... Crap. That is EXACTLY what I did. LOL

Thanks for the help, guys! XD

Hehe, no problem

Ah, I see . Well, the math for that is way over my head.

What I would recommend is that you create an animation of your door moving open and closed. That way you can just play the animation, and it will appear to move properly no matter which direction it is facing, and will remain attached to the proper location at all times (instead of floating around with lerp).

It would be helpful to have more information. Does your vehicle rotate? Or is it always facing the same direction? If you could provide an example .cap of what you're trying to do, that would be very helpful as well.

Hehe, no problem

Did you add the texture file?

i don't like using timedelta, it messes with my need for perfectionism.

Don't confuse the guy Quazi. TimeDelta is important unless you really, really know what you're doing. You're expert enough that you can work around it with advanced methods to get beyond it's limitations.

But for the rest of us who aren't that advanced, and for about 95% of everything we would need to do, timeDelta is the way to do it. It's a very important tool to learn, and you really should learn it before you can safely gauge whether or not you will need it for any particular task.

My advice to Azu:

Set down your game for an hour or two and mess around with timeDelta in a fresh .cap. Move some boxes around. Make some timers. That sort of thing. Once you get used to thinking in pixels per second instead of pixels per tick, it's not so hard at all.

And with your new mad skillz you will be one step closer to being a Construct Champ that gets all the ladies*

*(Individual results may vary)

This is due to your order of events.

In event 2, Level is equal to 1. One gets added to Level. Level now equals 2.

In the next event, Level equals 2, because you changed it already in the previous event. So it meets the condition for "Level equal to 2" and the event triggers, which adds 1 to Level. Now it equals three.

In the next event the same thing happens. And so on down the list until you hit six.

So, you could do this a few different ways. The first is you could add another criteria to your conditions to keep them from triggering all in the same tick. I would make another variable called "switch" or something like that, that turns On when you click the button, and turns Off when you level up. That way you can check Switch in your conditions, and if it is Off, then the level-up action won't run. Like this:

+On button clicked
  -> Set Switch On
    + Sprite Level = 1
    + Switch = On
      -> Level up
      -> Set Switch Off
    + Sprite Level = 2
    + Switch = On
      -> Level up
      -> Set Switch Off

Etc.
[/code:puxsx5mi]

The second way you could do this is to reverse the order of your level code.  So it would look like this:

[code:puxsx5mi]
+ On button clicked
  + Level = 5
    -> Set level to 6
  + Level = 4
    -> Set level to 5

Etc.
[/code:puxsx5mi]

And finally, since it seems you are doing a really simple linear calculation to increase your levels, you could simply do this:

[code:puxsx5mi]
+ On button clicked
  -> Add 1 to level
  -> Multiply Attack x 2
[/code:puxsx5mi]

And leave it at that.

You might want to ask Minor about this sort of thing. He's currently working on a game that does exactly this.

You can see a video of it here in this thread:

But I imagine it's rather complex, so I don't know how willing he is to divulge his work.

I don't see any Graphics-type objects (e.g. Sprite) in the insert object dialog.

Halp. ;o;

[edit]Here's a screenshot as proof: http://dl.dropbox.com/u/2982005/construct_classic_nogameobjects.png

Are you sure you didn't pick "New Application" instead of "New DirectX Game" when you started your project?