Tasharen Entertainment Forum

Support => TNet 3 Support => Topic started by: Filip on December 06, 2013, 04:16:29 AM

Title: TNet: Problem with SendQuickly
Post by: Filip on December 06, 2013, 04:16:29 AM

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

Title: Re: TNet: Problem with SendQuickly
Post by: ArenMook on December 06, 2013, 04:26:53 AM

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?

Title: Re: TNet: Problem with SendQuickly
Post by: Filip on December 06, 2013, 05:27:51 AM

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.

Title: Re: TNet: Problem with SendQuickly
Post by: Filip on December 06, 2013, 07:15:27 AM

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?

Title: Re: TNet: Problem with SendQuickly
Post by: ArenMook on December 07, 2013, 12:49:53 AM

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.

Title: Re: TNet: Problem with SendQuickly
Post by: Filip on December 07, 2013, 09:34:55 AM

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?

Title: Re: TNet: Problem with SendQuickly
Post by: ArenMook on December 07, 2013, 04:25:42 PM

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

Title: Re: TNet: Problem with SendQuickly
Post by: Filip on December 08, 2013, 01:48:20 PM

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

Title: Re: TNet: Problem with SendQuickly
Post by: ArenMook on December 09, 2013, 01:05:32 AM

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.

Title: Re: TNet: Problem with SendQuickly
Post by: Rogdor on December 09, 2013, 10:55:48 AM

Quote from: ArenMook on December 09, 2013, 01:05:32 AM

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?

Title: Re: TNet: Problem with SendQuickly
Post by: ArenMook on December 10, 2013, 01:32:05 AM

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

Title: Re: TNet: Problem with SendQuickly
Post by: Filip on December 10, 2013, 09:29:29 AM

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

Quote

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?

Title: Re: TNet: Problem with SendQuickly
Post by: ArenMook on December 10, 2013, 11:33:58 PM

I was referring to Custom Object Creation (http://www.tasharen.com/forum/index.php?topic=5416.0) 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?

Title: Re: TNet: Problem with SendQuickly
Post by: Filip on December 11, 2013, 09:10:08 AM

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.

Title: Re: TNet: Problem with SendQuickly
Post by: ArenMook on December 12, 2013, 06:34:41 AM

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).

Title: Re: TNet: Problem with SendQuickly
Post by: Filip on December 28, 2013, 07:34:19 AM

Sorry for late reply, I have been away for a christmas trip.

TNManager is located in my startup scene, yes. It is attached to the same gameobject as where TNAutoJoin is attached. TNAutoJoin joins another scene where the actual game content is. (Just like your multiplayer tutorial with dedicated server).

Quote

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.

I am not talking about incompatibility with TNAutoSync and Mecanim. I understand that TNAutoSync is generally not good for syncing your "main character". I am talking about that I believe it's impossible to structure my game objects like you mentioned:

Quote

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

Apply root motion will cause the "GameObject" to move relatively to the "Rigidbody", in such way the Rigidbody itself will not be affected by the Mecanim's movement. The colliders will stay in the same fixed global position while the GameObject with the attached animator will move around. The problem I'm facing is that I don't know how to tell Mecanim to apply root motion onto the Rigidbody instead of the GameObject.

Title: Re: TNet: Problem with SendQuickly
Post by: ArenMook on December 28, 2013, 05:08:32 PM

Mecanim's root motion moves the rigidbody in an uneven, animation-controlled fashion. It's very difficult to sync this over the network fluidly. Your best bet is to either sync whatever causes the root motions to occur (such as joystick thumb position), or not use root motions. Animation-controlled movement is great for the main character of single player games, but it's a bad idea for everything else as the blended animation movements are often unpredictable.

Title: Re: TNet: Problem with SendQuickly
Post by: Filip on December 28, 2013, 06:13:14 PM

Good point Aren, It is probably best to inactivate root motion like you say, and apply the speed to the rigidbody parent directly.

I am finding TNet more and more appealing to my project. It's really agile and easy to work with. Keep it up and thanks for the support!

Title: Re: TNet: Problem with SendQuickly
Post by: ArenMook on December 29, 2013, 01:27:42 AM

I'm glad you like it! :)