RPTools.net

I don't have time to play with it now, but I wonder if you have multiple frames that use the same interrupt if only one is ran(the last one) or if both are ran. If everyone starts writing code using <link rel='onChangeSelection' type='macro' href='macroLink'> I'm just wondering if the calls are stacked or if they are overwritten.

I'm guessing it's okay, but who knows.

I've made this thread Sticky, at least until someone updates the wiki with information about these three. Hopefully that would be in the wiki section on how to build frames and dialogs... (Anyone who does make those updates, please post back here and I'll un-sticky the thread. Thanks.)

aliasmask wrote:I don't have time to play with it now, but I wonder if you have multiple frames that use the same interrupt if only one is ran(the last one) or if both are ran. If everyone starts writing code using <link rel='onChangeSelection' type='macro' href='macroLink'> I'm just wondering if the calls are stacked or if they are overwritten.

I would assume that if the frames do not have the same name, than any currently open frame, with the onChangeSelection event keyed, will executed the macro linked to onChangeSelection.

So if you have 3 frames open - Frame 1, Frame 2, and Frame 3 - with that option, then all three will fire their onChangeSelection macro.

However, if you use the same name for the frames, then it will just replace whatever's in there. Thus, it's better with this to title the character sheet "Character Sheet", rather than a unique name. It also only works while the frame/dialog is open, of course.

Edit: confirmed - if you have two open frames (with different titles, obviously) with onChangeSelection actions, and you change selection, both frames change. So, anything that fires on onChangeSelection will fire.


There are a lot of things you can do with this, but I think people will also figure out what they should do with it, and what doesn't work so well. Automatically changing character sheets/references on selection is a superb use, for instance.

This is awesome!

I've made a quick macro box for my use that changes on selection This is going to be extremely useful in running my campaign. It'll make things a lot easier and more effective.

And one for the Players to use that changes on impersonation They won't use it so much unless controlling an NPC or one of the players forgets his laptop and they have to share. But the future considerations are pretty cool for when they get followers.

Now, is there a way that if I change a token's properties it's automatically updated on their macro?

P.S. Thanks for the colour scheme, mine was pretty bland.

Skester

If you just change the properties manually or with a macro that doesn't refresh the frame, then no, the frame won't be updated.

One thing I added to the sheet posted above is a macro hidden in the portrait that if clicked will refresh the frame. Also, you can click on the selected token again to refresh.

But if you're changing stats with macros, just have the macro call the sheet at completion. In my framework, I don't force players to have the sheet open, so the only macros that do this are those that are called from the sheet itself. I basically have, for instance, an Ability Setup macro and an Ability Setup from Sheet macro. The latter just calls the former, then refreshes the sheet. (Using the code I submitted, or a variation, remember to pass the name of the sheet to preserve the page).

I saw the hidden macro in the portrait. I actually changed it to a macro which uses goto() and bringtofront() to find the token quickly.

I was thinking about using the refresh button, but I know that some of my guys would forget to use it. And the macros that I use for cure light wounds are generated by the token doing the curing, but effect the target token. So then It'd have to figure out who was being cured and refresh the macro on their system.... beyond me. I'm just borrowing code off of people and finding out new things every week.

Skester

The other day, I used this to modify my based-on-Daelkyr's Dragon Age framework, so that I didn't have to keep multiple character sheets open for my bad guys, and my players could just click their token to get to the sheet (my players were handling two characters each).

It's really excellent - make my life so much easier.

This is very kool stuff guys.
I've been a player in Plo's group for some time now and it's been great. His character sheet is really slick, and don't believe him when he says 2 days from never there are very few thing that are missing. Also Skester I woulda emailed this to you sooner if I'd had thought about it lol, sorry mate. However that said sometimes I find that despite the screen space saved and the quickness and utter koolness of it all, in my campaign for the group I've removed the functionality from my character sheets etc. in favour of unique frame names as I find the players hardly use it (we rarely have more than one character so refreshing through the macros is enough) and my personal preferance as a GM is to have a different sheet for each NPC/Monster in an encounter and unique naming allows for quicker identification of this - but I might just be weird xD

But yeah, still a very very awesome function and I've als found that the selected option on a macrolink is a God-send as it's allowed me to make up a frame with controls for each of the different inventory locations in my version of Pyromancer's UIS which is just so quick and easy.

Mal

Mal,

For me this is like remote keyless entry. Once you have it you can't go back. It's not needed, but it's soooo nice. Am I showing my age? At least I didn't compare it to a TV remote (though I do remember a time when we didn't have them too)

Having just one window that changes for the token you select gives you so much freedom as a DM to have the info and abilities quickly at your fingertips. You still have mouseover to get info off of other tokens, but with a properly designed macro you should be able to launch whatever you need off of it.

I'll send over my next set of updates for you to look at in probably a week or so. See how many I can get through on my list first.

Skester

yeah, Like I said, it's probably just me. Don't ask why - I think if I didn't have so many persistent NPCs and most of the info I needed for encounters were the mosters then I'd probably use the onChangeSelection. I understand what you're saying though, this is a very awesome piece of code that really should be used more, I'm just sayng that for me personally that usage isn't my preferance
I'll keep it in next time I get an updated framework file from Plo and see how it affects things i suppose (and it will reduce the amount of code I have to change to update lol xD). Your next build looks like it could be really interesting, can't wait

Mal

Wow. This is nice. I will be playing around with it.

Speaking as someone who has been using this for a long time, it recently came to my attention that this can effect performance depending on what's being done.

The issue revolves around the fact that onChangeSelection triggers any time a token is clicked on, even if it's the same token that was previously selected and never de-selected. So clicking on your token once to select it will draw a character sheet, but once you click on it again to drag it around it has to draw it AGAIN. If it takes 1-2 seconds to draw your sheet then you're actually dealing with 2-4 to be able to move a token. If your players move a square or two and stop to think they're going to add another 1-2 seconds back on once they start moving again.

travist627 worked up a solution revolving around storing and passing the last accessed token in macro.args and then only loading the frame if the token was different. This looks to have vastly improve performance when it comes to moving tokens. You can see our work here http://forums.rptools.net/viewtopic.php ... start=1350

I was recently going to look into doing exactly this. Thanks for the link.

(Also, did I read Rumble right up above when he suggests a click runs onSelectionChange four times? If so, and if that could be fixed, your 1-2 second delay might be cut to .25-.5. Still annoying, but far less so.)

This may be something that is better fixed in the MT source code. If the token being clicked on to select it is already selected, then don't fire the event at all.

At first I was concerned that this mght be a bad thing (if the user wanted the charsheet to update in case properties had been changed by another client, for example) but it's just as easy to click away from the token and then click back, and that single extra click is probably a worthwhile UI "penalty" in order to gain the performance advantage in other cases.

Azhrei wrote:This may be something that is better fixed in the MT source code. If the token being clicked on to select it is already selected, then don't fire the event at all.

That would be the optimal solution.

I'm not sure how many times it fires. Rumble was reporting 4 or so, but when I tell the frame macro to output to all when it runs, I only get a tokening reporting in chat once. However, it WILL report whenever I click on it. By putting in a count loop to redraw the sheet multiple times I can push the delay up high enough it's timeable and there is a definite time delay if the same token is selected again to move.

Yet when I put in the code to prevent it I'll get 3-4 reports from the token in chat that something is running, yet the frame macro is not redrawing since there is no delay on re-selection. So I'm not entirely sure where or what the macro is that's forcing multiple outputs to chat, it strikes me as a fluke somewhere in my code and a much better solution would be to write some macro's solely to test it.