TNet: Problem with SendQuickly

[Filip]

I get following console errors when I use SendQuickly instead of Send:

Trying to execute a function 1 on TNObject #16777214 before it has been created.

Trying to execute a function 2 on TNObject #16777214 before it has been created.

failed to convert parameters
LocomotionPlayer.SetRotation (System.Single)

In the Update function I have:

1. tno.SendQuickly(1, TNet.Target.AllSaved, transform.position);
2. tno.SendQuickly(2, TNet.Target.AllSaved, speed);

And in the bottom of the same class I have:

1.         [RFC(1)]
2.         void SetPosition(Vector3 val) {
3.                 mPosition = val;
4.         }
5.        
6.         [RFC(2)]
7.         void SetSpeed(float val) {
8.                 mSpeed = val;
9.         }

Everything is running as it should, but I get those errors in the console, which is bothering me. If I change SendQuickly to Send I do not get any errors.

Can anybody please tell me what I'm doing wrong?

Thanks,
Filip

[ArenMook]

I don't recommend sending frequent calls to yourself if you can avoid it. Use Target.OthersSaved instead.

That said, I don't remember if I removed this feature or not, but Send likely caches the RFCs, waiting for the object to be created, while SendQuickly does not. The error itself tells you that the object hasn't been created yet. Did you use TNManager.Create to make it?

[Filip]

Thanks for the fast reply. I'm using TNAutoCreate to create it.

What is the proper way to see if the object has been created? I tried to do

1. if (tno.isMine()) {
2.   tno.SendQuickly(1, TNet.Target.AllSaved, transform.position);
3.   tno.SendQuickly(2, TNet.Target.AllSaved, speed);
4. }

but I still get the same errors.

[Filip]

I now noticed that the errors occurs when receiving the RFC, not sending. I.e. there is no error on the client that send the rpc. It occurs on the part that has just joined the server and is creating a new tno and at the same time receiving RFC. Perhaps we can block incoming RFC until tno is created somehow?

[ArenMook]

All object creation calls happen before other RFCs. So unless you are creating the object manually in one of your RFCs instead of going through TNManager.Create, it shouldn't be an issue.

Now that I think about it though... messages that go through sendQuickly likely bypass the proper order of things as they sent unreliably (via UDP), and can arrive in random order.

[Filip]

I'm still having the same problem, but I'm not sure that it's worse than just an annoying error message, because the game is working as it should?

I have reworked the code quite a lot, but I'm still syncing the position 30 times / second via SendQuickly. (Is there another way to sync the position?) I find it odd that noone else is having this bug... Am I the only one syncing the position with SendQuickly in FixedUpdate 30 times / second?

[ArenMook]

30 times per second sync of position? That's... a lot. See my response here:

http://www.tasharen.com/forum/index.php?topic=7017.msg33116#msg33116

[Filip]

OK, thank you. I have tried the SyncRigidBody-script. Tried to use it with the default value of 10 syncs / sec, (which I assume you consider far too high, so why is it default?). Anyway it looks not good at all. Tried to decrease it to 5 syncs / sec, and it looks horrible. The player bounces forth and back lagging A LOT. Really feels like I'm out of options here... I really thought TNet would have some ready scripts for syncing simple character movements in an ease - seems like I took a bite off more than I can chew... I don't want to invent the wheel again and write some interpolation mambo jambo that some people are talking about in this forum.

Also, I'm not doing a helicopter game so I don't want to buy your ready-made game for 65 bucks.

Thanks

[ArenMook]

Small note before I forget again... all custom creation handlers must be on a persistent (not dynamically instantiated) TNObject. If they aren't, you will be seeing errors like "trying to execute".

All network updates are going to be jittery by the nature of how they work. Think about it... your framerate is 60 FPS+, but network updates < 20, and are not evenly spaced like FixedUpdate. The most common approach to addressing this issue is simply making the renderers use Spring type lerp movement to "move after" the rigidbody.

You don't need to write custom scripts for that. Simply structure your objects like so:

Rigidbody, TNObject
- Collider 1
- Collider 2
- GameObject with LagPosition (and possibly LagRotation) on it
-- Renderer

This will mean that the rigidbody and colliders will always be using the latest data, while the renderer will trail behind your rigidbody, thus resulting in smooth looking movement.

No code necessary, and no need to buy the MPGSK. This is the same method I use in the 2nd example with the spawning cubes.

[Rogdor]

You don't need to write custom scripts for that. Simply structure your objects like so:

Rigidbody, TNObject
- Collider 1
- Collider 2
- GameObject with LagPosition (and possibly LagRotation) on it
-- Renderer

This will mean that the rigidbody and colliders will always be using the latest data, while the renderer will trail behind your rigidbody, thus resulting in smooth looking movement.

No code necessary, and no need to buy the MPGSK. This is the same method I use in the 2nd example with the spawning cubes.

That was so informative that I bookmarked it for my notes. Perhaps a good choice to go into the FAQ?

[ArenMook]

Done. http://www.tasharen.com/forum/index.php?topic=6538.msg33291#msg33291

[Filip]

I now see a light in the tunnel, thank you.

Small note before I forget again... all custom creation handlers must be on a persistent (not dynamically instantiated) TNObject. If they aren't, you will be seeing errors like "trying to execute".

I don't understand this. "Custom creation handlers" - are you referring to the AutoCreate-script? I have dragged this script onto a persistent cube in my scene. You must be referring to something else?

I agree with Rogdor. Very informative, thanks for that. Just one thing... I don't know how to tell Mecanim to apply root motion onto the "rigidbody object" instead of the character object. Any clues?

[ArenMook]

I was referring to Custom Object Creation handlers. They need to be on a persistent TNObject.

Not sure what you mean about the motion part. Reference the rigidbody object on your script, then use it?

[Filip]

Thanks for clearing out the "Custom Object Creation handlers". I am not using it, I'm using the TNAutoCreate script which I believe use the standard TNCreate script? I still get the "Trying to execute a function 1 on TNObject #16777214 before it has been created." everytime I start.

"Apply root motion" is Mecanim's built-in functionality to apply the animation motion to the gameObject that owns the Animator. So that the animator is automatically adjusting transform.position for the GameObject according to animations internal movement.
http://docs.unity3d.com/Documentation/Components/class-Animator.html
The problem is that I don't think it's possible to tell the animator to "Apply root motion" to a parent object. So if I setup the structure as you suggest, it will move the game object around inside the parent container (Rigidbody, TNObject).

On the other hand it's possible to permanently disable "Apply root motion", and handle the motion manually. But then the movement will not look as realistic, for example the feet might slide on the ground a bit, since it hard to sync the exact movement speed with the feet placement on the ground. Lots of animations have root motion that makes alters the transform.position of the gameobject, and it's a nice feature to have.

[ArenMook]

Where is your TNManager located, Filip? The TNManager must be present in the scene with a TNObject script attached to it.

It's generally best to place it in your start-up scene so that it's always going to be there.

I don't recommend synchronizing position and rotation using TNAutoSync when using mecanim motions. Sync whatever causes the motions states to change, or the changed states themselves. This way each client will have an up-to-date set of states and do their own movement logic.

Have the object's owner periodically send out the pos/rot so that other clients can make corrections as necessary (1-2 times per second is enough).