Maybe I am approaching this problem from the wrong angle then, Unity can (I thought) only talk to script directly on the page that the control exists on, not server side script.
I have not been successful yet in placing a Unity control on an ASPX page and it have access to the C# functions associated with that page.
I do not want to trigger a page postback and cause a page refresh. Everything that loads with the page needs to be focused and available to the Unity player.
I have a shared class on the server which contains a hashtable of my players and there data, the other thing I have is a local set of variables that contains all player specific data which is populated upon successful player login.
These are all server side events. The user only sees the resulting fields populated by this information. I guess this thing needs to be rounded back (since I was going stickly off the javascript interaction), to wether or not Unity web player can communicate directly with serverside methods.
In a web based situation, all I am doing is passing values generated by Unity back to the server and I don’t want to leave the current page.
The only thing Unity seems to lack, is an onload event for the player that allows you to input an array list of WSDL pages.
These pages would then expose methods to Unity for the game, making Unity a SOAP client.
That would bypass the need for javascript injection.
On top of that, I want Unity to be able to modify html fields on the page, like labels for instance, which you are doing in script, a Unity call of something like:
page.label1.text=“this value”
Page = current page the player is on, label1 is a label on the page, and text is its value.
Maybe I have way overcomplicated this issue. Its an issue for me right now. I need the client to talk to the server and prefferably through soap natively.