Some requests old and new...

[Irrlicht]

1) Functions to get an image's original width and height.
Say I put handouts in tokens and use the Bag of Trick's Show Handout to see them. At present, I have to set an arbitrary value for the image's size, and thus, unless I already know the picture's original size, I may input a too large value and the resulting image will be all pixelated. So, I'd need functions to get the picture's original size and use it as the default value of the input.

2) One option I keep seeing as more useful the more macros I build, is to have the possibility to hide/show macro groups in each panel the same way one can do it with directories in the resource library. That way, groups containing a large number of macros would occupy only a single line when hidden, making the panel (particularly the campaign panel) clean and easier to scroll when looking for a given macro. To this could also be added an option to create subgroups; a trivial example: a Skill group containing the Social Skills, Lore Skills and Physical Skills subgroups, each of which can be hidden or showed.
Also, a way to sort groups by a custom order (rather than the automatic alphabetical order) wouldn't be a bad thing.

3) This one I asked six years ago and Azhrei said it would someday come, in future 1.4 builds, but as a reminder:
As some, or perhaps many may know since distant time, in the countries that commonly use the metric system, all the units of measure of D&D and Pathfinder have been converted from miles to kilometers, from feet to meters and so on.
Now, since the default unit for D&D/PF's tactical movement is 1 square = 5 feet = 1.5 meters, the problem in MapTool is that it doesn't accept 1.5 (or 1,5, for that matter) as the default unit per cell, since it doesn't accept any decimal value at all. Being able to use decimal values would save a lot of pain, especially with players who can't get into ft. to meter quick conversion.

4) Another old one:
When a circular or conic sight is added, it's range is set and immutable, right? I mean, if I have "Blindsight 20 ft: circle distance=20 r20" and assign it to a medium-sized token, it will have a range of 20 ft; but if I assign it to a colossal token, the effective range will only be 5 ft (despite the fact that the real range, from the token's center, is 20 ft).
So I have to add something like "Blindsight 20 ft (Colossal creatures): circle distance=35 r35" (or use offset, for a conic vision). This means I must have various sight entries for the same sight for different-size tokens.
I think it'd be good to have an option (say adding a letter "s" to the code of the sight), so that if I assign the Blindsight 20 ft to a token, I will only need to have the sight "Blindsight 20 ft: circle distance=20 r20 s" in my campaign properties, and it'll be 20 ft for a medium-size one, 20 effective ft (while 35 real ft) for a colossal-size one, and other appropriate proportions for every other size (free-size included, possibly).
This would keep the panel much more clean (currently I have to add tons of sight lines).

[taustinoc]

2) One option I keep seeing as more useful the more macros I build, is to have the possibility to hide/show macro groups in each panel the same way one can do it with directories in the resource library.

I gotta say, there's a certain charm to the idea of putting the macros into a treeview control, rather than the current buttons in frames.

[JamzTheMan]

Some good thoughts.

1) I assume you want to get the original width/height for an image Portrait/Handout? We do have Wiki: getTokenWidth() which does what you need but the picture would have to be a token using freesize. Couldn't/shouldn't the handout work in %'s though? As in "show this handout at 100%"? Seems it would be better but in any case not a hard request to get done...

2) Interesting idea. Not sure on about the difficulty. Probably a little painful to do this in swing. We could implement a "tree" but then you would have only 1 macro per line. Maybe we can put a "jPanel" of buttons on a "treeNode"...hmmm Along those lines, how about a "Search" bucket at the top like we have for Assets? Filter the whole panel as you type? I know some Lib tokens that I hate scrolling to find that one subDoSomeWork macro...also, I guess we have the macro's in "Groups", maybe a +/- button on that panel to hide/collapse it may work...

