MapTool 1.3 Development Build 55

zEal wrote:

execLink() doesn't appear to really be a trusted function,

I tested it execLink() it is trusted.

zEal wrote:

or the requirement that a function that resides a library token needs to be non-player editable to be trusted has been silently lifted.

I wouldn't so much say the requirement has been silently lifted, more like it never existed

A macro is trusted if any of the following conditions are true.
1) It is executed from a lib:Token that is not owned by a player using [macro():].
2) The GM types something in.
3) Click on a macro that is non player editable.
4) I think (but I cant remember at the moment) click on a campaign macro.

Trusted macros can call non trusted macros and vice-versa, the trusted state will just flip between the two appropriately.

Then there is the "completely trusted" macros. If a macro is completely trusted and run by a player then it gets the special hilite (based on the options in the preferences).
For a macro to be fully trusted it must start from a trusted source (so a non player editable button), and only call trusted macros from that point onwards.

Rumble wrote:

Is it worth the effort to change? I mean, for me, it's irrelevant - I've never had a label or name obscure anything to the point I noticed, so it could be left alone on the "if it ain't broke" basis.

If it's trivial to change, I can't imagine any real objection.

Per Trevor: "insanely simple"

OK, I changed the video in my signature to better show the new vision stuff in B55. Hopefully it isn't as confusing as the last.

I made it so it shows mouse clicks too so you can see that I am clicking the tokens and the background, which was missing in the first video.

Peace out!

Much easier to see !

dorpond wrote:

Rumble wrote:

Is it worth the effort to change? I mean, for me, it's irrelevant - I've never had a label or name obscure anything to the point I noticed, so it could be left alone on the "if it ain't broke" basis.

If it's trivial to change, I can't imagine any real objection.

Per Trevor: "insanely simple"

And the issue with selecting a token in Hard Fog?

I would like it if labels only showed on mouseover.

dorpond, What happens when a player or GM clicks on multiple tokens?

Amaril wrote:

dorpond, What happens when a player or GM clicks on multiple tokens?

You see through the eyes of the selected tokens.

Rumble wrote:

And the issue with selecting a token in Hard Fog?

I am a bit confused. How is the token going to be harder to select in Hard Fog? You will still see the label when you mouseover it and the label simply goes away when you click on the token. You still see the candy cane outline around the token.

I don't see the concern.

Perhaps I will move this to another thread for futher discussion.

The new thread for talking about labels is here:
viewtopic.php?f=3&t=8471

I just opened 1.3b55 on my Mac OS X (leopard), and I'm SO excited about the new integrated menus and being able to use the standard mac shortcuts.

However, one of the nice things with the old java menus was the keyboard shortcuts for certain menu items. For example, to open the last campaing file:
1. type 'alt-F' (File)
2. type 'R' (Recent)
3. type '1' (first in the list, most recent file).

I use that one a lot. With the new Mac OS menus, it's a bit more complicated ( have to use the system keyboard shortcuts, which are sadly, not quite as "short").

The main purpose of this post, however, is to point out a bug. When I typed in the old shortcut (alt-F), the file menu appears, in the wrong position, and an error is generated. I didn't copy all the details, but it should be fairly easy to reproduce.

Thanks for all your hard work everyone!

dorpond wrote:

Now that we select tokens to see as them, does anyone have any objections to changing the way token names and labels work?

Currently:
We hover a token and the labels show
We select a token and the labels show

Proposal:
We hover a token and the labels show
We select a token and the labels don't show
...

I agree with this for the reason that it helps MOVEMENT! Currently, if a token's name hits up against hard fog, then that token can not move. If the name went away when selected, then movement would be better.

Quote:

* Token movement/copying functions now do not force "snap to grid" when using the distance values (cell based movement still snaps to the grid).

Not really a bug, but this patch note reminded me about a modification I have locally that you might want to consider. The feedback from dragging a token that has "Snap to Grid" set is very clunky, as the token "jumps" from cell to cell. Removing the line (774 in PointerTool.java in the current SVN)

Code:

zonePoint = renderer.getZone().getGrid().convert(cellUnderMouse);

from handleDragToken() makes this action much nicer, without loss of information presented to the user, since the cells consisting of the movement path (including the destination) are already highlighted (although if you felt it was really necessary, I suppose it wouldn't hurt to maybe have a very faint "ghost" of the token in its ending cell).

Love the project! Keep up the good work.

-hC

biodude wrote:

I just opened 1.3b55 on my Mac OS X (leopard), and I'm SO excited about the new integrated menus and being able to use the standard mac shortcuts.

However, one of the nice things with the old java menus was the keyboard shortcuts for certain menu items. For example, to open the last campaing file:
1. type 'alt-F' (File)
2. type 'R' (Recent)
3. type '1' (first in the list, most recent file).

I use that one a lot. With the new Mac OS menus, it's a bit more complicated ( have to use the system keyboard shortcuts, which are sadly, not quite as "short").

The main purpose of this post, however, is to point out a bug. When I typed in the old shortcut (alt-F), the file menu appears, in the wrong position, and an error is generated. I didn't copy all the details, but it should be fairly easy to reproduce.

Thanks for all your hard work everyone!

I've created a bug post and I'm looking it.

hyperactiveChipmunk wrote:

Not really a bug, but this patch note reminded me about a modification I have locally that you might want to consider. The feedback from dragging a token that has "Snap to Grid" set is very clunky, as the token "jumps" from cell to cell. Removing the line (774 in PointerTool.java in the current SVN)

Code:

zonePoint = renderer.getZone().getGrid().convert(cellUnderMouse);

from handleDragToken() makes this action much nicer, without loss of information presented to the user, since the cells consisting of the movement path (including the destination) are already highlighted (although if you felt it was really necessary, I suppose it wouldn't hurt to maybe have a very faint "ghost" of the token in its ending cell).

Love the project! Keep up the good work.

-hC

Yes, what hC said. If if really is that easy, I support it now, else maybe something to think about for 1.4?

RPTools.net

MapTool 1.3 Development Build 55

Who is online

Top

Top

Top

Top