Messages

1

TNet 3 Support / Re: DontDestroyOnLoad and TNManager.Create

« on: June 19, 2014, 05:43:13 AM »

Alright, thanks.

2

TNet 3 Support / Re: TNSerializer structs

« on: June 19, 2014, 05:41:12 AM »

You can pass in parameters to Activator.CreateInstance, so it could be used for the other function. The only difference is that it would throw an exception if a constructor with the provided parameter signature is not found, instead of falling back on the default constructor or returning null, like the current implementation.

But, assuming that's not a problem, the two methods could be replaced with just

1.         /// <summary>
2.         /// Create a new instance of the specified object.
3.         /// </summary>
4.  
5.         static public object Create (this Type type)
6.         {
7.                 return Activator.CreateInstance(type);
8.         }
9.  
10.         /// <summary>
11.         /// Create a new instance of the specified object.
12.         /// </summary>
13.  
14.         static public object Create (this Type type, int size)
15.         {
16.                 return Activator.CreateInstance(type, size);
17.         }

Although, I haven't tested the performance of Activator vs invoking the constructor via reflection.

3

TNet 3 Support / DontDestroyOnLoad and TNManager.Create

« on: June 18, 2014, 06:32:05 PM »

I have a few dynamic objects which persist between scenes. I am getting "Network ID ## is already in use" error messages, which appear to be caused by TNManager.LoadLevel resetting the object counter used for assigning ids. Is there a supported way of having network objects correctly surviving a scene load?

4

TNet 3 Support / TNSerializer structs

« on: June 18, 2014, 11:33:15 AM »

In the method TNSerializer.Create(this Type type) (TNSerializer.cs:259) you use reflection to get a constructor for the type provided. If this type is a struct, this doesn't seem to work.

I swapped out the entirety of that method with...

1. Activator.CreateInstance(type);

..and everything seems to work fine for structs and classes. Was there a reason you went down the constructor reflection route instead of using Activator?

5

NGUI 3 Support / Re: Color tint support for custom shaders

« on: June 10, 2014, 10:40:18 AM »

I believe it uses vertex colours for tinting sprites in the default shaders.

6

NGUI 3 Support / Re: Bug: 2D UI Events Inside Clipped Panels (3.6.1)

« on: May 31, 2014, 03:41:24 PM »

Not fixed in 3.6.2. Colliders inside clipped panels don't receive events. The colliders do receive events when setting the same panel to "Constrain but don't clip". It doesn't seem like there were any changes to UICamera.cs at all in 3.6.2...

7

NGUI 3 Support / Bug: 2D UI Events Inside Clipped Panels (3.6.1)

« on: May 29, 2014, 02:16:11 PM »

When using the 2D UI event mode I found a bug where widgets inside a clipped panel had their events filtered out by the IsVisible check on the clipped panel. It was using the raycast world pos, which was 0,0,0 for some reason.

I changed line 742 of UICamera.cs from

1. if (IsVisible(ref mHits.buffer[b]))

to

1. if (IsVisible(lastWorldPosition, mHits[b].go))

and that fixed it.


EDIT: In fact, I'm encountering a lot of other issues with 2D colliders. One is that below a certain size the collider no longer gets hit by raycasts (I assume there is some minimum size that Unity is disabling the collider at)

8

TNet 3 Support / Re: Networked Game Structure

« on: May 15, 2014, 01:18:56 PM »

The parent objects won't be destroyed, so it should be fine then. Thanks.

I'm on 1.9.0b. I had to add System.Double to TNSerializer.cs (in WriteObject(), GetType(int) and GetPrefix(Type))

9

TNet 3 Support / Re: Networked Game Structure

« on: May 15, 2014, 09:48:29 AM »

If I were to create an object via TNManager.Create, then another by TNManager.Create, and parent the second object to the first, would that cause problems? I've got them parented so the planet moving will move all the buildings attached to it. I could move them out and update the positions in Update() if you think parenting would be a bad idea.


