Question: Is there a way to lock token scale by script?

[lule]

Hallo to all of you out there,

is there any way to lock token scale by lua-script or in xml-files?

Best regards,

Lule

[Moon Wizard]

No, there is no way to do that currently.

Can you give me an example of what you are working on, so I can understand your need?

Thanks,
JPG

[lule]

Thanks for this question. The first post was a little bit to vague as I see now.

I am working on an auto scale function of tokens to the grid. It is already working. The only problem until now is when you zoom into a map and the token scale lock is not activated via menu, the tokens are smaller then they should be. When the token scale lock is activated every thing is working fine.

Therefore I am looking for a function to set this lock via lua-script (so that the ruleset users do not have to do this manually) or as standard by xml. I prefer the lua-script variant because then to lock could be set or released when the corresponding option is changed in the option menu.

[Zeus]

I like the sound of that.

It would be nice to be able to create modules with maps with grid predefined/applied and accompanying tokens scaled and locked appropriately. This would complement the token pre-layout functionality added to 4E.

I suggest we add it to the wishlist as an API request.

[Moon Wizard]

I can add a function to set the lock scale.

However, I think that the challenge is that the map images and token images can be any size. You can't make assumptions in a ruleset about standard token sizes or map scales, unless you are providing all the maps and tokens. For example, I've seen tokens at 32x32, 50x50 and 70x70 for "Medium" creatures. Also, maps can vary drastically in their scaling (20, 25, 30, 50, ... pixels per grid).

I've been tossing around the idea in the back of my head to allow a campaign wide setting for token scaling. (i.e. Creatures added to the map are auto-scaled to their game statistics size. Tokens associated to Medium creatures would auto-scale to one grid square, Large to 4 grid squares, etc.) However, I haven't wrapped my mind completely how that would work as a general feature for multiple rulesets. Also, it requires the grid to be in place already, and other design decisions. (auto scale after grid set?, etc.)

Regards,
JPG

[Moon Wizard]

Just added in v2.9.3 beta.

setTokenScale() will unlock the token scale.

setTokenScale(<floating point number>) will lock the token scale to the value specified. It's a pixel to pixel scale denoting the relative scale between the map and the tokens. To give you a point of reference, the number in my test maps from my Rise of the Runelords campaign (Part 4, Caves) using the built-in medium letter tokens was ~4.4.

Regards,
JPG

[unerwünscht]

Just to make sure we (and by we I mostly mean I) understand. Lets say we have medium tokens that are 256x256 and the map resolution is at 50x50 per square. We would setTokenScale(50.50.) ... is that correct?

[Zeus]

I've been tossing around the idea in the back of my head to allow a campaign wide setting for token scaling. (i.e. Creatures added to the map are auto-scaled to their game statistics size. Tokens associated to Medium creatures would auto-scale to one grid square, Large to 4 grid squares, etc.) However, I haven't wrapped my mind completely how that would work as a general feature for multiple rulesets. Also, it requires the grid to be in place already, and other design decisions. (auto scale after grid set?, etc.)

Regards,
JPG

Yeah, I was thinking its easier to define from a module perspective as you can control the image and token sizes directly. Across a Ruleset?Campaign becomes tricker if you don't want to kybosh flexibility.

What about some options in the Options Palette with a couple of slider controls to set the base grid size and token size for all images but allow image windows (using the toolbar) to locally override campaign settings where necessary.

[Moon Wizard]

unerwünscht, I think the scale would be 256/50 = ~5.1 in that case.

DrZ, that's pretty much along the lines of what I was thinking. Campaign-wide setting for defaults, with overrides for individual images. I'm thinking that it's going to need to be override per layer as well when we get there (i.e. foliage/building scale different than mini scale).

Cheers,
JPG

[unerwünscht]

So in other words we should try to make a community effort to push for making everything in a scale of 4 pixels. in example instead of using 50 pixels as the default use 64. Thus the typical 256x256 tokens you find all over the net could easily drop down to 128x128 and 64x64, or even 32x32 for those that like smaller tokens.

[Trenloe]

I think the setTokenScale functionality will do away with the need of GMs resizing their maps to fit a certain scale - so this is great news! :)

I think a lot of people out there don't even use any specific scale, as it changes from map to map and most of us hard worked GMs don't resize their maps to fit a specific scale. I use a lot of maps extracted from PDFs - and I just go with whatever scale the individual map extracts as is; and it is usually different for each map in the same PDF. All I do is manually resize the tokens on each map - which is a bit of a pain, especially with a lot of tokens.

Because of this I think the functionality that lule appears to be working on would be great - helped by the new setTokenScale API. Make sure all of your tokens are in the same scale (64, or 128, or whatever pixels = medium, etc.) and then use an auto-scale feature that calculates what the size of the token should be when it is placed on a map that could have a wide range of XX pixels = 5 feet/1 square. If my tokens were always 64 pixels per "Square" and I draw a square on a map that is 32 pixels, then the setTokenScale value would be 64/32 = 2. If the next map I drew a grid on was 67 pixels to a square then setTokenScale = 64/67 = 0.96, etc., etc., for each map that has a differing scale.

So, from the above - as a GM just make sure your tokens are all in the same scale and then the setTokenScale calculation can be used to fit them to the ever changing grid size from map to map. Fantastic! :D

[Moon Wizard]

