VBL/Lights/Vision, what would you like to see?

[Craig]

Given the fairly safe assumption that the whole vision/light thing will get some kind of reworking in 1.4 it might be worth while to start a discussion on what people think is currently missing from vision/light/VBL, what's needed, what would be nice, what could be done better, etc.

Let's see if we can get all the ideas about vision that I am sure have been posted in many other threads in the one place. So if you have an idea that some how affects vision here would be the place to post about it!

[jfrazierjr]

One thing I have thought about was in the place of vision vs light. For example, Infrared is both a type of vision AND a type of light. So is UV. My thoughts here were that objects would be sources of light types other than standard illumination which may require certain vision types to see.

Another thing I have thought about is in the area of people having multiple vision types of putting a order on them as well as being able to say "normal vision trumps IR" ie, you can't use the later if the former is in use. or something like that..

[aliasmask]

1. I think one thing that is really tied in to VBL/Lights and Vision would be the layers themselves. Having the VBL be an actual layer that you either turn off/on globally or per the token setting would give rise to many special effects (namely elevation).
2. Also, the order in which lights are drawn is an issue. Lights should have their own or follow the token it is apart of z-order. I recently ran across having a large room light, so everyone can see everything in the room and a small red light in a corner get completely washed out from the large light.
3. This has been discussed before, but tie together vbl and the non-transparent part of a token. Token has vision blocking basically, but the difference would be the token will still be revealed. This is nice for columns or large objects in a room, or say a roof of a building.
4. Layer visibility is important too. Yes the GM can see everything, but it would be nice to turn off a layer so the GM can see underneath it as the players would see the map. This combined with some of the above features will allow the GM to create multi-story buildings or even dungeons all in the same x,y area and tokens wouldn't need to be moved to another map or another part of the current map losing access to the surrounding area drawn. I currently have a macro that will swap a transparent image with the current image and back so I can see through it (mostly done for roofs).
5. I'm not a fan of the current "circle" of vbl. It's not precise enough and either reveals too much or not enough. I usually have to hand draw my circle VBL.
6. As mentioned before, multi-vision types should be possible for different environments. Really someone with Darkvision has 2 types of vision, normal and darkvision (only used at night in unlit areas) Technically, Darkvision doesn't work in a lit area so if having darkvision 60' and you're holding a torch 20' + 20' dim light.. you should only see 40'. But that could be handled with a vision precedence to overcome or ignore that rule. For example, this would be true if order of evaluation is normal vision, darkvision. But he could see 60' holding a torch if order was darkvision, normal vision. The light could be treated as an environment as well, where standing in a lit area negates the use of darkvision.
7. Environment Layer! Some areas of maps have Day areas and others Night. This would be awesome to be able to specify certain zones as Day or Night. I imagine this should be a layer as well that will apply to any layers below it and could be turned on and off. I can also see this used for fog where vision limits could be shortened or even extended. This layer could be textured like the FOW, but the area is drawn.
8. Day, Night and Shadow (twilight) environments. I'm not sure what the mechanic would be for Shadow but I'm thinking there may be some application for it. Perhaps show a light source if in a daylight zone? It wouldn't effect vision necessarily, but give the option for a lighting special effect.
9. I think this is asking too much, but perhaps giving vbl objects or special vbl drawn lines the option for an aura? I'm trying to think of a nice way to give the corners of rooms some shadow.
10. Movement Blocking Layer. Most things that block vision also block movement. When creating the vision blocking lines give the option to block movement, as well as with vbl objects.
11. I've mentioned this before on another post (I'll link it later), but I would like to have "fuzzy" vision blocking. The line will have a distance associated with it. Lets say A-C-B where C is the drawn line and A,B are the parallel lines at n-distance. A token looking at line C from outside the distance on the B-side will see every with in the distance of line C including A,C and B, but not beyond A. Now if the token crosses in to the area covered between A and B then they can see everything as if the VBL was not there. Once the walk to the other side of A they will not be able to see past the B area. I can see this being good for transitions (cliff-sides, stairs and raises areas of a room).
    
    There could be a variation of this as well. The VBL doesn't block vision at all until you step in to the fuzzy area. If coming from the B-side you can see all including past the A side, but once you step in to the fuzzy area you can no longer see past the A line. This would be similar to walking up to a raised area you can see over (the ground at eye level), but once you get against the wall, you can not see the above area anymore (only whats at it's edge).

