FEATURE: Goto+, getViewPortXYZ, setZoomlevel

[wolph42]

Basically an extension of Wiki: goto() it currently uses token or x and y as parameters, it would be nice to have this x,y,z or token,z. Where z (optional!) sets the zoom level of view.

Additionally it would be nice to retrieve the current viewport x,y and z. E.g. getViewPortXYZ()

[Jagged]

Perhaps it would be better to have a separate setZoom() function? I could see it being difficult to determine the difference between Goto(X,Y) and Goto(Token,z), especially as we have this issue where sometimes a tokenId gets treated as a number.

PS: In all my years of playing with Maptool I never noticed the Zoom indicator in the bottom corner, or that you could edit it! ::)

[RPTroll]

PS: In all my years of playing with Maptool I never noticed the Zoom indicator in the bottom corner, or that you could edit it! ::)

Wow. Nor had I. Perhaps making that a little more obvious is in order.

Also, the tooltip gets in the way.

[aliasmask]

Heh, I know about the zoom indicator but didn't realize you could edit it either. I did notice it was editable in mote. Not sure if I ever needed to edit it though.

[RPTroll]

BTW - I agree with making set Zoom its own function.

Updated task spreadsheet 15.6/.7
https://docs.google.com/spreadsheets/d/ ... sp=sharing

getViewPort() returns x,y,zoom% and setZoom(zoom %) would fulfill the requirements.

[JamzTheMan]

Mmm. I've been editing that zoom box forever lol. Guess it came with messing with VBL and light sources during coding and wanting that exact 50% or 10% or something.

Would be a perfect candidate for the "Did you know?" tip popup. We also need a "Did you know?" tip popup.

Putting these functions in should be easy. I need to combine all the "macro functions" into a consolidated group and work on them at once unless someone else takes them first. Need. More. Coders...

[RPTroll]

Would be a perfect candidate for the "Did you know?" tip popup. We also need a "Did you know?" tip popup.

Task 34
https://docs.google.com/spreadsheets/d/ ... sp=sharing


Macros are in task 15 - macro functions (8 subtasks/functions) and 16 - macro events (2 subtasks)

Code: Select all

15	Macro Functions
15.1	Improved Find Token - scans all maps for tokens
15.2	Fixed token id - Asset ID changes between load. 
15.3	setMapVisible() and renameMap() macro fuctions - might be easy. See feature request topic for details.
15.4	Fix/change getTokenFacing/setTokenFacing (open) - see forum topic for details
15.5	setTokenheight/width (open) - easy one for new coders. see forum topic for details.
15.6	Improved goto() Functionality - duplicate with 15.7
15.7	Get/Set viewport() - goto xy/set zoom level. Might be a separate set/get zoom function.
15.8	Add tokenId to get/set GmNotes
16	Macro Events
16.1	onTokenFacing() event (open) - see forum topic for details
16.2	ontokenDrop onTokenDelete Events

[Jagged]

I've created a Pull request for a setZoom(x) and getZoom() function.

Hope I've done the pull request correctly. GitHub noob!

[JamzTheMan]

woot!

[wolph42]

woot!

+1

[Jagged]

Hope I've done the pull request correctly. GitHub noob!

As I get more familiar with GitHub, I come to the conclusion that I didn't do it right. Or at least, not in a way that could be described as "best practice".

I get the feeling that I should have created a local branch, done all my coding on that local branch, pushed that branch up to my fork, then done the pull request from that branch, and then leave the merge of that branch up to Craig. Rather than what I did, which was to merge the code in my fork and ask Craig to pull my fork/master.

Does that sound right?

[JamzTheMan]

That's my take. I started creating "Branches" to group my code into. But it's just a "logical" grouping.

Regardless, Craig should only have seen "what changed" regardless. Where it seems "advantageous" is if you have 2 "features" or "bug fixes" going and you finish one of them. It's easier to then select that "branch" and checkin/submit pull request.

You should now resync back to the master "Upstream" so you will pull my changes, and vice versa for me...

[Jagged]

I think the main advantage of doing everything on a branch and then letting Craig merge it to Master, is the clearer revision history. Plus it probably makes things a little clearer for Craig.

[wolph42]

I've created a Pull request for a setZoom(x) and getZoom() function.

Hope I've done the pull request correctly. GitHub noob!

Just tested these and I noticed that setZoom(getZoom()) renders an error. This should not happen. IRC Jamz had something similar a while back with a new function he created so he might shed some light on it.

[Jagged]

I will look into it.