Layers: One above tokens

[trevor]

It's not so much a java problem as a modeling problem.

We can't use raster images (pixel-for-pixel) images to store the drawables, that would use excessive amounts of memory, and would drastically slow download times.

Instead, we use more of like a vector-like method to store what's been drawn. That is, there is actually a Drawable class that is extended by the various tools. The map contains an ordered list of Drawables, one list per layer. When a part of the map draws, it starts at the bottom and renders them in order to the top.

Technically speaking it would be pretty easy to make them work similar to vector programs where you can select , move, modify and delete them individually.

Then comes the eraser. The way the eraser works is by creating an "erase" drawable, which is just a regular drawable with an "erase" flag on it, which makes it erase instead of draw. This essentially cuts out a hole in the image that has been rendered up to this point.

So, if you have a rectangle, then cut out a circle in the middle, you'd have a nice rectangle with a see-through hole in it. This is where the problem comes in. The rectangle is a whole object, rendered before being punched out. If you select and move the rectangle, the erased inner circle is not moved. So what you end up with is a full rectangle again, and a magical "hole" that will punch a hole in any other drawable that sits underneath it that is moved over it.

One of the reasons we opted for raster vs vector drawing is because it's simpler to use, and we wanted the tool to be accessible to those who don't have a great grasp on working with graphics programs that use vector graphics.

[ego093]

...and we wanted the tool to be accessible to those who don't have a great grasp on working with graphics programs that use vector graphics.

The problem with this is that most vector drawing programs have settled on certain conventions that make a lot of sense, and not just within an illustration or design context. I wouldn't and don't use the current drawing tools because they attempt to break those conventions without any good reason. Case in point: erase objects. In most drawing programs, when "erasing" from a polygon / spline, the resulting object is recalculated so that moving it is still possible. I'm imagining the reason for your erase objects had to do with undo, but they just don't make sense when it comes to trying to create complex objects using the eraser.

What I would really like to see is a move to SVG rendering and the ability to import SVGs as maps / mapping tiles. I don't want to have to draw a map in MapTool - I want to be able to use Inkscape to create a visually rich environment using powerful tools that make sense. If MapTool looked for layers with particular IDs for special content (auto FOW, LBL or the location of the token layer), then we'd have the perfect level of integration.

For people new to MT, you then provide a quality collection of pre-built SVG tiles that can be dropped into place to quickly build out a dungeon. Using SVG filters you could get some amazing looking tiles that take no time to download and keep the pace going.

I understand that some people play in sessions where they're creating a dungeon on the fly and so they'd like to be able to draw out regions within MT. Keep the basic tools you have and make them work within the SVG framework.

[Full Bleed]

I've been thinking about this a little bit, and was wondering if perhaps a distinction should be made between Layers and Levels? This would aid in making sure that maps were built in a uniform way.

That is, Layers, as they exist and are grouped now in MT, could equate 1 Level. A new Level, could consist of its own relatively independent group of layers.

The primary consideration would then be setting how the tokens and objects on each Level interact with the levels above and below.

[trevor]

That could work. Create logical groupings of tokens, that could then be ordered.

The key would be that tokens could only be a member of one group at a time.

[trevor]

This would be above the background layer but below the token layer and allow for standard GM things like secret door markers, notes and traps. Everything on it is invisible to players. Is this what's being proposed?

This has been implemented for 1.2b18. Note, you can't change layers once it has been draw (although I could imagine this being a feature sometime).

I imagine you could use it to indicate useful information to the GM.

Hmm, now that I think about it, I could easily put stamps on the GM layer, and make it easy to change layers from GM. The trick is making it obvious that only the GM can see it.

[mosat]

This has been implemented for 1.2b18.

Yippy!