Urgent explanation needed please - the time is different

I mean, the problem i posted in the post about the mouse movement.

I detected that i'm working detecting the Input.GetAxis("Mouse X") but when i test this in the editor it works fine, but to get a behavior like in the editor in the build i need to multiply this value by 10 (more or less)

Also i'm using a Mathf.SmoothDamp to do some acceleration/deceleration in the mouse movement, and i need to multiply by 10 too the variable smoothTime (i'm using this variable like in the explanation of Mathf.SmoothDamp)

i don't understand this difference.

Please help

 

Ok, sorry...i think the problem is the same for both posts.

The value of the Input.GetAxis("Mouse X") is different inside the editor and in the build.

Why is that?

Thanks.

 

You can see what i'm saying, or at least test it.

1.- Create a new scene

2.- Apply this script to the camera (it shows the value of the Mouse X in the GUI

Code (csharp):

1. var mus_force = Input.GetAxis("Mouse X").ToString();
2.  
3.  
4. function Update() {
5.     mus_force = Input.GetAxis("Mouse X").ToString();
6. }
7.  
8. function OnGUI () {
9.    
10.     GUI.TextArea (Rect (10, 10, 300, 30), mus_force );
11.    
12. }
13.  

3.- See the values flowing.

4.- Do a build

5.- Execute build and see the values...are completly different!!!

Why is that????

EDIT :

I tested with a web player build...and the values seem to be ok, so it must be something in the windows build, i need to export my demo as soon as possible, help please.

 

No one can help me?

Please...unity team...help, i need to send the demo as soon as possible to a client.

 

Thanks for being with my problem, i'm a bit desperate

 

I noticed that the Time.deltaTime is a lot different in the windows build and in the editor, i attach a picture wiht an screenshot.

 

Oh my god

I'm using Windows XP X64, but i had no problems until now ...mmm there is a test that i didn't tried...create a completly new project, may be the project is corrupt

I'm gonna try.

 

Creating new project doesn¡t solve the problem.
What can i do?
I attach the test project i just did, the same problem with Time.deltaTime
Also here is the link to the build of this project, so you can see the bug, i'll upload to my server because it's a 4megs file.

http://www.bone-studio.com/clientes/juan/build_bug.zip

Thanks

 

Time.deltaTime is the time elapsed between 2 frames. In the editor, the engine has a lot more stuff to do (debug, multiple scene views, ..) so I guess that's why Time.deltaTime is bigger... I'm no expert though.

 

Tried on another computer with the trial.

The Time.deltaTime is still bad.

camille:

If you try the project you'll see that the values of delta time inside the editor and inside the build must be at least similar, not 0.01000(editor) and 0.00010(build) with nothing in the screen, and when i mean nothing is nothing at all, only the GUI to see the delta time.
Also in the web player the delta time is similar to the delta time in the editor, so something is bad with the windows build

But thanks for the answer.

 

Well, I kind of believe the build is optimized and the editor quite slow, but I don't know for sure.

I believe the framerate in the webplayer is limited...

Putting that aside, I can't see how Time.deltaTime could be "bad". The higher the framerate, the lower Time.deltaTime is. And the framerate is definitly higher on builds than in the editor / the webplayer...

What I am trying to say is that if the framerate is bigger, then the mouse will have moved less per frame, thus the values of the axis will be smaller. Sorry if that's not very clear, it's quite hard for me to write in english

hope that helps

 

Well...at first, then why Joe Robins cannot reproduce the problem?

BUT...if i think in this maybe you are right, so is not a unity bug is more or less a bug in my scripts and my understanding of unity time, so how can i fix that?, because i cannot trust the movement o fhte camera or an object to a value that change a lot in time...mmm

How do you think this could be fixed?

Thanks for the new point of view, i tell you that i want to be this a lot more than a problem with unity, i can fix my head but not unity

EDIT 1:

Also i use this script to see the values of the mouse input:

Code (csharp):

1.  
2.  
3. var speed = 10;
4.  
5. var mus_force = Input.GetAxis("Mouse X").ToString();
6.  
7.  
8. function Update() {
9.     mus_force += (Input.GetAxis("Mouse X") * speed);
10.     mus_force = mus_force.ToString();
11. }
12.  
13. function OnGUI () {
14.    
15.     GUI.TextArea (Rect (10, 10, 300, 30), mus_force );
16.    
17. }
18.  

and the values are a lot different inside editr/web player nad build (inside the first two are fine, but in the second is bad, like my sight of time delta.

 

Maybe you could use deltaTime as shown in the first example of this page :

http://unity3d.com/support/documentation/ScriptReference/Input.GetAxis.html

Code (csharp):

1. var translation = Input.GetAxis ("Vertical") * speed;
2. var rotation = Input.GetAxis ("Horizontal") * rotationSpeed;
3.  
4. // Make it move 10 meters per second instead of 10 meters per frame...
5. translation *= Time.deltaTime;
6. rotation *= Time.deltaTime;

 

There was no luck, the behavior of the mouse is different even aplying this solution, in the editor it moves like i want it to move and in the build don't

 

Ok, here is a new thought.

When i use the mouse in the editor and monitor the value of Input.GetAxis("Mouse X")(for example) the values are sometimes highee than 1, maybe even 5 or 6, that's ok and the behavior of the mouse is fine.
But when i do a build suddenly the values are always below 1 and the mouse acts slowly.

I cannot understand

(i'm speaking only about Input.GetAxis("Mouse X") values, not distances or nothing to do with Time.teimDelta.

Cheers.

EDIT 1 : Of course in the web player there is no such problem.

 

Time.deltaTime is supposed to be different...it doesn't matter what the values are. The point is that the higher the framerate, the smaller the values. In this case, it should be irrelevant; don't multiply mouse input by Time.deltaTime, since mouse input is already framerate-independent. If you multiply mouse input by Time.deltaTime, then it becomes framerate-dependent, and you get different behavior in the editor compared to the build.

--Eric

 

Eric:

That's my point

i'm not multiplying the mouse input by delta...i'm not operating with it at all, i'm only monitoring it, and the values are a lot different.

 

Like with Time.deltaTime, the mouse input values are supposed to be different depending on the framerate. If your code is correct, it's not an issue. It's hard to say without seeing what you're doing, but one thing that could cause problems is using mouse input in FixedUpdate (which should never be used for anything except physics code).

--Eric

 

It seams that the problem has something to do with the framerate, i limited the framerate of the build to 50fps and then the values of the mouse are correct, also de movement, it seems that the framerate in my buid was really high, so maybe what i'm to tell is a silly thing but it was not working fine.

Is it possible?

limiting the framerate is a workaround, but i'm not happy with this solution, i don't understand why exist this problem if i'm not working with Time.deltaTime.

Comments?

EDIT 1:

Eric:

I didn't see your last post, it seems that the framerate was guilty, so i did what i wrote up

 

I've never had to limit the framerate to get the same mouse behavior in the editor as a build. It's not really possible to say what the problem is without seeing your code though.

--Eric

 

Get the ticks of the machine, as Erich and the others have pointed out, do not use internal timer of delta of either the mouse or frame values, use a constant calculation against real time.

Every program you write has a start counter, set and reset a global variable (or local to the object) based on ticks elapsed. As with life, time is a constant, there are so many ticks in a second, so many in a minute and so many in an hour. This is a constant.

So at the begining of the frame you need to get the current tick count, multiple that value by what ever, then use that value against your mouse speed or what ever you are trying to change, you have to use global variables for this because each frame will need to have a counter that is tested against ticks passed.

Hope this helps or makes sense, I use this type of feature for a tank simulator for calculating braking averages against tonage and distance.

 

it's really interesting.

Can you post some example code?

I'm a bit new to unity scripting

Cheers.