ID:1677619
 
While bugs should still be reported to the Beta Bugs (or Bug Reports), this thread is to track down games that work and do not work with the Webclient.

This thread is open to all for checking the status of any published game and actually report any abnormalities that currently exist. I will update the list as more are contributed. Any moderators are also free to modify this post in the event there are more games to report status.

Game List:
Castle by Rushnut (Rushnut Version): http://www.byond.com/games/Rushnut/Castle - Map control is functional. It appears that the child window that is supposed to show up to the right does not appear.

Chatters by Xooxer: http://www.byond.com/games/Xooxer/Chatters - Say and some verbs work, but output is non-functional. UI is also messed up.

Classic Tron BYOND Edition by Bandock (Latest Version): http://www.byond.com/games/Bandock/ClassicTronBYONDEdition - Portions of the UI are non-functional due to no grid support at present. Parts of the map are cutoff due to view size appearing smaller than it should be (used 64x48 due to the icon size of 1x1).

Darke Dungeon by Shadowdarke: http://www.byond.com/games/Shadowdarke/DarkeDungeon - Non-functional due to what is stated in Lummox JR's post: http://www.byond.com/forum/?post=1677619#comment11992881

DawnCaster Infestation by Ter13: http://www.byond.com/games/Ter13/DawnCasterInfestation - First person view has shrunk and the game map is exposed.

Disky Challenge by Bandock: http://www.byond.com/games/Bandock/DiskyChallenge - Fully functional (excluding MIDI which is normal)

Geekdash by Acebloke: http://www.byond.com/games/Acebloke/Geekdash - Fully functional

Murder Mansion by SuperSaiyanGokuX: http://www.byond.com/games/SuperSaiyanGokuX/MurderMansion - Some issues with the UI and no output on the left and right sides at all. Tabs are currently non-functional under the webclient.

OmegaMall by Stad: http://www.byond.com/games/Stad/OmegaMall - Fully functional

Paint by XxDohxX: http://www.byond.com/games/XxDohxX/Paint - Functional, though part of the bottom is cutoff.

Roleplay Hub by Crazah: http://www.byond.com/games/Crazah/RoleplayHub - Password field does not hide the password in the webclient, but does in Dream Seeker. Backspace seems to not work properly either. Also, the lobby is currently non-functional on the webclient.

RPG Sweeper by Forum_account: http://www.byond.com/games/Forum_account/RPGSweeper - Fully functional

SkyDrop Delivery by Bandock: http://www.byond.com/games/Bandock/SkyDropDelivery - Fully functional

Space Station 13 by Exadv1: http://www.byond.com/games/Exadv1/SpaceStation13 - Problems reported by various posters in reference to the webclient.

Text City Simulator by Bandock: http://www.byond.com/games/Bandock/TextCitySimulator - Fully functional though with an unneeded map control.

Wargames by Acebloke: http://www.byond.com/games/Acebloke/Wargames - Functional with some UI issues. Mainly near the bottom and some of the buttons scrunched up.
I've been trying to work around with http://www.byond.com/games/Crazah/RoleplayHub to get it to work with the web client. A large amount of the interface doesn't seem to want to work, hopefully that gives some good material.
Did a check and though I have not registered yet, I can definitely see a flaw with the password when that field is selected and typed through the webclient exposing the password.

While I haven't fully tested it myself yet, this is definitely something important that could lead to a fix Crazah.
RPG Sweeper by Forum_account: http://www.byond.com/games/Forum_account/RPGSweeper - Works perfectly; I just completed it. It looks a bit nicer when you winset the map's zoom to 1, since the size is just below the webclient's size.
Very nice Kaiochao, I can see that Forum_account's RPG Sweeper game is fully functional as you stated. No UI problems from what I can see.
Omega Mall by Stad is fully functional (provided you allow midi files)

