Mask functionality?

[Callum]

I've downloaded the FG demo, and I'm very interested in purchasing the full version to get a game running. One thing is putting me off, though. The map masking tool seems very clunky to use, and I consider this tool essential for the way I want to play. Can anyone share their experiences of using map masking during games, or other ways they've found of gradually revealing maps as the players explore?

Thanks!

[richvalle]

I'm running the Worlds Largest Dungeon in FG. So far the masking/unmasking works ok. A bit cluncky as you say but not too bad. Combined with the new zooming features its pretty good.

rv

[Callum]

But how do you control accurately which bits are masked/unmasked?

I take it there's no "fog of war" effect, where the PCs' light sources (or vision limits) control what they can see of the map? Or any plans to add such a feature?

[richvalle]

But how do you control accurately which bits are masked/unmasked?

I take it there's no "fog of war" effect, where the PCs' light sources (or vision limits) control what they can see of the map? Or any plans to add such a feature?

I don't think so... there is no way FG can know what is a wall, door ect. One of the great things about FG is that its so easy to drop images in from other programs and they all work.

To control the masked/unmasked:

You right click on the map and then select 'layers' then 'enable mask'. This fogs the whole map. I think it also puts you in 'mask mode'. In mask mode when you left click and drag with the cursor it draws a red line on the map. You trace out what parts you want to unmask. When you finish tracing the parts you release the mouse button and the unmasked parts show up on the players screen.

On the dm side while it is masked you can see though it so you can see the whole map kind of fogged over. For the players the fog is solid and they can only see the parts you unmask.

rv

[Blue]

Just give us an option for light sources. Its very pratical in open areas still. And if we have walls etc we should just use the old method.

[Callum]

To control the masked/unmasked:

You right click on the map and then select 'layers' then 'enable mask'. This fogs the whole map. I think it also puts you in 'mask mode'. In mask mode when you left click and drag with the cursor it draws a red line on the map. You trace out what parts you want to unmask. When you finish tracing the parts you release the mouse button and the unmasked parts show up on the players screen.
Thanks for your reply.

I tried the method you outline in the demo program, and found it very difficult to accurately reveal specific areas - because of the way the tracing tool works, I always seemed to end up with weirdly-shaped masks. Perhaps this is just a lack of skill on my part. But I feel that if this tool was a little more versatile - it could draw rectangles, circles, etc; or could be used to "wipe" areas of the mask away - then it would be fine for its purpose. As it is, I can see myself getting very frustrated with it.

[Razaan]

I'm big on the mask-revealing dungeon adventures. I use the mask tool on every map of every adventure I do. I don't know if it's just me, but I have yet to have any problems with the unmask tool. It seems very easy to use to me.

[richvalle]

Just give us an option for light sources. Its very pratical in open areas still. And if we have walls etc we should just use the old method.

I suspect this might not be easy to implement.

[richvalle]

I tried the method you outline in the demo program, and found it very difficult to accurately reveal specific areas - because of the way the tracing tool works, I always seemed to end up with weirdly-shaped masks. Perhaps this is just a lack of skill on my part. But I feel that if this tool was a little more versatile - it could draw rectangles, circles, etc; or could be used to "wipe" areas of the mask away - then it would be fine for its purpose. As it is, I can see myself getting very frustrated with it.

I know what you mean. I had the same problems at first. You do get better at it with use. And being able to zoom into the maps so you can see smaller portions helps a bunch.

As a tip, make sure you have pleanty of space to move the mouse around once you start the unmask.

rv

[joshuha]

I believe they mentioned more drawing tools and options for masking coming soon. Also, a handy tip is if you are trying to unmask an area and mess up, if you hit escape before release your mouse it will cancle the unmask.

[Alkaven]

Just give us an option for light sources. Its very pratical in open areas still. And if we have walls etc we should just use the old method.

I suspect this might not be easy to implement.

I can think of a way. Simply enable a feature for mask-layer images (something simple like a cut-out), then make adjustable light-radius for tokens that use the mask layer as boundries.

Example: I've got two 3x3 rooms side by side with a thin wall between them and an open door in an image. Then I make masking image out of everything the player CAN'T see even with lighting (to illustrate walls). Ta'daa! Just have to have a toggle feature for light sources on tokens and boom, it's done. Keeping the physics of lighting real isn't hard either.

