[patch - MapTool b89] VBL Macro Functions width-height fix

Notes on testing the latest builds of MapTool

Moderators: dorpond, trevor, Azhrei

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

[patch - MapTool b89] VBL Macro Functions width-height fix

Post by JamzTheMan »

Sorry Az, I should have made sure you grabbed the latest version of the patch.

Here's the fix built from b89, just a couple lines of code.
Attachments
Patch - VBL Macro Functions width-height fix.txt
(2.02 KiB) Downloaded 173 times
-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
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by Azhrei »

Thanks. I'll grab the patch in the morning and apply it. :)

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by Azhrei »

Okay, so I went to apply it and I have some questions. I don't know if wolph visits here (I think he does) but your code looks like this:

Code: Select all

if (t < 2) { t = 2;}        // Set default thickness to 2 if null or negative
if (t % 2 != 0) {t -= 1;} // Set thickness an even number so we don't split .5 pixels on BasicStroke
if (t > w-2) { t = w-2;}    // Set thickness to width - 2 pixels if thicker
if (t > h-2) { t = h-2;}    // Set thickness to height -2 pixels if thicker
if (w < 4 ) { w = 4;}        // Set width to min of 4, as a 2 pixel thick rectangle as to be at least 4 pixels wide
if (h < 4 ) { h = 4;}        // Set height to min of 4, as a 2 pixel thick rectangle as to be at least 4 pixels high  
Perhaps some of those should throw exceptions about illegal values? If they don't, and the modified values are simply allowed to become the ones that are used, the macro developer could end up with results that he doesn't expect and no way to know why.

But telling them, "the thickness has to be at least two" gives them a way of knowing what's going on behind the scenes so they can correct it on their end...

That would seem to apply to all of those checks. What do you think? Do you want to document all of those constraints or have the code check them and flag them as errors? I'm leaning towards the latter... If you agree, go ahead and make the change and then post a new patch. (Btw, I added new messages to i18n.properties to account for keys in arguments that have the wrong type. I don't know if there are similar ones that cover ranges of values; if there aren't go ahead and create some. :))

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

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by wolph42 »

yup im here and reading it... I see your point and for me its equal, either leave as is or throw an exception error. I did test this new function not knowing about these exceptions and did notice that below 4 it remained 4 which I didn't really see as a big surprise.

Actually, thinking about this... , id rather not have it throwing an exception error as the only reason i can think of when a macro coder uses these extremities is when something is automated. In that case id rather wonder about the fact that a vbl object cannot be smaller then 4x4 pixels then that the entire macro blow up. In the end it will result in the fact that Ill need to write an exception catcher for that particular case. Which on the whole is a bit inefficient. Note that were talking <4x4 pixel objects here! Ill add it to the wiki, together with the 'even only' thickness which is a lot harder to understand unless you now whats going on.

Btw, im not sure if you know why this is build in but in case you don't: the 'thickness' of the line is centered around its coordinates, meaning that a 10x10 object with thickness 2 is actually 11x11 now THAT is something i did not expect and threw me off.

On the whole, id much rather have a proper wiki documentation then a macro unexpectantly throwing errors at me.

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

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by JamzTheMan »

Yea, I agree with wolf, as these are just basic sanity checks. As the odds of a person really needing to draw a 2x2 solid square and got a 4x4 pixel square is so remote.

Plus, it will definitely be easier to explain these exceptions in the wiki. I will make the changes if you really want though.
-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
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by wolph42 »

JamzTheMan wrote:Yea, I agree with wolf, as these are just basic sanity checks. As the odds of a person really needing to draw a 2x2 solid square and got a 4x4 pixel square is so remote.

Plus, it will definitely be easier to explain these exceptions in the wiki. I will make the changes if you really want though.
@jamz: do you still have version b87k around. some peeps still are stuck with b87 and i misplaced that branch version

by the way, what exactly does b89a contain what b89 does not?

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by Azhrei »

wolph42 wrote:On the whole, id much rather have a proper wiki documentation then a macro unexpectantly throwing errors at me.
Okay, thanks for the feedback. I've made these changes. SVN rev 5929.

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

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by wolph42 »

