RPTools.net

Isometric Maps and New Token Types
You may have seen that there is a reasonable amount of work going on developing Maptool 1.4 and one of the new feature of Isometric maps has reached the point where it would benefit greatly from testing by people other than the developers. What we are making available here, is an early beta and there will almost certainly be bugs that need addressing as well as areas of functionality that we haven't started work on yet. However it would be great to see what people can do with the functionality developed so far, whether or not the community thinks it worthwhile, and if so, what areas need developing. With that said, this beta release adds the functionality described below. Please play, and provide as much feedback as possible.

cheers,

Jagged




Functionality
Isometric Map Grid

• A new "diamond" style grid that is twice as wide as it is high. This is not "true" isometric drawing with 30 degree angles, but approximated isometric, often found in computer games.
• Tokens are automatically stacked so tokens in the forefront are stacked above those in the background.
• Vision and Light areas are adjusted for the isometric grid.

Figure Token Type

• Added a new Token type called a "Figure"
• Figure token images are only contained by the width of the cell, unlike other grid types, where the token is contained by both width and height. When the token image is taller than the cell, it extends out the top of the cell.
• If the token image extends out the top of the cell, it is not clipped by the vision blocking layer or by fog, if the centre of the cell can be seen.

Token Image Tables

• Added a new token property called an "Image Table"
• The image table must be a table in the campaign and should contain values from -180 to +180
• When the facing is set on a token with an image table, the returned image automatically replaces the default token image. This can be used to give the appearance of three dimensional rotation.

Preferences

• Added a new option to the token preferences that forces the display of token facing arrows, regardless of whether the token has an image table or is a top down token.

What is NOT Available

• Needless to say this is not true 3D, only fake 3D. But I don't expect that to hold you back.

Download
Now available from the official download page!
An Example map - 07/11/2015 Inspired by the Dyson’s Dodecahedron Blog If you don't fancy downloading stuff from someone you have never heard of before (and I wouldn't blame you), you can download the source code from Github here (Branch:Isometric Tag:Iso_test_2 ).

The previously released beta are still available if required but you should download from the main link above.
Windows Zip - 15/06/2015
OSX Zip - 15/06/2015

Isometric Map
The isometric maps produced by this release are not true isometric and are instead a form of map often used in computer games where the height dimension has half the scale of the width. The reason this has been adopted is because it makes it easier to map a square grid onto an isometric grid and for the ease of image conversion. When setting the size of an isometric grid, the number you enter is used as the height, which is the shortest dimension. The width will be twice that value. The coordinate system used by the isometric grid system, imagines that the grid was a square grid that was rotated and tilted (foreshortened). Therefore X and Y coordinate values are based upon the diagonal position, rather than the horizontal and vertical position.
Figure Token
Figure tokens are a new type of token designed to be used in conjunction with isometric maps, but will work with all types of map. The Figure token is designed to mimic the behaviour of a table top miniature when placed upon a map. A Figure token differs from other tokens in the way the token image is resized, how the tokens are stacked on top of each other and how the token is displayed when partially obscured by vision and/or fog.

Figure Token Image Boundary
The most obvious way a Figure token differs from other token types in the way the token image is adjusted to fit the map cell. For normal tokens of standard "medium" size, the token image is scaled to fit within the boundary of a single cell. So if the token image was 200 wide by 400 tall, and was dropped onto a 50 by 50 square grid, the image of the token would be resized to 25 wide by 50 tall. However, if the token was changed to a "Figure" token, the image would be immediately resized to 50 wide by 100 tall and would "poke" out the top of the cell. If you used a square image as a figure token, you would not notice any difference when placed upon a square grid map, but is placed on an isometric map, it will appear to pop out of it cell.

