Closed lupestro closed 2 years ago
Agreed, maybe this helps: https://github.com/PhilippeKr/TorchLight I like the concept of different buttons for the different types of light sources - or if you only want one button, the player should be asked which light to produce. Also, currently if a player has the light and dancing light cantrip only the dancing lights are produced - this realy should be a player choice.
Interesting - I was thinking more along the lines of "if what you've got is a candle, light the candle - if what you've got is a lantern, light the lantern." For non-magical light sources, in many cases, this should suffice, although I've toyed with the idea of a second button for the "lower/raise the hood" of a hooded lantern, if that's what you've got.
The premise of Torch is that it is the actor's token that is the light source, in proxy for some carried item. This kind of sets it off on the wrong foot for more clever scenarios, as you can set a candle or a lantern down in the middle of the room or place a torch in a sconce on the wall and benefit from its light, something Torch can't model. (The same issue applies for the Light cantrip.)
So, even before we get to supporting a single token with multiple available light sources with more control than a priority list, I'm wrestling with whether Torch's basic premise is sufficient, or if we want to allow for the separate tokens similar to Dancing Lights for more token types. If we aren't going to do the latter, then how fancy do we want to get with detailed control of basic character-token-based lighting?
@spirritus Here's a thought - if you are carrying more than one recognized light source, Torch could give priority to the light source you've equipped vs something in a container. I'll have to look up the data representation of something being equipped vs in a bag, though. Maybe Torch is already only looking at equipped gear, in which case the selection issue is already solved.
For some character classes, we can give priority to prepared spells, but I recognize it isn't a satisfactory general solution there. Support of more spells, support of Light as separate from actor token, spell selection, will need some thought. Maybe the spell side belongs in an effects package for spells rather than something totally light-focused.
I've got something in the works to let you choose among the light sources in your inventory in DnD5e using a right-click for a context menu appearing below the flame icon. It handles the tri-state nature of Hooded Lantern and the narrow beam of Bullseye Lantern. It makes no attempt to set light color, intensity, animations, etc., but it could in the future. We continue operating in the general "carried light source" manner, all least for now.
What I have will appear around the time of v10 and may have a few enhancements over the work I did this weekend. I'd like to deal with placed light sources but there is more to work out for those. I don't intend to deal with spells at levels that can be consumed (so nothing beyond cantrips) or spells with other effects. There are other modules for that kind of stuff.
Is it possible to save the configuration of the light sources, especially Light / Dancing Lights spell? Currently the Dancing Lights' colour is set to black with a 1.0 intensity so it's barely distinguishable from the fog of war. The issue that I see is if I (the DM) have to customize each of the four dancing lights to a yellow colour and a lower intensity but only to have it all reset if the player recasts Dancing Lights with a click of the button.
I think this module is great because one of my player keep using Dancing Lights and it saves me from creating tokens for each of the four dancing lights (which can be accidentally selected in combat tracker).
If I can make a suggestion, I think there are 3 milestones to achieve all of this. I will relate them with other proposed suggestions with links. Each of them would already provide great functionality separately, so I order them in order of simplicity;
If an identical field is added for the cantrips, we would have the same conditional logic (only they would always take precedence over items), and in the same way several options with custom names could be set.
With this first milestone, surely all the lights will be identical, but it would be easier to implement for all systems (it is possible that the other two milestones that I propose are too specific for DND5E, I don't know, because I haven't played other systems).
This second milestone is more complex, but it would replace the first once achieved: a section for "cantrips" and another for "items", in each of them with "add" buttons, to add (in order of priority of use) not only the name, but the properties of that type of light. Radius, glowing intensity, whether it consumes item (and if so, which one) or not, etc.
The third milestone would be two ways to turn off the light: normal click to just turn it off, and secondary click to "drop" it, like in the "Drop my torch" module. Falling would create a token for the light. Together with the second milestone, you could customize in the light settings if you're going to have control of that token (for example, for Dancing Lights, which aren't static, but can be moved by the character).
I think the module would be greatly improved if it had all this. All the best!
The work I commented on in April has now been released as v2.0.0 for use with the test version of FoundryVTT 10. You can use that version to define and configure light sources, using just about anything Foundry offers. If you have a test setup for V10, and only in such a test setup, please do kick the tires and leave me feedback on this ticket about the configurability. If folks agree this version substantively provides what was requested, I'll close the ticket.
As soon as v10 is released and considered safe to use, you can turn users loose on this - which means NOT NOW. :) Many systems and many more modules are far from ready for customary use in v10 at present, and may cause hangs that require you to restart your server or may corrupt your data, rendering your game permanently damaged. If you back up your data and create a test setup with very few modules installed, it will let you kick the tires on all the new stuff. Just keep your customary games in v9 for the time being.
@Airwrecker The Dancing Lights issue is actually a bug, introduced by one spot in the code not adjusting to the token lighting change for v9. This oversight also affects the code I just released. I'll create a separate issue for it and see if I can fix it for both v9 and v10.
@Airwrecker Re-reading your comment in the light of day ;), I think you will find the configurability in v10 gives you the means to solve the color issue with a JSON file - you can change any of the light settings - the radius, color, opacity, and even give it animations to make them twinkle if you like, with an entry something like this:
"Dancing Lights": {
"name": "Dancing Lights",
"type": "cantrip",
"consumable": false,
"states": 2,
"light": [
{
"bright": 10, "dim": 15, "angle": 360, "color": "#ff9329", "alpha": 0.5,
"animation": { "type": "torch", "speed": 5, "intensity": 5, "reverse": false }
}
]
}
However - limitation - all four lights will share the same setting, so you can't do "Dancing Microsoft Lights" :) .
The v10 features deliver on this feature, so I'm closing the issue.
Without sacrificing the simplicity of one-button activation: