Layer Extension

[Foen]

Just a quick post to say I've added an extension to the FG Wiki that allows maps to have two layers: one for placeables; and one for standard tokens.

The GM can toggle between the two and hence can move the placeables, but players can only ever interact with the standard tokens. This would also enable dungeon tiles to be used, although I guess that GMs would need to keep an eye on token sizes.

The extension isn't perfect, and in particular:

• Any attempt to zoom the maps using the scroller and the control key will get the two layers out of sync, so zooming should be performed by the using the mouse wheel; and
• The extension uses a fixed size for the top layer (5000 by 5000) because FG doesn't expose a method to set a drawing size dynamically. This means that images load a bit more slowly and that the extension only works with maps that are equal or smaller than this.

Use of the extension should be fairly self-explanatory, and it has been designed to be generic. That said, if your custom ruleset already makes changes to the imagewindow window class, it will be incompatible with this extension. Hence this extension is not compatible with the Image Tools extension (because they both modify imagewindow).

I've only given this a cursory test, so please let me know if you have any problems.

Foen

[Zeus]

Now that could work quite well. I might just have to have a play with this when I can get some free time.

I have already built the digital versions of the DU1-DU4 D&D Dungeon Tile sets, I hand scanned my personal sets for hi-res digital versions. With the hard work already done, saving off some reduced size versions for use in FGII shouldn't be a problem.

Having this ability in 4E would be useful for on the fly dungeon delves, my group always wonder off course and I am always having to search (last minute) for a random map to host an encounter.

I'm thinking if I reduce the overlay size a little, say to 2000x2000 px and limit the underlying images to 2000x2000px, each image should be more than sufficiently sized to host a single area. I could then integrate this extension with your Atlas extension to create a linked tile based map capability. Each encounter map would be limited in size but I think this would be best for maintaining fidelity and shorter load times.

I was also thinking of perhaps adding a radial command to the top-level image layer to add tokens for all current entries in the CT to the map. This would make it faster to deploy for each encounter area.

[Zeus]

OK as a PoC for 4E, I quickly exported a handful of my hi-res DU1 tiles and images as PNG 50px tokens and created a simple 1000x1000px basic dungeon tile map in Photoshop with some walls using custom grey/black/blue fill textures and masking. A very simple approach with the intention of quick turnaround time for basic floorplans - 5-10mins per encounter area.

Then in FGII I simply populated the map (standard image) with required tokens for doors, furniture and features and viola a pretty decent encounter map. The background image (floor and walls) came out at as a 230Kb JPG in size and the tokens are on average 30-75Kb each so pretty manageable.

Connection time was pretty decent 5 secs for the map and about the same again for the tokens but then again I'm on a fast GigE network with a local test LAN client. The true test I guess will be will be 3-4 internet connected clients which I can do next week during one of my real games. I'll update this therad with how I get on.

The only issues I can see is that FG applies a slight drop shadow to tokens and so some tile elements look slightly off as a result (see the rubble as an example).

Overall though I think its worth investing some time in integrating Foen's new layered image approach so I'll have a play and report back.

If it works as well as I hope it will I can look forward to a new way of building my D&D 4E maps.

[Foen]

Did you run this using the extension? I can't see the layer toolbar in your screenshot, and I *can* see a close box.

[Zeus]

No this is just the regular 4E image window, I wanted to see how practical the process would be and how quality and number of tokens would affect performance.

Next step will be to integrate your layers and atlas extension code.

[Foen]

I just wondered if you'd given it a try, as it should be useable with the 4E ruleset as it stands (albeit without a closebox and any other 4E-loveliness), just to see if it works how you'd like.

[Zeus]

Yeah I will do, I just need a bit of time as I am juggling some other code fixes to other extensions I recently made available.

I assume the only visual difference I will see from the image in the screenshot when using your code is that the FG grid will overlay the underlying tokens (not PCs, NPCs) etc. and of course any toolboxs you have added. Which is fine.

Rather than use this 'as-is', would it be OK to adapt and integrate it with your Atlas code. The integration would be 4E specific. Would you be OK with this?

As per the Partysheet extension I'll happily apply an acknowledgment and credits for the original code.

The only real challenge I forsee is whether we can tweak the 4E ruleset to accept module based maps with pre-assigned tokens. Or whether FGII itself constrains this capability. In either case without the ability to load a module based image with tokens pre-assigned it might render the approach constrained to campaign based images only which may not be ideal for many GMs.

[Zeus]

I just tried it quickly but I hit a few of challenges:

i) If I set the grid on the top layer as I believe is intended, setting the grid is difficult as the green marker box renders offset to the pointer and not directly underneath as it's supposed to be.

ii) If I zoom in on the top level using my middle mouse scroll wheel to set the grid, all is fine, however as soon as I zoom out again the grid becomes miss-aligned.

iii) I have to re-export my tokens again to a smaller real size as without a grid on the layer underneath I cannot scale the tokens to match the scale of the PC tokens. This is workable but I would prefer it if we could link the scale of the two layers to the grid size of the top layer.

[Foen]

You can set the grid on the lower layer, and it replicates on the upper one, so that should help the first question, although I'm not sure why that offset behaviour happens (it is only a drawing, after all).

If zooming isn't working, it may be because the upper layer size isn't big enough, or because you are using this with a previously opened image which didn't save at 1x zoom. I should be able to fix this in code.

I think the first point answers your third question.

Please let me know if that helps or not.

Foen

[Zeus]

Ah Ha.

I set the grid on the bottom layer, switched to top layer added a PC token, adjusted the scale I wanted. Locked token scale.

I then disabled the grid, and switched to the bottom layer and began populating my encounter area with furniture doors etc. Then I re-enabled the grid and switched to the top layer.

Here are the results:



As can be seen, top layer tokens do not cause a problem when stacked on top of the lower layer tokens. And all tokens are scaled atomically. Exactly what I wanted.

Now all I need to do is figure out how to integrate your atlas code and how to overcome module based maps with pre-assigned tokens.

Good work Foen.

Edit: One thing I have noticed, re-positioning the viewpoint via middle mouse button moves the top layer only and not the underlying image, result is de-synced top-layer. You have to remember to switch to the image layer to use the middle mouse button.