Chronos – Time Control – Unity Awards Winner

Thanks, I'm sorry for not examining the thread earlier! what parts of the Unity API currently block you?

 

I did try to pitch some feature requests to the engineers at Unite Boston, but I guess they're quite busy. The core required feature would be to serialize / deserialize a complete GameObject at any given point, even in an opaque data structure. Without such a thing, replayable method calls would be a nightmare to manage and highly unstable.

Even if I didn't include replayable method calls (and that's already a big sacrifice, IMHO), there are some objects that are complex to reset at a certain point in time (namely animators and particle systems), so the replay wouldn't look exactly the same. I could circumvent that by recording the position of every single bone or particle, but that requires some major data compression to be viable. Serializing/deserializing the animator's recording (even in an opaque format) would help, but it's not possible yet. I guess I could also manually resimulate particles up to a certain time (like I do with Chronos), but it comes with its fair share of limitations.

 

To clarify what I mean about replayable method calls (RMC):

Say at a given point in time, you want your object to turn red instantly. With a RMC, you could do something like:

Code (CSharp):

1. void ChangeColor(Color color)
2. {
3.     GetComponent<Renderer>().material.color = color;
4. }
5.  
6. replay.Invoke("ChangeColor", Color.red);

And if you reload the scene and start a replay, at that exact moment, the object would turn red.

But what if you don't reload the scene, and instead ask for a replay of the last 5 seconds (before the object turned red)? Your object is still red, while it should be of its previous color instead.

That's the whole problem with RMCs: reverting them without reloading the whole scene, nor forcing the user to write inverse code (like Chronos does with occurrences). I consider it too troublesome for someone wanting to implement replay in their game to start coding all their actions in reverse.

 

That said, I'm not even sure (de)serializing an object would help without bringing some significant memory bloat, but it would make starting replays a bit easier for the end-user and me, most importantly for instantiating / destroying game objects at given points in time without need for some complex tracking.

 

In my case I'm probably most likely going to put hooks in the RPCs for networking with some meta data, so that I can at least record the gameplay, if only in one direction as a fall back. It's a bit of work, and annoying but should suffice mostly, if I use the meta data to construct valid targets for the data, and call my pooled particle systems.

For Chronos, or an asset to do it, I can understand how hard this must be.

 

That's the thing: replayability for a known game concept with its limits is easy (easier) to accomplish. But for any game where it has to "just work" (for a lot of people who can't even write a line of script), it becomes nearly impossible.

 

Thanks for the quick response. I tried it and it still didn't work. I even tried to put most of the Chronos-related scripts at negative numbers (so they will be executed before default time), and still get the same problem... I noticed that at the point of AddForce, the time.rigidbody2D has its velocity as (NaN, NaN), as opposed to (0, 0).

Also, I noticed that during the first few calls to FixedUpdate(), time.rigidbody2D.velocity is also (NaN, NaN), and after a few calls it becomes (0, 0).

 

Hm, that sounds like a bug, although it's so obvious that I'm surprised nobody has reported it before. I'll investigate and get back to you ASAP (probably won't be today though, I have to catch up on a bunch of university stuff).

 

That university life... I feel you..

Also, I know that you mentioned in the website, that we can not rewind particles that are in world simulation, but do you think that this will eventually be possible?? Because only particles in local space being rewindable means that we can only rewind static particles (such as a water fountain). If we have a car that has a smoke particle system attached to it, even tho we can rewind the car itself, we won't be able to rewind the smoke, which makes it less realistic.

 

To be perfectly honest, unless Unity changes their API and starts allowing negative playback speed for particles, the answer is most likely no. Have a look at Chronos/Source/Timelines/RewindableParticleSystemTimeline.cs if you want a preview of how I do it right now. Resimulating at each frame seems to be the only solution, and as such it forces a renewal of the source of emission. It's quite a hack, but that's the only way I found after weeks of trying.

If you want to support the feature request I posted quite some time ago, you can head here:
https://feedback.unity3d.com/suggestions/allow-negative-values-on-particlesystem-dot-playbackspeed

 

Hi,

