Experimental APIs for FGU

[Moon Wizard]

As part of v4.0.7; I've actually embedded quite a few new APIs that I'm testing out to see how useful they are; as well as to make sure that the API calls are in the right formats that are needed as well as to sound out issues with the new APIs. These APIs may change in the near term based on feedback, and I'll post here if I do. So, if you plan to look at using these, make sure to subscribe to this thread.

And here they are:

imagecontrol
getTokensWithinDistance(token/{x=#,y=#}, #) -> (table of tokens)
getDistanceBetween(token/{x=#,y=#}, token/{x=#,y=#}) -> (number/nil)

File (new global package)
addCampaignAssetFile(path, type) -> (string/nil)
getCampaignFolder() -> (string)
getDataFolder() -> (string)
openCampaignFolder([subpath])
openDataFolder([subpath])
openTextFile(path) -> (string/nil)
saveTextFile(path, string)

Token
getTokensWithinDistance(token, #) -> (table of tokens)
getDistanceBetween(token, token) -> (number/nil)

Utility (new global package)
decodeXML(string) -> (table)
encodeXML(table, [bool]) -> (string)

Regards,
JPG

[Vam]

Thanks Moon Wizard! I just gave Token.getDistanceBetween() a shot, and I love how it returns usable values in ruleset units instead of the pixels or whatever they were that getPosition() returns. I was trying to figure out how to convert for ChatBat (https://www.fantasygrounds.com/forums/showthread.php?65432-ChatBat-(Chat-comBat-Extension)). I'll be using that for sure.

[Frodie]

Oh wow, so will this import Hero Labs Online?

[SilentRuin]

I can see these being pretty useful. Not planning on making any more extensions at the moment, but you never know what will trigger one as my own campaign progresses. I can see these being handy enough (plus any future ones - maybe with lighting?) that I will need to track this thread in case I want to incorporate new stuff into my existing extensions or make a new one.

[celestian]

As part of v4.0.7; I've actually embedded quite a few new APIs that I'm testing out to see how useful they are; as well as to make sure that the API calls are in the right formats that are needed as well as to sound out issues with the new APIs. These APIs may change in the near term based on feedback, and I'll post here if I do. So, if you plan to look at using these, make sure to subscribe to this thread.

And here they are:

imagecontrol
getTokensWithinDistance(token/{x=#,y=#}, #) -> (table of tokens)
getDistanceBetween(token/{x=#,y=#}, token/{x=#,y=#}) -> (number/nil)

File (new global package)
addCampaignAssetFile(path, type) -> (string/nil)
getCampaignFolder() -> (string)
getDataFolder() -> (string)
openCampaignFolder([subpath])
openDataFolder([subpath])
openTextFile(path) -> (string/nil)
saveTextFile(path, string)

Token
getTokensWithinDistance(token, #) -> (table of tokens)
getDistanceBetween(token, token) -> (number/nil)

Utility (new global package)
decodeXML(string) -> (table)
encodeXML(table) -> (string)

Regards,
JPG

OMG, how did I miss this post. I will test various bits of this. The distance/between and decode/encodeXML will be useful (aura in the 2E ruleset and the XML handoffs for OOB messages).

[celestian]

Utility (new global package)
decodeXML(string) -> (table)
encodeXML(table) -> (string)

Regards,
JPG

I ran a few tests to figure out how to use these, "Utility" seems to be valid? Utility.encodeXML()

The test was this:



msgOOB.jsonDice = JSON.encode(aDice or "");

Debug.console("manager_action_damage.lua","notifyApplyDamage","aDice---->",aDice);
Debug.console("manager_action_damage.lua","notifyApplyDamage","msgOOB.jsonDice---->",msgOOB.jsonDice);

if UtilityManagerADND.isFGU() then
Debug.console("manager_action_damage.lua","notifyApplyDamage","encodeXML()",Utility.encodeXML(aDice));
end




[1/27/2021 2:07:39 PM] s'manager_action_damage.lua' | s'notifyApplyDamage' | s'aDice---->' | { #1 = { s'value' = #1, s'type' = s'd3', s'result' = #1 }, s'expr' = s'd3' }
[1/27/2021 2:07:39 PM] s'manager_action_damage.lua' | s'notifyApplyDamage' | s'msgOOB.jsonDice---->' | s'{"1":{"value":1, "type":"d3", "result":1}, "expr":"d3"}'
[1/27/2021 2:07:39 PM] s'manager_action_damage.lua' | s'notifyApplyDamage' | s'encodeXML()' | s'<?xml version="1.0" encoding="utf-8"?>'


I expected the msgOOB.jsonDice to be similar to the encodeXML() value (JSON.encode/decode is my internal methods I use in 2E) but... as you can see it's not. Perhaps im not using it as intended?

[Moon Wizard]

What is in aDice?

EDIT: Nevermind, I see it in your code output

JPG

[Moon Wizard]

The encode/decode XML is very specifically to encode/decode between XML and Lua tables. I do not expect it to match to JSON encoding/decoding.

JPG

[celestian]

The encode/decode XML is very specifically to encode/decode between XML and Lua tables. I do not expect it to match to JSON encoding/decoding.

JPG

Woops, yeah thats my fault for seeing encodeXML and translating that to "encodeJSON" because... yeah I'd LOVE that also. My mistake.

Would it be possible to add a JSON encode? I'm fairly certain that Unity has it native, would be nice to have.

[Moon Wizard]

Just to clarify, there is a very specific format that the encoding supports for Lua tables in order to allow bi-directional translation of data. It's not meant (at least at this point) to be some sort of general purpose convert "any" Lua table to XML. It could be something to enhance later.

Within the table, all XML child tags are referred to by number indicating their child sibling order pointing to a table that must include a "name" variable. This is the XML "tag". You can also specify an "attr" table for the tag, as well a numerical children. This is to deal with the fact that XML child tags can have the same name; mirrors the format used for controls to access XML tags; and matches up with a common Lua library used for XML processing.

Here's an example:

XML


<?xml version="1.0" encoding="utf-8"?>
<root version="4" dataversion="20201016" release="4.1">
<character>
<name type="string">Bobby</name>
<token type="token">portrait_id-00002_token</token>
<coins>
<slot1>
<amount type="number">0</amount>
</slot1>
<slot2>
<amount type="number">0</amount>
</slot2>
<slot3>
<amount type="number">0</amount>
</slot3>
<slot4>
<amount type="number">0</amount>
</slot4>
<slot5>
<amount type="number">0</amount>
</slot5>
<slot6>
<amount type="number">0</amount>
</slot6>
</coins>
</character>
</root>


Decoded Table


{
1 = {
name = "root",
attr = { release = "4.1", dataversion = "20201016", version = "4"}
1 = {
name = "character",
1 = {
name = "name",
attr = { type = "string" },
1 = "Bobby",
},
2 = {
name = "token",
attr = { type = "token" },
1 = "portrait_id-00002_token",
},
3 = {
name = "coins",
1 = {
name = "slot1",
1 = { name = "amount", attr = { type = "number" }, 1 = "0", },
},
2 = {
name = "slot2",
1 = { name = "amount", attr = { type = "number" }, 1 = "0", },
},
3 = {
name = "slot3",
1 = { name = "amount", attr = { type = "number" }, 1 = "0", },
},
4 = {
name = "slot4",
1 = { name = "amount", attr = { type = "number" }, 1 = "0", },
},
5 = {
name = "slot5",
1 = { name = "amount", attr = { type = "number" }, 1 = "0", },
},
6 = {
name = "slot6",
1 = { name = "amount", attr = { type = "number" }, 1 = "0", },
},
},
},
},
}


Regards,
JPG

[Moon Wizard]

Unity does not have a native JSON encoder/decoder. It has a very special purpose JSON->screen object decoder, which requires a prefab that exactly matches the JSON to work. So, it can't be used for general purpose arbitrary JSON encoding/decoding. I actually looked at this very specifically for you.

My plan is to eventually add encode/decode JSON. However, it requires adding a complete library just to support a single set of APIs; so I'd like to sound out the rest first.

Regards,
JPG

[celestian]

imagecontrol
getTokensWithinDistance(token/{x=#,y=#}, #) -> (table of tokens)
getDistanceBetween(token/{x=#,y=#}, token/{x=#,y=#}) -> (number/nil)

Token
getTokensWithinDistance(token, #) -> (table of tokens)
getDistanceBetween(token, token) -> (number/nil)


I did some testing with these and noticed that the values are not "between tokens" but "center of token -> center of other token". Between (IMO) would be from sourceToken edge to targetToken edge.

The target mechanic (which is fine) on tokens does the same so you can visually see what I mean.

https://i.imgur.com/jDhemKe.png

I thought the functions would return 5 ft, not 10 ft. The Token.getDistanceBetween function output 10, not 5, in the above situation.

This is the function I use to get the "actual" distance between tokens.

The TLDR is you have to subtract the "tokensize" space out of the calculation.... IF you're wanting to get what I would call "between".

Regardless I can use this function to replace some of my code for the basic calculations and adjust for tokensize on my own.



--[[

This will get the distance BETWEEN these 2 tokens.

getTokenDistance(source,target);

]]
function getTokenDistanceBetween(tokenSource,tokenTarget)
local bValidDistance = true;
local nDistanceBetween = 0;
local nGridSize = 0;
local yOffset = 0;
local xOffset = 0;

local imageSource = ImageManager.getImageControl(tokenSource);
local imageTarget = ImageManager.getImageControl(tokenTarget);

if tokenSource ~= tokenTarget and imageSource and imageTarget and
imageSource == imageTarget and imageSource.hasGrid() then
local xSource,ySource = tokenSource.getPosition();
local xTarget,yTarget = tokenTarget.getPosition();

nGridSize = imageSource.getGridSize();
local nMapUnitSize = 10;


if UtilityManager.isClientFGU() then
nMapUnitSize = imageSource.getDistanceBaseUnits() or 10;
else
nMapUnitSize = imageSource.getUnitControlValue() or 10;
end

xOffset,yOffset = imageSource.getGridOffset();

local xGridSource = (xSource + xOffset) / nGridSize;
local yGridSource = (ySource + yOffset) / nGridSize;

local xGridTarget = (xTarget + xOffset) / nGridSize;
local yGridTarget = (yTarget + yOffset) / nGridSize;

local nX = math.abs(xGridTarget - xGridSource);
local nY = math.abs(yGridTarget - yGridSource);

local nDistance = math.sqrt((nX * nX) + (nY * nY));

local nodeSourceCT = CombatManager.getCTFromToken(tokenSource);
local nSourceSpace = DB.getValue(nodeSourceCT,"space",nMapUnitSize)/nMapUnitSize;
local nSourceSize = ((nSourceSpace)*nMapUnitSize)/(2*nSourceSpace);

local nodeTargetCT = CombatManager.getCTFromToken(tokenTarget);
local nTargetSpace = DB.getValue(nodeTargetCT,"space",nMapUnitSize)/nMapUnitSize;
local nTargetSize = ((nTargetSpace)*nMapUnitSize)/(2*nTargetSpace);

nDistanceBetween = math.floor((nMapUnitSize * nDistance) - (nSourceSize + nTargetSize));
else
-- target and source not in same image
-- or source == target
-- or no grid on map
bValidDistance = false;
end

-- Debug.console("manager_token_adnd.lua","getTokenDistanceBetween","nDistanceBetween",nDistanceBetween)
-- local nAPIDistanceBetween = Token.getDistanceBetween(tokenSource, tokenTarget);
-- Debug.console("manager_token_adnd.lua","getTokenDistanceBetween","nAPIDistanceBetween",nAPIDistanceBetween)

return nDistanceBetween,bValidDistance;
end




Unity does not have a native JSON encoder/decoder. It has a very special purpose JSON->screen object decoder, which requires a prefab that exactly matches the JSON to work. So, it can't be used for general purpose arbitrary JSON encoding/decoding. I actually looked at this very specifically for you.

My plan is to eventually add encode/decode JSON. However, it requires adding a complete library just to support a single set of APIs; so I'd like to sound out the rest first.


Understood, thanks for the insight and consideration for this.

[celestian]

Just to clarify, there is a very specific format that the encoding supports for Lua tables in order to allow bi-directional translation of data. It's not meant (at least at this point) to be some sort of general purpose convert "any" Lua table to XML. It could be something to enhance later.

Within the table, all XML child tags are referred to by number indicating their child sibling order pointing to a table that must include a "name" variable. This is the XML "tag". You can also specify an "attr" table for the tag, as well a numerical children. This is to deal with the fact that XML child tags can have the same name; mirrors the format used for controls to access XML tags; and matches up with a common Lua library used for XML processing.

Here's an example:


That would make importing XML really easy. Nice!

[Moon Wizard]

I'll need to look at your token distance feedback in more detail while reviewing the code. I see what you're saying; and I think I agree that the "distance" values returned and tokens within distance should factor in token grid size. I wouldn't incorporate the APIs yet until I get a chance to make that determination; since I'll probably change the way they work to match. I definitely appreciate you taking a look.

Regards,
JPG

[celestian]

I'll need to look at your token distance feedback in more detail while reviewing the code. I see what you're saying; and I think I agree that the "distance" values returned and tokens within distance should factor in token grid size. I wouldn't incorporate the APIs yet until I get a chance to make that determination; since I'll probably change the way they work to match. I definitely appreciate you taking a look.

Regards,
JPG

Understood, I'll comment out the usage for now, thanks for the new features!

[Dakadin]

Thanks for adding the distance calculations between tokens. I haven't had a chance to test it yet but I saw the same issues as celestian when I was implementing range calculations in the RMC ruleset when comparing to the targeting distance lines. The issue is much easier to see when you put larger opponents next to smaller ones and ones that are the same size. Basically range increases especially on the diagonal measurements.

[mattekure]

For the distance functions, I wonder if there is a difference in interpretation based on the ruleset. Looking at the image Celestian provided, 10 ft. would be the expected distance in a 5e game. Scaling through the 5e standard NPC sizes, Medium, Large, Huge, and using the 5 foot grid, the expected ranges would look like this

https://imgur.com/JYJ0lYq.jpg

[Dakadin]

The issue that I encountered was those distances weren't consistent with different sized tokens because like celestian I noticed that FG is measuring to a distance into the squares you are showing. It became an issue because even if it was adjacent to the larger token at the corners the distance would be greater than it was from 2 medium size tokens.

[MadBeardMan]

Just to throw my oar in, the distance between tokens, I'd like the idea we can have the distance with/without tokens sizes, for example I could use the 10ft as shown to know a character is within the blast range of a grenade in Traveller as that feels fairer than being 5 fit away, and just to throw a difference in, Traveller tends to use hexes, so I think it's fair middle of base -> middle of base.

Cheers,
MBM

[LordEntrails]

I would think center to center and then a token size attribute would be more flexible. It would then let the calculation be left up to the ruleset. Don't forget, their is the whole diagonal distance calulation things that is ruleset and rule option specific.

[celestian]

Distance between tokens is a pretty clear definition. The space between the 2 tokens.

The 10 ft line is the distance between the tokens.

https://i.imgur.com/sVLzgSo.png

Distance from center of token to center of another token would, I expect, be called something else.

That's the line of 20 ft.

[deer_buster]

My humble interpretation of this...

getTokensWithinDistance(token, #) -> (table of tokens) -> this should get all tokens that have some portion of their space included within the radius from the center of the provided token
getDistanceBetween(token, token) -> (number/nil) -> I see this as the number of units distance from the center of one token to the center of the closest square of another, or vice-versa. If I am in a 5' square with a 5' reach, then the token next to me is considered within 5' of me, regardless of its size

[deer_buster]

Distance between tokens is a pretty clear definition. The space between the 2 tokens.

The 10 ft line is the distance between the tokens.

https://i.imgur.com/sVLzgSo.png

Distance from center of token to center of another token would, I expect, be called something else.

That's the line of 20 ft.

It would require a 15' reach to hit that dragon

[Moon Wizard]

The distances will be calculated as center of grid square to center of grid square distances. Since large creatures take up more than one grid square, the closest is used for distance calculations. (In the example picture above, this would be 15.) These APIS should work the same; and I will be updating them as soon as I get time.

Regards,
JPG

[deer_buster]

The distances will be calculated as center of grid square to center of grid square distances. Since large creatures take up more than one grid square, the closest is used for distance calculations. (In the example picture above, this would be 15.) These APIS should work the same; and I will be updating them as soon as I get time.

Regards,
JPG

Just curious, will it understand and handle the variant for diagonal measurement in 5e if it is set to Variant?

[Moon Wizard]

It will be whatever the values are for the image, which are based on the ruleset settings. It should be identical to what is displayed on the distance arrows, once fixed.

Regards,
JPG

[celestian]

The distances will be calculated as center of grid square to center of grid square distances. Since large creatures take up more than one grid square, the closest is used for distance calculations. (In the example picture above, this would be 15.) These APIS should work the same; and I will be updating them as soon as I get time.

Regards,
JPG

That's unfortunate and means I'll have to keep my own version of distance adjustments for size of tokens.

It seems odd to me to measure from the center of a creature and not it's edge when referring to distance to a thing. When I measure distance between walls, I measure the outside edge of one wall to the outside edge of the other.

Without an edge to edge measurement auras will not work properly when they are suppose to have say a 10 ft radius. If you have a very large creature, the aura wouldn't even get out of it's own space.

[deer_buster]

That's unfortunate and means I'll have to keep my own version of distance adjustments for size of tokens.

It seems odd to me to measure from the center of a creature and not it's edge when referring to distance to a thing. When I measure distance between walls, I measure the outside edge of one wall to the outside edge of the other.

Without an edge to edge measurement auras will not work properly when they are suppose to have say a 10 ft radius. If you have a very large creature, the aura wouldn't even get out of it's own space.

See I read that totally different. If you have a large creature with a 10ft aura, it starts from the center of the closest square of the icon to the target being measured. Adjacent square would be 5 ft, and next square out would be 10 ft. This way you would look to the center of the square being "covered" If the effect doesn't extend that far, I would rule that it doesn't affect

[damned]

If you have a very large creature, the aura wouldn't even get out of it's own space.

Just curious... how would you expect that particular case to work?

[celestian]

See I read that totally different. If you have a large creature with a 10ft aura, it starts from the center of the closest square of the icon to the target being measured. Adjacent square would be 5 ft, and next square out would be 10 ft. This way you would look to the center of the square being "covered" If the effect doesn't extend that far, I would rule that it doesn't affect

Still, it's not the distance between the tokens, it's the distance between inner token space, not between. Infact, with the inability of FGU to measure half-square slots (FGC did) it would probably make matters more difficult to calculate.


Just curious... how would you expect that particular case to work?

It was a point to better define distance measurements. Not so much how auras work. In this particular case if the dragon was huge, took up larger than normal space and had a 5ft aura it wouldn't extend beyond his own token if you measured it from center of token.

[deer_buster]

Still, it's not the distance between the tokens, it's the distance between inner token space, not between. Infact, with the inability of FGU to measure half-square slots (FGC did) it would probably make matters more difficult to calculate.

I'm just not sure the reason why you need the distance between tokens....I'm sure you have one, but if, as JPG said, it is providing the distance to the centers of the nearest squares of each token, then it should be relatively easy to calculate (e.g. subtract 5 feet, or the base unit of measure distance). A creature adjacent to you would have a distance between the tokens of 0, but would be considered within 5 feet reach of each other, and I think that is what it is returning.

[MeAndUnique]

Unity does not have a native JSON encoder/decoder. It has a very special purpose JSON->screen object decoder, which requires a prefab that exactly matches the JSON to work. So, it can't be used for general purpose arbitrary JSON encoding/decoding. I actually looked at this very specifically for you.

My plan is to eventually add encode/decode JSON. However, it requires adding a complete library just to support a single set of APIs; so I'd like to sound out the rest first.

Regards,
JPG

I'm sure you're already aware of it, just in case though System.Text.Json is lightweight, both in requirements and in performance.

[Moon Wizard]

Unfortunately, that library is not available yet in the .Net version that Unity engine supports. (which is .Net v4.x option in the Unity build interface)

Regards,
JPG

[Moon Wizard]

Just poked into the Unity forums to investigate this; because I would prefer to use native .Net classes than to import yet another library (like Newtonsoft). Apparently, the Unity team has been slowly working towards .Net 5 / .Net Standard 2.1 over the last 6-9 months; but does not offer support yet.

Regards,
JPG

[MeAndUnique]

Oh, I had assumed FG wasn't on the old framework version given that FGU is relatively new. Out of pure curiosity, what's holding FG back from using .Net Standard 2.0?

[Moon Wizard]

The Unity cross-platform engine that we built FGU on uses their own implementation of .Net; and they currently support .Net 2 / .Net v4.x

Regards,
JPG

[MeAndUnique]

Unity also supports .Net Standard 2.0 (as of 2018 iirc), which is easily overlooked given the .Net Framework 2.0 support :) In the few Unity projects that I've migrated forward from Framework to Standard I haven't encountered more than maybe a day worth of work in converting, but I have heard the rare tale of woe.

[celestian]

I'm just not sure the reason why you need the distance between tokens....

Because ALL actions assume distance to the token/npc, not it's "center". When someone quoted "you'd need a reach of 15 ft" I ignored it because I don't play 5e all that often so don't know it's mechanics all that well but when there is 10 foot between targets and you need 15 ft reach to hit, that makes 0 sense to me. All I need is the reach to touch the target, which in the example I gave was 10 ft.

As I showed earlier I already have code to do this w/o the system mentioned here and I'll continue to use it but if we're talking about API code that will more than likely improve performance since the API calls are not encumbered by LUA then... it would be nice for it to function as would be expected. As far as I know there are only 2 of us that actually do this sorta thing as is and the 2E ruleset is one of them. When auras become a thing in FGU natively this will become more apparent.

[MeAndUnique]

In fact, as I think about it, the only troubles I've encountered personally are when resuscitating Unity projects that hadn't been maintained for a couple years. Had to spend a fair amount of time migrating away from obsoleted Unity API calls, but I can't recall anything from the Framework to Standard conversion itself breaking.

[LordEntrails]

I don't remember the rules for AD&D, but since 3.0, two tokens that are adjacent to each other are considered to be five feet apart, and at melee distance for medium/normal reach creatures.

[Moon Wizard]

According to the rules of every tactical system I've seen, tokens next to each other have a distance of 1 grid unit between each other.

For auras, since the distance is from center of nearest grid unit encompassed by source token to similar center of grid unit on target token, then the aura effect should still apply. (i.e. If aura is 10 ft., then the target must be "within" 10 ft; not adjacent to 10 ft. That means that any token with 2 grid units (assuming 5 ft. per unit without diagonal multiplier) would be affected.) This is also assuming that auras radiate from the edge of the creature, rather than the center. (which is vague in most game systems)

I'm looking at the functions right now. And other than what appears to be some sort of rounding bug that I'm investigating on maps with non-integer grids, the calculations are correct.

Regards,
JPG

EDIT: And the rounding issue affects all distance calculations, not just the API version.

[Moon Wizard]

With example pictures with an underlay (i.e. aura) of range 2 grid units.

JPG

[MeAndUnique]

The Unity cross-platform engine that we built FGU on uses their own implementation of .Net; and they currently support .Net 2 / .Net v4.x

Regards,
JPG

Since you seemed interested in the idea of moving forward from the old Framework 4.6 version I figured I'd ping this topic again in case it got lost in the shuffle. The following excerpt from the Unity Docs (https://docs.unity3d.com/2019.1/Documentation/Manual/dotnetProfileSupport.html) clarifies that .Net Standard 2.0 is presently supported and recommended (in addition to, and distinct from, the legacy .Net Framework 2.0):

"Stable scripting runtime
The stable scripting runtime supports two different profiles: .NET Standard 2.0 and .NET 4.x. The name of the .NET Standard 2.0 profile can be a bit misleading because it is not related to the .NET 2.0 and .NET 2.0 Subset profile from the legacy scripting runtime. Instead, Unity’s support for the .NET Standard 2.0 profile matches the profile of the same name published by the .NET Foundation. The .NET 4.x profile in Unity matches the .NET 4 series (.NET 4.5, .NET 4.6, .NET 4.7, and so on) of profiles from the .NET Framework.

Only use the .NET 4.x profile for compatibility with external libraries, or when you require functionality that is not available in .NET Standard 2.0."

[Moon Wizard]

All I know is that System.Text.Json does not resolve in the Unity project; and throws a compilation error. So, that means that something isn't supported somewhere. Unfortunately, this is low priority; so it's not something I plan on spending a lot of time investigating.

Regards,
JPG

[MeAndUnique]

Oh, for sure, not worth hunting down for Json. The engine upgrade itself may be worth it for performance improvements (you have to manually switch to .Net Standard). It does have a small risk of requiring additional changes, depending on what libraries FG currently leverages.

[Moon Wizard]

We use a lot of libraries; probably not worth the risk. Especially since we're deep in vision/lighting updates.

Regards,
JPG

[deer_buster]

What's wrong with the existing Unity JSON utility? Granted it may not be as feature heavy as system.text.json, but it's at least optimized for Unity.

[Moon Wizard]

This is the built-in Unity JSON serializer:
https://docs.unity3d.com/Manual/JSONSerialization.html

You must have a serializable class with the exact same structure as the JSON you are trying to load/save. It is not a general purpose serialization library; but designed to load/save specific Unity object data.

Regards,
JPG

[dogfisc]

I'm trying to use the imagecontrol getDistanceBetween and getTokensWithinDistance and I find that if I pass in numeric values they seem to always be calculated as if they were 0, 0. Below are some results with two tokens which, according to the targeting arrow, are 15 feet apart. getDistanceBetween correctly returns 15 if I pass in the tokens, but 0 if I pass in their positions. I'm using FGU and Pathfinder 1e.

Of course, this is my first foray into working with any sort of positional data in FG, so I may just be doing something wrong.

local srcToken = CombatManager.getTokenFromCT(srcActor.sCTNode);
local tgtToken = CombatManager.getTokenFromCT(tgtActor.sCTNode);
local srcImage = ImageManager.getImageControl(srcToken);

Debug.chat("srcToken: ", srcToken);
Debug.chat("tgtToken: ", tgtToken);
Debug.chat("srcImage: ", srcImage);

local srcX, srcY = srcToken.getPosition();
local tgtX, tgtY = tgtToken.getPosition();

Debug.chat("srcToken to tgtToken: ", srcImage.getDistanceBetween(srcToken, tgtToken));
Debug.chat("srcX, srcY: ", srcX, srcY);
Debug.chat("tgtX, tgtY: ", tgtX, tgtY);
Debug.chat("srcX,Y to tgtX,Y: ", srcImage.getDistanceBetween({srcX, srcY}, {tgtX, tgtY}));

s'srcToken: ' | tokeninstance = { { container = image.id-00002.image, id = 16, x,y = (275.0, 25.0)} }
s'tgtToken: ' | tokeninstance = { { container = image.id-00002.image, id = 12, x,y = (100.0, -50.0)} }
s'srcImage: ' | imagecontrol = { name = s'image', x,y,w,h = 1,37,1068,945 }
s'srcToken to tgtToken: ' | #15
s'srcX, srcY: ' | #275 | #25
s'tgtX, tgtY: ' | #100 | #-50
s'srcX,Y to tgtX,Y: ' | #0

[Moon Wizard]

If you are passing numerical values, they must be of the form of a Lua table with "x" and "y" indexes pointing to the X,Y values you want to measure to/from.

Regards,
JPG

[Moon Wizard]

Given your natural assumption, I'll look at adding a simple numerical indexing option as well (such that table[1] and table[2] are equivalent to table["x"] and table["y"]) in a future version.

Regards,
JPG

[dogfisc]

If you are passing numerical values, they must be of the form of a Lua table with "x" and "y" indexes pointing to the X,Y values you want to measure to/from.

Regards,
JPG
That’s what it looked like from your original post, but when I had tried that I got the same result. I went back, and I had misread: I was using uppercase X and Y as the table indexes.

Thank you! Sorted now, and these new APIs are really useful.

[Weltenbrand]

I am experimenting with the token distance functions.
I noticed that half grid cells are rounded up.
E.g. if one grid cell is 1m than 1 and a half cell distance is calculated as 2m.
Is this intended?
And can I change it to get 1.5m?

It would be alos nice, I one could give a flag to getDistanceBetween to return raw distances.
44875

[Moon Wizard]

If you convert the map record to use raw distances (or the ruleset in general); then the raw results will be returned. (i.e. the image will return whatever is being used for the distance calculation specifically.)

Regards,
JPG

[Weltenbrand]

Ok, how do I set the ruleset to use raw distance by default?
And can I disallow the GM to changes this?

[SilentRuin]

Ok, how do I set the ruleset to use raw distance by default?
And can I disallow the GM to changes this?

Grid is defined in map tools, it has the grid distances and a check box for raw distances - if that is what you are talking about. A GM has full control of everything so they can copy/edit whatever they want if they have a mind to change it.

[Weltenbrand]

If you convert the map record to use raw distances (or the ruleset in general); then the raw results will be returned.
I was referring to this.

Where it can be set in the image interface is clear.

People are bad at reading manuals, therefore I would like at least set raw as default.

[celestian]

If you convert the map record to use raw distances (or the ruleset in general); then the raw results will be returned. (i.e. the image will return whatever is being used for the distance calculation specifically.)

Regards,
JPG

Is there an new API for the raw distance flag? Apologize if I missed that somewhere. Checked confluence and couldn't find what I was looking for.

[Moon Wizard]

For rulesets, the following tag will set the raw distance calculation as the default:
<distance>
<diagmult>*</diagmult>
</distance>

For API interactions, the following call will set the current map to raw distance calculation:
imagecontrol.setDistanceDiagMult("*");

There is no way to "block" GMs from changing to what they want using the image control panel. This is by design, and you should not subvert the GM from changing to what they want for their own games.

Regards,
JPG

[celestian]

For rulesets, the following tag will set the raw distance calculation as the default:
<distance>
<diagmult>*</diagmult>
</distance>

For API interactions, the following call will set the current map to raw distance calculation:
imagecontrol.setDistanceDiagMult("*");

There is no way to "block" GMs from changing to what they want using the image control panel. This is by design, and you should not subvert the GM from changing to what they want for their own games.

Regards,
JPG

Thanks for the details. The <distance></distance> bit goes in the base.xml I presume? Does it need to reside in a specific section or it's own under root? I attempted the latter and it didn't seem to work for me.

[Weltenbrand]

Thank you.



There is no way to "block" GMs from changing to what they want using the image control panel. This is by design, and you should not subvert the GM from changing to what they want for their own games.


I disagree with this statement. I/we subvert GMs from changing a lot, by not suppling a option to change XYZ in a ruleset. I dont see why ditance calculations should be different.
If the map does not return half gridcells as 0.5m, the melee distance calculations wont work for my ruleset. And people often dont read manuals/wikis, therefore I would like to make it clear, that this setting should not be changed.
Adding a tooltip would also be fine, but it seems to me that this controls are part auf the FGU Programm and nor of the CoreRPG ruleset.

[SilentRuin]

Thank you.



I disagree with this statement. I/we subvert GMs from changing a lot, by not suppling a option to change XYZ in a ruleset. I dont see why ditance calculations should be different.
If the map does not return half gridcells as 0.5m, the melee distance calculations wont work for my ruleset. And people often dont read manuals/wikis, therefore I would like to make it clear, that this setting should not be changed.
Adding a tooltip would also be fine, but it seems to me that this controls are part auf the FGU Programm and nor of the CoreRPG ruleset.

You missed the point, its not that you "can't code it to happen" its that they do not want to code it to happen as that is one of the great features in FGU map tools, GM's can do what they want to make the data behave as they want. They are not going to give some 3rd party control over denying that control.

[Weltenbrand]

I understand it is a want. It is ok if SW don't want to change it.

You missed my point - "GM's can do what they want to make the data behave as they want." - no they can't. They can change the data as far as the current ruleset allows them (or maniuplate the db.xml).
They cant roll a skill check in DnD with a d2. Why ? the ruleset does not allow this, because it isnt "correct" in this ruleset.

It is fine to not provide this functionality to ruleset devs, but please dont use freedom for GMs as an argument for this.

[SilentRuin]

I understand it is a want. It is ok if SW don't want to change it.

You missed my point - "GM's can do what they want to make the data behave as they want." - no they can't. They can change the data as far as the current ruleset allows them (or maniuplate the db.xml).
They cant roll a skill check in DnD with a d2. Why ? the ruleset does not allow this, because it isnt "correct" in this ruleset.

It is fine to not provide this functionality to ruleset devs, but please dont use freedom for GMs as an argument for this.

They can with generic map tools. Which are not ruleset based. At least in the context of this conversation about distances and map definitions. If you're changing the topic to other specific ruleset data - then sure - what you can do is limited to ruleset (to some degree as there is still generic data that must be respected) because that is their data and their tools to control it.

[Weltenbrand]

I will move this to PM. I don't think the discussion is too philosophical to belong here.

At topic: I am doing the distance calculation with getPosition and getGridSize now without the getDistance functions. This appraoch should be not affected by "raw distance" ?
There is no "need" to anything. I made my point and dont find the counter argument to be convincing.

[LordEntrails]

I would be annoyed, and perhaps not even use a ruleset, if the ruleset did not allow me to use maps/images in a unit of measure that makes sense to me. Some folks want meters, some want feet. To refuse to allow people to change this when the built in capability is already there is... unfortunate. But that's just from a GM/User perspective w/o specific knowledge of your ruleset.

[SilentRuin]

Not sure why I allowed my counter argument to go offline but I'll share it here so that what he found unconvincing is at least public...

First this is only my opinion as I'm not a SW dev, low level ENGINE code data sets and controls are given access to rulesets (CoreRPG, 5E, etc.) on a need to use basis. Because it can really screw things up if non SW employees have access to manipulate whatever they want. So they limit what they expose and what you can do with that data/control. Anything in the ruleset code they provide is fair game for you to change. But not the ENGINE level code because people outside of their direct control messing with that level of the code can seriously make their overall product look bad. So they only have the DEV document expose certain API functionality. This whole thread is about a few new API's they are going to expose. They, as a rule, are cautious in exposing any of that stuff to outside devs (ruleset/extension).

And for sure when they expose controls (map tool check mark for raw distances check mark) that control that same data. Some things in the FGU product are not subject to "ruleset" control. Low level map functionality and behavior being one of them. That is ENGINE code. Smiteworks keeps control of ENGINE operational code and does not provide API's for them except in limited cases for use by rulesets. There are plenty of examples of this, but for sure this whole thread is about them opening up access to the ENGINE data operations with an API. It will be limited.

Will they change that at some point? Only if it does not risk any future changes or control of those changes they have planned for the future. Hence, a gate on what they will expose in the API to the ENGINE code/data.

[Weltenbrand]

Ok back to public if this is desired.

@SilentRuin
First this is not the part I find unconvincing, this is the last part you send me and I haven't responded yet.
Again I understand it is not exposed at the moment. You don't have to repeat how it is at the moment. This doesn't change anything on the argument if it is a good or bad idea.
I made the point that I think it would be good to be able to hide the control. The response was not "subvert GM" as the reason to not do this. Which I think is not a valid argument, like I stated.
I also stated "not wanting to do it" is accetable. This would habe been a way better answer in my opinion.

From your PM "you do not want to accept that they will not expose it for you. That is your point."
I written one piece of opinion to SW in a sub forum which is build to give feedback. Afterwards I disagreed with you answer and didn't say anything further regarding SW, just to you answer.
I seemed to have missunderstood your answer. I thought you have a reason why you think it should be like this. Now I get the feeling your answer is more "it is like it is". Which is ok, but not really helpful.
I think it is fair game to give feedback in a feedback subforum as client which generates more clients in his free time.

And a boolean flag to hide a control surely does not create a massiv esecurity flaw in the engine code.


@LordEntrails I dont want to disallow changing the units or grid cell size. I want to disable uncheck "raw distance". The ruleset needs to be half grid cells to be calculated as half cells and not rounded to full cells.

[LordEntrails]

Got it :)

[Weltenbrand]

I think I overlooked this bit:


imagecontrol.setDistanceDiagMult("*");


I can call this before every distance calculation, to get the desired behaviour? (And set it back to the value from imagecontrol.getDistanceDiagMult if I want do be nice.)
(with the side effect that the shown and the used distance are different)
But this wont work with the Token Package ?

[Moon Wizard]

You should not override this. If the GM has specifically changed the distance calculation to what they want in their game; why would you override it for your internal distance calculation? That just means that your distance calculation does not equal the GM's expected distance calculation.

Regards,
JPG

[Weltenbrand]

I think the GM expects to get the right modifier in terms of the underlying PnP.
I am not on the "allow everyone to shoot themselves in the foot" side.

The philosophical stance aside, I am quite sure people would prefer the right modifier instead of message "this setting of the distance disables the following features x,y,z".
The PnP has a bad handling of distances on battlemaps, it has strange effects.
I will implement a option to disable "the correction of wrong imagecontrol settings". People can choose to shoot themself in the foot if they really want to.
But for the others which want the ruleset to automated the ugly calculations of the PnP away, I want to do this.
And I kind of know my users, a couple will click the controls just because they are there.

[Moon Wizard]

I believe you are looking at this wrong.

You set up the ruleset to map to the ruleset rules in FG; and the GM has control whether to override those rules in their own maps. If they choose to use a different distance calculation, why do you care? There is no reason to "enforce" your "correction" on GMs.

Just use the distance as returned by the map "as is"; and apply whatever automation goes with those distances. Don't try to "fix" things; just apply it.

Most users won't even bother changing the units; so not sure why this is such a concern.

Regards,
JPG

[Weltenbrand]

It is a bit more complicated than just raw or not raw. I simplified it here. Always using the shown distance really does not give you the right results in every circumstance except the GM between melee and range rolls.

But ok we will not agree here.

I will use my own distance calculations, if the users pprefer it otherwise the will let me know.

In my experience is that people will change settings because they can and than complain that stuff doesn't work anymore. Already happened even if the option tooltips says what the effect will be.

I think everything is said.

[celestian]

For rulesets, the following tag will set the raw distance calculation as the default:
<distance>
<diagmult>*</diagmult>
</distance>

For API interactions, the following call will set the current map to raw distance calculation:
imagecontrol.setDistanceDiagMult("*");

There is no way to "block" GMs from changing to what they want using the image control panel. This is by design, and you should not subvert the GM from changing to what they want for their own games.

Regards,
JPG


Thanks for the details. The <distance></distance> bit goes in the base.xml I presume? Does it need to reside in a specific section or it's own under root? I attempted the latter and it didn't seem to work for me.

This has gotten lost in this discussion so want to repost/bump.

[Weltenbrand]

Gameelements.xml

[celestian]

Gameelements.xml

Oh wow, duh, thanks ;) I almost never touch that so never remember it.

For what it's worth tho it's still not setting that on for me. Checking map and it's still 10 across when ti's half-way unless I toggle the raw distance option (which I thought would be set by the change). I'll dig around. Actually I've a good idea what this is, the campaign settings ... yep.

[rathen45]

Oh wow, so will this import Hero Labs Online?

I want this too, hell I'd settle for OG herolab support again now that it's no longer in development. but that doesn't seem to have anything to do with this update.

[Moon Wizard]

These APIs have been moved to the developer API reference wiki. Again, please note that these are for FGU only.

https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/996644535/Developer+Guide+-+Ruleset+API+Reference

Closing the thread for now. If you have specific issues with the APIs, please post in Workshop or House of Healing forums.

Regards,
JPG