Layer Extension

[Foen]

Just a quick post to say I've added an extension to the FG Wiki (https://oberoten.dyndns.org/fgwiki/index.php/Layer_Extension) 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.

https://farm5.static.flickr.com/4031/4449963165_77c8131b45_t.jpg (https://farm5.static.flickr.com/4031/4449963165_ffa0a27e7e_o.jpg)

[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:

https://farm3.static.flickr.com/2719/4451111304_9cb7bb219c_t.jpg (https://farm3.static.flickr.com/2719/4451111304_edfc098531_o.jpg) https://farm5.static.flickr.com/4047/4451156678_42d9b764b0_t.jpg (https://farm5.static.flickr.com/4047/4451156678_034fda3d5e_o.jpg)

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.

[Foen]

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.

Ahh, I can't test middle-click stuff, because Windows Se7en hijacks the middle click. I can put some script in to fix this, but won't be able to test it.

What is the middle-click supposed to do, exactly? Does it set the viewpoint to top-left and the zoom to 1x?

Foen

[Zeus]

No in a sense it grips the image at the pointer and allow you to move the image so I guess the viewpoint is set to the point position? Not sure. Zoom level is unaffected. Think thats registered by mouse wheel notches.

[Foen]

Should be doable, let me look into it.

[Zeus]

Cheers that would be great.

[TR0LL]

Yes great work guys! if this works out without any issues it will be amazing! Combind this with DrZeuss's Tables for a random dungeon and go to town!

[Foen]

Updated version should allow viewpoint to be changed with the middle mouse button.

[TR0LL]

Will it be possible to merge this with Image Tools? I find them very useful. (doesn't need to be done right now obviously.

[Zeus]

Yep, works for me with 4E.

Nice work Foen. I have dropped a message to Doug, Tenian and Moon_wizard
reference the feasibility of module based maps supporting pre-assigned tokens. If I hear anything I'll let you know.

[TR0LL]

I found an odd issue, I made a test tile, 250 x 800 pixels which would force all squares to be 50x50.

Now the problem is that the vertical alignment on the grid is perfect, however the horizontal alignment is 50% off as seen here.

https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/LayedMaps.jpg

[Foen]

Did you set the grid on the bottom layer (rather than the top)?

[Foen]

(From the screenshot the two layers look out of sync: look at the grid lines)

[Zeus]

I'd agree with Foen, if you set the grid on the bottom layer the top layer auto syncs and sets its grid identically.

If you set the grid on the top layer, the grids de-sync when you zoom or move the map.

Try setting it on the bottom layer as suggested, it works fine for me.

[TR0LL]

Did you set the grid on the bottom layer (rather than the top)?

Yes, and I just double checked to make sure.

Here is the token tile im using.
https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/CorridorLLeft.png

if you want to check it yourself.

could it be related so that in order to scale the token properly (50px per square) that I have to extend the map with the drawing tools, then zoom out, and this is somehow messing up the alignment?

When setting the grid, move to lower layer, and place grid there, (ive done this) is there anywhere in particular I should be starting it? or a method I should be using? Ive tried putting it in the center, and in the lower left corner, not sure if it would make a difference but its still the same.

Do I need to close the map and reopen it before I place tiles? just trying to get a process down in case Im doing something wrong.

[Foen]

Yes, I think the problem is caused by you extending the drawing area. The extension has to keep both layers in sync, and there is no method/event exposed by the FG engine to capture when the drawing size is changed.

I'll change the default drawing size to match the top layer.

Foen

[Foen]

I've aligned the default drawing sizes of the main image and the top layer, and set the window to re-synchronise the two layers when it first loads.

v0.3 is now on the FG Wiki (https://oberoten.dyndns.org/fgwiki/index.php/Layer_Extension).

Foen

[TR0LL]

The new default map size is awesome, but the problem still remains with my tile. have you tried it yet?

I make a new map, place a 50px grid, put the tile down, zoom in to make tile squares fit the grid and lock, they still don't align, always 50% off on one facing.

Ive notice that its always one facing or the other. if the horizontal is right the vertical is 50% off, and vise verse.

It isn't because of my token size is it? 250x700 pixels?

[Foen]

Spot-on!

The token is centred on the grid and your size isn't an even multiple of squares in one direction. There are two ways to get around this, either switch off the grid to place your tokens by hand (like DrZeuss did) or else change the tokens to be an even number of squares in each direction.

Foen

[TR0LL]

I chopped up my tile to do some testing, and the results were... odd...

https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/LayedMaps2.jpg

As you can see the ones in green are fine, and will fit right on any facing. the rest though are always 50% off on one facing or the other.

Edit - ah-hah! Read your post before this one, the ones that are not working are 3 squared wide... hell yeah we figured this one out!

[Foen]

To be more precise, the centre of your token must either fall in the centre of a grid square or else at a precise intersection.

Your first token (7 squares by 4) centred length-wise at 3.5 squares and width-wise at 2 squares, so the exact centre was on a border of a square in one direction and the centre of a square in the other. The same is true of the 3x4 tokens.

In summary, a token must either have an odd number of squares in both directions or an even number of squares in both directions, but not a mixture of odd and even.

This is because grid-snapping works to the centre of a token, not its top left.

If you want tokens of non-regular sizes, you can add extra width using invisible (alpha=0) pixels. These should work just fine.

Foen

[Oberoten]

... you have done it again. *headshakes* I always assumed that getting layer functuionality in there was beyond doable from a ruleset aproach.

You are a tricky one. Tricky beyond belief.

- Obe

[TR0LL]

I simply cannot express how happy I am with this solution! They HAVE to add this functionality to the core engine and if they don't I would be very surprised!

Foen and DrZuess you guys ROCK!

[TR0LL]

I made a quick and dirty test tileset.
Cloudy Gray background map 20x20 wide
and a set of simple dungeon tiles to test with.

https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/DungeonRunning.jpg

These are really simple and I only spent about 15 minutes on them, if anyone wants them I will upload them, but I do plan to make MUCH better tiles.

and here are the individual tiles.

https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/QuickTiles.jpg
Not too bad, all together the tokens are 253KB

Is there any way to disable the shadow effect FG puts on tiles? they distort the look of the dungeon sections as you can see.


Edit:
One last shot of these tiles with my newly created player tokens.
https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/DungeonRunning2.jpg

[Zeus]

After some extended use last night here's some more feedback.

If you are happy to work a pre-generated background image of say the floor and walls (as per my screenies in the other thread), the two-layer approach works very well. You can position and scale your tiles (furniture, features etc.) very easily, apply your grid and off you go. However with this approach comes the dependancy of pre-defining your room layouts before your game, which for some may not be ideal.

If on the other hand you prefer to work with only a pre-generated image of say a wall texture and use tiles of rooms (as per TR0LL's screenies), 8x8, 4x2 etc as well as tiles for furniture and features, tile deployment becomes trickier. This because your now having to apply tokens upon other tokens on the bottom layer and we all know token stacking in FG can cause issues. So I'm thinking for a true tiling capability we are going to need at least one more layer.

Ideally I think the solution would benefit by having 3 or possibly 4 layers. Or perhaps at some point in the future a dynamic ability to define any number of layers? Holding the dynamically created transparent layer controls into a table or list.

Anyhow, 3 would help as it would allow you to deploy floor tiles and then deploy feature tiles without stacking issues arising.

Layer 1 - Background Image and Floor Tiles
Layer 2 - Features
Layer 3 - PC/NPC Tokens

Is it doable?

[Foen]

Doable, but non-trivial. I'd like to think that SmiteWorks contributed to the project by fixing one or two problems with the imagecontrol so that this becomes a really useable project: it would be a shame to devote considerable ruleset development effort to a solution that doesn't quite work.

In particular, the following items would make this much more useable:

The ability to resize a drawing from code: this is doable from the radial menu, but not possible in code. Dynamic sizing of the drawing layer would improve efficiency;
A fix for imagecontrols so that they stop intercepting events when they are invisible. Currently you have to set an image control to zero size if you want to expose one behind it, you can't just set it invisible or set it disabled;
An event that fired when a user manually extended the drawing layer;
An event that fired when the user changed the image/drawing zoom (onZoom, perhaps, like onScroll); and
A fix for the sendToBack and bringToFront methods so they do what they say. Currently they only change ordering for rendering purposes, they don't reorder for event handling purposes.

In addition to these, the following would make things easier for imagecontrol manipulation, but aren't directly connected to implementing multiple layers:

Fixing the onDrawStateChanged, onGridStateChanged and onMaskingStateChanged events, as they don't currently fire. This would allow a proper implementation of the drawing tools; and
Adding an x and y argument to the onMeasurePointer event, after the pixellength argument. This would allow hex maps to show the correct distances for vectors.

While on the subject of fixes, and hot off the press from the BRP implementation, it would be great if the acceptdrop tag was fixed so that you could have multiple tags in the same window control, one for each drag data type. This used to work in earlier versions of FG, but seems to have been broken somewhere along the way. I'd love to use it to implement better equipment lists (weapons, armour, shields, items, etc).

Foen

[Zeus]

Well lets hope Doug/moon_wizard can assist. I really think this has the potential to significantly add value to the overall experience of virtual table-top play in FG.

[TR0LL]

I just noticed a problem, that I hope can be resolved.
when this extension is on the following Layer mapping features disappear.

Mask (pretty big to me)
Navigator (handy but not a big deal)

Is there anyway to get at lest the Mast feature back?

[Foen]

Hmm, it seems that masking is a bit of a problem. The layers work by placing a drawing over an image: the image is the lower layer and can contain the background. The drawing is the upper layer and is empty (apart from tokens and a grid).

The only problem is that the FG engine doesn't provide masks for drawings, so the upper layer can't be masked. I'll have to give this some more thought: perhaps the upper layer should be a blank/transparent image.

I'm not sure what you mean by the Navigator feature: what does this do?

Foen

[TR0LL]

When you turn on the navigator it opens up kind of a mini map that you can click where you what the map view to be, handy for large maps, not not a requirement.

[Foen]

Well I'm blowed, I've never seen that before! I guess it is also linked to the fact that drawings (the active layer) don't support some of the features that images (the bottom layer) support.

[TR0LL]

Well, no matter what you do, even if I have to give up Masks, I will be using this extension, it allows for the flexibility I need/want.

I beg, develop it as much as you can!

I know you get the idea but I cant help but be excited about this -

here is an example of how useful it is!

This only took me maybe 3 minutes to put together.
https://i634.photobucket.com/albums/uu64/LumberingTroll/RPG/Stuff/Useful01.jpg

As for stacking tokens on the tiles, make sure all your ground tiles are done and in place then drop a token (furniture/magic circle/pit/whatever) on an area that has nothing then drag it in place, easy as pie. - note this is all done on the lower layer, only player tokens/npcs/templates go on the top layer.

[BruntFCA]

It's great to see this, we were talking about it in tdewitt274 thread in the gallery about 2 weeks ago.

Sorry I've been out of the loop since bitdefender so called anti virus program almost trashed my computer. Nice simple tiles you have there Troll, BTW did you get the parser working in the end?

One nice addition, if we are talking about tiles, is it possible to get "animated" gif like tokens or graphics in the game?

For example if you look at the screenshot below, I've made the two braziers as moveable tokens (their traps). It would neat if there was a little fire animation on them too. This could work for all sorts of little things such as traps and blasts.

I've currently been playing with NWN to make maps fast, I got a very high
rez screen so I can print screen and xfer them easily. The little lava pits and stuff (animated) look amazing, but of course thats lost once you xfer it over.

https://img28.imageshack.us/img28/2766/hiddendungeon.jpg

[TR0LL]

ya im all set. thanks for remembering.

Also for the new layer system you can use masks and the navigator, it just needs to be done on the lower layer.

[ddavison]

Hey guys, I am just now catching up on this thread and I must say I am quite impressed -- but that is not a real surprise whenever Foen and DrZeuss are involved.

JPG has been been working on various code fixes, patching memory leaks, fixing the id overlap issue with campaigns and modules and numerous other issues. On top of that, we have some needs to re-work the XML engine a bit to make it better at handling large XML files in modules, prevent FG from loading all tokens into memory on launch, etc. The last one will really be important if you start building up large tile folders under tokens.

I think we could add in the additional events per Foen's request with maybe one or two possible exceptions. It is up to Foen and DrZeuss if they want to keep things as an extension or if they want us to roll it into the official ruleset. We would obviously like to test it out fully to make sure it holds up well when hosting a game with a full group of players as well. I have some concerns with this one if the tile tokens don't xfer quickly to all the players.

Other than that, I will make a few notes below:


Doable, but non-trivial. I'd like to think that SmiteWorks contributed to the project by fixing one or two problems with the imagecontrol so that this becomes a really useable project: it would be a shame to devote considerable ruleset development effort to a solution that doesn't quite work.

In particular, the following items would make this much more useable:

The ability to resize a drawing from code: this is doable from the radial menu, but not possible in code. Dynamic sizing of the drawing layer would improve efficiency;
this should be possible
A fix for imagecontrols so that they stop intercepting events when they are invisible. Currently you have to set an image control to zero size if you want to expose one behind it, you can't just set it invisible or set it disabled;
I don't think you want to disable the events for tokens based on visibility. It is still helpful to allow GMs to move invisible tokens around that (s)he sees but the players don't. I think what you really want is for only the tokens on the selected layer to intercept events. We would need to default all tokens and functionality to a set layer but allow rulesets to "enable" other layers I think.

An event that fired when a user manually extended the drawing layer;
doable
An event that fired when the user changed the image/drawing zoom (onZoom, perhaps, like onScroll); and
might be doable. The problem is that it will be firing a lot of events. Will the zoom factor need to be per layer?
A fix for the sendToBack and bringToFront methods so they do what they say. Currently they only change ordering for rendering purposes, they don't reorder for event handling purposes.
doable if we get the layer # feature implemented.

In addition to these, the following would make things easier for imagecontrol manipulation, but aren't directly connected to implementing multiple layers:

Fixing the onDrawStateChanged, onGridStateChanged and onMaskingStateChanged events, as they don't currently fire. This would allow a proper implementation of the drawing tools; and
doable
Adding an x and y argument to the onMeasurePointer event, after the pixellength argument. This would allow hex maps to show the correct distances for vectors.
doable

While on the subject of fixes, and hot off the press from the BRP implementation, it would be great if the acceptdrop tag was fixed so that you could have multiple tags in the same window control, one for each drag data type. This used to work in earlier versions of FG, but seems to have been broken somewhere along the way. I'd love to use it to implement better equipment lists (weapons, armour, shields, items, etc).
JPG or I will need to look into this further
Foen

[Zeus]

Thanks for update Doug, thats great news. I look forward to a tileable future. :)

As for the credits, thank you but for the record, the concept and extension for dual-layer images is really down to Foen's genius.

Having said that, it is a nice complement to be associated and hear that the UK based community contributions to FG are highly regarded. Thank you.

Z.

[Foen]

Thanks Doug, and others, I think it is a really positive sign from the change in FG ownership that the dialog between Doug/JPG and the community is live and responsive. In truth I think the list above includes some wishes, and that a good solution wouldn't "need" everything above.

resizing from code isn't needed, because a large fixed drawing layer could be used, but it seems wasteful of systems resources to chuck 5000x5000 drawing layers into every image "just in case";
the inivisibility I was talking about is when the drawing layer goes invisible, it should stop intercepting events (just like other invisible window controls stop intercepting events), not just when tokens go invisible. That said, this isn't needed, because it is possible to resize the layers;
event firing is needed, however, as the script has to keep layers sync, and anything that a user can do from the radial menu which doesn't fire an event would fail to be trapped by the script. That said, the number of events shouldn't blossom, as I think scrolling is more frequent than zooming, and scrolling already fires events;
sendToBack and bringToFront aren't strictly needed if I continue to use the resize-to-zero method for each layer. It is a shame they don't do as documented, however, as that would be useful in other contexts too (RMC ruleset would have made use of this for the tables, but it didn't work as expected);
The onGridStateChanged event actually seem more important than I first thought, because they would allow changes to the grid on the top layer to be caught and reflected in the lower layers. Currently the grid changes are only propogated when the active layer is changed;
As TR0LL has pointed out, the lack of masks for drawing layers is also a problem, and that seems more problematic than some of the above; and
The rest isn't needed but is more nice-to-have.

What this extension provides is a method for managing layers without changing the basic engine mechanics, beyond those outlined above, so there isn't a need to create a new layer# approach. I'd be delighted if this were folded into core rulesets too, though it probably needs to be an option/preference because it otherwise adds extra complexity to every image when it might otherwise be used only but a subset of GMs.

I'll start work on a multi-layer version, as suggested by DrZeuss.

Stuart

[TR0LL]

Just wanted to add that the current state of the layer system works well with multiple people connected, I had 4 people connected and showing them the tiles and we had zero problems and no delay in the display of said tiles/maps. Its awesome to see that this will get more attention and I cant wait for it to be fleshed out. FG2 was one of the best purchases I've made in a while!

[ddavison]

Thanks for update Doug, thats great news. I look forward to a tileable future. :)

As for the credits, thank you but for the record, the concept and extension for dual-layer images is really down to Foen's genius.

Having said that, it is a nice complement to be associated and hear that the UK based community contributions to FG are highly regarded. Thank you.

Z.

I was mostly referring to your nice additions on the Party Sheet for 4E and the other things you've been sending me screenshots of. But for the record, the UK community is very well represented I think.

[Czarisyn]

what would be extremely awesome is to add an interactive layer.
The DM places a layer on the map that outlines walls, doors, traps, and light sources

So, say the players are running in a dungeon with only torches as their light source, the layer will only illuminate the map to only what their light source lets them see. If they come to a door and open it, the light source bleeds through the door, but not the wall.

I know its far fetched, but remember everything that is made today once came from someone's dream.

[Zeus]

I was mostly referring to your nice additions on the Party Sheet for 4E and the other things you've been sending me screenshots of. But for the record, the UK community is very well represented I think.

My bad. Cheers.

[Callum]

Hmm, it seems that masking is a bit of a problem. The layers work by placing a drawing over an image: the image is the lower layer and can contain the background. The drawing is the upper layer and is empty (apart from tokens and a grid).

The only problem is that the FG engine doesn't provide masks for drawings, so the upper layer can't be masked. I'll have to give this some more thought: perhaps the upper layer should be a blank/transparent image.

Does this mean that masks can't be used at all with this extension, or only that the upper layer can't be masked? If the latter, then isn't the main functionality of masks maintained - hiding and gradually revealing maps?

[ddavison]

Hey guys,

Be sure to check the laboratory notes here: https://www.fantasygrounds.com/forums/showthread.php?t=12497

I believe all the requested events have been added.

[Zeus]

Yeah I did notice the LUA enhancements, thanks for that. I will get to it (at some point), promise.

Right now I have a list as long as your arm of checks and changes to make to all the extensions I have recently released for 4E, following the monstrous update from you guys.

This on top of map, map and more map making for H3 and two parallel running SoW campaigns, sheesh. I really need to find a game to play in as a player for a change :)

And pulling together a nice little standalone .NET app (FGII 4E Module Tools) which makes short work of module text production for 4E.

I need sleeeep.

:cry:

[Tailz Silver Paws]

Just thought I would pop in and say a few words. I've been thinking that some kind of "layers" for FGII were needed for a while now, great work to see you guys putting in the hard yards on that. I look forwards to seeing how your layers feature turns out.

If I might add... maybe the functionality of the layers, the user friendliness, would be enhanced with some kind of "Layers Pallet" or a little panel that displays which layer is currently active? Sort of like how Photoshop uses layers?

Just my 2 cents...

[TR0LL]

Looks like Im necroing this one, but I wanted to ask has the development of this gone anywhere? Ive been away dealing with college and my third child was born about a month ago.

[StuartW]

My coding time has practically vanished, so I haven't been able to make any headway on this. Sorry.

Congratulations on your new child!

Stuart