[patch - MapTool] moveOverToken + getMoveCount (merged)

Notes on testing the latest builds of MapTool

Moderators: dorpond, trevor, Azhrei

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [patch] moveOverToken

Post by aliasmask »

If there were snap/unsnap macros, I would use them. Especially considering the getLastPath bug dealing with unsnapped tokens. Also, the snap and unsnapped states are key in knowing the true position of a token. I've only been causally reading what you guys are up to, but knowing the size of an image would be really useful too.

But this is all extras to me. I would much prefer MT be finalized before making more tweaks that could extend the finalization. Then future patches will be for a custom build and possible integrated in to the 1.4 rewrite.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: [patch] moveOverToken

Post by JamzTheMan »

aliasmask wrote:If there were snap/unsnap macros, I would use them. Especially considering the getLastPath bug dealing with unsnapped tokens. Also, the snap and unsnapped states are key in knowing the true position of a token. I've only been causally reading what you guys are up to, but knowing the size of an image would be really useful too.

But this is all extras to me. I would much prefer MT be finalized before making more tweaks that could extend the finalization. Then future patches will be for a custom build and possible integrated in to the 1.4 rewrite.
AM, just an FYI, I have added several of those functions while developing my VBL functions as they where needed/extremely useful in determining where to put said VBL. I currently have:

o isSnapToGrid([id]), returns 0 or 1 (although if you are looking for a setSnapToGrip, I don't have that but this at least helps in macro logic)
o getTokenWidth([id]) & getTokenHeight([id]), returns the width/height in pixels for a given token.
o getTokenX & getTokenY modified, passing a 2 as a parameter now returns the pixel x,y position for a given token regardless of which layer it is on or if snapToGrid is turned on.

They are packaged in my custom JAR and I'll submit a patch soon(tm). Whether it gets included or not I know not but I'll supply a custom JAR with these patches until then.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [patch] moveOverToken

Post by Lee »

@wolph42 Well, there you go, Jamz got your back wolph :)

@aliasMask I pretty much want the same thing. I also want to make it into the contributor list too :lol: When thinking about finalizing MT, two things always pop into mind (loosely quoted):

a. dorpond said the last MT would be the public face of MT for the lengthy period until 1.4 comes out and that we should do what we can to make everything as smooth as possible. My interpretation of "smooth" is to address what Azhrei said (also loosely quoted) in the Feature Requests section; that MT so far hasn't taken into consideration accessibility conveniences for the end-user. Which is the reason why I'm tackling it, because I subscribe to the philosophy that positive experiences with a tool can be greatly increased with a nice flowing interface.

b. I think that the official dev team should concentrate mainly on 1.4, but I do think that the ideas pitched in the Feature requests section give them things to think about for the next generation MT. So, I believe there is value for them for other people to add to the feature list if: 1. it doesn't break MT, 2. it shows the theory in action, 3. it can be done in a timely manner going toward finalization.

I actually wanted to pitch MT 1.3 to be finalied on b90. Whatever outstanding bugs that we can help with, we will. Whatever new features introduced, should be thoroughly tested and fixed in b89. If there is one thing I'd like to think tank with others on, it'd be VBL and FoW. For that, it'd be invaluable to have the dev team provide insights as much as possible.

As for the bug you reported earlier, I'll start working on it tomorrow morning. You should amend the error scenario a bit. The "key" token always reports correct coordinates whereas "follower" tokens do not. Let's continue the discussion on the original post.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [patch] moveOverToken

Post by Lee »

IDK how to break this to you wolph, but there already is a function to get the snapped and unsnapped state. isSnapToGrid has been available for a while now it seems. I just tested it on b86 after finding it in the code while working on the onMultipleTokensMove bug.

It either needs impersonation or passing the token name or id to it. Apart from this, there are a quite a # of other undocumented functions and slash commands; some seem to not be working like the /cc or /color macro which changes chat font color (this one I fixed). I'll log of these finds as I go through the code, fixing what I can.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [patch] moveOverToken

Post by wolph42 »

Lee wrote:IDK how to break this to you wolph, but there already is a function to get the snapped and unsnapped state. isSnapToGrid has been available for a while now it seems. I just tested it on b86 after finding it in the code while working on the onMultipleTokensMove bug.

It either needs impersonation or passing the token name or id to it. Apart from this, there are a quite a # of other undocumented functions and slash commands; some seem to not be working like the /cc or /color macro which changes chat font color (this one I fixed). I'll log of these finds as I go through the code, fixing what I can.
Right... Well not knowing of them doesn't really help now does it. Anyway good to hear there are 2 now... I think you mainly need to break this to Jamz though as he just build a redundant function...

I'm curious to your other findings!

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: [patch] moveOverToken

Post by JamzTheMan »

Lee wrote:IDK how to break this to you wolph, but there already is a function to get the snapped and unsnapped state. isSnapToGrid has been available for a while now it seems. I just tested it on b86 after finding it in the code while working on the onMultipleTokensMove bug.

It either needs impersonation or passing the token name or id to it. Apart from this, there are a quite a # of other undocumented functions and slash commands; some seem to not be working like the /cc or /color macro which changes chat font color (this one I fixed). I'll log of these finds as I go through the code, fixing what I can.
Eh? Wait, what? Hey, what do you know! Cool then, I can remove it from my class. Guess I should have did a better code search, but as Wolf said, functions don't do any good if they are not documented. Wonder why it never made it to the wiki? Funny that I pretty much ended up naming it the same and code looked the same to, but it was only a few lines of code and 5 mins work so no biggy.

Just don't tell me there were VBL functions already :)
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: [patch] moveOverToken

Post by CoveredInFish »

Whow ... isSnapToGrid() is old, like b69 old. Totally missed that. (see announcement)

EDIT: added it to the wiki


Post Reply

Return to “Testing”