Printable View
Looking at it.. I do see one issue with making it universal.
You aren't picking up the distance factors from FGU... In FGU the Distance Multiplier and the Distance Suffix are variables.. you probably should use those instead of a fixed 5 and ft .. that would make it pretty much work with anything in FGU.
Good point. I do use those variable when I have an image, but didn't in the plain token logic. I've updated the token logic and pushed to the Forge, so all should be good when it gets activated. Thanks.
I'm getting a very weird error with the latest build.
When I open the map, send to background, and then click on a token with vision, I get:
Also it has changed how send to background works. It leaves the windowed version open on top of the new view pinned to background.Quote:
[ERROR] MOUSE UPDATE: System.NullReferenceException
at (wrapper managed-to-native) UnityEngine.GameObject.get_activeSelf(UnityEngine. GameObject)
at CAEKKJIAJAP.LJPJAFHDPDB () [0x00023] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at CAEKKJIAJAP.LEEOHICLPIB (OPHDOKAJKAB OHECONBACLA) [0x0008a] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at CAEKKJIAJAP.EIOAOCIOICC () [0x00250] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at FG.CompositeImage.SortLayers () [0x00eea] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at FG.CompImageTokenLayer.ReceiveClickUp (System.Int32 OFIHBJJLLEO, UnityEngine.Vector2 KDOLCCJLOPE) [0x000ff] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at FMPJEDNFKON.MJNHCNGDOEA (System.Int32 OFIHBJJLLEO, UnityEngine.Vector2 LPJINEPFOMB) [0x000f9] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at AEKKJAPPMPK.DOPJDILPJCG (System.Int32 OFIHBJJLLEO, UnityEngine.Vector2Int OHCOFOJAPAN) [0x00050] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at KGNOOCIONDH.ReceiveClickUp (System.Int32 OFIHBJJLLEO, UnityEngine.Vector2Int OHCOFOJAPAN) [0x0001b] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at LEECPKFJIAJ.PKJBEAGEEFK (System.Int32 OFIHBJJLLEO) [0x001b0] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at LEECPKFJIAJ.JIDMLNKADMN () [0x0005c] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at FG.FGDesktop.OPILCLOHJGM () [0x00010] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
at FG.FGDesktop.Update () [0x0004e] in <c37ae9fb12b44b35bcbe0927d92c7e93>:0
It seems to be interfering with "Extended automation and alternative overlays" by Kelrugem
I don't see that on mine, but strangely enough when both Aura Effects and this are loaded, it draws the range arrow several times larger than if either of them are not loaded. I think it has something to do with when it's looking for the imagecontrol reference on its way up (before it really should be - if I set the bOpen to false at that point, I get nil returned). For now I've reverted to the older build until I can play with it some more to see if I can call it later in the process (but still automatically).
If it is something I can fix on my side, then please let me know :) I have sadly no idea yet what has changed in the newer build of height :)Quote:
Originally Posted by bmos
I'm not following this, could you send me a message with more details?Quote:
Originally Posted by GKEnialb
Quote:
Originally Posted by Kelrugem
Thanks. It actually seems to be a side-effect of me calling ImageManager.getImageControl(token, true) from TokenManager.getWidgetList. Not sure how, but everything else is just setting local variables. I'll look for a different way of doing that.
I'll do that now (but will put these picture here, as I don't think you can send images in a message) - "small arrow" is what it looks like if either of our extensions, but not both, are loaded and "large arrow" is what it looks like if both are loaded.Quote:
Originally Posted by bmos
Attachment 49040
Attachment 49042
I can't reproduce the script error in a new campaign, but I am still seeing the map double when "sending to background"Quote:
Originally Posted by GKEnialb
Here is a test campaign that just needs this extension loaded along with yours (the previously-posted version that you reverted): https://forge.fantasygrounds.com/shop/items/29/view
Thanks - I'll use this when testing out my update (may be a few days).Quote:
Originally Posted by bmos
Okay, new version up in the Forge that gets the correct variables from the rulesets without causing the issues that were noted. bmos, was able to use your test campaign to confirm the issue with 4.10 and confirm the lack of the issue with 4.11.
Sweet! Was it due to some 4.1.6 change?Quote:
Originally Posted by GKEnialb
Nope. Basically I moved my logic from pulling in token_height_indication.lua (which was causing a race condition when trying to get an image control) to pushing the variables from image.lua when it initializes.
This is dialing the clock back a bit... Had a question a few months back about enabling players to adjust the height of NPC tokens that were shared with them for situations like familiars or summoned critters and it didn't look like an option due to how ownership works. Was trying out MeAndUnique's 5E-Friend Zone extension (https://www.fantasygrounds.com/forum...5E-Friend-Zone) and together with this extension, it seems to provide the desired functionality. Haven't played through a whole session yet to see if any conflicts arise, but a quick test on a 5E campaign seemed to work. Was able to adjust the shared NPC's height, move, and target normally as a player without an issue. Adjusting NPC height on both Player and DM instances updated height and range correctly on the other.Quote:
Originally Posted by GKEnialb
Anyway, just wanted to share in case anyone else was in a similar situation with shared NPCs (or already tried and had bad things happen). Even with just DM control for NPCs, this extension has been great for my players with flying familiars and spider companions - thanks again for making and maintaining!
Awesome - thanks for letting us all know. Very cool that Friend Zone gets around that ownership issue (I use that extension, but never tried out changing the height).
Awesome, always good to hear when things just work. :)
Kent Height has been delisted. If you used it upgrade your extensions
Hi,Quote:
Originally Posted by rhagelstrom
is this because it's no longer needed?
Cheers,
Simon
Yeah once you update your Flanking and Ranged ext, it will fix the issue of not tracking the height that Kent Height was fixing. Kent had not updated his ext in a while so Kent Height was a fix to get them to work with token height so that it can track distance correctly. Now that Kent updated his ext, this one is no longer needed.Quote:
Originally Posted by Ludd_G
Cheers! :)
Quote:
Originally Posted by Svandal
I just want to report that this is still an issue with the combat modifier calculation extension and this extension. I was not sure what the 4.1.5 bug was you refered to and I have just put this issue on hold where I do not use the extension.Quote:
Originally Posted by bmos
But it has not been fixed in fantasy grounds yet. Do you konw if it is still a 4.1.5 bug or something else? I would like to use both extensions together, but I have nagged about this bug a lot in the past :)
Thanks for the report. The image.lua in TokenHeight only has 64 lines and doesn't have targetToken, so I'm guessing that Combat Modifier Calculation is pulling in the base version. I'll download that extension and try to confirm.
I can't recreate it following the steps in your post with just Token Height and Combat Modifier Calculation loaded (using 3.5, at least - which ruleset are you using?) Created two PCs with ranged attacks, added them to the combat tracker, drug them onto a map, opened one character sheet and drug the attack onto the other, without issue. If you're recreating with a different set of steps, please list them and confirm those are the only two extensions loaded.
That is strange. I am using pathfinder ruleset and only using those rulesets.Quote:
Originally Posted by GKEnialb
I will try to delete all my extension, redownload them and try again to see if that fixes it.
I will post a more comprehensive bug report when my kids are asleep tonight.
I just did a quick test.
It is only a bug for my existing campaigns. If I create a new campaign there is no errors.
Thank you for trying it out.
No worries. Glad that works for new campaigns, at least (though strange). Have you tried just clearing out the combat tracker and maps and re-adding everything? Or in the worst case, exporting / importing your campaign data?
I have not tried that, thanks your the tip.Quote:
Originally Posted by GKEnialb
It is not a problem, I dont have any running campaigns at the moment.
FYI
Love the Ext.
I am running a Champions campaign using this extension with the MoreCore ruleset.
Grid is hex and 1 meter.
So far, so good.
Awesome. Glad it's working for you - I think you may be the first to use it with a hex grid. Let me know if you encounter anything strange.
If the grid is set to raw it looks like the numbers are pretty close to expected, but the numbers look a little high when the grid is not in raw mode. Here is a picture and some data. Note the map is one I created / imported, the hex grid is 10.0 x 10.0 pixels and a hex is 1 meter.
Attachment 50978
Attachment 50979
It actually looks like it's working as expected.
For raw measurements: The target being due north and northwest should be the same (tried it without TokenHeight to confirm and both showed 4m), so column H and N being identical is correct. Not sure what calculation you're using for K, but it should be sqrt((x1-x2)^2+(y1-y2)^2+(z1-z2)^2) all values in pixels, divided by the grid pixel size. For an image looking just like yours, the attacker is at (933.4749146, 594.6726072188, 0) and the target is at (898.68267822266, 574.81237792969, 0), which has a distance of 40.06156 pixels, or 4.0m. I do round to single decimal point in raw.
For non-raw measurements: Morecore is returning 1.5 as the diagonal rule (same as D&D 3.5 or PFRPG). The distance calculation for that is taking the full amount of the maximum delta in any dimension and half the amount of of the delta in the other two dimensions (scaled to the units and gridsize). So if the attacker is 10m higher, the two locations in pixels are (933.4749146, 594.6726072188, 100) and (898.68267822266, 574.81237792969, 0), with the biggest difference in the z-axis of 100, and taking half of the differences of the x-axis (34.79223633) and y-axis (19.86022929) for a total distance of 127.3262, which is 12 hexes or 12m (trying to get the figures directly into the grid was tough, so the pixels I had may be slightly skewed from the pixels you had, so the 12m vs 13m isn't too surprising).
So basically, if you want to use "real" math, you need to use raw measurements. If you use the default Morecore settings, your values won't be as accurate, but that's just how Morecore diagonals are defined. Let me know if any of that doesn't make sense.
Yeah, I kind of figured that would be the case for the non-raw. The raw will work just fin e for us, especially the whiners in the group. ;-)
Thanks again!
I am sure this has been asked before, but there ARE 40+ pages to go through...
Does this work with Automatic Flanking and Range for the setting "Ranged in Melee Auto Disadvantage"?
I have a token at ground level next to a token with a height of 25ft. The range shows 25 feet, but I still get Disadvantage rolls for target in melee range.
Thanks!
Attachment 51119
Kent updated his ext to use the height measure. Make sure you have removed both this ext and Kent's and re-download both. I have tested it on my system and it is working. Other Kent ext (pack tactics and sneak attack) have also been updated.Quote:
Originally Posted by razzed1
I only have one other extension that is "not mine" in my campaigns - but man... This one just broke down a barrier for me. Kudos on this one. Simple, sleek coding. Instantly hooks into things that use the FGU token distance functionality.
I'm adding this one to all my campaigns. Well done author. Well done.
Thanks for the feedback! Glad it's working well for you.
I know I sent you a bunch of PM's but I figure we are on different time zones. Basically, I've rewritten some of the image.lua file to solve two problems...Quote:
Originally Posted by GKEnialb
- Conflict with other people who use onMeasurePointer (need to call super first so they get a shot)
- Becomes unusable when large number of tokens on map (streamline of processing in onMeasurePointer)
I've included a zipped "test" version with these fixes. I tested under the test campaign I use to test my stuff tailored for "Big Battle Test" things, which is where I verified that Token Height made the campaign unusable then verified this fix that it made it much better. I'm sure their could be more streamlining where getTokens() calls are involved though. However, this is "good enough".
Thanks so much for this. Wasn't checking these messages because I was swamped with work all day, so appreciate you looking into it. I knew that the getTokens calls weren't very efficient, but hadn't noticed it get that bad. I'll do a bit of testing with these changes myself and update the Forge if all works well.
---
The proposed code changes all looked good and all my testing passed. I've uploaded the new version to the Forge and just waiting for it to become active.
Weird - usually all I do is refresh the forge page and get back in my forge item and its ready to be made DATA - LIVE. Anyway - I'll check it out when it gets there as 4.11 was still showing for me. Also I just slapped that together - it might be worthwhile to see if there are other places that get hit with a lot of getTokens() where you just get them at the top level and pass the returned structure of them to all the lower levels that use them. But the bulk of slow down fix should be good enough as is.Quote:
Originally Posted by GKEnialb
Yeah, normally it's super quick, sometimes it takes a while. It is up and ready to go now. I'll look for other optimizations when I get a chance. Thanks again.
Yep AdvantagesPA.ext now works with it and the performance is improved. It's actually good enough now that its hard to tell where FGU slowness with LOS and lighting and large number of tokens is not the sole issue left.Quote:
Originally Posted by GKEnialb
Thank you!
[Further more refined testing shows its still slower with it loaded so I'll look to see if anything else can be done - it may just be a limit based on the single getTokens() search being hit so frequently (with lots of tokens)]