ID:133202
 
Would it be possible to add some sort of pop-up warning that alerts people who aren't running in 32-bit Color mode that BYOND may not run properly in all situations? I remember a program I had several years ago that wouldn't even run without 32-bit colors on, so it should be possible.
Seems like there have been a lot of bug reports lately that have been due to this.

http://www.byond.com/developer/forum/?id=682530
http://www.byond.com/developer/forum/?id=685510
http://www.byond.com/developer/forum/?id=684879
Seconded. It's too nonstandard for a random 2D application to require working in 32-bit colors, so it should definitely at least bring up a warning and have that known.
This seems like the wrong feature request; what we need here is the ability to *see* the color depth of the client.
In response to Alathon
That'd actually be a separate request, since that still kind of lacks the point of the program alerting the player beforehand to switch to 32 bits if possible because not doing so could have adverse effects. Being able to tell the color bits in-game would be considerably less useful then, say, the resolution (cough) itself, even though it might be possible to rearrange some of the game's interface functionality without having the player losing functionality.
In response to Alathon
Alathon wrote:
This seems like the wrong feature request; what we need here is the ability to *see* the color depth of the client.

What would that accomplish? Giving you the option to output the warning instead of having BYOND do it itself?
If BYOND can't display certain things without 32 bit colors; there's not much you'd be able to do about it, even if you knew what depth your users were running.
In response to Falacy
What Alathon has in mind could be, say; if you know a player's running in < 32-bits, instead of (unintendedly) outputting a black box to them, don't output anything. That's a little better, but still not useful and frankly is more work for the programmer instead of just having the program tell the player to switch to 32-bits before he joins the game. <.< I don't think there could be a reason any currently-still-in-existence computer to not be able to do that, or something.
In response to Kaioken
Kaioken wrote:
What Alathon has in mind could be, say; if you know a player's running in < 32-bits, instead of (unintendedly) outputting a black box to them, don't output anything. That's a little better, but still not useful and frankly is more work for the programmer instead of just having the program tell the player to switch to 32-bits before he joins the game. <.<i don't think there could be a reason any currently-still-in-existence computer to not be able to do that, or something.
<br/> Thats not what I had in mind at all.

The request is to show a popup when color depth is under 32 bit. But what if I don't want that to happen? What if I want to immediately boot the player? Or not pop anything up at all? Or design the popup using my own custom layout?

If you can check the color depth, you can do the popup yourself. This whole mantra of making BYOND take care of things you're perfectly capable of with some exposed information (In a far better fashion) is a step in the wrong direction.
In response to Alathon
Alathon wrote:
If you can check the color depth, you can do the popup yourself. This whole mantra of making BYOND take care of things you're perfectly capable of with some exposed information (In a far better fashion) is a step in the wrong direction.

What reason would there be for each game to have its own system for handling a message/pop up, which is providing information about a global BYOND feature/bug?
The message shouldn't even come up during games, it should come up when the pager is launched.

In certain/most matters, it is of course better to handle things yourself if and when possible. However, this isn't one of them.

You've been ranting since the IsBanned() topic. IsBanned() kills players before anything happens (client/mob creation, resource downloads, etc), sure you COULD use client/New(), buts its less efficient.
My main concern was the resource downloads. Are you even sure client/New() is run before resource downloading is complete?
In response to Alathon
Every separate game making its own function of alerting this is pretty silly. Some game owners may not even be aware of this technicality to begin with, and naturally since this is pretty much a problem in BYOND, it makes sense to have BYOND alert to it. That way if it's somehow fixed later, you won't have a bunch of games stupidly warning players against artifacts which have been fixed, and also the player will get a warning without actually joining a game, maybe when starting the pager and when starting to connect to a game, and he'll be able to turn it off or change when it's displayed through one global setting in the pager preferences.
As for something like giving the programmer the ability to boot a player using a given number of bits, that's frankly rather silly and I don't see a whole lot you could do with this number. If it's given it should just be part of the resolution in case that is easily accessible. You might as well add a function to check a player's default browser or maybe e-mail program so you can ban him if you don't like it, or add the gender as an argument in world/IsBanned(). :P
In response to Falacy
Falacy wrote:
What reason would there be for each game to have its own system for handling a message/pop up, which is providing information about a global BYOND feature/bug?

Uh, the same reason for games having their own system of displaying a GUI - Or being able to skin the layout of the game.

I don't want to be forced to align myself with some generic automatic warning that I can't control. I want control over the playing experience, all the way from attempting to launch the game to closing it down. What you're suggesting is taking more of that control away. Its a bad trend.

All you need is something like client.color_depth; then you can do whatever you want with the player if the color depth doesn't match the 32bit color depth you want.

Kaioken wrote:
As for something like giving the programmer the ability to boot a player using a given number of bits, that's frankly rather silly and I don't see a whole lot you could do with this number.

How about.. Booting them if their color depth doesn't match, or asking them to change their color depth? Or alerting them that if they stay in 16-bit or 8-bit color depth, they won't be getting the full experience playing the game.

Oh look dolly, options! Possibilities! Not being restrained to some generic message which won't fit the scheme of an umpteen amount of games if they even bother to skin their interface a wee bit.

