I know what the "customization" reference means. He wants to be able to have certain objects run independent of the time scale.

Yeah, I like that idea. Sure wouldn't hurt to have application-level control of texture filtering. Linear, Bi, Tri...

I can't imagine it would be easy in Construct to do what you are asking it to do. And besides, it sounds like all the time you'd spend coding that spunk could be better used for, you know, learning how to play better.

[quote:1f7p1uzf]f an "O is in family X" condition where added to Construct it would make this pattern easier to implement and a little cleaner. Plus such a condition would be useful in other circumstances.

In the interest of keeping things simple for the end user, I'll agree... however, there isn't much here that you couldn't do with just variables and lots of events. You're right though, a more defined inheritance scheme would be nice for Construct and would simplify things for creators.

It's gotta be something about that CG toolkit. Perhaps it's playing hell with your registry upon uninstall?

Caspis speaks truth. Sometimes, the best deeds go unpraised. It's part of this thing called being a nice person.

Unless the toolkit had anything to do with the visual C++ stuff. When you reinstalled Construct, did you allow the visual c++ installer to do its thing? Otherwise, I'm out of ideas.

I ended up being wrong about my events things. Well, kinda. I achieved an acceptable effect for basic behaviors but could not work with physics. Timescaling, though, I'm all for it.

Tutorials will come. Tell you what, name your first priority in your next reply. Me or somebody else will put together a short example for you in little time. When you have that one, ask us of your next priority. At this early stage, we should realize this will help build tutorial files instead of telling you off about 'not trying it yourself first.'

This is a very fine request. While I do not currently have the time to undertake your ideas to the letter, I will keep it in mind to explain things to this amount of detail in my future sources.

Create all the objects you want to be affected by slow motion in their own family. Next, create a global variable that you can define the percentage of speed you desire. On all objects in this family, create variables to hold the original (normal) values of the changes we will be making.

To make it work, add an argument to all relevant movements and animation speeds that modifies them according to the slow-mo variable. In pseudo code, perhaps something like this:

+On a whim,
-set "SlowMo" to .085

+Slow Mo is on.
-Set "Desired Traits" to (Desired Traits * "SlowMo").[/code:1u2vrr3g]

Of course, this is vastly over-simplifying things, but with some hard work you can achieve a very convincing effect.  You can even ramp the SlowMo using some math to make the transition smooth.  Do you have a cap that I might be able to play around with?

This is already implemented in the program options. Although, not all key combinations seem to work for me..