Another misc question: Any reason why System.Double isn't one of the default supported types for RFC parameters? Took me a while to track down why an RFC call was failing (the error wasn't particularly helpful... actually, the error was fine, I don't know why I didn't realise sooner) until I found that double's don't serialize correctly.

10

TNet 3 Support / Re: Networked Game Structure

« on: May 14, 2014, 07:31:10 AM »

Are there any complications I should expect when using nested TNObjects? I've browsed through the code for TNObject, and it looks like there is quite a bit of parenting logic in there. RFC calls seem to seek out methods in all MonoBehaviours that are in child gameobjects, not just the ones attached to the same object as the TNObject behaviour.

EDIT: Another question: Should RFC ids be unique across all objects, or unique within an object? IE can I have Class1 with a method with RFC ID 1, and Class2 also having a method with ID 1 and not have any problems?

11

TNet 3 Support / Re: Networked Game Structure

« on: May 14, 2014, 05:27:13 AM »

I can definitely see it working with a single TNObject on the root Planet. It just seems... wrong to put all the logic in once place like that. I'm not very experienced with networking, so maybe that's just how it has to be done.


Misc. question: Are reliable (TCP) messages executed in the exact same order on every client?

12

TNet 3 Support / Networked Game Structure

« on: May 13, 2014, 08:03:22 PM »

Hi Aren,

I currently have a game which has a structure like this: (classes in bold)

- Each connected player has control of a Planet
- Each planet contains 12+ BuildingSlot gameobjects, each of which can contain a building of any type.
-- Player can trigger construction of Building gameobjects in these slots (Building is subclassed by many unique building types)
-- These buildings have their own unique properties to sync (e.g.: reload time for weapons), as well properties common to each (health, construction progress, etc)
-- Buildings may be destroyed by the actions of other players

I currently have it set up so the Planet, BuildingSlot and Building all have their own TNObject, to prevent all the building logic taking place in the root Planet object.

I've read around some previous topics in this board and it looks like you recommend against having nested TNObjects, I'm wondering how you would recommend structuring a system like this in that case. I'd like to avoid bundling all my building logic and communication in one place if possible.

Any advice would be appreciated.

Thanks!

13

NGUI 3 Support / Re: Culling Problem (3.0.6 f5)

« on: November 28, 2013, 03:51:23 PM »

Ah, yes, f6 has fixed it. Thanks a bunch!

Can I just say that the latest changes you've been making to NGUI (depth sorting, panel alpha, panel depth, the new UI event system, auto-resizing colliders to match widgets, etc) have made it an absolute joy to use. Thanks!

14

NGUI 3 Support / Culling Problem (3.0.6 f5)

« on: November 28, 2013, 03:39:37 PM »

Hi again. I'm having an odd problem with some 3D UI that worked fine in versions prior to 3.0.6.

I've made videos to show the problem:
https://www.youtube.com/watch?v=9UqnYuJ_w_Y <- Shows how the NGUI meshes are culled far too early
https://www.youtube.com/watch?v=ou_stg8vjaY&feature=youtu.be <- Shows how the distance that meshes are culled at changes depending on where the meshes are in world-space.

My setup is something like this:

UnderWorld GUI Camera - Shows the rings around the outside of ships (not all of them, I'm in the process of transitioning them all over)
Main Camera
OverWorld GUI Camera - Shows the ship option hexes

It seems that in some areas of the world, the generated NGUI draw calls are seemingly culled when the camera gets too close. The camera's near clipping plane is set as low as possible (and this setup worked fine pre 3.0.6, so something has changed with NGUI to cause this).

Any ideas?

15

NGUI 3 Support / Re: Flickering Issue

« on: November 26, 2013, 03:32:41 PM »

That's the flickering resolved for me, thanks Aren. The alpha stuff still happens, but my workaround works fine for that.