No, that may be a bug. Please report any issue with the system in the maptext thread.
I'd make maptext a type of /atom/movable you can place on the map. You can set its pixel_x/y/z vars, visibility, etc. to control how it's displayed. If you want to attach it to a mob you can add an instance of /maptext to a mob's overlays.

I'd also make the maptext object adjust its size to fit the text on one line by default. If its width and height are both zero when you set its text, its width and height are updated to reflect the size it occupies. If you set its width to 120 but leave the height at zero, it'll wrap the text to fit inside a width of 120 pixels and will set its height to be the vertical space occupied by the text.

Having it be its own type also gives you the ability to add vars to the /maptext type that control additional display properties. Things like font, background color, border, etc.

One alternative is to stick with the atom.maptext var but to have significant HTML support, so you could do something like this:

mob.maptext = {"<div style="border: 1px solid #000; background: #fe9; width: 100px;">This is the mob's tooltip.</div>"}

The best alternative is to have code that can execute on the client. That way you can create text using existing methods (ex: creating one object or overlay per letter) but the objects are being created on the client, not on the server. The client just has to invoke a method that resides on the client. This type of thing really lends itself to being handled by the client because it's for client-end display purposes only.

The server has the ability to execute DM code and the client has the ability to cause procs on the server to be executed. The server has the ability to create objects, define/manipulate their appearance, and tell the client about the object's appearance. The client has the ability to draw objects given their appearance.

All of the pieces are already made (ex: the BYOND staff has functions to execute DM code), you just need to set things up so the client can create objects that are "client-side". Instead of being managed by the server they exist only within that client. The only trouble spots I can see are:

1. How to interpret server-mandated changes to objects that have been manipulated by the client.

2. How to sandbox the code that runs on the client.

The first problem is mostly for the developer to deal with. If both the server and client are changing the same atom's icon, that's my problem to deal with. The second problem is mostly about preventing certain actions. Many things don't make sense (alert, input, etc.) and many things would obviously be prevented (file read/write/delete, etc.).
Currently maptext is a property of /atom so you can massage it into any kind of subtype you want simply by overriding a /atom. The reason I did it this way is that things like images and overlays already accept atoms and those are things you'd commonly want to use maptext with. I don't think this is an issue. Limited styling is supported through the HTML, as you suggested (currently it handles alignment, fonts, colors, images).

The major problem is with text-extent. We can't easily update the variables to reflect the size of the text because the size is only known by the client (this stuff is in fact set by windows calls so the server may not even have access to it). I do consider this a significant limitation since it requires the dev to either use heuristics or know the size of the fonts in advance, but I'll think about ways we can deal with it.
In response to Tom (#22)
Tom wrote:
Currently maptext is a property of /atom so you can massage it into any kind of subtype you want simply by overriding a /atom.

The difference is that the properties of maptext will be exposed clumsily through vars like maptext_width. You're not likely to add the full set of properties that it actually needs. If /maptext was a type of object it could have its own vars and procs.

The way it is now, it's not likely that people will use a mob's maptext directly. To simply display a mob's name you'll need to create an object, set its maptext, and add it as an overlay. There's nothing wrong with that (aside from, as Kaiochao mentioned, also showing a copy of the mob's icon), but if you're going to always use maptext by creating additional objects to act as overlays or screen objects it might as well be its own type.

The major problem is with text-extent. We can't easily update the variables to reflect the size of the text because the size is only known by the client (this stuff is in fact set by windows calls so the server may not even have access to it). I do consider this a significant limitation since it requires the dev to either use heuristics or know the size of the fonts in advance, but I'll think about ways we can deal with it.

If you can write code on the client that positions text and can determine its width, you can write that same code on the server. Another problem is that if the font can be drawn in different ways on different computers, there's no way for the developer to know what sizes to use.

You might be better off creating your own "font" file. It could just be a .dmi file with some extra information. This would let the user create custom fonts easily and it'd force consistency with how the font is drawn.
In response to Forum_account (#23)
Forum_account wrote:
The difference is that the properties of maptext will be exposed clumsily through vars like maptext_width. You're not likely to add the full set of properties that it actually needs. If /maptext was a type of object it could have its own vars and procs.

True, but the same could be said of mob.icon pointing to an icon object rather than a file. If we ever wanted to expand maptext down the line, we could always have atom.maptext = {some maptext object} and do it that way. Having it be a part of /atom is extraordinarily convenient on our end because we support /atom drawing in so many places where you'd also want to use maptext. Width & height are the only additonal things we absolutely need to know because, unlike with icons, text does not have an internal bounding box.


If you can write code on the client that positions text and can determine its width, you can write that same code on the server.

Not when the server and client may have different architectures. For example, what if the host is on linux? I'm using windows calls to pull fonts, calculate extents, and draw text. This is all client-side and may change with the machine (for example, in Flash). I realize this is limiting in cases where you may want to have server-based precision, and in that case you may have to use a soft-coded solution. Or we might be able to come up with a reasonable system that involves querying the client when the host doesn't have that info available. I don't know. Again, my goal was to just get something that worked well for a lot of common cases, and I think people have found some benefits already (even though it's a bit incomplete atm).
In response to Forum_account (#23)
Forum_account wrote:
The difference is that the properties of maptext will be exposed clumsily through vars like maptext_width. You're not likely to add the full set of properties that it actually needs. If /maptext was a type of object it could have its own vars and procs.

You're basically raising my same points.

The main thing about it having its own procs is it can have things like AppendText() and what not so we could add text to it without needing to redo all the text.

With that said, I think the new maptext is more like a "label" and we're wanting it to be a "textbox".
I don't think the maptext_x and maptext_y are necessary. I've used maptext with much success in my current projects. For a fully featured chat system using maptext, I have had no need for additional offset parameters. I've seen a few other chat systems and so forth around, using maptext, that have no problems without these additional parameters.

I think all we need is some documentation and whatever confusion there may be should be cleared up.

I will have to agree about the default values for maptext_height and maptext_width though. That one was pretty frustrating to figure out at first, because of the lack of documentation (Since it made sense for the default value, 0, to allow text of "infinite" width and height).
If you're using screen objects, maptext_x/y aren't necessary because you can specify pixel position values in screen_loc. If you're using maptext as an overlay, you can use the object's pixel_x/y. The maptext_x/y vars are only essential if you want to simply use a mob's maptext var. It would make it more newbie friendly but there's no point to it because you can add maptext as an overlay (assuming it worked properly). If adding maptext as an overlay isn't newbie friendly, we need to change our definition of what a newbie is.

Aaiko wrote:
With that said, I think the new maptext is more like a "label" and we're wanting it to be a "textbox".

It's not that I want it to be like a textbox, but I want it to be able to be used for textboxes. Currently, you can use existing methods of creating on-screen text to create textboxes but that wouldn't be able to make use of maptext.

Also, maptext can't even be used for labels. A simple use of maptext is creating tooltips. If you want the tooltips to have a border or background color you're out of luck because you can't determine the size of the text.

Tom wrote:
Not when the server and client may have different architectures. For example, what if the host is on linux? I'm using windows calls to pull fonts, calculate extents, and draw text. This is all client-side and may change with the machine (for example, in Flash). I realize this is limiting in cases where you may want to have server-based precision, and in that case you may have to use a soft-coded solution. Or we might be able to come up with a reasonable system that involves querying the client when the host doesn't have that info available. I don't know.

All the more reason to use an internal font format or to avoid this entirely by supporting client-side processing. Polling the client for values is undesirable. You can't guarantee that fonts will be drawn the same on all clients, so different clients could return different values. The extra back and forth communication to get a value from the client is undesirable too.

Again, my goal was to just get something that worked well for a lot of common cases, and I think people have found some benefits already (even though it's a bit incomplete atm).

I'm not sure it works for a lot of common cases. So far it works for displaying on-screen chat to a limited extent - no scrolling, no on-screen input. It also works for displaying names below mobs but there's not a huge performance difference there.

I'd rather have a way to nest interface controls inside of a map control. For example, you place a textbox on the map control in DM's interface editor and the textbox will be rendered as part of the map. If the window is stretched out and the map is drawn at 2x size, so is the textbox. If you want on-screen chat, just nest an output control inside the map control.
In response to Forum_account (#27)
Forum_account: you are basically saying, "do it my way or don't do it at all". I'm saying that your way isn't feasible but this method is; if users don't find it suitable, they can use the existing soft-coded methods (which have always been quite good, hence the reason this was never a priority). Native maptext adds no extra overhead and very little complexity to the language. The main advantages are simplicity and having access to a bunch of fonts and styles.

You may not find this useful, but a lot of users have. It works fine for onscreen chat; you can scroll by culling text around newlines (it doesn't hurt to send more text than you want to display, as the client will clip to your bounding box, showing the end text by default). You can do tooltips by setting a bg color (I don't recall if that's in the current beta but it will be in the final, and possibly a border too). There are plenty of things you currently can't do well without proper extent knowledge, but even that can be avoided through use of fixed-width fonts or heuristics.

Anyway, as usual we're saying the same thing back and forth. I was on the fence whether we should even release this since it is an incomplete solution, but I've seen enough good things from people who have tested me to confirm that it is valuable to them.
In response to Tom (#28)
Tom wrote:
if users don't find it suitable, they can use the existing soft-coded methods (which have always been quite good, hence the reason this was never a priority).

Could you elaborate on "quite good". Here's a short list of methods I can think of for soft-coding on-map text...

1. one object or atom per letter
2. one object or atom per sentence or "line" of text
3. one object or atom period, text is always added as overlays with pixel offsets
4. no objects, text and its letters are "images" (hard to manage / sort)

All of these require the server to send visual updates to the client, ie: "you can see this"... but the "this" is fully described over the wire (lots of data, very slow).

In my tests, I wrote my own version that added each letter of a sentence as an image object to the overlays of a screen object for each client. Hosted on my laptop, had my friend test it, he said it took 3 seconds to display after the command was executed.

Tried the same thing with forum_account's hud groups example and it took much less time. His does not use overlays, but uses one object per line (I think, forum_account??)

So this poses the question... Where are the optimizations at for speed transfers and what is the most optimal? Would it be even faster if each letter was an object (albeit too many objects = bad design)?

Regardless, I think having map text is a MUST. Even if the feature is worthless to some people; I think just for speed and bandwidth purposes, it is very useful.
Tom wrote:
You may not find this useful, but a lot of users have.

I do find it useful, just not nearly as useful as it could be. There should be a long list of features you could use maptext for, but there's not.

This is what happened with custom interfaces. The feature had a lot of potential but interface controls are ugly and hard to use. Instead of using them to their full potential people only use them for a handful of things. Generally, they're only used for chat input, output, and mode selection (say, global, ooc, etc.). The need for maptext stems from how bad interface controls are.

The same thing will happen with maptext. The feature has a lot of potential but, because of how it works, people will use it for just a handful of things (names under mobs, on-screen chat, tooltips). For those few things this feature is useful*, but it doesn't help developers for all other text-based features.

* Even this is questionable because you lose control over how text is displayed (no custom fonts, no control over how letters appear/disappear, etc.).

FIREking wrote:
Could you elaborate on "quite good". Here's a short list of methods I can think of for soft-coding on-map text...

Current methods aren't bad for lots of things. Maptext is most beneficial for dynamic text. If you use overlays to write a player's name below their mob, you have to send more data to each client but this should only happen when you first see the player. Once they're on your screen you'll have their overlay information and it won't be updated unless their name changes. It only sends more data to the client initially (that's how it should work, at least).

An example of dynamic text is on-screen chat. Player chat isn't that bad (the messages at least remain visible for a while). The worst case would probably be an on-screen display of an NPC's chat messages (like in old console RPGs). Each message is generating using a ton of objects, displayed to the player for a short time, then you delete all of the objects. You have to send a lot of data to the client for a message that is seen for a short time.
I would like to see some love for the following working exactly the same as one large icon:


obj/outputbox
icon = 'outputbox.dmi'
screen_loc = "13,1 to 19,4"
maptext_width = 192
maptext_height = 128
maptext = "Test"

mob/player/default/proc

Create_Chatbox()
client.screen += chatbox

Remove_Chatbox()
client.screen -= chatbox
I still would like this feature to be implemented. I shouldn't have to go out of my way to create a new object and slap it on top of the existing object just to make the maptext appear to move over a couple pixels.
In response to Yut Put (#32)
Yut Put wrote:
I still would like this feature to be implemented. I shouldn't have to go out of my way to create a new object and slap it on top of the existing object just to make the maptext appear to move over a couple pixels.

Yeah, it's pretty complicated. I have a good way of managing it though, luckily.
Page: 1 2