Wargames - I wasn't able to get past the Name screen when I attempted it.
Darke Dungeon is not functional due to the nature of its browser interface; it's setting document.location.href=[byond url], and that's not something we can trap. (Browsers have very firm security rules about overriding the window.location assign and replace functions.) Unless I can come up with a way of rewriting the scripts at runtime to cover the most common cases (not something I much want to do) I'm not sure it'll be compatible.
Bandock wrote:
Castle by Rushnut (Rushnut Version): http://www.byond.com/games/Rushnut/Castle - Map control is functional, but several other controls do not show up (probably due to intended lack of support for such controls).

Do you know which controls in particular aren't showing? All we don't support right now are grid, tab, and bar, and frankly tab should be low-hanging fruit now after the recent info control change.

Chatters by Xooxer: http://www.byond.com/games/Xooxer/Chatters - Say and some verbs work, but output is non-functional. UI is also messed up.

Chatters does have a ridiculously complex UI. The overabundance of popup windows could be a problem but I'm not sure. It'd help to have some more specific feedback on where this breaks down.

Classic Tron BYOND Edition by Bandock (Latest Version): http://www.byond.com/games/Bandock/ClassicTronBYONDEdition - Portions of the UI are non-functional due to no grid support at present. Part of the map is also glitched under the webclient.

Can you be more specific about the map glitch? I'm curious about that.

Roleplay Hub by Crazah: http://www.byond.com/games/Crazah/RoleplayHub - Password field does not hide the password in the webclient, but does in Dream Seeker. Backspace seems to not work properly either. Also, the lobby is currently non-functional on the webclient.

This may also relate to input not currently supporting non-command formats. (The password param isn't supported yet either.) That's something I could work on.

Text City Simulator by Bandock: http://www.byond.com/games/Bandock/TextCitySimulator - Fully functional though with an unneeded map control.

Probably all I need to do is make sure a "blank" map message handles the on-show and on-hide code for the map control properly. Right now all I have is that any map message triggers on-show, which I did for SS13's sake.
Ah, alright. For Classic Tron BYOND Edition's sake, I got a closer look and all it looks like is wrong is the map view size. It's probably because the view size was set to 64x48 (which is probably unsupported). Here is the download link that is supposed to work, but seems to result in installation failed messages: https://dl.dropboxusercontent.com/u/24250760/BYOND/ Classic%20Tron%20BYOND%20Edition.zip (The version on my BYOND membership is the older version I kept around)

For Castle by Rushnut, I have a feeling it has something to do with the child window not showing up at all. Updated the status to confirm a missing child window.
The webclient seems to perform very very poorly when icons with a large number of icon_states are being used.

Starhawks is unplayable through the webclient (it uses a number of icons that have 544 icon states).

My lighting system, d4y_dfl, has a very low framerate in the webclient as well. My lighting system deals with a single icon that has 6561 icon_states.

I should probably file a bug report for these.
In response to D4RK3 54B3R
Yeah, a bug report would probably be ideal.

There's a line we walk here because the webclient is basically doing all the icon lookups, and has to walk a tree to find the right icon, then keep walking to be sure it has the right state/movement. Before release I made a major improvement to this tree walk so it would avoid re-walking the same nodes more than it had to, but with 6500 states in play that's still a lot of walking. Maybe there's a way I can cache this, or store some master info on states, to speed up the process.
In response to Bandock
Bandock wrote:
Ah, alright. For Classic Tron BYOND Edition's sake, I got a closer look and all it looks like is wrong is the map view size. It's probably because the view size was set to 64x48 (which is probably unsupported). Here is the download link that is supposed to work, but seems to result in installation failed messages: https://dl.dropboxusercontent.com/u/24250760/BYOND/ Classic%20Tron%20BYOND%20Edition.zip (The version on my BYOND membership is the older version I kept around)

I'll take a look. We do support 64x48 but maybe something is wrong in the code.

[edit]
Oh shoot, I misread that. We support that icon size. For the view size that's way huge. I'll see what I can figure out on that, although there's a limit to how far it makes sense to support such things.

For Castle by Rushnut, I have a feeling it has something to do with the child window not showing up at all. Updated the status to confirm a missing child window.

Do you mean a child control, or a popup window? A child control ought to appear; an independent window will at most try to use popup(), and there may be cases where that isn't working quite right. We don't support movable sub-windows at this time.
In response to Lummox JR
Lummox JR wrote:
Bandock wrote:
Ah, alright. For Classic Tron BYOND Edition's sake, I got a closer look and all it looks like is wrong is the map view size. It's probably because the view size was set to 64x48 (which is probably unsupported). Here is the download link that is supposed to work, but seems to result in installation failed messages: https://dl.dropboxusercontent.com/u/24250760/BYOND/ Classic%20Tron%20BYOND%20Edition.zip (The version on my BYOND membership is the older version I kept around)

I'll take a look. We do support 64x48 but maybe something is wrong in the code.

[edit]
Oh shoot, I misread that. We support that icon size. For the view size that's way huge. I'll see what I can figure out on that, although there's a limit to how far it makes sense to support such things.

For Castle by Rushnut, I have a feeling it has something to do with the child window not showing up at all. Updated the status to confirm a missing child window.

Do you mean a child control, or a popup window? A child control ought to appear; an independent window will at most try to use popup(), and there may be cases where that isn't working quite right. We don't support movable sub-windows at this time.


Child control is what I meant.

Also, I used that view size since I used the icon size of 1x1 (at the time, it seemed like a feasible solution). However, I have been getting reports it was rather laggy when hosted sometimes. I might even bring back the old code or start fresh again.
In response to Lummox JR
Lummox JR wrote:
Yeah, a bug report would probably be ideal.

There's a line we walk here because the webclient is basically doing all the icon lookups, and has to walk a tree to find the right icon, then keep walking to be sure it has the right state/movement. Before release I made a major improvement to this tree walk so it would avoid re-walking the same nodes more than it had to, but with 6500 states in play that's still a lot of walking. Maybe there's a way I can cache this, or store some master info on states, to speed up the process.

I'm having a bit of difficulty in reproducing the problem.

When I reduce the number of icon_states in my lighting system to 625, the performance improvement on the webclient is almost negligible. But when I run other developers' lighting systems in the webclient (since that's the first thing that comes to mind with a huge number of icon states), none of them exhibit the same performance problems that I've encountered. Forum_account's Dynamic Lighting uses 625 icon_states. FIREKing's Light Speed uses 4096 icon_states. Neither of them are exhibiting the performance issues that I am encountering.

