transition.moveTo "on the fly" speed/time changing, is this possible?

Hi!

Transition is very powerful tool, so it’s much more easy to use it instead of do each frame calculations. Can the speed (time) be changed on the fly? I.e. baloon is moving from x1 to x2 with speed depending on transition time and I need toi slow down it’s speed. Yes, I can just reduce it’s coord every frame by slow-down-delta-value, but using crutches is not very good idea.

I didn’t found same question, but I think it was already asked. In documentation transition can return a table. And no other info. What table can be returned by transition func? this maybe is answer to my question.

Thank you guys!

Looking at the API docs, I would say you have limited control over a current transition:

If you want to modify an existing transition (unless someone out there has a library to provide this) you would probably want to track the values you want control over, destroy one transition and create a new one immediately.

I picture it like this: A dot moving across the screen at a constant pace via transition. A slider allows the speed to be changed. When the slider is moved the transition is destroyed and a new one created using the current location as a starting point and the modified values as input. The tricky(ish) part is working out the time value for the newly created transition (although this is really just subtraction.)

Yes, I thought about this. Time can be found from distance between two points: start and end points. Distance was 1000 the time was 1000, new distance is 500 and the time will be 500.

I see there is a table returnable from proc so I thought perhaps I can control transition params in flow. 

table: 0E25A708 { 15:40:54.467    [\_transition] =\> function: 047202E0 15:40:54.467    [\_instantiatedByTransLib] =\> true 15:40:54.467    [iterations] =\> 1 15:40:54.467    [\_target] =\> table: 0E25A708 { 15:40:54.467                   [\_proxy] =\> userdata: 0A024AA8 15:40:54.467                   [\_class] =\> table: 0A024D10 { 15:40:54.467                                 [removeEventListener] =\> function: 0471FC40 15:40:54.467                                 [addEventListener] =\> function: 0471FC20 15:40:54.467                                 [\_\_index] =\> table: 04727F50 { 15:40:54.467                                                \*table: 04727F50 15:40:54.467                                              } 15:40:54.467                               } 15:40:54.467                 } 15:40:54.467    [\_timeStart] =\> 3720.5 15:40:54.467    [\_delayParams] =\> table: 0E25A708 { 15:40:54.467                        [y] =\> 870 15:40:54.467                        [x] =\> 270 15:40:54.467                        [time] =\> 10049.875621121 15:40:54.467                        [delay] =\> 45224.440295044 15:40:54.467                        [transition] =\> function: 047202E0 15:40:54.467                      } 15:40:54.467    [\_duration] =\> 10049.875621121 15:40:54.467    [\_delay] =\> 45224.440295044 15:40:54.467    [tag] =\> "" 15:40:54.467  }

You’d be better off downloading the transition.* source and modifying it by adding functions instead of tweaking those ‘internal’ fields.

https://coronalabs.com/blog/2018/07/10/corona-labs-releases-a-new-public-build/

Open-source libraries

In addition to these changes, Corona Labs is open-sourcing the following libraries:

  • timer.*
  • easing.*
  • transition.*
  • composer.*

You can download the Lua source for these libraries from the Corona Labs GitHub account. In addition, the widget.* library was updated to be in sync with our internal library.

Thank you! This is new approach )

Looking at the API docs, I would say you have limited control over a current transition:

If you want to modify an existing transition (unless someone out there has a library to provide this) you would probably want to track the values you want control over, destroy one transition and create a new one immediately.

I picture it like this: A dot moving across the screen at a constant pace via transition. A slider allows the speed to be changed. When the slider is moved the transition is destroyed and a new one created using the current location as a starting point and the modified values as input. The tricky(ish) part is working out the time value for the newly created transition (although this is really just subtraction.)

Yes, I thought about this. Time can be found from distance between two points: start and end points. Distance was 1000 the time was 1000, new distance is 500 and the time will be 500.

I see there is a table returnable from proc so I thought perhaps I can control transition params in flow. 

table: 0E25A708 { 15:40:54.467    [\_transition] =\> function: 047202E0 15:40:54.467    [\_instantiatedByTransLib] =\> true 15:40:54.467    [iterations] =\> 1 15:40:54.467    [\_target] =\> table: 0E25A708 { 15:40:54.467                   [\_proxy] =\> userdata: 0A024AA8 15:40:54.467                   [\_class] =\> table: 0A024D10 { 15:40:54.467                                 [removeEventListener] =\> function: 0471FC40 15:40:54.467                                 [addEventListener] =\> function: 0471FC20 15:40:54.467                                 [\_\_index] =\> table: 04727F50 { 15:40:54.467                                                \*table: 04727F50 15:40:54.467                                              } 15:40:54.467                               } 15:40:54.467                 } 15:40:54.467    [\_timeStart] =\> 3720.5 15:40:54.467    [\_delayParams] =\> table: 0E25A708 { 15:40:54.467                        [y] =\> 870 15:40:54.467                        [x] =\> 270 15:40:54.467                        [time] =\> 10049.875621121 15:40:54.467                        [delay] =\> 45224.440295044 15:40:54.467                        [transition] =\> function: 047202E0 15:40:54.467                      } 15:40:54.467    [\_duration] =\> 10049.875621121 15:40:54.467    [\_delay] =\> 45224.440295044 15:40:54.467    [tag] =\> "" 15:40:54.467  }

You’d be better off downloading the transition.* source and modifying it by adding functions instead of tweaking those ‘internal’ fields.

https://coronalabs.com/blog/2018/07/10/corona-labs-releases-a-new-public-build/

Open-source libraries

In addition to these changes, Corona Labs is open-sourcing the following libraries:

  • timer.*
  • easing.*
  • transition.*
  • composer.*

You can download the Lua source for these libraries from the Corona Labs GitHub account. In addition, the widget.* library was updated to be in sync with our internal library.

Thank you! This is new approach )