Game Development Community

Playthread, non-cyclic animations, and clients

by Azaezel · in Torque 3D Professional · 08/03/2013 (12:00 am) · 6 replies

Not entirely certain where to start digging here, so for now, I'll just lay out the issue while I'm digging around:

We've got a set of shapebase derivatives (not players) utilizing %obj.playThread( 0,%anim );

When %anim references a cyclic animation thread, clients joining after the animation is triggered see the animation. When it's not, they do not.


Anyone have any insights to offer in terms of where to focus the research?

#1
08/03/2013 (1:53 am)
Interesting. When are you triggering the animation? Is it possible it is completing the animation before the client can see the animation? What you may want to do is have a trigger where the client spawns into. This should cause an on enter trigger event. Then you can tell the animation to start the animation. You can then set a flag that the animation has been seen or delete the trigger itself if the makes sense for your game.

It does not necessarily need to be a trigger, just something that will react to the presence of the player and allow you to ensure it plays only once through a flag of some sort. It could even be a temporary AI Player if that makes more sense for the game.
#2
08/03/2013 (10:17 am)
Couple cases off the top of my head: during their onAdd, and during their onDisabled. I have considered faking it, but I'd much prefer to drill down to the scoping code and properly snap them to a synced animation position. Just not sure where to put that first spade.
#3
08/03/2013 (1:40 pm)
I am not sure where to look for that. The first thing I would find out is if you can reliably tell when the client can actually "see" the object. I would hazard a guess there might be a call to on add to scene or something similar. Or it might be in the connection object. You will probably need to trace the execution and try and determine when by playing a tone or something non visual. Sorry I can't give you something more definitive.
#4
08/03/2013 (8:23 pm)
It'll be in the object transmission system somewhere. You did give me a game-sepcific workaround while I poke at this though:

function BridgeTriggerData::onTickTrigger(%this,%trigger)
{
	if (!isObject(%trigger.owner))
	{
		%trigger.delete();
		return;
	}
	if(%trigger.owner.isDown != true)
	{
		%trigger.owner.setThreadPosition(0,1);
	}
	else
	{
		%trigger.owner.setThreadPosition(0,0);
	}

For one example I've shared with the class, where .owner is an object reference tacked on to a trigger. That (and another one that swaps between a cyclic and non-cyclic animation depending on it's disabled state) does tell us that the client is getting the animation sent, but it needs to be reminded of the position...

Thinkin a long term fix'll end up in either ShapeBase::writePacketData / readPacketData , or altering ShapeBase::packUpdate ...
#5
09/13/2014 (3:59 am)
Right, I'm looking into this. I've set up a really basic test harness in t3d-bones. When the server is created, it spawns a StaticShape with a 10-second or so animation. When a client connects to it, it should see the animation. At the moment, the client does see the animation, but the position is incorrect. I can load up two clients and their animations are completely out of sync. So, that's one problem.

I'm as-yet unable to actually make a bloody non-cyclic sequence. You'd think the code would work if I just changed playThread(0, ambient) to playThread(0, rise), but no dice - client sees nothing. Which you might think is Az's bug appearing, but even if I call setSequenceCyclic(rise, true), same deal. Apparently only the ambient will play. Hhh.

EDIT: okay, so I have to create a TSShapeConstructor on the client as well. I can do that. So this is the sequence I'm seeing:

  1. Server starts up and begins non-cyclic "rise" animation
  2. Client #1 joins and sees "rise" animation play from the start
  3. Client #2 joins after the animation has ended and doesn't see it at all.
So now Client #2 is in an inconsistent state where it sees the cube on the ground, whereas the server and Client #1 see it in the air. Woot.
#6
09/14/2014 (4:22 pm)
It seems that unpackUpdate always reads the position as 0. Which makes sense, because if you do a search on ShapeBase::Thread::position, it's never actually updated on the server. I'm experimenting with that...

Fixed, I think.