fgu 4.4.4 rotated tokens not 'selecting' correctly... ( as if not rotated. )

[bratch9]

Hi,

Noticed that when you enlarge a token, the rotated 'selection' hand hover does not show in the correct area. ( Possibly due to some interaction with the changed gridOffset. )

They also seem to get reset to horizontal on reload of the campaign.

The rotation angle also seems to be re-set when you change the size of the token, bringing the token back to horizonal (zero rotation.) This then seems to confuse the rotate usage as it seems to still think it was actually rotated and applies the new rotation and sort of resets the drawn image to how it probably should have been...

See attached 'rotated_444.jpg' showing the 'selection' box been shown when the cursor is outside the image area but within the image area if it was not rotated...

-pete

[bratch9]

Just an extra, while I've not tested this... I also suspect the 'token update on hover' also is not running. ( As my spell tokens extensions does not show updates to hand cursor in the rotated area outside the horizonal area. ) Due to it thinking the cursor is not within the image area.

-pete

[pindercarl]

Hi,

Noticed that when you enlarge a token, the rotated 'selection' hand hover does not show in the correct area. ( Possibly due to some interaction with the changed gridOffset. )

They also seem to get reset to horizontal on reload of the campaign.

The rotation angle also seems to be re-set when you change the size of the token, bringing the token back to horizonal (zero rotation.) This then seems to confuse the rotate usage as it seems to still think it was actually rotated and applies the new rotation and sort of resets the drawn image to how it probably should have been...

See attached 'rotated_444.jpg' showing the 'selection' box been shown when the cursor is outside the image area but within the image area if it was not rotated...

-pete

Thanks for the report. This should be fixed in the next update.

[bratch9]

Thanks for the report. This should be fixed in the next update.

By next update, are you talking next update of the rulesets or next update of the fgu exe side.

ie are you talking about updates in the next week or so, or updates in the next month or so.

Just so I can inform my 'spell tokens extension' users that the core game is broken for token selection (near the edges depending on rotation.. ) and they will just have to use the CT or find an area that token selection works...

Thanks, Pete

[Moon Wizard]

A hot fix has been pushed to address this issue, as well as a few others. Please run a new Check for Updates to get the latest version.

Regards,
JPG

[bratch9]

A hot fix has been pushed to address this issue, as well as a few others. Please run a new Check for Updates to get the latest version.

Regards,
JPG

Thank you for the quick hot fix, my quick tests seem to show this as fixed. ( And also my spell tokens extension looks to be working now. )

-pete

[bratch9]

Found a client->host sync issue with version 4.4.4(hotfix) to do with rotation and bitmap setcolor.


In the attached 'bitmapwidget.jpg' you can see that the extra 'addBitmapWidget' is not respecting the 'selectWidget.setColor("00000000");' on the client which is applied on creation during an overridden 'TokenManager.updateHealthHelper' ( which does call the original function. )



local selectWidget = tokenCT.findWidget("B9ST");
if not selectWidget then
selectWidget = tokenCT.addBitmapWidget("logo_b9");
selectWidget.setName("B9ST");
selectWidget.setSize(math.floor(tokenWidth*1), math.floor(tokenHeight*1));
selectWidget.setColor("00000000");
end


Once the token has been moved on the client the logo image correctly goes invisible. This is a new 'feature' of the fgu 4.4.4 version.

I could not replicate this with a health damaged npc 'HealthDot' which my code is based on, and in the 'coreRPG' 'TokenManager.updateHealthHelper' is the point of create/update of this on the health dot, so I would expect my bitmap widget to be initialised with correctly color.



I have also seen rotation differences showing up in the new fgu 4.4.4 version, see 'client_server_sync_issue.JPG', again a new 'feature' of 4.4.4. This is more complex as I also have to sync the 'imageControl.setTokenOrientationCount()' as I increase this to 72 on a per map basis on the host. Due to this been a host function only, if the client opens an image that the host has not opened, the client sends a message to the host to try and set this value. If the image is not open on the host side, it is temp opened and orientation count set and closed back down. So the host might glitch a fraction of a second but normally does not see the image open/close in one frame. So this might be some delay sync issue in fgu 4.4.4 that is now different to previous versions of which this was working fine. It tends to be in sync if the host opens the image first before a client does, which is the more normal case of the DM moving players onto a map and sharing it. But obviously could happen that the client opens the map first on a new session at a later date, hence the requirement to bounce the message via the host.

{ Note. I do seem to recall at some point the rotation count was set in the 'gameelements.xml' with a <tag>, but not seen this for a long time and might have been in FG classic. Does it exist in FGU, as this might be a better was to force the value without a sync message... which might solve the rotation sync issue... }

Thanks,
Pete

[Moon Wizard]

Widgets are not synchronized across machines; each client must set up separately.

Since this is such a very specific issue; can you please put together a small extension that shows this issue? We don't have anything like that on our side to test with.

Thanks,
JPG

[bratch9]

Attached a cut down version of spell tokens extension. ( for you v0.0 )

It only has the part of the code that adds the 'B9' logo bitmap widget override.

See attached 'bitmapcolor.jpg' from FGU 4.4.4 ( client showing logo on player/npc tokens, which will clear up as soon as you move the token. )

See attached 'bitmapcolor_443.jpg' from FGU 4.4.3 ( not showing as expected due to color set. )

Feel free to adjust the alpha in the code for the setcolor to confirm the logo exists on both the host and client. ( As its a black logo it does not respond to 'color', ie you can not make it red unless you decide to quick edit the logo and fill it with white. As its just an black alpha cut out logo... )

