It's already possible to have a talking NPC in a chat. There's a few different ways to do that. As for on labels, why? If you want something like that, use on screen objects. As BYOND moves forward, interfaces are becoming less and less ideal for most games, because they're not compatible with HTML 5 client and they're not as flexible as on screen objects.

There's no fixing this, and no need to. Interfaces have their own uses, and there's nothing wrong with using them, but this feature is unnecessary and would probably result in nothing but trolling, and/or ugly stuff in games made by the younger and/or less mature developers.

I don't mean to insult anyone of course, and I'm all for suggesting ideas, but this one simply wouldn't do much good for the vast majority of the community; so it would be a bad idea to waste time adding it.

@Toddab503

Lol, I'm sorry but your arguement against this feature request doesn't make a whole lot of sense. Scratch that- it doesn't make any sense.

____________________________________________________________
I quote:

"would probably result in nothing but trolling, and/or ugly stuff in games made by the younger and/or less mature developers."

First, I would like to clear the air by letting you know that Dream Maker is a free-to-use tool, where people can create their Dreams, or whatever they might happen to want to make, if it's pornographic or offensive then it simply doesn't get shown on the site.

I would like to add that you can create something immature or... ugly with just about anything in BYOND.
____________________________________________________________

"There's no fixing this, and no need to."

It's not a bug, this is a feature-request, put in the feature-request section of the forum.
____________________________________________________________

"they're not as flexible as on screen objects."

Interfaces are far more flexible than onscreen objects, and far easier to use.
____________________________________________________________

"As for on labels, why? If you want something like that, use on screen objects."

Interfaces are far easier to use and create than onscreen objects, which whilst are not obsolete; do not support gifs efficiently. And will certainly not support images of the size used on title screens.(Without terrible lag)


An example of a titlescreen made with an interface
____________________________________________________________

And lastly, your magnum opus.

"so it would be a bad idea to waste time adding it."

... I haven't got a lot to say to this, other than the feature is hardly an engine overhaul, and the key objective of any engine is to progress.

____________________________________________________________

Have I covered everything, there? Let me know if I haven't. Interfaces are far faster than onscreen objects (Which you seem so overly fond of). And whilst I do not want to upset or offend you, I think that you should learnt a little more about the engine before you try to impede it's progress.

Todda probably knows more about the engine than most.

Although I would also prefer if interfaces could have this feature, I can see the sense in not implementing it.

The future for byond is html5/flash and interfaces will apparently be phased out. Thus more emphasis on on-screen objects. I am sure if you really wanted to, you could implement this with some javascript/html in a browser(interface).

@Bumblemore

You are correct, it is a free to use tool to make anything the developer wants, but that doesn't mean a feature that would probably only benefit a few of the more interface focused developers should be added. Especially since interfaces won't be supported by the HTML 5 client and this request might encourage bad habits that result in more unappealing GUI design in games that don't use the client as well. That is what I meant by the ugly and immature bit. Sorry for the confusion.

---

I never said it was a bug. The no fixing this, and no need to bit was referring to interfaces not being compatible with the HTML 5 client and the fact that they're less flexible than on-screen objects.

---

They are easier to learn and/or use, yes, but you are wrong about the interface being more flexible. Interfaces tend to still be in the lead for inputs and outputs, but maptext is helping on-screen objects catch up in my opinion, and the HTML 5 client will offer even better, more flexible options; though they will require some learning and effort to do.

I used to think interfaces were superior as well, but I learned the hard way that I was wrong. Granted, my mind wasn't set as strongly toward interfaces as you, but either way; on-screen objects done properly do prove to be far more flexible. They're a lot better for transparency, and offer way more control over the visual appearance of each piece of your GUI, etc.

---

On-screen objects don't need to support images, but they can. Truthfully though, rather than on-screen objects, on-screen images would probably be a more accurate term for your situation. At least for the gif. You would need objects for 'buttons' and such. You can create a dmi with an animation, or a still frame, or you may even be able to use the gif directly and set up a /image to do it. I've never tested using a gif, so I can't fully comment on that, but it's only because I didn't ever need to. All of this can be done nearly as efficiently as well as interfaces as well.

