In response to MisterPerson
You can find the code for the default controls in your BYOND install under web.
In response to MisterPerson
I guess for developer purposes I could see that. That should probably be a feature request.
What causes a game to return "This game is currently not available to play" in the webclient?

I'm hosting a test game on 1274 (the latest beta verison) and while people can connect via dreamseeker, this error 'not available to play' pops on the webclient, even though 'allow webclient' is checked off in daemon.

what can cause this?
In response to Mista-mage123
I've noticed this to be a fault with the webclient over time. I typically have to either reboot or shutdown/startup the game again just to fix this. An explanation that I have seen someone else give before (and have tested to verify) is when someone reconnects repeatedly multiple times. While it doesn't happen everytime, it's in the realm of possibilities. Your fix is to reset the game. To avoid it? I don't know. I haven't experimented that much. Lummox JR can probably give you more insight on the matter.
"Your fix is to reset the game"

That's the thing. I haven't once been able to get this game to host on the webclient. Tried rebooting the game/daemon, etc.

While my other games work fine, this one outright refuses to launch on the webclient. It might be a glitch somewhere but sadly I have no idea on what could cause it

EDIT: Tried unchecking the map and skin files and tried hosting, once again, works in dream seeker but refuses to run in webclient. "This game is not available to play". So weird...
There may be a bug in play causing this issue, that will be fixed in 507.1275. If that's not it, I'd probably have to catch the issue in action to know more.
In response to Lummox JR
Lummox JR wrote:
There may be a bug in play causing this issue, that will be fixed in 507.1275. If that's not it, I'd probably have to catch the issue in action to know more.

I've been meaning to get around doing some basic trial and error tests for you like I promised. With all this school work that I just love procrastinating to do... I keep losing time to do the tests. I'll try for this Saturday. I say this in-case anyone else wants to do some testing as well to help out.

Free servers are given for testing purposes if anyone wants to do so.
I've got a game hosted right now that I've never been able to connect to via webclient. I'm getting a cross-site scripting exception in the JavaScript console.

BYOND 507.1263, Windows 7 64-bit. Port is forwarded on router.

http://www.byond.com/play/xxx:9000

XMLHttpRequest cannot load http://xxx:9000/query. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.byond.com' is therefore not allowed access. The response had HTTP status code 500.


Edit: This happens when hosted in DreamDaemon or DreamSeeker.
In response to Polatrite
Have you tried updating to 507.1274/1273? http://byond.com/download It may seem like a useless thing to do. But, it could somehow fix your problem.
That did the trick! Didn't realize there was a newer beta version, thanks.
Is it possible to disable the web client box on the hub? My game uses a lot of skin based controls and isn't really compatible with it but new players try to use it still.
In response to IceFire2050

Click that. I don't think there's currently a way to globally disallow the webclient, but on a per-server basis, that's how it's done. You could, however, check client.connection in world.IsBanned() and deny access to webclient-users. Maybe.
okay this has been irking me for a while

do click events not work in the webclient or something?

Specifically, the SD_ALERT library.
http://www.byond.com/developer/Shadowdarke/sd_Alert

it has a function that is supposed to trigger Topic() of the datum

"function c(x) {document.location.href='BYOND://?src=\ref[src];'+x;}"}"

however, when i click the links in the menu, nothing happens in the webclient. i can't figure out how to fix it. im not even certain Topic() is being called at all here in the webclient, but it works just fine in dream seeker.

any help would be appreciated.

On a side note...

Kaiochao wrote:
I don't think there's currently a way to globally disallow the webclient

There is, if(src.client.connection=="web") del src

;p

In response to Mista-mage123
What's most likely is that sd_Alert() is not being handled properly by the JavaScript shim. Specifically, we have a fixjs() function that should adapt any changes to window.location or document.location (including the .href form) to call byond.go() instead. I'd love to simply intercept the window.location change, but browser security settings make this impossible.

However, I fixed some issues with the shim a while back and this specific issue looks really familiar. I'm particularly sure I handled that case. Are you using the latest beta?

[edit]
The shim is handling this correctly in my quick console tests, confirming what I saw in the webclient when I worked on this.
In response to Mista-mage123
I did find an error in the shim after all, per id:1813273. It's possible that what I tested was not using sd_Alert but was simply the same function presented in a different way (in Darke Dungeon, IIRC). That would explain a lot. Please retest in 507.1279.
In response to Mista-mage123
I meant a way to keep anyone from generating a webclient link. Also, to deny a client before resources start downloading, you should be using world.IsBanned().
In response to Lummox JR
thanks lummox, the 1279 fixed the problem and it works properly now.
Is there a way to update the default webclient byond_browser module without refreshing the entire control? Possibly using ajax?
In response to Evi of au
Evi of au wrote:
Is there a way to update the default webclient byond_browser module without refreshing the entire control? Possibly using ajax?

How do you mean, exactly? If you mean just sending data to a browser window, you could output to JavaScript using something like "mybrowser:scriptname" in output().
I'm running into a plethora of problems with the weblicent, mostly having to do with simply some things can be clicked, and some cannot. That have through the analysis of some programmers I've spoken too, is the webclient's own fault.
Page: 1 2 3 4 5 6