Simple to implement. It only needs to be implemented now.

[richvalle]

Just give us an option for light sources. Its very pratical in open areas still. And if we have walls etc we should just use the old method.

I suspect this might not be easy to implement.

I can think of a way. Simply enable a feature for mask-layer images (something simple like a cut-out), then make adjustable light-radius for tokens that use the mask layer as boundries.

Example: I've got two 3x3 rooms side by side with a thin wall between them and an open door in an image. Then I make masking image out of everything the player CAN'T see even with lighting (to illustrate walls). Ta'daa! Just have to have a toggle feature for light sources on tokens and boom, it's done. Keeping the physics of lighting real isn't hard either.

Simple to implement. It only needs to be implemented now.

What I meant was not easy to program. Its easy to sit and think of cool things to put into a program. Not so easy to put them in.

Besides, untill the stability issues are taken care of I hope everything else takes a backseat.

Also, I think the improvments planned for 1.06 are already mapped out. But maybe they can find a way to put something like this in later. Who knows... it might be easier to 'implement' then I think.

rv

[Alkaven]

Just give us an option for light sources. Its very pratical in open areas still. And if we have walls etc we should just use the old method.

I suspect this might not be easy to implement.

I can think of a way. Simply enable a feature for mask-layer images (something simple like a cut-out), then make adjustable light-radius for tokens that use the mask layer as boundries.

Example: I've got two 3x3 rooms side by side with a thin wall between them and an open door in an image. Then I make masking image out of everything the player CAN'T see even with lighting (to illustrate walls). Ta'daa! Just have to have a toggle feature for light sources on tokens and boom, it's done. Keeping the physics of lighting real isn't hard either.

Simple to implement. It only needs to be implemented now.

What I meant was not easy to program. Its easy to sit and think of cool things to put into a program. Not so easy to put them in.

Besides, untill the stability issues are taken care of I hope everything else takes a backseat.

Also, I think the improvments planned for 1.06 are already mapped out. But maybe they can find a way to put something like this in later. Who knows... it might be easier to 'implement' then I think.

rv

Being a programmer, I can say that it isn't all that hard.

[Craw]

Being a programmer, I can say that it isn't all that hard.

That particular statement gets devs riled up more than anything else I've seen on other boards. Not being a programmer, I have no idea whether it is hard or not. However, I have seen certain people back up their "not so hard" statements with a pretty convincing "here is my mod that does just that." I'd certainly like more functionality out of the mask feature. If 1.6 doesn't meet everyone's desires, perhaps the programmers in the community can whip up a quick fix.

[richvalle]

I've taken plenty of programming classes but I've never worked with anything graphical so I was keeping quiet.

My comment about being hard to implement was a gut reaction, not based on exp or programming skills.

However, from a purely practical point of view... I would much rather see some other things then this as it would only be truly useful on a small handful of maps (ones without walls, doors ect).

rv

[Ram Tyr]

If 1.6 doesn't meet everyone's desires, perhaps the programmers in the community can whip up a quick fix.
Exactly. Some folks have done some great stuff already. Perhaps we can look forward to something from Alkaven.

However, from a purely practical point of view... I would much rather see some other things then this as it would only be truly useful on a small handful of maps (ones without walls, doors ect).
With respect to the time spent by the folks at Smiteworks, I also would rather see them focus on other stuff.

Later.
Ramza

[Alkaven]

Sure, I'll "whip up a quick fix" if I get paid for it. I already gave Smiteworks $30, I have no intention of giving them free stuff. But if you need some convincing, it only takes one point of reference on a bitmap. You take that point (whatever the number may be, likely stored in a token object's position attribute), and then use the radius as a distance of visibility, (which can also be stored in the token object as an attribute). Now for walls and such which crop that line of sight, that's what the image mask is for. Using another bitmap, one color would be the visible portion, all other colors would be considered unsee-able. It could be Filename + "_mask.bmp" for all I could care.

There's two ways to go about doing this. One way is to take the pixels (as numbers of course) in that now generated circle from the radius and exclude them from view (you can even do this before rendering if you'd like). Another way (using a slightly more sophisticated formula) would be to take the closest pixel (that is the non-visible color) and make that the rendered radius.

So, it requires three attributes: 1. The token position, 2. The visibility range, and 3. A Bitmap.

