Anyone having this issue when using interpolate Behaviour?

Tiny_Ideas

Hello,

For the last month I had been trying to figure out this glitch that kept occurring in my game. I finally found what was causing it.

I am using three interpolate behaviours to change an actors (70 of them) colour.
It works perfectly smooth if I manually type in the variables.

But if I have the actors reference an attribute or table cell, or even a self.attribute with the exact same value, it doesn't like it, and glitches. The glitch is only for about 0.2 seconds, but its enough to make a game look unprofessional when the main character glitches when it is being moved.

This has been recreated twice.
Has anyone experienced this issue and any work arounds, or other ways to reference the values without manually typing it in.

Thanks,

owen_dennis

I've been having a similar problem, but not that many actors. I have a number of randomly spawned actors that update their position in a table that a hitbox then tracks. Those randomly spawned actors use the interpolate function to move back and forth. If I suddenly have the actor stop interpolating where it was going to go, the hitbox keeps going for a moment or two and sort of loses track of where it was supposed to be before snapping back. It's loses track for longer than it takes the cell to update, so that part probably isn't the problem.

I've been trying to get rid of it by getting rid of interpolate and miming the behavior with accelerate, move, or change velocity and timers. It's not perfect, but I don't experience that glitching thing. I'm still working on it, hoping I can figure it out though.

Socks

Are you interpolating the colour of 70 actors at once ?

And has each of these 70 actors got three interpolations ?

Which would be 210 interpolations going at once?

Tiny_Ideas

@Socks Thats correct.

This doesn't cause an issue if the value is typed in. But as soon as it starts to try reference another attribute, it can't handle it.
If there is another way to change a colour of an actor over a length of time then I am all ears.

@owen_dennis I know the feeling. It took me a week before I noticed it had nothing to do with the amount of actors I had. Because if its an 8x8 grid (64 actors) you can't really do anything with them if they can't even do this.

The_Gamesalad_Guru

What if you interpolated the first color value to the second using a real attribute and constrain all those actor's color to that attribute. Have another attribute that turns on the constrain during the interpolate and turn it off after the interpolation is done. Then the constrains become inactive.

Socks

@Tiny_Ideas said:
Socks Thats correct

I like a man with ambition 210 concurrent interpolations is ambitious indeed ! Glad to hear GS didn't keel over and die, impressive stuff.

@Tiny_Ideas said:
This doesn't cause an issue if the value is typed in. But as soon as it starts to try reference another attribute, it can't handle it.

Like The_Gamesalad_Guru says, maybe try interpolating a single value, and constraining the actor's colours channels to that interpolating value . . . ? If the actors are interpolating the same colour at the same time you could try referencing the game's clock so it needn't wait for the code to cycle around and deliver the data from the attribute - you don't say in what way the attribute is referenced, or mention its relationship to the other actors - but layer order may play a role.

Also if any of the colour channels are changing at the same rate you could reference them (so - for example blue could reference green).

@Tiny_Ideas said:
If there is another way to change a colour of an actor over a length of time then I am all ears.

Use the animate behaviour, I do it all the time, much less taxing than three Constrain behaviours.

The_Gamesalad_Guru

@socks I've talked with him about this project. I think he only changes one value. It would he cool if we had some effects for image changes like cross dissolve.