OLD Wolph42's 'Drop-in' Bag of MT Tricks OLD

[Cay]

I checked the manuals once again.

The "inline" manual in the Bag of Tricks panel does not mention dragging the image_none onto the base map.
The "online" manual at the beginning of this thread does.

Maybe in a future release you'd want to add this information to the inline manual.

[wolph42]

Thanks! I Will.

[aliasmask]

Here's an interesting idea for you that would seem easy to integrate with what you have so far. Darkness and reduced visibility. Upon entering the effect, the sightType is set and switched back when leaving. So, for fog cloud you can set the type to something like to 7.5 ft and set a concealment state. I can do a mod for the attacks where it will check the target for concealment and automatically select the miss chance radio button. Just a thought.

I was just mulling over implementing a vision system using states, like see invisible to handle some of the token stuff automatically. For example, if an invisible token "can" be seen and the viewer has see invisible, then it would set ownership to the invisible marker on the object layer. Whenever the token moves it could make spot/listen checks for tokens in area using all the proper mods for range and stealth and give the person moving the various skill checks.

[wolph42]

THe things you mention are very system dependend so that makes it quite hard to implement. I lIke the idea of the darkness fog but that's actually already supported: traps. These tokens allow for code that is triggered when you move over or on them. Maybe I should name them more generic and call them eventTokens. Then Create a couple of functions that you can call at the start of the token: stepOn, stepOff, onToken and OverToken. These are booleans That are set within the scope of the. Function.

