Hi ronin

There is http tunnelling - just not tooooootally done yet. But almost

Gimme a few more days of testing, and I will also ship you a dll for testing in your end.

Best
Thomas

Great - will get that in locally and test later today.

Could you please run a quick test on the http fallback too - see if it works fully in your end?!?!

Its not fast, but it works for me.

Been looking a bit more at the reconnect issue, and have a hunch that its a socket problem. Looking at the SFS console, you actually never see a real socket disconnection happen. Using netstat also shows the socket in TIME_WAIT. I've now tried to play around with the Disconnect method a bit, and not...

Should be possible, but I have no personal experience with it. Someone on this part of the forum posted some code not to long ago.

Basicly have an endless loop if I recall.

Source code drop is available here: http://www.fullcontrol.dk/downloads/SmartFoxClient-081130.zip There is also a build debug dll in bin/debug Please give this a try on your projects to see if the HTTP failover works for everyone. It should also NOT crash on exiting the player. As detailed above, it...

OK - I *think* I got http failover working now. Will during today run a few local tests here and then put up a snapshot build+sources for testing. Especially ppl with Windows machines should give this is go. Had to code my own http client over raw sockets + make my own threaded pull mechanism. Using...

OK - time to give things a "name". There is a "reconnect issue". That is when in the webplayer you close a tab with a Unity player, open again and try to establish the connection again. Then there is a "crash on close". After having run http communication, then browser ...

HTTP / bluebox failover seems to work now for at least standalone games. Replace the HttpConnection Send and HttpSend + receive methods with this: public void Send(string message) { if (connected || (!connected && message == HANDSHAKE) || (!connected && m...

If I recall correctly - Marco please correct me if I am wrong - then variable updates on the user that sent them are not returned back to him. You are supposed to update those yourself locally on sending them. You can test it by enabling debug and see the raw messages send by the server in the log. ...

Oh - good question then on how to do that with SFS. The backend connection is a TCP socket connection that you cannot "delegate" between Flash and Unity. You would most likely have to re-connect and re-login (transparently) inside your game. Depends naturally on what you are doing. If your...

The way the API works, it first tries to make a socket connection to the server on port (whatever you entered - usually 9339). If that fails, then it will try the same host but on port 8080. If that also fails, then you would get that error (I think). So make sure that you actually have a SFS server...

Just got to make sure - you did remove your hostname and port, so that the error message included the correct ip+port - right?

As Marco said, the http tunneling is not fully running yet in beta 2. Will get cracking on that really soon.

Personally I just spend less than 1 day to port an existing Unity web game to an iPhone version. Main part of the time was spend reducing polygons, texture sizes, stereo sound to mono and streamlining lights. Very little code changes involved. Cant wait to get cracking on iPhone games leveraging SFS...

Unity keeps its javascript/C#/boo scripting capabilities and compiles it down to something running on the iPhone.

So porting an existing Unity project to iPhone is purely a matter of reworking art + performance optimizing. The code and everything else stays the same. Ultra efficient.

Hmmm - havent seen that one here. But good with a fix! I will very soon start up for the (final?) beta and get the last issues nailed. The main culprit seems to be failover to http - that still uses regular async instead of threads, and thus will crash Firefox and similar on shutdown. Please hammer ...