When Time.timeScale is set to 0.0, the following code is called until mouseup, but never again, no many how many time I click on the GO’s collider. Setting the timeScale back to 1.0 makes the function repeatable again. Specifically, it’s the second-to-last line that causes the problem. What is it about setting the transform position that is time-dependent???
function OnMouseDrag() {
var referencePoint = Camera.main.ScreenToWorldPoint( Input.mousePosition );
referencePoint.z = transform.position.z;
transform.position = referencePoint;
}
I have a related question.
I notice that I have an object that stops recieving mouseups altogether when timescale is set to 0.
The object has a box collider, and recieves calls normally until timescale is set to 0, then nothing.
Any ideas?
(Edit: Interesting to note that like the original poster, I too can get my code to execute once. After that, mouseup/mousedown isn’t called for that object until timescale is set back to 1. Is this a bug? Workaround? )
function OnMouseDown() {
//check with parent
print("initmode: "+initMode);
if (myParent.FeedbackCall("drag_marker",myID)==1 initMode==0) {
isDragging=1;
dragTimer=Time.realtimeSinceStartup;
//print("clicked!");
}
}
The first time the object’s clicked after timeScale is set to 0, the whole snippet is executed. It doesn’t cause a loop anywhere.
The second time the object is clicked, the print line doesn’t even execute. As far as I can tell, mousedown isn’t called at all.
Now, if I set timeScale to 0.01, the object remains “unclickable” until the next time the physics objects are refreshed (I have a physics system running). After the refresh (which I can see as a small increment in the movement in the physics object), I can click the object once more.
Again, nothing of this happens with timescale set to 1. I am at a loss as to what could be causing the behaviour, as I’m really not doing anything fancy at this point.
The problem is definitely physics related.
If I remove the physics that is interacting (indirectly) with the object recieving mouseups, the problem goes away.
Basic setup:
The “problematic” objetc is a mesh with a box collider. When it gets a mousedown it starts doing raycasts against a mesh it is touching, and adjusting the position based on the mouse location.
When it gets a mouseup, it ceases this procedure.
I’m basically allowing the user to drag the object across a mesh.
The mesh has a collider to catch the raycasts, and the object has a collider to catch the mouseups.
I have two theories:
The mouseups aren’t triggering due to the raycasts. Since timeScale is set to 0, maybe Unity imposes a limit on the ammount of collider interactions per physics “window” (and with timeScale=0, the “window” would be infinitely long).
Mouseups aren’t triggering due to the two objects touching (although they’re not using rigidbodies, and one is set to trigger). Same reason here - maybe this throws a spanner into things by not allowing further collider messages to go through?
I have no idea how the behaviour can be avoided, or what combination of factors may have contributed to it. I’m hoping for some insight on how Unity handles situations like this one, and raycasts/collsions with a low timeScale in particular.
Eliminating the raycasting eliminates the problem.
The raycasting is done like this:
if (initMode==1 || isDragging == 1) {
var ray = Camera.main.ScreenPointToRay (Input.mousePosition);
var hit : RaycastHit;
print("raycasting");
if (Physics.Raycast (ray, hit)) {
gameObject.transform.position=hit.point;
gameObject.transform.position.y=0.1;
}
}
I can’t really see how this would cause a problem?
If the above is commented out, the object this script is attached to recieves mouseups/downs when timeScale=0. If it’s not commented out, it recieves one mouseup/down call, then ignores them.
Alright. I’ve hit the wall. I can’t tell why it would be a problem to do raycasting with timeScale=0, and as said before - it does work perfectly when timeScale=1.
I really do need to get around this somehow, as I do need to get the real world point of the mouse location on that mesh. And I have to do it while “paused”.
This is the same problem I’ve been having. I’ve been able to work around it mostly by using my own raycasts instead of the OnMouse functions.
The problem with these functions doesn’t seem to be completely limited to raycasts, though. In the following project, timeScale starts out at 0. When you drag the box, it moves with the mouse, but only within a certain area, as if the box collider is not being updated (even though it appears to be in the editor). Clicking the box when it is outside the “circle” causes no OnMouseDrag events to occur.
Unpausing the scene (timeScale = 1) using the space bar fixes the issue.
This smells like a bug to me, or at least…a feature.
I find it a bit curious that the original post hasn’t recieved a reply from OTEE, despite being several months old.
It’s a pretty severe problem if you need to have functionality while “paused”.
Sorry, as you can see from the quote I was actually addressing Marble, I hadn’t noticed the time difference . Anyway, it does indeed appear to be a bug, in my first test I wasn’t using orthogonal projection, so the movement of the cube wasn’t large enougth to notice the problem. And you don’t even need to be at timescale 0, 0.001 is more than enougth for the problem to appear.
So you basically check for a mouseclick and use a Unity raycast to get the object clicked? Then you send a message to that specific object, thus simulation OnMouseUp, etc?
Well, tried it but I don’t get it to work - I must be approaching it the wrong way.
I set up a check in Update in my “gamecontrol” script. It does a raycast whenever there is a Input.GetButtonDown (“Fire1”)
A broadcast is done against the object hit by the ray.
However, the problem is the same as before - the raycast doesn’t register after the first click. Since the raycasts created the problem before (see above), I don’t see this as a solution?
Unless, of course, you meant that you’re doing your own raycasts from scratch. If that’s the case I don’t consider it a workaround, as it’s far too much work for circumventing a silly problem that really shouldn’t exist in the first place.
I don’t think you can just use a ‘manuel’ raycast to solve the problem. I used this small script with Marbles project to visualize the problem (Place it on anything and put the cube into layer 8.) and clearly raycasts doesn’t work either.
using UnityEngine;
using System.Collections;
public class CubeCheck : MonoBehaviour {
private ArrayList spheres = new ArrayList();
public float range = 10f;
public float interval = 1f;
// Update is called once per frame
void Update () {
for (int index = 0; index < spheres.Count; index++) {
Destroy (spheres[index] as GameObject);
}
spheres.Clear();
for (float i = -range; i < range; i+=interval) {
for (float j = -range; j < range; j+=interval) {
RaycastHit hit;
Vector3 start = new Vector3(0, 1, -10);
Vector3 direction = new Vector3(i, j, 1) - start;
if (Physics.Raycast(start, direction, out hit, Mathf.Infinity, 1<<8)) {
GameObject go = GameObject.CreatePrimitive(PrimitiveType.Sphere);
go.transform.position = hit.point;
go.transform.localScale = Vector3.one/10;
a.Add(go);
}
}
}
}
void OnDrawGizmosSelected() {
for (float i = -range; i < range; i+=interval) {
for (float j = -range; j < range; j+=interval) {
Vector3 direction = new Vector3(i, j, 1) - new Vector3(0, 1, -10);
Vector3 start = new Vector3(0, 1, -10);
Gizmos.DrawLine(start, start+(direction*5));
}
}
}
}
I tried something extremely similar in my project - however, it didn’t help. Also, it seems like in my case the raycasting is in fact what’s causing the problem.
When I comment out the raycasting code, everything works fine even when timeScale is 0.
I submitted a timeScale=0 problem once, but my project was too big and OTEE wanted me to isolate the problem more, which I eventually gave up on. But if someone has a project that demonstrates this problem, and it doesn’t have lots of moving parts, then it seems like it’s time to submit it.
I did submit it - although I didn’t attach the project (due to several reasons, not isolating the problem enough is one).
I too would encourage Marble or Talzor to submit it and include their test projects. I could obviously do it, but since it’s their code it seems suitable that they submit their respective projects.
I don’t think this is a bug honestly. That might be why they haven’t responded to the thread at all. There is information in the manual about Update and FixedUpdate that is related to this somewhat. Based on last nights trials with timeScale, I discovered that non rigidbody objects with attached script keep chuggling along, while anything attached to a rigidbody seems to hault for the timescale. This then relates to the rotation of an objects in this thread. The object can’t act on that request until time is set to a value other than 0 again.
Mind you, I have only had a few moments to visit this method dealing with time. Hopefully I can get into more depth of the issue later tonight and post any findings that I might come across.
Sorry, I disagree.
The objects I have the timescale problems with aren’t using physics (other than collecting raycasts and clicks using colliders, but they have no rigidbodies). Further, the objects I do have which use physics (but recieve/send no raycasts) continue to recieve mouse events throughout the scene even with timescale=0.
What’s causing the problem in my case are the raycasts. Before raycasts, they collect clicks with the timescale=0. After, they ignore the clicks (or, I would guess, the mouseup/down calls aren’t sent by Unity). Again, setting timescale to even 0.01 solves the problem. Either it’s a bug, or a design flaw IMHO.
I would be delighted if anyone could offer a workaround or pinpoint the cause. I’m at a loss.
. Anyway, it does indeed appear to be a bug, in my first test I wasn’t using orthogonal projection, so the movement of the cube wasn’t large enougth to notice the problem. And you don’t even need to be at timescale 0, 0.001 is more than enougth for the problem to appear.