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?
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?
#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
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 ...
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
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:
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:
- Server starts up and begins non-cyclic "rise" animation
- Client #1 joins and sees "rise" animation play from the start
- Client #2 joins after the animation has ended and doesn't see it at all.
#6
Fixed, I think.
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.
Torque Owner Demolishun
DemolishunConsulting Rocks!
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.