ID:121542
 
Resolved
The atom/maptext var can be used to output text on the map. The text is displayed in a rectangle defined by atom/maptext_width & atom/maptext_height. The map control's font & color is used for drawing, but can be overriden with html styling.
Applies to:DM Language
Status: Resolved (494)

This issue has been resolved.
Support for native drawing of text on the map (it's requested in here somewhere for sure)
This was just something thrown in when I realized we now support arbitrarily-sized bounding boxes and could thus handle text-extend. It seems to do fine in limited testing, but I don't know how well it'll hold up with heavy use since there is some overhead in the way DM manages the strings passed around. If not, there are the existing icon-based workarounds.

Since it repurposes the bound_vars, it's best used (obviously) for non-dense movable or image objects. The object's layer is used to draw the text, and it can be used alongside icons (the text will be drawn after the icon in the same layer).
Interesting
Please implement a way to make this library obsolete next, then this one, then this one.
I'm guessing this is mostly for speech bubbles and name tags? Sounds pretty cool.
Very nice. :D

Keep up the good work Tom and the staff!
SuperAntx wrote:
I'm guessing this is mostly for speech bubbles and name tags? Sounds pretty cool.

It can be used anywhere you put an object (including screen objects, images, etc). So in theory you can do map-based chat this way, although I'm not sure on the performance implications just yet.
Tom wrote:
SuperAntx wrote:
I'm guessing this is mostly for speech bubbles and name tags? Sounds pretty cool.

It can be used anywhere you put an object (including screen objects, images, etc). So in theory you can do map-based chat this way, although I'm not sure on the performance implications just yet.

Very nice Tom. I know your comment wasn't referring to me, but I can see it being useful for onscreen input if the performance is incredible. :D

Of course we'll have to wait and see to try that out.
Bandock wrote:
I can see it being useful for onscreen input if the performance is incredible.

Yes, this was one of the things which frustrated me immensely when designing the HUD chat for Decadence. It would be nice to have input boxes right on the map rather than requiring users to enter text into a little popup window.
@Bandock: Input is more complicated than output/display. You have to catch every keystroke and react accordingly, take into consideration cursor positions, have selection/copy/paste options, etc.

@Antx: You could toggle the visibility & focus of an input control over a portion of the map if you didn't want to use a text input().
Falacy wrote:
@Bandock: Input is more complicated than output/display. You have to catch every keystroke and react accordingly, take into consideration cursor positions, have selection/copy/paste options, etc.

@Antx: You could toggle the visibility & focus of an input control over a portion of the map if you didn't want to use a text input().

Already handled it for the most part through the SByIo Library V3 code (which is unfinished). If anything, I could adapt it with map_text support. :P
Falacy wrote:
You could toggle the visibility & focus of an input control over a portion of the map if you didn't want to use a text input().

That's one way of going about it, but it has its drawbacks as well. Nothing quite reaches the speed an efficiency of the ugly old input() dialog.
The HUD Groups library has an on-screen textbox control. The problem with an on-screen text box is that the control is more than just text. You need to show a background, border, cursor, highlighted text, etc.

It'd be nice if you could render interface controls within the map control. If you place a label, button, or textbox inside a map control in the interface editor, DS would just render the control's display as part of the map.
I assume this is what came out from those thousands of years of saying DMIFont-like-support will be native to BYOND.
and this feature was placed here after this post was made. EITHER COINCIDENCE, OR SOMEONE NOTICED.
It's nice to see stuff like this added. Little things with major possibilities, like this, are what the DM language needs (assuming it all performs well).
Aaiko wrote:
It's nice to see stuff like this added. Little things with major possibilities, like this, are what the DM language needs (assuming it all performs well).

The possibilities aren't too major. One map control has one font with one font color. It'd also have no support for bitmap fonts. This just covers another problem - there needs to be some capacity for custom client-side processing. Creating text is currently cumbersome because it requires a lot of objects. If each client could create and position these objects it wouldn't be a problem at all.

Instead of sending an udpate to the client containing information about 100 objects (icon, icon_state, pixel offset, etc.) just to create one sentence, you'd just send the sentence to a proc that runs on the client. The client would then create objects that get displayed like real objects, but only exist on that client. It's still a developer-written DM proc that creates the text using an object for each letter, but it's executed on the client instead of the server.

This would work well for text and it'd truly open up major possibilities. Every graphical effect that people are afraid would run poorly over the internet would instead use hardly any bandwidth at all.
Forum_account wrote:
The possibilities aren't too major.

This is just the first step for maptext, I'm sure. Once styles and what not are supported, it will open many doors.
Aaiko wrote:
Forum_account wrote:
The possibilities aren't too major.

This is just the first step for maptext, I'm sure. Once styles and what not are supported, it will open many doors.

Those additions would be useful but that's about all this feature leads to. I don't see how this would easily support bitmap fonts, special effects (ex: making individual letters move), custom symbols (ex: being able to put a fire icon in a string to indicate a damage number is fire damage).

If limited client-side processing is the goal, this feature isn't part of the path that leads there. BYOND has some features that might only do 50% of what a game developer needs, but they're implemented in such a way that you can customize them to add that other 50%. The default movement system might only be 25% of what you need, but you can override procs to change how it works. This doesn't look like one of those features. If it doesn't provide that flexibility, developers have to either take it or leave it. To create what they need they'll have to leave it.
Well, assuming this is relatively efficient, I think people will be able to make good use of it, and we can add further customization down the line. For example, I already made it so you can at least set the font/color/style of each individual maptext; you just can't do inline styles. In theory we can handle the full parsing so that it works more like the output control, which even supports inline images. A lot of games just want to put some chat text on the map and tons of formatting isn't required for that. This seems like a better compromise than using an icon-based system.

If you don't want to use it, that's fine. But please stop derailing this thread with your constant negativity.
It'd just be nice to see some more features that users can extend themselves instead of having to rely on the BYOND staff for updates. I'd think the BYOND staff would like that too.
Page: 1 2 3 4 5 6