token, onDragStart, onDrag, onDragEnd

[bratch9]

On drag stuff not getting called...

This is a coreRPG image.lua ( rename .txt file for upload ). Since we are in the image class i've named my Token.onDrag = onTokenDrag and output with onTokenDrag debug to be clear.

This is an empty campaign with just a created character called bob, nothing set just name.


1. when approve movement is enabled... ( No Drag calls for an extension to do anything with.. )

see 'approve_lock.jpg', when a player make a move suggestion. ( no drag events happen, which probably is ok.. )
see 'approved_lock.jpg', once the gm 'approved' the move. Still no drag events... it would be nice to get a 'onDragStart', 'onDrag' (during the animation phase of the token moving ), and an 'onDragEnd' to wrap things up.



2. when approve movement is disabled, player free to move token..

see 'player.jpg', once again we can see 'onTokenDragStart' multiple times with multiple maps open, I feel this should not be the case. We can see onDragStart and onDragEnd event, but you will also notice that the params these callbacks 'should' provide are all missing. They only return the 'target' parameter.

No 'onDrag' continue events are call during the move section. ( onMove events would be called, but really both should be getting called ? or onDrag,onDragStart,onDragEnd need fully replacing with onMove, onMoveStart, onMoveEnd ? )

also no events are called on the gm side when the player moves a token.


3. when approve movement is enabled or disabled and gm moves a token..

see 'gm.jpg', again like the player side only the onTokenDragStart/End are called on the gm side, and nothing extra shows up for the player side ( in the image it still shows the player move 6 lines, from (2) above. )



while I'm not too bothered about loss of parameters, it would be nice if the documentation was upto date. I've linked below the locations I look, please advise if a 'different' more upto date location exists.

I'm not sure if the onDrag(Start/End) for tokens is in progress of been 'removed', and the 'onMove' for tokens replaces it ?

Let me know if a fix, update is going to happen on this as the inconsistency of these calls and the report on my other thread for 'token,onAdd' is causing a lot of issues with extending token movement control in extensions.

-pete






Document pages,

https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/996644662/Token#onDrag
https://www.fantasygrounds.com/refdoc/Token.xcp#onDragEnd

[bratch9]

To be clear, I think the 'onDrag(Start/End)' calls should only happen on the machine doing the drag. And the database 'sync' system should keep the other machines tokens in position.

I'd like to see the 'onDrag' for tokens been called. ( I could match this up with the onMove and track it with holding the onDragStart target etc.. )

I'd like to see call for this only on the map the token is moving on, instead of calls for every map that is open.

And when in token lock, once the dm has approved the move for the player who did the drag sequence, I'd like to see that players machine get an onDragStart, onDrag calls during the move animation, and an onDragEnd. Once the move has been approved. I guess this could run simpler on the gm side and allow the database 'sync' system to keep the machines in position, but getting some form of sequence call on one machine to simulate the act of the move animation so that extensions can process token moves under 'locked' token approved moves.

-pete

[LordEntrails]

MOD: moved to Workshop, it's the best location for these types of discussions :)

[superteddy57]

The documentation was last updated in April and many new features have been added to images. Updating documentation isn't finalized, as this area, is consistently being updated as of late. I will pass this along to Moon Wizard to have a look and see if he can provide a more in depth answer to what you are seeing.

[bratch9]

The documentation was last updated in April and many new features have been added to images. Updating documentation isn't finalized, as this area, is consistently being updated as of late. I will pass this along to Moon Wizard to have a look and see if he can provide a more in depth answer to what you are seeing.

Thanks, the calls on images that the token is not on really should be cleaned up. Getting a documentation that matches the version release would be helpful. And I'm not sure on the loss of the onDrag call but maybe its not linked to the onMove instead.

I'll look forward to possible updates/feedback.

[bratch9]

The documentation was last updated in April and many new features have been added to images. Updating documentation isn't finalized, as this area, is consistently being updated as of late. I will pass this along to Moon Wizard to have a look and see if he can provide a more in depth answer to what you are seeing.

Hi Superteddy57,

I do not agree with document update last april.

I say this because the documentation does not have 'findWidget' (and others that I know about), which is part of the 'widgetcontainer' calls used by the coreRPG. This function was in use when I started extension development back in may 2020 and I started a git depot to keep ruleset history changes to allow three way merges of ruleset changes into my extensions as required. I would guess its even further out of date than this point in time that I know about...

So I'd say the documentation, in some parts, is out of date by much more that a year, not a few months.

