Page 1 of 1

Impersonate Function

Posted: Wed Sep 12, 2012 6:55 am
by Lee
IDK if I asked this before, but is there a reason why impersonation only has a slash command and not a function? While [token:] does most of what is needed from an impersonated token, I believe having the ability to set impersonation through a function (e.g. impersonateToken(tokenName)), can be a very useful thing to have. In my case, I've come to appreciate that an impersonation persists whereas a selection doesn't; useful to have when I want to keep a lib:token's macros available at all times during design. Unfortunately, I can't apply stuff like conditional etc. since we all know that slash commands always have to be on top of the first macro, to execute.

As stated on one my of earlier posts today, I've done a brief scan of the MT code and want to affect some changes on a fork of the final MT build, for personal use. One of these is making a function for ImpersonateMacro. I've pretty much traced the area of execution and I'd like to ask the devs for any advice before I start on this particular item :)

Re: Impersonate Roll Option

Posted: Wed Sep 12, 2012 7:04 am
by aliasmask
Do you mean like Wiki: switchToken()? It sets the Wiki: currentToken() impersonation for the rest of the function. If the user name matches that of the token (as a side effect) the impersonation remains. If you were to tweak something, I would tweak switchToken.

Re: Impersonate Roll Option

Posted: Wed Sep 12, 2012 7:16 am
by wolph42
In addition to AMs comment (Wiki: switchToken() indeed does exactly that which you describe) I'm a bit puzzled by this:
Lee wrote:useful to have when I want to keep a lib:token's macros available at all times during design
the whole Idea of a lib:token is that the macros ARE available at all times, so what exactly do you mean with this?

Re: Impersonate Roll Option

Posted: Wed Sep 12, 2012 1:42 pm
by Lee
aliasmask wrote:Do you mean like Wiki: switchToken()? It sets the Wiki: currentToken() impersonation for the rest of the function. If the user name matches that of the token (as a side effect) the impersonation remains. If you were to tweak something, I would tweak switchToken.
It's more of having the functionality of /impersonate in a function as opposed to changing up the macro execution context.
wolph42 wrote:In addition to AMs comment (Wiki: switchToken() indeed does exactly that which you describe) I'm a bit puzzled by this:
Lee wrote:useful to have when I want to keep a lib:token's macros available at all times during design
the whole Idea of a lib:token is that the macros ARE available at all times, so what exactly do you mean with this?
:lol: I should have been clearer. I meant the macro buttons on a lib:token. My global panel is chock-full of macros calling library macros so I've devolved into running macros from the library itself. Like everyone else, I flit around the MT interface like a mad moth around a flame, so inadvertent clicks on the map area clears the selection panel. It's annoyed me enough to want to make some tweaks. Currently, I work around this by having a couple of macros on hotkey to re-select these tokens and one to cycle through them, but I think it's a lot more convenient, at least for me, to "lock" a lib:token in the Impersonated panel; not to mention that, while there have been many workarounds through macros (like the one in A.M.'s lib:players or another one I saw on the User Creations section), it'd be nice to use the built-in impersonate functionality while macro coding, e.g. [impersonate(tokenName)] ["say something"] [impersonate("")]. I guess it's more of a personal preference and not for everyone :)