Now, because I know how much you guys love to tear me down, despite all the sense I make, I'll refrain from disclosing more. Honestly, I don't care about a feature like this. It only really makes sense for hack & slash environments. I don't even use the mask feature. If the players can 'see' the enemies there behind a wall, who cares? Their character's don't. It's how they roleplay it that concerns me.

[richvalle]

Sure, I'll "whip up a quick fix" if I get paid for it. I already gave Smiteworks $30, I have no intention of giving them free stuff. But if you need some convincing, it only takes one point of reference on a bitmap. You take that point (whatever the number may be, likely stored in a token object's position attribute), and then use the radius as a distance of visibility, (which can also be stored in the token object as an attribute). Now for walls and such which crop that line of sight, that's what the image mask is for. Using another bitmap, one color would be the visible portion, all other colors would be considered unsee-able. It could be Filename + "_mask.bmp" for all I could care.

There's two ways to go about doing this. One way is to take the pixels (as numbers of course) in that now generated circle from the radius and exclude them from view (you can even do this before rendering if you'd like). Another way (using a slightly more sophisticated formula) would be to take the closest pixel (that is the non-visible color) and make that the rendered radius.

So, it requires three attributes: 1. The token position, 2. The visibility range, and 3. A Bitmap.

Now, because I know how much you guys love to tear me down, despite all the sense I make, I'll refrain from disclosing more. Honestly, I don't care about a feature like this. It only really makes sense for hack & slash environments. I don't even use the mask feature. If the players can 'see' the enemies there behind a wall, who cares? Their character's don't. It's how they roleplay it that concerns me.

Ok... sounds like you know what you are talking about... vs me who does not. :)

Hey, no one is tearing you down (in this thread at least). Only time I can think of that happened is when you started to say how Smiteworks had 'ripped you off' or some such. Which, to give you credit, you later said you had used the wrong words.

No harm... just friendly talking about FG here.

rv

[richvalle]

RE your idea above...

Wouldn't there have to be some sort of pixles to feet conversion? Not every map is in the same scale.

And it would have to scale up and down as the map was zoomed in and out.

This could be handy on something like a fog covered graveyard or on a large scale map where the unmasked part is the limit of their vision.

rv

[kalmarjan]

Now, because I know how much you guys love to tear me down, despite all the sense I make, I'll refrain from disclosing more. Honestly, I don't care about a feature like this. It only really makes sense for hack & slash environments. I don't even use the mask feature. If the players can 'see' the enemies there behind a wall, who cares? Their character's don't. It's how they roleplay it that concerns me.


Okay, point taken. Right now, I think that the concern should be addressing the issues with image sharing, push pins, and masking before we even attempt to make a feature like this. It seems that the more that you add to the program in ways of "hacks" and stuff, the worse off the program becomes.

As for getting paid by SW; if I was paid by them I would churn out the tokens, modules, and other stuff, the same as I have done for free. I have also done this in a non-condescending manner. Anytime anyone asks me for help or a way to do something, I do my best to help. Like a good community member. This is not for monetary gain, rather - the learning experience.

Before FG came around, I was in the dark ages in XML programming and graphics. FG has opened a new world for me. Now I am looking into making Graphics a career. Would not have happened if there were more condescending people out there. (And you know who you are - :b )

BTW: My real career right now is as an executive chef. Believe you me, if any member asks me about how to cook or how to prepare something, I will give the information as best as I can, in a helping manner. NOT in a condescending manner.

You only get what you give people; try to keep the barbs and the sarcasm to a minimum, and lets see where we can take this awesome program. :)

'Nuff said

Sandeman

[Ram Tyr]

Sure, I'll "whip up a quick fix" if I get paid for it. I already gave Smiteworks $30, I have no intention of giving them free stuff. But if you need some convincing, it only takes one point of reference on a bitmap. You take that point (whatever the number may be, likely stored in a token object's position attribute), and then use the radius as a distance of visibility, (which can also be stored in the token object as an attribute). Now for walls and such which crop that line of sight, that's what the image mask is for. Using another bitmap, one color would be the visible portion, all other colors would be considered unsee-able. It could be Filename + "_mask.bmp" for all I could care.

