In response to this thread I believe that it would be a good idea to create a new library (.lua) file in the content folder that allows users to tween properties of different instances.
As it is, I do not feel that we need a method for every instance to tween properties, and instead a library would suffice just perfectly. We’d be able to use linked source of a module script to access it.
I have created a library for this purpose but have placed it in confidential tags in-case changes are made to the original file causing code created using it to become obsolete in the future. This module supports all datatypes, any that aren’t tweenable such as strings and enums are set after duration has elapsed.
Why would you put the source code in confidential tags if is just going to be open for us to look at if it gets implemented? Why not just give us the source now?
Since the code may be changed in the final iteration I want to keep it between just myself and the admins, rather than giving out code that could become obsolete very quickly making it difficult to switch.
Tweening library for pretty much every property which can be tweened between two values, and supports ‘add ons’, to improve functionality.
If that doesn’t do what you’re looking for then I don’t understand the point of this thread, as this is basically what was said in the OP.
This discussion is about making it easier for users with no prior experience to animate objects. The original topic by Place is a good example of this.
The library you have provided works off of property names instead of datatypes which means it has limitations. It’s further worth noting that the same library spawns multiple threads as opposed to one updating thread which would be far more efficient. Sure you could debate it allows plugins to fix this, but that totally steers away from the point of making things simple.
This discussion is about making it easier for users with no prior experience to animate objects. The original topic by Place is a good example of this.
The library you have provided works off of property names instead of datatypes which means it has limitations. It’s further worth noting that the same library spawns multiple threads as opposed to one updating thread which would be far more efficient. Sure you could debate it allows plugins to fix this, but that totally steers away from the point of making things simple.[/quote]
Having one thread to update everything isn’t always a good thing, as it means that if you’re animating a lot of objects (and I mean a lot) the animations actually become slower as you constantly have to loop through a table of lots of items. Lua tables use up a lot of memory and aren’t as fast as multiple ‘threads’.
I personally prefer “lower-level” tweening. That is, I just want a tween function that will input a time duration and output a ratio. Then code can be built on top of that to do other fancy things. That’s how I’m doing it currently at least and it’s worked well and helps with code extension quite nicely.
I have been playing with the idea of a generic property tweener for a while now. I also have written one in lua for some of the code that we are using on the Games team.
As far as implementation goes: I am not fond of getType functions that try to reverse engineer the lua reflection system to guess how to handle certain userdata types, especially when implementing official features.
That along with performance reasons is why I am thinking this would be better implemented in the C++ engine code. Although, if there are any concerns about that feel free to let me know. Also, I want to say that I am just discussing here, and there is no commitment to this feature as of right now.
I’d like to see an alpha modifier callback that would allow us to make our own easing styles. It would be called with the linear alpha and return the modified alpha. It would work like
[code]local modifier_sine = function(alpha)
return math.sin(alpha*math.pi/2)
end
tween(
part, – Object
‘Transparency’, – Property
0, – A
1, – B
0.3, – Time
modifier_sine – Modifier
)[/code]
[quote] …
That along with performance reasons is why I am thinking this would be better implemented in the C++ engine code. Although, if there are any concerns about that feel free to let me know. Also, I want to say that I am just discussing here, and there is no commitment to this feature as of right now. [/quote]
I have no concerns regarding that at all, what I was hoping for here was a sort of an in-between module that’s already on the client which then puts no pressure on you guys to change over. Plus, if you used the same syntax for the C++ version you’re suggesting then you could easily keep forward compatibility by ‘forwarding’ the function and its parameters.
This discussion is about making it easier for users with no prior experience to animate objects. The original topic by Place is a good example of this.
The library you have provided works off of property names instead of datatypes which means it has limitations. It’s further worth noting that the same library spawns multiple threads as opposed to one updating thread which would be far more efficient. Sure you could debate it allows plugins to fix this, but that totally steers away from the point of making things simple.[/quote]
2.0 fixes all of these problems but idk why we would use this as a default library. it’s not exactly meant for this, as my original intention was for GUI work and the support for other properties just “happened” lol
i mean i like the shameless advertising by digpoe but i honestly couldn’t see rbxanimator being used as a default. not at all.
edit: i still use multiple threads, yes, but the only reason is because i did a benchmark on 2000 parts and found that multi-threaded operations ran smoother than a single-threaded one in such use cases. the delay between frame iterations-per-part was horrible and grotesque at best.