Only have one filter, but add a drop down for motion behaviour

[GrandyB]

Having multiple filters mean switching between types is awkward. You may set everything up then realise that you picked the wrong type, in which case you have to make a new filter and slowly transfer the values over - not ideal. Also makes testing out the different types awkward.

Instead, have one filter type but with a 'Behaviour' drop down at the top of a single filter, that changes which fields and toggles you get to see.

Suggested types:

1. One way, A to B.

• Pre-defined start point A, pre-defined destination point B.
• If a source isn't at A when it is activated, it is moved there as the motion begins.

2. One way, ? to B.

• Any start point, pre-defined destination.
• Just takes current position and moves it to A.

3. Two way, A to B and back.

• Pre-defined start point A, pre-defined destination point B.
• Forcible moves sources to the start or destination when moving forward/backward.

I think it's currently confusing, and sometimes contradictory, as to the behaviour of motion when you do/don't provide specific values for position and size at start and end. I think we also have some bugs in this area which will be easier to diagnose when we have clear separation of types.

Some examples of wanted motion:

• "Move something across the screen". You'd use 1, as you just want a single direction.
• "Move between 2 positions". You'd use 3, as again, you only want forward and back.
• "Move between 3 positions". You'd use several of 2. Just a destination point to travel to. That way you can move between the 3 of them in any order.

Thoughts?

[CatxFish]

I think using drop down menu is a better way but there are some behavior issues need to prevent when we implement it like how to save hotkey config when switch between one way and round trip .

And using the absolute and relative coordinate issue may be considered here
The first one and the third one obviously should not appear in relative system.

[GrandyB]

Agreed about the config, shall have to play around with that.

Regarding relative movement, we might have different definitions... I think I can see relative movement working for 1 and 3, but not 2!

Relative movement should work for anything with a provided start point - here's a user journey for relative movement:
For purposes of the example, the source is currently sitting at X:640, Y:360

"One way, A to B"

• Must define start position (have my auto-input button next to it!)
• Tick a 'Relative destination' checkbox
• 'Distance X' and 'Distance Y' fields instead of destination fields
• Enter "100" for the 'Distance Y' field.

This would implicitly set the destination to X: 640, Y: 460.
Same thing would happen for Two way, A to B and back. Implicitly set the destination based on distance. Behind the scenes would be basically the same it is now, just that it saves it after some simple maths.

Option 2 (One way, ? to A) doesn't work because we wouldn't know where to begin? What is the destination relative to? Imagine having several filters using this on the same source... you would lead your source out into the void by making it move relative to its current position over and over again!

[GrandyB]

As a note, I'm working on this.
First stage will be converting what we currently have into a drop down, second will be to split these out as per this ticket. I have the drop down working but as you mention, hotkeys are a pain.

[CatxFish]

Great , Let me know if you need help .

[CatxFish]

This feature has been implement in version 1.1.2