Figure Tokens Stacking
Another way Figure tokens differ, is that they have their own rules about how they appear in the Z-Order i.e. when they overlap, which should be on top. To attempt to represent a 3D view, Figure tokens will always place the token that is in the foreground, on top of a token in the back. If two tokens are at the same position in the foreground, the largest token will be pushed to the back. If they are both at the same position in the foreground and of the same size, then normal Z-Ordering will apply. Figure Tokens and the Vision System
Another important feature of Figure token, is how they behave in the vision system. Figure tokens can extend beyond the bounds of their cell but the rules for whether or not you can see a Figure token are based entirely upon whether or not you can see that cell. In the example below, the top of the figure token stretches into area that is hidden by the vision blocking layer. However, because the player (the character with the staff) can see the cell the figure is standing in, he can see the whole of the figure. If a player can only see a small part of Figure token's cell, it will behave like any other token and will be clipped by line of sight, but if the player can see approximately half of the token's base, then all will be displayed. As shown in this example with Fog of War. Token Image Tables
Token image tables are a new feature that work with all token types but are designed specifically with Figure tokens in mind. Token Image Tables give you the ability to use different images when the token is facing different directions. This gives you a simple way to give the appearance of 3D.

To use this feature you must first create an appropriate Table. The Roll value for the table needs to match possible values returned by token facing which go from -180 to +180 and so should use "1d360-180". The range values should then match the appropriate arcs (such as 0-90 for facing North East). The images used in the table need to share the same dimensions as each other, and ideally of the token's default image, otherwise there will be a juddering effect as the images are switched.

Some example table range values:
Table Ranges for 4 Directions: Table Ranges for 8 Directions: You will notice that with this table, "West" had to be split, and appears twice.

Once the tables have been created, they can be selected as part of the Token Configuration. One that has been done, when you assign a facing to the token, the default token image will be replaced with one from the table instead. It is important to note, that if you save a token, the Image Table is not saved with it. They can be exported separately though. Example tables can be downloaded and imported here 4 Direction Table and 8 Direction Table

Converting Plan Images to Isometric
Example using Bogie's Sorceress Tower map and starting from a square grid for demo purposes:

1. Drag your image onto the Object or Background Layer of your map.

2. In this case since the image is designed for 200 pixel squares, turn on "Snap to grid"


3. Edit the map and change it to Isometric grid.

4. Right click the image and select "Flip" > "Isometric Plane"


5. Position image:

Looks good so far, but I haven't fully tested. Also, I noticed we lost a feature awhile ago and since you're poking around this area I was wondering if you can fix it again.

When moving a token on the token and object layer it jumps around unevenly because of snap to grid. So, to move it up or left I just have to move it 1 pixel, but to move it right or down I have to move it a full grid square (50 pixels).

The last time this worked correctly was back in b87, although the object layer still had this feature/bug. I know with tight vbl maps this causes some problems and confusion.

aliasmask wrote:When moving a token on the token and object layer it jumps around unevenly because of snap to grid. So, to move it up or left I just have to move it 1 pixel, but to move it right or down I have to move it a full grid square (50 pixels).

I had noticed that and was relieved to discover it wasn't something I had introduced I shall see if I can find a solution.

OK, did some testing, only found one bug, one quirk, and some usability suggestions.

1. Bug

Zoom bug

tile-zoom.jpg (279.68 KiB) Viewed 9863 times

Ok, so I set an Isometric tile as a background texture. When I zoomed in/out the graphics didn't clear, unless I changed the window size (eg maximized window)

On a similar note, is it possible to properly tile an isometric image? I find the issue being an isometric image trapped in a rectangle image coordinates. How do you resolve this?

Tiles

tiles1.jpg (77.5 KiB) Viewed 9863 times

2. Quirk
In the sample map, I placed a tile (red arrow), when I rotated it, it rotated at 45 degrees and wouldn't rotate back to it's normal view, I had to rotate it with the shift key to get it back to a 90 degree view.

Also, when I placed a character image (blue arrow), and changed it to figure on the token layer, it seemed abnormally large? Figure selected is currently set to "small" and still 3 grids tall?

Sample Map

docks.jpg (266.08 KiB) Viewed 9863 times