We currently have some problems using rigidbody.IsSleeping(), it always returns false when coupled with Chronos.
The rigidbody timeline internaly disables the useGravity to apply gravity manually.
This seems to be the root of the problem.

Is there a workaround or am I doing something wrong ?

Thanks.

 

Hi Tony,

That's a known issue; rigidbodies are not sleeping anymore with Chronos because of the manual gravity. I've tried reverse engineering the algorithm Unity uses to determine whether a rigidbody should be put to sleep (e.g. with a threshold on the kinetic energy formula), so that I could manually put them to sleep, but after several days, it never worked like Unity.

You could write a simple script that checks for that kinetic energy formula compared to the sleep threshold in FixedUpdate, and if so, call Rigidbody.Sleep(). Maybe it won't be exactly like Unity's default, but it should at least help put some rigidbodies to sleep.

Code (CSharp):

1. void FixedUpdate()
2. {
3.     float E = rigidbody.velocity.sqrMagnitude * 0.5f
4.     E += rigidbody.angularVelocity.sqrMagnitude * 0.5f;
5.  
6.     if (E < Physics.SleepTreshold)
7.     {
8.         rigidbody.Sleep();
9.     }
10. }

 

Hey, awesome asset
I have bought it yesterday. At this moment I haven't testing it. So I maybe this question is stupid ;P

Is it possible to reset the time instantly to the beginning?

 

Hi Neo,

Unfortunately, as mentioned plenty of times in this thread, Chronos is not a replay plugin. Please have a look at the previous pages for an idea as to why that is and what are my future plans.

Cheers!

 

Hey,

Hope school is treating you well..

I took some time to investigate the rigidBody2D.velocity being (NaN, NaN) bug, I found that the RigidBody2DTimeline calculates the velocity using component.velocity / timeline.timeScale, and timeline.timeScale is 0!!

The timeline gets its timescale at its Start() from its Clock object's time scale. In my case, this Clock object is a global clock parented by a "Root" global clock. The Clock object I have calculates its correct timescale using its local timescale and its parents timescale and this happens in the Start() function, which makes sense. BUT, what I noticed is that the Clock object's Start() gets called BEFORE its parent clock's Start(), which means the Clock will have a timescale of 0...

I am wondering how is Chronos handling the order of the creations of parent clocks and child clocks?

Also, I am playing with the Chronos files execution order a lot, they are now mostly executed before the default time, but does the order among the Chronos files matter? E.g. TimeKeeper.cs before Clock.cs or TimeKeeper.cs after Clock.cs, does it matter?

 

Oh, that does make sense. I remember fiddling around this a lot a couple of months ago and not finding a perfect, automatic solution that would be performance friendly.

Before calling your method (since it's in start), try calling:

Code (CSharp):

1. timeline.clock.ComputeTimeScale();
2. timeline.rigidbody2D.AddForce(...);

The documentation about the method is here. It should force a recalculation of the time scale that takes parents into consideration.

Tell me if it works. Even if it does, I consider this to be a little hacky and I'll try to find an automatic solution for the future, but at least it would fix your problem for now.

 

It still doesn't work. I think we are recomputing the clock's timescale and not the timeline itself's. Since rigidBody2DTimeline's velocity is calculated using the timelines timescale, it will still give us a NaN error..

Does Unity allow us to control in which order components of a game object get initialized?

 

Ok, this is getting quite annoying. Let's recap.

• In Clock.Start, parent-child relations are established, then time scale is computed. This is in Start to make sure that every Clock has been registered within the Timekeeper.Awake.
• The first problem you face is that the Child clock computes its time scale before the Parent clock. Because of this, the Child's time scale is multiplied by its Parent's then-zero time scale and stays at zero. There seems to be no Unity way to guarantee the order in which Clocks get initialized.
• We "fixed" that by forcing a time scale recalculation of the Child clock before adding the force.
• The second problem is that this doesn't automatically update the Timeline (for performance, it's only updated once per update).
• We can't "fix" that again by manually setting the Timeline's time scale, as it is a protected setter (for good logical reasons; you never should have to set it).
• Even if we could fix all this manually, it's ridiculously hacky and code-bloating. Users shouldn't have to worry about that just because they want to use Chronos in Start.

I think I found a fix, would you mind trying it?

