[Run-on warning] Guess who just spent the last, oh... I don't even know how long, coding a map screen chat system from scratch, uploaded it as a demo, waited patiently for some review, only to learn, just moments ago, that maptext is an atom variable now, and I just wasted all that time working on a slick new feature that has become obsolete before it was created. The same thing happened with my isometric library. As soon as I got some functionality working good, Lummox ups and blesses us all with isometric maps, making all that work that summer moot. In fact, the same thing happened with my pixel step library. Not long after showing it off, Lumms does me dirty with pixel step support.

Did I wrong you in a past life, JR? :P

So, I need to know what I missed. What's new? Before I go rewriting that ray tracer, any plans for that? Should I stop now? How about the Markov chains and Perlin noise libraries I have kicking around? I really don't want to waste my time again reinventing the wheel. :/

Don't feel bad, I was actually working on map screen (onscreen) input just before maptext was implemented.

As a matter of fact, you can still implement it. Heck, it's definitely better now thanks to the Any macro introduced just a couple years ago now (which can be linked up with a procedure). No need to setup overly complicated macro systems (which my input system used).
I do have map-based input in my demo. Maybe it's not a complete wash. :P

I did see the new Any macro when I was working on it, but decided I didn't want to write a keyboard event handler just to put some chat on the screen, so I opted to create individual macros for each character key, enter, backspace, the arrows, and uh... that's it, I think.
One thing I saw in a game that blew my mind. In Eternia, you can zoom in and out of the map. It's super slick and shiny, and I have absolutely no clue how they did it. Seems impossible with my current, outdated, understanding. I don't see any zoom var on these atoms. Any ideas, or is it a trade secret?
In response to Xooxer
This is most easily achievable by creating a PLANE_MASTER (that's an appearance flag) for a plane and applying transforms to it when you mousewheel up and down.

To get started, try something like the following:

src.myMaster = new/obj/planemaster
src.client.screen += src.myMaster
animate(src.myMaster, transform = matrix()*2, time=5)
plane = 1
plane = 1
screen_loc = "1,1"
appearance_flags = PLANE_MASTER

Which produces the following result:

Woah. Planes, huh? And this vis stuff. Fascinating. Thanks for the demonstration. That is neat as hell.
Reminds me of that time I made a complicated system of chat channels and image objects to get team chat on the map screen and then maptext came out and you could remake the whole thing in 15 minutes. And it would run faster.
Pretty much what happened, nearly word for word.
In response to Xooxer
Xooxer wrote:
Woah. Planes, huh? And this vis stuff. Fascinating. Thanks for the demonstration. That is neat as hell.

The thing that'll really blow your mind, is the ability to create hierarchal entity-component setups using vis_contents. It makes designing HUD widgets an absolute blast.

You can do panel masking

Resizable widgets

And with some fuckery, I even got text boxes working pretty reliably
In response to Xooxer
Xooxer wrote:
Pretty much what happened, nearly word for word.

Now thereís a name I havenít seen in a long time.