[maleitch]

Dynamic lighting so I can have flickering light from my torches on the map.

I kid...I kid....or do I?

[neofax]

I would like to have the capability of X-Ray(ability to see thru VBL) for Superhero type games. Gradients of light instead of "cliff" light. By this I mean that I wish the light would fade from being able to see to black instead of color A for the first x feet and then a darker color B for the next x feet and black thereafter. I would also like animated light to capture the feel of a true torch, but this is low on the wish list.

[eRaz0r]

Regarding Darkvision and normal light, I'd have to say that this would have to be campaign-dependant. In some game rules, there might be no interference between light sources and darkvision.


But to add my own 2c - I would love to be able to specify the following : (and yes, some of this is repeated from prior posters! - and I apologize if some of them are existing capabilities of the system - I'm still learning the awesomeness that is Maptools!)

A PC's vision types : LowLight, IR, Darkvision, Ultravision? X-ray vision? Radiowave Vision? Being able to define how they work would be great. (Lowlight in D&D4e simply makes dim light bright for that character. It doesn't double the range of the light source as in prior editions)

A light sources type - does it emit IR/UV/regular light? Does it work only for the PC holding it? (certain spells/items do that - emit light that only the PC can see). Which visions can see this light?

A VBL's type : Which layers are impervious to which types of vision? X-Ray goes through everything but Lead, for example.

Auras which can negate or reduce lightsources or vision. (e.g. a darkness/gloom spell)

Transparency to Light Types - If an object is transparent to normal vision, but visible with IR vision, that would be cool. If a creature is invisible, but I have true seeing, I could use this property to emulate that.


I don't think we should use this system to emulate Elevations. That should be part of a separate system for Layers of Maps (spoken about elsewhere)

[Full Bleed]

1) Object/Token VBL : VBL that can be attached to Objects/Tokens.

2) 1-Way/2-Way VBL : VBL that you can see into but not out of (particularly useful for trees, columns, and object/token vbl.)

3) VBL Exceptions : As requested above, VBL that is ignored by user defined vision types (probably best defined by having VBL layer types.)

4) Quicker and More Accurate "View as Player" : Perhaps have a toggle button on the screen and some way to quick select the Group View or an Individual Player's View.

5) Automatic way to set "Player Token Always Visible" : A system option that precludes using a the "personal light" workaround.

6) Ability to Change Vision Distance after Map is Created.

7) In the absence of MBL, the ability to have VBL block movement.

[wolph42]

Vbl on tokens is absolutely number one. Drawing vbl while painting map the number two.
In addition to aliasmask day and night zones in one map, I would suggest 'overbleed' between the two zones. E.g windows in house where the outside daylight shines through.

[jfrazierjr]

5) Automatic way to set "Player Token Always Visible" : A system option that precludes using a the "personal light" workaround.

Hmm...I thought I fixed that? Perhaps that was only for tokens using conic sight(since then they would only see a slice of their token).

6) Ability to Change Vision Distance after Map is Created.

The problem here is that all the vision types would have to be recreated after the map is modified. Not hard, but why not just use explicit ranges on your vision types? More importantly, the way vision works with range now is that if the campaign vision type row has a distance option, said value is used. If not, then the map's range is used from when the map was created(which is based on a preference). So the code would have to reread all the light strings and filter only those that do not explicitly set the distance and then remove and recreate those visions. Honestly, I am not sure I see much point in even having it be per map any more now that it can be set for each vision.... Just wondering.....

[Full Bleed]

5) Automatic way to set "Player Token Always Visible" : A system option that precludes using a the "personal light" workaround.

Hmm...I thought I fixed that? Perhaps that was only for tokens using conic sight(since then they would only see a slice of their token).

Had a game a few weeks ago where a player with a light source stepped "out of view" leaving another player in the dark (they could not see their own token.) They were in a 5' sliver of "darkness" and should have been able to easily step back into the light, but they needed me to move their token. Looks like their vision type had r1 on it. Not sure if that's the problem or if they just lost track on their token because their screen went black...

At any rate, I'd rather not have to do that. An option to make one's token always visible would be appreciated without having to go into all my vision types and add r1 or r2 or whatever. New users (and old, alike) have problems with vision sometimes precisely because of the way things like that are handled (i.e. having to go into each defined vision type and add a "personal light", etc.) A simple, "Player can always see their token" option on the token or a global option would be a better solution, imo.