3) Hmm, not sure what the ramifications of changing that value from an integer to a float would be, we may have to look at the math for footprints and bounding and all that everywhere to make sure we don't have rounding errors if we convert back to int. It is an "arbitrary" value though, it can mean what ever you want. I personally would just put in 15 as that would then mean 15 decimeters right? So 345 would be 34.5 meters. Simpler that 55 feet is um...math...something in meters. Macros would have to account for it as well but they can display whatever. I assume mostly this is more just for the drawing/pathing numbers shown when moving tokens. Maybe a compromise would be adding an option to convert/show the distance in the GUI (when dragging/measure tool). SO the campaign can stay at 5ft and show 35ft for someplayers who choose English system and 10.6m for those who select Metric (or otherway around). We could even get fancy and auto-scale it, so 2640ft show as .5 mile or 1350 meters shows 1.35km... Add in a handy macro for conversion as well?

4) That interesting, you know, I never really realized that or looked at it. As I'm a Pathfinder player playing GiantSlayer and know the Light/FoW code...this may get some attention this week... I'll have to go look up the rules (I assume it's distance measured from any side). We'll have to make sure that LowLight doesn't double the distance added as well. I guess that is why all my lights are like "Torch: 20.5 feet"... doh. Anyhoo, I'll take a look. I may only be able to do "Footprint", ie, it has to have a "Size". If it's Native/Free size it would still be from the center as I wouldn't have #grids to calculate from...

[Irrlicht]

Some good thoughts.

1) I assume you want to get the original width/height for an image Portrait/Handout? We do have Wiki: getTokenWidth() which does what you need but the picture would have to be a token using freesize. Couldn't/shouldn't the handout work in %'s though? As in "show this handout at 100%"? Seems it would be better but in any case not a hard request to get done...

That's exactly what generated the request. The only way to get the original size is to have the handout as the token image and freesize. In a macro, you can temporarily swap the image and the handout, but you can't set a token as free size, so you always get merely the width of the sized token.
And if you have to keep it freesize, it's as good as merely dropping the image on map as freesize to begin with, without using a macro.
Having it in % would be nice too, and would suffice for me, but I must say I can imagine a very big picture (whose actual size an user would be unaware of) may be retrieved as too big for a screen, if set at 100%, while knowing the actual size would allow one to get it as big as their screen allows for a full display.

2) Interesting idea. Not sure on about the difficulty. Probably a little painful to do this in swing. We could implement a "tree" but then you would have only 1 macro per line. Maybe we can put a "jPanel" of buttons on a "treeNode"...hmmm Along those lines, how about a "Search" bucket at the top like we have for Assets? Filter the whole panel as you type? I know some Lib tokens that I hate scrolling to find that one subDoSomeWork macro...also, I guess we have the macro's in "Groups", maybe a +/- button on that panel to hide/collapse it may work...

The search would sure help, though the best thing for me would still be the full tree with groups and subgroups (where I could keep open just the groups I need during online play and close all the other utilities for campaign preparations, for example; or even copy some macros in multiple groups so I can have different sets open with a number of equal macros and a number of different ones depending on the moment's needs).

3) Hmm, not sure what the ramifications of changing that value from an integer to a float would be, we may have to look at the math for footprints and bounding and all that everywhere to make sure we don't have rounding errors if we convert back to int. It is an "arbitrary" value though, it can mean what ever you want. I personally would just put in 15 as that would then mean 15 decimeters right? So 345 would be 34.5 meters. Simpler that 55 feet is um...math...something in meters. Macros would have to account for it as well but they can display whatever. I assume mostly this is more just for the drawing/pathing numbers shown when moving tokens. Maybe a compromise would be adding an option to convert/show the distance in the GUI (when dragging/measure tool). SO the campaign can stay at 5ft and show 35ft for someplayers who choose English system and 10.6m for those who select Metric (or otherway around). We could even get fancy and auto-scale it, so 2640ft show as .5 mile or 1350 meters shows 1.35km... Add in a handy macro for conversion as well?

Yep, as far as I'm concerned, for this one I only "need" the value displayed on the GUI. All calculations in macros can be easily converted, but some sort of template that shows converted values on the GUI would do the trick.

4) That interesting, you know, I never really realized that or looked at it. As I'm a Pathfinder player playing GiantSlayer and know the Light/FoW code...this may get some attention this week... I'll have to go look up the rules (I assume it's distance measured from any side). We'll have to make sure that LowLight doesn't double the distance added as well. I guess that is why all my lights are like "Torch: 20.5 feet"... doh. Anyhoo, I'll take a look. I may only be able to do "Footprint", ie, it has to have a "Size". If it's Native/Free size it would still be from the center as I wouldn't have #grids to calculate from...

Yep, that came up in the old thread where I originally posted that request as well; in Pathfinder, a creature is considered as if moving the whole time inside its space, so its eyes are virtually on any point along the border of its space.
At present, the list of sights in my campaign is huge due to this reduction in range for tokens of bigger size than Medium.

[JamzTheMan]

Yep, that came up in the old thread where I originally posted that request as well; in Pathfinder, a creature is considered as if moving the whole time inside its space, so its eyes are virtually on any point along the border of its space.
At present, the list of sights in my campaign is huge due to this reduction in range for tokens of bigger size than Medium.

How about light sources? Is there an official ruling on those? If a Huge creature is carrying a torch, is he swinging around within his space? I would guess yes but... (Have to at least fix darkvision, so will be in that code anyway, just curious if there is an official ruling. It'll be an option to use or not use...)

[Irrlicht]

As far as I know, it's not specified (surely not in the CRB's Additional Rules chapter), but if a creature is (virtually) looking in every direction (which is why at first I used conic vision, but then switched to full circles), it supposedly moves its light source wherever it is looking, so the origin of the light would still be in every point along the borders of the occupied spaces, extending as far as the light's normal range in every direction even if the creature occupies N spaces.
Basically, take a candle, which only sheds light in a 5 ft. space; imagine it is wielded by a Colossal creature; if it only sheds light from the center of the token, it won't ever shed light for that creature unless it moves over anything it would like to look at, but I think if you ask anyone, they'll agree the creature will simply bring the candle at the edge of its space, where it is looking, so it can benefit from the 5 ft. light. So, since it is considered looking in every direction, the light should be all around it.

[JamzTheMan]

Light can be tricky. A huge creature holding a candle (unless it's a huge candle) illuminates 5 feet no matter what. If I apply it to the footprint (15x15) so he can see 5ft beyond his footprint, that same candle now illuminates 25x25 squares. Now a token from one side can also see the back side of the huge creature. This is exaggerated even more with lowlight.

I see two ways around this:

1. When a light source is added, it also adds a "Personal lightsource" (think darkvision) equal to the tokens FootPrint + Light Source radius.

2. Add a "scalesWithToken" option, which basically assumes a "torch" held by a huge creature is a "huge torch" and so the light is larger and increased by the size of the tokens footprint.

I'm thinking #2 is the better option? Now the question is, where do we put this option? If we put it on light sources you would need two copies of each light source (because a Huge creature could still pick up a small torch). There could be similiar cases for sight types i suppose. So I think two options on the token are better?

o "Scale Light with Size"
o "Scale Vision with Size"

Both checked by default, with included macros to set/get values.

Thoughts?

[Irrlicht]

First of all, very nice ideas.

The best would be a combination of both, of course.

And for the second option, it would also be better to have the option both in Light Properties and tokens, if we want to consider all possible cases. A Huge creature may be holding a "huge-sized" candle and a normal bull's eye lantern (conic light, not just a circular light that would cover the candle's light in each direction), so the first would need to scale while the second wouldn't. In this case you'd have the token set to "lights not scaled" but would apply the scaled version of the candle to it.
Now, provided this example is something no one will ever see or need in game, if there's any trouble with adding both options and I had to choose one, I'd personally prefer to have more flexibility, even if it clogs the properties a bit, so I'd choose having it in Light Properties (they'd never get more clogged than how much they are now anyway, for me, since I need a different line for every light for every size larger than Medium, while with the scaling option they'd be just two lines per light*).

The first option (adding the personal lightsource) would still be a very nice addition because, while yes, a creature will usually wield a size-appropriate light source, it could still pick up a smaller one, which (without this option) would then be either ineffective/less effective or, if scaling is on, it will cause the problem you mentioned where another creature would see behind the light-wielding one.

I think if you could implement all of them (1, 2a and 2b), it'll be very hard to find any new issue with lights ever again.
That said, if I have to vote only one, I'm for the scaling option in Light properties.

*And auras... with the fact that Dragons alone, not counting other monsters with non-standard ranges) come in every size and have a wildly wide variety of aura ranges (and also some of them have two auras with different ranges), my auras list is huge, as of now. Scaling would cut it greatly.