Azhrei wrote:
wolph42 wrote:On the whole, id much rather have a proper wiki documentation then a macro unexpectantly throwing errors at me.
Okay, thanks for the feedback. I've made these changes. SVN rev 5929.
Thanks.

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

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by JamzTheMan »

wolph42 wrote:
JamzTheMan wrote:Yea, I agree with wolf, as these are just basic sanity checks. As the odds of a person really needing to draw a 2x2 solid square and got a 4x4 pixel square is so remote.

Plus, it will definitely be easier to explain these exceptions in the wiki. I will make the changes if you really want though.
@jamz: do you still have version b87k around. some peeps still are stuck with b87 and i misplaced that branch version

by the way, what exactly does b89a contain what b89 does not?

Sure, here's the link:
https://docs.google.com/file/d/0B2c01YG ... sp=sharing

b89a just has the VBL minor patch and my other custom functions sendURL(URL, Text) & requestURL(URL) I use to send/get external data to my macro's. They return raw text. If it's web page for instance, the source code (HTML). I use it to call .php files returning JSON or accessing data from Google Drive (ie pull statblocks from Hero Lab portfolio's)

Once the b90 goes in, this fork will be dead and just for my own use as the the other functions scare people lol
-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
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by wolph42 »

JamzTheMan wrote: Sure, here's the link:
https://docs.google.com/file/d/0B2c01YG ... sp=sharing

b89a just has the VBL minor patch and my other custom functions sendURL(URL, Text) & requestURL(URL) I use to send/get external data to my macro's. They return raw text. If it's web page for instance, the source code (HTML). I use it to call .php files returning JSON or accessing data from Google Drive (ie pull statblocks from Hero Lab portfolio's)

Once the b90 goes in, this fork will be dead and just for my own use as the the other functions scare people lol
thanks and ok. Note that I've rewritten the doors macro using lines instead of squares, so the the vbl doors macros *should* work properly without your fix.

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

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by wolph42 »

[quote="Azhrei"]

Code: Select all

if (t < 2) { t = 2;}        // Set default thickness to 2 if null or negative
if (t % 2 != 0) {t -= 1;} // Set thickness an even number so we don't split .5 pixels on BasicStroke
if (t > w-2) { t = w-2;}    // Set thickness to width - 2 pixels if thicker
if (t > h-2) { t = h-2;}    // Set thickness to height -2 pixels if thicker
if (w < 4 ) { w = 4;}        // Set width to min of 4, as a 2 pixel thick rectangle as to be at least 4 pixels wide
if (h < 4 ) { h = 4;}        // Set height to min of 4, as a 2 pixel thick rectangle as to be at least 4 pixels high   
im working on the wiki: does this apply to ALL shapes or only rectangle and cross? I'm writing the wiki with the latter in mind, so correct me if im wrong.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by jfrazierjr »

wolph42 wrote: Btw, im not sure if you know why this is build in but in case you don't: the 'thickness' of the line is centered around its coordinates, meaning that a 10x10 object with thickness 2 is actually 11x11 now THAT is something i did not expect and threw me off.
Cause you are thinking about this as a "box" or "shape" or whatever in the human terms. When you create a shape in a programming language, all you need are points.

As an exercise, draw two dots on a sheet of paper. Can you imagine a line connecting the two points even though there is none(for most people they can)? A bit harder example would also have a small number of people being able to visualize(without being told to do so) a circle(or technically two circles) with one point being the center point and the second the outer diameter of the circle(and a few really weird people will actually visualize the intersection of BOTH circles.)

Likewise, if you draw a third point, most people can easily visualize a triangle, again, even if no such visible line exists on the paper. So those are the coordinates in "points".

Now... when it comes to the lines themselves that can be drawn to connect all those points, it's actually a STILL a single micro thin line(connecting points even if the line is not visible on the screen) and what the drawing stuff in the code does is set a "Stroke" which "draw's" a line of X thickness CENTERED on this invisible line which connects the center of each of these points. Doing it any other way really breaks down when you try to do it any other way mathematically since you then have a changing definition of what is "inside" and what is "outside" the shape. ie, something like shapeA.Intersects will NOT return true unless it crosses the plane(that micro line) of two(or more) points for shapeB. So, even if you have the ShapeB with a line thickness of 100, the secondary shape has to intrude at least 50 px "into" the border of the shape to be intersecting(ie, it's not good enough that it intersects with the drawn line of the border itself). This same concept holds true when it comes to filling a shape with a specific color, half of the stroke will be outside the shape and half will be inside(and thus cover up the fill color of the shape.)



EDIT: I think the change you requested from Jamz that he implemented to deal with this is the WRONG approach. The reason why is that the approach then changes the coordinates of the shape itself which I think is a very bad precedent to set vs properly explanation of how shapes are drawn(ie, I went into a lot of detail here that is not unnecessary and could be boiled down quite a bit)
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

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

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by wolph42 »

jfrazierjr wrote:
wolph42 wrote: Btw, im not sure if you know why this is build in but in case you don't: the 'thickness' of the line is centered around its coordinates, meaning that a 10x10 object with thickness 2 is actually 11x11 now THAT is something i did not expect and threw me off.
Cause you are thinking about this as a "box" or "shape" or whatever in the human terms. When you create a shape in a programming language, all you need are points.

As an exercise, draw two dots on a sheet of paper. Can you imagine a line connecting the two points even though there is none(for most people they can)? A bit harder example would also have a small number of people being able to visualize(without being told to do so) a circle(or technically two circles) with one point being the center point and the second the outer diameter of the circle(and a few really weird people will actually visualize the intersection of BOTH circles.)

Likewise, if you draw a third point, most people can easily visualize a triangle, again, even if no such visible line exists on the paper. So those are the coordinates in "points".

Now... when it comes to the lines themselves that can be drawn to connect all those points, it's actually a STILL a single micro thin line(connecting points even if the line is not visible on the screen) and what the drawing stuff in the code does is set a "Stroke" which "draw's" a line of X thickness CENTERED on this invisible line which connects the center of each of these points. Doing it any other way really breaks down when you try to do it any other way mathematically since you then have a changing definition of what is "inside" and what is "outside" the shape. ie, something like shapeA.Intersects will NOT return true unless it crosses the plane(that micro line) of two(or more) points for shapeB. So, even if you have the ShapeB with a line thickness of 100, the secondary shape has to intrude at least 50 px "into" the border of the shape to be intersecting(ie, it's not good enough that it intersects with the drawn line of the border itself). This same concept holds true when it comes to filling a shape with a specific color, half of the stroke will be outside the shape and half will be inside(and thus cover up the fill color of the shape.)
On the latter I'll have to disagree. Assuming that the thickness correction is NOT made (so the default case) then a rectangle shape lets say 50x50 thickness 20 fed to eraseVBL() will erase an area of 70x70. So would I have a second VBL shape of say 5x5 outside the 50x50 area but inside the 70x70 area then according to you these two shapes do not intersect (and if only looking at the point, they indeed don't) but due to the line thickness of the 50x50 shape the 5x5 shape is still erased!

On the whole though you are right, this type of correction you should be careful with as to when and why you apply it. However in this particular case: rectangle shape there actually IS an inside (the limited part) and outside (the unlimited part) so its safe to play with the line thickness of this particular shape. A user would overall expect that when she creates a 50x50 pixels shape that its actually 50x50 pixels and not 51x51. With other shapes one should not apply this.

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

Re: [patch - MapTool b89] VBL Macro Functions width-height f

Post by JamzTheMan »

Wolf, that logic is only for rectangle (although min thickness is 2 for all shapes, they can have a odd numbered thickness and the thickness grows from center as normally.

Jz, I think we implemented it the correct way for HOW we implemented rectangles. Now, we could have implemented those differently and if we took the right approach is another discussion.

eg You can define a rectangle 2 ways, specify 2 x,y coords, or specify the upper left x,y coord and then a height and width. We went with the latter. So it made sense that if you specified a width, it should only be that wide.

Generally speaking, getting x,y,h,w is easy using functions only and no math. And generally, we found most cases of needing vbl on a token also required the vbl to stay with its footprint.

That, and if you want to define it the other way, you can use a polygon and 4 points. (which reminds me, I think Wolf asked somewhere if we still had a line shape, we do, polygon with 2 points.)

So bottom line, the rectangle and cross "shapes" are convenience shapes to make life easy with built in logic.
-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


Post Reply

Return to “Testing”