Storyline 360 drag-and-drop issue: object moves away from cursor after state change

Hi Ronald. I can see you are right. I think this is the only option at this point. The thing is, by doing this, I hope the users will not consider this as a limitation as we are running a playtesting. I will give it a short now. I appreciate it. 

Thierry's diagnosis nails it: the object's hit box stays at the Drop Correct size (328 px tall) even after the visible state switches back to Normal, so the cursor offset is computed against a bounding box the learner can't see. Since there's no native "reset drag anchor" and no supported JS hook for it, the reliable fix is to stop reusing one object for both jobs: keep the small Normal-sized object as the only draggable, and put the big installed visual on a separate non-draggable object underneath it. The learner always grabs the small proxy sitting on top of the big visual, so the anchor math never changes and there's no jump. State changes then only swap the visual underneath, never the dragged object itself.

Hello ArminBaghaei​ . I was able to understand your problem by reproducing it in my own file. The problem obviously stems from the significant difference in the size of your object depending on its state. When you click on the bottom (for example) of the object in the “Correct Zone” state to reposition it, you’re still moving a ‘shape’ that’s 328 pixels tall, even though it reverts to its “Normal” state, which is 48 pixels tall. This is why it seems like the cursor is pointing into thin air.

A small piece of JS code seemed like the most promising solution, but as usual with the AI Assistant, it was a three-hour struggle with no results. I did manage to realign the object in its Normal state under the cursor as I moved it (with a few lines of code that force the object to follow the cursor), but then, when I tried to cancel that forced tracking, set the object’s coordinates to that centered position, and restore the object’s original draggable functionality: the Assistant couldn’t code it correctly (and neither could I, of course). Maybe some tech-savvy folks can help you with this.

So, I can only offer you a small workaround—it works, but it’s just a workaround. At the same time, is what you’re looking for really essential for the success of the activity and for memorizing the information? However, I’m just like you: I like to dig into a problem when I encounter one.

You can apply a motion path of 0 pixels and 0.1 seconds to your object and create a trigger: Move Object along this path when its state is Normal. That's it.

As soon as you move the object out of its drop zone, it instantly returns to its original position: you don’t have time to notice that the cursor and the object aren’t aligned. That’s the workaround.

This is better than adjusting the drag-and-drop options with “Return object to starting point…” because if you don’t release the selection on the object, you’ll still see the misalignment.

I hope this helps.

Hello, 

or this interaction, I’d structure the triggers so the visual change happens only after the drag/drop action, rather than trying to reposition the object while Storyline is still handling the drag.

A clean sequence would be:

When the user drops the object on the correct target

→ Change the object to Drop Correct.

This is the point where the installed membrane should appear.

When the user clicks/starts interacting with the installed object

→ Change its state back to Normal.

Put this trigger before any subsequent action that depends on the state change.

Immediately after that state change

→ Reposition the object so its center is aligned with the pointer (if you're using JavaScript).

Allow the normal drag interaction to continue

→ The learner can now drag the small Normal-state object back to its original location.

when multiple triggers respond to the same event, Storyline executes them sequentially, so the order in the Triggers panel matters.