Darkness as a Light source

[JamzTheMan]

OK, so I thought I'd take a look at one other thing that's came up sort of often at our table due to Tieflings... Darkness.

I took a look at the light sources and hacked together a proof of concept for myself to see how difficult it would be and what sort of road blocks I'd hit. It took me a while to trace through the process of light sources and finally figured out most of it. So I changed the code to add a new "type" of light, for now called NEGATIVE (to go with Normal & Aura, prob change to Darkness, dunno). You add a "Light source" like: 'Darkness - 20: negative circle 20'

It then processes all "normal" light, then subtracts "negative" light source, then adds "personal" light sources (as generally defined as darkvision which generally perceives through darkness, even magical). It works, although you do get a weird "affect" based on it's not "vision blocking" so although you can not see into it, you can see past it. Not sure if this is something I can fix yet or not without major impact to performance. I'm sort of aiming for a "low impact" if at all possible to performance and code.

Due to the fact that not all systems work the same, and to truly support Pathfinder/DnD, you really start breaking into the 1.4 vision density feature request as I would need to "rank" light source strengths and process them in order, and even more difficult, find a way to "reduce" the light levels which are defined but not really "understood" by MT (ie Torch - 20: circle 20 40#000000 is 20 foot of bright light, 20 foot of dim light would reduce to 20 foot of dim light).

So given those issues, would it still be worth it to anyone else to have "something" for now? At least through macro's and various light source definitions, it could be passable and give GM's a little more control over the battlefied.

Also, are there any other issues, technical or otherwise, anyone can see that would need to be handled?

[Azhrei]

Sounds like an interesting idea. I'll keep an eye out here if something needs clarification regarding the code, but note that I'm no master of light/sight/vision in MT so I'm not sure I could help much. Joe may be a better source of info.

[jfrazierjr]

Interesting concept. I can't see an easy workaround for NOT being able to see past the darkness(which does not make sense in the real world) without a TON of changes(none of which I would suggest making in 1.3. As you stated, this gets into different VBL types combined with different vision types(ie, xray vision can see through "normal" VBL, but not "lead" VBL for example.)

[Azhrei]

Yeah, the "darkness" in the D&D world is strange. So is silence.

If I'm in the middle of a dark area, I can normally still see bright areas that are far away. Doesn't work that way with the "Darkness" effect.

If I'm on the other side of a door from a loud racket, I can still hear the noise. But not within a "Silence" effect. But if the silence effect is between me and the noise yet doesn't encompass either one, then I can hear the noise?!

Magic messes with reality, which is one of the reasons why it's so much fun! But it gets difficult to model in a software program because there's no real world exemplar that we can point to and say, "Make it work like that."

[JamzTheMan]

Yea, not only does "magic" darkness block los, it technically only lowers the light level of "ambient" light. So, during "daylight" vision, it would only be dim light. So only with torches and such dies it nullify.

So i think i will leave it as is, as it technically doesn't "break" or "change" how anything currently works and works decent enough for drow running around with it on.

I'm thinking of adding one more source of darkness that also affects personal light (ie blocks darkvision) and stop there vs adding light "stengths", leavimg that for 2.0, otherwise i have to possibly add/subtract from the visible Area more than it should.

I agree that to block los could be problematic. Although, in theory, it could be not to bad. It should just be another topology (Area) to copy track all darkness on and apply where necessary. But I may have to hack to many places for that and agree not worth it in that case for 1.3.

Currently i only had to modify 3 classes and not that many lines of code. I need to combine my to for loops into something more streamlined and i will share the patch.

[JamzTheMan]

OK, so did a little research for Pathfinder "darkness" for at least a basis of what I needed. And actually, looking at the Darkness spell, it only reduces light within the "area" of darkness. It actually makes no mention of not being able to see "through" it. And given if you were outside during the day, it would only be dim light so obviously you could see through it then. So maybe I'll just keep it as is for my game as well, ie you can see "past" magical darkness (unless someone points me to where it says it WOULD block LOS!)

So, given that and other reasons, I scrapped the Vision "types" and went a little further and added a new option instead called "Lumens" (an integer representing light level) Given the light properties below, default lumens is 0, negative lumens basically take precedence over any light with lumens it reduces to 0. So a -20 lumens will cause darkness over any light source of 20 lumens or less.

Personal Light vision is set at 100 lumens.

So, Daylight (lvl 20) > Deeper Darkness > Sunrod & Darkvision (aka Personal Vision) > Darkness > Torch (and all other lights)

Code: Select all

D20
----
Lantern, Hooded - 30: circle 30 60#000000
Daylight (lvl 20) - 60: circle 60 lumens=500
Everburning - 20: circle 20 40#000000
Lamp - 15: circle 15 30#000000
Torch - 20: circle 20 40#000000 lumens=5
Candle - 5: circle 5 10#000000
Sunrod - 30: circle 30 60#000000 lumens=50

Darkness
----
Darkness - 40: circle 42.5 lumens=-20
Deeper Darkness - 60: circle 62.5 lumens=-200
Darkness - 20: circle 22.5 lumens=-20

I basically add all the light sources into a TreeMap<Double, Area> and it sorts them all by lumens. I add any light source areas of the same lumen and I convert negative lumens to absolute value and add .5 so 1, I know what is "darkness" aka non-intergers and 2 it sorts automatically in the TreeMap and -20 sorts higher than 20. I then start with the visibleArea, add light or subtract light from the area as I iterate through the map. So given a single token with all the light sources active above, the treeMap would hold 7 areas.

I end up iterating over the areas about the same, as currently each token with a light source is grabbed, light sources added/intersected and added to a List, then the list is iterated over. Although it seems the light sources are iterated over several times on each click of a token (before and after my change) so not sure if this is on purpose or there is some room for optimization here.

[jfrazierjr]

Another way to implement this as a "hack" and yet still have it work somewhat as expected would be to create a separate object that acts just like the existing ummm(I forgot the exact class names) VBL AreaOceans BUT have an additional parameter for "layer". And by "layer", I am more thinking in the sense of vision types that can see through it. So for example, this special VBL on "layer 1" would block "normal" vision, while the special VBL on "layer 2" would block normal AND darkvision. And you could easily give this special VBL their own "colors"(such as black). Then, when inside the render loop for a token, you would have to take this information into account AFTER normal VBL.

This would probably take about 10-20 hours of work or so for the coding just that part + the new networking code to transfer to each client, not counting any UI changes to allow one to select which specific "layer" to apply VBL to using the VBL drawing tools. All together, I would think this could be accomplished in 20-30 hours of work.

My only concern would be for the GM who owns multiple tokens and thus would have no tokens selected and how would that look(we already know that Player View sucks, so I would not worry to much about that part.)

[JamzTheMan]

Now that I'm mostly done with it, I don't consider it so much a "hack" now. Although I would have preferred to put it on the Light class vs LightSource but it would have required a lot more mangling of the code. I could then have maybe changed the lights as in "lower the light level" vs just on/off. But currently MT really isn't "aware" of light levels, we just id them by color.

But for light that DOES block LOS, ya, I had the same thoughts. Adding multiple topology layers to track the lights, adding the darkness to the light Area (read java class) and to the VBL Area, then at render combine the topology (the VBL Areas) together.

But then you get into, how many layers do you want? Do they scale based on # of different lumens defined? I think I'll leave that to 2.0 and a redesign to handle all that...unless a few months go by and I get bored again lol

Just happened to have the day off more or less yesterday so cranked it out as is. Probably won't have that chunk of time again for a while (especially with my new media-table project coming up!)

[JamzTheMan]

Jf, does this look right to you? I'm trying to trace how often and what events for vision/lighting fire off. I Have a map with 1 pc, normal vision, torch, night time and a NPC with darkvision 20' away.

If I just press meta-shift+o or move the token 5', it SEEMS like excessive calls to flush methods and getVisibleArea (which forces recalculation of all lights again due to the flush).
I just put a couple of system.out.print's on call of a couple functions. Some of these calls seem to be from multiple threads as I see some flush calls in the middle.

I know it's a little low-key debugging, just trying to make a little sense out of it. But thought I'd ask before diving into it more if it's normal or not. Just seems like a lot of repeated calls for a single event.

meta+shift+o

Code: Select all

**flush(token) called for: Our PC
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
##flush() called
##flush() called
calculateVisibleArea called
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
**flush(token) called for: Our PC
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
---getVisibleArea finished
##flush() called
##flush() called
calculateVisibleArea called
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
+++getVisibleArea called
calculateVisibleArea called
+++getVisibleArea called
##flush() called
**flush(token) called for: Our PC
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
##flush() called
##flush() called
##flush() called
calculateVisibleArea called
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
calculateVisibleArea called
+++getVisibleArea called
##flush() called
calculateVisibleArea called
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
+++getVisibleArea called

move 1 cell

Code: Select all

**flush(token) called for: Our PC
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
##flush() called
##flush() called
calculateVisibleArea called
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
**flush(token) called for: Our PC
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
---getVisibleArea finished
##flush() called
##flush() called
calculateVisibleArea called
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
+++getVisibleArea called
calculateVisibleArea called
+++getVisibleArea called
##flush() called
**flush(token) called for: Our PC
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
##flush() called
##flush() called
##flush() called
calculateVisibleArea called
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
calculateVisibleArea called
+++getVisibleArea called
##flush() called
calculateVisibleArea called
+++getVisibleArea called
>>tokenVisionCache NOT used: Our PC
---getVisibleArea finished
+++getVisibleArea called

[xavram]

Did this ever get pushed into any of the 1.4.x releases? I just stumbled across this now and I know that in my games, darkness is a pain to handle. You end up having to draw a darkness area, maybe put VBL around the edges, then tell people, "play it straight, if you don't have Darkvision, you can't see inside of this".

If, instead, you could just drop a token wiht a "Darkness aura" on it and vision was automatically handled...well, that would be super cool.

[RPTroll]

From the Announcements section on the New Dev/Test MapTool

New lighting option, "lumens" allows fow to be concealed vs revealed, ie "Magical Darkness" effect.

[xavram]

Drool...I'm still working in 1.4.0.4, but looking forward to this!