maptext_x and maptext_y in Feature Requests

Page: 1 2
ID:364795
 
Feb 25 2012, 9:56 pm
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
Not sure where this goes exactly since it's about a beta version of BYOND, but here is my feedback after using the new maptext feature extensively:

I would like two variables to be included with the addition of maptext:

maptext_x, and maptext_y

They would determine the pixel offset of the atom's maptext. Currently, positioning maptext is very difficult and perplexing, even for the experienced users.

I'd also ask that there be default values for maptext_height and maptext_width. Many users are complaining to me about how their maptext is by default invisible because they did not define the height and width yet for their atoms, and it's a pain for me to have to do too.
#1 Feb 25 2012, 9:58 pm
I don't understand the necessity of maptext_width/height, but that's probably because there's no documentation on the feature yet. I would like to assume that when it goes public, it should be straightforward enough as simply setting maptext to something and have it show up.
#2 Feb 26 2012, 12:39 am
I still think the maptext should be its own datum and called something more like textfield which has all the variables for the texts and then people can add it as an overlay to things or just simply place it on the map. It could even be an atom/movable or something and could even have pixel_x and pixel_y and all that other stuff. I find it odd the way they're doing this text stuff.

As more customization is added, every atom is going to have 20 variables for "maptext" and what not.

They could even add some type of "interface" datum which then has "textfield" and "scrollbar" and other stuff. You can then link the scrollbar to the textfield and scroll the text and make the scrollbar look however you want and place it anywhere you want. They could even get rid of the 4.0 interfaces entirely and replace them with these interface datums, making everything fully onscreen and compatible with the upcoming Flash client.

There's just so much that could be done (and should be), so going about this text stuff in this method is going to bite them in the ass in the future.

But that's all just my opinion. Sorry to hijack your request, I just think if the text was done the proper way, a request like this wouldn't be needed.
#3 Feb 26 2012, 1:02 am
The "odd way" of doing text stuff is exactly what you want. The reason I made maptext a properly of /atom is so that you can just make a /atom that is used for your text and use it wherever you want (eg, with an image, an overlay, or a regular map object). There is no need to support "20 variables" for maptext because we already have those variables on /atom. In other words, atom.maptext and atom.icon are really two forms of the same thing-- a visual representation of the atom; the fact that you can mix them is really just a bonus and not really something I'd encourage.

If you want to offset your text, just make a /obj with the maptext and use step_x and step_y.

The default values of maptext_width and maptext_height are just the tile size. I'm not really understanding why this concept is so hard for people to get, unless there is an error in the implementation. All you do is set the text and the bounding box, and from there you can just treat it as if you had an icon of that size attached to the atom.
#4 Feb 26 2012, 1:41 am (Edited on Feb 26 2012, 1:52 am)
In response to Tom (#3)
Tom wrote:
The "odd way" of doing text stuff is exactly what you want.

It makes sense if all you want is a "block of text", which is what it currently is. If that's all you want and all you plan on doing, it'll work the way it is.

I just assumed you'd want to expand on the feature in the future. Like make it an actual textbox with scrolling, text selection, let it be an input, and what not. I don't know if you're the one working on the Flash client or Lummox JR, but Flash has a nice way of doing text (which they call textfields and is its own object).

As a datum you could run icon operations on them to give it alpha transparency and many other things. The developer can then make children of the datum to share properties instead of declaring colors, styles, and all that inside the block of text all the time. For example:

/interface/textfield //built-in
    Sidebar //developer-made
        text_color="#000"
        InfoText
            this=that
            this2=that2
        InfoText2
            this=that2
            this2=that


There are many other things as well.

If your Flash client pays off, you can assume majority of games will go through it, thus the old 4.0 interface stuff will eventually be obsolete. But you can still give developers the ability to do those interface things on the actual map via onscreen objects like an "interface" datum, in which a textbox (known as an Output or Label in DM) would branch from and the current maptext method wouldn't be needed. You could replace the 4.0 controls with their own respective onscreen object datums.

The language is starting to get confusing. It used to be really object oriented and now it's starting to become it's own hybrid thing. While I enjoyed 4.0 interface stuff because I could customize my games more, the way it was done made no sense in the grand scheme of the language. I feel this onscreen text stuff is going the same route. It'll work, it just doesn't fit the language as well and is hard to expand on in the future.

But I'm just assuming the language will eventually get to the point of fully onscreen and built-in interface controls to replace the 4.0 stuff.

By the way, I'm not trying to bash you or your work, I just wanted to provide some friendly and constructive criticism.
#5 Feb 26 2012, 1:52 am
The reason why this and the interface stuff may seem non-OO is that they are client-side features. BYOND does not have a true concept of a client-side compiler, so it is difficult to integrate this kind of elegant notation efficiently. The server really has no idea of what text is being rendered because it isn't the one doing the rendering (this presents the biggest issue with the system in that it is difficult to properly cull text without knowing where it resides).

I was under the impression that people could make use of a simple way to output text, and if the system had limitations, they could use the less-efficient but more-flexible soft-coded solutions (which are of course all server-side). If this isn't what is needed, I'll be glad to pull it. Implementing things as you want is just a lot more difficult... that's just the bottom line. Perhaps that isn't good long-term thinking but unless people start making good use of the existing feature set to produce quality games that can bring us some income, BYOND has no long-term future anyway.

Flash has a lot more options available to it because it is purely client-side.
#6 Feb 26 2012, 2:07 am
In response to Tom (#5)
It's a good feature no matter what. I guess I'm just being hopeful that you'd expand on the onscreen interface side of things (where onscreen text would fall into) eventually and replace the old Windows-based interface stuff. Flash already has that stuff made, you just have to translate the DM language to said Flash components and display them on the client's screen.

I'm mostly just worried about not being able to have the interface I want with the Flash client and I think a purely map-based language (outputs and all) would be ideal for the language.

#7 Feb 26 2012, 2:38 am
I understand, but I don't think you appreciate the difference between an interface object and a map object from the POV of a client-server architecture. A map is mostly passive as far as the client is concerned, but an interface requires interaction and constant feedback. To properly handle interfaces, we'd need to have a client-side DM interpreter, which introduces all sorts of synching headaches.

In the interest of compromise, what I've done here instead is repurposed our existing network object-- the atom-- so it can display text. This just introduces a new fundamental display unit, analogous to the icon. You can build interfaces on top of this (in Flash it will display using the text field but the dev need not care about that). You could even build a library to make the notation more OO and have it create different UI components around the text. In fact, Forum_account has already written something like this for soft-coded text and could probably update it to use this new maptext when it is ready.
#8 Feb 26 2012, 2:55 am
In response to Tom (#7)
You went the simplistic route. Me and other developers are always going to ask for the more complex stuff so we don't have to do it ourselves on the server-side. Server-side scrollbars (or the illusion of them anyway), for example, would be a poor way of handling them, which is why I would rather have the ability to put a full functioning textbox on the screen instead of just text. Which is what I thought this might eventually lead to, thus more variables would be needed, which is in turn why I recommended the datum approach.

Anyway, the feature is good no matter what, I just hope we can add glows and outlines to the text eventually.
#9 Feb 26 2012, 4:56 am
There's nothing wrong with DM providing simplistic features as long as it's not too simple that it prevents us from developing more complex features with them. Unfortunately, that's often the case (I'm not sure yet if that'll be the case with maptext).

Many of BYOND's features work this way - you have to either take it or leave it. If you don't want pathfinding the way walk_to() works, you have to implement pathfinding yourself from scratch. If you don't want to handle collisions exactly the way BYOND's pixel movement handles them, you have to implement pixel movement yourself. I wouldn't be surprised if maptext turns out the same way. These features make BYOND look useful but when you consider that you often can't use these features at all to accomplish what you really need to accomplish, it can end up being a huge waste of time for the staff. Taking the time to add features in a way that developers can easily expand upon them would be very beneficial.
#10 Feb 27 2012, 12:00 am
In response to Tom (#5)
Tom wrote:
I was under the impression that people could make use of a simple way to output text, and if the system had limitations, they could use the less-efficient but more-flexible soft-coded solutions (which are of course all server-side). If this isn't what is needed, I'll be glad to pull it. Implementing things as you want is just a lot more difficult... that's just the bottom line. Perhaps that isn't good long-term thinking but unless people start making good use of the existing feature set to produce quality games that can bring us some income, BYOND has no long-term future anyway.
...

I'm not so sure I feel like a respected user when you are basically saying you require us to make you some income by using a limited system.

Give us better tools, and you'll get better games.
#11 Feb 27 2012, 12:16 am
It isn't a criticism. It's a fact. If people can't make successful, income- generating games with the current system, this project will die. And if you think BYOND is too limited to do what you want, just use something else. It will be more powerful, but more difficult too. That's the tradeoff when using any engine.
#12 Feb 27 2012, 12:52 am
In response to Forum_account (#9)
Forum_account wrote:
I wouldn't be surprised if maptext turns out the same way. These features make BYOND look useful but when you consider that you often can't use these features at all to accomplish what you really need to accomplish, it can end up being a huge waste of time for the staff. Taking the time to add features in a way that developers can easily expand upon them would be very beneficial.

The OP is already using maptext (which is a lot easier and more efficient, albeit less flexible than the soft-coded solution) and the issue he has brought up is not a problem if he simply treats text units as their own objects. Although this isn't the most comprehensive solution, I believe it is sufficient for the majority of games that want to output text on the map. This is largely how DM works-- it isn't the most powerful language and I know some users get frustrated with having to use inelegant workarounds, but it tries to handle common tasks without forcing the dev to think about them too much.

I hope that this feature can be used in much the same way that the pixel-movement is, as both a default mechanism for basic use and a drop-in for more complicated libraries. I have some doubts about the latter due to the sever's lack of awarenes of text extents, but I'll think about how we can deal with that.

Mostly the idea was just to get something out, because this really did fall out naturally from some other recent developments.
#13 Feb 27 2012, 1:29 am
In response to Aaiko (#8)
Aaiko wrote:
You went the simplistic route. Me and other developers are always going to ask for the more complex stuff so we don't have to do it ourselves on the server-side.

Forum_account wrote:
There's nothing wrong with DM providing simplistic features as long as it's not too simple that it prevents us from developing more complex features with them.

You also have to keep in mind these features must be simple enough for any newbie to use them. There are already many advanced techniques for handling text more elegantly, but this feature is both simple and efficient. I think it hits that sweet spot right between ease of use and functionality.
#14 Feb 27 2012, 6:53 am
In response to SuperAntx (#13)
I agree. When you think about the fact that the maptext feature will only mainly be used for simple on-screen prompts, names, login screens, labels, and the like, you begin to understand why it doesn't need to be that complicated. Keeping it simple is really the best way to go, and if you do need something that has more functionality and flexibility, you're still very free to use the soft-coded libraries already available. Either way you see it, this will take quite a bit of load off of servers while generating on-screen text, and the more complicated text-library functions will only be called periodically when you need them.
#15 Feb 27 2012, 7:07 am
In response to Tom (#12)
I haven't used maptext much so I'm not sure if it's flexible enough that its useful for more complicated situations. There are a few things I could use it for to replace parts of my libraries but I don't think it would work.

The Speech Bubbles library sets the height of the bubble based on how many lines of text there are. To make it work with maptext I'd need to set the maptext_width, create the text, then figure out the necessary height. It sounds like maptext doesn't support this (you can use maptext_height to limit the height, but not to read the natural height of the text).

The HUD Groups library would also need that feature. Also, for HUD-based textboxes you need to be able to display non-text things. At the very least you'd need to be able to show where the text cursor is but I don't think that's possible. It also includes functions to find the widths of strings (as opposed to only being able to say "clip this string to this width") and maptext doesn't provide a way to do that.

BYOND doesn't need an easy way to place text on the map. It needs an easy way to place text on the map that can be used in decent-looking ways. Functionally it doesn't seem like a big deal, but there's a huge difference between being able to use maptext to create nice-looking tooltips and being able to use it to only create ugly tooltips.

Dream Maker's interface editor is great but you can only use it to create plain looking forms with windows controls. You can't use it to create nice looking interfaces like you'd expect to see in a modern game. It seems like the feature should be very useful but it isn't. While there is the potential to create huge, complex forms with the interface editor most people don't use it because it'd look bad. Most games just use the interface editor to, at most, place a map control, output control, text box, and a few buttons.

The interface editor can't create interfaces that are remotely professional looking, so the feature is used in a very limited way. The same thing can be said about the winset/winget procs, isometric maps, and other features. If maptext can't be used to create something that's remotely professional looking, there's a good reason to believe that it will also be used in a very limited way.
#16 Feb 27 2012, 9:15 am
In response to Tom (#11)
Tom wrote:
It isn't a criticism. It's a fact. If people can't make successful, income- generating games with the current system, this project will die. And if you think BYOND is too limited to do what you want, just use something else. It will be more powerful, but more difficult too. That's the tradeoff when using any engine.

I'm simply saying fighting your user base isn't going to help your cause.
#17 Feb 27 2012, 12:34 pm
I think it might be nicer if maptext_width/height could be thought of as the dimensions of an onscreen text box, so that it would wrap the text rather than make all the text completely disappear when it's out of bounds.
#18 Feb 27 2012, 12:42 pm
In response to Kaiochao (#17)
Kaiochao wrote:
I think it might be nicer if maptext_width/height could be thought of as the dimensions of an onscreen text box, so that it would wrap the text rather than make all the text completely disappear when it's out of bounds.

That's what it does.
#19 Feb 27 2012, 1:29 pm
In response to Tom (#18)
Strange, it's working now. I'm pretty sure it hasn't been working before, since I've tried many different ways to make text actually show up, but all I've ever had was nothing.

I given an /obj maptext, and added it as an overlay to my mob. Is it intended for the maptext to have a copy of my mob's icon in it?
Page: 1 2