Layer Extension

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

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