Now, if I could only auto-detect grids, but that's a more complicated problem. ;)

JPG

[Zeus]

unerwünscht, I think the scale would be 256/50 = ~5.1 in that case.

DrZ, that's pretty much along the lines of what I was thinking. Campaign-wide setting for defaults, with overrides for individual images. I'm thinking that it's going to need to be override per layer as well when we get there (i.e. foliage/building scale different than mini scale).

Cheers,
JPG

Ha Ha I forgot about Layers, I'll see if I can take a look at the code when I get to images in 5E. This would be a nice feature addition to Enhanced Images.

[lule]

Well a lot of response here.

There is not a Problem with different sizes of tokens in the functions I wrote. More or less this was one of reasons to write such a function. The other was, that I liked the thought to add a Token and it fits automatically to the grid.

@JPG: What is the standard scale of the new setTokenScale API? I have to set this scale because I a doing the scaling of tokens on the image of that token. So it would be enough for me to have a API like setTokenScaleLock(true|false). And this could also be changed via click on the radial menu like it is today.

For all the people that are interested in the code (Please take in mind that i am not a software engineer and still learning in xml and lua. Therefore for some things there can be a more elegant solution):



function onInit()
if User.isHost() then
[...]
Token.onWheel = onTokenWheel;
end
Token.onAdd = onAdd;
onInitOptionsPruefung();
end

function onGridStateChanged(type)
[...]
onGridStateChangedOptionsPruefung();
end

function onInitOptionsPruefung()
if OptionsManager.isOption("TANP", "on") then
local gittergroesse = getGridSize();
if gittergroesse ~= 0 then
local alletoken = getTokens();
for k, v in pairs(alletoken) do
if v.getScale() == 1 then
setSkalierung(v, gittergroesse);
else
v.setScale(v.getScale());
end
end
end
end
end

function onGridStateChangedOptionsPruefung()
if OptionsManager.isOption("TANP", "on") then
local gittergroesse = getGridSize();
if gittergroesse ~= 0 then
local alletoken = getTokens();
for k, v in pairs(alletoken) do
setSkalierung(v, gittergroesse);
v.setPosition(onTokenSnap(v, v.getPosition()));
end
end
end
end

function onAdd(token)
if self.getDatabaseNode() == token.getContainerNode() then
[...]
if OptionsManager.isOption("TANP", "on") then
local gittergroesse = getGridSize();
if gittergroesse ~= 0 then
setSkalierung(token, gittergroesse);
end
end
end
end

function onTokenWheel(ziel, stufen)
if self.getDatabaseNode() == ziel.getContainerNode() then
if OptionsManager.isOption("TANP", "on") then
local orientierung = ziel.getOrientation();

if Input.isControlPressed() then
local skalierung = ziel.getScale()+0.05*stufen;
if skalierung == 1 then
skalierung = 1.00001; --Lule: necessary to distinguish between a new token which is still not scaled and a token which was manuell scaled to the factor 1.
end
ziel.setScale(skalierung);
ziel.setOrientation(orientierung+stufen);
end

if Input.isAltPressed() then
local gittergroesse = getGridSize();
if gittergroesse ~= 0 then
setSkalierung(ziel, gittergroesse);
ziel.setOrientation(orientierung+stufen);
end
end
ziel.setPosition(onTokenSnap(ziel, ziel.getPosition()));
end
end
end

function setSkalierung(token, gittergroesse)
local tokengroesse = {};
local skalierung;
tokengroesse["x"], tokengroesse["y"] = token.getImageSize();
if tokengroesse["x"] >= tokengroesse["y"] then
skalierung = math.floor(gittergroesse/tokengroesse["x"]*1000)/1000;
else
skalierung = math.floor(gittergroesse/tokengroesse["y"]*1000)/1000;
end
token.setScale(skalierung);
end


This is the code in the "imagewindow_image.lua". [...] Indicates that there is also other code in the function with other functionality.

The code is already working. The only "problem" is, that you have to set the token scale lock when zooming into a map. Some of the users of our ruleset are used to do the token scaling in a special way, based on the possibilities without this functions. The zoom into a map until they reached a scale which fits to their tokens and then set the grid. With the new functionality they are very small. Well they could also first set the grid and then place the tokens. Know they should lock the token scale via radial menu. That would work fine but users are users and they are click lazy.

Regards

Lule

[Moon Wizard]

The scale is completely dependent on the map to token relative scale. It would be 1.0 if you just dropped tokens on a brand new image without resizing or zooming.

Regards,
JPG

[lule]

Thanks JPG.

@ all how want to try the code above:
I discovered a new problem with the code above. I didn't consider to zoom level in a map. Maybe that is connected with my other problem - I am nearly sure. I have to think about it and then try to solve the problem.

[lule]

Two more questions:

1. The "function to set the lock scale" is that a function which set the value of <scalelock> in the db.xml <image><category ...><id-xxxxx><image type="image"><tokens><scalelock> ?

2. Could we also get a get-function for this value?

[Moon Wizard]

1. Yes, the setTokenScale() function sets the value you see in the scalelock tag of the database save files.

2. Just uploaded a new v2.9.3 beta version with getTokenScale.

JPG

[lule]

Again Thanks a lot JPG. I just saw the email about your post and wanted to say: no hurry ("2. Should be straightforward, but swamped right now, give me a couple days.). But your are that fast....