The campaign in both 444 and 443 version were just a new 5e with the 'fg battle maps' and 'player's handbook' loaded to get the map and giant spider. Just a brand new non-setup player character with an token image applied. Then both added to a map and that map shared. Load both the host and the client and just open maps on both to see the issue. When you move a token on 4.4.4 the B9 logo correctly goes invisible as it then decides to apply the correct color setting.

As this is clearly visible on the client, the code is obviously adding this for the client. With the color ("00000000") only been set just after the addbitmap call I would expect the logo to be alpha-ed out an not visible on the client. ( as per the 4.4.3 fgu version. )

Thanks, Pete

[Moon Wizard]

Thanks. I've forwarded to @pindercarl to review as the image/token developer.

Regards,
JPG

[Moon Wizard]

I just pushed v4.4.5 with what we believe may fix the issue. Please run a new Check for Updates to get the latest version to give it a try.

If you are still seeing an issue, we will need step-by-step instructions on how to recreate the issue you are seeing, as we are not familiar with your extension nor its usage.
(i.e. 1. Open new FG campaign; 2. Create image with FG Battle Map 01 asset.; 3. Create PC; 4. Assign token to PC; 5. Add PC to CT; ...)

Regards,
JPG

[bratch9]

I just pushed v4.4.5 with what we believe may fix the issue. Please run a new Check for Updates to get the latest version to give it a try.

If you are still seeing an issue, we will need step-by-step instructions on how to recreate the issue you are seeing, as we are not familiar with your extension nor its usage.
(i.e. 1. Open new FG campaign; 2. Create image with FG Battle Map 01 asset.; 3. Create PC; 4. Assign token to PC; 5. Add PC to CT; ...)

Regards,
JPG

fg 445 does not resolve the issue, I managed to recreate it.

See attached image 445.jpg


I've marked on both the host and client image map area the approximate location of the cursor when the capture was made. The image was taken with the client (right) map image of the pair, you can see the 'help text' 'cone of cold (bob)' showing when the cursor is clearly outside the cone of code area, but if the graphic was in the 'correct' position like on the host (left) image it would have just been in the edge of the cone of cold spell token. So both the client and host 'know' the location and the 'token->hoverupdate' function is correct on both, the graphic is drawn is some 'odd' location on the client making it out of sync.

Obviously if I rotate/move the spell token on the host then the client will catch up correctly... and if I rotate/move the token on the client side then the incorrect location gets rotated/moved and this 'new' wrong position gets synced to the host side. Bringing both in sync with each other.

I created this with a new campaign and to take these images I just loaded the host side, touched nothing, and joined with the client and just opened the client image before opening on the host side.

I'll spend some time later making a campaign for you to load and hope to replicate with. ( I'm assuming you can gift yourself the b9-spelltoken and b9-commoncore extensions from the forge !!! )

Thanks for continuing to look into this.

-pete

[Moon Wizard]

Yes, we can get a copy of the Forge extensions when needed; just a manual process.

All we need is the campaign and specific step-by-step process to see the issue, so that we can recreate here.

Regards,
JPG

[bratch9]

Yes, we can get a copy of the Forge extensions when needed; just a manual process.

All we need is the campaign and specific step-by-step process to see the issue, so that we can recreate here.

Regards,
JPG

Find attached a campaign and special version of my spell tokens extension for you to use.

1. install 'rotate_token.zip' into your campaign folder. ( Unzip into a folder called 'rotate_token' or whatever you want to call it on your machine. )
2. install 'B9_SpellTokens.ext' into your 'extensions' folder.
3. host load the 'rotate_token' campaign. ( This should be marked as loading the 'B9 - Spell Tokens' extension and on load it should announce as v0.1 )
4. do nothing on the host.
5. client 'join' the 'rotate_token' campaign.
6. toggle off setting on startup and next out all the on startup windows.. ( Nothing needs to be loaded or changed from default )
7. client 'claim' character 'bob'
8. double click the 'bob' token to open the map he is on.

You should now have a client map open on 'battlemap01' with two 'T' tokens and a 'B' token. One of the 'T' the right most should be upside down. ( See 445_hf.jpg right side map image. )

9. Go back to the host window, you can now open the 'battlemap01' ( shortcut on the '1' in the bottle left, or find in the images or off the CT etc.. )

You should now be able to see on the host that the right 'T' is only tilted a small amount clockwise, while your client version is still fully upside down. ( See 445_hf.jpg leftside map image. )


I think this is because of the use of 'image.setTokenOrientationCount', which is marked as a 'Only scripts running on the session host can set this property.' in the documentation, which is used to increase the rotation count available for 'fine' rotation of spell tokens. Which can also be used to fine rotate normal player/npc tokens as well.

In this flow case, with the image NOT open on the host, when the client joins and you open the image on the client I send a message to the host to change the orientation count. This checks on the host for the image and if needed 'opens' the image, calls setTokenOrientationCount, and if the image was opened on the host it will close it back down. ( Its all in one step so you normally dont see the image flick on for any time. )

Because on the client this message is sent on the onInit, I think the client goes on and calculates the rotations of the tokens at the low rotation count. When the updated count is 'synced' to the client it probably does not 're-generate' the token rotation.

Thanks, Pete.

[pindercarl]

Changing the orientation on the client was not triggering a redraw of the token. This should be fixed in the next update.

[Moon Wizard]

The change @pindercarl mentioned has now gone Live.

Regards,
JPG

[bratch9]

The change @pindercarl mentioned has now gone Live.

Regards,
JPG

Thanks for the updates, I've checked with both the testing versions attached in this thread and with the full spell tokens extension and all seems to be working now.

-pete