[Jagged]

My personal thoughts are that 1 & 3 are definitely things we should look at and should be added to our work list.

I would rather address 2 by adding code libraries so code no longer needs to be attached to buttons.

4 is interesting but seems somewhat game specific to me, plus there are work arounds.

[JamzTheMan]

@Jagged, I agree with the same. Although since I play pathfinder, and we're doing GiantSlayer... #4 is getting personal attention

@Irrlicht Good point on the auras. I suppose a "Huge" ghoul would emit stink 20 foot from it's footprint? It will have the same options which ever way I go. I'll probably start with the check boxes and go from there.

BTW, do you have any links to the ruling? I can only seem to find general Light ranges and LOS. I can't seem to find where they talk about sight and auras (although it could be subtle wording I'm missing).

[Irrlicht]

Uhm, Ghouls don't have stench (though I too always remember them as having it, dunno why, I looked up the 3.5 SRD and they didn't have it even back then, so it's not a relic memory from 3.5 era)... anyway...
What do you mean by footprint?
Anyway, the aura should extend from the edges of the creature's space(s), not its center. It isn't actually specified anywhere in the rules, but apart from the fact that I think it's the natural way everyone uses auras (unless they start considering stuff like we're doing for MapTool), there are examples that make it clear it can't extend just from the center of the creature. One is the Red Dragon's Fire Aura. The Red Dragon gets it for the first time when it reaches Huge size, and the radius is 5 ft. If it started from its center, it would be practically non-existent.
Also, the wording on that aura, gives the perspective: "Fire Aura (Su) An adult red dragon is surrounded by an aura of intense heat. All creatures within 5 feet take 1d6 points of fire damage at the beginning of the dragon's turn."
So, creatures within N ft. from a creature with an aura are inside the aura (N is obviously the range of the aura, and distance from a creature is undoubtedly counted from the closest space occupied by the creature, not its center).

About sight/light I'm afraid there's nothing beyond the CRB, where the rules are focused on Medium/Small-sized characters, but... same as for auras, unless someone has made VTT-like considerations*, I think everyone (devs included) will agree that the range starts from the edges of the creature.

*AndI doubt that includes many people also because light/sight comes heavily into play for us who use MapTool, but (apart from people who use VTTs without light/sight), most people play at a table, and light rules ery rarely come into play, because it's a pain to do it at a table without software.

[Jagged]

@Jagged, I agree with the same. Although since I play pathfinder, and we're doing GiantSlayer... #4 is getting personal attention

Would it be possible to add a "size" parameter to the vision and light system?

[JamzTheMan]

@Jagged, I agree with the same. Although since I play pathfinder, and we're doing GiantSlayer... #4 is getting personal attention

Would it be possible to add a "size" parameter to the vision and light system?

Anything is possible.

So, do you mean just adding a re-"size" keyword that tells the light to resize based on it's token OR a "size=Huge" key/value pair? I was planning on going the former and not the later. (or a size=auto/off or some such probably so the light can be forced to not resize with creature to override the resize option on the token....)


BTW: I was thinking about "1) Functions to get an image's original width and height."
Instead of getHandoutWidth, and getPortraitWidth, etc, I'm planning on a getNativeImageWidth(assetID) instead. We can already get assets for all the images so just pass it to this function to return what we need. Then you can use it with table images as well with only 2 new functions added...

[Jagged]

I was thinking of "size" returning the token size whatever size it has been set. So that one sight definition could be applied to any token.

On your image resize options, I like the "native" option.