LibActionPads v3.11.0

[exotic hill]

I would keep designer minimized (and only max it when you want to modify a door). Generally speaking, there a ton of "designer code" that gets skipped when it's minimized. The designer wasn't made for "real-time interactive changes" it was meant to design something and put it into production. If i have the designer "maxed" then I'd want it to respond to anything the GM clicks on.

I would look at that isOnActionPad code as that should be the only code used to test how close a token is.
I'll set up a 50px grid with a 5' reach and see if I can duplicate the issue

So long as I adjust the reach value and change it from 145 to 50, it works like I'd think you'd expect . . .

Found this one too, I can leave the designer open but the door icon isn't going to be bolded because the bold is driven by the door overlay being triggered or not. That said, I'll revert to the old behavior that leaves the designer open anytime you click an actuator (that is how it was before all the conditional opening features).

[exotic hill]

@turbid quarry the dynamic grid size / reach check. I'm thinking of ways to handle this.
I would probably require a new variable or a checkbox that states, if checked with use Distance value along with 1.45 x GridSize?
I don't know of a way to allow all three options (hard value, dynamic prop value, and gridsize X 1.45 value).

[exotic hill]

Still working through it but this is where I'm going with it so far :

[turbid quarry]

I think I just wanted the ap menu to always pop for the GM. But not for "basic doors" for the non-gms. Solves my problem with that behaviour. As for having the designer open all the time... I've been wondering about that myself... I just wasn't sure about how I was going to deal with that. I guess I'll just open it when I'm going to use it. I thought having it open all the time would kind of keep me more in-touch with the state of the interactive objects on the board... and tweaking or adding things as I went along as opposed to trying to build everything perfect out of the gate though.

@exotic hill how does the "distance in grid cells" setting interact with the "distance in pixels setting"? seems like it should be one or the other

[exotic hill]

I don't disagree to a point but allowing both where you use a property along with that checkbox would allow a DM to include the token size or additional reach additions or subtractions. I was trying to find a way to resolve the t-rex giant with a mouse reach 🙂

[turbid quarry]

I mean in the settings now I've got "distance in grid cells" at 2. "distance in pixels" is 50. 50 should only reach out to the middle of adjacent cells. 2 grid cells is a lot further. It seems to be using the pixels settings... what's it doing with the "distance in grid cells" setting? they can't both be true.

[exotic hill]

2 is used in a getTokens condition check.
Of that output, 50pixels is measured and the first token that's in range wins (with impersonated and selected tokens taking dibs)

[turbid quarry]

So the entire gettokens call and comparisons can be bypassed with an impersonated/selected token. Are you doing that? Because, while I see the video you made, sometimes it's working for me and sometimes it isn't... and I just don't see how the logic fails when something is impersonated... but it's got to be making bad choices sometimes when it has choices to make.

[exotic hill]

Taking dibs / priority IF they passed check 1.

[turbid quarry]

But why do check 1? Just measure to the actuator. 😉

[exotic hill]

I don't think that would account for no tokens being selected and/or multiple tokens being selected. There are differing use cases.

Also getTokens trims the number of tokens I'm looking for, that is it's main purpose for my "coding" use case.

[turbid quarry]

I'm talking only when there is an impersonated or a (single) selected token. I think you need to break out the logic so using impersonated/single selections simplifies the "clever" stuff that I think is messing up an otherwise solid method.

[exotic hill]

I don't see aything is "messed up" though 🙂

Or, what isn't working?

I do want to provide an allowance for the t-rex mouse reach vs a dragon with double reach even tho the tokens are the same "size".

[turbid quarry]

Right. But reach is a separate issue. The problems I'm seeing have to do with the fact that it's not measuring the right token against the right door. And that should be impossible if you only measure the impersonated token against the clicked actuator. I don't know... in your sample above, move those tokens around more, swap them, change impersonations more. It's breaking on my side for some reason.

[exotic hill]

I fixed this already in 3.6.1

[turbid quarry]

Ah... ok... I thought your post above was illustrating no issue.

[exotic hill]

The last video I posted was what I fixed but wanted to hear you thoughts on the checkbox + range type dealio 🙂

I'm not accounting for token size and a property can help with some of that, I wasn't sure if it could resolve "all of it".

[turbid quarry]

Oh... well... if you're trying to set a "default" then I guess that logic should simply be gridsize*1.45? Otherwise reach just has to be per token capable. You were correct that there is not one size fits all. Trex is big with a short reach. Giant is big with a long reach. Have to defer to a property/framework for that. The reach prop in D&D and Pathfinder is in 5 foot increments... but that may be different for other systems.

[exotic hill]

So a combo you don't think would be needed? Just leave a text box to allow a property to be typed in and maybe a checkbox to use or not use the "default"?

[turbid quarry]

I don't think you have much choice. I know that to properly support this I'm going to have to build an ActionPads reach specific calculator to account for varying token size, grid size, and reach prop (the basic formula I provided in the git post I made was just for medium). Any universal assumptions you try to make are probably going to fail...

I just thought that grid*1.45 is a better starting point than a more arbitrary 145. So, over all, I think a (default, manual, property) selector solves as much as you can.

[exotic hill]

I could allow for an evalMacro acceptable formula as well, so it could be a number a hasProperty or an evalMacro format
and provide some examples in Help.

I have this option available when / if you tie macros to an action.

[turbid quarry]

Another option should be to ignore reach. Let the GM/players police what can and can't be used.

[turbid quarry]

Is there no way to have threaded comments/conversations in this type of channel? If not, that is all the more reason that ActionPads needs its own full-blooded channel.

[turbid quarry]

@exotic hill I officially have the 100th "issue" on your git. You're welcome.

[turbid quarry]

@exotic hill How can I use an overlay to draw something in the center of the viewport? The getview functions are all related to the map viewport.

[exotic hill]

It's a combo of getViewPort getViewArea and getZoom Let me try to find a snip it of just that . . .

[turbid quarry]

I figured it out... I just hoped there was a simpler way

The way I did it was set zoom to 1, get view area, subtract start/end x/y to get the overlay viewport dimensions, then half them, and set the zoom back to where it was. Would be nicer to have a function for that... but now I guess I do. :/

[exotic hill]

You shouldn't have to do that with zoom but it does make the math easier :).
If you math out your numbers, pre-zoom, and multiplied by getZoom (do NOT round), it should land you in the middle.

[exotic hill]

@turbid quarry I'm going to start putting the latest dev version on the git site. v3.6.1b is up there now. TBH I don't know if it covers all of it so I'll need some help / reminders on what I missed. There were several "quality of life" improvements and general bug-fixes.
I added in some size auto-detection that "seems" ok . . .