There's two ways to go about doing this. One way is to take the pixels (as numbers of course) in that now generated circle from the radius and exclude them from view (you can even do this before rendering if you'd like). Another way (using a slightly more sophisticated formula) would be to take the closest pixel (that is the non-visible color) and make that the rendered radius.

So, it requires three attributes: 1. The token position, 2. The visibility range, and 3. A Bitmap.

Now, because I know how much you guys love to tear me down, despite all the sense I make, I'll refrain from disclosing more. Honestly, I don't care about a feature like this. It only really makes sense for hack & slash environments. I don't even use the mask feature. If the players can 'see' the enemies there behind a wall, who cares? Their character's don't. It's how they roleplay it that concerns me.

Wow. :shock:

My request/suggestion about contributing was made in earnest. You would not be giving anything to Smiteworks, you would be giving it to each of us that downloaded it and used it in our games.

As for getting torn down... :?:


As for getting paid by SW; if I was paid by them I would churn out the tokens, modules, and other stuff, the same as I have done for free. I have also done this in a non-condescending manner. Anytime anyone asks me for help or a way to do something, I do my best to help. Like a good community member. This is not for monetary gain, rather - the learning experience.
100% behind that statement.

Later.
Ramza

[Alkaven]

RE your idea above...

Wouldn't there have to be some sort of pixles to feet conversion? Not every map is in the same scale.

And it would have to scale up and down as the map was zoomed in and out.

This could be handy on something like a fog covered graveyard or on a large scale map where the unmasked part is the limit of their vision.

rv

Yes, your right. That's kinda where the 'little bit of difficulty' I mentioned earlier comes in. The line is point-to-point not point-to-radius. So you would need some kind of logical mapping in there where you would check the end of the rendered radius against the value of the pixel in the bitmap in order to find out where it ends.

And while I am a big supporter of open-source, you all paid for this application. If I contributed, that means you all technically paid for that feature still. Which means I'm really just contributing to their wallets in the end. If they released the source-code for the application, or had a mod IDE available, I would gladly and most definitely share all my modifications for free. Hell, if it meant enough to me and I had enough spare time, I would type some relevant code out for you guys to misunderstand (as always), but I don't even have time to finish editing my Chapter 1 entry for my Broken Mountains adventure.

And I don't believe in karma, sorry. It's proven that of all the good things I've done in college to help people, they've done everything in their power to sabatoge my education intentionally.

[Craw]

Hell, if it meant enough to me and I had enough spare time, I would type some relevant code out for you guys to misunderstand (as always), . . .
And I don't believe in karma, sorry. It's proven that of all the good things I've done in college to help people, they've done everything in their power to sabatoge my education intentionally.

Whether you can or cannot put out relevant code is not the issue. The community is about being helpful, not about self-aggrandizement. There are people in the community who are willing to help. You yourself began to see the devil in the detail once your off-the-cuff solution began being analyzed. Can those things be addressed? Sure. But if you aren't going to do it, then please don't go out of your way to be condescending to those of us who don't make a living programming. I'm sure you get frustrated at non-programmers' lack of coding skill, just as I'm sure any educators in the community are baffled by how everyone has deliberately sabotaged your education, whatever that means.

[Alkaven]

I just said it wasn't all that hard. Geeze. This is why I said you all go out of your way just to tear me down. A number of you started debating my comment and I merely clarified it. You guys asked me to prove how difficult it is by posting code, and I gave you a reason why I won't.

I'm sick of this. I can't even post an opinion that isn't even about the product's price or quality without being shot down by childish attacks on my 'willingness' to help the community.

[kalmarjan]

I just said it wasn't all that hard. Geeze. This is why I said you all go out of your way just to tear me down. A number of you started debating my comment and I merely clarified it. You guys asked me to prove how difficult it is by posting code, and I gave you a reason why I won't.

I'm sick of this. I can't even post an opinion that isn't even about the product's price or quality without being shot down by childish attacks on my 'willingness' to help the community.

Okay, point taken. Lets all agree to disagree about whether the other is being childish. Point finale.

Question is: Are we willing to make this mod or not? If not, consider the matter closed... until the Devs get time to process this once other issues related to the latest release are resolved. Agreed?

Now, lets all play nice... and get back to what matters.... gaming. :)

Regards,

Sandeman

[richvalle]

