Anyway, I made a cap file to demonstrate my previous post. It's not very exciting, at all.

Just a quick hack to show the OP one of the many options he could use.

http://tropple.com/caps/time.cap

Okay, so what you'd want to do is when your player dies, store the time in a variable for just that.

For example, death_time. Then when death_time has a value to compare, if the difference between it and the current time exceeds your delay (5 seconds, for example), then do your function/action/magic.

I will provide a .cap later if you like, I gotta go right now though. Good luck

Well basically, when my player dies, a value is constantly added to. When that value reaches certain numbers, things happen..like the screen fading to black or going to a different layout.

It works fine when I use V-Synced Mode, but everything happens waaaay too fast when I use Unlimited Mode. I read that if something like this happens (anything running too fast when you use Unlimited mode) then Time Delta should be applied..otherwise you'll have some problems on certain computers..but I guess this situation is different?

So when your player dies you're trying to delay a little bit of time then fade the screen out or restart the level ?

Er... By nature if an event occurs every X ms it's timesynced to begin with. The problem with unlimited FPS is some computers might run the game at 100fps, some at 20fps, so on and so forth. You never know. So moving something by 50 pixels every step will vary wildly depending on how fast the game is rendering.

If you're doing things in steps of time anyway, you don't need to worry about it.

Maybe you could elaborate exactly what you're talking about, because what you've listed is the same as doing 100ms x 50, x 100, x 150 (5 seconds, 10 seconds, 15 seconds).

Why don't you just "do this every x ms" (every 5, 10, 15 seconds) ? Why bother adding to a counter?

EDIT: Missed this question:

[quote:10frcve3]Also, unless I misunderstood, Time Delta varies. This means the value will never actually be exactly 50,100, or 150, right?

Sure it varies a little (or can a lot), but it ultimately depends on how much you're doing each step. If you load resources at random times during the game it'll sky rocket when you do, compared to if it's humming along just doing the same stuff every frame.

TimeDelta is usually a very small number. For example 0.0013. It's the time it takes your computer to perform 1 game loop. Even on a "slow" computer, it's usually a very small number (compared to whole numbers). Most computers can render a basic game at 60fps solidly with vsync on. Mine can run my sample projects upwards of 10,000 at times with it off. That's a really small number

I can't think of a reason you'd need to be using TimeDelta in a cumulative fashion like I think you're attempting (even though it's not in your sample you give). Construct does this for you by offering the "every X ms" event.

But again, unless you elaborate more, I can't even fathom what it is you are trying to accomplish. But to answer your question... if you are adding it cumulatively every gamestep... if you're casting it into an integer, it will eventually land on the whole number you're after. Yes. But if you happen to do something time consuming at that moment, it may skip over the number you are after. I'd encourage you to use greater than/equal to as opposed to just equal to.

But for more accurate time calculations, just use what construct offers.

Just to further the compliments on construct, I'm a C++ programmer for many years, and I always looked down upon game makers as half-assed, no-skilled dead ends for people too lazy to learn how to really make games. They were always too limited to make anything decent (and typically, suffered horribly in performance).

Forgive the snobbery, just being honest.

However, Construct has changed my opinion completely. It's extremely well done. While it still has its limitations, it's light years ahead of game makers I've looked down upon in the last decade... to the point where I'd say it's a mandatory wrench in any game builders toolbox. Whether they use it to release the game or not. It's just marvelous for fleshing out ideas quickly and getting demos up and running to pitch ideas to others.

Most of this is based around the open-ended nature of Construct and it's ability to be extended by a powerful scripting language. Instead of offering people a box to play in, you've given them an engine they can tap into (effectively, giving them a world).

Well done, Scirra!

Just my two cents, but this is probably why virtually every support service from game companies begins with... "reinstall your game and try again."

Because I'm sure they've wasted countless hours trying to fix games people tinkered with and broke.

Something else you could try is preemptive file screening. It would be a little bit of an upfront time sink, and possibly more complicated than it needs to be... but do an md5 hash of all your files and store them in your compiled source. Then at run time you could scan and compare your external files to the md5 hash (for example).