These tokens then can be used to program stuff in like you mention, but will be system dependent. Eg I personally play warhammer 40k which is significantly different then eg DD. and I do not want to go so far as to implement system dependent code. (even though I did this with the traps, but only as example.

I can imagine that you create a separate lib file that hooks into the Bag and suppots the system and FW you're talking about (pathfinder??)

[lonewolf147]

Just to put my 2 cents in, I love the idea of being able to adjust vision based on a location. I never thought to try that with your traps functions, and will have to play with that (I've got plenty of foggy/misty/darkness areas in the dungeon).

But, I do have a concern with it. Let's say you have a field of fog. The player can walk right to the edge of it and still have normal vision and be able to see 90ft into the fog. Once they enter, their vision is reduced, but they should not have been able to see that far into it in the first place. Any thoughts on how to adjust for that? Is it possible to code something in the 'fog token' that will hinder vision?

[wolph42]

I would need to think about that nut I think that you can stack tokens, like a pyramid. So when you walk on the edge you get a minor adjustment and the farther you walk to the centre of the stack the more your vision limited... Ill first gonna make the generic tokens. Likely I'll remove pits and traps then (which you can replace with the generic ones).

By the way I think you can do the same for movement.

[aliasmask]

Just to put my 2 cents in, I love the idea of being able to adjust vision based on a location. I never thought to try that with your traps functions, and will have to play with that (I've got plenty of foggy/misty/darkness areas in the dungeon).

But, I do have a concern with it. Let's say you have a field of fog. The player can walk right to the edge of it and still have normal vision and be able to see 90ft into the fog. Once they enter, their vision is reduced, but they should not have been able to see that far into it in the first place. Any thoughts on how to adjust for that? Is it possible to code something in the 'fog token' that will hinder vision?

I suppose you could draw vbl. But yeah, that is tricky. You would have to implement an invisibility feature (like in the 3.5/pathfinder FW) once someone enters the fog or darkness. Funny in 3.5, darkness really isn't inky black darkness anymore, it's more like fog where you can see inside anyway. In fact, fog ends up being more hindering than darkness.

[wolph42]

Can players pass through a vbl?

Another method would be using my erm forgot the name border tokens? That transport a token when they move on or over it to another section. You could create small pockets of fogged area somewhere else on the map and use the border tokens to move them to an back.

[aliasmask]

Although, with fog, if you're on the border you can see everything outside of fog just fine. In my framework, you can't walk through vbl. I would just move the token that extra 5'. DM gets a move override option.

[Raoden]

So, I'm finally getting around to trying to learn all these spiffy utilities. The .cmpgn file seems to work fine, but when I just drop the .rptok into another campaign, I get an error simply from trying to open the frame "Bag of Tricks Macros":

 Error in body of roll.       Statement options (if any): frame("Bag Of Tricks Macros", "width=215; height=550; temporary=0")       Statement Body : { [r:mtt_createMacroButtonsOnTokenMove()] }

I checked that the lib token has no Ownership, and I've reloaded the campaign to make sure onCampaignLoad is initialized. I looked inside onCampaignLoad, and I see that it should be defining the function that is giving an error ... but apparently it isn't.

Do I need the .zip file version of the macros just to view the frame of macro buttons?

EDIT: Yep, ok, I read the Implementation section more carefully and figured out that I need the Table ... sigh. Oh well.

[wolph42]

@raoden: you can work without the table but then you cannot use any of the prefab macro frames. So you need to drag the macros in the campaign section to your campaign panel. Then it works. Of course for certain pads you'll need the table anyway so you're better of installing it...

@alias: to get back on my first response to your first post: are the 'generic' tokens with the flags something that you could use or not. I gave some more thought and realised that you can set the activation type per generic token through a setting that you save onto that token. This has the advantage of copy paste.

[aliasmask]

Ah don't worry about it. It was just an idea. I actually use my own version of some of the tools you have. I was just thinking you can implement a vision trigger by going over an area.

[wolph42]

Ah don't worry about it. It was just an idea. I actually use my own version of some of the tools you have. I was just thinking you can implement a vision trigger by going over an area.

Ah I don't worry about those things I like the challenge and the ideas. And I like the idea of movement adjustment and vision adjustment, the challenge however is to get it generic as that's the whole idea of the bag.
For movement I could think of creating a form which shows the distance travelled which is calculated based which tokens you move over. So a gm could create movement impeding tokens which adjust the value travelled in the form when you move over them. Bit tricky though. I think that can only be done if you move at once (so not step by step but with waypoints). In addition you could even limit the token movement but I think that will turn out to be a drag when you eg quickly want to move a token to another area, hence a form showing the movement amount.

As for vision... Not sure how to get that generic, although I could provide a preset of sight variables you need to set for your own game, eg mtt_vision1, mtt_vision2, mtt_vision3 etc for which you can set the actual values for your own game and the token where you move over automatically set the token to the corresponding vision type... Would one want to use such features??

[lonewolf147]

As for vision... Not sure how to get that generic, although I could provide a preset of sight variables you need to set for your own game, eg mtt_vision1, mtt_vision2, mtt_vision3 etc for which you can set the actual values for your own game and the token where you move over automatically set the token to the corresponding vision type... Would one want to use such features??

Having a background token change the vision setting on a PC token sounds useable to me. It would work for the most part in any vision hindrance setting (ie fog, darkness, snow, sandstorm) and I could implement it right away in my campaign. Sadly, it doesn't address the ability to reduce vision to see 'into' a token. With the limitations of the current VBL system in MT, I don't know that a pseudo-VBL could even be scripted without a rewrite of the base code of MT.

[aliasmask]

As for vision... Not sure how to get that generic, although I could provide a preset of sight variables you need to set for your own game, eg mtt_vision1, mtt_vision2, mtt_vision3 etc for which you can set the actual values for your own game and the token where you move over automatically set the token to the corresponding vision type... Would one want to use such features??

Having a background token change the vision setting on a PC token sounds useable to me. It would work for the most part in any vision hindrance setting (ie fog, darkness, snow, sandstorm) and I could implement it right away in my campaign. Sadly, it doesn't address the ability to reduce vision to see 'into' a token. With the limitations of the current VBL system in MT, I don't know that a pseudo-VBL could even be scripted without a rewrite of the base code of MT.

You could kind of do it with a covering token, but that gets complicated. Well, maybe not with tools Wolf has. It'll be like a roof. Visible to people outside of area, but invisible to people inside. GM would always see "roof" though unless he switch to player view, but even then that's kind of buggy too.