Tween of the same type are always returning each their own unique IDs.

[AlexandreFiset]

I just found that each time a new TweenState is created, it generates a unique ID. Is that by design? What if I want the current tween to go away when adding a new one?

For instance, if I start an alpha tween on some Ui but there is already one acting on it, I'd like the new one to override the old.

[NagaChiang]

Tween IDs are the same if the following parameters are all the same. elapsedTime is the elapsed time of the application, which I just realize that it might not be a good naming.

entity-tween/Runtime/Tweens/Components/TweenState.cs

Lines 68 to 82 in e5ca94a

	private int GenerateId(in double elapsedTime, in int entityInQueryIndex, in int tweenInfoTypeIndex)
	{
	unchecked
	{
	int hashCode = (int) EaseType;
	hashCode = (hashCode * 397) ^ EaseExponent.GetHashCode();
	hashCode = (hashCode * 397) ^ Duration.GetHashCode();
	hashCode = (hashCode * 397) ^ IsPingPong.GetHashCode();
	hashCode = (hashCode * 397) ^ LoopCount.GetHashCode();
	hashCode = (hashCode * 397) ^ elapsedTime.GetHashCode();
	hashCode = (hashCode * 397) ^ entityInQueryIndex;
	hashCode = (hashCode * 397) ^ tweenInfoTypeIndex;
	return hashCode;
	}

This way, if you create a tween with the same type in the same time, their IDs should be the same.

However, by design, there can be only one tween of the same type on the same entity, and the new one should override the old one.

It sounds like a bug if it doesn't work this way. Sorry for not having time to verify myself.

[AlexandreFiset]

I'm just wondering what part of the code disallow having two tweens of the same type other than:

if (!hasTargetType) { ParallelWriter.AddComponent<TTarget>(chunkIndex, entity); }

Because that only add the target to the entity, but then after a new tween state is created and added to the buffer. That means that if you have two tweens of the same type, but started at different times, they'll appear twice in the buffer, right? At least that is what I see. There seem to be no system removing an active tween.

Also, this part:
if (!hasTweenBuffer) { ParallelWriter.AddBuffer<TweenState>(chunkIndex, entity); break; }
Why does it break after adding the buffer? Wouldn't that prevent the tween from being added to the entity?

Sorry for all the questions :) I should be able to do a merge request if I can find a way to fix the issue I have with multiple tweens of the same type not working as I expected.

[NagaChiang]

I'm just wondering what part of the code disallow having two tweens of the same type other than:

if (!hasTargetType) { ParallelWriter.AddComponent<TTarget>(chunkIndex, entity); }

Because that only add the target to the entity, but then after a new tween state is created and added to the buffer. That means that if you have two tweens of the same type, but started at different times, they'll appear twice in the buffer, right? At least that is what I see. There seem to be no system removing an active tween.

As far as I know, when you AddComponent() with the existing instance of the same type already on the entity, the behavior will be SetComponentData(), so it will always have exactly one instance per type unless you use buffer.

Therefore, TTweenInfo (e.g. TweenScale) and TTarget (e.g. NonUniformScale) will be always have only one instance on the entity by the ECS design.

Also, this part: if (!hasTweenBuffer) { ParallelWriter.AddBuffer<TweenState>(chunkIndex, entity); break; } Why does it break after adding the buffer? Wouldn't that prevent the tween from being added to the entity?

And I think you are right I missed the corresponding TweenState check.

But how will it make sense to have 2 tweens altering the same property back and forth at the same time?

Sorry for all the questions :) I should be able to do a merge request if I can find a way to fix the issue I have with multiple tweens of the same type not working as I expected.

No worries! I'm happy to discuss with you if you find it interesting and you don't mind I might not respond immediately.

To be honest, I kind of lost the passion for this project, since it feels like that Unity will abandon the whole idea of ECS/DOTS and this project will die eventually. So I spend my time on other things then. I once thought this project will be so helpful.

[AlexandreFiset]

I understand that! Just so you are aware, DOTS is not going to die. I am not quite sure what is going on, but many Unity developers are working on Hybrid renderer, DOTS Animation and so on. See this comment from Joachim. Anyway to me this is more for learning to handle ECS / data management efficiently more than anything at the moment.

You are right that there can only be one component of the same type, but there can be more than one buffer. What that means is that when you add new states, the old ones persist and somehow are looping forever without being destroyed. I believe it is because the ID stored in the target no longer matches anything in the buffer.

Anyway, I'm on something else now but if I ever return to fix it I'll be sure to share the code just in case you're curious :)

[NagaChiang]

I understand that! Just so you are aware, DOTS is not going to die. I am not quite sure what is going on, but many Unity developers are working on Hybrid renderer, DOTS Animation and so on. See this comment from Joachim.

Oh so it seems they are just busy doing something else.

Anyway to me this is more for learning to handle ECS / data management efficiently more than anything at the moment.

I agree. Part of the reason why I made this project is for learning, and I did learn a lot about this new paradigm.

You are right that there can only be one component of the same type, but there can be more than one buffer. What that means is that when you add new states, the old ones persist and somehow are looping forever without being destroyed. I believe it is because the ID stored in the target no longer matches anything in the buffer.

Yes I think the old one should be removed once the new one comes in.

Anyway, I'm on something else now but if I ever return to fix it I'll be sure to share the code just in case you're curious :)

It will be a great contribution to this project, along with the new extensible design.