6) Ability to Change Vision Distance after Map is Created.

The problem here is that all the vision types would have to be recreated after the map is modified. Not hard, but why not just use explicit ranges on your vision types? More importantly, the way vision works with range now is that if the campaign vision type row has a distance option, said value is used. If not, then the map's range is used from when the map was created(which is based on a preference). So the code would have to reread all the light strings and filter only those that do not explicitly set the distance and then remove and recreate those visions. Honestly, I am not sure I see much point in even having it be per map any more now that it can be set for each vision.... Just wondering.....

Not sure why "all the vision types would have to be recreated after the map is modified." If you mean "re-read by MT" (I mean, they are all right there in the campaign file, already defined/created) then that doesn't sound like a very difficult issue.

Side note: A syntax change might be in order. Something like "Undefined/Default Vision Distance" is more descriptive than just "Vision Distance" which isn't really clear on how it interacts with selected vision types.

Second, as for "why not just use explicit ranges on your vision types"... because I don't want to box myself in like that. Right now, when I have a Day map, everyone can see the Default distance regardless of their vision type. And that distance may be map specific (forest, hills, mountains, desert, etc.) Say I set it to 240 because it's rolling hills. What if I decide, after I make the map... that a fog rolls in, it's dawn/dusk, smoke appears, and I want to change things up... I'm stuck. I can't drop it to 120. And if I had all of my vision types distance defined, what would I do? Go in and edit all of them? What if players go from hills to a dense forest, (still Day) and I want to change the default distance from 120 to 60?

It would simply be much nicer if I could just change the default map vision distance on the fly to account for changing conditions on a Day map.

[Cweord]

Different visibility types, so that you can have tokens that can only be see by a certain type of vision (people with see invisibility can see the invisible but no one else)

Multiple vision types per token (so you can see and see invisible at the same time etc)

Sight that can see through VBL but only certain distance (or through so many instances or so much thickness, so through so many walls)

[JonathanTheBlack]

What good is it to see through walls if there's no light on the other side to allow you to see what's there?

[Cweord]

Psionics, Radar, Thermal vision etc

[jfrazierjr]

Not sure why "all the vision types would have to be recreated after the map is modified." If you mean "re-read by MT" (I mean, they are all right there in the campaign file, already defined/created) then that doesn't sound like a very difficult issue.

Oh, it's not very difficult, just something else to be done. What I mean is that you would have to look at each vision. If the vision HAS a defined range to it, you would not want to modify that(otherwise, whats the point of setting the vision distance explicitly). For those that don't, you would remove them from the vision list, recreate with the new distance range, and add back to the vision list.

What if I decide, after I make the map... that a fog rolls in, it's dawn/dusk, smoke appears, and I want to change things up... I'm stuck. I can't drop it to 120. And if I had all of my vision types distance defined, what would I do? Go in and edit all of them? What if players go from hills to a dense forest, (still Day) and I want to change the default distance from 120 to 60?

Well, your not stuck, you just don't like the current answer. Also, don't forget that you are much less stuck now than you were a year ago when vision distance was added as an option since you only had the map distance and nothing more. In theory, you could even make "zones" via a macro (onChangeSelection macro for example) that checks for specific coordinates and if in said coordinates, change the vision type..(hmm.. I wonder just how slow/fast that would be with the current MTScript)

Now, with that said, I think I would kind of think things like fog would be best implemented by something like a partial vision blocking layer(which I don't think anyone has talked about....hmmmm). Ie, fog, but fog that allows some distance such as "cut my vision in half while in this stuff". Sort of like the whole movement cost thing. Perhaps that's a good approach.. perhaps not... If you base it on the map, then you are making the assumption that all player tokens are in the fog, dense forest, etc.

[Full Bleed]

Well, your not stuck, you just don't like the current answer.

Which is, as I understand it, what this thread is all about.


I'm not looking for workarounds. I know most of those. I'm looking to not *need* workarounds. When the environment changes, I'd like to be able to simply change the default vision distance. Heck, maybe even having some kind of easily applied multipliers (after map creation) would be fine. I could then set the map for 240, and select "Hills (.5)" or "Forest(.25)" or "Dusk (.5)" or whatever I wanted. The point is to not be locked in arbitrarily after the map is created.