3. So, some other things to note:
a. It was fun to play with, making this sort of map!
b. I was using images from the Shadowrun PC game (all images are stored in game in a directory as png's!) but noticed image sizes where not consistent. Even tile to tile the image size in pixels where not all the same. Not sure what the best way to resize them so things snap to grid better?
c. I highlighted in yellow the results of having to manually line tiles up, it wasn't easy... Again, more of my library of images than anything, but it will require some Forum threads probably on how to adjust images to grid sizes type tutorial eventually.
d. In placing images, I found I had to constantly "send to back" or "send to front" images to place things correctly. I was trying to think if there was an easier way. Maybe a toolbar toggle to change the default "z-order". ie, toggle a button so images are dropped to the back of the map vs the top/front of the map? That way you can build your iso map from top to bottom or bottom to top.

There also were a couple of time where it seemed that "send to front" didn't work and I would have to cut and paste to get the image to be placed on top again.

Otherwise, things seemed solid. I didn't get a chance to play with VBL or use the map, but in building, nothing horrible happened and nothing seemed to break.

Thanks for testing!

I haven't seen the problem with the background tile before. I guess that's because the system doesn't know how to tile with an isometric tile. You need to convert it into a square tile. I suspect the areas of transparency are what's causing the issue.

With regard to the height of some of the figure tokens: to control the height you need to pad out the width of the image. Although you can always adjust the size of the image from the Token config tab. Zooming in and out with the mouse wheel seems to work for me

Not sure about the Z-ordering problems, I've only altered the Z-Ordering for Figure Tokens. Everything else should be as it was before. Were you having problems with Figures or background stamps?

Glad you were having fun

You can use this as a guild for building figures. It's a psd file.

re: z-order, it was all object layer.

Let me know if you cant duplicate the zoom bug.

Regarding tiles, the problem is you would have to create the tile in such a way that it overlaps into the cells around it, which seem a pita. Should tiles be created skewed to fit a square and let MT skew it for Iso? How would you create an isometric wood tile otherwise? Not sure if this is an MT issue or Image issue?

Would it be possible to tell MT to set a texture image for tile an constrain it to x by y cells and to allow overlap?

I tried skewing my own tiles and it's not an easy job. It would be nice if the texture drawn by the iso draw tool would skew the pattern for me.

Have you tried taking a square texture and using the token config to set it to square? That should make the system skew the tile appropriately. Obviously not a great solution as you would have to copied it loads of times. Although, I think I have only set that up to work with Tokens, so I imagine nothing will happen on the object layer.

Currently when you drop a square or circle token onto the token layer it gets automatically skewed for the isometric plane. I had been thinking about changing this from automatic behaviour to a universal function like "flipping". I think this would be far more useful. Its really helpful seeing other people use your stuff, it makes some design decisions really obvious

JamzTheMan wrote: 2. Quirk
In the sample map, I placed a tile (red arrow), when I rotated it, it rotated at 45 degrees and wouldn't rotate back to it's normal view, I had to rotate it with the shift key to get it back to a 90 degree view.

I bet that was due to the behaviour I have currently programmed for Square and Circle tokens, which means they get automatically skewed for the isometric plane. I bet if you change the type to "Top down" it will revert to more normal behaviour.

Anyway, after listening to your feedback, I am going to change how that works, and make it more of a choice.

I've been playing with how Figure Objects might work (not added any object specific behaviour yet).

Here is an example of a Door as a figure token. It has been size a "Large" size (so 4 cells) and has be positioned exactly on a vision blocking line. Because Figure tokens are shown completely when a player can see just under half the base, the door appears when the player can see the appropriate cell. So this might work quite well, when applied to Objects.

So on that note...Would it make sense to restore the old logic on a per layer basis? ie Keep the 50%+ to view tokens, but on the object layer, show the whole object if you can see any part of it?

It sounds like we're trying to keep the mystery for NPC/Monsters hiding around corners, which is great, but is there any reason to hide doors, walls, buildings, etc? Or maybe only the background layer shows all?

Or is that what you are doing?

JamzTheMan wrote:So on that note...Would it make sense to restore the old logic on a per layer basis? ie Keep the 50%+ to view tokens, but on the object layer, show the whole object if you can see any part of it?

It sounds like we're trying to keep the mystery for NPC/Monsters hiding around corners, which is great, but is there any reason to hide doors, walls, buildings, etc? Or maybe only the background layer shows all?

Or is that what you are doing?

I haven't done anything with the Object layer yet, I will probably just replicate the Token logic first, to see how that works. But I will certainly consider making visible objects appear, I wonder how that was coded?

ps: You might find it worth downloading the Beta again, since I have added a "Flip" > "Isometric Plane" function.

Here are a few iso figures to test Jagged iso Maptool. More to follow.