RPTools.net

manually!?! Trying to insult me? No I meant with the use of macros and indeed ontokenmove. It does require some careful consideration though as you don't want to cycle through all tokens on the map each time you move one..

wolph42 wrote:manually!?! Trying to insult me? No I meant with the use of macros and indeed ontokenmove. It does require some careful consideration though as you don't want to cycle through all tokens on the map each time you move one..

ha! <begs for forgiveness>

I *thought* I had read something about manually adjusting the vision by token ownership, my bad.

Regarding token cycles, ya, I personally would use states and get all tokens with state, "purge invisible" for instance. Then compare those tokens. Plus, only fire onTokenMove routine for those with state "invisible" and "purge invisible".

I was sort of thinking of some "built in" way of handling this. Something like tokens are invisible except to those with this state, but I suppose it makes more sense to say ...with this sight type (and within distance)? But you can only have 1 sight right now so that's messy...

If someone wants to lay down some psuedo logic + UI, I'll consider it for inclusion...

*Edit: Maybe enhance "Visible to Owners only" to just add "Visible to States" or something. A state x beats state y would be even better?

JamzTheMan wrote:Regarding token cycles, ya, I personally would use states and get all tokens with state, "purge invisible" for instance. Then compare those tokens. Plus, only fire onTokenMove routine for those with state "invisible" and "purge invisible".

Doesn't MT push token updates when checking tokens for states?

A faster way may be to maintain an off-token list to look at and update. I'd keep the list on an off-map lib token (or, in my framework, I always have a GM token on a map that tracks certain things so that might be a candidate).

I am actually considering to create something agnostic for the BoT, been a long time since I did some cooking...

IF however you are considering to do something with the core maptool code I would suggest an entirely different aproach. More abstract than just 'invisibility'

I recall (but no clue what to search for) a discussion regarding this, when someone mentioned the idea to create 'vision groups' (parafrasing from a long lost memory here). Basically you can create vision groups, lets say 'Red' and 'Apple' and you can make tokens 'members' of those groups. Group members are visible to eachother (and share fow?) but groups cannot been seen by eachother. I think lightsources can also be made part of a group. The trick is that you can be member of multiple groups. So lets say your players are group 'Red' and you have an npc member of group 'apple' hence the group cannot see anyone from the apple group. Using an invisibility purge would in code mean that you make someone a member of group 'apple'. By also specifying lightsources as 'general', 'red' or 'apple' you can do funky stuff with those too.
('general' would be the current light system, meaning anything not assigned to a group and thus visible to ALL groups (but not the other way round).
)

OR

purging means that you assign a '30ft apple' vision type to a 'red' player (assuming you can have multiple vision types).

It would be good to dig up the original post concerning this as this requires quite some good thought and discussion to get this right.

nearly done with the invisibility purge in the bot. first test was successful. now need to do a lot of clean up and integration (documentation, settings, ui, etc)

edit: I was wondering when it would be getting tricky...that is when the token moves from within the purge distance to a further distance outside the purge distance. Thats a bit of a hassle with ranges and ownerships...

Oh? Excited to see the results!

urgh... here's a nice one:

two tokens can have (theoretically)
1. multiple owners
2. invisibility state
3. purge invisibility

the multiple owners is not that hard, however when you purge a token you effectively become owner of that token. Now if token is purging you at the same time than that tokens owners (among which you yourself) become thus owner of your own token
and now one walk out of purging range (when you thus remove all the owners of the purging token from the purged token and in this case vice versa)

I think I have it figured out and coded after a good migraine, now im gonna test...

nope.. another nice one:
assume one player owns two tokens, lets say pc and a follower (or cohort) he casts both invisibility and purge for both, now they move out of each other range, since they are no longer 'purging' each other ownership is removed...so you get these nice constructs:
edit: finally done... NOW I can start testing.
edit2: nope...that also turned out to be not true...but after an hour or so I finally was able to start testing. Now I am far in testing and finding the fun stuff like:

json functions you got to love them

Screenshot 2017-08-06 14.36.28.png (30.83 KiB) Viewed 866 times

edit3: its working!! quite a bit of a pain and requires more functions than I thought of but it works!

Just released a New version of the BoT

pls test the invisibility purge (see bot manual for instructions) and feed me back!

Wait, so, Purge uses ownership?

I know you are also making it generic but, lets use DnD rules for example and see if what you have works in that use case?

1. Purge Invisibility *removes* the Invisibility condition from the target, so in this case, just setting it so ALL tokens can see that token is all that is needed. Only happens while within the area of effect (30' from caster) and such turns back off when outside of it.

2. See Invisibility allows *only* the caster to see invisibility tokens, and such would need ownership/visible to owners. IIRC no range on the spell, so limits to tokens normal vision (so no distance checks)


It sounds like you have a mix of #1 & #2? Or I'm just reading it wrong because I haven't had my coffee...

You're right. I created see invisible and called it purge invisible. I'll update later. In the mean time havea look at the current functionality

to prevent double posts, I've initiated a further discussion on the purge inv. in the BoT thread. Can anyone familiar with dd respond pls?

invisibility expansion added. see bot thread for more info.