Interfaces are fast, no doubt, but I don't think they're always faster, and faster or not they get that speed at the cost of flexibility, customization, etc.

---

In conclusion, I suspect the problem here is that you aren't yet familiar enough with on-screen objects and images to use them efficiently and understand my point. Interfaces take some time to learn and get good with, on-screen objects and images take a bit more time than interfaces to learn and especially use properly, so once someone learns interfaces it can be hard to find the interest and motivation to switch but it's worth it. I know from recent experiences that this is true.

Do not just take my word for it, though. Look at NEStalgia, Eternia, and just about any other game doing really well on BYOND. They're all running well with very little of their GUI being interface based, most of it is all on-screen objects and images. They do use interfaces for some input and output, but not much else for the most part. Any performance issues they do experience have nothing to do with the on-screen stuff, because they set up the on-screen stuff properly.

SS 13 is, of course, excluded from all of this because they're essentially running a 3.5 interface with little to no on-screen objects from what admittedly little I've seen. You can argue with me about all of this if you'd like, but a lot of developers have contributed to the games I mentioned, so you have to at least consider these points.

However. I won't argue this any further. This feature request is no place for that. The whole point of my post was to bring up other options to you, and to state that I disagree with this feature request and feel it wouldn't be worth the effort. Part of why I feel it wouldn't be worth it is because I, like Ter13, thought this might not even be feasible, which could make looking into it more work than it's worth; but I seem to of forgotten to mention that bit so I apologize for that.

I don't know more than most as Jean suggested, I just know enough to support my opinions; which I've shared. So, I hope you don't feel that I came here to troll, or be an ass; I really do just disagree with the idea. The rest of my posts are simply the reasons why I do.

Good luck with figuring everything out for your title screen, and I hope it goes well. No sarcasm or anything intended. Just genuinely wishing you luck.

Tbh it's kind of aids that they're removing interfaces

Will interfaces still exist for Windows clients though? You have to realize that BYOND can be used for making more than just games, even though that is the primary use. As much as I hate to see them in games, interfaces can actually benefit certain kinds of useful applications. Don't forget that without them, you couldn't have things like multiple windows or maps.

I hope that interfaces will stay for games run from the desktop, and that these changes will only affect the HTML5 clients. Surely they wouldn't release a version of BYOND where the vast majority of games are completely broken would they?

Tom wrote:

The idea is that the web-version of BYOND will be more or less split from the existing, legacy version, with UI components completely designed (by the game developer) in html/javascript (or maybe something more modern like Polymer). Depending on how successful this is, we could then use this same system to embed these new BYOND games in standalone exes containing a single embedded browser component, mainly to support the client-server BYOND games you've all grown to know and love (as porting the server to a web-interface is essentially impossible).

This is what has me kind of worried. It sounds like Tom is talking about splitting BYOND into two separate versions, with the current one being "legacy" compared to the other. I think it would be better if the HTML5 client were just a new feature of the existing version, rather than some kind of replacement. Clients should be able to coexist on both the desktop, and on the web, all connected to the same server.

If BYOND were split into two separate versions, would the current "legacy" version receive the same amount of support as the HTML5 version?

Toddab503 wrote:

I don't think Tom means to say that both versions won't receive updates and what not. I think they'll be kind of like separate products. I don't, however, see much if any way for both to connect to the same server. I don't see how the html5 client could filter out all the interface based code, and one runs macros and the other doesn't etc.

I could be wrong, but that may be a very unrealistic expectation. Having a separate server for each wouldn't be so bad, though. I'm sure with the advances in the standalone client, both versions will see pretty much equal support.

Tom has historically been against the idea of maintaining multiple builds and products, and only does it when necessary. I think the history of maintaining Linux/FreeBSD builds has been somewhat... Annoying for them. That's not to say they won't do it, though.

Sounds fair enough.