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.
[patch - MapTool] moveOverToken + getMoveCount (merged)
Moderators: dorpond, trevor, Azhrei
Re: [patch] moveOverToken
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: [patch] moveOverToken
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: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.
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
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: [patch] moveOverToken
@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 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.
@aliasMask I pretty much want the same thing. I also want to make it into the contributor list too 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.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: [patch] moveOverToken
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.
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.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: [patch] moveOverToken
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...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.
I'm curious to your other findings!
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: [patch] moveOverToken
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.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.
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
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
- CoveredInFish
- Demigod
- Posts: 3104
- Joined: Mon Jun 29, 2009 10:37 am
- Location: Germany
- Contact:
Re: [patch] moveOverToken
Whow ... isSnapToGrid() is old, like b69 old. Totally missed that. (see announcement)
EDIT: added it to the wiki
EDIT: added it to the wiki
Re: [patch] moveOverToken
Right...
Well at least thanks for adding it to the wiki.
Well at least thanks for adding it to the wiki.
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS