ID:110801
 
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
I thought this had been requested, but this was all I could find. Instead of using whatever browser the user has installed (it doesn't very practical anyway) I'd rather see BYOND come packaged with its own browser (gecko, webkit, etc.).

It would be nice to know that all BYOND clients use the same browser so that HTML and JavaScript would behave the same for all clients. Not being IE is an added bonus. I'm sure there are some users with old versions of IE. If users were guaranteed to have a more feature-rich browser, things like NEStalgia's character creation process could be handled entirely by the browser and require very little interaction with the server.

With the way things current are I don't blame people for avoiding the browser control for interface elements, but it could really help in certain situations. Aside from ease of creation for certain effects, think of how much less traffic you could generate by handling a player's drag and drop inventory completely on the client. Instead of telling the server every time you mouse over an item or click on one, you can make the browser only notify the server when you perform a significant action (drop an item, equip an item, etc.)
Doesn't BYOND already use IE for all internal browsers? It only uses player's primary browsers in certain situations, like when using link().

things like NEStalgia's character creation process could be handled entirely by the browser and require very little interaction with the server.

How? The game itself would still have to generate and process almost the entirety of the information? A browser would just be an alternate, less impressive, display method.
BYOND uses an IE control that appears to use whatever version of IE you have installed. There are big differences between IE 5 and 8.

NEStalgia's character creation causes the server to generate new icons as the player selects colors. With 50 users doing that at the same time it can (and did) bog down the server. You can use dynamic html forms to create interactive menus that are handled by the client, the only communication is the server sending the form to the client and the client submitting values to the server. You don't need to send potentially dozens of icons to the client and the client doesn't have to tell the server about every mouse event.
Forum_account wrote:
NEStalgia's character creation causes the server to generate new icons as the player selects colors.

How are you going to dynamically generate icons using only a client sided browser? And why couldn't you do it already if its possible?
Also, NEStalgia's problems were most likely due to various issues unrelated to this. They quite possibly had slow servers, that couldn't send the few kbs required to show the new icons. NEStalgia probably wasn't handling the icon generation effectively. And, regardless of how NEStalgia was handling it, dynamically generating icons fails at performance, but that's another issue.
Double also, I somehow doubt there were 50 people at a time creating characters on NEStalgia. There were never even that many on a single server at a time, and there was probably a very small % of those player counts in the actual character creation process.
Honestly, if NEStaglia's character creation process was causing such massive lag, that offloading it allowed them to merge servers and get better overall performance, then they were doing it wrong.
How are you going to dynamically generate icons using only a client sided browser? And why couldn't you do it already if its possible?

The browser can generate images to show you what your character will look like. When you submit the form it tells the server what colors you selected and the server creates your icon. The difference is that the server isn't creating icons for every preview of your character, it only creates one icon when you submit the form.

Not only can the browser be used to avoid costly communication, it can be used to provide an interface that is less affected by lag. In a "traditional" menu made with screen objects, every mouse click is sent to the server and the server updates the menu by modifying screen objects. When the server gets crowded and everything slows down, the responsiveness of the interface suffers too. The content in a browser can handle mouse events on the client and would be responsive no matter how crowded the server is.

This is currently possible, but not ideal because it would be difficult to design a form that would work for all versions of IE. Having a specific version of webkit embedded in BYOND would give developers guaranteed consistency of browser content for all users.
I think one of the main reasons this hasn't been done is because all of the attempts to do it have failed pretty badly. Plus, it'd add like 3MB to 7MB to the size of BYOND's download package, that's a turn-off to a lot of people.
I'm curious to hear how it has failed badly, it doesn't seem terribly difficult and its commonly done. I'm sure plenty of support is available.

It might have been the reason that was given, but with BYOND games that are well over 3MB I can't imagine the download size being the issue.
It is definitely an issue for those of us forced to still use dial-up. I'd personally be pretty discouraged having to download a 10MB file instead of a 3MB file. Tom has expressed his desire to keep the download package as small as possible.

There are still tons of BYOND games that are below 1MB, and those are the games people that have no options for high-speed internet play. Alienating those people (which still account for over 50% of internet users). Also, BYOND doesn't officially support any operating system below Windows XP, which comes with IE6 stock -- which is more than enough to utilize javascript properly.

IE7, IE8, and IE9 still only account for a tiny TINY market share. So you should be working your HTML/javascript around IE6 anyways.
IE7, IE8, and IE9 still only account for a tiny TINY market share. So you should be working your HTML/javascript around IE6 anyways.

It's quite the other way around. http://www.w3counter.com/globalstats.php

I'm not sure how the embedded IE control compares to the browser, but it could help performance. IE doesn't win many (any?) contests for performance or efficiency.

which is more than enough to utilize javascript properly

It's also a problem when people have javascript disabled in IE. Given its track record I don't blame them. It would be nice for BYOND to have more control over this.
Even with javascript disabled in IE it will still work with the embedded browser. The embedded browser uses the settings of the browser control and not the user's preferences. We've tested it in the past.
People have reported problems related to JavaScript not working. Either JavaScript was somehow disabled or there was an error and the error messages were suppressed (which means it inherited IE's setting to suppress error messages because I see JavaScript errors in BYOND). I've never had the problem so I can't look into it more, but the next time it comes up I'll try to get more information.
Nadrew wrote:
Even with javascript disabled in IE it will still work with the embedded browser. The embedded browser uses the settings of the browser control and not the user's preferences. We've tested it in the past.

It looks like this can cause problems: http://www.byond.com/developer/forum/?id=786523
The one time I decide to update Internet Explorer, which I never actually use, it screws up everything ;_;. Changing all the security settings hasn't proven to get rid of the walls of prompts you have to go through to get to the actual javascript, and I don't expect to force everyone to do complicated steps just to make a game work right.
IMO the focus should be on implementing the WebKit rendering engine into BYOND.

It's used by at least Apple (Safari, mobile Safari) and Google (Chromium/Chrome, Android) as opposed to Gecko which is only used by one browser. Given that it's so widespread it might be easier to find some tutorial and/or examples of how it's implemented.

Gecko also has some nasty bugs in it and tends to be slower than the Webkit engine (at least the Javascript part). I've witnessed that if a piece of Javascript code gets busy the entire DreamSeeker process freezes up which is undesirable and which could be avoided for the better part by using the fastest engine available.

In short: Please don't make me use Gecko. It's a horrible engine which has only been getting worse these past few years. As seen here Chrome has overtaken Firefox and is on its way to overtake IE. Even Safari has gained more popularity in recent months!

If there is any way that I may be able to assist in the implementation of this feature I would very much like to do so. The lack of a proper browser control (at least one that doesn't differ per client) has been a pain for years and is one of the things that prevents a cross-platform client from going through. What exactly has been the problem implementing this and is there anything I could do to help (e.x., by trying to create a simple application which implements the browser perhaps?).
JBoer wrote:
The lack of a proper browser control (at least one that doesn't differ per client) has been a pain for years and is one of the things that prevents a cross-platform client from going through.

It's not just needed for consistent cross-platform support, it's needed for consistent single platform support! Right now you can't be sure that HTML and JavaScript will work the same way for all clients.

What exactly has been the problem implementing this and is there anything I could do to help (e.x., by trying to create a simple application which implements the browser perhaps?).

There's a little more to the BYOND browser control than just putting one on a form. You'd have to make links trigger calls to Topic() and be able to invoke JavaScript functions from outside of the browser control (like DM's output() proc). If you could show the staff how simple all of that stuff is, that might help.
In response to Forum_account
Forum_account wrote:
It's not just needed for consistent cross-platform support, it's needed for consistent single platform support! Right now you can't be sure that HTML and JavaScript will work the same way for all clients.

You can't be sure that HTML and Javascript will work the same way when dealing with it outside of BYOND either, so I don't think that's valid.

The pain I'm referring to is the fact that past versions of IE have had horrible issues and IE8 is the last version that still suffers from some lingering issues. And I can't be sure if a client that connects is running IE6 or IE7 which are even more out of date.

When you have a normal website you can at least reasonably expect whoever visits it to have the latest available version of whatever browser they're using, be it IE or some other browser. But with BYOND you might end up having someone connect who doesn't use IE and therefore has chosen not to update his version due to the time it would take to do so.

IE8/9 behave in a similar manner although IE8 is substantially slower and the built-in debugger is crap. IE6/7 don't even support half of the standards and any modern website no longer supports it.

There's a little more to the BYOND browser control than just putting one on a form. You'd have to make links trigger calls to Topic() and be able to invoke JavaScript functions from outside of the browser control (like DM's output() proc).

Obviously there's more to it than putting one on a form, but I'm not inclined to showcase things that they already know, which is why I asked if there's specific things they're having issues with.
In response to JBoer
JBoer wrote:
You can't be sure that HTML and Javascript will work the same way when dealing with it outside of BYOND either, so I don't think that's valid.

Outside of BYOND is a different situation completely. For websites people have the option of using a different browser - you can test a website using different browsers and suggest that people use one of the ones you've tested. With BYOND, you're stuck with whatever it uses. If your bank's website says "You need to use IE8 or Firefox", you'll use one of them. If a BYOND game tells you to upgrade IE, you won't play that game.

Also, the cross-browser compatibility issues are the web developers' burden to deal with, there's no reason to make it the BYOND game developer's burden too.
In response to Forum_account
Forum_account wrote:
With BYOND, you're stuck with whatever it uses. If your bank's website says "You need to use IE8 or Firefox", you'll use one of them. If a BYOND game tells you to upgrade IE, you won't play that game.

Which is the point I'm trying to make. It isn't asmuch that the HTML and Javascript may be handled slightly differently, but that very old versions of IE (mainly 6/7) might still be used by some BYONDers and that people will just refuse to play a game instead of updating IE (which is what everyone should do anyway).

Also, the cross-browser compatibility issues are the web developers' burden to deal with, there's no reason to make it the BYOND game developer's burden too.

I wouldn't mind having to write something so it will work in all browsers just so long as I can be sure that IE6/7 aren't used.
iirc, Lummy hates Chrome and all webkit browsers and whatnot.
He wanted to use Opera, Firefox, or something.
In response to Super Saiyan X
Super Saiyan X wrote:
iirc, Lummy hates Chrome and all webkit browsers and whatnot.
He wanted to use Opera, Firefox, or something.

Both Opera and Firefox are below Chrome in terms of market share. I don't think it's wise to use a rendering engine that's slowly losing popularity, especially one as slow and horrible as Firefox has shown itself to be.

Then again it doesn't matter, since nothing seems to get done around here. That's one thing the development of BYOND has in common with the Firefox browser: it took 10 years before a simple issue was fixed (https://bugzilla.mozilla.org/show_bug.cgi?id=166240, and yes comment #5 is my own).
Page: 1 2