I have the suspicion that it may have to do with my using /area for displaying lighting and their using /obj for displaying lighting...

The problem with Starhawks must be unrelated.
In response to D4RK3 54B3R
Aye, /area is fast for lighting in DS, though I'm not sure the same conditions apply on the webclient. Still, I would tend to think on the webclient that using /area and /obj would be just about equivalent.
SS13 is filtering connections to "seeker" in the current code base. Removing that appears that the game runs and plays - and nothing bad really in the UI - though I've not tested much beyond that.
In response to Pirion
Pirion wrote:
SS13 is filtering connections to "seeker" in the current code base. Removing that appears that the game runs and plays - and nothing bad really in the UI - though I've not tested much beyond that.

Yep, that's entirely on the authors to change. I have no idea why anyone would have added code like that in the first place, given that the connection var wasn't really useful for that purpose until a thin client came along anyway--and once it did it would prevent access. I had to make some changes to the source I had to allow guest logins (it had an outright bug) when I was testing, and also had to remove that seeker restriction.
It may have something to do with world.Export() calls appearing as valid connections?
The connection check SS13 does is at login, so it wouldn't impact world connections. It seems to be there as a just-in-case thing, but unless the goal was to keep telnet users out I don't see the point of it.

Though I haven't checked to see if client/Command() is used in the code. If it is, telnet users could connect without something keeping them out. In that case I'd just change the check to keep telnet users specifically out instead of only letting DS users in.
Updated the list to include Space Station 13 as one of the games affected by problems.
Page: 1 2