If the file signatures don't match, politely inform the user there's a problem with the file, tell them to reinstall it, and quit.

If you use thousands of external files, this would suck. If you use less than 50, it's probably not too difficult to do this. EDIT: Alternatively, you could zip archive your files and use zlib to access them... then just do one hash of the zip archive (this isn't hard to do in C++, but in construct it might be tricky... Though there are python zlib and md5 scripts out there).

That's just one idear I had off the top of my head.

Excellent update, guys, and very much needed for us Python types.

The reference to newly created objects is dreamy.

I just recently posted a thread here "Fix Your Timestep" which essentially illustrates this problem and even includes a comprehensive fix for it.

At this point, it's up to the developers.

Well, this is open source, I guess I could post a patch. Not something I'm able to dive into right now, unfortunately.

Oh yes, based on the above users suggestion, I forgot to say in mine....

Import/Export of layouts/sheets is extremely important in a team environment.

Merging caps would be another godsend.

I'm still new to Construct, so my suggestions may be short sighted.

• More Python integration. Currently exposure to the core engine is hit or miss. By more, I guess I mean full exposure. If I can "point and click" to it, I should be able to just python it.

• Speaking of Python, the current editor is kind of fumbly. Tabs for example sometimes work, sometimes change focus in the window. Sometimes the tab brackets don't work. Copy-pasting acts weird at times. The "intellisense" (helper text) isn't very complete or helpful, usually. It's not any one thing, it's just not as polished as it probably could be. Right now I use IDLE and copy-paste. But, then there's copy-paste issues at times (python could be less nazi about indentation in general, but what do you expect from a language that has an optional end statement operator).

• Networking. Nothing more than a layer or "wrapper" is really required, but some native support to connect and send packets around would be swell. PodSixNet works pretty good right now. Having integrated support would be faster, though. Object Replication would be dreamy creamy, but you did ask for blue sky stuff. This is the stuff end users would be interested in. Making a network object and telling it to be broadcast, and it internally be taken care of.

RakNet does all of this, quite simply too. I know the licensing might be an issue for an opensource project, but that should be between the game creator and Jenkins, not Construct and Jenkins (RakNet is free for most people -- only when the dough rolls in does he ask for a cut).

• Sprite Indexing and or easier/more obvious instance selection. Instancing in Construct is rather "masked." I don't know why, as it's extremely vital to select the thing you're trying to modify. For Python too!

• Astar module? I have it working in python, sure, but again, more integration means faster computations (compiled C++ vs. python...) It's a pretty easy thing. You guys even have a "node" editor built into some modules, so laying custom paths down would probably be easy, even for 1.0. Pre-generated pathing nodes would be a must too (and would probably be a lot faster in C than again, Python). Not that python is dog slow, it's pretty quick, but more speed is more speed! *grunt, grunt*

• Speaking of Astar, that's probably too low level anyway. Why not just go for sky blue and do AI actors? It's a pretty important part of a game, these days.

Hm, I guess this is more of a 1.0 wishlist than a 2.0 one. Most of this stuff I could see be attainable for 1.0, or well, should be anyway.

Like I said, I'm new still. Can't think outside the box yet =)

Have any of you developers read this by Glenn Fiedler?

http://gafferongames.com/game-physics/f ... -timestep/

Just curious on your thoughts of possibly including this in a future build of Construct?

I noticed that the physics are tied to the frame rate... I can't run unlimited FPS or the physics are non-functional (basically). Possibly I am missing something, though (I am using TimeDelta where applicable).

Feel free to correct me if that's the case, otherwise, I think you'll find Gaffer's solution to be quite simple and very effective. It also takes into account time scaling (slow motion, fast forward replays, etc).

PS: The State stuff in the article snippets is a little confusing, but if you scroll down and download/run the source code example for the tutorial, it'll make more sense.

I had some success doing my own cap of this today but im not much of an artist so the graphics didnt line up very well.

You could do it in python using py picker and some code to orbit objects around a point (in the event you wanted to maintain the running circle feel). I ran out of time at that point and didn't continue. I hope that steers you along the right path though.