You need to have a continuous integration system that automatically runs a script to pull out the api from the source code, and when the team update the source api they change the scanned comment/marked block that relates to the api so the CI system can automatic re-generation the documentation.

Think Unity Hdrp version drop down (https://docs.unity3d.com/Packages/[email protected]/manual/index.html) if you want an example of auto generated api documentation scanned from the code base.

If the team are providing documentation of the api for extension development, keeping this 'up to date' is important. I agree sometimes its a pain to do 'paperwork' when you are developing a code product, its boring and a faf. If your product has a 'documented api' you allow and expect external people to use, then we will try and use it, and we expect you to update it when it changes. So we can think about new things we could do if we know that api function existed, if we dont know it even exists then the power of having an api is basically lost.

In a modern world of development, the api document should be auto generated and available and correctly match the release version as part of the release. It should be part of the QA checks for a release that documentation and all software test cases are upto date and running and passing to 'validate' a release before it goes live.


-pete

[bratch9]

To follow up with some extra, if you add 'return true' on each of the call backs to 'stop the default actions' then you can get the 'drag.jpg' image output.

In this form you do get all three call backs, but obviously no movement of the token because of a very simple does nothing version of the onDrag(Start/End) functions in the image class Token mapping these callbacks.

You still get calls per open image, which as my other thread, I think is a BUG.

So 'something' in the default code is not properly calling the 'onDrag' per frame/mouse move update call. ( Not sure if this is intentional due to having the 'onMove' call back as its replacement ? or not ? )

It does not 'allow' callbacks to happen on token approve mode, you still get no callbacks for when the token is 'moved' on the map after the gm approves the move. Which I would hope should be added.

[Moon Wizard]

To be honest, I can not follow what you consider the "issue" to be. Your descriptions bounce around between topics/issues as you see them; and the details are embedded in a wall of text.

I would urge you to focus on asking very succinctly about what you are trying to accomplish first and foremost; then move on to provide some info on what you've tried; and then wait and see if anyone has any ideas.

More than likely, you should focus on using the onMove event; as the onDrag events can be impacted by approve/deny movement.

Regards,
JPG

[bratch9]

To be honest, I can not follow what you consider the "issue" to be. Your descriptions bounce around between topics/issues as you see them; and the details are embedded in a wall of text.

I would urge you to focus on asking very succinctly about what you are trying to accomplish first and foremost; then move on to provide some info on what you've tried; and then wait and see if anyone has any ideas.

More than likely, you should focus on using the onMove event; as the onDrag events can be impacted by approve/deny movement.

Regards,
JPG

1. FGC runs onDragStart,onDrag and onDragEnd callbacks, FGU only does onDragStart and onDragEnd callbacks. Making tracking hard because onMove is not a replacement for onDrag. If you have multiple tokens selected and start a drag you will only get onDragStart,onDrag,onDragEnd events for the one token in the group you started the drag with... You will get onMove events for every token that moves. The onDrag and onMove callbacks are very different. The fact FGU is missing its onDrag I consider as a bug.


( 2. which is covered by the other thread but was listed as its an issue on a wider than these selected callbacks I'll cover on the other thread. )


So this this has one issue, why is FGU missing its onDrag even callback ?

[Moon Wizard]

Thank you for summarizing. I'll look into the code to see if I can make sure it is consistent.

The fact of the matter is that the entire image/token system has been completely rewritten from the ground up to support all the new features in FGU; and thus will potentially have new behavior workflows or things that worked differently.

Regards,
JPG

[bmos]

1. FGC runs onDragStart,onDrag and onDragEnd callbacks, FGU only does onDragStart and onDragEnd callbacks. Making tracking hard because onMove is not a replacement for onDrag. If you have multiple tokens selected and start a drag you will only get onDragStart,onDrag,onDragEnd events for the one token in the group you started the drag with... You will get onMove events for every token that moves. The onDrag and onMove callbacks are very different. The fact FGU is missing its onDrag I consider as a bug.


( 2. which is covered by the other thread but was listed as its an issue on a wider than these selected callbacks I'll cover on the other thread. )


So this this has one issue, why is FGU missing its onDrag even callback ?

Pretty sure in FGU you want onMove rather than onDrag

EDIT: didn't read carefully enough! whoops

[Moon Wizard]

Just did some research, and I verified that the onDrag events not firing in a simple extension. I will need to look into whether those can be re-enabled. However, if they begin to impact performance of LoS/lighting, I will need to remove again.

Regards,
JPG