I'd like to say, most of it, is resolved. I do know the inventory issue, not sure if you're good with hooking into the player token and for now, you handleing that sync-back to the LIB:player token
I was looking for a good icon to use (as the function is there but there's not an icon yet) to "break" a door, essentially locking it in whatever state it's in and disabling the door until it's unbroken. To test this, you can add "chk_BRK":1 to the door object apJSON to see the affect

[turbid quarry]

I only see 3.5.3 in main and dev.

[exotic hill]

forgot to push /doh, it's there now.

[turbid quarry]

@exotic hill I've got some kind of conflict with my control sheet and the AP Menu. When I've got my gm token impersonated and the control sheet open (which I almost always do, unless I'm impersonating a pc)... every time I click on a door the ap menu flashes and closes. Door stays at 100 opacity. This is new...

You make any changes to the oCS?

[exotic hill]

No, not that I recall, the big edits where around the locks and isOnActionPad. Config changed a bit but I tested the transfer . . . Let me try to duplicate that (does the PC token have any keys, etc)?

I made several changes to the door overlay . . .

added "too far", and some better selected and impersonated token checks.

[turbid quarry]

If I impersonate my gm token with my control sheet closed I can operate the door... it's only when my control sheet is open that there appears to be something it's doing that triggers a close of the ap menu when selecting it. It's got an ocs of its own running to interact with other tokens...

but it doesn't know to close any overlays so it's something being triggered within the ap ocs... or ap menu...

[exotic hill]

It would imply it's seeing as if another click event?

[turbid quarry]

Something in the ap settings is messing it up... I did a transfer to keep my old settings and it has the issue... but a "new" version does not... I'll start resetting everything and see if I find the issue.

[exotic hill]

I will need to make sure the transfer is working right, that's sort of critical 🙂

[turbid quarry]

Had to reset the apd, too. But after doing that and redoing my settings it's not having the issue. Strange.

[exotic hill]

I'll go through the config macro and transfer macros, I'm missing something in there.

[turbid quarry]

Seeing some other unusual behaviour.
Regular sliding door with nothing on it. It is animated at 0/9 speed setting .

[exotic hill]

What direction are you animating,green or red (or blue or red)? Blue/Green is one way, red is the other way

[turbid quarry]

I figured out the issue... when the impersonated token is selected and I open the door it opens quickly... if they are not selected and I open the door it opens much more slowly... like it's not using the settings if it's not selected.

[exotic hill]

impersonation shouldn't impact the door speed tho.

[turbid quarry]

Impersonation isn't. Selection is.

[exotic hill]

Neither affects door speed tho.

[turbid quarry]

Check it on your side with the 0/9 setting (fastest). Impersonate a token, select the token (make sure it's selected) and open the door. Deselect the token (stay impersonated) and then click the door. It opens slower.

[exotic hill]

Zero isn't possible, it 1-9 (I removed 0 🙂 ).

0 is 0 pixels so yeah, if you didn't run config and the old setting of 0 is there, I could see some issues LOL 🙂

[turbid quarry]

This is the new one without transfer settings.

[exotic hill]

Let me try 9 . . .

[turbid quarry]

0 time delay/ 9 increment is the fastest setting, correct?

[exotic hill]

It all works right for me, 0/9 0/1 What is the color of the animation icon in the designer when you highlight that door?

[turbid quarry]

blue

[exotic hill]

Click it again to make it red, and what does that do when you test the door?

[turbid quarry]

spins the long way around. when selected it's fast... when not selected it's slower

[exotic hill]

I thought you said a slide door (that's what I've been testing), Let me do all the tests with a swing.

[turbid quarry]

I did... sorry... I fumbled that line and hit enter before I wanted to mid thought.

[exotic hill]

0/9 0/1 both work on my swing door, it's not jumping to any position.

[turbid quarry]

it's not jumping... it's just slower.

about half speed

[exotic hill]

Time delay is the number of seconds the increment takes place
Increment is the number of pixels the door moves when the increment is trigged by Time Delay.
It is a busy loop (as JS timers are dis-allowed).

[turbid quarry]

So how does having a selected token make it faster?

[exotic hill]

This is the only code in the door animation that even looks for or somehow uses selected()

    [h, if(tokenid!="" && rev_FOW),CODE:{
        [h: map = getTokenMap(tokenid)]
         
        [h, if(rev_FOW==2 || rev_FOW==3 ): restoreFOW(map)]
        [h, if(rev_FOW==1 || rev_FOW==2 ): exposePCOnlyArea(map)]
        [h, if(rev_FOW==3):    execFunction("exposeAllOwnedArea",json.append("",map),1,"not-gm")]
    }]```

So it would make no sense to have that make it faster 😦

[turbid quarry]

I have the reveal fow option set to 0.

try that

[exotic hill]

Wow, that's a lot faster, but not too shocking.

[turbid quarry]

I am actually still having the problem with the AP Menu and Designer options (not the whole designer, just the options that show below it) closing when I have my control sheet open and I click on a door. I thought it was resolved because I didn't have the "menu always open setting" on the "new" install. Once I have that, I can't open doors or design with my control sheet open. This wasn't happening with 3.6

So I don't think there is anything wrong with the transfer settings.

[exotic hill]

In actionPad_oCS around line 172
[h, if (isOverlayVisible("ActionPads Designer") && oLink == ""): oLink = macroLinkText("APoverlayDesigner@"+this,"",apType+","+oneToken) ; oLink = ""]
change it to this
[h, if (isOverlayVisible("ActionPads Designer") && oLink == "BOB"): oLink = macroLinkText("APoverlayDesigner@"+this,"",apType+","+oneToken) ; oLink = ""]

[turbid quarry]

Didn't change anything.

[exotic hill]

It would have made the designer fire off twice, was thinking it may help keep it open

[turbid quarry]

My ocs for my control sheet doesn't do anything but reload the sheet on a new selection since it displays different things with different types of selections.

[exotic hill]

stabbing a bit now but just curious if you forced a delay,
line 17 execLink(oLink)]
replace with
[h, if(oLink!=""): APdelayMS(oLink,200)]
(edit, you would NOT want to keep this in there anyway)

[turbid quarry]

just checked there is no difference between the newest and 3.6 osc... so the issue is elsewhere

[turbid quarry]

if I turn off the deselect, the options that pop below the designer stay open... but the ap menu does not. but I think something is definitely firing twice... on a door without the ap menu, the first time i click on it, it opens and closes... then it will work correctly after that. (I reverted the code you posted above that would make it fire twice so that's not it.)

I have to run, I'll check the git later if you've got anything you want me to try out.

[exotic hill]

The ap menu will only stay open if the flag is set in config, OR if there are options on the door more than open/close OR if the token being detected has a keyring OR if you're a GM and NOT impersonating.

[turbid quarry]

Flag is set. There are extra options on the door. The AP menu stays open when I'm impersonating a token. It stays open when I'm impersonating my GM token and shows the gm lock/unlock options (as it should, not sure why you said it shouldn't). It stays open when I have nothing impersonated (because it assumes I'm the gm.) All of that is as it should be. What is not as it should be is that it closes when I have my Control Sheet open (which means my GM is impersonated.) This all worked as it should in 3.6. It does not work in 3.6.1. I guess you can try making a dummy frame5 with an ocs that reloads the frame five to have it up at the same time to see if that's the issue... that's all the ocs on my control sheet does. And, again, this worked fine in 3.6 (still does, I can swap out the libs and it's fine) so something in 3.6.1 is the problem.

And it's not the 3.6.1 ocs because nothing changed there.

There is other funky stuff happening with my control sheet open when trying to open a door without any extras... I select it, and click on it, and it opens and closes (both). If I keep the selection it will work correctly from that point on. But if I deselect and click on it again, it will do the open/close again. So selection is part of the issue. And, again, works fine in 3.6.

It's too bad git can't track changes between two versions... I'd do a more thorough code review of the changes and try to be more useful figuring out the problem.

[exotic hill]

The other major changes were made in apOverlayDoor, I'll have to look and compare

[turbid quarry]

I looked at apOverlayDoor and tested the changes I saw and that didn't seem to be the issue.

[turbid quarry]

@exotic hill Ugh. The issue appears to be with changes you made to onChangeMap. I have some functions in my controlsheet that are pseudo functions of functions that, currently, do not support the mapID. In order for my controlsheet to stay tethered to a particular map while I'm viewing another map it will switch maps, pull values from the anchor map, and return to the map I am currently on. But even if the function was run on the "correct" map it was triggering a redundant setCurrentMap function that normally does nothing... but it turns out that even if a map does NOT change, setCurrentMap will trigger the onChangeMap event... and thus, your new 3.6.1 oCM would close the ap menu overlay. 🤦‍♂️

[exotic hill]

I would never have thought that, I'm glad you found it . .
I added the because I as was doing testing, I had the door overlay open, switched maps, and it remained open ,clicked it and got an error to chat. It's one line you can remark out or if there is a check I can do that would mitigate it.

[turbid quarry]

I was able to modify my functions to avoid the issue. I do wonder if onChangeMap should be modified to not trigger if the map does not actually change though.

[exotic hill]

I don't know about that because you are changing maps . . .
I could add small "check" in there with a 1 second delay that checks the maps a second time and if the mapname is still "new" then do XYZ.

[turbid quarry]

I wasn't changing maps though. You can test it yourself by opening the ap menu and then running a macro with [r: setCurrentMap(getCurrentMapID())] The onChangeMap event will trigger.

I understand why you put the check in the AP oCM so I'm not expecting you to change it... It just caught me by surprise that the event would trigger without actually changing maps so it was like the last macro I checked. 😉

[exotic hill]

But that is changing maps, just because you're doing it so fast and in one code block doesn't mean it's not happening.

You could add the mapID code bits (if the function you're using is supportive of it)

[turbid quarry]

I don't see that as changing maps. It's the same map.

[exotic hill]

But why call it all at then?

[turbid quarry]

I didn't need to. I just had the call at the end of the functions so I didn't have to have it in both sides of the codes block earlier in the function.

I was able to take it out without consequence... but it still showed that if you setCurrentMap to the map you're on, onChangeMap triggers.

[exotic hill]

The function invokes the exact same internal MT code stream that is used when the map changes so a fix is probably doable in the core MT code vs macro code, if you want to put in a bug/report on it, I should be able to "fix it". The odd thing is, that code block (MT code block), doesn't pass the prior mapID so it may seem easy but I need to get a "compare" in there somehow . . .

It maybe easier in macro script actually as it's one IF statement vs trying to create more params to exchange in the core code.

[turbid quarry]

Yeah... the argument could be made that having the functionality of using setCurrentMap on the actual current map to "refresh it" is a feature... but, then is onChangeMap supposed to ignore that? I dunno. This is a real corner case and only happening because of my hacky way to wrap entire macros with a map change check at the front end and a switch at the end (which was redundant some of the time because the macro wasn't on a different map.) I was getting rid of that wrapping with the psuedo functions...

[exotic hill]

Actually that's going to chicken/egg loop me :).
When I made that function, I actually tried to include the prior mapID but in this MT code block it doesn't care or want to know any "prior" ID's, it's building the new map full stop, (new map is whatever ID it was given, so the map is being re-rendered). It doens't look for, or allow a parameter to be passed for "prior ID".

onChangeMap actually triggers AFTER maptool created and changed to the new map.

[turbid quarry]

Not sure if you're not getting what I'm saying... onChangeMap triggers if you "change" to the map you're on.

[exotic hill]

Oh, I get it. but that's how it is supposed to work. When you setCurrentMap that function, will redraw the map, newly changed to, or existing, that function calls the "build map MT code". MT is re-rendering and doing all the same work if the map did NOT change. It doesn't and there isn't, a way to check "current map id" vs "new map id" in that entire core code block. It does what it's told, re-renders to a new map even if new is the current.

Just like when you rename a map. It actually copies to a new map (retains the ID), deletes the old map, it doesn't "edit the map".

[turbid quarry]

Ok. Then it can't be avoided. But, previously, a redundant/harmless setCurrentMap to the current map didn't do anything... now it triggers whatever onChangeMaps are in the campaign. 😉 It just so happens that the AP is the first lib with one of those in my framework.

[exotic hill]

That is why I *couldn't * pass oldID and newID via macro.args. I wanted to pass two ID's when I made that function, old Map ID and new map ID, (I'm sure Rev, KW, or Craig could overcome this) but I tried a number of methods to pass old/new because I wanted to have the "scripters" have an option to compare old to new (and also share what map you came from).
Maybe put a FREQ on extending onChangeMap to include prior mapID and I'll ask the big boys for some help 🙂 )

[turbid quarry]

Not sure I can articulate the ask as well as you. I'm glad to have the event as is, but haven't used it yet.

[exotic hill]

I can put one in 😉

[turbid quarry]

Tested the chk_BRK flag and it disabled the door. Do you have an idea for an image? I'm thinking you could use a simple "Disable" sign (circle with a slash through it.) And I think "Door is Disabled" over "Door is broken" is a better description.

[exotic hill]

Here is my door break, not sure I like the look tbh . . . The circle / slash combo fills up so much space you can hardly tell it's a door
I'm also (and what I've gotten a bit side tracked on) is added this other token to create Lib:PlayerName tokens if one does not exist. I'm finding several other advantages in breaking out the lib tokens to separate user databases

I also completed that FREQ for prior map ID in onChangeMap but it exposed what looks like a different bug. Waiting for some feedback from the Boss 🙂

[turbid quarry]

Yeah... I saw that. I worried I might be sending you down a rabbit hole with that one...

[exotic hill]

here's the new Door Config menu (and I've cleared the top row for icons from the top Gear Cog menu)
I'd really like two or three check boxes to cover a variety of "states" as of now, if it's checked, the icon will show up on the door overlay along with whatever detected icons would show (like key lock, etc).

[turbid quarry]

Send me the base door icon and the lock variant. I'll make a "disabled" version that's like the locked version if you'd like.

[exotic hill]

It's done already :p, I tweaked the width of the slash

[exotic hill]

v3.6.3b is up, and there are a ton of changes. I want to start moving things over to the new LibPlayerToken method soon
@turbid quarry I think most/all of the items you highlighted so far are "fixed/corrected". Please let me know if you see something out of place.

[turbid quarry]

If the AP Menu is open when you change something in this input it should refresh/update the AP Menu.

[turbid quarry]

I put some feedback on the git for the disabled feature. As for moving to a lib:playername method I don't think you should force that on users... it's just another layer of complexity that some just aren't going to want to deal with. I do, however, think it should be an option for us to decide where the player token specific ap json is stored.

• There is an "onMapChange mapID" broadcast going to chat for each map change. (this helped me find one of those situations where I was still harmlessly firing a redundant setCurrentMap though, so you are forgiven)

[exotic hill]

I forgot to remove / remark that line onChangeMap line (as I was doing that testing for priorMapID)

[exotic hill]

For the lib:playername, I was going to look for an existing token and if found announce via a Dialog that'd I'd be writing to the LibActionPads property of that token, If one was not found I was going to prompt to create one with clarity for the why, if they say "no" then it will default to the main lib:token.
I have other lib tokens that will require this though (eg. LibDiceOverlay). Also, as a side note, I'm slowly but surely updating Meleks framework to be current and intend to use Lib:PlayerName tokens there already.

[turbid quarry]

Sounds reasonable.

[exotic hill]

Demo of the disabled doors and GM awareness via mouseover disabled icon

[turbid quarry]

So in order to tell if a door is disabled, as a gm, I need to open the door ap menu, hover on the disabled icon, and then wait for the 1 second delay tooltip to show me it's disabled? No worries. Just give me an "On_Disabled" macro trigger in your "Macros on Actionpads" and I'll trigger a state locally.

[exotic hill]

I'm open to other ideas, I can change the actuator to the doorDisabled icon too. Changing the icon tells everyone that can see it is all (but same as locked doors).

So no you don't have to wait those terrible 1s delays /evilgrin LOL

[turbid quarry]

It's not the 1 second. It's the fact that I can't see it without clicking on the door and then hovering. That's kind of useless.

[exotic hill]

It's an easy change tbh, keep the dialog pop-up?

[turbid quarry]

Heh, I don't love the dialog popups... they're kind of intrusive... was going to put in a freq to start using overlays to show these notices (that will fade or disappear on click.) But, in general, I think that "yes" there needs to be some kind of confirmation of actions when you do them.

I'd say use the chat window... but that dings and gets in the way of door sounds, etc.

[exotic hill]

You're talking about in this area

[turbid quarry]

I don't think that will work because the ap menu closes after actions. I was thinking of a general overlay notice of what's going on... it can pop up, fade and close (or you can click and close it... same a dialog but nicer and less intrusive... and will "go away" on its own.)

[exotic hill]

That just pops up in the middle of the viewport or *located * someplace?

[turbid quarry]

Would be better if it could pop up closer to the door... but don't know the logistics of that. You're the overlay specialist. 😉

[exotic hill]

I could see the value in a udp short-message fade overlay textbox in a few places, lemme chew on that 🙂

[turbid quarry]

K. I have to run... look forward to seeing what you come up with. 😉

[turbid quarry]

@exotic hill Is putting in an "On_Disabled" macro hook on your list or should I put up a git freq for it?

Also, do you have a simple UDF included that we can run to check the flag of the ap json settings? Something like ap.chkSetting("lck") It's, obviously, easy to make this... but it would be nice to have it part of the lib for people writing macro hooks.

[exotic hill]

Would the on_disabled macro run after the icon changes to disabled?
There is an on_Click but wasn't sure when to tigger the on_disabled.

[turbid quarry]

Yes. For toggle type hooks I think there needs to be an off_xxx hook, too.

I kinda thought maybe it already did... but I haven't gotten into it. Just now starting to inquire about it.

[turbid quarry]

What do you think about some on_Add hooks? For example, when the pick lock icon is added to a door, frameworks could trigger a setup macro to add framework specific information like Lock DC, GM/PC Description, Trap info, etc. That way when the on_pick macro was triggered it could pull that info and run a targeted pick lock attempt (could send the DM/PC info/description, if there is one, and pop their Disable Device skill roll against the DC of the lock, etc.) Same with setting up framework specific settings for on_Inspect. My plan was to build these framework specific setup macros on my side (and I already have most of these proprietary macros in my setup)... but the hooks would allow the AP to facilitate some of the most common actions.

[turbid quarry]

Btw, I see what you mean about this. Sort of like with the On_Open hook. Is that triggering when the icon is clicked to open a door, or when the door has already opened? That's unclear. Should maybe sort those hooks accordingly (ones that trigger before the action, after the action, or have no ap action beyond triggering the macro hook.)

[exotic hill]

I'll admit I'm a bit cautious on adding too much . .. regarding the on_ this or that.
There is an APinterrupt macro that could be used in combo. I'll add the on disabled bit tho.

[turbid quarry]

No worries. It's easy to run a setup macro on the actuator after the fact. On_add would just make it more integrated.

[exotic hill]

on_Add when whould that be triggered?

[turbid quarry]

When you checkbox specific options in the "Configure Door" selector. Like If I checkbox the "pick" option.

@exotic hill Found a strange "bug" that may be an MT issue... but I'm just noticing it in 3.6.3. If I'm on another map and I have something selected... and then I switch to a map with doors and the first thing I click is a door to open, I get an AP generated error message ERROR:APoD - Selected Token not found! I click the door a second time and it works. If I'm coming from another map where I don't have anything selected, that doesn't happen. So it's like the first click on the door is referencing the selection from the other map. Not a huge issue (though it was happening enough to me that I thought something was broken), but I wonder if a deselectTokens function was run before the action if the error could be avoided.

[exotic hill]

I'll check I think that's a me bug

[exotic hill]

That was on purpose actually, it's been corrected 🙂

[exotic hill]

When they're clicked on in the door overlay, (I've not spent a lot of time on that logic tho). I know there are some reasonable improvements to be made 🙂

[turbid quarry]

So on_open is pre open? You click on the door, the on_open macro will run and if it returns a 1, the door won't open? What if the on_xxx hooks don't return a 1 or 0? Will it error out or just continue?

[exotic hill]

On_open should run if the door can accept opening. The part I'd have to check is if it's open and you click open again, will it run again.

[turbid quarry]

Well, now that you have a state check to see when a door is open, you can not show the open door icon when the door is open easily. 😉 So you don't have to worry about that.

Just don't add the open icon to the menuButtonHTML when the door is open.

Same can be done with cracked and closed.

[exotic hill]

new beta up that has those changes and the on_Disabled features and some other tweaks

[turbid quarry]

@exotic hill The onLock and onDisable hooks don't stick when you set them (they blank out).

[turbid quarry]

Also when the door is in the cracked position the cracked icon is still showing in the ap menu. That might be ok if it functions like I think the "default" way of "cracked" should (see the new freq I put in.) 😉

[exotic hill]

That should be an easy fix . . .(done, I missed 2 lines to save that variable)

[exotic hill]

I had a typo in the state check (it's peek was looking for crack) and ugg your FR 😉

[turbid quarry]

@exotic hill Is there a way I can initialize a new door outside the context of the APoverlayDesigner? I'd like to automatically add that step to my "Deploy Door" macro before triggering the Designer (so that I can apply presets.) I could do it after the fact at some point like when I first open a door, but that's hacky.

[exotic hill]

Yes, most likely, I could also take 10 mins to create a doorStamp macro that does the macro bits or whatever bits outside of open close and crack (as those require a manual touch anyway).
A side note on this part since I started this in 1.11.5, the door objects retain the map coords poly of where MBL/VBL was when the door was made. If you're not properly cleansing a door when it's made, if for whatever reason the force-MBL checkbox is checked, you'll start finding MBL,VBL getting stamped on the map at the x,y coords from when the original door was made (hope that makes sense).

I'm looking now, I think the best bet would be doorSet_New that is where the door copy detection code is. Again though, IMO it would be a lot easier to create a macro, that lets you select one token as a template, and then select any or deploy to all doors on the map. Trying to force your way into the code mid-point . . . not something it's designed for.

Is all you're trying to do is have one "good door" and make Mac, Snds, etc. I would strongly advise NOT coping the *BL, sub-jsons as part of this.
What part are you wanting to deploy on "all doors"?

[turbid quarry]

For starters, the "padMacs"... I took a look at doorSet_New and tried a few things... but could not get it to do what I wanted... and I don't want to change code or make something that will break if the core lib changes. So I was hoping there was a simple way to trigger that macro properly.

[exotic hill]

I can add a new macro called padStamp that offers the copy/paste of "things", using dialog so you can set a "source" and do a mass select of destinations

[turbid quarry]

There are other changes to doors I think I can do outside the designer too... like "disabling" a door... or "locking it" without a key, etc.

[exotic hill]

Most of this is doable outside of AP designer, I made a UDF called editActionPad and an APcontrols to help integrate to other macros, etc. (neither are complete becuse I never got any feedback or additional use cases).

[turbid quarry]

Not really necessary. This won't streamline anything for my use case. I know I can apply changes to padMacs after I initialize the door through the designer.

I just wanted to see if I could initialize the door and make the changes at the same time I drop the door image, before I fire up the designer.

I could create the LibActionPads prop and set the padMacs and other settings... but I'm guessing that once I hit "New Door Template" it'll overwrite it.

[exotic hill]

Not if it was a copy of a prior working door.

sounds and macs are retained

[turbid quarry]

I can have my deploy door macro pull up all existing doors and use copies... but the reality is that anytime I make a "new" (non copy) door I'll still need to make those default transfers.

[exotic hill]

I wouldn't ever make a new door once a master door is made, I would only ever copy/paste. (but that's me 🙂 )

[turbid quarry]

and when you want to make a door that's not a "master door"?

[exotic hill]

an example of that scenario?

[turbid quarry]

well, since I think we might not be talking the same language, if there is only ONE master door why are you fighting just making it DEFAULT.

[exotic hill]

I can't think if a reason to ever create a new door for YOUR use case. I don't want to force this use case to everyone or have another touch point to do this or that. There is a solution in place today.

[turbid quarry]

If I key a door, is that a good door for me to copy?

[exotic hill]

Yes, and the key gets flushed because the key has to be generated AFTER the door is made because it retains the tokenID of the source door it was tagge to. Keys can't be copied regardless.

[turbid quarry]

what about changing the image asset of the door? how do I do that after a copy?

[exotic hill]

drag and drop the image through token properties menu.

[turbid quarry]

so open the config... use mt's library or file explorer to find the new door asset... and then drag it... I don't have to do that. I've built a much better way to find the door image I want and drop it.

[exotic hill]

Sounds like a great fix then 🙂

[turbid quarry]

It's incompatible with your cut n paste method

[exotic hill]

So you've got a tool that pulls a token image, and you can't place that asset ID on the new door token?

[turbid quarry]

Will it go in at the right orientation? is it the same dpi as what it's replacing

[exotic hill]

DPI makes no difference. Token size makes no difference, you can free size a door if you wanted to.
AP has an absolute mandatory requirement that all doors default to hinge on the left and knob on the right. The image has to align with that requirement.

The RAW source image, not a flipped, or somehow changed image AFTER it's in MT.

That is why I took ALL the old images the MT offered where ALL the doors were DOUBLE WIDE to support BOT, I changed to be "normal" / standard.

[turbid quarry]

If you drop an image freesize the dpi certainly does matter

[exotic hill]

It should have no affect on a new door that hasn't had the open close crack states set.

[turbid quarry]

oh well... we're talking past each other in how to do things... you're minimizing steps/methods that I find onerous or annoying to repeatedly do... so I'll just build things on my side that make things easier for me. You've made a lot of nice improvements lately so I'll just focus on bug fixes (if I find any) and getting things working the way I'd like on my end.

[exotic hill]

I don't know that you're getting the copy/paste method and how easy that is, but /agree, we're good and still want the feedback 🙂

[exotic hill]

@turbid quarry I tell you what, help me help you . . . you create a macro group that is a copy/paste of the APinterrupt macro for all the on_??? hooks in padMacs, and I'll make the code to run those first (paste it here or im me)
I'll probably just run these hooks first and additively run the macs held in padMacs . . .

[turbid quarry]

Heh, I just got my deploy doors macro working fine now... I realized I didn't need the full "initialize" action on the doorSet_New... just what it applied when clicked. I should have just looked at a token in that state to begin with! 🤦‍♂️ I then could just add the extras and the Designer handles it just fine so long as I set the flags, too.

I'll take a look at APinterrupt... I know you've mentioned that a couple times but I'm not sure what it is.

[exotic hill]

it was more, create the 12ish some on_?? macros and get that macro group exported and sent to me 🙂

[turbid quarry]

ah... ok. I've got them done already... though I have them named like apOnAttack. You just want the interrupt code pasted inside them?

can rename a group on_XXX if you'd prefer... and make the buttons maroon if that's what you'd prefer

[exotic hill]

if you could please 🙂

[exotic hill]

I'll work on it later today.

[turbid quarry]

No worries. I've solved for my use case... but that will be nicer for others to be able to populate right on the lib. I guess you'll need to transfer those on update.

Having the hooks being "additive" is an upgrade, too. 😉

[turbid quarry]

@exotic hill the 3.6.5 download from git is actually 3.5.9

[exotic hill]

I just saw that, I keep forgetting to finish the PR, I also just updated that bug you found . . . so it's 3.6.6

LibActionPads v3.6.6

[exotic hill]

@turbid quarry it's really fixed now 🙂

[turbid quarry]

@exotic hill If I try to make changes to the LibActionPads property inside an on_xxx macro it seems to be ignored and overwritten. Is there any way to do that? We have access to a macro.args json with alot of data on the door in the on_xxx macros, but it doesn't seem like we can modify it and pass it back to the door action.

[exotic hill]

If that property is being written later (and it probably is), it would be my first guess (eg. I didn't used to write back to the door apJSON property but started to with setting padState, I'd say most of the macros run before that state is set because it's one of the last things I do in the ..door_OCP macro)

[exotic hill]

I can probably shift things around and I'm guessing this is only with open,close,and peek (crack), if you can confirm.

[turbid quarry]

Was only trying it with "crack"... would making the on_xxx macros udfs with the same scope make things easier?

[exotic hill]

Let me tweak the doorAction_OCP macro and I'll post it here as a text attachment, I think I have an easier way.

@turbid quarry see if this works. I also added better checking for linked / double doors so it should only trigger once

Something else is if the door is animated, I may have to check that better as I set a flag there to show something is inMotion

[turbid quarry]

It works to write the edits back to the LibActionPads property on the door... but it doesn't affect the behaviour of the action because I think the values the action uses are called before the on_xxx macros...

I am using an animated door (required, actually).

Animation isn't working though (as you suspected)

[exotic hill]

APinterrupt runs when the Door Overlay code is executed. Just noticed it will also on on_Click (so that's probably running twice now, maybe I need to add a on_Click_Door macro ??)
APinterrupt runs again after the icon is selected in the Door Overlay but in the same code block that it read the JSON from (so it can't be changed).

Are you wanting this to run before or after the action succeeds?

[turbid quarry]

Before. I think most of what I'd want to do with the on_xxx macros would be before... but, not entirely sure. Would be nice to be able to set a flag to run before or after... but if I had to choose one, it would be "before".

[exotic hill]

Before that text file above, it was running before 😉 But it all runs in the same block of code.

and I'm not "re-reading" the json after the on_ runs.

[turbid quarry]

But it's got to be using the values in the macro.args it sends to the on_xxx macros regardless of if we try and change them

[exotic hill]

maybe I can add a check on macro.return if it contains apJSON then to "redo" those vars (so to speak).

Let me reset to before the text file and get you a new copy to test.

[turbid quarry]

K... Got to run... got a game starting. Thanks for looking at this. I'm just feeling out what I can and can't do!

[exotic hill]

And you want the new json read BEFORE the door opens (so it would impact if it can or can't open?)

[turbid quarry]

Sending back the apJSON should work.

[exotic hill]

but before or after say, animation starts?

[turbid quarry]

before

[exotic hill]

@turbid quarry I was doing more testing and you can use the APinterrupt macro. To test, make this change on around line 33 in doorAction_OCP

    [macro("APinterrupt@"+this):apJSON]
    [h, if(macro.return==1):return(0,"")]
    [h, if(json.contains(macro.return,"apType")),CODE:{
        [h: apJSON = macro.return]
        [h: json.toVars(apJSON)]
    }]
    [h: json.toVars(padMacs)]    
}]
[h, if(chk_IMG): json.toVars(padImgs)]```
To check whether you're *in the right place at the right the right time*, you can check against the Door Overlay.
It should only be open AND an action taken on the door, during the *right time and place*.
So in your `APinterrupt` macro check for the overlay like this:
```[h: oList = json.path.read(getInfo("client"),"['overlays']")]
[h, foreach(oneO,oList), if(isOverlayVisible(oneO)), if(startsWith(oneO,"ActionPads Menu")),CODE:{
    do all that you want to the apJSON
]}
[h: macro.return=apJSON]```

[turbid quarry]

So I put an apJSON broadcast right AFTER that doorAction_OCP edit you provided and what I found is that it triggers BEFORE the on_Crack macro runs. So changes to the apJSON from the on_Crack macro aren't heeded. (And, yes, I double checked that the apJSON in the macro.return does have the changes I want.) Are the on_XXX macros deferred?

But maybe I'm not doing this as intended... you keep mentioning APinterrupt like I'm supposed to be doing something with it, but that's an empty macro. I thought it was just a template for the on_XXX macros.

The on_Crack macro is running, it's just not returning the modifications I'd like (i.e. not returning the apJSON... and probably not before the crack action happens).

[exotic hill]

Yes, they're deferred. It maybe easier if you share what exactly you're trying to do. I pass vars like what door action to take (open, close, crack) through a different var that's passed from the door overlay.
So I don't know, depending on what you're trying to do, if editing the apJSON data is going to net you want you want. Here is a new doorAction_OCP macro, and this is what I was testing in APinterrupt

[h: oList = json.path.read(getInfo("client"),"['overlays']")]
[h, foreach(oneO,oList), if(isOverlayVisible(oneO)), if(startsWith(oneO,"ActionPads Menu")),CODE:{
    [h: apJSON = json.set(macro.args,"padState","door,open","doorAction","open")]
}]
[h: macro.return=apJSON]```
`doorAction` is the var I use to know if the door should or shouldn't be opened, it's not really part of the apJSON but if you add it, when I `json.toVars` it will *come through*
In the example above, by me setting `doorAction` to `open`, the door can be opened, but not closed .

[turbid quarry]

I'm building the 3-increment crack functionality that I wanted. I'm only part of the way through it because I can't get the change in increment (padF) to apply before the crack action takes place. Seems like it should be easy but since it will not pass the altered apJSON from on_Crack to the door before the door action then it essentially does nothing.

That new OCP is throwing this error on every item click on screen. Error executing "getProperty": the token name or id "" is unknown. Error trace : actionPad_oCS@Lib:ActionPads <<< onChangeSelection@Lib:ActionPads <<< macroLink

I've added the apinterrupt code you provided, too... hadn't tried it with that properly... but the ocp is the issue now

[exotic hill]

I have no idea why you'd be getting any kind of oCS error, it doesn't touch and doesn't run APinterrupt and I didn't touch that.

Are you selecting a token in your code?

[turbid quarry]

Not running code. After I change the OCP... I get the ocs error... maybe a copy paste error I'll check again.

I probably pasted it in the ocs...

[exotic hill]

I was going to say, I'm running that stuff now and not having a problem . . .

[turbid quarry]

ocs ocp... what's the difference? 😉

Ok... am I supposed to be putting a modified version of that apinterrupt at the end of my on_Crack macro?

[exotic hill]

No, only use APinterrupt nothing else,HOWEVER to trigger the "run macs at all" you need to do something like this:

if all fields are blank, NO macros run (No on_... or APinterrupt will run)

[turbid quarry]

Ok... that's not very intuitive. So nothing goes in on_crack except something to trigger the apinterrupt which is going to run all of my Actual on_Crack code? The apinterrupt is going to have a lot going on in it as I build out the other on_xxx macros... I wish everything was self contained to the various on_XXX macros (on_Crack in this case).

[exotic hill]

This is to mitigate your desire to change the APjson before and/or while it's being used. you don't want on_crack because the code as it's written only runs that once the cracking has started.
You want in front of that, not on_Crack_Before :p

[turbid quarry]

Well, as it is, the on_Crack is actually after_Crack. You may as well just name it (and on_Open on_Close) that.

[exotic hill]

Just know that all the macros run after it's committed to that action not before. Right now APinterrupt only runs before in the doorAction_OCP macro. Anywhere else, it's run after commit.

[exotic hill]

When the action is committed, what you really wanted was before_Open

[turbid quarry]

Correct. We need a few more hooks.

[exotic hill]

You got it APinterrupt and if it works, we can talk about moving it up front in the other places

The only other thing the config is missing is a checkbox to run on_??? macs (and this will also run APinterrupt (vs having some bogus [r: 0] code) but not doing any of that if it doesn't work

I tested this and in my example code, I can block a door from closing via APinterrupt and it's not deferred

You could also use APinterrupt to run you on_Crack code 😉

[turbid quarry]

Running into problems... I tried turning my on_Crack code into a udf using the same scope figuring I could then just drop the udf call inside the code you provided... that failed... then I just did a copy past into your apinterrupt code and that failed (had to fix nesting limitation)... fixed that and it's still failing like it doesn't have macro.args... will play around more with it later.

[exotic hill]

FWIW I think the only way you're going to be successful at rewriting the apJSON is to use the APdelayMS function to defer a number of milliseconds (that has a busy loop, after any animation may complete) and this would be required (as I write to the OG json after animation is done ) . It's one thing to use APinterrupt to get in front of something but now you also want to get behind it at the same time . Without getting behind it, you'll never have the crack show back up on the Door Overlay.
You can also keep whatever custom version you want 😉

[turbid quarry]

That's too complicated. I'm just going to go with the apjson not being mutable within the on_xxx macros. I'll find some workarounds. I do think you should rename the open/close/crack "on_xxx" to "after_xxx" though.

[turbid quarry]

@exotic hill Any chance you could break out the "range/reach" check you use into a function that we could use in an external macro? Something like apReachChk(apAssetId, tokenID)

[exotic hill]

Before I go down another rabbit hole, what are you trying to do 😉

[exotic hill]

In my Distance property value I've got this [r: number(listGet(Speed,0))/5] couldn't you put a macro like this [r: reachUDF()] ?

[exotic hill]

LibActionPads v3.6.9

[upbeat nymph]

I found at some point UDFs in properties aren't using currentToken(), so you have to include that in your call.

I found I had to do that for my own distance calculations. [r: pf2.distanceStatSheet(currentToken())]

[turbid quarry]

Things I can't do with the on_xxx macros. Building things outside the ap, but compliant with its settings, means I need to reverse engineer how you do things (like determining distance between your doors and tokens). In this case I can't alter the primary door properties before actions are initiated so the best I can do is make somethig that can outside the ap's ui... and when I do that I'd like to check that the door and token triggering the action are within the reach/distance/range that the ap uses.

I imagine that you use the same methodology for doors, transports, and other elements when necessary?

[turbid quarry]

That doesn't look like what you use to determine when a selected or impersonated token is within range of a door (heeding the two global settings of Distance in grid cells a player token can be from an actuator and Distance in pixels a player token can be from an actuator)

[exotic hill]

I use a UDF named isOnActionPad (I don't recall having any other reach checking or hard coded anyplace)

[turbid quarry]

The second argument is tokDist. Is that a flag or literal? Seems like a flag of some type (where 0,1,2 mean different things)?

The tooltip says it's "distance range" but that doesn't seem right given that the distance range is an ap setting?

[exotic hill]

tokDist is a parameter fed into the UDF. If it's less than the use_DIS parameter from config, then it defaults to use_DIS. tokDist is used in both getTokens functions to find "closest". Of those that are close, impersonated wins, selected wins next, then any/closest PC token.

[turbid quarry]

So it's a flag? Code indicates that it can be <0 ... so I'd set it to -1 to use_DIS (which defers to ap distance settings, I presume)?

[exotic hill]

No it's not a flag, it's a number value used in getTokens range - upto check

[exotic hill]

That's not someting I update often enough 🙂

[turbid quarry]

So can I use isOnActionPad like this[r: isOnActionPad(doorID, tokDist, 1, selected/impersonatedID)] And, if so, what is tokDist? A getDistance() call?

[exotic hill]

0 is allowed because it tells me if there is an overlap (e.g. you're blocking the door)

The door ID isn't the actuator but yeah, you could/should be able to do that

[turbid quarry]

I should be using the actuatorID?

[exotic hill]

That's what I use, it's the apActu entry in apJSON (regarding the object layer door)

[turbid quarry]

The apID is actually the doorID... so I'll need to use apActu

[turbid quarry]

@exotic hill updated to 3.6.9 and it didn't transfer my on_xxx macros over.

[exotic hill]

Never even thought to add it, I'll put it on my list 🙂

I'll do my best to support that but it has to work through a getMacroCommand so I can write it again. I know I've had problem reading some macros in that way due to how quotes, doublequotes, etc are handled.

I'll have to test it.

[turbid quarry]

@exotic hill Should the designer ever be autoloading on door actions?

[exotic hill]

No, and I did see that but I couldn't recall the steps I took when I did see it. That should be an easy fix 🙂

[turbid quarry]

I think basically any open/close/crack action taken from the ap menu seems to trigger the designer... and my on_crack macro isn't working in 3.6.9 (though it does in 3.6.7)... not sure what the issue there is. it pops an overlay... but the overlay won't pop in 3.6.9.

[turbid quarry]

@exotic hill Btw... if I stick my on_Crack macro inside the on_Pick option and run it from there... it works in 3.6.9 ... it just no longer works in on_Crack.

[exotic hill]

on_pick only executes a macro, it doesn't do anything. On crack does something, it cracks a door open.

[turbid quarry]

I understand. I'm just informing you that in 3.6.7 what crack does doesn't get in the way of what my on_crack does. 3.6.9 broke something in that regard.

[exotic hill]

yes, I keep moving when the macros run to accommodate your desires 😦
eg. they don't run in the same place, because of the ask several posts up from here LOL

[turbid quarry]

But, unfortunately, it didn't accommodate the ask and it broke something... so I'm letting you know you need to revert.

[exotic hill]

truth be told, I have regrets adding the on_ at all 😦

[turbid quarry]

You shouldn't. It''s very powerful.

[exotic hill]

Moving those macros in code is a PITA and there is no promise it will work. If you're macro is 2 deep and I try to right that code while I'm one deep, I've had that fail. So no worries if it is simple stuff, like running another macro. But now I have to support or deal with folks that want to code deep in the on_ macros and I don't know that it will work that way.

[turbid quarry]

I'm betting the "problems" come from what open/close/crack do built in. Your apcontrols function does the "Action" without creating problems with the on_xxx macros (so far as I can tell right now). If you just drop those function calls into the on_close/open/crack it'll do just what it does now with a lot less risk of problems (at least that's what I'm finding.) It's a very simple solution and you've already built the infrastructure.

[exotic hill]

Once I get the code done for transferring the on_ macs, I going to want everything else tested before I do much more, doors with force drawmbl (not sure this even works now), windows, drawbridge, keyhole peeps, etc.
A ton of recent change for just doors without testing anything else and only one type use case.

[turbid quarry]

Understood. I guess all the more reason to revert the changes you made to try and accommodate editing the apjson in the on_xxx macros. The update to putting default on_xxx macros on the lib is a good one. Without the on_xxx macros all the other features (pick, knocks, inspect, listen, etc) would be kind of pointless. If you think the on_open/close/crack hooks are a risk take them out... if people want they can create their own separate open/close/crack macros that won't conflict with the built in "default" methods.

[exotic hill]

No, because if you had used a "standard door" that met your specific needs, with those macros would have been baked in the door.
I'm not saying they don't provide benefit, but the needs or lack of use, etc is an opinion or position you're in due to what I'll bad practice working through retro fits 🙂 (you know about opinions tho 🙂 )

just the audio alone or how a wood door vs a steal door, that makes less use of on_ macs. It all depends on where you're standing.

[turbid quarry]

Without the on_xx macros what's the point of the "pick" icon popping up in the apmenu?

[exotic hill]

It would run the macros you set here.
If you check the pick option so it shows on the door overlay, it doesn't do anything, the on_ macros didn't enable anything. IMO it just allows a one stop shop to make all the doors the same.
So again, if you had "done it by the instructions" this entire macro issue, would have been a non-issue. I'm just trying to help you fix your bad choice 😉

[turbid quarry]

I can't even follow what you're saying. The answer to the question is: Without the on_xxx macros, the buttons do nothing. The on_xxx macros exist to give them functionality.
What "bad choice" did I make?
And what "instructions"?

[exotic hill]

That's not a true statement. Hopefully this is more clear.
on_ macros provided no value except a one stop shop. A place to enter and run macros existed BEFORE (see image above)
Bad choice was you chose to not use a door template, (and for the life of me I still don't understand why), and instead, it seems like, you created a bunch of doors, then wanted macros on them, didn't want to modify the doors one at a time, so you put in a FREQ (and that's fine and I'm ok obliging when I can).
Video link of where this is mentioned https://www.youtube.com/watch?v=svNanE0mjP4&t=1966s
Personally, when I wear my map maker hat, I'll probably never use on_ macros as I'll do the proper way and make a door template with ALL my macros and features copy/paste where-ever I want a door (and change the image or whatever else is unique to that door).
At the end of the day, from where I'm standing, all these did is add confusion and complexity. Now there are two places to run macros on doors when there was only one. Now there is more complexity during upgrades, because I can't promise macros will migrate gracefully.

[exotic hill]

Another point, is you could have used APinterrupt from the beginning (probably still require the change I made to move it up and pass the json back). APinterrupt by itself, you running any macro of your choice from it, would have been adequate. There would be no need for the on_ macros. You can easily see and digest the json and route, process, do ANYTHING you wanted through that one macro. . .
The more thought i put into this, I may back out all the on_ to reduce the complexity, move the APinterrupt to the top allow apjson pass back and KISS.

[turbid quarry]

For clarity's sake... I never said they didn't exist "before". They existed before you added the DEFAULT on_xxx macros on the lib. But they're the same thing, whether it's on the lib or not. You indicated that the on_xxx macros were a regret... not that adding the second additive on_macros were a regret. Your picture above literally says "On_xxx" for each macro and that's the previous implementation... and without them most of the buttons do nothing.
I asked for templates in a freq and your solution was to use cutnpaste. I think that's a bad implementation. It's great that the tool supports cutnpaste, and it has it's place. But I just don't think it's a good method of deploying, building, and managing doors across maps.
I also didn't "want macros on them." I wanted the option to have DEFAULTS because once I built a macro to "Pick Lock" it would work on the vast majority of them. And without using the cutnpaste method, I was stuck manually entering the same links anytime I made different doors. All I wanted was for you to save default links somewhere. Instead YOU opted to create two separate locations to build two macros that would run concurrently (the "default" and the "unique per door" on_xxx macros). I thought it was a rather innovative approach and was additive.
I do not agree that it added complexity. It simplifies adding simple on_xxx functionality for people that don't know how, or want, to manage a second lib:token.
The complexity came when I asked about modifying the apJson within the on_xxx macros and found that I could not do it before the open/close/crack door action. And it would have been the exact same complexity whether it was being attempted from the ones on the lib or the ones I'd already built off the lib using the previous method.

For some reason that I can't quite grok, we seem to have communication problems sometimes. Probably because we have different design philosophies and because I'm approaching it from a user point of view (outside-in) and you're coming from a developer perspective (inside-out). Things can get tricky when trying to get in alignment. I wish you were getting more user feedback so it wasn't just two voices coming at it from different vantage points.

[exotic hill]

So, where I'm at . . .
I've not taken out the on_ macros (yet) but extending the use of APinterrupt and it will now always run (so you don't have to have an "active macro" in the macros input...I still have to deal with moving that one but I'll extend the help and advise it should be one line calling another macro)
APinterrupt will be passed specific actions , if no action is found, then it's being run AFTER the action completes (or in animations case, animation begins). Examples of data that will be passed to APi..
a before example (I can supply a list of "actions")
{"action":"overlay","tokensel":"80EBD3F08F3B455B9E532A8F66913ECD","apJSON":{"apType":"door","apID":"4492BFF47A59426B92A37C368881801F","apStates": more data ...
The above example fires off BEFORE the door overlay allowing you to impact what appears on the overlay . . .
an after example
{"apType":"door","apID":"4492BFF47A59426B92A37C368881801F","apStates":more data ...

[exotic hill]

an example of the only thing you need in APinterrupt

[macro("APmanager@Lib:myLibToken"):macro.args]
[h: returnData = macro.return]
[h, if(json.contains(returnData,"apType")): macro.return = returnData ;  macro.return=0]```

Then just have your APmanager macro on your Lib token with a switch based off action

There is an action for every on_ macro in lower case (so far)

I know this doesn't solve the initial ask so I'm still chewing on that (as I've got on_ regrets LOL), however, this use of APi is far better and more powerful than the on_s are.

I'll add a tab on this input to let you set Defaults 🍻 (macros that is)

[turbid quarry]

I kind of feel like you're solving a more complex issue so I'll just have to adapt to what you do here... at this point I'm fairly certain I can build just about whatever macros I need using the "dumb/do-nothing" on_xxx macros and the APcontrols function. For example, my 3 increment crack door macro works just fine when I don't try and shoehorn it into on_crack.

[exotic hill]

TBH I think the only change I really want to make now is remove the on_ , put up the added tab in the above input to allow for "default macros". Using APi over what you have is up to you and sounds like you've got it working.
I'd expect the only change you'd have to make is moving whatever macro you have on any on_ macs, to the new defaults section . .

[turbid quarry]

fyi, the tooltip on the key/lock icon says "listen"

[rare ether]

@exotic hill Over in another channel, there was a question about PC tokens getting stuck inside a wall when the boundary blocks of VBL are close to each other. Does this drop-in have a way to execute a macro on a token when it crosses the threshold of an area to (1) turn off snap-to-grid and (2) change the token size?

Assuming a suitably defined “threshold area”, of course. 🙂

[exotic hill]

I'm not sure I fully understand, I do support no-snap tokens against ?bl that exists on the map. No-snap tokens can't see ?bl on tokens though. I use a threashold of 10% less the token size (assuming it's not rectangular and is square).
I can also see where in your "path" you've hit a blocker. I don't know that I could determine if a PC token was in place and then a line of VBL was drawn through them, I could probably detect that though because they couldn't move at all

[exotic hill]

@turbid quarry v3.7.1 is up. I have an open item (I'll put it on github) around transferring still where the macros aren't moving, yet (and hopefully it will be just the two APinterrupt and APsounds (and sounds I may just remove all-together, I doubt anyone every used it)).

[turbid quarry]

I have sounds for actions in my framework, so I was just adding sound triggers to the on_xxx macros (i.e. playSound("Door Open")).

[exotic hill]

So it sounds like I need to do default sounds like default doors (re: macros)?

Also, the default macros will take second place to specifically set macros on the door objects themselves (so not additive)

I hope you'll like the APinterrupt changes if you find the use of it vs the Default macs.

[turbid quarry]

I think that would make sense, especially since sound links in mt can require updating (though my dropbox links have been working fine for years)... but if a link breaks, going around and replacing a whole bunch of links individually would be a pita. Changing one single default that handles most doors would be not so bad. I do wish I could call a udf in your sound ui though... since I manage my sound links elsewhere.

[exotic hill]

If you didn't use the UDF and used the macro itself, I'm thinking that should work (depending on variables, and udf requirements)

[turbid quarry]

I'll be trying it later using the code you supplied above. I'll let you know how it goes... If that apinterrupt code is what we should be using, you might want to allow people to set their "off token lib name" (mine is "Lib:AP_Extra") in settings and have the apinterrupt pull the setting.

[exotic hill]

This is what's in there now, in hopes to set that example:

[h: remarks = strformat('

[macro("APmanager@Lib:myLibToken"):macro.args]
[h: returnData = macro.return]
[h, if(json.contains(returnData,"apType")): macro.return = returnData ;  macro.return=0]

')]

[h: macro.return=0]``` (Is that what you mean? )

[turbid quarry]

I was planning on that... but then I have to use non-default macros (without the sound calls) if I want to use unique sounds. Not that big of a deal (should be rare).

[turbid quarry]

I'm supposed to build a macro called APmanager with a switch for each door action, right? But in that apinterrupt code, it assumes the APmanager macro is going to be on "Lib:myLibToken"... you can allow people to set the myLibToken name in settings and pull it from settings so people don't have to edit that macro.

[exotic hill]

That is example code, it is NOT meant to be used at face value (and is why it's remarked out). If you're going to use APinterrupt then there is an expectation that you know what you're doing (e.g can code in MT more than newb level) I would say most folks wouldn't need or want to use it at all.

[turbid quarry]

TBH, I understand that the point of this is to inject custom code at a different part of the built-in actions for open/close/crack (and maybe peek)... but, essentially, I'm just going with the flow. You tell me I have to use this to get in front of an action, then I'll use it. But I'm not going to pull that code out of thin air to get it to work... and if it doesn't work I'm also not likely to know why it's not working because I don't know its limitations.

[exotic hill]

I don't know how I can help resolve this though. I can add a bunch of text in that strformat section that states this is example code and there is an expectation you know how to understand JSON structures, MT scripting language, Library tokens and add-ons. If you do not know these things, do not use this

It gets in front of every door action. I'll likely set it to get in front of everything.

My ask is to look at the json data it passes (cuz you're not a newb) and tell me it looks good or I want more, etc?
eg. I'm passing action on the before and not on the after (so you know when it runs, before, or after, so you could alter things in both before start or after finish).

And to be clear, I think few or almost no one will use APinterrupt . I do not want to make it easy to circumvent the process without knowing what you're doing.

[turbid quarry]

You could put the json structure somewhere with some guidance. I mean, before I tried to modify the libactionpads prop and apjon I formatted them in a more readable structure to see what was stored and what I could possibly do. And, also to be clear, I'm fine with not using apinterrupt. I can use the on_xxx macros (or whatever you're calling them now) with the APcontrols() function... that gives me a lot of control over the order of operations.

[exotic hill]

but I'm dumping the on_ 😦

I was expecting you to move custom default macs to here:

[turbid quarry]

both the new ones on the lib and the original implementation? so no on_xxx macros?

[turbid quarry]

you were calling those On_XXX macros before

[exotic hill]

My intent was to delete all the on_ macs, provide you the option that you first requested, in hopes that meets the same requirement.
The APinterrupt is all about "advanced users"
I have NOT removed all the code for on_ macs yet but intend to.

[turbid quarry]

so what are the "set default macros"? Those aren't macros that fire "ON" clicking those door action icons?

[exotic hill]

Those are the replacement on_ macs.
I don't know that you would want to use both, you may just use APi for your needs, as they're special 😉

[turbid quarry]

I don't understand this syntax issue. Before you added a second set of concurrent on_xxx macros to the lib (which was not what I was asking for) each token had unique on_xxx macros. Now you've gotten rid of the on_xxx lib macros, but have "default macros" which I assume are just links to off-token on_xxx macros (which IS what I was asking for). You've indicated that they are not concurrent with the token specific on_xxx macros that are still on each door. But, regardless, they are ALL on_xxx macros. Whether on the lib, unique/token specific, or defaults... they're all just links to on_xxx macros. So if you say you're "getting rid" of on_xxx macros then that means no defaults, no unique on_xxx macros, no lib on_xxx macros. Can we at least clear that up?

[exotic hill]

I'm pulling out ALL the code that every used any portion of the maroon on_ macros. I'm deleting the maroon macros off the AP lib token.
That code will no longer exist as if it was never implemented, never say anything about the maroon on_ 🙂

[exotic hill]

The code that was used before maroon on_ macs existed is the exact same place that the Default Macros OR the custom door maros will run

[exotic hill]

For your purposes, that is "advanced", I would advise you ONLY use APi and route to your lib token for apJSON handling.

So the AP lib token has a set of default macros saved the exact same way custom door maros are set and saved. If you set a default door macro, it runs for any doors action (that you've set). If you set a door macro, it takes priority and the default isn't run.

APi provides a robust JSON to allow *action hijacking * 🙂

I implemented this I wanted the option to have DEFAULTS because once I built a macro to "Pick Lock" it would work on the vast majority of them. And without using the cutnpaste method, I was stuck manually entering the same links anytime I made different doors. All I wanted was for you to save default links somewhere.
and changed where APi runs that allows far more power and control.

[turbid quarry]

I hear you. And that's what I've understood things to be right now. But I'm not trying to make my life harder using the APi. I'm modifying the apjson just fine in the non-maroon, off lib, on_xxx macros before triggering actions with the APcontrols() function. I will take a look at the current APi implementation later when I have time to do some proper teeth grinding... but, as I mentioned earlier, you may have been "solving a more complex issue" than I required solving.

[exotic hill]

the teeth grinding will come from removing whatever you did and recoding it to work with APi I don't think it will be a heavy lift and due to where it runs, I'm hoping it will be better.

[turbid quarry]

I'm betting that the code I FIRST wrote for my 3-increment crack door has a much better chance to work with this new APi. I'll try to recreate it and give it a shot.

[exotic hill]

An example of what the json looks like . . . for opening a door.
Have your custom mac/lib with a switch based off action . . .(hopefully that simple)

list of actions right now are all the door actions, overlay, complete. Complete should only ever appear when the action concludes.
I'm sure there are some tweaks / things to do so I pass enough / all that's wanted.

[exotic hill]

LibActionPads v3.7.2

[turbid quarry]

@exotic hill Transfer is broken in 3.7.2.

[exotic hill]

Like nothing transferred or just the two macros didn't?

[turbid quarry]

Didn't deep dive... didn't get the transfer popup and I saw that the color of the "power" button was wrong... and just checked again... it's all just defaults.

[exotic hill]

I'll get that fixed in a few mins, not sure what I missed. I added that macro transfers for APsounds and APinterrupt, and the two new default macs and sounds bits.

[exotic hill]

This is fixed and it's on git but NOT releases yet.

[turbid quarry]

The settings seems to tranfer... but not apply. Have to go in and "apply changes" to get it to update.

[exotic hill]

doh, what else did I miss lol . . .

[turbid quarry]

And is there a reason to show the unlock icon if the door isn't locked? (and visa versa)

[exotic hill]

maybe, as there was a FREQ to allow players to lock doors 🙄 . this is the line doing it
[h, if(chk_LCK==1 || json.contains(tokJSON,"keyRing") || chk_UNL):menuButtonHTML = menuButtonHTML + if(isGM() && getImpersonated()=="","",hUseKey)]

[turbid quarry]

I'm talking about this [h, if(IamGM):menuButtonHTML = menuButtonHTML + hLock] [h, if(IamGM):menuButtonHTML = menuButtonHTML + hUALocks]

[exotic hill]

Those only show up for the GM, never a player. The logic a player goes through vs the GM is not the same.

[turbid quarry]

Do I need to see the lock option if it's already locked? or the unlock all locks if it has no locks?

[exotic hill]

The pad locks will always show for the GM.

[turbid quarry]

But why?

[exotic hill]

To perform simple locks or unlock all.

[turbid quarry]

Right. So once I simple lock it, why am I still seeing the option to simple lock it? Can I simple lock it twice?

[exotic hill]

Is it causing you harm?

[turbid quarry]

It's redundant clutter that's easily removed.

Unless I'm missing a reason for it... and I don't see one.

[exotic hill]

Lets agree to disagree LOL :), its cosmetic and the icons serve multiple purposes, it handles simples locks, locks keyed doors, unlocks simple locks and unlocks keyed doors. It's not that simple.

[turbid quarry]

So you can simple lock keyed doors?

[exotic hill]

yes

[turbid quarry]

And there is no distinction between the two in code?

[exotic hill]

It's not worth it to me. It is an icon on an overlay. The GM should have the option to ALWAYS lock or unlock a door, those two icons provide it. The GM shouldn't be forced to down a path.

[turbid quarry]

Forced down what path?

[exotic hill]

To only unlock a door if keys were used. If keys are used and I don't want a player to use the key, I can simple lock it.

So I NEED the pad lock icon to do that, even though it's already locked.

[turbid quarry]

So a door is key locked. I should also be able to apply a simple lock. I agree. But once I do, why am I seeing the apply a simple lock still? If the icon goes away I can tell it's got a simple lock as well.

[exotic hill]

I'm leaving it as is, but appreciate you 🙂

[exotic hill]

FWIW since you're getting savvy with my spaghetti code, if you wanted to add this (like you did on git where you posted the door overlay "fixes", I'm ok implementing it, OR if you want it as a FREQ, thats cool too, it's just not something I want to work through right now 😉

[turbid quarry]

I did have the lock icon display modified in the code I shared... but it would not have accounted for simple locking a key locked door since I think they both use the ch_lck flag. The unlock icon could probably be removed if there are no locks though with this: [h, if(IamGM && chk_LCK==1):menuButtonHTML = menuButtonHTML + hUALocks]

I haven't looked too closely at the key code... but I will because I'll want my players to be able to look at keys in their inventory easily so I'll need to hook into however you've got the keyring setup and display accordingly.

[exotic hill]

The diff between key locked and simple locked, The door object token has "padKeys" : "simple:0/1" That is ONLY created the first time simple locks is used, then toggles 0/1. The code would probably need to delete the simple out of padKeys all together.

padKeys also contains the key token ID, then ending in :0/1 (unlocked/locked). There can be any number of "keys" in padKeys in a string list.

I do have a gap around, if a key is in a PC inventory AND the door/lock is on another map, I expect some failures in this use case. Right now, I don't have map tracking for keys.

[sullen wharf]

Whew. Y'all have been going HARD since i've been away

looks like i'm gonna have to set aside some MT time

[exotic hill]

LibActionPads v3.7.4

[turbid quarry]

@exotic hill I still have to "apply changes" after the transfer with 3.7.4.

[exotic hill]

If you could test something on that for me (as I did test the transfer). If you manually closeOverlay("ActionPads Designer") and then re-run the designer, is that working?
I'm only re-running onCampaignLoad and I'm not checking if the Designer is already open (I'm guessing that because I'm not closing and opening the Designer overlay, that it's not "refreshing").

And I msissed that on_disabled macro 😦

[turbid quarry]

Don't have the designer open when doing the transfer. So I transfer, run designer, see that the button is green even though the it's set to blue. Then I close the designer and open it again and it's still the same. It only seems to "update" when I apply changes.

[exotic hill]

I found the miss I had, I'll put a new one up a little later this morning 🙂

[exotic hill]

@turbid quarry I've added 4 door options
What is the expectation of these?
Should they have the same macro and sound options as the other door features do or is this to allow a hook via APinterrupt?
(And have you had luck using that, was it a heavy lift?)

[turbid quarry]

I think they should have the same possible macro/sound hooks.

Not a heavy lift for APinterrupt for a basic implementation... though a near 1:1 transfer of the code I was using for my 3-crack macro exhibits some unusual behaviour and I'll need to modify it to get it working as intended. I do also have some questions about the order of operations that I want to clarify... I want to add detailed comments to the apManager.

@exotic hill Did you see my post on this closed issue? https://github.com/Jmr3366/Lib_ActionPads/issues/87#issuecomment-2639371538

[exotic hill]

I did see that, forgot to reply . . .
If the value is a number, it uses that, if it's not a number and I can hasProperty against it, it's a property, if it starts with [ it's evalMacro code

[turbid quarry]

So my token property is called APReach and the value of the property is {getAPReach(findToken(token.name), getCurrentMapID())} and that returns a number when you use getProperty("APReach") But if I put APReach in the Distance in pixels a player token can be from an actuator setting it does not work.

[exotic hill]

It looks like I'm getting an error and I'm not sure if it's an MT bug or not. I set that at a token property called eMaxHP. On or around line 50 in isOnActionPad I placed this: [h: broadcast(pix_DIS+"^"+hasProperty(pix_DIS,tokenid)+"^"+getProperty(pix_DIS,tokenid))]
The output was this (and it is WRONG):
eMaxHP^0^10

[exotic hill]

It looks like the hasProperty is returning 0 when it should be 1, so it's never reading in the proper value. This was done under 1.16.0b4, just tested under 1.15.2 and hasProperty fails there too. I'll see if I can narrow it down but the root cause of AP failing is the hasProperty check is returning 0 vs 1.

[exotic hill]

I removed the hasProperty check and it seems to work as expected now

[turbid quarry]

I think I was getting scientific notation when testing some bits of that code, too... didn't seem to affect the numeric value... but made it hard to "read" so I used number().

[exotic hill]

If you're up for testing it, that hasProperty check is in isOnActionPads blue macro around line 50 iirc... Just remove that part of the if statement.

[turbid quarry]

Seems to work.

[turbid quarry]

Not saying this needs to be a thing (I don't have a particular use case for it right now)... but I noticed that there is no APinterrupt for when the AP Menu overlay closes (though there is one for when it opens.)

[turbid quarry]

I'd like to verify that this is the order of operations for the "two stage" door actions when using the APinterrupt/APManager: APM(doorOpen) > animation > APM(open) > default onOpen Macro || onToken onOpen Macro > APM(complete)

If that is correct, where do I slot in the sound chain to have a clearer picture? I.e. Is it after the animation? I haven't messed with setting up the "sound interrupt" option yet. I am assuming that it will be soundInterrupt || default onXXX sound link || onToken onXXX sound link so that only one sound will play. And does the sound interrupt option require a link like the macros or can I use it to trigger sound code? (I've mentioned in the past that I manage my sound links in a playSound() function that makes updating framework wide sounds easier if links change and is more customizable... like I can add delays, use stream or clip, adjust volume, or play only part of a longer clip, etc.)

[exotic hill]

The APsounds was never integrated so while it exists, I'm not calling it (or I don't think so). With the other options that exist, I'd be curious if you'd even need it vs pasting in the URL to either the default sound settings or the door specific ones. It's a playClip and not a playStream so it's pretty simple . . .
I can also build out where and when APsounds should run, just nothing exists today.

[exotic hill]

APM(doorOpen) > APM(open) (1 of x) > default / custom macro if set (1 of x) > audio (1 of x) > animation (1 of x) > setproperty (1 of x) > APM(complete 1 of x) > APM(open) (2 of x) . . .

[turbid quarry]

What's the setproperty action? and what's APM(open) (2 of x) that comes after the complete action?

[exotic hill]

Each door is done sequentially so if a door is linked it does door one then door two, etc. So lets say you've got default sounds or some APi thing you're doing, that may only be useful if done on one door vs both (eg. use sound on one door, if you're cracking a door, etc.

[exotic hill]

LibActionPads v3.8.0

[turbid quarry]

@exotic hill I thought I updated to 3.8 the other day... but my test campaign is still on 3.7.4 ... and when I run the transfer macro I get an error Error trace : transfer@Lib:ActionPads <<< macroLink Unresolved value "apIMGmenuPadOnOffB".

[exotic hill]

I have another update hopefully later today and I'll have to test that better 😦

[exotic hill]

@turbid quarry I just put up a beta version v3.9.0b1. Lots of changes / updates, that transfer should finally be working. Added default options on doors, for macros, sounds, icons (for icons, defaults win if also set on door)
Added that soundUDF option but need your testing :). the custom icons (X, S, C, T) were added too.

[turbid quarry]

Should get to testing this tonight. Btw, have you looked at what it's going to take to create doors with the new wall topology?

[exotic hill]

I did ping Kw to see what was on his radar regarding the new walls. At the moment, there's no functions to transfer the new walls to tokens or in general manipulating them. I'm hoping those type functions come soon 🙂

[turbid quarry]

You should put in a freq for the functions/capabilities you need. He's doing a lot lately and these kinds of design decisions are probably best made earlier in the build out of this new paradigm.

Not done much testing on the 3.9 yet... but I did run into a quick issue with getting the wrong error message when an impersonated token is out of reach of an actuator. It tells me Ownership not detected . . .

[exotic hill]

I put in better ownership checks and missed some of the impersonation bits it seems. There are two errors now, one regarding ownership and another for too far

If Kw wants a dog list from "us" I'll wait for him to ask for one 😉

[turbid quarry]

All devs need feedback.

My udf isn't triggering in the default sounds field... do I have to wrap it some way?

[exotic hill]

I didn't have an easy way to test this looks like I need to :p

what are you using in that field CustomUDF('sound url') you can't use double quotes

[turbid quarry]

here is a simplified udf you can use ```[h: "<!-- playSound() -->"]

[h: soundName = arg(0)]

[h, if (argCount() == 2), CODE:
{
[h: target = arg(1)]
};
{
[h: target = "all"]
}
]

[h, SWITCH(soundName), CODE:
case "Door Open":
{
[h: execFunction("playClip", json.append("[]", soundLoc), 0, target)]
};
default:
{

    }

]```

[turbid quarry]

single quotes isn't working either

[proud charm]

Please do 🙏

[exotic hill]

Oh that's a slipperly slope Kind Sir :).

[exotic hill]

I did find some misses (on click), to resolve but I think the main issue here is it needs to be this [CustomUDF('var1','var2','var3')]

[turbid quarry]

@exotic hill I've got a door that's not working correctly in 3.9. For example, it's not opening and not showing the pick icon in the apMenu. Here is its json:

{"apType":"door","apID":"87900DC363294D2E99B709C92A246F8E","apStates":{"chk_FRM":1,"chk_SMD":2,"chk_HGD":1,"chk_SLD":2,"chk_LFD":2,"chk_WND":2,"chk_DBD":2,"chk_CLD":1,"chk_OPN":1,"chk_PEP":2,"chk_CRK":1,"chk_UNL":0,"chk_LSN":0,"chk_INS":0,"chk_KNK":0,"chk_PIC":1,"chk_PRY":0,"chk_ATK":0,"chk_BRK":0,"chk_ANI":1},"padClosed":{"padX":950,"padY":-1408,"padF":-90,"padID":"87900DC363294D2E99B709C92A246F8E","tokVBL":[{"generated":1,"shape":"polygon","fill":1,"close":1,"thickness":0,"points":[{"x":0.0,"y":0.0},{"x":0.0,"y":89.63999999999942},{"x":498.0,"y":89.63999999999942},{"x":498.0,"y":69.71999999999935},{"x":9.960000000000946,"y":69.71999999999935},{"x":9.960000000000946,"y":0.0},{"x":0.0,"y":0.0}]}],"tokMBL":"","padMBL":"","padVBL":[{"generated":1,"shape":"polygon","fill":1,"close":1,"thickness":0,"points":[{"x":949.5,"y":-1407.5},{"x":949.5,"y":-1407.0},{"x":949.5,"y":-1399.0},{"x":999.5,"y":-1399.0},{"x":999.5,"y":-1401.0},{"x":951.0,"y":-1401.0},{"x":951.0,"y":-1407.5},{"x":949.5,"y":-1407.5}]}]},"padPeep":"","padActu":{"tokX":963,"tokY":-1413},"padOpen":{"padX":950,"padY":-1408,"padF":40,"padID":"87900DC363294D2E99B709C92A246F8E","tokVBL":[{"generated":1,"shape":"polygon","fill":1,"close":1,"thickness":0,"points":[{"x":0.0,"y":0.0},{"x":0.0,"y":89.63999999999942},{"x":498.0,"y":89.63999999999942},{"x":498.0,"y":69.71999999999935},{"x":9.960000000000946,"y":69.71999999999935},{"x":9.960000000000946,"y":0.0},{"x":0.0,"y":0.0}]}],"tokMBL":"","padMBL":"","padVBL":[{"generated":1,"shape":"polygon","fill":1,"close":1,"thickness":0,"points":[{"x":949.5,"y":-1407.5},{"x":949.5,"y":-1407.0},{"x":949.5,"y":-1399.0},{"x":999.5,"y":-1399.0},{"x":999.5,"y":-1401.0},{"x":951.0,"y":-1401.0},{"x":951.0,"y":-1407.5},{"x":949.5,"y":-1407.5}]}]},"apHP":-1,"apAC":-1,"apActu":"E3B7986005E24F79B13B0A8870DA915C","padPeek":{"padX":950,"padY":-1408,"padF":-90,"padS":""},"padState":"door,close"}

[exotic hill]

I'll check the way I'm json.merging the Defaults into the specific door settings. I'm probably overriding the door setting . .

[exotic hill]

It's not the json.merge I'm doing, at the moment, I'm checking for chk_LCK to determine if the Pick Lock icon should appear.
[h, if(chk_PIC==1 && chk_LCK==1):menuButtonHTML = menuButtonHTML + hPickLock]

[turbid quarry]

Do you see any reason the door won't open?

[exotic hill]

No, it all looks good, it thinks it's closed right now. Curious if the behavior changed if you forced "padState": "door,open"

[turbid quarry]

I see what it is... it's just not working when I have the DM token impersonated. I can see the options... it just won't open.

[exotic hill]

That makes you a "GM" so it would not work the same as when you imp. a non-DM-named token :p. I hope it works as a "normal" token.

[turbid quarry]

Yes... it makes me the GM... I can see the GM options... can set locks... but it won't open the door. The open door icon will work if I don't have the DM token impersonated though.

[exotic hill]

It should be getting to the doorAction macro though (or if you can confirm that)?
I started passing the PCtokenID into the doorAction and doorAction_OCP. I bet it's getting stuck in OCP .. .

I found it (or bet this is it): [h, if(isGM() && getImpersonated()==""):IamGM = 1 ; IamGM = 0] I need to add your special "DM" check there 🙂

[exotic hill]

Can you replace the line I quoted above with this logic to test / confirm please?: ```
[h: tokenimp = getImpersonated()]
[h, if(isGM() && tokenimp!=""),CODE:{
[h, if(findToken(tokenimp)!=""): IamGM = if(getGMName(tokenimp)=="DM",1,0) ; IamGM = 0]
};{
[h: IamGM = isGM()]
}]

in doorAction_OCP.

Its around line 13 or so.

[turbid quarry]

That works.

[exotic hill]

I'm also changing this so if you've set a default Icon, it will always show [h, if(chk_PIC==1 && chk_LCK==1 || json.contains(libIcns,"chk_PIC")):menuButtonHTML = menuButtonHTML + hPickLock]

[exotic hill]

LibActionPads v3.9.1

[exotic hill]

@turbid quarry did you get a chance to check that audio UDF code?

[turbid quarry]

In 3.9.2 I am able to use the method you use here #1102924536279740518 message

You should update the text in Settings>Set Default Sounds to show the brackets though.

I want to add a link to the APDesigner in my GM Control Panel but I want it to open in the "max" view. [macro("APoverlayDesigner@Lib:ActionPads"):""] Similarly, I want the APDesigner to open when I select an actionpad from the object layer (in max view with the selected object in scope). I've got a token watch overlay that knows when I select an actionpad from the object layer so I don't need that, I just need to know what the macro call should look like.

[exotic hill]

[macro("APoverlayDesigner@Lib:ActionPads"):"apMenuMax"] would do that.
If you're on the object layer with APDesigner open, it would / should already max (if not in a minimized state, but yeah, if you've closed it or just want it to max . . .)

[exotic hill]

LibActionPads v3.10.0

[exotic hill]

@tame cosmos Regarding your question here:#archived-the-doors message
What version of MapTool are you using?

[tame cosmos]

1.16

I didn't notice this section.

[exotic hill]

What kind of door (simple, swing, etc)?

[tame cosmos]

I tried simple and swing both seem to do this

when i place the door it has no VBL/MBL

let me recheck that actually I think it might be making that tiny sliver of it

[exotic hill]

Its important that you've placed all the blocking lines before you create or use a door / template.

[tame cosmos]

yes that was all done prior

the door itself isn't creating the VBL correctly

for example this one just did this

[exotic hill]

Can you share what version of ActionPads you're using and the settings / config:

[tame cosmos]

3.10.0

I've tried with force mbl on and off

all the other setting are exactly that

[exotic hill]

Going through a clean slate test right now, to make sure there's not a bug you've found 🙂

[tame cosmos]

wouldn't be the first time I've done that by accident lol

[exotic hill]

Are you using VBL and MBL or only one / the other?

[tame cosmos]

that map I had both

[exotic hill]

This is a simple and swing door example on a clean slate campaign with using VBL and MBL.

That was done with the default settings (same as the image I shared above).

[tame cosmos]

hmm I might see my issue let me try again.

[exotic hill]

No worries, let me know if you're still having troubles. I've tried to make it user friendly but I know there's a learning curve to anything 🙂

[tame cosmos]

I just realized I needed to put them over a closed wall and not between an opening

I feel stupid lol

well this makes life easier

Thanks for the help JMR!

[exotic hill]

I've got some videos, link is on the top pinned post, if you've not checked them out, it shows most of the features broken out by chapters / sections.

[split nimbus]

copying question here from #archived-support-maptool-support as Jmr suggested...

I downloaded Lib:ActionPads token and have been watching tutorials and playing around with how to use them. I have a map I'm using for play/testing and threw a door token onto the object layer, then turned it into an ActionPad door and got it all set up and configured. The door graphic is an object, and the ActionPad door is on the token layer for players to interact with. I made it animate to crack open and full open. However, there's one thing that isn't working quite right and I'm not sure if I'm missing something with ActionPad or with MapTool in general. The door allows vision through it, even when closed. However, it does stop player tokens from moving through when closed. I drew my VBL rectangle around the entire room, then put the door token on the object layer and then edited token topography to move VBL from map to token. Then I set up the ActionPad token on top of the original door token. It all looks like it should work, however my player tokens can still see through the closed door. This is on MT 1.16.3. Any suggestions? I'm at work right now so I can't grab screenshots or video, but I'll be happy to do that later on today if needed.

[turbid quarry]

I drew my VBL rectangle around the entire room, then put the door token on the object layer and then edited token topography to move VBL from map to token. This doesn't sound quite right. You never edit token topography unless you're adding a keyhole (which I suggest you avoid doing until you're really experienced with the process). You draw the VBL for the room (make sure you are using Wall VBL). You drop the door image on the object layer and move it over a section of the VBL where you want the door to be. Toggle the VBL on and off to make sure it's in position. Select the door object>Set as New Door template. The door always shifts here so toggle the VBL on again so you can see to reposition door back to the place it was. You can use the arrowpad to move the door while the VBL is visible. Then set the type of door and its open and closed positions.

[split nimbus]

I think I did all of that as you described except for the additional part of adding VBL to the door token (the image of the actual door, on the object layer, not the ActionPad token on the tokens layer)

If I skip this step, then the door itself doesn't have any visual or movement blockers, correct? but if I just draw the wall VBL in a rectangle around my room, player tokens cant see or move in or out of the doorway regardless of whether or not a door token is there because the vbl is on the map. If I erase the VBL in the doorway where the door is supposed to go, that's fine but then there's still no VBL on the door itself to prevent vison/movement when closed and then allow those things when opened. Is that correct, or am I way off?

[turbid quarry]

When you put the door object over the Wall VBL that you've drawn and click the door type (i.e. "Swing Door") that's when Action pads transfers the VBL you've already put down to the door and shifts the door out of position. Then you move it back into position. You don't erase or modify the VBL manually. It's now attached to the door.

So if the wall blocked vision and movement before you set the door type it will after.

[split nimbus]

oh, ok. Thank you for your patience and explanation. It sounds like I'm trying to do an extra step manually that is unnecessary and that Action Pad takes care of it automatically?

I'll have to try this again when I get home

[turbid quarry]

Yes, that's what it sounds like is happening. Hopefully this gets you through the initial setup.

[split nimbus]

I can't remember exactly how I was playing around with this last night, but I was following this tutorial from timestamp ~5:00 to 11:00: https://www.youtube.com/watch?v=svNanE0mjP4&t=546s. I'm pretty sure I followed the steps exactly as they were in the tutorial and at the end, the player token could still see through the door. So that's when I tried editing the object door token's topography manually. But like I said, I'll give it another go tonight. There's probably something else I'm messing up, haha.

[turbid quarry]

That's a pretty old video, gives a LOT of information, and there are some changes to the UI that might be tripping you up... And if MT is also new to you then there is also a lot of popping around that UI that could throw you off. There is even a change to the VBL UI in MT itself that could be confusing in 1.16+ (where when you select the VBL tool you need to be on a type other than the "new" type to see the vbl as presented in @exotic hill 's video).

@split nimbus Which... now that I think about it... how are you drawing the VBL? If you're using the new type (the one with the dot connections) then that type is not compatible with ActionPads.

[split nimbus]

No, I'm just using the regular rectangle tool

I am fairly new to MT but I've been reading documentation, watching videos, and experimenting with it and I think I have a pretty decent understanding of at least the basics... But I also know that I don't know everything so that's why part of me is wondering if my seeing through closed door issue is caused by something I've missed or a setting that's wrong with MT itself and not action pads. Would it be helpful to take a screen recording of me setting up vbl on my cabin and adding a door and upload that here?

[exotic hill]

Yes I do that often and ya know a pic/vid is better than words 😀
I always push mine through Handbrake tho

[split nimbus]

alright, so I just got home and tried to make a new door, and everything seems to be working as it should. I'm not sure if it was messing up because I was manually editing the token topography, or maybe it was because I had another NPC token already in the room... but I did set each token to have their own vision and I tried to impersonate only the token I was testing with. regardless, I started on a fresh clean map, made the VBL, made the door, and inserted only one player token, and now all is well and I cannot see through closed doors! So thanks, Full Bleed and Jmr! 🙂

[patent spindle]

Speaking of Vids/tutorials, are there any new ones? Like how to use some of the other features Like Vehicles, proximity detector etc?

[exotic hill]

No, I'm latent regarding the videos. I can create some short and sweet ones to post here tho. My vehicles implementation does not take rotation into consideration, and there are some conditions (e.g. group "leaders" and vehicles don't play nice).
Let me put some videos together that I hope will help show those better. I'll try to include some of the neat tricks like opening a chest and looting an item from inside.

[exotic hill]

Vehicles Tokens :

• Must be a "size" and not native
• Must be on the token layer
• Don't play nice with "Leader Tokens"
• Don't play nice with mixed snap and no-snap
• Are "step-on" pads and as such, are tracked. To purge them, it requires ActionPads full reset or the token must be deleted.

Notes: Due to how multiple token selection works, it is important to not spam click / drag vehicle tokens.
To board the vehicle, take your passenger and drag them onto the vehicle footprint.
To deboard, drag them off.
To move the vehicle and passengers, drag the vehicle. If when you click and drag, nothing happens, re-select the vehicle token and try again (this try again is caused by not all tokens being selected AND a drag took place)

If I get around to it, I want to add these features (and to bookmark it): https://github.com/Lethargie1/Maptool-Vehicle/tree/master/library

[exotic hill]

Proxy Tokens:

• Perform an action based on circular / donut shaped proximity. Actions can be macros, evalMacro, property checks, etc.
• To be active, it must be visible to players (but as these reside on the hidden layer, they're not really visible to them).
• Less is better in that these are checked on every token movement

Notes: In the video example, I'm doing a very simple [r: 1]. Any return that is 1 will stop the token from moving.

They can really be used for any sort of "do this action when token gets this close". They can be used with neat tricks with step on pads. You can set a step-on pad to enable (or disable) the proxy token (by setting the visibility), and could lock a player in proximity of the now visible proxy token (or make a chest visible, or disappear :p )

[exotic hill]

Interaction Token (example: chest, loot, and looting)

If you move an interaction token to the hidden layer (like the gold), and want to "reset" that token, change to the hidden layer and click the token (moves the gold back to the token layer). This resets the interaction and makes the token clickable again by players.

[patent spindle]

Thank you for this

[lilac lodge]

Im running v1.15.2 with actionpads version 3.5.1 and none of my teleports are working, I have watched the video but that has not resolved the issue. So i am wondering is it something else or did i just miss a step somewhere?

[exotic hill]

I'll be able to complete some tests when I'm back at my desk tomorrow (roughly 12hours from now).
Could you share if these are step on (stargates), step off (door portals) or click (under the interaction menu) ?

If you're porting to another map, you'd have to use "Move Token To Map" option under the Toolbox main selection.

[exotic hill]

I did test this on 1.15.2 and it works as expected. I'm guessing you may have missed a step. I would also advise to upgrade to the newest version of ActionPads. I should be releasing an update to this and several of my lib tokens in the next few days.

[candid ermine]

It may just be me that can't find it, but has anyone tried playing around with this library and the new walls?
My thought is, that if a door is drawn using the "old" VBL and Walls are used for the rest, shouldn't it work?

[exotic hill]

It would work so long as you're not doing these kinds of things (where removing / adding *bl is being done)

[candid ermine]

I don't use animations anyway, so that would probably be safe then 😉

[exotic hill]

Lib:Slide isn't required for that tho :p . My point was only to say there isn't a transferBL function for the new wall types.

[candid ermine]

Oh, then I am not sure I understand what you're saying?

[exotic hill]

In the video, BL is being transferred to/from a token, you see a roof, but then you don't and you see the walls. That technique isn't possible with the new walls yet (but trying to pressure Kw to add them :p ).

The new walls don't have any transfer function, yet

[willow nimbus]

So does it mess with the doors that transer BL, too?

[candid ermine]

Ah, now I got it. Thanks 🙂

[exotic hill]

Doors (all types I'm aware of) use some form of blocking layer addition/deletion, the new walls "exist", they can't be changed (by macros)

[willow nimbus]

Copy that. Yeah, just checked, and the doors still seem to function if the token has it's own VBL already.

[candid ermine]

I am thinking that I use the walls for ... well, walls. Anywhere there's a door, I'll start by drawing a line of old style VBL and then handle doors as usual.

[turbid quarry]

@exotic hill The animation of my test doors opening in 1.18.1 is crazy bad. Have you tested that?

@exotic hill I'm on 3.9.2 and found an extraneous ) in the APtoggleoCS macro on line 14 [h: returnMSG = "Starting ActionPads onChangeSelection Overlay")] Breaking in 1.18.x

[exotic hill]

Is this without libGDX? I've been testing that a lot and there are several issues (overlays don't work correctly or example).
I'm putting out an update today that should have all the erronous ) removed / resolved

[turbid quarry]

Yes, without libgdx.

[exotic hill]

I've been doing a lot of testing emulating slow networks using Clumsy. It seems like there is a lot better syncing of the tokens (maybe it's just me . . .).
Anyway, under the Door section, in doorAction_Animate last line, make these changes. I don't see the stutter I used to see when player 1 opens a door vs whatever the other player see. The only session that seems laggy is the GM session where I can see through all fog.
This change removes all delays regarding door animation:

[h:' APdelayMS(deferLink,spd_DOR) ']```

[turbid quarry]

That's not the issue I'm seeing. It's taking about 5-6 seconds to open and does it in 8-9 visible "steps". It's faster when I have a token impersonated, but still much slower than in 1.17. It's always been slower when not having a token selected or impersonated, but now it's really bad.

[turbid quarry]

As you can see, when you have a token selected/impersonated the performance is always best. But, more importantly, something has changed in 1.18 to significantly change the performance.

Here is 1.18:

Here is 1.17:

@proud charm Any idea what might have changed in 1.18 to make the animation performance worse?

[proud charm]

It could be all sorts of things.
If I had to guess I would say it's due to a change in how we manage token VBL (well, VBL in general). It's fast in static cases, but also quite possible that it adds lags when things are changing each frame.

Best thing to do is to share campaign files that have these performances issues, then I can dig into it. Actually, I've been meaning to make a place dedicated to just for reporting performance problems...

[exotic hill]

This is a "me" problem not a MT problem (since this animation isn't technically supported 🙂 ).
I will say it seems like libGDX handles BL better (or at least a misguided visual perception from me ;p) When I test some zoom in/out with libGDX the gui responsiveness appears better /em 2cps).

[turbid quarry]

It's not just a "you" problem. If behaviour has changed then it's good to know the cause/consequences of changes.

[exotic hill]

If you set the FoW settings to 0 does it change anything?
I can try to run checks and try to find out where any speed impact could be coming from.

[turbid quarry]

I already have it set to 0.

[exotic hill]

I'm seeing some different issues with 1.18.1 though. For me the speed is the same. I even get worse performance from 1.17.1. FoW doesn't seem to change things for me. I do have some onChangeSelection troubles (the video shows that as I have to click the token twice and it doesn't "deselect" like it should be doing.
(left video is 1.18.1, right is 1.17.1)

[proud charm]

As far as I can tell, onChangeSelection itself is still working.
I wonder if maybe you are hitting slightly different code in your macros that might be running into some issues, say with the yet-to-be-fixed macro location stuff.

[sullen wharf]

@exotic hill not sure where to ask, but i use actionpads, slide, and token grouper, so as you suggested to me way back when, i also use your Lib:Bootup. Trying to use it with 1.18+, however, just throws the same parsing error at me. Theres no extra parentheses, quotes, or other things that i can see. have you encountered this at all?

[exotic hill]

Yes, there were several corrections that 1.18 found. The lib tokens should be updated on my github except actionpads. I need to push it up to git still

[sullen wharf]

cool. now i jsut need to go through and start debugging the other libs i use.

[sullen wharf]

Click Portals should just work upon creation, yes? i dont need to do anything to set them up?

[exotic hill]

Correct, just if you move one to another map you have to use the MoveToMap icon under the toolbox.

[sullen wharf]

hmm something may be going on in my campaign then, as nothing seems to happen when one is clicked. would there be a server setting or some such that might be affecting it?

[exotic hill]

If you're willing . . .

I did have some updates to portal pads, I don't think I adjusted the click pads though.
I'll run through a couple tests.

[sullen wharf]

i'll give it a shot. always happy to test for you

[exotic hill]

Something is going on with the click pads, quick test is failing too, does nothing, probably something simple . . . checking now.

[sullen wharf]

same on my end.

[exotic hill]

Yeah, I was doing an extra check that was causing an if to fail.
This one is working with the clicky ports

[sullen wharf]

yup, that works.

thanks man. Hows things going otherwise? trucking along?

[exotic hill]

Oh yeah, doing a lot of work on the MonsterMaker token and some tweaks on Meleks framework doing my hobby thang

[sullen wharf]

excellent. getting it ready for 1.18, yeah?

[exotic hill]

Just some minor things 🙂

[exotic hill]

Most current version that should be fully MapTool 1.18.x compatible:

[willow nimbus]

@exotic hill I just added the new version to my campaign. The overlay menu shows an ocs overlay is checked, but I don't actually "see" an overlay. Should there be one?

[exotic hill]

No, technically the "..oCS" overlay is used for doors and interaction pads. I do check for it though so don't close it 🙂

It's there, but is empty, like the door handler overlay

[willow nimbus]

Copy. Found out how to bring up the controls for AP. I think something's off when using default theme for this submenu, maybe? Or maybe, I just need to configure something to be able to see it better?

[exotic hill]

Good call out, that looks bad 😦 . I can put black background behind the icons to mitigate light themes. If you see other areas like that, let me know please :).

[willow nimbus]

Also, this happened when I clicked the little green light bulb on the doors help screen.

[exotic hill]

If you're up for it .. macro getHelp_Doors under -Utils Doors macro group,
I must have accidentally deleted a [h: on line 338.
should be this[h: ftrHTML =

[willow nimbus]

Yep, that fixed it. Thanks!

[willow nimbus]

@exotic hill Do you have a tutorial video you recommend for all the features this thing has? lol

[exotic hill]

Yeah the pinned post has one linked. The video is a few years old. There are several throughout this thread but hard to find :(.
If there is something specific I can create a quick ad-hoc video.

[turbid quarry]

@exotic hill Did you do a test update from 3.9.2? With my "Custom" updater, when it gets to your transfer macro it throws a Value for APicns input. Clicking past it seems to work, but I don't know what the consequences of that might be.

[exotic hill]

I can't recall what version but there was an update not long ago when I had a typo in this line of transfer mac re: theAPicns variable.
So I'm clear, this is your custom updater failing or something happening via the Transfer Lib:ActionPads mac?

[turbid quarry]

My custom updater just simplifies the process... allows me to just drop the new lib (which gets autonamed to something else), select it and the old one, hit an update button, and then hit a replace button and it moves into the old libs place and deletes it... but it is ultimately using your transfer macro. Maybe I'm running the transfer macro off the old lib?

Yes, I am. For some reason I thought that was what I was supposed to do (never understood why).

[exotic hill]

Running the transfer mac off the old, renamed lib:token, that becomes the sourceJSON I use.
If you run it off the new lib:token, the sourceJSON is itself.

[turbid quarry]

Either way, I get the error.

[exotic hill]

Let me toy with it some, I'll set some default custom icons and give it a whirl . . .
You're only seeing something odd with in that use case, the default icons set here:

[exotic hill]

I've dug into that and I don't have an option to set a background color within an Input function 😦
(unless @turbid quarry has some ideas 😉 )

[turbid quarry]

Where is the input for that config?

[exotic hill]

doorSet macro in Utils Door group, starting at line 83.

an example "vchk_UNL|"+chk_UNL+"|<html><img alt='Unlock' width='30' src='asset://"+apIMGitemUnlock+"'></html>|CHECK", (i've tried multiple tags and placements and styles 😦 )

[exotic hill]

I did some very basic tests going from 3.9.2 where I set default icons.
I renamed the lib token
I dragged 3.10.10 to the map.
Ran transfer from the old lib:token.
All my settings moved over as expected.

[turbid quarry]

Nothing I'm trying is working. You could update the icons with an dark outer glow or shadow.

[exotic hill]

Yeah, I'm thinking the same thing. I play around with adding a black-outline, but this will impact those images anywhere they're used (not expecting any negative from that though . . . )

[turbid quarry]

You could take a page from melek's elevation and make a theme responsive form. 😉

[exotic hill]

I had seen some threads around trying to detect themes, I'd have to look at the hex color codes to know if there are ways to determine dark vs light . . . not super savy regarding colors and all :p

[turbid quarry]

You could also bundle a set of gray and black icons and let people choose theme (Dark/Light/Neutral). Or just make a form that's always "dark"... the white check boxes are always going to be hard to see on a light theme.

[turbid quarry]

I just used the default method (you just used) Unresolved value "APicns". Error trace : transfer@Lib:ActionPads <<< macroLink Are you trying it with an empty "APicns":""

Nope, that's not it.

I see the issue... [h, if(json.contains(sourceJSON,"APicns")): APsnds = json.get(sourceJSON,"APicns") ; APicns = ""]

[exotic hill]

I think that was the bug I referenced above

[turbid quarry]

It's in 3.10.0 too.

[exotic hill]

it's fixed now though, somewhere between 3.10.0 and 3.10.10 :p

[turbid quarry]

Oh, you haven't updated the git.. I downloaded the latest from there.

I use the -oTM version so I didn't take it from this channel.

[exotic hill]

Yeah, I just fixed all the missing ) the other day. I wanted to run through some tests, etc. I need to get it updated soon (this week for sure).
just rename that onTokenMove and you're good 🙂

[turbid quarry]

Ok, just crossed wires. I thought I was getting the latest. No worries.

[willow nimbus]

For some reason losing VBL in doors. Any idea what might be causing that? Using latest version of Action Pads from this thread. Thanks!

[exotic hill]

I just did a quick test and so long as you've got MBL and VBL drawn (so the line should look purple), it should be picking up both. The line should look yellow on the object layer door token once it's done.
And to check, Is this on 1.18.x?

[willow nimbus]

Yes, Sir. 1.18.2

[exotic hill]

Let me run it through on 1.18.2 just to make sure, I just tested it on 1.17.1

[willow nimbus]

I used a door from the doors lib. AP seemed to take it okay. Also wondering if there is a way to remove it as an AP door and just return it to a normal image? So, like if I wanted to redraw VBL and place the image and start over, is there a way to fully remove all traces of AP on the token?

Maybe using token with VBL already assigned has something to do with it? Since "the doors" has that long I-shaped VBL already assigned to the images?

Going to try it with clearing token topology first.

[exotic hill]

Yes, there are two ways, you can add LibActionPads to your campaign property and delete that from the toekn. You can open the Toolbox menu and select the toolbox icon, select that token, it will display "my" jsons and you can clear from there ala the video.

I've going to get tied up with some other things, may be an hour or so before I can test in 1.18 . . .

[willow nimbus]

No worries at all. I'm going to keep playing around with it between patients. Thanks for all you do, since I know this is an "in my free time" kind of hobby thing for you!

Seems to be working now, so I'm guessing it had to do with the image already having topology.

[willow nimbus]

@exotic hill How do you recommend adding light source tokens that won't register as the pads being "stepped on"?

Update: Not sure if it's the preferred or even only way, but I figured out putting lights on background layer seems to not trigger the pads.

[willow nimbus]

@exotic hill Also, I got the following when I tried to link a token to a trap template (not sure if I'm doing something that it's programmed or not):

Argument number 2 "trapID" to function "json.get" must be an integer.
Error trace : APlinkPads@Lib:ActionPads <<< configSet@Lib:ActionPads <<< macroLink

Both were on the hidden layer when I had them both selected and tried the link chain button in AP.

I want to resize the AP trap template (white image) over just the glowing circle part of the huge square trap overlay token, so that if they walk on the glowing part, the trap triggers and the whole square overaly becomes visible with a notice that the trap was triggered. Thought maybe using the "link" ability would allow this, but is there a better way? If not, I may use a photo editing program to cut the image down to just a square at the circle's edges. (I'm just using the resources that came with the map download, hence the huge square overlay).

Think I figured out that I just need to use the red trap button to make a trigger for it.

[exotic hill]

I'm not sure I understand the use case, but it sounds like you want Lights to go "on" when you step on a pad?

[exotic hill]

I'd like to mitigate that script error with a captured error so I'll do some testing with that.
Here is an example of a linked trap setup
The nets are the traps (white trap token with a net image), the yellow is the detect pad, the red is the trigger.
If a player walks into the red I run a genericscript
[h: dc = 8][h: chkSKZ = if(hasProperty('Wisdom','myself'),getProperty('Wisdom','myself'),0)][h: chkWISm = if(hasProperty('Wisdom','myself'),getProperty('Wisdom','myself'),0)][h: chkWISp = if(hasProperty('WisdomPro','myself'),getProperty('WisdomPro','myself'),0)][r: if(chkSKZ && roll(d20)+chkWISm+chkWISp>dc,2,0)]
That will, based on the tokens wisdom, it will "detect" something.
If any player steps on the red trigger, the trap goes off an all 3 nets "drop".
This was done by setting up each net trap, droped a red trigger pad, then linked those net traps to the one trigger.

I'll work to put some trap / step-on videos together.

[willow nimbus]

It was more that dropping a light source into a room that had a trigger pad associated with it was triggering the "roof" to come off. I only wanted it to come off the players stepped on the pad. I -believe- I can avoid the problem by putting the light source tokens (candles, lamps, etc.) on the background layer.

[exotic hill]

Another trap example that makes another token become visible, and stopping player movement. The one tweak I did NOT make was changing the white trap icon to 0 opacity (you can't make it not visible or it will disable the trap).

[exotic hill]

There are pads designed for "roof" usage where you can hide objects under a roof. Like door mats and another option to toggle the roof on/off.
Either of those allow you to hide things under the roof. I think the challenge with lights is, when they're set, they're always visible. Again, not 100% clear on what you're trying to do but it may require some extra steps or maybe even a custom macro hook.

[willow nimbus]

@exotic hill Do you know of a way to have a trap's triggered token topology (VBL & MBL) not active until it's triggered and transferred from the hidden layer?
I'm using remote triggers and everything is working amazingly, except the VBL blocks the path players need to take before they can reach the trap that calls in the token the VBL is on. Hopefully the the attached screenshots illustrate what I'm wanting to do. The circle of "teeth" is the opening to the throat. I want to call in the "throat" and have the players be inside it via an overlay token that blends perfectly with the map. Only thing is, even though the throat token is on the hidden layer until they step on the throat opening, they can't get there because of the VBL & MBL from the invisible (hidden layer) token.

Maybe a super-fast animation of the token sliding to the spot after they trigger it? Just brainstorming here. lol

[exotic hill]

Is the Mouth an actual overlay (the overlay function) or a token?

There a couple ways I support VBL transfers. In this case I'd want the mouth as a token, the BL to encompass the whole image on the left (hiding the throat (essentially what you've done minus the cutout).
I'd use the "Invis. On/Off" pads. . .
bah, let me take the image you shared and make a video :p

[willow nimbus]

No actual MT overlays in use other than the ones AP uses. I call them "overlays" because that's what the map and token publisher calls those those types of tokens/images.

The cutout is from the token's own VBL for the "throat" token that comes in as the players step on the "teeth" trap.

[exotic hill]

Messing with this a bit still. It's not working the way I want because of how the VBL needs to disappear in the one area and drawn different to allow the south passage access (like you said in the first place). The design at the moment is just to toggle the VBL on/off. I think the use case you've demonstrated is a good idea for me to add it 🙂

[willow nimbus]

@exotic hill Are the welcome mats/step on triggers working correctly for you in 1.18 and the latest AP? Earlier, I ended up having to use the regular (resizable) version of the step on pad, as using the on and off version weren't having any effect when a token stepped on the pads. Let me know if you would like me to try and test it in other scenarios if it's not easily reproducible.

(I even went and re-watched the video from the pinned post with the red tents again to make sure I was doing the "enter/exit" tokens properly.

[willow nimbus]

@exotic hill Sounds like that would be pretty amazing and I can think of at least one other map my party played recently where it would have been a great feature.

[exotic hill]

No, they're not, I noticed this too. I think it's actually something I overcorrected when I cleaned up the extra )

[willow nimbus]

@exotic hill Also, is there a way to prevent a door token from tripping the pressure pad? I had the roof working great, but then added a door and it's registering that something is always on the pad, thereby making the roof stay invisible. Thanks!

EDIT: So order seems important: Put door(s) in place first, then add the step-on pads.

Also, when I placed the door, it didn't seem to like taking the VBL from the new wall drawing lines, but worked when I used the older (poly) drawing tools. Not sure if that's a known issue.

[exotic hill]

There's a "process" to hide things under roofs / toggle pads. Doors do need to be done first. Then the roof. I assume you're using invis pads (since on/offs are broken 🙁 ).
The steps are.

• Select the pad
• Open the Gear\Wrench menu
• Select the Eye icon
• Select the tokens you want hidden under the roof (holding shift down if more than one, can only be done per layer)
• Once the tokens are selected, select the Eye icon again

If you have things to hide on multiple layers, just repeat that process after selecting the layer (this is required because your selection *clears * if you leave a layer and select something else)

[exotic hill]

On the new walls, there are no functions available to interact with them.

[willow nimbus]

Thanks much for this! Good to know that it can be managed in AP itself!

[exotic hill]

LibActionPads v3.10.11

Several updates:#134 Tokens following a leader should now stop following a path when the leader gets blocked/stopped. #133 If using toggle roof tokens, I now enforce a `resetFOW` to block site inside of buildings or under roofs #132 Portals/Teleports should now more accurately place tokens when "landing" #131 You can now output to chat and share to players, instead of output to dialogs, frames, or overlays. #130 Now check for impersonation and proper distance checks #129 Impersonation is required to emulate player token movement. The GM can now override any token movement / block when not impersonating. This means GM's moving player tokens over traps or pads that stop players, will not stop a GM moving it. #128 This error is now being handled.
Please note #129.

Other fixes not shown above

• Invis On/Off pads are now working (aka Door / Welcome Mats)
• Cleaned up extra ) findings that MapTool 1.18.x detected.
• Several minor code updates.
• Broke out Rotation and Animations options for Step-on and Clickies.

Some things under development

• For step-on and clickies: More Lib:Slide integration to allow custom animations like sliding into a trap
• Options for multiple BL transfers. Not just a toggle BL on/off but to replace it with other BL captured BL

As always, back up your campaign and run the Transfer macro from the old / renamed lib:actionpads token

[willow nimbus]

Going to try this out after today's session. Too nervous to switch to it atm, as I've get everything working pretty solid right now.

[willow nimbus]

@exotic hill So, got new version installed and trying to add a slide up door. Everything goes great until I go to close it for the first time, and then it gets gigantic for some reason (see screenshots). Not sure what's going on that would make the image change so much.

[willow nimbus]

@exotic hill Doormats are working nicely, though! Was struggling for a bit, then realized I had to add "actionpad" to GM name of the object I want them to invis toggle or they don't do much. lol.

[exotic hill]

That seems odd and I'm not sure at all why / what would be causing that.
I'll test and come back 🙂

[willow nimbus]

@exotic hill Is there anything significant actually stored on the ActionPads lib token related to the current campaign? Just wondering if it's safe to move it to another map.

[exotic hill]

It stores a JSON for the maps that contain step-on pads (of any kind, traps, etc).
It self cleans in that if it doesn't see a map, it will delete that mapID and subsequent entries.

So if you take it back and forth, it's going to cleanse itself.

It does not track doors in this way, or clickies.

[willow nimbus]

That sounds like it would mostly be a problem between campaigns? Just moving it to a new map, it would still see the maps with the step-ons and traps, right?

Basically wanting to move it to a new map so it -won't- get transferred between campaigns when I take my normal GM tokens map back and forth.

[exotic hill]

If it is anywhere in the campaign, it should work. You shouldn't need to move to any other map.
edit, err, once you cut/paste it to another map you shouldn't need to move it :).
and I've not tested what you're doing.

[willow nimbus]

Copy, and thanks!

Gonna make a new map called "ActionPads" 🙂

[willow nimbus]

So far no issues with moving lib token to a new map, just FYSA.

[turbid quarry]

@exotic hill Current version in top post has wrong link.

[candid ermine]

I know I've done this before, but it's been a while and I cannot remember how to do it. I have tried following the Youtube video, and I follow it to the letter as far as I can tell, but I cannot get roof visibility to work. Here's what I am doing:

1. I have an outline and a roof token on the object layer. They are the same size
2. The outline is beneath the roof, and both are visible to players.
3. I click Step On and then Invisibility Toggle Pad.
4. This generates a toggle token on the Hidden layer which I then resize to almost the same size as the roof token.
5. I then move to the Token layer and move a token onto the roof, and nothing happens.

The libactionpads property on the toggle token looks like this.

{
  "apType":"toggle",
  "apStates":{
    "chk_PRF":1,
    "chk_LNK":0,
    "chk_MAC":0,
    "chk_SND":0,  
    "chk_IMG":0,
    "chk_VIS":0,
    "chk_OPC":1
  },
  "apID":"150CA5C5C1264187A7851C3CCC6F76D3",
  "toggleID":"E435B9C7B0FB4BCAB19158FF30D9E327",
  "apTokensOnPad":""
}

I have confirmed the tokenIDs.

What am I doing wrong or missing?

[exotic hill]

Did you upgrade to the newest version? There was a bug I introduced (not certain when), but it was fixed in 3.10.11

I'll run through a quick test and make sure I didn't mess anything else up 🙂

[candid ermine]

It's never been used in this campaign file before, so it is brand new.
Yes, this one: Lib_ActionPads-oTM.v3.10.11.rptok

Should I maybe have taken the one without oTM?

[exotic hill]

onTokenMove is required for step-on so you're good there (-oTM has it disabled, assumes you've integrated onTokeMove elsewhere)
And this one:

Should be this easy 🙂

[candid ermine]

Yeah, that seems to be exactly what I am doing, but it doesn't work.

[exotic hill]

let me check with hex . . .

[candid ermine]

Oh, could it be that?

[exotic hill]

No, I just tested and it's working there too. Is that PC token visible to players or anything "funky"?

And to be double sure, you're using the AP version that has the onTokenMove macro and NOT -onTokenMove

[candid ermine]

So, probably the wrong library?

[exotic hill]

You can just rename that and remove the - However, you need to make sure you are NOT using onTokenMove already, on another Lib:token.

if you rename it you won't have to redo any step on pads

[candid ermine]

Too late 😋

I do have a onTokenMove in my add-on library, but it only contains this:

[h:tc.debugLog("onTokenMove", getPlayerName())]

[exotic hill]

You can't have more than one active onTokenMove macro across your campaign. I'd not use the debug one unless you're debugging 😉 and just rename it -onTokenMove
edit
I didn't catch the add-on bit, so it's a few more steps for you, I'm sure the rules apply the same

[candid ermine]

Ok, I'll cook a new version without the macro. It's a place holder anyway

[candid ermine]

Now it works! Thanks. So, in the event I ever need to implement onTokenMove, how do I handle it then?

[exotic hill]

On line 17 of the onTokenMove macro.

What "I" do for my lib:tokens to play nice, is I only use the -oTM lib:tokens, and I add Lib:Bootup as it is a one stop shop for onTokenMove , onMouseOver, onMultipleTokenMove, etc.

Lib:bootup is on my github site.

However you can either add your custom onTokenMove macro before line 1 or after the last line of whatever active onTokenMove macro you're using.

[candid ermine]

Right. Gotcha. Thanks 🙂

[sullen wharf]

Bootup is a life saver. i put all my onTokenMove s on there for any other libs i'm running. i definitely reccomend

[candid ermine]

Currently I only have the one in LibActionPads, so I'm good, but I'll certainly keep it in mind if I ever need it.

A small add-on question. Is it possible to get a NPC in the tent, without having the roof go invis?

I believe I have asked this before, but it is long ago...

[exotic hill]

Yes, you can hide things under things.
#1102924536279740518 message

I could see a bug where, if everyone leaves the tent, along with the NPC, they could be triggered to go opac / not-visible.

[willow nimbus]

Are you saying you want the NPC to be able to actually move/travel into the tent without the roof going invis, or that you just want to be able to PLACE an NPC in the tent without the roof going invis?

In the latter case (well, in most cases, actually) I prefer using the doormat pads so that I can more easily control when the roof goes transparent/opaque.

[candid ermine]

Both probably, but it is not in any way imperative. I am merely curious 🙂

[exotic hill]

My mind went to a vendor in a tent, that PC's interact with, that would only be seen, once you enter the tent.

[candid ermine]

That is a good example of what I was thinking as well.

[patent spindle]

When attempting to link Roof Visibility pads I am getting The following Screen

I am using Maptools version 1.17.1 and actionpad 3.10.11

I clicked through leaving everything at 0 and it did what it was supposed to, but it seems like this is not defined someplace

[exotic hill]

Let me do some tests quick tests.
edit
Yep, that's a bug.
This should fix it (don't forget run Transfer from your renamed lib:token)

[willow nimbus]

I forget.... Is the difference between the two versions just that the non-oTM one already has the oTM macro renamed so that it's inactive?

[exotic hill]

-oTM is to mean no active onTokenMove macro, so yes 🙂

[patent spindle]

Question: For Traps, I change the max count to 1. But it continues to trigger when after. (its supposed to be a one and done trap)

[exotic hill]

No, it should not be doing that. I did a quick test and it is working for me.
I'll post a video in a sec.
Are you doing any blocking of movement (deny move if trapped)?

[patent spindle]

no

ok now its working

Before It was triggering like 50 times.

Wait... I think i see something. I also had a Disarm Token out the first time. I just did it again and this time with a disarm token and its still triggering after the count. Remove the Disarm and it stoped after the count.

[exotic hill]

Ahh, yes, you're correct. I see that too (with the disarm).
I think/expect it to be an easy fix. I'll work on it a little later today

[patent spindle]

coolies. Not crazy afterall. (Making you work with this trap function :P)

[willow nimbus]

I had seen something similar before, but just thought it might be intentional that the token needed to remain on the disarm "button" or the trap would automatically reset (which I didn't want, but didn't know better).

I could actually see the utility of it working both ways: 1) Another character needs to stand on this "plate" to disable the trap for their fellow party member, or 2) Stepping on the "disarm plate" permanently disables the trap.

Watching your video, though, I see that I probably just needed to set the trap to just fire one time and didn't need to bother with the disarm button.

[exotic hill]

Disarm was meant for things like your 1) example, player stands here so trap won't trigger, or if an object is removed from a pedestal , the trap gets enabled.
I don't really have a true "disarm".
Any trap that is set to Visible to Owners Only is fully disabled / disarmed / won't trigger. This can be set easily by connecting a macro to the trap, trigger, or disarm pad.
example macro to disable after one Step_On
[h: setOwnerOnlyVisible(1,'927A8DC4A3D14B8BA65C40E6EA626F2E')][r: 1]

[exotic hill]

This should resolve the disarm pad / too many trigger issues. It should work in combination of disarm and number of times triggered.
Also removed some debug chats I'd left in.

[patent spindle]

aight, I will break this later 😛

Currently in the process of making a Dumpster Generator

[exotic hill]

I'm hoping to finish this soon, just debating on how to capture the blocking layer for these options (e.g. use a token and size a rectangle to capture it, via transfer*BL functions ... or some form of get*BL function).
While not a trap as Tucker71 was looking for, it should allow the same functionality. Token triggers an event and slides along a set path sourced from it's current location, falls into a pit trap, or just activates a step on pad and ?BL is swapped vs removed

[turbid quarry]

@exotic hill Would there be any issue with closing the Designer with a simple closeOverlay call? I know closing the ocs via the designer sets an ap state setting... but didn't see anything for the designer.

[exotic hill]

No, that can be closed whenever.

[willow nimbus]

Sorry if I've already asked this previously, but is the only way to make stairs "invisible" to connected players by setting opacity to 0%? I know they became inop when I unchecked "visible to players" in token context menu.

The map already has stairs, so don't need the icon, but I like to avoid setting opacity to 0% so that -I- can still see the icons in GM view.

Thanks much!

[exotic hill]

You can move them to the hidden layer and players won't see them.

[willow nimbus]

@exotic hill Any idea what would be causing stairs to warp me to the upper-left corner of the map instead of to the other half of the pair of stairs?

[upbeat nymph]

Not sure, but if you don't give coordinates, things default to 0,0

[willow nimbus]

Ahh, upon further testing it only seems to happen if the token setting is not snap to grid.

[exotic hill]

That still shouldn't be happening. No snap should still be working.

[exotic hill]

Found and fixed this :).
I'm hoping to get an update out this weekend.

[exotic hill]

LibActionPads v3.11.0

• Portal, stair, gate, and misc fixes

[willow nimbus]

Just updated to this version, will give it a whirl when I start building my next campaign world later this week. Excited to try it!

[willow nimbus]

@exotic hill Not sure if this is a known "issue," but renaming a map after settings up portals, etc. with ActionPads caused them to break for me. Wonder if instead of referencing what it needs by a fixed map name if it could instead use the getCurrentMap function?

On 1.17.1 Win 11

Error is:

Continuing after error running event onTokenMove @ MainLibToken, error Can not find map "4.3 Landro" in function "getTokenX"..

After reviewing my oTM macro, it seems it's already only referencing the map via getCurrentMapID, so it must be something more nested that's making a connection to the actual map name.

[willow nimbus]

@exotic hill In case it helps, here is my oTM macro:

[h, if(isFunctionDefined("actionPad_oTM") && !isFunctionDefined("slide_oTM")),CODE:{
    [h: actionPad_oTM(getLastPath(),getLastPath(0),currentToken())]
    [h, if(macro.return=="deny" && isOverlayVisible("ActionPads oCS")): tokens.denyMove = 1]
}]
[h,if(isPC()), code:
{
    [h, if(getLibProperty("PersistentFOW")==1): exposePCOnlyArea(); exposeFOW()]    
};{}]
[h, if(getProperty("door.pinned")==1): tokens.denyMove = 1]
[h, if(getProperty("Movement") == "None"): tokens.denyMove = 1]

[h: vTokID = findToken("Trigger")]
[h,if(vTokID != ""), code:
{
    [h: vPath = getLastPath(1)]
    [h: vLocTrig = movedOverToken(vTokID,vPath)]
    [h, if(!json.isEmpty(vLocTrig)): Path.Trigger(vtokID, getCurrentMapID())]
};{}]

Interestingly, when I used

[r: json.indent(getInfo("functions"), 2)]

... I didn't see Path.Trigger as one of the listed UDFs.

[exotic hill]

I'll double check but I don't think I'm tacking "names" and only ID's. Renaming a map shouldn't cause that, but will test it out.

[exotic hill]

Not sure what to say on this one. That isn't a function I use Path.Trigger.

[willow nimbus]

Hmm, okay, thanks much for verifying!

[balmy scroll]

Hi, I'm tring to use this lib to set some doors, since the BoT doors doesn't seems to work on MT 1.18.
I'm following the tutorial but, when i click the "swing door" button the VBL doesn't align very well 😆 .
Before setting the door there was just a Wall VBL wall under the door.
Could this depends on the token i chose as door?

[exotic hill]

Due to how 1.18.3 offsets tokens, it does NOT work as expected. I think a new MT version is out (or will be soon).

[balmy scroll]

Ok, I'll go with the simple door maybe by now.
Thanks Jmr

[turbid quarry]

1.18.5 is out. But I thought this was fixed in 1.18.3 ...

[balmy scroll]

I was, and I'm still on, 1.18.5, but it seems not fixed. Even the simple door delete to much VBL on opening, but I think is the same problem.

[exotic hill]

I’m on the road this week but will check when I’m home on Saturday

[exotic hill]

I checked this and it DOES work as expected. The issue you're running into here is you'll need to reduce the size of the door so it only envelops the VBL/MBL you want affected. In your case, you just need to size and place the door image so the token/image only touches the VBL you want to move.
So, yes, this was / is impacted by the token you chose as a door. If you used any of the cheesy 🧀 built-in doors, you could have customized the size and avoided this :p

[exotic hill]

Yes, you're correct 🙂

[exotic hill]

an example using the simple built-in door

[balmy scroll]

Hi JMR, thank you for the advice.
I've used Gimp to reduce the "empty" surface around the door, and now it work perfectly 😉

[exotic hill]

@willow nimbus not at all what you mentioned in testing-feedback but this feature allows what you mentioned. In my testing (and it could just be me), the more onChangeSelection overlays you have, they seem performance impacting at times, like a lag symptom between click and react, so less is better IMO.
Anyway, the point was the video.

[willow nimbus]

Woah, that is awesome! I'm lovnig this. Only thing I would need to figure out is how to make custom images for the clickable "mag glass" since each room description is numbered (see screenshot). Is that already doable, or would that be a whole other level of modifying the feature?

But wow!

[exotic hill]

Do you want the players to click on it or just you?
Is the information you're wanting to display text, or a single image?

And if only visible to you for "clicking", the image,text, etc can still be displayed for all players

[willow nimbus]

Oh, definitely just me clicking. They typically won't even see those.

If I want them to actually see a note on something, I just force show it to them via showing them a handout on a token or something.

[exotic hill]

I would place the inspect / mag glass on each number, of your map, make them "Not visible to players" and just click them when you want to display something, the sources can be Notes, GM Notes, portrait image, handout image. You can select GM, gm-self, all, or self, as to the who can see it.

[willow nimbus]

Great idea!

[willow nimbus]

I feel like I'm formatting this header image as I've seen done similarily before, but for some reason the image doesn't appear the in the dialog output. Any ideas where I've gone wrong here?

<style>
.container {
           position: relative;
           text-align: center;
           color: white;
           }
</style>
<div class="container">
  <img src='[r: getTokenImage("", findToken("general_popup_header", "Resources for GM"), "Resources for GM")]' alt="Header" style="width:100%; height:50px">
</div>

[exotic hill]

I don't think your code is *wrong * but I couldn't get any function to work in Notes. In my testing I did take the result of this [r: getTokenImage('', 'Beucephalus', 'Curse of Strahd')] and that assetID:\\... did work

.container {
           position: relative;
           text-align: center;
           color: white;
           }
</style>
<div class="container">
<img src="asset://13eb4028efc7c283d331d214b23b8b3e" alt="Header" style="width:100%; height:50px"></div>```

[exotic hill]

On the doors discussion from Meleks thread, this is how I envisioned players to see/handle doors. I pop the actuator above FoW when the player is "in range". I do get the point around, it's not always easy to see/know a door is there

you only see it "this way", if you're impersonating a PC token OR you're a Player GM's are not restricted and can move through all BL and fog

[willow nimbus]

Nice. For some reason I was thinking that the door VBL in AP completely surrounded the door so that it wasn't visible at all. But that doesn't seem to be the case in the video. Will have to give it a try again. Thanks for posting!

P. S.: Was that vid on 1.18+?

[willow nimbus]

Yes, I was able to get it to work with an asset ID, but was trying to avoid that to ensure there wouldn't be any issues with transferring the image tokens between campaigns.

Glad to know it wasn't something I had screwed up. 🙂

[exotic hill]

missed your question, yes that is all on 1.18.5

[balmy scroll]

Evening @exotic hill , this "BoT_onTokenMove" macro that i see in my pads lib, has been automatically renamed by the lib itself since it finds anohter "onTokenMove" macro in the BoT lib?

[exotic hill]

BoT and ActionPads may not place nice together. I have not done testing recently. BoT does this, the renaming of onTokenMove macros. However it places "my code" at the bottom of the BoT onTokenMove macro and I don't believe it will function there. If I recall, you'd need to manually edit BoT's oTM macro and place ActionPads, onTokenMove code, there (I hope this makes sense).

Ultimately, there can be only one onTokenMove macro across ALL lib tokens and add-ons (that is why BoT does this).

If you're only using ActionPad for Doors, then this won't matter as onTokenMove is not a requirement for doors. If you're using any type of step-on pad (traps, roofs, trees, etc), those require onTokenMove

[balmy scroll]

Tbh I thinking about removing BoT from my campaing, at least by now, since I'm using that just for the teleports, and your ActionPad have those too

[exotic hill]

That would be the easiest path 🙂 (I'm bias tho 😉 ), and it doesn't have the initial "integration" that BoT can have, I tried to make all my lib tokens, drop-in easy

[balmy scroll]

And I did it ;).
I don't think the mighty @vivid moon will take it personally 😆 .

[balmy scroll]

Hi guys, I set up this gas trap with a trigger in the little room above.
I'm tryingo to add a sound to the trap but I have 2 quesiton:

1. should I add the sound on the gas or on the trigger
2. can I use a path like "file///c:..." to point a file on my pc?

[exotic hill]

I would add the sound to the trigger.
TBH I've not tested using a file syntax, It may work.

[balmy scroll]

Uhm, it doesn’t seems to work 🫤 nvm, I can make the “tsssssssss” sound with my voice 😂

[exotic hill]

I do have this as a "testing" source site (and for doors, and misc sounds). It's been months since I updated it. Most of it is a copy/paste of what @slim island set up in his soundShare site.
https://jmr3366.github.io/soundShare/

[balmy scroll]

Cool, the white noise feets perfectly 😉 Thx mate

[balmy scroll]

Another pair of questions 😁
Can i add all this tokens in the same trap, so they all appear once a player enter the room? And can i link 2 triggers, one for each entrace?

[exotic hill]

Yes, you can add two triggers, I don't think "linking" them would be required. Just drop two triggers.

To make the tokens visible, you'd need a script for that in the Step-On macro feature of the trap itself that runs a custom macro you made or something like this
[h, if(getVisible(findToken('hiddenTokenName'),0,setVisible(findToken('hiddenTokenName'))]
I'd think running a macro would be better as you've got a several hidden tokens there

[balmy scroll]

Got it thanks 😉

[balmy scroll]

Is it possible to "remove the trap" from this tokens without removing them form the map?

[balmy scroll]

nvm, just 1 token was a "trap token".
Anyway, I'm testing a simple macro to move a token form hidden to object layer, but i got this error.
In some previous campaign I've used the "switchToken()" to select the token I want to move, but it gives me the same error, so I don't think that this is the problem.

[turbid quarry]

You have an extra right paren in the findToken line.

That also doesn't do much of anything.

At the very least you're going to need to assign the findToken ID to a variable and then use it when setting the token layer... [h: tokID = findToken(tokenName)] [h: setLayer("OBJECT", tokID)]

[exotic hill]

I would place a macro on a lib:token somewhere or from the GM panel
with contents like this:

[h, if(getLayer(findToken('Ghost Female'))=='OBJECT'), foreach(oneToken,tokenList):setLayer('TOKEN',oneToken)]
[r: 0]```

[balmy scroll]

it kinda work, thank you both guys 😉 .
The list is a very good suggestion, I'm not used to use arrays even on my rl job 😂
Anyway the "if condition" give me an error:
*   Opzione di tiro "if": parametri di opzione 1 non adeguati.       Dichiarazione opzioni (se esistono): h,if(getLayer(findToken('Ghost Female'))=='HIDDEN'),foreach(oneToken,tokenList)       Dichiarazione Corpo : setLayer('TOKEN',oneToken)
Info errore: aaa@{name='aaa, location='campaign, source='campaign'}*
I can still use it without the if condition btw 😉

[exotic hill]

@turbid quarry, wanted to chat you up on your feature request https://github.com/Jmr3366/Lib_ActionPads/issues/140. I like the ideas. Some of it is already done but likely clunky/anti-user-friendly.
I wasn't sure if you've played with these features. The interact, step-on, proxy, features all have the ability to do a lot of what you mentioned.
I will look to add a staging, placement, trigger of sorts like what you mentioned.

I just finished an initial draft for removing and placing *BL. The BL is not transferred to a token. This is the beginning of my elevation implementation.
I want to finish my Initiative lib:token that will allow a cross map initiative list so IF you wanted, you could have "true" elevation via separate maps.

[turbid quarry]

I know that a lot of the tools to simulate "Encounter" triggers already exist... but I'd like to see it be more independent (like doors are)... and not fully rely on the oTM (only have it be an option). The basic idea would be to place tokens where you'd want them for an encounter then use the AP to "Setup Encounter" with options about how it handles that (hide the tokens and leave them where they are, move them off map to a staging area, drop a step-on pad, play a sound, etc.) Then be able to Manage the Encounter with an Encounter Actuator.

For example, right now I tend to setup most encounters by placing tokens in their spots and hiding them. I use a special state (just an "obvious" orange dot) to indicate that a token is invisible because MT does not have a good method of indicating that to the GM (though we have some better halos coming that might be a nice alternative). Then I have to go through and unhide them all when the encounter starts. I was going to make a quick lib to allow me to select all the tokens, set it as an "Encounter", and then give myself the ability to show/hide "encounters" easily (maybe play a sound and send some preset flavor text, etc.) And I know I could hook that into the AP, but it would be a lot of additional setup per encounter to utilize the AP as is... when I want to be able to do it all quickly and easily.

Nutshell: The AP has just about everything necessary to make a fully featured Encounter Manager, so before I started building some kind of intermediary between my framework and the AP, I figured I'd float the idea to see if you wanted to just built something more native into it.

[turbid quarry]

Initiative managers independent of the built-in one can get complicated and be hard to maintain full sync. Would be better if MT itself could link init windows to multiple maps.

[exotic hill]

Don't disagree but I'd expect it a ways out. I don't have any great solution for cross map "attacks" or how macros running from one map with a target on a different map; how could that work . . .. (in the mean time, I'm going to mimic something what Melek has done).

[exotic hill]

The non-otm Trigger already exists, so for starters, I can add a token selection option that moves tokens around from a staging area, to a production token specific x,y,f (and include make visible, etc).

[willow nimbus]

Hmm, I run mine the same way, FB. Interestingly, I've never thought about it, but could probably come up with something in onChangeSelection that would add something (a state icon?) that would indicate to me (the GM) that the players can't see tokens that aren't visible to players. I know that the name is a different color when hovering over it, but that isn't super noticeable, and I still run into issues pretty much every single session where players are like, "Uh, we don't see the creature(s) you're describing." Ugh...

[turbid quarry]

I have a FREQ in for this issue, and while it generated a lot of discussion... and anyone who has actually GM'd with MT knows there is a problem... the solutions seem too paralytic to actually have anything implemented. So, I continue to use a basic ORANGE dot state to show me when tokens are hidden. It's not perfect, and still prone to potential error, but it's what I've settled on for now. https://github.com/RPTools/maptool/issues/3347

[patent spindle]

Is there known issue with Tokens not able to move with Tokens able to navigate around MBL toggled on? My PLayers (and players only) are having issues with moving them

[exotic hill]

Not that I'm aware of, is it snap or no-snap, fow, ?

[patent spindle]

Snap, with FOW

[exotic hill]

I will test to confirm and share my server settings, etc, but it should be working.

[exotic hill]

This is my server settings, and a video example

[exotic hill]

I went through several other tests. I'm not seeing this issue. I would confirm these settings in the config menu.

[exotic hill]

After playing with it for a while now, from a client, where I did run into this; once I reset FoW, the problem was resolved. I'd expect if your setting above is 0 or 4,5,6, you shouldn't have had this problem.

[patent spindle]

thanks

Mine was Set to 0

Still doing it, Send yo0u a video you can see what I mean

https://1drv.ms/v/c/1e889cc3642d526b/EU_KTTZl03pDrPNwx5qORDwBhGwkqw82K2p4rG5H4pIy5g?e=Z33XBP

[patent spindle]

I think its some weird maptools issue with it.

I had to restore Fog for each of the players

[exotic hill]

Sounds like the same issue I had seen.

[patent spindle]

THanks for the assist

[normal oak]

Hey, a quick question, I have been using this for doors so far, but wanted to try my hand at doing it with Stairs as well, and for some reason the onTokenMove doesn't seem to be working. I am fairly new to the whole thing, so I don't know if I might have missed a step on setting it up.

[exotic hill]

You would need to use the ActionPads download that does NOT have the -oTM .
You will also need to make sure you only have on token with onTokenMove
What other Lib:Tokens do you have, if you can share?

[normal oak]

Simple5eHelp is the only other one I have, I will need to change it to that one then.

Is that video still correct on how to transfer between? or is it not needed because of only doors?

Ok, changing to that version works now.

Thanks.

[exotic hill]

That is still correct.

[normal oak]

By the way, this tool is awesome, and works so well, once you know what you are doing with it.

[normal oak]

Is it possible to have 2 objects be a "door" but not have something with any vision blocking? Basically I want to have a sliding area, but just want it to move.

It is just covering something on the background layer.

Actually, I am going to just create it as a single asset.

[exotic hill]

I do check for some sort of MBL or VBL on the door. It doesn't have to be much, in this example it's just that small bit in the screen shot and then the video

[normal oak]

Ok, that makes sense

[willow nimbus]

Just curious, how did you get AP to work without using a table for images? Specifically, I'm thinking about the icons in the Designer Overlay and default door images.

[exotic hill]

It's not an easy procedure and I'd make copies of your tokens before doing any of this: https://wiki.rptools.info/index.php/Adding_extra_image_files_to_tokens
(it's also technically not supported)

[willow nimbus]

Holy Moly! Talk about a hack! LOL. Hmmm. Not sure if I want to get into all that, but distributing the token and also the table entries seems kinda janky, too.

[turbid quarry]

Speaking of this hack... You have image assetIDs in the LibActionPads prop and the AttachedImageMap prop. Some are different (i.e. apIMGdoorOpen and doorOpen). What is the difference between these two sources of IDs?

[exotic hill]

That makes no real difference though. The AttachedImageMap prop was the name of the token when I dragged it on the the map, and is what gets stored in assetcache (two files are written to asset cache, the image file and an info file). When I inject the image into the lib token, I used the original token name (e.g the filename of the image). The name in the LibActionPads prop is the one I use in the code.

[exotic hill]

I think the future of this is to use / convert it to an add-on (a bridge I've not walked across fully yet myself). The other option is to use github or another "hosting source" where you rest.get. This is what I'm doing in a future update to LibDiceOverlay (so you no longer need the tables).

[turbid quarry]

So, it makes a little bit of difference for what I was going to use it for... as part of my local "Lib:AP_Extra" I've added a way to dump all the AP icons into a table where I can then peruse the icons (currently 149 icons) and easily change anything I want, then transfer the changes back to the LibActionPads prop so it uses my new images... and I was going to use the existing AttachedImageMap as a record of the "default" images if I wanted to switch back to them. But if it's different, that was a potential problem. Not a big deal, as I can save the original LibActionPads APImages field on my lib but was going to save myself that step.

[exotic hill]

Neat Trick 😉

[willow nimbus]

Been playing around with old BoT campaign and was trying to remember if you added "vehicle" functionality to AP?

[exotic hill]

Yes, it's under the toolbox, Not sure if it's what youre looking for tho 🙂

[patent glacier]

Is there any way to have this for, say, buildings and such? But without reseting player movement through walls?

I'm running in-person DnD and want to have roofs as a sort of fog of war only on individual buildings for more of a immersion. But i still want to have god move enabled.

[exotic hill]

I'm not certain I understand but there is a way to allow roofs as a sort of fog of war, like this video:https://cdn.discordapp.com/attachments/1102924536279740518/1422923289877155950/apDoorsOverFoW.mp4?ex=6906a5d4&is=69055454&hm=210f9536ad67929cd2ee0f4b127640cd4857c9ba455d76ef7f70b205d4d5368e&
However you'll notice that as soon as the player token goes under roof, it's force-stopped.
I do this so I can hide the roof and lay down whatever blocking layer could have been under the roof.
I could be missing your point altogether though . . .

If you could share a bit more or let me know if I'm on the right track 🙂

[patent glacier]

That’s exactly what I want except for it force-stops the movement

I’m going to be moving the players by my own hands; and if I say they make it inside they make it inside. I don’t care if there’s a wall.

TL;DR Keep the roofs and get rid of force-stop.

[exotic hill]

I can add that as an option. Let me see if I can provide a hack for you. . .

[patent glacier]

That would be soo sweet of you!

[exotic hill]

Are you using toggle or pad on/off for your roofs?

[exotic hill]

I'm going to assume you're using toggle pads and v3.11.0 of ActionPads.
In the -Utils Pad macro group. Expand the macros and locate the APprocessPad macro.
On line 239, it looks like this: [h, if(firstStep),CODE:{ change that to be this [h, if(1==0 && firstStep),CODE:{ so it is never successful.

[patent glacier]

I’m starting up my PC now.

And I don’t know yet; probably pad on/off but I haven’t been able to get that far because it was stoping GM’s player movement through doors and windows.

[exotic hill]

I'd expect that hack should do it :).
The next version of ActionPads allows a GM to move a token as you describe, without limits, (but players can't). A GM can impersonate a player token to emulate their experience.
Meaning to say, I'm thinking, if you're moving the tokens, and you're a GM, then this will be the future default behavior. If this is for players to move and not be blocked, that would be new feature.

[patent glacier]

It is for GM's. It's just players won't be able to move their tokens due to it being on one screen for in-person play.

Thanks bunches!

[patent glacier]

😬 I spoke too soon. It doesn't work; might be because i impersonate ActionPad themselves so i impersonated an NPC and deleted them to clear selected.

Walls (VBL,MBL) still block movement with actionpads on the map. When action pads is removed walls no-longer stop movement like expected.

[exotic hill]

If you can undo the hack and can you check this setting, and make sure it's 0:

[patent glacier]

it was a 1 and not a 0; also how did that menu come up? I was looking for it and it just randomly popped up like a fairy on my shoulder arrived.

Also; that worked! Thanks!

[exotic hill]

This Macro on the lib:token and the gear cog in the overlay

[slim island]

This is also doable by using an image for FoW

[willow nimbus]

Hmmm, I haven't tried using a texture for FOW yet; now I'm wondering how that will "feel" with roof/canopy textures.

[exotic hill]

I think you'd have one image where all the roofs of that map align with the background (I've not tried that myself 🙂 ).

[willow nimbus]

Which sounds pretty neat, tbh.

[slim island]

Yup. Means having a background image and a matching overhead image. Good for forests too. Only problem is you need the whole map as an image.

[balmy scroll]

Hi all,
I have a map with a little dungeon where I set some doors.
Now I need the same dungeon in a "night" version, with some other enemies and other little differences, so I've tried to export the original map and import it again, but here comes the issue: the doors no longer works.
When I click the trigger, i get this message
SUCCESS:APoD - Reconnected door!
I think that the reason is that those doors are kinda stored with the original map name, and now, on a different map, I need to redo all the doors. Am i right?

[exotic hill]

This is because imported maps get new tokenIDs. I use tokenIDs to track the relationship between the door actuators and the object layer door. The "reconnected door" is a best effort to reconnect the actuator to the door. Best effort in that it looks for the closest door and attempts to "connect" those two things. If you have a double door or several doors close to each other, this "auto-connect" may not work well.
I did create a mapexporter lib:token to overcome this issues. This is in the drop-in-tools section.
Some background info: https://github.com/RPTools/maptool/issues/4789

[lilac lodge]

where is the link for the 3.11 download I cant find it, I can find 3.10 which i have but I would like 3.11 as I updated to 18.6 recently.

[exotic hill]

It's on the pinned post 🙂 #1102924536279740518 message

https://github.com/Jmr3366/Lib_ActionPads/releases/tag/v3.11.0

[compact gull]

Hey Jmr, I've been playing around with actionpads and making doors. The tutorial video is good but I'm running into an issue where the door image doesn't align with the token outline. If I move the image to match the outline the pivot point changes too.
As you said, it is easy to use and set up but I need some trouble shooting help on this.

Pic attached to hopefully make clear what I am talking about.

[exotic hill]

for hinged / swing doors, it will offset the token so it will pivot at the correct point. That was something MapTool changed in 1.18.x (I think). I'll do some testing to see if there is a way to mitigate that but it's sort of a side affect of swing/ hinged doors.

[compact gull]

OK, thanks for the info. I'll live with it for now. It was pretty extreme in a couple of doors I did, so much so the outline did not intersect the image at all which made it somewhat awkward to select.

Another issue I've run into happens when I use the stairs or teleporters. I have a property on tokens called Condition that contains the following code:
[h: stateList = getTokenStates()][h:sList = ""][h, foreach(item, stateList, ""), if(getState(item)): sList=listAppend(sList,item)][r:sList]

This is so when I mouse over a token the character sheet shows what conditions/states are active on the character.

After using a actionpad teleport or stair this code either vanishes or it gets replaced by this code:
{"layer":["token"],"pc":1,"range":{"token":"D79FA55EC870497982C447AE2BEE0EC6","distancePerCell":0,"upto":2}}

Any idea on what is going on here? To be clear, this change is unwanted and is some side effect of actionpads.

EDIT: Seem to have fixed it by changing my property Condition to Conditions. I guess actionpads uses condition for something.

[willow nimbus]

@exotic hill Does AP support the sound proximity stuff that was in BoT? I don't run BoT as it hasn't' been updated in a while and don't need most of what it offers, but I created a new map with a waterfall and want to make the volume increase as the players move toward/away from it. Thanks!

[exotic hill]

Yes, the audio pads support distance and sight checking.

[bright ridge]

I have a quick question — maybe someone here can help.

I was previously using MapTool version 1.15.2 with the SimpleDoors framework for interactive doors without any problems. I’ve now tried upgrading to versions 1.16.x, 1.17.x, and 1.18.x, and I’m running into the same issue in all three:

When I use any framework that relies on the door logic (SimpleDoors, SmartDoors, ActionPads), my mouse starts jumping around whenever I move a token. This only happens while the associated overlay is active (as shown in the video).

I tested it on a fresh map with the unmodified framework and a newly created NSC token. No server running, no other frameworks or macros interfering just Maptool and ActionPads.

The MapTool I'm using is a fresh install, though my .maptool-rptools folder might still be from 1.15.2 idk.

The NSC Token is:

• visible for players
• snap to grid
• owned by all users

Does anyone know what could be causing this? I couldn’t find anything related in this post.

[willow nimbus]

@exotic hill I'm suddenly getting an error when trying to place a new step-on pad:

ERROR:pS_N - actionpad must exist in GM name!

Any idea what could be causing this?

[exotic hill]

If you're setting a token as an actionpad, "ActionPad" has to be the GM name, it's a safety measure. You can change the name back, afterward.

[bright ridge]

Here are some logs, dont know if it helps, the errors inside do not appear each time :/

[exotic hill]

The mouse jumping around though, ActionPads isn't doing anything with onMouseMove.
Let me check the logs you supplied.

[exotic hill]

When you mention NSC token, I'm not sure I know that acronym.
Can you share what OS you're running.
If you check the ActionPads settings, under the gear cog, they should be this:

[bright ridge]

Im using the german version of MapTool. I guess NSC is the german equivalent to NPC in Maptool.
Im on Windows 11 Pro 64x

[exotic hill]

I assume the same result if you save, then load a clean campaign with ActionPads enabled?

[bright ridge]

Created a new map, dropped ActionPads Lib into it as well as a new token. Saved. Loaded Campaign again same issue (ActionPads onCampaignLoad did its job)

2025-11-30 22:09:38.407 INFO  net.rptools.maptool.client.MapTool - ********************************************************************************
2025-11-30 22:09:38.410 INFO  net.rptools.maptool.client.MapTool - **                                                                            **
2025-11-30 22:09:38.410 INFO  net.rptools.maptool.client.MapTool - **                              MapTool Started!                              **
2025-11-30 22:09:38.410 INFO  net.rptools.maptool.client.MapTool - **                                                                            **
2025-11-30 22:09:38.411 INFO  net.rptools.maptool.client.MapTool - ********************************************************************************
2025-11-30 22:09:38.411 INFO  net.rptools.maptool.client.MapTool - Logging to: C:\Users\orbde\.maptool-rptools\logs/maptool.log
2025-11-30 22:09:38.411 INFO  net.rptools.maptool.client.MapTool - getting MapTool version from manifest: 1.18.6
2025-11-30 22:09:38.411 INFO  net.rptools.maptool.client.MapTool - getting MapTool vendor from manifest:  RPTools
2025-11-30 22:09:38.460 INFO  net.rptools.maptool.client.MapTool - argument passed via command line: -v=1.18.6
2025-11-30 22:09:38.460 INFO  net.rptools.maptool.client.MapTool - overriding MapTool version from command line to: 1.18.6
2025-11-30 22:09:38.460 INFO  net.rptools.maptool.client.MapTool - MapTool vendor: RPTools
2025-11-30 22:09:38.472 WARN  javafx - Unsupported JavaFX configuration: classes were loaded from unnamed module @4de4b452
2025-11-30 22:09:41.138 INFO  net.rptools.maptool.client.ui.MapToolFrame - Removing the F10 key from the menuBar's InputMap; it did exist
2025-11-30 22:09:41.614 INFO  net.rptools.maptool.client.ChatAutoSave - Starting the countdown again
2025-11-30 22:09:54.334 INFO  net.rptools.maptool.client.TransferableHelper - Selected: java.awt.datatransfer.DataFlavor[mimetype=application/x-java-file-list;representationclass=java.util.List]
2025-11-30 22:10:01.242 INFO  net.rptools.maptool.client.ui.token.dialog.edit.EditTokenDialog - Stopping autoGenerateTopologySwingWorker...
2025-11-30 22:10:02.371 INFO  net.rptools.maptool.client.TransferableHelper - Selected: java.awt.datatransfer.DataFlavor[mimetype=application/x-java-file-list;representationclass=java.util.List]
2025-11-30 22:14:43.132 INFO  net.rptools.maptool.client.AutoSaveManager - Time to copy Campaign object (ms): 8
2025-11-30 22:14:43.134 INFO  net.rptools.maptool.client.AutoSaveManager - Starting autosave...
2025-11-30 22:14:43.641 INFO  net.rptools.maptool.client.AutoSaveManager - Automatisches Speichern abgeschlossen.  Dauer (ms): 506

And no errors this time >_<

Could it be worth a try to move my .maptool-rptools and let Maptool create it again? Im using Maptool since 1.12 or so and never refreshed these files i guess

[exotic hill]

yeah but this is the "same" in both your error logs
@proud charm any pointers on what would cause this: ERROR net.rptools.maptool.client.swing.AbeillePanel - Could not init method: initPropertyTable java.lang.reflect.InvocationTargetException: null at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source) ~[?:?] at java.base/java.lang.reflect.Method.invoke(Unknown Source) ~[?:?] at net.rptools.maptool.client.swing.AbeillePanel.panelInit(AbeillePanel.java:98) ~[MapTool.jar:1.18.6] at net.rptools.maptool.client.ui.token.dialog.edit.EditTokenDialog.<init>(EditTokenDialog.java:132) ~[MapTool.jar:1.18.6] at net.rptools.maptool.client.ui.token.dialog.edit.EditTokenDialog.<init>(EditTokenDialog.java:137) ~[MapTool.jar:1.18.6] at net.rptools.maptool.client.ui.MapToolFrame.getTokenPropertiesDialog(MapToolFrame.java:777) ~[MapTool.jar:1.18.6] at net.rptools.maptool.client.ui.MapToolFrame.showTokenPropertiesDialog(MapToolFrame.java:763) ~[MapTool.jar:1.18.6] at net.rptools.maptool.client.tool.PointerTool.mousePressed(PointerTool.java:440) ~[MapTool.jar:1.18.6] at java.desktop/java.awt.AWTEventMulticaster.mousePressed(Unknown Source) ~[?:?] at java.desktop/java.awt.Component.processMouseEvent(Unknown Source) ~[?:?] at java.desktop/javax.swing.JComponent.processMouseEvent(Unknown Source) ~[?:?]

[exotic hill]

There is a 1.18.6 zip file version that you can unzip in a folder and just run it, there is no "install".
If you're able to try that, it would help confirm some things.

[bright ridge]

Downloaded the MapTool-1.18.6-win.zip extracted it. Also redownloaded the Lib_ActionPads.v3.11.0.rptok from github latest release. Dropped it into new map. saved campaign. reopened caimpaign. Same problem (Checked your settings from above, all the same)

maybe a wrong/old java version?

[exotic hill]

MT comes with it's own java though so you shouldn't need anything else.

[bright ridge]

Is there anything else I can provide to you to help finding the problem?

[turbid quarry]

If you're not using those for something else... uninstall all java installs. ReBOOT computer. Then test again. Sometimes there can be conflicts between standalone java and what MT has installed.

[bright ridge]

Im using java for some things but i guess reinstalling it (testing without it installed ofc) will not break my environment...hopefully haha
MapTool though is the most important besides Minecraft and some coding things ^^

Ill try...

[turbid quarry]

Btw, Minecraft has caused issues with MT in the past due to it setting an environment variable that sets memory too low. #archived-support-maptool-support message It seems to override MT's memory settings.

[bright ridge]

Would it be an idea to seperate my MapTool instance into a virtual machine? xD

Uninstalled all my java destributions. Rebooted PC. Extracted Maptool zip again (just in case) created new map and so on... same problem :/

[turbid quarry]

I think you can just edit the environment variable. But you could also try creating a second "clean" User profile (where you don't have minecraft or other java installs). In MT, when you go to gather debug information what's it say about memory allocation? (in Help)

[bright ridge]

This?

Max mem avail..: 7 GB
Max mem used...: 248 MB

==== MapTool Information ====
MapTool Version: 1.18.6
MapTool Home...: C:\Users\orbde\.maptool-rptools
MapTool Install: C:\Users\orbde\Desktop\MapTool Bugfix\MapTool-1.18.6-win\app
Max mem avail..: 7 GB
Max mem used...: 248 MB
Custom Property: -DMAPTOOL_LOGDIR=C:\Users\orbde\.maptool-rptools\logs
Custom Property: -DMAPTOOL_DATADIR=.maptool-rptools

==== Java Information ====
Java Home......: C:\Users\orbde\Desktop\MapTool Bugfix\MapTool-1.18.6-win\runtime
Java Vendor....: Eclipse Adoptium
Java Version...: 21.0.1
Java Parameters: 
  -Djpackage.app-version=1.0
  -Xss8M
  -Dsun.java2d.d3d=false
  -Dsentry.environment=Production
  -Dfile.encoding=UTF-8
  -Dpolyglot.engine.WarnInterpreterOnly=false
  -Djava.util.Arrays.useLegacyMergeSort=true
  -XX:+ShowCodeDetailsInExceptionMessages
  --add-opens=java.desktop/java.awt=ALL-UNNAMED
  --add-opens=java.desktop/java.awt.geom=ALL-UNNAMED
  --add-opens=java.desktop/sun.awt.geom=ALL-UNNAMED
  --add-opens=java.base/java.util=ALL-UNNAMED
  --add-opens=javafx.web/javafx.scene.web=ALL-UNNAMED
  --add-opens=javafx.web/com.sun.webkit=ALL-UNNAMED
  --add-opens=javafx.web/com.sun.webkit.dom=ALL-UNNAMED
  --add-opens=java.base/java.lang=ALL-UNNAMED
  --add-opens=java.desktop/sun.awt=ALL-UNNAMED
  --add-opens=java.desktop/sun.java2d=ALL-UNNAMED
  --add-opens=java.desktop/javax.swing=ALL-UNNAMED
  --add-opens=java.desktop/sun.awt.shell=ALL-UNNAMED
  --add-opens=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED
  -Djpackage.app-path=C:\Users\orbde\Desktop\MapTool Bugfix\MapTool-1.18.6-win\MapTool.exe

[turbid quarry]

Yeah. You've got enough memory, so it's not the minecraft issue

You can go delete the .maptool-rptools directory... MT will rebuild it on the next run.

[bright ridge]

Ive set the memory in my MapTool.cfg using

[JavaOptions]
java-options=-Xss8M
java-options=-Xmx16G

[bright ridge]

Will this reset my Maptool Settings?

[turbid quarry]

Not most of them... I think you'll have to select the theme again... and reposition windows.

The gather debug is only showing a 7G allocation though... wonder why. Mine, for example, shows Max mem avail..: 32 GB in gather debug because I have java-options=-Xmx32G in my config.

Maybe try setting it to 6G.

[bright ridge]

Well I did that on my installed version. Currently im using the zip version, I guess I need to do it for each instance of MapTool

[turbid quarry]

Yeah. Default memory allocation is 25% of system. I don't suggest setting it higher than half.

[bright ridge]

I have 32GB so should be fine :)

==== MapTool Information ====
MapTool Version: 1.18.6
MapTool Home...: C:\Users\orbde\.maptool-rptools
MapTool Install: C:\Users\orbde\Desktop\MapTool Bugfix\MapTool-1.18.6-win\app
Max mem avail..: 16 GB
Max mem used...: 280 MB
Custom Property: -DMAPTOOL_LOGDIR=C:\Users\orbde\.maptool-rptools\logs
Custom Property: -DMAPTOOL_DATADIR=.maptool-rptools

Okay let me try removing the .maptool-rptools

Oh hello Whitemode 💀 🙈

Okay deleted the folder. the newly created version is 10MB (old one was 1gb, guess these where my assets xD) sadly didnt solve the issue

[turbid quarry]

If you look at your task manager during the issue... is MT pegging the cpu?

or gpu

[bright ridge]

Without Overlay active, when moving a token:

• CPU around 2%
• GPU none

With Overlay active, when moving a token:

• CPU 3-8%
• GPU 2-6(%)

[turbid quarry]

That's not it. Running out of ideas. Could update your mouse driver. I'd also try creating a new "clean" windows profile, do a mt zip install (really no install at all) and try it there. That would be more isolated from your current environment.

[bright ridge]

I’m not really into creating different profiles. I prefer using the same one all the time. Do you have any experience running MapTool in a Windows virtual machine? I mean, I can just try it myself, but maybe it’s common knowledge that MT doesn’t run properly in VMs.

[turbid quarry]

I've never done it.

[bright ridge]

Okay thanks for your time anyway :)

[turbid quarry]

I just wanted to see if a clean user profile would fix the issue... I know it's not really a good solution... you could kill the profile after.

If the VM is easier, worth trying, too.

[bright ridge]

trying this one first. Dont want any remaining files form a deleted user later. Im not trusting windows to fully cleaning it up later xD

Ill update you when its done. Will try that later or tomorrow

Do you have any suggestions about using Win 10 or 11? (im aware of win10 being out of support but win 11 needs more ressources i think)

[turbid quarry]

I'm on 11. No issues.

[willow nimbus]

Believe it had something to do with changing the name of the map that the ActionPads lib token is on. Saving then reloading the campaign seems to have fixed it, though.

[turbid quarry]

I wonder if that FX error in your log is the problem... makes me think there is some kind java conflict. MT is supposed to be isolated, but it's not completely when it comes to the env variables, etc.

Could also try switching to English locality to see if the issue persists. Probably not that but worth checking.

[bright ridge]

Okay, I'm kind of disappointed right now
I set up a fresh Windows 11 64-bit VM with ONLY the newly extracted MapTool 1.18.6 files and the lib token.
I added the lib and a token, and my mouse still jumps...

I also extracted the MapTool files on a freshly reset Windows 10 laptop that has absolutely NOTHING to do with my host machine. I literally got this one week ago and wiped it completely. I redownloaded the files to this laptop directly, startet maptool added lib and a token. Connected a default office mouse, nothing special, no drivers needed.
And BOOM — same issue O_ö

I'm pretty sure, it can not be my setup... 😭

[bright ridge]

I create a new Campaign in 1.15.2 and it works...I do the same in 1.16.0 (or higher) and the mouse starts jumping

Seems I have the same issue with other Frameworks that use Overlays (for example LibMouseOverlays). Did something change regarding overlays in 1.16.0?

[turbid quarry]

You can see the changes in 1.16 here: https://github.com/RPTools/maptool/releases/tag/1.16.3 But... This would have been reported by now if this was something common. Should move this to a support thread and see if you can get some more feedback/testing since this is an overlay issue for you (not an ActionPads issue). Be sure to share a basic campaign where the issue is easily reproduced.

[bright ridge]

Yea question is, how to reproduce...im literally just creating a fresh campaign an thats it. I guess the problem can not be reproduced that easy on another system if its that uncommon... thanks for your help anyways, I will move that to support very soon

[exotic hill]

I've been attempting to duplicate this with a 1.18.5 and 1.18.6 and can't seem to find these symptoms.
Something Az reported re: the mouse https://github.com/RPTools/maptool/issues/5840 Not sure if it's related (probably not).

[rare ether]

You noticed that my report was for macOS?

[exotic hill]

Yeah but you know how things can manifest themselves from seemingly unlikely places :p

[rare ether]

Heh, yep...!

[candid ermine]

I have version 3.1.2 in my campaign, any upgrade issues I should be aware of? Or is it just drag in?

[exotic hill]

Rename your current Lib:ActionPads token, drag the new to the same map, run the transfer macro from the OLD token.

If you're only using doors, that's not requried 🙂

[candid ermine]

Thank you 👍

Uh, potentially slight issue:

=== Checking Lib:ActionPads macros ===
getHelp_Doors: has unmatched parentheses: 1
getHelp_StepOn-Steps: has unmatched parentheses: -2
=== Done! Found 2 of 130 macros to audit! ===

Can I ignore those?

[exotic hill]

Those are false-positive (or should be)

[candid ermine]

Gotcha, I figured you had trawled through the code, but better ask once too many, that the other way 'round.

Oh, got this?

Lib:ActionPads says . . . CUSTOM ERROR onChangeSelection not found on Lib:ActionPads

[exotic hill]

Only if you clicked on something after you renamed the lib:token :p

(and you would have to do the process I described)

[candid ermine]

Yeah, it looks like I got either before, or during the transfer, so it's just me not being too observant 😄

[exotic hill]

It's all good 🙂

[kind ginkgo]

is there a way to make ActionPads linked to an elevation using Melek's Elevation library?

[exotic hill]

It should be treated like any other token with Lib:Elevation. Is there a specific example you can share?
A door actuator on the token layer and door on the object layer, they should be able to be part of whatever layer you defined within Elevation. When selecting ActionPad "clickables" (like an actuator) you'd have to shut off the ActionPads oCS menu (the power toggle on the overlay), it will assume you're trying to open a door or something.

[kind ginkgo]

that was it, disabling the oCS menu allowed me to select the door and set it to the correct elevation. thank you!

[willow nimbus]

@exotic hill Just a heads-up, @exotic hill , first time I've ever tried to create a window and getting a parser error right away. Running 3.11.0 on MT 1.18.6 w/Win 11.

Specific error is:

org.antlr.v4.runtime.misc.ParseCancellationException
Error trace : doorSet@Lib:ActionPads <<< macroLink

So, that ended up being just an issue with the very first line in the macro (broadcast line). Just removed the set of single quotes and it fixed it. But then I got this error when I added actoinpads to GM name and tried to make a window:

doorSet : doorWND,
ERROR:dS_W - Can't find apStates!

In the new Dragon Delves published adventure book, they included a "dungeon" that consists almost exclusively of transparent glass doors. So, since I wasn't sure how to make a "glass door," figured I would try just making them windows.

Also tried using "the doors," but even after clearing the token topology and grabbing only MBL from the map for the door, VBL would get automatically redrawn upon closing the door. >.<

[exotic hill]

I'll try to duplicate the script errors, that shouldn't be happening (although it is almost impossible to test every feature on every release 🙄 )
In the doors section of the config, one of the built in doors, is "glass", You could try that in lieu of a transparent token :).

[exotic hill]

I've tried to duplicate this a few times now. That error comes from macro doorSet_Window and it comes up when you click on this button, and it can't find the apJSON or the apStates within the apJSON on the token. Not sure if you've got this repeatable but if you can, let me know and I'll get it fixed 🙂
(looks like I missed pasting the image but "this button" is the Doors Menu, Window icon (it would have a green power button on it), so long as this object layer token would have been "set" as a door template )

[exotic hill]

Looking for some feedback on the future of ActionPads . . .
I started ActionPads initially to integrate into Lib:Slide so when a token slid over a pad I could trigger something. I kept adding feature after feature, and ended up landing here, where we've got doors, traps, triggers, clickies, audio, proximity, etc.

Other bits to share . . . there is a lot of bloat to the current code, it uses very little JS, and frankly is a lot of spaghetti code I threw together to make things work. This first iteration of ActionPads was built on MapTool 1.11.5, 3ish years ago and there is a lot of code to make things work for those older version (probably not "today" but it used to work on legacy MapTool).

I'm wanting to make things better, take advantage of the experience gained over the past few years, and sort of rebuild ActionPads where I'm only supporting MapTool 1.18.6+, using newer features, integrating faster code via JS, maybe even supporting an "add-on" version (that is not reasonable today). etc. My landing zone would be more of a "Toolbox" than an "ActionPad"

I've not started anything but curious of the feedback. My intent would be to not do any more work on ActionPads outside of bug fixes and start creating Lib:Toolbox and move features from here to there.

[turbid quarry]

My preference would be for you not go to an omni "ToolBox" concept. That sounds very much like the BoT and I think its lack of focus ended up hurting it and became harder to maintain and harder to sell over time. The AP has grown, but it's still fairly focused on pads/actions/object interaction. If you want to bundle some of your other tools into a more general "toolbox" then... sure. But for AP, I'd prefer to see it stay closer to its existing scope. As for refactoring... I understand that lure... but I also understand that rebuilding something to do exactly what it currently does (only x% better!) is a double-edged sword (i.e. with the same amount of effort and time invested, what "new stuff" could you have built?) That's your call.

[exotic hill]

Yeah, I get your point on the focus blur part. The other angle I could do, and was already on the path a little bit . . .
Just maintain AP (fixes, features adds that make sense, etc), and release focus lib tokens I've been tossing around (like onlyDoors). Just make sure I don't create conflicts and allow play-nice amongst them.

[rare ether]

You may want to create some test code to check the performance of MTscript vs JS. Switching to JS is not always a win, especially if there are a lot of transitions back and forth between the two (IME). If there’s a lot to do and it can all (or mostly all) be done in JS, then you’ll get a runtime benefit. Obviously, the tooling behind JS is so much better that development and testing is much quicker there as well, and that may be a good reason all by itself…

[exotic hill]

TBH the main one that comes to mind is lastpath logic, that is my biggest timesink

[patent spindle]

I think that you should stick to things tokens/layers can interact with on the map, Like the Doors, Traps, Roofs, Stairs etc. the only thing I would like to see is something like the "Inspect" tool being able to play sounds. IIRC it currently does not. or make it so that there are sounds that play for all players when clicked. (i like sounds ok?)

[willow nimbus]

@exotic hill For some reason I was thinking this had been addressed already, but I'm using 3.1.1.0 and I'm still showing this using the default theme for the Configure Door window.

[exotic hill]

There isn't a way to put a background on the "input box" dialog 🙁

[willow nimbus]

How difficult would it it be to add color/tint to the icons? Just as an idea...

[exotic hill]

Because they are "tokens", they are sourced from a webp images, I'm not aware of way to do that. I'm working on getting createAsset fixed to help overcome this type issue (I can then convert an svg to an image/token).
Short answer, no, if it were converted off a input to a dialog/frame, yes, but then I lose the captive portal aspect.

[blissful slate]

Hi all! I have a weird behavior which I suspect is some misconfiguration on my side. I have added LibActionPads v.3.11.0 on a MapTool 1.18.6. I have added a step-on portal. The portal works, but when the token emerges from the other side, it's sometimes off by one cell; so, it appears on one cell, but it's actually on the one the right, or the one to the bottom, and so on. I think the exact position depends on the position of the portal relative to the containing cell, but I am not sure. Is there some hint I should follow in setting up the portals?

[exotic hill]

I am aware of a couple of problems that can manifest themselves when using portals.

One is a bug I need to fix where if you travel past the portal, when you land your lastpath continues to execute and can cause some landing zone misplacement. This problem does NOT exist when using Lib:Slide.

The other issue looks like the image attached and sounds like what you described. Lack of contrast doesn't make it easy to see but if you look closely, you'll see the token image with the selection box, does NOT align with the white semi-opaque starting point. They're a square off from each other with the white box starting south of the token image. I believe that is a maptool bug but need to make it repeatable and file a report. No macro should be able to cause that sort of misalignment

[blissful slate]

Not sure if https://github.com/RPTools/maptool/issues/5043 plus some other logic could be the cause of it; I have seen that moving the icons of the portal inside the cell causes different behaviors.

[blissful slate]

Actually, I think it could be related to interactions between moveToken function and Snap to Grid. Here is the behavior I can observe:

• create a map, with a grid size of 100
• put a token on the map
• execute [moveToken(0, 0, 1, getSelected())] this ensures that the token is in position 0,0
• if you grab and try to move the token, it's in the correct position
• execute [moveToken(0, 50, 1, getSelected())]
• now, if you grab and move and move the token, it appears to be in the wrong position (half-way between two cells)

The interesting thing is that the position is still reported as (0, 0), not as (0, 50)

[rare ether]

There was a change within the last few versions to make sure those coordinates were clamped to valid ranges, but maybe a few spots were missed.

IIRC, there’s a complex interaction interaction between the Token (where the x,y is actually stored), the Grid (which dictates the valid upper-left cords), the MTscript functions (which adjust the x,y in the Token without referencing the Grid) and the mouse drag movement (which clamps the coordinates and writes the new values back to the Token, but also must contend with non-snap-to-grid Tokens). It would be pretty easy for some piece of that to be missed. Your bug (repeatable) bug report will make it easier to find and correct, though. Thanks!

[blissful slate]

Cool; do you want me to create an issue for it?

[patent spindle]

Started to get this Message:

Continuing after error running event onTokenMove @ ActionPads, error    Invalid condition in IF(fault= 1 && disTOP=="" && length(custMSG)!=1) roll option.       Statement options (if any): h, if(fault= 1 && disTOP=="" && length(custMSG)!=1),CODE       Statement Body (first 200 characters): { [h, foreach(oneTrap,trapID), if(getTokenImage("",oneTrap) != "asset://"+apIMGpadTrapExtra):setLayer("OBJECT",oneTrap) ; setLayer("OBJECT",oneTrap)] [h, foreach(oneVis,visID): setVisible(1,one.

when using the Disable traps.

Using maptools 1.18.6 and Vers 3.11.0

And Continuing after error running event onTokenMove @ ActionPads, error Must specify a location for the macro "Continuing after error running event onTokenMove @ ActionPads, error    Invalid condition in IF(fault= 1 && disTOP=="" && length(custMSG)!=1) roll option.       Statement options (if any): h, if(fault= 1 && disTOP=="" && length(custMSG)!=1),CODE       Statement Body (first 200 characters): { [h, foreach(oneTrap,trapID), if(getTokenImage("",oneTrap) != "asset://"+apIMGpadTrapExtra):setLayer("OBJECT",oneTrap) ; setLayer("OBJECT",oneTrap)] [h, foreach(oneVis,visID): setVisible(1,one." to be run from. . When using detect>

I have been uising the same code in the past to detect traps.

and this: When just moving

[exotic hill]

Can you share how you've got the trap set up? Is it just a simple trap or are there any trigger, detection, or disarm pads involved?
And with or without the custom trigger check you shared?

[patent spindle]

I am Using traps out of the Box, Nothing set up yet.

[exotic hill]

I need to update the text on the dialog and do more testing but could you test once more with your custom check, but have it end with this [r: if(tRoll<=dc,1,2)] It is not liking 0 and I think that's because I didn't update that dialog after I added <pic>

[patent spindle]

. To Test Everything I Opened a Brand New Session Threw in a Brand New Download. Added Just My 2 Properties, (Peception and PerFocus) and Then i attempted again.
Disable is broken. It throws that error still. Detect Will Not Trigger.

[h: dc = 13][h: tVar = if(hasProperty('Perception','myself'),getProperty('Perception','myself'),0)][h: tVar1 = if(hasProperty('PerFocus','myself'),getProperty('PerFocus','myself'),'')][h: tBon = if(listFind(tVar1,'Seeing')>=0,2,0)][R: tRoll = 3d6+tVar+tBon][H:broadcast(tRoll)][: if(tRoll>=dc,1,2)]

This is the Code I am Using For Macro. (I know that there is an R: and Did that so I could see when it should trigger,and when it exceeds that 13, Nothing

[exotic hill]

Here is a simple example, I'm using Dexterity and Defense as the properties. I believe this is doing what you're looking for.
It should trigger if failed and not trigger if pass. I'm also broadcasting both vars as I wanted to make sure it was working.

There is syntax error in that code snip you shared

[patent spindle]

Hrmmm

Is it supposed to Trigger all the time now?

[exotic hill]

I didn't confirm but the intent would be to set the max trigger at 1, or I believe it will continue to trigger

[patent spindle]

Ok. So what I am currently Testing: Detect Trap: Using your Macro, even if it should fail, it is succeeding.
I Changed the Output to [r: if(tRoll>=dc,1,2)]

LKast time I checked a 9 is less than 13.

even changing it to [r: if(tRoll>=dc,2,1)] Still triggers

[exotic hill]

I can test it more later if you want to share the camp file back. If you're using a detecting pad the combination can be tricky.

[patent spindle]

Yeah I can do the thing

[exotic hill]

I'll be able to test and play with it a little later.

[exotic hill]

The detect pad is meant to run a check if the trap can be detected. It won't disable the trap unless it's set to via a custom macro. The macro on a detect pad is unique and not the same as the trap. You can use a detect pad to disable trap if that's what you're wanting.

I did/do see a bug on the green disable pad, and will make a report on that. There are other ways to disable the trap though

It maybe easier to let me know what you're trying to do and I could help better from there.
If you want a token to detect the trap, and if detected, to disable it, we can get that done.
If you want to detect the trap and make it visible to have a player disable, we can do that do.

[patent spindle]

So, I think I'm not explaining, its 2 seperate issues.
Issue one. The code I am using isnt running detect.
issue 2. When using the disable pad, I get an error.
That was My bad, Should have explained that better.

[exotic hill]

I do see a bug/error on the disable pad. I believe this can be overcome with other options is all.
So I was wanting to focus on the end-state, eg:

• detect, make visible, disarm fail/success
• detect and disarm

You can use a detection pad to disable the trap, to make it visible, or to disarm it all-together, all through using the custom macro options.

[blissful slate]

I could use some help in debugging why libactionpad is (partially) not working on a specific campaign; I was able to use stairs and from/to portals, but I can't make the invisible rooftop work: the token simply doesn't become invisible; I was able to work with the same tokens on a different campaign; I tried to remove and re-add the action pad, but with no success

[exotic hill]

Is this is AP v3.11.0 and MapTool 1.18.6?
I'll run it through a quick test.

[blissful slate]

yes; the fun thing is that it works in campaign, but not in another

[exotic hill]

All "new" or any rptok tokens saved, or maps exported, imported, or any map name changes?

[blissful slate]

there are no imported/exported maps; I can create a new map, if it's useful

[exotic hill]

Let me test real quick and make sure its working as intended 🙂

Oh, is this a toggle (left) or on/off pad (right):

[blissful slate]

yes

left

[exotic hill]

Is it linked to any other tokens? I tested it both methods, and it worked for me. I'll make a quick video if that'd be helpful. A suggestion would be to use the toolbox toolbox and delete the contents of the LibActionPads property. Then attempt to reset it.

[blissful slate]

ok, thanks! I will try in two-three hours (session is starting soon :D)

[exotic hill]

Toggle Pad methods

[blissful slate]

besides, I have seen your videos (and the other one you did on YT on this topic): the thing is that it works on one campaign, perfectly, and doesn't in another 😢