Kaioken wrote:
If it's given it should just be part of the resolution in case that is easily accessible.

Why would you make the resolution harder to parse instead of just providing a seperate variable for color depth?

Kaioken wrote:
You might as well add a function to check a player's default browser or maybe e-mail program so you can ban him if you don't like it, or add the gender as an argument in world/IsBanned(). :P

Yes, because those things are all similar. Default browser could very well be relevant to check; what if you're launching an external browse that doesn't even work in IE? Then you'd want to warn the player about that.

Or you could just keep lobbying for BYOND to handle everything for you, making it harder and harder for those of us who try and create something that doesn't look like a generic skin. If the concept of having to write a 5-line function to handle this with exposed client info is too burdening for you, then I'll have to go with the idea that you're just arguing for the sake of it.
In response to Alathon
Alathon wrote:
I don't want to be forced to align myself with some generic automatic warning that I can't control.

But it doesn't have anything to do with aligning with the game, or the game. It'd be an alert from the BYOND pager itself.

Oh look dolly, options! Possibilities! Not being restrained to some generic message which won't fit the scheme of an umpteen amount of games if they even bother to skin their interface a wee bit.

Same as above. I suppose you're opting for a new interface format that let's developers customize how their players' pager application (byond.exe) looks as well?

Or alerting them that if they stay in 16-bit or 8-bit color depth, they won't be getting the full experience playing the game.

That's what BYOND will alert them to, and for all BYOND games they might choose to play in, because it's a BYOND problem.

Why would you make the resolution harder to parse instead of just providing a separate variable for color depth?

So now 5 lines is burdening. ;) As for the question, because having a client var give the value of a player's color depth while related, but much more usefully relevant info, his resolution, is completely inaccessible would be pretty ridiculous. I don't mind if they add a var for color depth after they get around to finally supplying the resolution, but because of its limited uses it might not completely warrant a new var even then, but that's something to think on.
In response to Kaioken
BYOND doesn't work without 32-bit colour. It's not the games that don't work without 32-bit colour. So BYOND should display the warning.

Which would you rather do? And since it's a problem with BYOND, NOT the games, BYOND should warn the user, NOT the games. And that way it would also only be displayed for versions of BYOND with the problem. It would also reduce the amount of (completely unnecessary) work the game's creator has to do, and it would reduce the amount of network traffic.

And: Can a game be written that displays a warning when you start the pager? I thought not.
In response to Kaioken
(From what I understand) Kaioken's suggestion offers convenience and Alathon's suggestion offers power and options.

I'd get behind power and options over convenience any day. In my opinion, BYOND too often takes the path of convenience, binding logic to low-level functionality (like getting the client's screen resolution and color depth) - logic I'd rather handle myself.

Convenience will get you quantity over quality (and diversity) and I don't see why we should suggest dumbing a system down because we're afraid people can't handle programming for it.

As a compromise, I'd rather see two things:
-The ability to get a datum containing the client's screen width, height, and color depth (if not refresh rate).
-Some hook (by hook I mean an overridable proc - like New()) that occurs before resource download, client New() and Login()

But, I'm guessing the second is impossible/improbable.
In response to TheMonkeyDidIt
Actually, you can already get screen width and height. I should make a library on it, it's pretty simple.
In response to Jeff8500
I appreciate the thought, but if you're referring to the JS or winget methods, I'm well aware of them and I find them to be fairly hacky-esque. Unless your speaking of some other way?

Anyway, point is: I'd vote much more often for the Alathon 'control over convenience' philosophy.

Hell, I'd rather have the option of getting ALL possible display settings and SET them to what I want the player at (or some player choice from a list I present) with the game fullscreen.

Meh. Not that I'm bitter or anything.
In response to TheMonkeyDidIt
I'm referring to the winget() method. It's the only good method, and while a datum containing the vars would be nice, control over convenience :P.
In response to Jeff8500
The non-JS methods are fairly hackish, and none are necessarily constantly accurate as far as I'm aware; a proper method to get this info would be considerably better.
In response to Jeff8500
Naturally the current method offers no more control than a datum describing the nature of a client's screen, and less convenience. As such some form of object exposing this information (even if read-only) represents a marked improvement as it exposes more data to the developer while also solving an inconvenient interface short-coming. There is no trade-off between control and convenience, which was the decision-making dilemma that the control over convenience notion was looking to address.
In response to TheMonkeyDidIt
TheMonkeyDidIt wrote:
-Some hook (by hook I mean an overridable proc - like New()) that occurs before resource download, client New() and Login()

But, I'm guessing the second is impossible/improbable.

Why would that be impossible, since IsBanned() works exactly like that. Happens before resource download and creating a client.


TheMonkeyDidIt wrote:
As a compromise

I would rather see a compromise as well (e.g. a warning that has a default setting, but can be changed to the developers content). I don't see a real need to announce a warning in the pager, rather than in a game, since a lot of games won't use features that would need 32 bit graphic setting and for the people using them, there is no need to see this warning.
In response to Immibis
I've never seen a BYOND game that worked only in 32-bit color. I've been using 16-bit color on my monitor and all the icons look fine to me.
Page: 1 2