Hell, if it meant enough to me and I had enough spare time, I would type some relevant code out for you guys to misunderstand (as always), . . .
And I don't believe in karma, sorry. It's proven that of all the good things I've done in college to help people, they've done everything in their power to sabatoge my education intentionally.

Whether you can or cannot put out relevant code is not the issue. The community is about being helpful, not about self-aggrandizement. There are people in the community who are willing to help. You yourself began to see the devil in the detail once your off-the-cuff solution began being analyzed. Can those things be addressed? Sure. But if you aren't going to do it, then please don't go out of your way to be condescending to those of us who don't make a living programming. I'm sure you get frustrated at non-programmers' lack of coding skill, just as I'm sure any educators in the community are baffled by how everyone has deliberately sabotaged your education, whatever that means.

Well, either he's a troll or just not very good with getting his ideas across in a way that does not sound condescending.

Either way I'm going to start ignoring his posts.

rv

[Dupre]

We are very lucky to have a community as creative and friendly as you all are, but this thread is getting too personal in a negative sense and I will need to lock it if it continues down that path.

There are some good ideas here, some easier to implement, some a bit more difficult. Light sources fall under dynamic fog of war, which is something we would like to implement, but light sources have some design issues - some of which are already mentioned here.

Those of you who have not gotten used to the lasso tool, we will introduce more tools. If you would like to get your hands dirty with code, 1.06 will support LUA (https://www.lua.org) for scripting. Some of the presently available functionalities will be transfered over to the scripting layer so you should have plenty of examples to start with.

[Sigurd]

I'd also see other things, namely multi character per player, worked on before mapping\masking.

The Zooming is really good. I'd love to see fog of war & an extra layer or two. A layer for secret doors & traps would be really good, and perhaps another layer just 'cause. Better layer tracking might make it possible to keep map modifications for the length of the adventure. They'd have to find a way to encrypt the map on the client machines though. More secrets = more tempatation.

Re: User Statements

Its really a paradox that eventually serves the developers.

'This should be easy-do this' is a natural extension of closed source\proprietary programing. You can't tell the complainer "Go ahead, I'll expect it in a week." (That generally shuts them up)

Users answer most of their own questions on this website - that saves the company of a lot of time. They're also vocal about product desires - aiding design questions. We're still a small polite user base.

Devs should savour these times. :lol:

[Craw]

Actually, I like the lasso tool pretty well for non-rectilinear areas (Caves). A little practice with the tool does help. However, for the typical rectangular rooms and circular rooms in most structures, some kind of circle and rectangle unmasking would be great. From comments made in other threads, I seem to remember that such tools were likely with 1.6.

One thing I'd love to see are tools that reference the map grid. Since the grid scales and is not dependent on the underlying image, anything tied to the grid frees the DM from having to worry about particular design elements in maps and images. Imagine spell radii and cones, range tools, etc. tied to the grid. Unless this has already been implemented, of course. :lol:

[DeadlyAccurate]

I like the idea of an eraser tool (with maybe Ctrl+erase to re-mask) for unmasking. I also like the idea of a circle, especially if that circle locks in size. That way, you could indicate viewable areas by setting the size of the light radius depending on what sort of light source the PCs are carrying.

And if you want to get really fancy, the ability to set low light conditions (i.e. you have 20 ft. of visibility and another 10 ft. that is in concealment), maybe with an effect similar to the hazy effect the DM sees when the map is masked would be cool. :)

I do consider stability to be first and foremost the most important thing for the devs to work on, however.

[kalmarjan]

And if you want to get really fancy, the ability to set low light conditions (i.e. you have 20 ft. of visibility and another 10 ft. that is in concealment), maybe with an effect similar to the hazy effect the DM sees when the map is masked would be cool. Smile

This has been mentioned a few times in this post, and I have been doing some thinking on this. It would be cool to program this function to recognise walls and such, but it seems like it would be complicated.

How would it work out if we treated the map and masking like layers? You have the Map layer, the mask layer, a token layer and create another layer for light sources, possibly keyed to a token. Then you would not need to worry about the light radius "knowing" about walls and such, because these would already be "masked" So you essentially can have the best of both worlds.

The thing that would be required is a "fading" effect to be placed onto this layer, so you could see what is underneath, only in your radius or square of sight. I think that this would solve the whole invisable token request as well.

Any thoughts?

Sandeman