Well, these changes seem simple enough. I am hope they can be folded into the existing code.
Printable View
Well, these changes seem simple enough. I am hope they can be folded into the existing code.
Thanks for looking into this. I'll post an update in a few hours. Hopefully this fixes the issues from both nephranka and anathemort
Thanks!Quote:
Originally Posted by GKEnialb
On a side note. I was on the Discord channel for rob2e and Jeremy post this:
Jeremy Putman — 05/15/2021
for example. I changed a single line in the checkForNerbyEnemies function from
if checkMeleeDistanceBetweenTokens(token, sourceToken) == true then
return true;
end
to
if Token.getDistanceBetween(token, sourceToken) <= 5 then
return true;
end
And it seemed to trigger the same way with or without the new height extension on the FG forums, but also took into account that extensions height variable so if they were side by side, buy 10 ft up it didn't trigger the disadvantage.
It worked for sneak attack and I also tried it in the flanking & range ext from kent and it worked there as well. The one that did not work was pack tactics from kent. This is a big deal for those of us that want to use height and range rules. I let Jeremy know it was a great find. I thought I would share it.
Thanks, nephraka - happy to see that. And thanks bratch9, as the proposed fix seems to work great (I was able to drop asset tokens, so should be fine for spell effects, and drop a bunch of tokens with the faction buttons). v3.9 posted accordingly.
Looks to working for me. Thanks!
Working for me, too. Thanks for the fast fix!Quote:
Originally Posted by GKEnialb
4E
Token Height version 3.9
In tonight's game when ever somebody moved their token the Host received this error:
[ERROR] Handler error: [string "campaign/scripts/image.lua"]:30: attempt to index global 'Interface' (a nil value)
Not sure what triggered it. I remember opening an image and had players view it then when we went back to the map with their tokens on it, the error started happening. This extension is the only one with an "image.lua"
I think changing:
toCode:if getDistanceDiagMult or Interface.getDistanceDiagMult then
should keep this from occuring, but this is almost certainly an extension compatibility issueCode:if getDistanceDiagMult or (Interface and Interface.getDistanceDiagMult) then
I just experienced something odd:
completely new campaign, 5E, no other extension running
added four characters to the CT, opened a random map [with LoS presets], tried to drag the characters from the CT to the map using the green helmet symbol. During the drag, as expected, a greenish square was shown, but when I released the mouse button, the characters stubbornly refused to enter the map....
Using v3.9? This was just discussed and fixed.Quote:
Originally Posted by Roach
I think my example (screenshot) should measure as 5 ft, not 10 ft, as this is still the first diagonal. I understand there are different options, so I will try them out in PF2.
That strongly depends on how you approximate the diagonal multiplier. The usual diagonal in 2D has a multiplier given by the square root of 2 (in the Euclidean metric). Many rulesets approximate that by either 1 or 1.5, and then round down to the next multiple of the grid incrementQuote:
Originally Posted by Weissrolf
However, in 3D you do not just have one diagonal in a square grid. The screenshot you show is about a "double-diagonal" whose diagonal multiplier is the square root of 3 (in the Euclidean metric), not of 2. You may approximate it in the same way as the square root of 2, but one may argue that one wants to avoid that. GKEnialb's approximation gives an approximation of 2 for the square root of 3
That actually "makes sense" if you approximate square roots by the continued fraction expansion: https://en.wikipedia.org/wiki/Method...tion_expansion
There is some table a bit downwards of that article, and the first order approximations of the square root of 2 and 3 are 1.5 and 2, respectively, with respect to that approximation :)
If that fits whatever the rulesets say is of course something different; sadly, ruleset developers (I mean Paizo etc.) do rarely explain things mathematically, if they even think mathematical for such things. Often 3D stuff is done very vague in my opinion. If you like the explanation with the continued fraction expansion, then it may be easier to accept such calculations :)
(Though I assume that it is intended that GKEnialb's extension works like this; I may be wrong, I did not test it on my own. I just only looked at your screenshot)
Does it show a range of 5ft. If the flying and standing tokens are directly next to each other? (because then it would be again a square root of 2, just "one diagonal")
Yes, orthogonal sides show 5 ft. only the 3D diagonal shows 10 ft. PF2 rules state: "As with ground-based movement, moving diagonally up or down in 3-D space requires counting every other diagonal as 10 feet."
Going another step diagonally and up increases the calculation to 20 ft. while it should be 15 ft, it's the second diagonal step.
depends now whether they want that one accounts the corresponding diagonal move in the 2D plane :D Because the diagonal of your screenshot also has a diagonal move in the projection into the 2d plane (hence, the square root of 3 talk above). But Paizo may not have thought about that you have two different diagonal movements in 3d, so, difficult to say if there are no examples in the PF2 rules clarifying that (are they?)Quote:
Originally Posted by Weissrolf
As Kelrugem says, there is some level of uncertainty in how the rules are written.Quote:
Originally Posted by Weissrolf
Right now it appears to have been calculated as 5ft diagonal + 5ft altitude.
Moving further away then becomes 15ft diagonal + 5ft altitude.
Have you considered using raw distance?
They are neighboring squares, that is 5 ft. and people can hit each other over the head. Sometimes answers are that simple. :p
Also depends :D A flying target is often more difficult to hit, even if adjacent; in the case of your screenshot only the feet and legs may be similar to hit as non-flying targets, while the remaining body becomes more difficult to hit, reducing the probability for a successful attack :D With respect to Euclidean measures the distance from centre to centre is certainly bigger than if the target would not fly :DQuote:
Originally Posted by Weissrolf
I changed line 30 as you suggested. Will report back after next game if the error happens.Quote:
Originally Posted by bmos
Thanks!
For sake of the game system adjacent squares are 5 ft. apart from each other, in PF2 even the second diagonal is considered 10 ft for the sake of (only) weapon reach. Physics and anatomy are ignored.
It also makes no sense to split a diagonal 3D distance into a 2D diagonal + altitude while drawing orthogonal 3D diagonal distances directly. And at least in PF2 the first 3D diagonal is 5 ft. regardless of direction, just like in 2D. I quoted the CRB rule earlier (page 478).
I will take a look at the code and try to fix it for our PF2 group. It's a useful addon in any case.
No reason to become blunt :) My last answer was actually partially also a joke since I found the imagination behind that situation funnyQuote:
Originally Posted by Weissrolf
And you misunderstood, it is essentially not split like that (though may be equivalent to that after an approximation); see my explanation above. Not every diagonal in 3d is the same, and I can understand if GKEnialb wanted to cater for that. That is just something purely mathematical, no anatomy, no physics. However, maybe GKEnialb will add an option for that, maybe not; and as also bmos said, your quote still contains some degree of uncertainty
I added another quote for more clarity, but that was after your next post. You are too fast for me. :p
"Measure flanking in all directions— creatures above and below an enemy can flank it just as effectively as they can from opposite sides."
aah, oki, indeed, PF2 seems to do as you propose :)Quote:
Originally Posted by Weissrolf
Uploaded v3.10 to protect against this error (though as with the other "disappearing" functions, no guarantee as to the behavior if this comes up - at least it'll stop the error in the console). Thanks for the response, bmos.Quote:
4E
Token Height version 3.9
In tonight's game when ever somebody moved their token the Host received this error:
[ERROR] Handler error: [string "campaign/scripts/image.lua"]:30: attempt to index global 'Interface' (a nil value)
Not sure what triggered it. I remember opening an image and had players view it then when we went back to the map with their tokens on it, the error started happening. This extension is the only one with an "image.lua"
Any drop issues should have been fixed in v3.9. I tried to recreate it, but couldn't. Which random map was it? If I have it as well, I can take a look at the grid settings.Quote:
I just experienced something odd:
completely new campaign, 5E, no other extension running
added four characters to the CT, opened a random map [with LoS presets], tried to drag the characters from the CT to the map using the green helmet symbol. During the drag, as expected, a greenish square was shown, but when I released the mouse button, the characters stubbornly refused to enter the map....
Still trying to get my head around this not being considered two diagonals. Granted, if it is, then according to the rules you quoted, it'd be 15 ft and not 10 ft, so my formula wouldn't work either way... I can definitely either have a different formula for PFRPG2 or put an option in (would prefer to do the former, as I'd have to add an option to the existing set of options for 5E and create new options for non-5E) - just need to contemplate what that formula would be (which will probably hit me about the time as I can imagine the cubes touching on one vertex is considered the same as two cubes touching on an edge which is considered the same as two cubes touching on their faces). :)Quote:
I think my example (screenshot) should measure as 5 ft, not 10 ft, as this is still the first diagonal. I understand there are different options, so I will try them out in PF2.
Okay, v4.0 is now posted, which gives a different diagonal distance than the other 5/15 diagonal variants. Weissrolf, let me know if this meets what you were hoping for. The only difference really turns out to be when all the deltas are the same: a 5'x5'x5' delta in this will be 5' as requested (and 10'x10'x10' will be 15') as opposed to 10' and 20' with the other. If anybody preferred the original formula in PFRPG2 or wants this new behavior in another ruleset, let me know and I'll add an option to toggle between the two.
Mea culpa - I hadn`t realized it had been updated, relying on MNM's 3rd Party Updater.Quote:
Originally Posted by bmos
No worries - didn't even know about that extension. Looks very useful, so I've submitted the form to add this extension to Mad Nomad's list.Quote:
Originally Posted by Roach
Got this error today after Shift Drag a token to a new location on the same map. After I did the Shift Drag this error happened then every time that token was moved the error happened.
https://i.imgur.com/Ng1w4YA.png
Oh! That's exactly the same error I got! If this error is linked to this extension that would be helpful to be corrected!
I thought it was an interraction with the Aura extension.
We have to figure out why all of these functions keep disappearing. It is a call made from this extension, but CombatManager isn't modified in my extension. Can you give me details on your setup (other extensions, ruleset, etc?) and can you reproduce it? I can put guards around the call to prevent an error, but you can't really do much if the CombatManager goes away. Thanks.
I exited FGU and reloaded to see if I could duplicate the error but was unsuccessful.Quote:
Originally Posted by GKEnialb
Ruleset is 4e.
I have a bunch of extensions including Aura Effects.
I will mess around later with trying to recreate the error by adding extensions one at a time.
Thanks - appreciate the effort.
I've got another one for you :|
https://github.com/bmos/FG-Aura-Effect/issues/10
I wonder what is going on with these!
Perhaps see if everyone having that issue is also using Aura Effect?
I couldn't recreate locally since I can't recreate the exact conditions of the error 48. It happened during a live cloud game with four players connected. A neutral NPC with an AURA effect was introduced to the game at the beginning of the session and the error started when trying to move any character loaded in the CT and/or added later or even after PCs were changed of map or moved via Shift Drag. It really was a "close spammed logs every single token move" festival for 4 hours, but I kept quiet. No player saw the log error and I ignored it because you know, the show must go on. ^^
When moving the party token that was not linked to the CT in the Overland Map with no AURA active in that map, no error was encountered.
This is with the PFRPG1 Ruleset with these extensions:
FG-CoreRPG-Coins-Weight
FG-CoreRPG-Extraplanar-Containers
FG-PFRPG-Ammunition-Manager
FG-PFRPG-Encumbrance-Penalties
FG-PFRPG-Malady-Tracker
FG-PFRPG-NaturalArmorBonusTypes
FG-PFRPG-Time-Manager
MirrorImageHandler
Mythic-Abilities
PFRemoveEffectTag
TokenHeight
WindowSaver
Drain-and-Permanent-Bonuses
FG-PFRPG-Extra-Stat-to-Saves
FG-PFRPG-Spell-Formatting
FullOverlayPackagewithalternativeicons
FG-PFRPG-Advanced-Effects
PFRPG-EnhancedItems
FG-PFRPG-Advanced-Character-Inventory-Manager
FG-PFRPG-Live-Hitpoints
FG-PFRPG-Item-Durability
BetterMenus
FG-Aura-Effect
Very similar experience for me as well. The only difference was a foe npc not visible was added to the CT and the errors started. Not reproducible, so far, but I will keep at it.Quote:
Originally Posted by Khoredran
The two different times this happened to me, two different campaigns. I was using Aura Effect as well as Height. It also happened an hour to hour and a half into the sessions both times.Quote:
Originally Posted by bmos
I'll see if I get the error again with only Aura Effect loaded and not Height in our next game.
The error only happens on the GM host side, players don't see it. I had to deal with the console up every time a player moved their token for about an hour till the end of our game... as was stated earlier, the show must go on :-)
Hopefully the conflict will get worked out as Height is a really awesome extension.
I just finished some tweaking/testing on the CoreRPG Coins extension, and began receiving a very similar error. I found that all of the functions were declared as local functions, which is not what I am used to doing. So I tried changing them all from the format:
local function abc()
to
function abc()
After doing this I stopped having that error. I cant say 100% for sure this is the cause for what others are experiencing, but it may be involved somehow.
Actually not all of them, just the ones that only needed to be called from within that script. Using local functions is a good idea when they aren't going to be needed in another scope, but perhaps this does not work in certain circumstances such as when also using function replacement in another script (such as Token.getDistanceBetween = getDistanceBetween) or perhaps when using OOB. I've been doing the former for a while without seeing this issue, but I only just started using OOB recently so it could be that. I have globalized the functions involved in OOB messaging (but not the other local functions) for Auras v1.1-beta.2. If someone who is having this issue can give it a shot I'd love to hear your results.Quote:
Originally Posted by mattekure
EDIT: looks like I had a couple typos. here is a working test build: Auras v1.1-beta.3
I tried the Aura v.1.1-beta.2. with all my other extensions and the AURAs in the CT just stopped working altogether.
I also tried the extension alone in a new TEST campaign and no success either. Ruleset used: PFRPG1
EDIT: I tried the Aura v.1.1-beta.3 with all the extensions and everything seems to be working as intended!
I will have to try it in a live play with all the players connected, but this looks promising. ^^