Add 'Implicit Lights'

[wolph42]

Is your feature request related to a problem? Please describe. The problem is that EVERY light source needs to be defined in the campaign properties. This has the following issues:

• hard to transfer to another campaign
• always visible to players (e.g. the source 'glowing dragon eyes' might be something you don't want to show
• light sources are not 'self contained' (like tokens)

Describe the solution you'd like Add the option to the token editor to set an 'implicit lightsource'. That is a text field where you can enter e.g.: Dragon Eyes : cone arc=70 30.5 122.5#000000 this makes it easy to create specific lights AND to export import specific lights AND export import maps without worrying about the light settings in the campaign properties.

Describe alternatives you've considered none

Additional context suggested spot for the lightbox:

[Phergus]

See #331.

[melek]

Would this make it possible for lights imported via the the Universal VTT format to work out of the box, at least in a limited way?

[Phergus]

@melek Yup.

[FullBleed]

Totally for this.

[wolph42]

See #331.

I wasn't aware of that. Thats also useful, but this is another approach and I would state that both methods are useful

[BlackwingNL]

Tokens can contain more than one light now, which may make the suggested location less ideal.

Perhaps having them listed and manipulated through the menu is a more natural option, with options to add, edit and remove an implicit light, and the menu listing all implicit lights currently on the token. In the UI mock-up below I have also shown the actual light specification between brackets after the name of the light, to make it easier to see what the light actually is.

The proposed dynamic functions are still valuable too, but I think a lot of users would benefit from this being accessible through the UI.

As for the name "implicit" that's just the term came to mind last night when testing universal VTT import from Dungeon Alchemist with Wolph42. The best name for it may be individual or dynamic or something else completely

[Phergus]

See #331.

I wasn't aware of that. Thats also useful, but this is another approach and I would state that both methods are useful

Not really another approach. You're just describing a specific user interface element over what has to be implemented to make it happen. The goal should be to achieve the following:

1. Automatically create light sources on import of a Unversal VTT file that includes them. Really need to enhance the importer so that you can enable/disable the import/creation of Lights and also the Object LOS blocking in UVTT files. With the additional of Terrain VBL, the Object LOS blocking needs to get turned into Terrain VBL.
2. Provide a GUI interface (edit token dialog/context menu) to add/define lights on the fly for tokens.
3. Provide a macro interface to add/define lights on the fly.

As @BlackwingNL says, tokens can have multiple lights on them so that would need to be handled whether in the Edit Token dialog or via a fly-out menu.

[BlackwingNL]

All 3 goals listed by @Phergus will need the Light itself to be implemented first. To achieve that the current Light needs to be adapted with (as far as I can see):

1. The type distinction between a regular light and this new type light
2. A location where to store these lights.

As for 2: As I understand it, tokens don't actually contain a light object, but only a reference (GUID) to a light object in the central list of light sources. These light objects only exist in a campaign, not in an exported map or a saved token (!). This significantly limits the portability of lights through maps of tokens but that's a different issue. So for these implicit lights a light object has to be created and stored somewhere so it can be referred to by the token in the same way and current functions that interact with lights need to be able to find these implicit lights as well.

One option would be to still store them in the campaign with the other lights, just hide them in relevant places (in de campaign properties dialog, and the light menu when the token does not contain that specific light). Outside of the UI this would mean the rest would be pretty much transparent for the light functions.

A second option is to store them on the token that also has the reference to it. This would mean a bit more work for the light functions but makes these lights more modular and able to be saved with a map or token.

[Phergus]

Tokens actually have a list of AttachedLightSource objects and each of those have a GUID reference to a campaign-defined LightSource object that contains a list of Lights that make up the LightSource.

So there is a pretty good starting point to having self-defined lights as part of a token.

[wolph42]

@Phergus that makes total sense. @BlackwingNL i like the mock up, that indeed makes better sense...and I assume you're the 'blackwing' that actual came up with this idea of implicit lights?

[BlackwingNL]

@wolph42

..and I assume you're the 'blackwing' that actual came up with this idea of implicit lights?

from the same post with the mock-up in it:

..last night when testing universal VTT import from Dungeon Alchemist with Wolph42.

So yes, I'm him ;)

[kwvanderlinde]

I've been working on this concept through the sister issue #331. I won't be dealing with the UI for now (aside from basic right-click support), instead focusing just on macro function support.

This is the approach that seemed most natural after playing around with it for bit:

1. Allow defining any number of light sources on tokens in addition to the campaign.
2. Allow toggling token lights sources by name, just like for campaign light sources. I.e., via the right-click menu or setLight() function.
3. When a token light source is toggled off, its definition sticks around on the token rather than being dropped.

And for this FR, I would add a point (4): editing token light sources should be similar to editing campaign light sources. I.e., via our lighting DSL right now, and via some improved UI when we get #4088.

End result is that these token-specific light sources would be identical to campaign lights except for where they are defined and some other minutiae. I believe this will accomplish any stated goals (UVTT support, keeping lights secret, enabling specialized lights, etc).

Any feedback, especially on what we should call these lights, would be appreciated.

[bubblobill]

Having just read this, it jumps straight to an overcomplicated implementation of something people have been asking for for a long time. Whilst it may be nice to have transient light sources, surely we should first have put in place;

• createLight,
• removeLight, and
• updateLight,

that update the campaign.

[cwisniew]

Having just read this, it jumps straight to an overcomplicated implementation of something people have been asking for for a long time. Whilst it may be nice to have transient light sources, surely we should first have put in place;

• createLight,
• removeLight, and
• updateLight,

that update the campaign.

I know we haven't been doing it this way in the past but I have been trying with my additions to follow it, my preference going forward is to do it via the UI first, macros can follow. UI makes it available to more people and you can change it based on feedback, macros functions are hard to change without breaking people's macros so should probably wait until the feature is ready and has feedback.

[kwvanderlinde]

I will at least add a UI for this so it isn't only macros. Will keep this in mind going forward.