[RESOLVED] How to force 2.1 webplayer download/usage?

Ok my web app doesn’t work in 2.5, and I tried changing all the references in the html launch page to 2.1 from 2.x but it still downloads 2.5 and if 2.5 is installed it will default to using that one how can I tell the browser to keep using the older one for my app.
How do you force Unity web app to use an older version?

You can’t. What does not work? Please report a bug and attach the project folder (or just the web player).

EEEK!! So what your saying is I need to rebuild the project in 2.5 ASAP. When I do that, what happens if it does work in the 2.1 player will existing users be prompted to update the player?

I’m still trying to track down what is causing it. But bascially what used to work is I could click on and select objects in my scene, now I can’t. This is rather the entire point of the app and we are actively trying to sell this at the moment. So this is rather serious.

The way this works is I use a render texture and renderWithShader to render colour codes for the objects. I then test for those colours and lookup in a hashtable what the object is. There’s post about it in this forum, you helped me come up with the system.

Bug report with webplayer on the way.

I’ve opened and run the project in 2.5 and it seems to be something wrong with the following code not performing the same function as in 2.1. I can see in the scene view that the camera no longer follows the mouse correctly.

function Update() {
	mp = Input.mousePosition;
	var t = camera.main.ScreenToWorldPoint (Vector3 (mp.x, mp.y, camera.main.nearClipPlane));
	transform.LookAt(t);

}

function OnPreCull() {
	oP = camera.main.projectionMatrix;
	
	if (globals.showToothSelector) {
		shiftedProjection ();	
	}
	else {
		rP = oP;
	}
	
	camera.projectionMatrix =  cursorSelectionMatrix( mp.x, mp.y, 16 ) * rP;
}

function normalProjection () {
	camera.ResetProjectionMatrix();
}

function shiftedProjection () {
	var w : float = Screen.width;
	var h : float = Screen.height;
	
	rP = oP;
	rP[0,2] = 0;
	rP[0,0] = rP[1,1] * h/w;
}

static function cursorSelectionMatrix(x : float, y : float, s : float) : Matrix4x4
{
  
  	var sx = Screen.width / s;
	var sy = Screen.height / s;

    var m : Matrix4x4;
    m[0,0] = sx;  m[0,1] = 0;  m[0,2] = 0;  m[0,3] = 0;
    m[1,0] = 0;  m[1,1] = sy;  m[1,2] = 0;  m[1,3] = 0;
    m[2,0] = 0;  m[2,1] = 0;  m[2,2] = 1;  m[2,3] = 0;
    m[3,0] = 0;  m[3,1] = 0;  m[3,2] = 0;  m[3,3] = 1;
    return m;
}

Maybe in future when there’s an update existing customers should get the chance to test their apps before its all released…

When I trace the output from this line

var t = camera.main.ScreenToWorldPoint (Vector3 (mp.x, mp.y, camera.main.nearClipPlane));

In 2.1 it gives me values like (0.3, 18, -11)
but in 2.5 it gives me (0.3, 0.3, -11)

Looks to me like ScreenToWorldPoint has become ScreenToObjectPoint, or its just plain broke.

Any ideas how to fix this?

I tried the following code taken from the help

function OnDrawGizmosSelected () {
    var p = camera.ScreenToWorldPoint (Vector3 ( 100 , 100, camera.nearClipPlane ));
    Gizmos.color = Color.yellow;
    Gizmos.DrawSphere (p, 0.1);
}

This works in 2.1 but throws the error below in 2.5

Please file a bug and attach the project folder that shows the issue.

I have filed a bug including the web player. I’ll also send the project folder.

In the meantime if anyone can think of another way to project a point from screen space to world space that would be great. I can get close but nothing yet transforms precisely to the correct spot.

Resolved. There was another MainCamera in a different scene that was loaded first. I guess 2.5 treats this differently from 2.1.

Although this is now resolved it does highlight the fact that any apps built in 2.1 have to be completely re-tested to make sure they still work when an update is released, surely we need a way to enforce which version is getting used. I have no idea what other issues might be lurking in things that have been changed for 2.5

Can you post the case number so we can find it quickly.

Generally before we ship we go through an insanely large list of published web games to avoid regressions. The goal is to always stay 100% backwards compatible. Your game was apparently not on that list. We will add a website where users can post links to their published content, so that we can make sure it is tested prior to release.

We are also planning to build a fully automated regression testing framework that notifies us of any regressions in the web player immediately during development.

Case 167251.

That sounds like a most excellent idea.

How would you stay 100% backwards compatible in this case? It seems like you have fix a bug that then highlighted a bug in my code, so how can you account for that?

As an example:
The game Monsters Aliens for Dreamworks, rendered a plane using Graphics.DrawMesh from inside OnGUI. The correct way of using on GUI would be to call Graphics.DrawMesh only when if (Event.current.type == EventType.repaint).

We did some optimizations and changes that caused this bug in the customers code which previously had no side effects, to now have side effects and display the geometry in a different location.

The content shipped 3 days before we shipped 2.5, so we did a last minute workaround. Where we kept the optimizations in the editor but disabled them in the web player.

Another solution we have in our arsenal is checking the version with which the content was published and adding specific workarounds based on version of Unity that was used to publish the game.

In any case, better and earlier visibility into problems also lets us go with the third solution, working with content developers early on if their published content exposes a bug and have either them fix it prior to release or if thats not feasable work around it.

This kind of work obviously has a strain on the source base where you have specific content workarounds, which makes it more messy. So lastly we have the ability to have multiple versions of the player in our web plugin. This allows us for example when we ship version 5 of Unity or something like that, to say:
All versions 2, 3 and 4 will use the Unity 4 web player runtime and only Unity 5.0 content will use Unity version 5.0. This still goes through the same autoupdate mechanism so the plugin install base will still be shared and no new plugin needs to be installed.

And of course once we do such a new version, we can just go through the source base and remove all those nasty content specific workarounds and set things right.

Thankyou for the detailed explaination, that is both informative and interesting.

This just in: UT has announced Unity versions 3.0, 4.0, and 5.0. All three are in beta and expected to be released any minute.