This is a version of 4.8 with some debug. This shouldn't be used by anybody unless they're having issues - the version on the forge is what should be used otherwise.
Printable View
This is a version of 4.8 with some debug. This shouldn't be used by anybody unless they're having issues - the version on the forge is what should be used otherwise.
Small problem: Clicking on options always need one extra click to cycle back to the first option.
Big problem: Using the scroll-wheel without key-modifier does not zoom in/out of the map when the mouse-pointer hovers over a token.
GKEnialb, I may be able to help you with that issue since I already solved that in my extension; actually Moon Wizard solved this issue :)Quote:
Originally Posted by Weissrolf
(though I am guessing now, I did not yet test your extensions)
Change your onWheel function to the following:
You see, way more concise than your function :) You currently overwrite everything and your return true is at the very end; however, seemingly the onWheel function gets merged with the original one, it won't overwrite it as it usually happens with scripts. It rather runs simultaneously with the original one (though I am not sure whether this is how one should describe it, just my naive observation after Moon Wizard's help and suggestions). If the return true gets executed, then anything in lower layers like the original onWheel function won't be activated and searched for. (so, it basically stops the onWheel activation/procedure) That means, that you can control with the position of the return true, when you actually want the original code to be executed or overwritten. By having the return true in the Alt-if-clause, which is the only real new information you add via the height extension to onWheel, you assure that your code only applies when pressing alt. While for other shortcuts like ctrl and shift it will still use the original code.Code:function onWheel(tokenCT, notches)
if Input.isAltPressed() then
TokenHeight.updateHeight(tokenCT, notches, true);
return true;
end
end
This method improves compatibility with the actual code and also won't overwrite the onWheel code when just the mouse wheel is used while hovering over a token. Then Weissrolf's issue should be solved since the original code actually already adds zooming while hovering over a token and using the mouse wheel :)
Your method executes always return true, leading to that the code for a pure mouse wheel without using shortcuts while hovering over a token is overwritten. With Moon Wizard's method you then do not need to figure out adding the zooming while hovering over a token :) (and neither do you need to maintain the code for the other shortcuts which can be a mess; your shift-if-clause may for example not work completely on hex grids or other type of grids in general since adjacent fields are not always 8. So, this issue may be then solved, too :) )
This seems to have done the trick. Thanks Kelrugem!
Solution:Quote:
Originally Posted by Weissrolf
Basically baselabel and baseval create the label and value so you shouldn't include them in labels and values.Code:function registerOptions()
OptionsManager.registerOption2 (
"THIALLOWUSERADJUST",
false,
"option_header_height_indicator",
"option_label_allow_player_mod",
"option_entry_cycler",
{
labels = "option_val_no",
values = "no",
baselabel = "option_val_yes",
baseval = "yes",
default = "yes"
}
)
OptionsManager.registerOption2 (
"THIPOSITION",
false,
"option_header_height_indicator",
"option_label_height_position",
"option_entry_cycler",
{
labels = "option_val_bottom_left|option_val_left|option_val_top_left|option_val_top|option_val_top_right|option_val_right|option_val_bottom_right",
values = "bottom left|left|top left|top|top right|right|bottom right",
baselabel = "option_val_bottom",
baseval = "bottom",
default = "bottom"
}
)
OptionsManager.registerOption2 (
"THIFONT",
false,
"option_header_height_indicator",
"option_label_font",
"option_entry_cycler",
{
labels = "option_val_large",
values = "large",
baselabel = "option_val_medium",
baseval = "medium",
default = "medium"
}
)
OptionsManager.registerOption2 (
"THIFONTCOLOR",
false,
"option_header_height_indicator",
"option_label_font_color",
"option_entry_cycler",
{
labels = "option_val_medium|option_val_light",
values = "medium|light",
baselabel = "option_val_dark",
baseval = "dark",
default = "dark"
}
)
OptionsManager.registerOption2 (
"THIDIAGONALS",
false,
"option_header_height_indicator",
"option_label_variant_diagonals",
"option_entry_cycler",
{
labels = "option_val_long",
values = "long",
baselabel = "option_val_short",
baseval = "short",
default = "short"
}
)
OptionsManager.registerCallback("THIALLOWUSERADJUST", setPlayerControl)
OptionsManager.registerCallback("THIPOSITION", changeOptions)
OptionsManager.registerCallback("THIFONT", changeOptions)
OptionsManager.registerCallback("THIFONTCOLOR", changeOptions)
setFont()
end
Thanks, Kelrugem and bmos! Uploaded v4.9 to the first page and the Forge (still processing in the Forge as I write this) with both of those fixes. Wish I had known about the onWheel thing at the beginning - could never quite figure out that behavior. :) And also didn't know about not duplicated the baselabel/baseval. Great to learn new things.
Was this updated in the forge or only in this thread?
It is live on the forge as of now. It took long enough to process last night that I got distracted by a shiny object and didn't check later, so thanks for the reminder. :)
I recently updated to 1.2 of Kent Height and 4.9 of Token Height and when i put a token 20' in the air and next to another token it is rolling with disadvantage with a ranged attack. It was working previously.
I can confirm this is no longer working and was fine before.
Same version of Kent's extensions as before?
Same setup: 1.2 of Kent Height and 4.9 of Token Height. No change in the Kent original exts (those have not change in some time). The only change is token height.Quote:
Originally Posted by bmos
I was able to test it on v4.8 and v4.7 both have the bug. I don't have anything before 4.7. Maybe something in v4.5 did it?
Ok...lots of variables here but I think I found it. kent height 1.1 + token height 4.9 work. The issue seems to be in kent height 1.2.
I have had reports of this issue. It happens when Height returns 0, I don't know why that happens. When Height returns 0, Kent height will use the original 2d code from Kents extensions. In this case it doesn't know about height. if you look at your console output /console Kent Height will print a message there anytime Height returns 0.Quote:
Originally Posted by nephranka
If you can figure out how to reproduce the error it would help a lot into getting it fixed. The only common factor I've heard to reproduce is multiple players connected.
I loaded kent flanking & range, kent height, and token height (versions in the chat window). Added an npc and a pc to the CT and to the map. Adjusted the pcs height to 30ft and attacked with a longbow. I open the console for the screen shot. Clean build. If I move the pc back it fires without DIS.Quote:
Originally Posted by rhagelstrom
The options are Long Range Auto Disadvantage ON and Ranged in Melee Auto Disadvantage ON.
Might be worth adding a printstack to that console message.Quote:
Originally Posted by rhagelstrom
Can you try reproducing with the version found in this post? There are some extra debug statement there that hopefully could narrow down what's going on.
I went and used v4.8 token height & kent height v1.2. Screen and logs attached.Quote:
Originally Posted by GKEnialb
Thanks. @rhagelstrom, are you calling Token.getDistanceBetween? If so, since imagecntrl.getDistanceBetween is returning 30 and Token.getDistanceBetween directly returns imagecntrl.getDistanceBetween, the only way you'd get a 0 is if neither token has an ImageControl:
Code:function getDistanceBetween(sourceItem, targetItem)
local ctrlImage, winImage, bWindowOpened = ImageManager.getImageControl(sourceItem, true)
if ctrlImage then
return ctrlImage.getDistanceBetween(sourceItem, targetItem)
else
ctrlImage, winImage, bWindowOpened = ImageManager.getImageControl(targetItem, true)
if ctrlImage then
return ctrlImage.getDistanceBetween(sourceItem, targetItem)
else
return 0
end
end
end
@nephranka, did you add the tokens to the map by dragging from the combat tracker or from some other source?
Dragged from the CT.Quote:
Originally Posted by GKEnialb
Thanks. No reason they shouldn't both have the image of the map associated with them then. @rhagelstrom, any thoughts?
Kent height 1.3 should fix the issues anyone was seeing and it is live now in the Forge. It looks like I uploaded a bad build in 1.2. Sorry for the problem anyone was having.
Wow thanks Rhagelstrom. I missed using these tools now I can turn them back on. AWESOME!!!Quote:
Originally Posted by rhagelstrom
Tested and working good! Thanks!Quote:
Originally Posted by rhagelstrom
Should there be an option to pick which range method to use? I can only see font color, font size, location of indicator, players can change height, variant diagonal style.
What do you mean by range method as opposed to variant diagonal style?Quote:
Originally Posted by graphil
If you want to use raw Pythagorean method you should unlock map and check the use raw distances option (which is per-map not for the whole campaign).
Ah, it is on the map not a global option. Thanks.
Have an issue. If I take a monster directly out of the Monster Manual and place it on the map everything works fine. But if I choose a creature out of my own sub folder monster manual, it does not seem to.
You don't need to have a flying speed. The token does have to come from the combat tracker, though.
Yeah have that... working tests trying to find out what broke it, I will get there, perhaps a mistake of my own
Found the error.... it is an SUE problem, not sure there is going to be a fix for that.
Not sure if this is useful to you, GKEnialb, but thought you should see part of new FG changelog:
[DEV] Consolidated token initial onAdd/onMove event into a single onAdd event with correct token position.
...
[DEV] Token onDrag event was not triggering. Fixed.
@bmos, thanks for that.
@DwightLee, glad you found the problem, but sorry there may not be a fix for you. What is SUE? If there's anything I can do on my side, I'd be happy to investigate.
disregard for now
There is a compatability issue that happened again now with the latest live version of fantasy grounds unity.
A compatability issue between this extension and "combat modifier calculation" extension. I have reported it before also, but it had been fixed a couple of times.
I am not sure if it is the latest fantasy grounds version or one of the latest "token height" extension versions that has caused this issue to come back again. "Combat modifier calculation" has not been updated so it is not a update from that extension at least.
A small summary:
I get this error message:
Handler error: [string "campaign/scripts/image.lua"]:147: attempt to index local 'targetToken' (a nil value)
I added a bunch of debug.chat commands in the "combat modifier calculation" to see when the error happens. The error happens when the extension calls this function (in the "manager_action_attack_custom.lue" file):
local adjTokens = srcImage.getTokensWithinDistance({x=tgtCoord.x, y=(tgtCoord.y * -1)}, 5);
See details here
https://www.fantasygrounds.com/forum...l=1#post617619
Not sure where the error lies.
Sorry - I've been out of town. Do you have tokens on the map that aren't on the combat tracker? Basically targetToken is coming from looking up each combatant node in the combat tracker and isn't finding one of them. I can protect against that easily enough, but want to make sure I'm not ignoring a valid token.
Yes, I am sure everything is in the combat tracker.Quote:
Originally Posted by GKEnialb
I think you are just running into a new 4.1.5 bug: https://www.fantasygrounds.com/forum...ion-miss-match
I realize that you've probably tested your extension with all the Rulesets that you've enabled for it, but is there any real reason to restrict it to a limited set of Rulesets?
Mainly because I started with just 5E and only added as requests came in and I could test to see if there were any ruleset-specific peculiarities (particularly with diagonals). That being said, I probably have enough rulesets now that it should work for any of them - I'll remove that restriction. Now to find a mod to get the name of this thread changed. :)
Edit: Live on the Forge