In Chronos/Source/Clock.cs,
after line 49 (parent.Register(this)),
add: parent.ComputeTimeScale();

With this, you shouldn't need the previous fix. This will ensure parent time scales are always calculated before children's, and therefore the change should propagate correctly.

However, we still need to set up a proper execution order. It should be:

1. Clocks (LocalClock, GlobalClock)
2. Timeline
3. (Normal)

This is to make sure that the Clocks calculate their time scales before the Timelines copy them, and that your scripts get called after all that, when the timeline has a proper time scale assigned.

I think I can ship a package with a predefined execution order (it's in the meta files IIRC), so I'll try to have all that automatically fixed in the next version. In the mean time, I'm really grateful for your patience and I hope we can get this resolved ASAP.

 

Yes, the fix works.

Thank you so much!

 

Hi

I am just wondering how easy it might be to add Chronos behaviour to an application that uses a couple of other popular plug-ins?

First of all Curvy, which enables objects to move around a curve based on a constant velocity with the help of a SplineController script that moves it based on time, delta time etc.

Second, I am using UniRX (Reactive Extensions) which permits something like the code below and in this case it is part of some spawning code

spawnTimer = Observable.Interval(TimeSpan.FromSeconds(CurrentWaveTimePerSpawn))
.Take(CurrentWaveNumLeftToSpawn)
.Subscribe(_ =>
{
SpawnWaveItem(wsvm);
});

.. so I'm not sure how easy it might be to rewind/unspawn and pause etc.

Any advice much appreciated

cheers

Nalin

 

Hi Nalin,

I can't provide support for third party plugins, but you can adjust them yourself. The easiest solution, when plugins include a "speed" parameter, is often just to multiply your actual speed with the timeline's time scale parameter (e.g. Curvy.speed = 3 (actual speed) * 0.5 (slow motion) = 1.5 (adjusted)). That saves you the trouble of editing the plugin files themselves.

For other types of plugins, you might want to look for references to Time.deltaTime and other similar calls to replace them with the Chronos equivalent (e.g. GetComponent<Timeline>().deltaTime). A list of required migrations is available here to make your life easier: http://ludiq.io/chronos/migration

Let me know if you have more specific questions.

 

I've been getting this warning message:

"Trying to change the mass of the rigidbody while time is paused or rewinding, ignoring."

Is there a reason why you can't change the mass of a rigidbody while paused with Chronos? What would happen if I override this warning and have it perform the mass change?

The reason I ask is that I have a script that imports stats for different game objects at the start of a scene, and sets different parameters like rigidbody.mass during the Awake() call, which is necessary for several other functions that happen immediately after. Chronos seems to treat Awake as timeScale = 0, which is the same as paused.

 

Hm, actually no, that's an old warning from back when mass was used to simulate time effects. You can safely ignore it for now.

If you want to stop the warning from showing, change the check's severity from "Warn" to "Ignore" in Chronos/Source/Timelines/RigidbodyTimeline.cs on line 126. I'll make that default behaviour in the next version.

 

Changing the check's severity from "Warn" to "Ignore" only disables the warning message, but the AssertForwardProperty function still blocks the call to set the rigidbody mass to the desired value if you're calling it on Awake (i.e. when timeScale <= 0). I've change line 126 in RigidbodyTimeline.cs to the following to make things work properly for now:

set { bodyMass = value; }

 

Oh, right. Thanks for the heads up.

 

Chronos v.2.2.1 has been submitted for review!

• Fixed bugs related to execution order
• Fixed area clock gizmos
• Removed restriction on changing mass while time is paused or rewinding
• Added Recorder.ModifySnapshots()
• Optimized active component lookup on timeline

Full changelog: http://ludiq.io/chronos/changelog

 

@ludiq
I upgraded to Unity 5.3 a couple of days ago and notice several compiler warnings regarding enableEmission property being obsolete. I know this is not a showstopper, but will you be releasing an update to fix the obsolete warnings? I know this can be an issue for backward compatibility, so I didn't know your policy on how you handle these kinds of situations.

I really enjoy using Chronos. It is a great asset.

Thanks.

 

Hi! Yup, another user warned me about those. I haven't had the time to look at 5.3 yet (finishing my semester right now!), but I intend to fix them for v.2.2.2 (and have a look at whether the new particle improvements could speed up Chronos in some way).

My policy on versioning is to always follow the latest Unity version. Therefore, v.2.2.2+ will only work on Unity 5.3+.

 

Hello!

Having some troubles compiling Chronos plugin in my project after dowloading it from a DVCS.
Here is the error I get when compiling:
Assets/Plugins/Chronos/Source/Dependencies/Reflection/Utilities/Extensions.cs(8,29): error CS0101: The namespace `Chronos.Reflection' already contains a definition for `Extensions'

Compiler is right (as usual), there is a definition for "Extensions" in:
--> Dependencies\Reflection\Utilities\Extensions.cs
--> Dependencies\Reflection\Editor\Extensions.cs

I surely missed something really dumb, but cannot find what

For information, I just synchronize Assets and ProjectSettings folder to the DVCS, so the whole Library folder has to be recreated and it seems to happen because of this. Taking the original project with the full Library folder works.
So is there something stored in Library that is mandatory and that I missed?

Thanks for your help

 

Is there any way to make the unity Cloth system work with Chronos?

 

Hm, I hadn't thought of it. By looking at the documentation, perhaps I could make it work by substituting the normal force with a timescale adjusted gravity and by multiplying the world scales. I've added it to my longer-term schedule.

Usually, that would be avoided because the Editor folder is compiled in a separate project. Did you somehow place all of Chronos under an Editor directory? It should be placed under a Plugins directory instead.

 

Hello,

I placed the whole plugins in the Plugins folder.
I wonder, should I even include the whole "Source" folder in my project?
Sorry I'm very new to Unity plugins and not sure what I should keep in the project.

Thanks for your help.

 

Hm, that's odd. I'll do some more testing after Christmas and try to figure it out. Worst case, I'll rename the classes, but I don't understand why they're conflicting (only on your install) in the first place.

Cheers!

 

I have a quick question about implementing Chronos for a move based puzzle game. Essentially I want to be able to 'undo' moves, allowing the player to rewind each move they've made by pressing a button. I assume this would be best achieved by taking a custom snapshot at the end of each player move?

Thanks! - Hawk

 

Hi, I have just purchased Chronos and when I import it I get these 2 errors ..

Assets/Chronos/Source/Editor/AreaClock2DEditor.cs(31,18): error CS0616: `DrawGizmo': is not an attribute class

Assets/Chronos/Source/Editor/AreaClock2DEditor.cs(31,18): error CS0246: The type or namespace name `DrawGizmoAttribute' could not be found. Are you missing a using directive or an assembly reference?

Unity 5.3.1f1

EDIT ..

It was a Javascript called DrawGizmo in the Plugin folder causing the error .. all sorted now.

 

Now Im having a problem accessing from JavaScript, can someone point me in the right direction please .. Thanks.

Code (JavaScript):

1.  
2. #pragma strict
3.  
4. import Chronos.Example;
5.  
6. private var _time : Chronos.Example.ExampleBaseBehaviour;
7.  
8. var _rotationTime : float;
9.  
10. function Start ()
11. {
12.     _time = GetComponent.<Chronos.Example.ExampleBaseBehaviour>();
13. }
14.  
15. function Update ()
16. {
17.     transform.Rotate(_time.time.deltaTime * Vector3.one * _rotationTime);
18. }

I thought that should work but I get the error ..

NullReferenceException: Object reference not set to an instance of an object .. at line 17

 

Still stuck on this .. I've tried ..

Code (JavaScript):

1. #pragma strict
2.  
3. import Chronos.Example;
4.  
5. public class TestRotation extends MonoBehaviour implements ExampleBaseBehaviour
6. {
7.     private var _time : Chronos.Example.ExampleBaseBehaviour;
8.    
9.     var _rotationTime : float;
10.    
11.     //              ----------------------------
12.     function Start ()
13.     {
14.         _time = GetComponent.<Chronos.Example.ExampleBaseBehaviour>();
15.     }
16.     //              ----------------------------
17.     function Update ()
18.     {
19.         transform.Rotate(_time.time.deltaTime * Vector3.one * _rotationTime);
20.     }
21.     //              ----------------------------
22. }

Still no luck ..

 

I'm not a JavaScript expert, but I believe you should directly extend ExampleBaseBehaviour, because ExampleBaseBehaviour itself extends MonoBehaviour. It's a simple inheritance hierarchy.

Your code should be:

Code (JavaScript):

1. #pragma strict
2.  
3. import Chronos.Example;
4.  
5. public class TestRotation extends ExampleBaseBehaviour
6. {
7.     var _rotationTime : float;
8.  
9.     function Update ()
10.     {
11.         transform.Rotate(time.deltaTime * Vector3.one * _rotationTime);
12.     }
13. }

How did you implement the BaseBehaviour class? It should be something like this:

Code (JavaScript):

1. #pragma strict
2.  
3. import Chronos;
4.  
5. public class ExampleBaseBehaviour
6. {
7.     function get time()
8.     {
9.         return GetComponent.<Timeline>();
10.     }
11. }

P.S.: How did you create a JavaScript namespace for "Chronos.Example"? I thought JavaScript had no namespaces.

 

Unfortunately, Chronos isn't built for per-snapshot rewinding. I tried looking at the source to see if it could be easily adapted, but the architecture truly isn't fit for it without some major changes.

However, I suggest you create a simple data structure -- a snapshot class -- to hold the game state at a given point (e.g. where the puzzle pieces are located, etc.), then fill it at each move and add it to a Stack. Then, on "rewind" (which would more aptly be named "undo"), simply pop and apply the latest item on the stack. I can't really give you further help, but this should get you started!

 

Was spending some time finding the cause of a memory leak that was resulting in some nasty crashes in my game and it turned out Chronos was the culprit.

It looks like if you have an Animator attached to any timeline, Chronos' default behaviour is to start recording, and with a default recording amount of Infinite.

Is there a reason why this is the default setting? It seems kind of counter intuitive that there would be a "Recording Duration" variable in the Timeline component, but it doesn't affect the time that the Animator records for. I noticed in the Chronos' documentation under Limitations it states that there's a Memory Leak under the Animator, but this seems to have been patched in the newest versions of Unity, and now it's just Chronos itself that is causing the memory leak.

I'd also mistakenly assumed that disabling the "Record Transform" bool would disable all recordings for reverse timeflow (I only need the forward time control abilities) but after looking through the source code it looks like I was wrong. Is there any particular benefit for separating out the Animator recordings so they're always running? It seems like a large amount of overhead for any components with an Animator attached.

 

Argh, that animator leak bug is still there? Unity told me they had fixed it on their machine, and it doesn't occur on mine. Are you sure the leak comes from Chronos (e.g. a Chronos component or script) and not from Unity's animator (i.e. Scene Memory > Animator)? (I take it you know how to tell the difference with the profiler, since you said you've been debugging a leak).

If it's from Chronos, can you tell me which script?
If it's from Unity, I'll reopen that bug report at Unity's QA.

As you noticed, you can change the DefaultRecordingDuration in Source/Timelines/AnimatorRecording.cs so that it isn't infinite. However, I've taken note of your comment and will try to provide a "Rewindable Animator" and "Animator Rewinding Limit" on the timeline itself. In the mean time, I'm more concerned about the memory leak.

 

May not have worded that the best. The "leak" is Unity's animator using an indefinite amount of memory which eventually causes a crash (so under Scene Memory > Animator, the memory allocation will keep growing). This is because Chronos has the DefaultRecordingDuration set to 0 (infinite), so Chronos is the root cause.

If you change DefaultRecordingDuration to any non-zero value the Animator will cap the recording properly, so yes, Unity fixed the animator leak bug, but the fact that Chronos by default tells the Animator to record indefinitely is in itself a "memory leak" which will cause Unity to crash eventually.

The simple fix for this would be to change DefaultRecordingDuration from 0 to 10000 (your current upper limit) and possibly also change the lower clamp value of _recordedFrames so that the value is never 0 (AnimatorTimeline.cs, line 34).

I can't think of a good reason to ever record indefinitely, it's just asking for trouble.

 

@ludiq thanks for the answer, that worked fine, I have a Mech walking around and when I slow the global clock down his animations slow but he still walks at the same speed so I now know I need to use

Code (JavaScript):

1. timeline.navMeshAgent.speed

but how do I add timeline Into that script ?

Thanks.

 

Since you have your BaseBehaviour (I presume), you can simply use:

Code (CSharp):

1. time.navMeshAgent.speed

If your class doesn't extend BaseBehaviour, you'll have to use:

Code (CSharp):

1. GetComponent<Timeline>().navMeshAgent.speed

 

Hi all!

So I've been using Chronos for my game and I was finding some strange behaviour when pausing time and using NavMeshAgents. I hold the timeline timeScale at 0 for a couple of seconds. When the timeline timeScale goes back above 0 (unpaused), the objects would move backwards a small amount and then continue on.

My object has both a rigid body and a nav mesh agent. The rigid body is of course set to kinematic while the nav mesh agent is doing the movement work. The first problem here though is that when the RigidbodyTimeline3D restores its snapshot, it writes to the game object's transform. The nav mesh agent does not like it when we manipulate the transform position directly. I added some lines to the rigidbodyTimeline3D so that if there is a NavMeshAgentTimeline with a non-null Component and the NavMesh is enabled, it does not write the position to the transform.

I changed NavMeshAgentTimeline to implement Update as well. It tracks when the nav mesh agent's timeScale hits 0 and stops being zero like the RigidBodyTimeline, and does a similar snapshot using NavMeshAgent.Warp() to set the position. I also set the NavMeshAgent velocity to Vector3.zero when it registers that time has stopped.

We're not currently using the recording for playback on any of our objects so I haven't tested how it might affect that.

These changes in conjunction fixed my problems. What do you think? Should I share that code back somehow?

 

@ ludiq It's all working now ..

Code (JavaScript):

1. private var _navAgentTime : Chronos.Timeline;

then at start ..

Code (JavaScript):

1. _navAgentTime = GetComponent.<Chronos.Timeline>();

then calling it ..

Code (JavaScript):

1. _navAgentTime.navMeshAgent.speed = patrolSpeed;
2. _navAgentTime.navMeshAgent.angularSpeed = turnSpeed;

Thanks for your help.

 

Hi, I have a GameObject that has children each with a particle effect on them does each of the children need their own TimeLine or could I slow them down from their parent containing a TimeLine ?

At the moment I have put a TimeLine on each with this script ..

Code (JavaScript):

1. #pragma strict
2.  
3. import Chronos.Example;
4.  
5. public class SlowParticaySytem extends ExampleBaseBehaviour
6. {
7.     private var _slowTime : Chronos.Timeline;
8.     private var globalVarsScript : GlobalVars;
9.  
10.     function Start ()
11.     {
12.         _slowTime = GetComponent.<Chronos.Timeline>();
13.         globalVarsScript = GameObject.Find("Global Vars").GetComponent.<GlobalVars>();
14.     }
15.     function Update ()
16.     {
17.         if(globalVarsScript.slowDownTime)
18.         {
19.             _slowTime.particleSystem.time = 0.0;
20.         }
21.         else if(!globalVarsScript.slowDownTime)
22.         {
23.             _slowTime.particleSystem.time = 1.0;
24.         }
25.     }
26. }
27.  

And they slow when slowDownTime is true.

Thanks.

 

Hi @josh_s_dev !

Thanks for looking into this so extensively. I believe it would've taken me significant time to figure that quirk out.

Would you mind sending me your code edits by PM? I'll look them over and try to implement them properly (with rewind).

Each object needs its own Timeline. Timelines do not affect children.

 

(Just to let everyone know: I'm working on v.2.3 which includes fixes for pretty much every bug on page 8 + the ones I've received by email. I'll release it ASAP).

 

Hi @ludiq

I managed to make some progress with Curvy and I can get it to pause and rewind

However some of the more sophisticated examples have events where the added to the curves so that when a control point on a curve is reached it triggers an event. In this case rewind does not work and I have tracked it down to when it calls UnityEvent.AddListener(call). When this is commented out, it works.

Any ideas why this might be?

cheers

Nalin